From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Collecting markers with MPS Date: Wed, 24 Apr 2024 11:08:00 +0200 Message-ID: References: <87cyqfjk6n.fsf@gmail.com> <86sezb2oj2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3834"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Helmut Eller , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 24 11:09:00 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rzYcd-0000gs-RN for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Apr 2024 11:08:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzYbs-0000vj-9t; Wed, 24 Apr 2024 05:08:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rzYbp-0000nL-LZ for emacs-devel@gnu.org; Wed, 24 Apr 2024 05:08:09 -0400 Original-Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rzYbm-0007Jh-3X; Wed, 24 Apr 2024 05:08:09 -0400 Original-Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a557044f2ddso735315666b.2; Wed, 24 Apr 2024 02:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713949682; x=1714554482; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=XKNKjL3SAFcHdbIuQkIsHFGjRrzcfHYlEkuPbMoy/d0=; b=JWboBWGrlsoNU42n6Dbt9O8CvdaZU06v1ke3Rfe8c1d8JuiUTykCR20b7HDLKG+kl4 xKuVgaQzrysIQ2fL8Q+LNNorU5WjhnOtQSPnzI1Pk0CODgCfY8Lp4ZWjVDznV9gXOC23 PhobJiqqk7EOyOl7uYtwcaqZ01QRlSeU5hxLO67CM1esVIZ7Y3qA/r95k3eKrZsA6jUG C/v56CdvcHW6YVdxRVxJCJudoq0Ph6ZRO5bmA8ph7OUOol3Tk9TyvqzXud0j4g0bBLKh ZvqP6rLTiP8scWLW7qphyULqmsydruyx7mYz4YiqOTVDe5sAl5zwOXr1dlMpTmZf2at9 bm/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713949682; x=1714554482; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XKNKjL3SAFcHdbIuQkIsHFGjRrzcfHYlEkuPbMoy/d0=; b=iI4n9yg4sdsO9DPMJxSYAtfHPKzA2gSfilersRTg9C2IuDbgjUTP7ymAp005Pi25cv NyAaiPPdoow9tGqE1piF4rTgQ9msEWhB7nLiUqVzG8UqE+9FxXxh7y3dEU5GMeuwpT8K 45/8Cy9/Ce6c5XNozRC5fhRZSu/1kJTXpejFTy4uK4GAijyiETBtvjGCF5ZouNrXhgGq NLbRsgX0YZWp/mHCQH6vGc5To5D0HacGnWzce1uh8O01axOipDtW4X1S9xVhOwtyM2nm gP7+Yw9JdiEWyfCeJEdBzaJdY4da0ctbHI2XzrVHy+kzrdF+T/ZNJZ2K6zEe2fT/T0UU OFkA== X-Forwarded-Encrypted: i=1; AJvYcCUC/7jkNu+B93kix/fF4EFzjbtn5D1DseQ7OBoYEqq1y4GgbUncadITXgbzx89SALSwN4QWls+wXd6UgqBnpT8slQfN X-Gm-Message-State: AOJu0Yxm65RVlztN8HBrSJAwxzea05s0GYYBuDoIJciq4fm3eiQQ8Cdo 9ygO/EdR9htKjjtA2RR9mrdIXx8F3kW9zqpE4iVkDyCeCDm64KJhScUmbmsb X-Google-Smtp-Source: AGHT+IE4T2iwKAwyd+iN+PM5hir/5nK+jDMIbZiLOnGiRNo6wILDjIlQ30PSE+d1/6wFWWsI1D5AaA== X-Received: by 2002:a17:907:7792:b0:a55:b021:c0b1 with SMTP id ky18-20020a170907779200b00a55b021c0b1mr1145352ejc.9.1713949682226; Wed, 24 Apr 2024 02:08:02 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3abb0.dip0.t-ipconnect.de. [79.227.171.176]) by smtp.gmail.com with ESMTPSA id lk19-20020a170906cb1300b00a526418d0ebsm8103184ejb.74.2024.04.24.02.08.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 02:08:01 -0700 (PDT) In-Reply-To: <86sezb2oj2.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Apr 2024 10:44:17 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::62e; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318023 Archived-At: Eli Zaretskii writes: >> From: Helmut Eller >> Cc: emacs-devel >> Date: Wed, 24 Apr 2024 09:26:08 +0200 >>=20 >> On Sat, Apr 20 2024, Gerd M=C3=B6llmann wrote: >>=20 >> > - Figure out what is done in the old GC in garbage_collect that is not >> > directly related to GC, and how to do that when GC is concurrent. >> > Examples are buffer undo_list, window prev_buffers/next_buffers >>=20 >> In the igc branch, markers are currently not collected because they are >> referenced from the buffer's chain of markers. The old GC has special >> code to break this link. There is also special code to break links from >> the undo-list to markers. Exactly! Glad that you look at this! >> With the MPS, we could introduce explicit weak reference objects, >> similar to WeakRef in Javascript[*]. Buffers would then, instead of the >> current chain of markers, have a list of weak references to markers. >> (Markers would no longer have the embedded "next" field.) The same for >> the undo-list: instead of markers, it would contain weak references to >> markers. >>=20 >> This would allow markers to be collected, but the empty weak-ref objects >> would still be in the undo-list and the buffer's markers-list. A timer >> could periodically go through those lists and remove the empty >> weak-refs. >>=20 >> Does this sound like a reasonable plan? To me, it sounds like it will >> require relatively big changes to the buffer code. Much bigger than the >> 200 or so lines of special code in the old GC. Also, the undo-list is >> visible to Lisp code, so those weak reference objects in there must be >> new types of Lisp objects. Makes sense to me, but I must say that I have 0 experience with that using MPS. It might require some experimentation how to about implementing such weak references, but that could be fun. Let me give Eli a brief overview what MPS has. MPS support weak references. Objects containing weak references must be allocated from a special type of memory pool, which MPS calls AWL pools (=3D Automantic Weak Linked pool or so). Such a pool, and MPS allocatioin points are already there in igc. An object in AWL can contain references, but these references must either all be weak or all be strong. (That's okay for weak hash tables, where all keys are weak/strong or all values are weak/strong references. Which, BTW, is the reason why I split key_and_value into two vectors in the branch.) >> On the plus side, explicit weak reference objects could make some things >> easier to understand and might be more widely useful to Lisp >> programmers. Yes, I'd find that a big plus, too. >> What do you think? Is there an more elegant alternative? Can't think of one.=20 > My opinions here mean very little for now, as I don't yet have a good > view of the issues, but in general: why do we have to do everything > the old GC did in the new GC? Can't we leave some of the stuff to be > done in the main thread? For example, the old GC would compact buffer > text, Lisp strings, and font caches -- this cannot be done from a > different thread, AFAIU. Why not keep doing this from the main > thread, like we do now? They are not really directly relevant to GC, > just some housekeeping tasks that need to be done from time to time. > Yes, it would mean the main thread still needs to stop from time to > time, but for much shorter periods of time. And it will allow us to > sidestep the significant changes like those mentioned above, some of > which would mean Lisp-level changes that will affect Lisp programs. > > If leaving some of this stuff in the main thread is reasonable, we > could add the above two jobs to that part, which would allow us to > leave the existing related code almost intact. > > Does this make sense? Yes, it makes sense. One could of course use a timer. Or maybe, don't know, run something when we handle an MPS message. That just occurred to me a second ago, so it might be nonsense. But Helmut's idea _is_ pretty elegant and appealing I must say. And it relieves the client of some more work (with the idea of improved responsiveness...).