[gclist] What to say about GC.

[David Chase]

In this discussion of GC versus optimizer bugs, I find that my experience 
is that it is easier to deal with GC bugs than it is to deal with 
optimizer bugs.  Despite the scary black-box nature of the Boehm-Weiser 
GC (for most C++ programmers, at least), in any single-threaded system 
its behavior is relatively well-determined, and you can step through 
it.  I've debugged porting bugs (to the 68030-based Sun 3/80) and 
I've ported it to MT system (Olivetti PC running Mach) and I've dealt 
with user-induced bugs ("clever" Modula-3 user LOOPHOLEing pointers 
into integers, storing said integers into an array (the compiler 
knows the type, so the array is tagged as pointer-free)).  In all 
these cases it took less than a day to figure out what was going 
on, once I knew that there was a bug.  We had a big leak once, that 
someone else traced to overconservatism (back in the days before 
blacklisting), and this was easily fixed by reusing the retained 
data structure. 

In the case of compiler bugs, life can be much worse.  Memorable
ones include the miscompilation of a Sun cgsix device driver by
a compiler that didn't quite respect "volatile" like it should,
and the week I spent in two parallel debugger sessions attempting
to figure out where the wrongly generated code was in the 88 pages
of assembly language that was the result of "narrowing down" to
the error.

The Boehm-Weiser collector functions incredibly well if you consider
the adverse nature of the (non-) interfaces it must use to perform
such obvious operations as "find ALL the data" and "stop all the 
threads except for this one" and "tell me all the thread stacks".
In the cases where it fails the first step to take is to go looking
for whatever part of the root set it is failing to find.

speaking for myself,

David Chase