[gclist] Separate data space for collector data.

[Giuliano Carlini]

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

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

A less than perfect system is still useful.

While segregating is a good idea, I think you're being
a bit too bleak here. Smashing random memory anyplace
will often result in mysterious and hard to debug errors.
If you demand that a GC must be impervious to these
errors, then you must demand the same of all other
subsystems: I/O, exception handling, multi-threading,
etc.

> The user has no way to track what
> is hapening to her and we have no practical way to
> help.

This does require help from the GC. But, only in the debug
version. The production version can run full speed.

Most data can be segregated cheaply. The only data I can think
of off the top of my head that can't be are "next" pointers in
free chains. For these, we need only segregate redundant data.
Then, between calls to the GC's functions, record which pages
have been dirtied. The start of every GC function calls a
function which checks to see if any of the next pointers on these
dirty pages have been smashed.

While not 100% precise, it will narrow down where the pointer smash
occurred.

Regards,

g