From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector Date: Fri, 24 Nov 2017 23:15:05 -0500 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1511583339 4834 195.159.176.226 (25 Nov 2017 04:15:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Nov 2017 04:15:39 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 25 05:15:34 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIRsK-0000Q9-JD for ged-emacs-devel@m.gmane.org; Sat, 25 Nov 2017 05:15:32 +0100 Original-Received: from localhost ([::1]:51931 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIRsM-000264-RF for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 23:15:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIRsG-00025k-I3 for emacs-devel@gnu.org; Fri, 24 Nov 2017 23:15:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIRsD-0000u1-2m for emacs-devel@gnu.org; Fri, 24 Nov 2017 23:15:28 -0500 Original-Received: from [195.159.176.226] (port=50495 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIRsC-0000td-Pz for emacs-devel@gnu.org; Fri, 24 Nov 2017 23:15:24 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eIRru-0007WP-Bf for emacs-devel@gnu.org; Sat, 25 Nov 2017 05:15:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 36 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:j23k7WHQc7vzlfQg/2p1LpE/pGY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220449 Archived-At: > We could, at some point in the future that's definitely not now, have > a flag day and run the preprocessor once[1] to disambiguate what are > currently Lisp_Objects by their uses, all typedef'd to Lisp_Object. IIUC by that you mean to somehow instrument all Lisp_Objects that are on the stack (and are currently traced via the conservative stack scanner), so that we can use a precise collector. This will only be acceptable if after the switch, invalid code (e.g. Lisp_Objects on the stack that aren't properly instrumented) is automatically detected. After all, we used to have some of that info (i.e. we used to do precise stack scanning by manually registering/deregistering Lisp_Objects on the stack. It wasn't precise enough for a moving GC, tho), but it was riddled with bugs because it was only maintained by hand. > Then switching garbage collectors becomes a matter of providing the > right header file rather than having to go through all the source > code, manually or with a converter. Again, there's no rush and no need > to do everything at once. No doubt, the GC can be changed. There's been some attempts at using the Boehm GC to replace Emacs's current GC, for example. It never went much further than an initial proof of concept, but I think it's pretty clear that it can be done. It's less clear if it can bring very many benefits, OTOH (clearly a generational or a concurrent GC would be desirable in some corner cases, but nowadays the GC is rarely a source of complaints). Also I think a non-moving GC will be a lot easier to accommodate. I'm not sure how your code deals with cases where we take a Lisp_Object and extract a C pointer from it which we keep long enough to survive a GC. Does your GC also trace through char* pointers into buffer text? Stefan