[gclist] Separate data space for collector data.

[David Chase]

> 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 think this is correct, if you include the proviso that there is 
also unsafe code in the system.  For a safe language (Java, Sather, 
Eiffel, Modula-3, Scheme, Dylan, ML) the choice of a conservative 
collector is simply an engineering decision. However, having worked 
on the run-time for an "error-detector" for two famous unsafe languages, 
I agree that you cannot hide your internal data structures well enough. 

N.B. Keeping data separate means using (say) mmap to allocate
internal data structures.  Mmap'd memory is usually far from
memory that users are likely to tinker with.

> First I am talking about experience with a commercial
> product that must be industrial strength. If the
> user can corrupt collector data in ways that makes
> the collector crash at some later time the collector
> is nearly useless. The user has no way to track what
> is hapening to her and we have no practical way to
> help.

This has been my experience as well.  A derailed GC can do a lot 
of damage in a hurry.

> Real languages not only have garbage collection but
> like Java they are type safe and do not allow access
> to objects other than through their methods.

Indeed, but note again that conservative can be a handy implementation 
technique for such languages.

speaking for myself,

David Chase