[gclist] Two conservative collectors

Charles Fiterman cef@geodesic.com
Fri, 19 Nov 1999 07:18:50 -0600


At 01:53 PM 11/18/99 -0800, you wrote:
>There are a bunch of problems with using debug information to determine
>stack layout:

There are always problems, we do the best we can.
>
>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.

In this construct the language doesn't even have to do the +. Suppose it
does and the pointer is on the stack and we have to report on it for
some reason. We don't know the pointer's type but we can find the target
and report that and if it has a vtbl report that.

>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.

So do I. Given optomized code your reporting becomes a lot worse.
>
>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.

Its not good enough for a GC but C++ users use our GC primarily as a
debugging tool. We have multiple libraries some of which use debug info and
some don't.

>
>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. 
>
>-----Original Message-----
>From: Charles Fiterman [mailto:cef@geodesic.com]
>Sent: Thursday, November 18, 1999 1:29 PM
>To: gclist@iecc.com
>Subject: RE: [gclist] Two conservative collectors
>
>
>At 01:24 PM 11/18/99 -0800, you wrote:
>>[Charles Fiterman wrote:]
>>> Our inhouse use of debug info is approaching the point where a precise
>>scan
>>> of the stack would make sense.
>>That's actually more ambitious than what I was talking about.  The only way
>>you could possibly do this with our collector is by providing your own
>>traversal procedure.  Where you get the layout info from is your problem.
>I
>>would be surprised if you could get reliable stack layout information,
>>especially about temporary values and at high optimization levels, from
>>debug information generated by existing compilers.
>
>Yes from debug info generated by existing compilers. Where else. Debuggers
>work. They tell you what is in variables and track pointers. You can only
>do a half way job if you aren't committed to reading and using debug
>information from existing compilers.
>
>
>