[gclist] Two conservative collectors
Thu, 18 Nov 1999 13:53:30 -0800
There are a bunch of problems with using debug information to determine
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.
From: Charles Fiterman [mailto:email@example.com]
Sent: Thursday, November 18, 1999 1:29 PM
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
>> 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.
>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.