[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Conservative GC isn't safe

From: Daniel Colascione
Subject: Re: Conservative GC isn't safe
Date: Mon, 28 Nov 2016 12:09:09 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 11/28/2016 12:03 PM, Eli Zaretskii wrote:
Cc: address@hidden, address@hidden
From: Daniel Colascione <address@hidden>
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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]