[gclist] Two conservative collectors

[Michael Spertus]

At 06:05 AM 11/19/99 -0500, you wrote:


>Date: Thu, 18 Nov 1999 13:53:30 -0800
>From: "Boehm, Hans" <hboehm@exch.hpl.hp.com>
>Subject: RE: [gclist] Two conservative collectors
>
>There are a bunch of problems with using debug information to determine
>stack layout:
>
>1) If I'm inside the call to g in
>
>         f() + g(13)
>
>where f returns a pointer (and has been evaluated first) and g returns an
>integer, I know of no way to ask about the (temporary) pointer value
>returned by f.  Thus the debugger doesn't have to find it.  It has no
>associated name.  But the garbage collector does have to find it.  I doubt
>there's any way to get information about the location of f's return value
>out of most debugging symbol tables.
>
>2) I don't know about you, but I often get incorrect information about local
>variables from the debugger if the code has been optimized.  This is usually
>a documented feature.  If you do get accurate information, I suspect that
>your compiler inhibits some optimization for debuggable code.
>
>3) C unions (but we knew that).
>
>4) Buggy debug info.  My experience with debuggers is such that I tend not
>to trust debug information enough to make program correctness depend on it.
>Most debuggers I've known give the right answer about 98% of the time.
>(Actually, a few were more like 50%, but ...)  That's good enough for a
>debugger.  It's not good enough for a GC.
>
>I'm not arguing against using debug info for heap layout.  That's much
>easier to get right, and far more likely to be reliable.  Paul Wison's
>experience seems to be that it works.

Like you, I would be very surprised if debug info was good enough to 
provide any help to the collector in garbage collecting the stack. However, 
the original idea of this thread (I'm not sure if it has changed :) was on 
trying to report on excess retention not to automatically eliminate it. I 
would expect that debug info could be very useful on that score even if it 
is only "good enough for a debugger". Matt, how did you determine that the 
reports you were seeing came from holes in the stack and not temporaries as 
Hans suggests?