From: Daniel Colascione <dancol@dancol.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Conservative GC isn't safe
Date: Mon, 28 Nov 2016 12:09:09 -0800 [thread overview]
Message-ID: <508da2a6-15bc-ddf2-72b7-b1c35d9949c8@dancol.org> (raw)
In-Reply-To: <831sxvz81l.fsf@gnu.org>
On 11/28/2016 12:03 PM, Eli Zaretskii wrote:
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Mon, 28 Nov 2016 11:40:22 -0800
>>
>>> I already answered that up-thread: it will be dead code, and thus will
>>> likely do the wrong thing if it ever runs.
>>
>> We'll always have stray pointers to object interiors that will exercise
>> these code paths. I've broken enough of them recently enough to know.
>
> We are not talking about broken code. It's easy to get yourself hung
> in Emacs by writing bad code. Writing additions to GC to detect bad
> code is not a good use of CPU cycles and of our time.
What are you talking about? No matter how good the Emacs C code is, the
compiler is legally allowed to generate code that trips up the current
conservative GC. Code that looks perfectly safe may end up being
compiled into something that trips up the current GC scheme. Even if it
is possible to arrange C code such that, at runtime, we always keep GC
roots around, the rules must be very subtle.
We can make a simple, cheap modification to the GC to plug this hole
once and for all. Other systems that use conservative GC have made
similar modifications. I still don't understand why you're resisting
this change when I've outlined a clear way in which things might go wrong.
You're the one always talking about future-proofing the C core so that
it needs less expert maintenance. This is a change that will
future-proof the Emacs C core so that it needs less expert maintenance.
>>> I also suggested what to do instead: add assertions that express what
>>> we believe should never happen. Stefan says doing that is unlikely to
>>> be justified by the dangers, but if we think so, then we shouldn't be
>>> afraid of the problem in the first place. If we are, then adding
>>> assertions is the way to go.
>>
>> It's not possible to assert, statically or dynamically, that we don't
>> have this problem.
>
> If we cannot assert the invariants, either we don't really understand
> the problem, or the problem doesn't exist in the first place (or
> both).
It's possible, from a CS perspective, to do a reachability analysis on
the generated machine code and prove that all accessible objects have
live head pointers. I think. But adding an analysis like this to the
build process would be a research project in itself. It's easier to just
make the GC more conservative.
next prev parent reply other threads:[~2016-11-28 20:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-26 8:11 Conservative GC isn't safe Daniel Colascione
2016-11-26 8:30 ` Paul Eggert
2016-11-26 8:33 ` Daniel Colascione
2016-11-26 9:01 ` Eli Zaretskii
2016-11-26 9:04 ` Daniel Colascione
2016-11-26 9:24 ` Eli Zaretskii
2016-11-26 15:05 ` Stefan Monnier
2016-11-26 15:21 ` Camm Maguire
2016-11-28 17:51 ` Daniel Colascione
2016-11-28 18:00 ` Eli Zaretskii
2016-11-28 18:03 ` Daniel Colascione
2016-11-28 18:50 ` Eli Zaretskii
2016-11-28 18:03 ` Stefan Monnier
2016-11-28 19:18 ` Daniel Colascione
2016-11-28 19:33 ` Stefan Monnier
2016-11-28 19:37 ` Eli Zaretskii
2016-11-28 19:40 ` Daniel Colascione
2016-11-28 20:03 ` Eli Zaretskii
2016-11-28 20:09 ` Daniel Colascione [this message]
2016-11-28 19:26 ` Andreas Schwab
2016-11-28 19:34 ` Stefan Monnier
2016-11-26 15:03 ` Stefan Monnier
2016-11-26 15:12 ` Eli Zaretskii
2016-11-26 16:29 ` Stefan Monnier
2016-11-26 16:42 ` Eli Zaretskii
2016-11-26 18:43 ` Stefan Monnier
2016-11-27 6:17 ` Ken Raeburn
2016-11-27 15:39 ` Eli Zaretskii
2016-11-28 9:50 ` Ken Raeburn
2016-11-28 15:55 ` Eli Zaretskii
2016-11-27 16:15 ` Paul Eggert
2016-11-28 9:36 ` Ken Raeburn
2016-11-28 15:55 ` Eli Zaretskii
2016-11-28 16:15 ` Stefan Monnier
2016-11-28 17:37 ` Eli Zaretskii
2016-11-28 17:49 ` Stefan Monnier
2016-11-28 17:57 ` Eli Zaretskii
2016-11-28 18:05 ` Stefan Monnier
2016-11-28 19:09 ` Ken Raeburn
2016-11-28 19:33 ` Eli Zaretskii
2016-11-29 8:49 ` Ken Raeburn
2016-11-28 17:03 ` Björn Lindqvist
2016-11-28 16:13 ` Paul Eggert
2016-11-27 16:52 ` Stefan Monnier
2016-11-26 19:08 ` Pip Cet
2016-11-27 0:24 ` Paul Eggert
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=508da2a6-15bc-ddf2-72b7-b1c35d9949c8@dancol.org \
--to=dancol@dancol.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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).