From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: Opportunistic GC Date: Wed, 10 Mar 2021 09:18:39 -0800 Message-ID: <87lfav6i6o.fsf@rfc20.org> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37010"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Pip Cet , Stefan Monnier , eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 10 18:54:00 2021 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 1lK320-0009V6-8a for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Mar 2021 18:54:00 +0100 Original-Received: from localhost ([::1]:53646 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lK31z-00021J-A4 for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Mar 2021 12:53:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36442) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lK2U0-0001fP-Ka for emacs-devel@gnu.org; Wed, 10 Mar 2021 12:18:52 -0500 Original-Received: from relay13.mail.gandi.net ([217.70.178.233]:57505) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lK2Ty-0004A3-60; Wed, 10 Mar 2021 12:18:52 -0500 Original-Received: from mdeb (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay13.mail.gandi.net (Postfix) with ESMTPSA id E2A1E8000E; Wed, 10 Mar 2021 17:18:43 +0000 (UTC) Original-Received: from matt by mdeb with local (Exim 4.94) (envelope-from ) id 1lK2Tn-000mFQ-Tr; Wed, 10 Mar 2021 09:18:39 -0800 In-Reply-To: Received-SPF: pass client-ip=217.70.178.233; envelope-from=matt@rfc20.org; helo=relay13.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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.23 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" Xref: news.gmane.io gmane.emacs.devel:266288 Archived-At: Pip Cet writes: > On Mon, Mar 8, 2021 at 3:37 AM Stefan Monnier wrote: >> I've been running with the code below recently to try and see if >> opportunistic GC can be worth the trouble. > > Just a random idea: What if we exploit the fact most people have more > than one CPU core these days, garbage-collect in a separate fork()ed > process, then do only the sweeping in the main process? > > Immediate advantage: we'd never mark objects in the "real" Emacs > process, making debugging easier. > > My implementation proposal would be to pipe(), fork(), run GC, then > send through the pipe the Lisp_Objects which can be collected by the > original Emacs. > > For me, it was a bit difficult to see that this would indeed be safe, > but I'm now pretty convinced it would be: objects that are unreachable > in the child Emacs cannot become reachable in the parent Emacs (they > might show up on the stack, but that's a false positive). > > We'd have to be careful not to run two "real" GC processes at the same > time. Hi Pip, Neat idea. Are there examples of other GC implementations using this approach? Perhaps this has been tried before, elsewhere, and we could learn a lot from that. I looked for myself and found https://dlang.org/blog/2019/07/22/symmetry-autumn-of-code-experience-report-porting-a-fork-based-gc/ which talk about this idea in the context of the D run time. This page mentions a different idea: doing the mark pass with multiple threads. This might be worth exploring; the two ideas are composable with each other. Matt