Re: Conservative GC isn't safe

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Mon, 28 Nov 2016 10:03:49 -0800
> 
> On 11/28/2016 10:00 AM, Eli Zaretskii wrote:
> >> From: Daniel Colascione <address@hidden>
> >> Date: Mon, 28 Nov 2016 09:51:37 -0800
> >>
> >> struct foo* f = something();
> >> int* x = f->&field;
> >> something_else(); // invalidate global memory
> >> *x = 5; // f is dead here, but still in scope
> >>
> >> Even if you don't write this kind of code, the compiler is allowed to
> >> generate it.
> >
> > But there's no such code in Emacs, and will never be.
> 
> I think you have too little faith in the ingenuity of compiler writers. 
> Why can't the compiler generate this sort of code in cases we don't 
> anticipate?

Because no matter how ingenious the compiler writers are, they cannot
produce code that will trigger GC where we didn't write such code to
begin with.  As long as there's no GC, the above is harmless.

> > Lisp objects we
> > create are either temporaries that can be GC'ed, or values that cannot
> > be GC'ed, in which case they are passed to some other code, either a
> > callee or returned as a value.  The only ones that can be dead as
> > above are the first variety, about which we don't care.
> 
> When this assumption stops holding, it's going to be very difficult to 
> debug the resulting occasional crashes. Wouldn't it be easier to use the 
> information *already in the memory tree* to make GC more conservative 
> and understand interior pointers?

I don't see why such assumptions should stop holding: we write code as
part of the Lisp interpreter, not as just any C program.  So creating
Lisp objects just to fiddle with their C-side internals will never
make sense, and code like that will always be rejected or rewritten.