Re: Conservative GC isn't safe

[Daniel Colascione]

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
> 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.