RE: GC and static data (Was: Projects)

["Boehm, Hans" <hans_boehm at hp dot com>]

I'll try to answer some of the questions w.r.t. the incremental GC support
in our collector.  I'm not sure what the differences are for what's being
proposed here.

What is actually preventing somone from turning on incremental GC in the
current collector?  It seems to me there are three likely issues:

1) The runtime might make some system calls that write to the heap without
invoking the wrapper calls.  This should be fixable with a small amount of
work, right?

2) Native code doesn't play by the rules.

3) Native code doesn't tolerate the SIGSEGV's used to implement the write
barrier.

I believe the write barrier logic in our collector could be made to handle
regions outside the heap fairly easily.  The /proc-based barrier for Solaris
already does so (and the thread stack marking code relies on it heavily,
though it has other problems).  The cost is that we would take more write
faults.  More importantly, the native code issues would get worse, since
system calls that write to statically allocated data would now need to be
protected, so that they don't encounter a write-fault.  This issue could be
avoided by putting better dirty bit support into the OS, but I'm not sure
that can be done in a way to keep Linus happy, for example.

Thus it seems to me that the main issue with incremental collection is
whether you are willing to tolerate some restrictions on native code.  (I
just successully ran unmodified Ghostscript with the incremental collector.
So the restrictions are not that strong, but they are there.  Introducing
write barriers for static data makes them worse.)

If you use a non-VM write barrier, native code becomes even more of an
issue, it seems to me.

Treating statically allocated objects as though they were part of the heap
is hard.  The problem is that they wouldn't obey the usual alignment rules
for heap objects, so that they couldn't be described by the usual collector
data structures.  This may be different for other collectors, but I suspect
it will still be an issue.  Treating them as roots is easy.  Ignoring them
isn't much harder.  If the object may become garbage, I'm not sure you want
to allocate it statically.

Hans

-----Original Message-----
From: Corey Minyard [mailto:minyard@acm.org]
Sent: Friday, April 28, 2000 6:33 AM
To: Per Bothner
Cc: java-discuss@sourceware.cygnus.com
Subject: Re: GC and static data (Was: Projects)


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