From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector Date: Fri, 24 Nov 2017 23:05:45 +0000 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1511564840 2497 195.159.176.226 (24 Nov 2017 23:07:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Nov 2017 23:07:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 25 00:07:11 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 1eIN3v-0008PR-3M for ged-emacs-devel@m.gmane.org; Sat, 25 Nov 2017 00:07:11 +0100 Original-Received: from localhost ([::1]:51396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIN42-0004yN-7u for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 18:07:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIN3L-0004xv-DA for emacs-devel@gnu.org; Fri, 24 Nov 2017 18:06:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIN3G-0004xy-34 for emacs-devel@gnu.org; Fri, 24 Nov 2017 18:06:31 -0500 Original-Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]:44156) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIN3F-0004vh-SY for emacs-devel@gnu.org; Fri, 24 Nov 2017 18:06:30 -0500 Original-Received: by mail-wm0-x22a.google.com with SMTP id r68so24877731wmr.3 for ; Fri, 24 Nov 2017 15:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K1/sGyFypBHb4ppuowvWz3QunMoy9gFZ+cgzAPn9u3o=; b=oobv5gvPsMVrLbjVgYeAlu7M/NCYnpSGDzOIe3CbpzbwNBHMMC9WnRLtZMrbIpAmxr zsXDXATE0gev5VMXt4ya9oZTzOfO0k/q4R4hcjwFyvHUgmUVH4MiooAoewMz0eUv+ZKq Gkkj0J7oRRbVLgUYgZNvBQd6Ga1Imw9gCRuifFDGrXxEzunVGK2m+vk/gINCGdlPZSIH DSYOfSmuXM504s0gS3Y0cbSrqZ+EPtoLBVoj9mfXOOsUKtLzRL+8SxClsoioKyaRxajS TY/bpLp19pC4g0SkXkoIoMSS6GOIl0A9WsKNd3HsVpMnoZaD6aKENVCCIVeIevKBDcoO brpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K1/sGyFypBHb4ppuowvWz3QunMoy9gFZ+cgzAPn9u3o=; b=f7beM0mFumqtlQzs4iwZFKEhfUY94TBbNnALaoiGXlR7DWusCePsIzcmYIvgvSnFRZ 7VM1c8Ld22EpCOS8nAWU6J+RPEJ9RJQVqqeDkxpHxe4SLyWrZpbdynVCCqO3oCNonfqz e0D8xXlOys8rVmW1+EAj/0GaUQwakuK7nU7vypWWGrOgX3WNNtlOgvC2iDMlAIayPOnj don7XEhBaWQIV3YW4plvZEN8lMdFTA0wrB3EAyvUSNfq5CO1/D9y+bwvUWTUjeICvvSq tpNUlYVeLcSc0sK74S0J/Qf8R/Y2G2RE7oAp0tN5unT4ys8xrzciQ9vbIjhG5aPtlBOS ID5g== X-Gm-Message-State: AJaThX5i2AQ+S/YJHJGoFF6VFRg3ZJ6xuyVFx1odVKVIH4aToTSZGDDe Nu1cbsnRnGkN+B6uPovpQAjEAX/0AgmRhrdh5iQ= X-Google-Smtp-Source: AGs4zMbeZ6Ap18DkNcGtgE7ODsc29VRl9ryXdIEmJ4FGfhk+qzhfZFAaEqbbDX5AIKNmbfAnHUlmnCs+v+fpXMWtkTU= X-Received: by 10.80.144.48 with SMTP id b45mr39725563eda.127.1511564786470; Fri, 24 Nov 2017 15:06:26 -0800 (PST) Original-Received: by 10.80.150.6 with HTTP; Fri, 24 Nov 2017 15:05:45 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22a 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:220443 Archived-At: > I'm not sure what we should do with it, tho: I think the simple awareness that doing the switch at some point in the future is feasible is quite enough to satisfy me. Part of what triggered this was what I perceived as a "switching GCs is impossible, so let's not worry about it at all" attitude. My main reason for writing a converter in the first place is that as the Emacs code base is relatively stable, at least as far as using regular and well-structured C code goes, there's no rush to do anything. I'll probably just continue to lurk on the list until I hear someone say something that makes me think they'd benefit from running (part of) the converter, then pounce :-), and I hope my converter will still work then. > I don't think building Emacs by preprocessing all files through a C->C++ converter is going to be a very popular proposition (e.g. will make debugging the "C" code even more fun). I agree completely. The current converter uses Perl and Marpa, which are Free Software but not GNU, so it's definitely not an option. But let's not make it any harder to eventually move to a moving GC. In particular, let's require save values to know where their Lisp_Objects are! I've ignored that issue for now, but "potential Lisp_Object" is a bad thing to have. (For the same reason, I would like to submit a patch to change SAFE_ALLOCA to SAFE_ALLOCA_LISP where the latter is appropriate). I think the current compromise whereby stack values are conservatively marked and heap values are precisely Lisp Objects or not is good. 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. 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. So Lisp_Object f(Lisp_Object arg) { Lisp_Object val = XCDR (arg); return val; } would become Lisp_Return_Value f(Lisp_Handle arg) { Lisp_Value val = XCDR (arg); return val; } I don't think that's horrible, though better names could surely be found, but others might disagree. [1] I don't think there's a legal issue with merely using Perl and Marpa to run a converter that I'd gladly transfer copyright of to the FSF. If there is, please let me know!