[gclist] Separate data space for collector data.

[Jim Larson]

In message <2.2.32.19960913090440.0031cb68@192.9.200.1> Charles Fiterman
vents:
>I am coming to the conclusion that a conservative
>collector must keep its data separate from user
>data even if this requires substantial overhead.

What do you mean by "keep its data separate", and how is it different
from what you're doing now?

>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 is for C, right?  Are you exporting an interface to the
collector's data structures, or is the problem that stray pointers from
user code randomly clobber things?

If it's the latter, there's not much you can do aside from putting the
collector in a separate address space, using shared memory to access
the heap and stack, and debugging controls to access the registers, if
the OS supports it.

You've mentioned before the difficulties of providing a collector as a
commercial product - dealing with "colloquial" C and all of its
monstrosities.  It's hard enough to write a good collector in a
cooperative environment!

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

Well, there will always be some need for a language that allows direct
access to pointers, if for no other reason, than to implement runtime
systems for higher-level languages.

Scheme48 handles this in a clever way - their virtual machine is
written in a disciplined subset of Scheme, called prescheme, with
special primitives for manipulating pointers.  A special-purpose
compiler translates prescheme to C.  In theory, a native-code compiler
could generate machine code from prescheme, avoiding C entirely.

Jim Larson
james.s.larson@jpl.nasa.gov