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: Sat, 25 Nov 2017 23:50:16 +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 1511653873 2879 195.159.176.226 (25 Nov 2017 23:51:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Nov 2017 23:51:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 26 00:51:08 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 1eIkDw-00007d-SP for ged-emacs-devel@m.gmane.org; Sun, 26 Nov 2017 00:51:05 +0100 Original-Received: from localhost ([::1]:54714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIkE2-0004hb-L6 for ged-emacs-devel@m.gmane.org; Sat, 25 Nov 2017 18:51:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIkDr-0004gb-Te for emacs-devel@gnu.org; Sat, 25 Nov 2017 18:51:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIkDq-0004ky-TZ for emacs-devel@gnu.org; Sat, 25 Nov 2017 18:50:59 -0500 Original-Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:43335) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIkDq-0004jh-MV for emacs-devel@gnu.org; Sat, 25 Nov 2017 18:50:58 -0500 Original-Received: by mail-wm0-x22c.google.com with SMTP id x63so27892445wmf.2 for ; Sat, 25 Nov 2017 15:50:58 -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=2CVRmGLKrqdjKPd16glgqVbQpbzQQ3ZSjeJmlQqulXg=; b=BJKR36MR8HvNv5nJv3mEHXKATasj5ec1glx3uMtdC3DuATTF625oRB5zWxfabwH0uE S4nedXd96zEVqHNlScdzck+xmAiBS6DU0eiVXK4hgjGw5qfJsbF56iXaUJwmRQxrLQO5 qTPXCC3gQdlYePJIY20d+M7Jn4XNnYNbuRy55IHIuH4RZUS9m5gYThx5zrBoUQGbhZrg pAD3gwPoPn1NDN0AyHv1EsQArWJBzLzT5NfDNdQXK8ebqvHLOa9HtjhB8i3F8lNuKct2 uzEGB9MKRAwhm3irimU3KQb0r+QArzAckTQ4cA7H4fAVkWVf4Dv75il8nWolpYsxZqPr 7PSQ== 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=2CVRmGLKrqdjKPd16glgqVbQpbzQQ3ZSjeJmlQqulXg=; b=TjUvibSDPGtoeDqNkN7qeeC65uuO+hsOP6ghkmg8/pn8f46ik7cEeHcEm1E5m73657 BWQp0MpkNFKCl8UPH8qYFhTvRC6SSrhsXg6LMKvQTGSjL2jULp0ao26y1sUWXZ4VUiXM rx5i7QdeHsXakaBgRtZy8GfiQBZ3VAMhD41tkvEXlmj6sJL6k/0uye9u8MwxeNR0Xxhb ngvHha96R6xfgGtbQFvBR2FO3ShQjYUvnQcAorz9z3OXtS9jKeTvS7NZDNvj56OzF1uf rluKsE2uAihZeE77y3aNi2XN9aym/3TJUNkFip3mKbNCN1TZ/a3KRqQoCRYeeSKcRq2H 2GDg== X-Gm-Message-State: AJaThX44z8HjSyebb6vZ/M/xH5qATxJCWzmvTePe/OZUf+4KVvKLijrn Mwzpj8GBYWS5SPU0u2lxrgUTlWJeyCJVGf8J/tM= X-Google-Smtp-Source: AGs4zMaG8FE6j3aY32VUVycbv1TF90KWKetKHSw1RGM4lRDLBJ+Fu87ofH4Ka1E9YiquSjEp+1uxIyx2Tz32DtWmHD8= X-Received: by 10.80.134.108 with SMTP id 41mr46400019edt.69.1511653857458; Sat, 25 Nov 2017 15:50:57 -0800 (PST) Original-Received: by 10.80.150.6 with HTTP; Sat, 25 Nov 2017 15:50:16 -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::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:220455 Archived-At: On Sat, Nov 25, 2017 at 4:15 AM, Stefan Monnier wrote: >> 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. Yes, that is, I think, what I'm doing. > 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. Hmm. Is that for every build, or as a debugging option? Doing it for every build is hard, doing it as a debug option should be possible: after all, there'd be no more Lisp_Objects, just stack values, heap values, and return values, which could use __attribute__((constructor)) to check they are indeed on the heap, stack, or that their __builtin_frame_address changes. (I'm also treating pointers and arrays specially, but that's mere optimization.) > 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. You mean GCPRO? I'm not sure what you mean by "not precise enough"; I briefly tried using the GCPRO information to keep track of stack Lisp_Objects, but was defeated because some places didn't GCPRO variables that they knew to be protected by upstream callers, as well as the bugs. >> 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). I guess I'm an exceptional user, then, because I complain about it a lot. It's very much in embarrassing-pause territory here. > Also I think a non-moving GC will be a lot easier to accommodate. I suspect that I don't fully understand the benefits of a moving GC, because memory fragmentation alone simply has never been a problem for me. I've compromised by, as I said, combining the disadvantages of both approaches (though "disadvantages" can be read as "debugging opportunities"): Lisp_Objects are JS::Values whose JS_GetPrivate pointers are constant, even though the JS::Value isn't. So that's essentially a non-moving GC with extra error checking (because even Qnil can move (from one non-zero representation to another, too), and has, which was a little confusing to debug). > 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. Right now, it doesn't, because the C pointer is constant. It should be easy enough to convert, say, buffers and real vectors, because they have accessor methods/macros. Frames would be a lot harder (but then there are few enough of those that we can just accept they don't move). > Does your GC also trace through char* pointers into buffer text? No.