From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Pip Cet <pipcet@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector
Date: Sat, 25 Nov 2017 20:20:03 -0500 [thread overview]
Message-ID: <jwva7z9rgqh.fsf-monnier+Inbox@gnu.org> (raw)
In-Reply-To: <CAOqdjBdNCg0zD_20sUKCHDiD2ZN2N0bbGSDqWh2orgY12AVVXA@mail.gmail.com> (Pip Cet's message of "Sat, 25 Nov 2017 23:50:16 +0000")
>> 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?
The check doesn't have to be done for every build, but it needs to be
static (i.e. performed during something like compile-time, not
run-time).
> You mean GCPRO?
Yes.
> I'm not sure what you mean by "not precise enough";
I'm referring to the problem you saw:
... but was defeated because some places didn't GCPRO variables that
they knew to be protected by upstream callers...
> I guess I'm an exceptional user, then, because I complain about it a
> lot. It's very much in embarrassing-pause territory here.
Interesting. I wonder what part of your use patterns would cause that.
Do you remember of particular situations where this happens, or is it
just kind of all the time?
>> 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.
A moving GC is not necessarily better. It's a popular choice in
languages with high allocation rates, because allocation is extremely
efficient (just move the allocation pointer forward) and because
a stop© of the youngest generation can usually recover a lot of
garbage with fairly little effort (because often there are much fewer
live objects in the young region than dead ones, so copying the live
objects is cheaper than (mark&)sweeping the dead ones).
But it's not like it doesn't have downsides.
Stefan
next prev parent reply other threads:[~2017-11-26 1:20 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
2017-11-25 23:50 ` Pip Cet
2017-11-26 1:20 ` Stefan Monnier [this message]
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=jwva7z9rgqh.fsf-monnier+Inbox@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=pipcet@gmail.com \
/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).