Re: GC and static data (Was: Projects)

[Corey Minyard <minyard at acm dot org>]

Per Bothner <per@bothner.com> writes:

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

The person in question above is me.  The problem is that for an
incremental collector in most systems, the types of the stuff
statically allocated is not known.  Also, you can't really
write-protect static memory so you don't know if it has changed or not
Well, maybe you can, but it would be a big pain.  But maybe it's
doable.  I haven't thought about it.  But if you have an area of
memory that you don't know is changed, to complete a GC you have to
scan all of it then any new objects it digs up.

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

I'd agree with this.  There are so many compiler flags that getting a
compile right in some environments is tricky.

Corey