Re: GC and static data (Was: Projects)

[Per Bothner <per at bothner dot com>]

Anthony Green <green@cygnus.com> writes:

> This actually makes sense for our current GC scheme, but someone I
> know working on an incremental collector considers this a big lose.
> The incremental collector has to finish a full scan of the root set
> and then handle any newly created objects in one pass (with all the
> mutators blocked).  Putting a lot of data into static memory (root
> set) slows this down a lot, especially if the data is not changing (as
> would be the case in Class objects, for instance).

I don't understand this.  Maybe if I understood the algorithm in
question - but that's ok, I don't need to.  I just want to make sure
you understand that statically allocated objects do *not* need to be
in the root set, at least as the term "root set" is normally
understood.  Such objects be scanned like any other objects.  Anything
that is reachable from a statically allocated object, and that is
still live has to be reachable from something else that needs to be
scanned anyway.

We can think of pre-allocated objects as living is a separate segment
that is part of the gc's heap.  If the gc needs special book-keeping
data structure, they can be created for that segment just as for the
normal heap, either at compile-time or at startup-time.  The only
difference is that the gc never automatically allocates memory from
that heap, only "manually".

The potential lose that I can see is checking for pointer validity
in a conversative collector.  That test may be more complex if
it has to take into account pre-allocated objects.

> In this scenario, I believe dynamically allocating as much as possible
> would make sense.  Perhaps we should introduce a compiler flag to
> select?

Too many compiler flags ...  I certainly want to minimize adding new
user flags.  I don't so much mind adding new jc1 flags that are
automatically passed from gcj.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/