From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Collecting markers with MPS (was: STatus of MPS branch) Date: Wed, 24 Apr 2024 10:44:17 +0300 Message-ID: <86sezb2oj2.fsf@gnu.org> References: <87cyqfjk6n.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39353"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 24 09:45:05 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 1rzXJR-000A6m-JS for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Apr 2024 09:45:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzXIm-0000Wy-DB; Wed, 24 Apr 2024 03:44:24 -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 1rzXIj-0000WO-Rr for emacs-devel@gnu.org; Wed, 24 Apr 2024 03:44:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rzXIj-0000IO-Ip; Wed, 24 Apr 2024 03:44:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=rYFrK6+8kHuR4EQMrw1nQwizQIWOaDvcrxghQBn1wws=; b=RpBjr7cKS8OniPc1GU8O yBlPdfbItZkjvjqVQ8gpp3ff0vfv+xBP6Rfx4yQPS0XBKf25RyGs9YxnbmzvL9QgR6MvH+7j0sO6v DaJ3hYICVbQyHQBzwvhg9huUak4pl55yD7ihpx/wMGtXOFNsaKb7157wPUn5nIXhrC9XYJaBLfWuT lfvkhYZEuJaWnThsixl6Z50I7Gnv2ubsD8XWPIB+c+VjweGhjY+vmaCDrAVuszOJwNdSDy+zw6wYc rmKhgfqQLhOg6lkADAJRH1DSj/SO+hL4PdKc2I6f35JJLp2PR86bPxWOz1Y9QJIsEilh7SFdthgic v7feHzcISMf4Lw==; In-Reply-To: <87cyqfjk6n.fsf@gmail.com> (message from Helmut Eller on Wed, 24 Apr 2024 09:26:08 +0200) 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:318020 Archived-At: > From: Helmut Eller > Cc: emacs-devel > Date: Wed, 24 Apr 2024 09:26:08 +0200 > > On Sat, Apr 20 2024, Gerd Möllmann wrote: > > > - 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 > > 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. > > 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. > > 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. > > 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. > > On the plus side, explicit weak reference objects could make some things > easier to understand and might be more widely useful to Lisp > programmers. > > What do you think? Is there an more elegant alternative? 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?