Re: Conservative GC isn't safe

[Ken Raeburn]

On Nov 28, 2016, at 14:33, Eli Zaretskii <address@hidden> wrote:
> 
>> From: Ken Raeburn <address@hidden>
>> Date: Mon, 28 Nov 2016 14:09:44 -0500
>> Cc: Stefan Monnier <address@hidden>,
>> address@hidden,
>> address@hidden
>> 
>>>> But after computing "aref_addr (string, ifrom)", it may very well be
>>>> that `string` is dead and the compiler may then decide not to write
>>>> it into the stack.
>>> 
>>> It will still be there in the caller.
>> 
>> Not if Fsubstring (or whatever function) is applied directly to the return 
>> value from some other call.
> 
> No, it still will be there.

Not anywhere saved by this part of the call chain.

> You need to keep in mind how these variables get to Lisp, and for what
> purposes.  Our code is written for certain purposes, and that mandates
> how data flows in the code.  If you go high enough up the stack, you
> will find every Lisp object value that matters at some level.

I’m talking mainly about calls between C functions in Emacs.  Some original 
data may come from Lisp code, way up the stack, but if some C routine applies 
Fdowncase() or Fmapcar() or Fconcat() to the Lisp-supplied values, and does 
further manipulation on them, then we’re dealing with objects generated in the 
C code and not referenced by the Lisp stack.

> 
>> As Björn described, the caller may not keep it around at all, just shift it 
>> from register to register, and the callee can scribble over those registers.
> 
> The number of registers is finite, even in the x86_64 architectures.
> The compiler cannot keep storing values in registers, because it needs
> to leave enough of them available for the next level of function
> invocation, about which it knows nothing before that function is
> called.  Go deep enough, and values will be pushed on the stack
> because the compiler needs to free a register.

Or they get discarded, when the compiler sees that they’re not needed any more. 
 Not when they go out of scope, but when they’re no longer actually used in the 
function.

>> Even if there’s an automatic variable assigned the value, if it’s not used 
>> later, the compiler may optimize it away; I’ve lost track of how many times 
>> GDB has indicated to me that it recognizes a variable name but at the 
>> current point in the code it’s been optimized out so GDB can’t show it to me.
> 
> The fact that GDB cannot tell you the value, and instead throws the
> "optimized out" thing at you, is just a sign that GCC didn't leave
> behind enough information for GDB to get its act together, and/or that
> GDB has bugs, and/or that DWARF is not expressive enough to cover some
> ingenious optimization technique.  It doesn't necessarily tell
> anything about where the value really is.  If anything, it means the
> value is not in a register, i.e. likely on the stack (where else?).

Bugs in one or more of the tools are certainly possibilities, but there really 
are cases where the value just doesn’t exist in any particular location, memory 
or register, because it’s not needed and the registers can be reused for 
something else.