[gclist] Separate data space for collector data.

[Hans Boehm]

"I am coming to the conclusion that a conservative
collector must keep its data separate from user
data even if this requires substantial overhead."

I'm not sure that this is the right direction.  The most common
problem I've seen is user code overwriting collector free list links.
I suspect that's the only part of the data structure that's difficult
to move.  Most of the time that results in a segmentation fault in a specific
place in the allocator.  That could be documented (and sort of is documented
in my collector).  If you put a known bit pattern before the link and
checked that before dereferencing, you could probably produce reasonable
diagnostics in 95% of the cases, at moderate cost.

The real solution is likely to be a compiler or object-code postprocessor
that inserts checking codeduring debugging.  My PLDI '96 paper described a
solution that would addresses this problem, among others.  So does Purify,
presumably.

(I'm assuming the source language is C or C++.  As Charles points out, this
is otherwise not likely to be an issue.)

Hans

Hans-Juergen Boehm
boehm@mti.sgi.com