RE: gc problem?

["Boehm, Hans" <hans_boehm at hp dot com>]

Aren't there also other issues with the debug information for the stack?  I
haven't looked at DWARF2.  But presumably it's meant to answer questions
such as "What's the value of X?", and on optimized code it seems that you
actually get answers to requests like "Give me your best guess for the value
of X?".  This is only loosely related to the questions the garbage collector
might ask: "Can the value in register Rn possibly be dereferenced at some
point in the future?"  The answer to the last question might be "yes" even
if Rn doesn't hold the value of any program variable.

I think there have been successful uses (e.g. by Paul Wilson's group) of
debug information to determine layout of heap objects.  But that's an easier
problem.  Debuggers ususally get that right, even for optimized code.

Hans

> From: Jeff Sturm [mailto:jsturm@one-point.com]
> 
> On Wed, 24 Oct 2001, Bryce McKinlay wrote:
> > >2) (Harder, may not ever happen.) Teach the compiler to 
> generate descriptors
> > >for the stack layout, and the collector to interpret them, 
> so that we can
> > >scan the stack (mostly) nonconservatively.
> > 
> > Can't GCC do this already (ie DWARF2)? If that is good 
> enough for the EH 
> > unwinder and GDB, wouldn't it have enough info for GC as well?
> 
> That's an interesting idea.  My impression is that it would be a
> significant undertaking since neither GCC unwind nor debug info are
> sufficient (the former lacks type info, the latter isn't mapped to the
> process image).  It would require augmenting the unwind info or
> introducing a completely new section.  (Mapping the debug sections
> probably isn't practical due to size.)
> 
> The real question is whether any potential gains are worth 
> the effort.  I
> seldom see any extraordinary heap growth due to blacklisting from
> interior pointers on real-world code, even on SPARC (which is 
> somewhat of
> a worst case given its sparse stack layout).
> 
> Jeff
>