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 16:23:02 +0000 Message-ID: References: <6f96617b-2c9a-2a2c-d39e-779f275c9bb8@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="94eb2c0df912f8e72a055ebcf93d" X-Trace: blaine.gmane.org 1511540640 9518 195.159.176.226 (24 Nov 2017 16:24:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Nov 2017 16:24:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 24 17:23:53 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 1eIGlc-0001wg-F9 for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 17:23:52 +0100 Original-Received: from localhost ([::1]:50046 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIGlj-0003BE-RZ for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 11:23:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIGlX-0003Av-EX for emacs-devel@gnu.org; Fri, 24 Nov 2017 11:23:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIGlV-0007ZL-N4 for emacs-devel@gnu.org; Fri, 24 Nov 2017 11:23:47 -0500 Original-Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:41780) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIGlV-0007NT-Az for emacs-devel@gnu.org; Fri, 24 Nov 2017 11:23:45 -0500 Original-Received: by mail-wm0-x22c.google.com with SMTP id b189so23374480wmd.0 for ; Fri, 24 Nov 2017 08:23:45 -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=Jeu6J3sCNN+g6kgko0FKhHI0azg9ZD2RIK/YnNmwXF0=; b=jhW7BTjSAErDrtg+uVEQT3mdscfERJ9ZS04uh9hlSiTkLKsEmQzGfs8cZa8gpGOcFK YX4AuMiPdoHOcufWAoH2UBgAKi+6+vpkmdR9ojQGHOTQSoHR9bkWmSfDv7QQ/BHF9GVB 7iSJQLla+W/1jDwfm2Q0rmICKUzjWaqCklfMWV+3WL7a+1BpT4Bvv0PmtHWSX2r7LlHu HGv4CQ1oJ6kPdU5zBlNzxAxdlQo9HRZtwY4KSmFIBdwBl1/537hjgjRoa/Z/MUIiYZ9L njBIgAUBZ4IcJ2XjBAUfhUPG8CsctwKaoIo5/NCbp/7u5kWTLo75TBbM90wptFzWAf6L qURw== 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=Jeu6J3sCNN+g6kgko0FKhHI0azg9ZD2RIK/YnNmwXF0=; b=ZuAn+AFdcLDTlvyXNWpJ8Vwf7FiivMT9bHTN2LYy8g34fn2ngnNU9wwWv9dHdxggt/ m6rr6nY1khV04ZCEE2wOkl3n2Ix49pbAnwhrx8AGMD2GF7TpAo4JQjkwBTCpXlL1PMC+ KHGuhPRW8J5g1GAfBwY/ZN7dr80NSVaruATbGsFqSvhpsnCRgNWVXsuKhPwcuimfHggf bsThL9MxutE4kbL74ti/D9u5CNweomld8ClU3QafkCVHeLiuYJ1rihOAuARhErKt15ZX Q/2BxwnvOGEUGTC/Cetp6n0Tgks5n5k88NH3yF3/AP6BQRRjs1bk1KezDLJAYcjtfJfR foLw== X-Gm-Message-State: AJaThX4yDaIQdUqnwGU5uejOwLvEVPiSzDz/cigYOKxHJ+8nPPTrAzV2 GQzao4x1kdtxZm+Lo+3URbfi6QcbaXkneyCmods= X-Google-Smtp-Source: AGs4zMYawnhbFgWaLpYmSIqcAF/B4zNgWdqKrHTy+Q7NO4igvOhPalMgCajXoNEu/RC+gl5QRn/JcPrNdeKdpByXsEk= X-Received: by 10.80.183.148 with SMTP id h20mr5472663ede.178.1511540624247; Fri, 24 Nov 2017 08:23:44 -0800 (PST) Original-Received: by 10.80.150.6 with HTTP; Fri, 24 Nov 2017 08:23:02 -0800 (PST) In-Reply-To: <6f96617b-2c9a-2a2c-d39e-779f275c9bb8@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22c 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:220431 Archived-At: --94eb2c0df912f8e72a055ebcf93d Content-Type: text/plain; charset="UTF-8" On Fri, Nov 24, 2017 at 8:07 AM, Paul Eggert wrote: > Wow Thank you. > sounds like you've done some interesting things, and it's interesting > to see that you got it to work at all with a copying collector. "At all" being about the limit of it, at present. While I managed to write that email without a segfault, there are plenty of race conditions that I'm aware of. I think we're fine in theory, though, once we make sure that signal handlers cannot trigger GC. (If my understanding is correct, signals can occur after every instruction, including in the middle of a call sequence while the argument, or return value, is unprotected). >> I do advocate making the >> official Emacs compile with G++ with the -fpermissive option, to help >> further experiments. > > What changes would this entail? If you're already running Emacs through a > C-to-C++ converter, why can't the converter arrange for the changes itself? You're right, I should be clearer on this point: I want to help out others who decide not to use my converter, not myself. One thing that current stable versions of g++ are missing is structured initializers, and I decided to convert the few instances we have of those by hand rather than write code to do it. I think, but I'm not sure, that the current development version of g++ will correctly deal with those, though. Another thing is nested structs/enums/unions. I think those are bad style in addition to presenting a portability concern, even though they're easy to catch for the converter. The most vexing issue for me right now is that I haven't figured out how to get gnulib working with g++ without modifying files after every sh autogen.sh, though. I admit I don't understand the gnulib build process at all, so any hints would be appreciated. The other issues are minor (a union and a typedef sharing a name, C++ keywords, enums treated as ints), but overall it seems a potential deterrent to people who want to just try linking a C++ library to Emacs as an experiment, without using my converter. >> - dumping (I'm currently using CANNOT_DUMP=yes. Is that supposed to >> work? Because it doesn't without a few changes to the initial Lisp >> files.) > It is supposed to work. Admittedly it's not tested much. We really need to > move away from the current dumping model anyway, so CANNOT_DUMP mode will > grow in importance (in some sense). I'll open a bug for the CANNOT_DUMP issue. While I've got a fairly good overview regarding the C code, now, I don't understand the Lisp bootstrapping process, which appears to be the issue... What do you think about the future of pure space? That also seems to me to be an optimization that might no longer be worth it, and perhaps to add even more complexity to the code than dumping does. >> [1] - there's one place that uses "false" for "NULL" > > Please let us know where, and we'll fix it. Patch attached. --94eb2c0df912f8e72a055ebcf93d Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Use-NULL-for-NULL-rather-than-false.patch" Content-Disposition: attachment; filename="0001-Use-NULL-for-NULL-rather-than-false.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jae3ef4m0 RnJvbSBlYWM1Zjc4MTE3YjA3Yzc2ZWI3MjVhNDY1M2I1ZDhmNzAzODJjMTY1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBGcmks IDI0IE5vdiAyMDE3IDA4OjMzOjIyICswMDAwClN1YmplY3Q6IFtQQVRDSF0gVXNlIE5VTEwgZm9y IE5VTEwgcmF0aGVyIHRoYW4gZmFsc2UuCgotLS0KIHNyYy94ZGlzcC5jIHwgMiArLQogMSBmaWxl IGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEvc3Jj L3hkaXNwLmMgYi9zcmMveGRpc3AuYwppbmRleCAwMTZlNzA0NGNhZi4uN2U0N2MwNmMyZDcgMTAw NjQ0Ci0tLSBhL3NyYy94ZGlzcC5jCisrKyBiL3NyYy94ZGlzcC5jCkBAIC0zMTg3Miw3ICszMTg3 Miw3IEBAIHhfZHJhd19ib3R0b21fZGl2aWRlciAoc3RydWN0IHdpbmRvdyAqdykKICAgICAgIGlu dCB4MSA9IFdJTkRPV19SSUdIVF9FREdFX1ggKHcpOwogICAgICAgaW50IHkwID0gV0lORE9XX0JP VFRPTV9FREdFX1kgKHcpIC0gV0lORE9XX0JPVFRPTV9ESVZJREVSX1dJRFRIICh3KTsKICAgICAg IGludCB5MSA9IFdJTkRPV19CT1RUT01fRURHRV9ZICh3KTsKLSAgICAgIHN0cnVjdCB3aW5kb3cg KnAgPSAhTklMUCAody0+cGFyZW50KSA/IFhXSU5ET1cgKHctPnBhcmVudCkgOiBmYWxzZTsKKyAg ICAgIHN0cnVjdCB3aW5kb3cgKnAgPSAhTklMUCAody0+cGFyZW50KSA/IFhXSU5ET1cgKHctPnBh cmVudCkgOiBOVUxMOwogCiAgICAgICAvKiBJZiBXIGlzIHZlcnRpY2FsbHkgY29tYmluZWQgYW5k IGhhcyBhIHNpYmxpbmcgYmVsb3csIGRvbid0IGRyYXcKIAkgb3ZlciBhbnkgcmlnaHQgZGl2aWRl ci4gICovCi0tIAoyLjE1LjAucmMyCgo= --94eb2c0df912f8e72a055ebcf93d--