Re: Conservative GC isn't safe

[Paul Eggert]

On 11/28/2016 01:36 AM, Ken Raeburn wrote:
> here we pass Fvector a pointer to somewhere within the “contents” array of the 
> vector passed as argument “string”

Sure, but in practice there are always other copies of 'string' floating 
around. Look at the call to Fsubstring in bytecode.c, for example:

  TOP = Fsubstring (TOP, v1, v2);

There's another copy of 'string' in the stack. Even if that code were 
changed to this:

  Lisp_Object v = POP; PUSH (Fsubstring (v, v1, v2));

Because the garbage collector doesn't know where the stack top is and so 
scans the entire stack, the GC would still mark the string.

In practice, Emacs C code doesn't create objects that no Elisp code 
cares about, and then mess with those objects in a way that can cause GC 
and that does not need the object base address. Partly this is due to 
the longstanding tradition where such objects needed to be GCPRO'd 
anyway. Partly it's because it's the Emacs C code is designed to be 
subsidiary to the Lisp code, and it's unusual to create and mess with 
objects not intended to be exported to Lisp.

If Emacs code starts doing what you're worried about, then we'll have to 
modify the GC marker to chase all pointers into objects, not merely base 
pointers. But I don't see this being a problem in the current code.