From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector
Date: Fri, 24 Nov 2017 23:15:05 -0500 [thread overview]
Message-ID: <jwvzi7b9fab.fsf-monnier+gmane.emacs.devel@gnu.org> (raw)
In-Reply-To: CAOqdjBfNVGXPKuhpB58FNVJPWNU9KjOJUcqL5PmRU3CVz8MgQA@mail.gmail.com
> 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
next prev parent reply other threads:[~2017-11-25 4:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 19:01 [EXPERIMENT] Emacs with the SpiderMonkey garbage collector Pip Cet
2017-11-24 8:07 ` Paul Eggert
2017-11-24 16:23 ` Pip Cet
2017-11-24 18:20 ` Paul Eggert
2017-11-24 23:27 ` Pip Cet
2017-11-25 0:21 ` Paul Eggert
2017-11-25 23:50 ` Pip Cet
2017-11-24 22:13 ` Stefan Monnier
2017-11-24 23:05 ` Pip Cet
2017-11-25 4:15 ` Stefan Monnier [this message]
2017-11-25 23:50 ` Pip Cet
2017-11-26 1:20 ` Stefan Monnier
2017-11-26 4:20 ` Paul Eggert
2017-11-26 5:11 ` Stefan Monnier
2017-11-26 10:27 ` martin rudalics
[not found] ` <jwva7z9rgqh.fsf-monnier+Inbox@gnu.org>
[not found] ` <9d7be625-85ae-54d5-3897-6f701c8ea124@cs.ucla.edu>
[not found] ` <jwvo9npprfw.fsf-monnier+emacs@gnu.org>
2017-12-01 1:03 ` Steve Fink
[not found] <CAOqdjBe98BpWE- Ey8fPY1DmfCiLYnB06d30Xqf_KMm_muvKbDg@mail.gmail.com>
2017-12-01 17:57 ` Steve Fink
2017-12-03 0:37 ` Pip Cet
2017-12-03 5:24 ` Steve Fink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvzi7b9fab.fsf-monnier+gmane.emacs.devel@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).