status of gcj's boehm collector?

[Boehm, Hans]

> -----Original Message-----
> From: Adam Megacz [mailto:gcj@lists.megacz.com]
> "Boehm, Hans" <hans_boehm@hp.com> writes:
> > ...System.gc()...
> > > In that case, how would a latency-sensitive application 
> signal the GC
> > > that it is now "okay" to stop-the-world for a long time 
> (ie perform a
> > > full heap scan)?
> 
> > I looked it up in response to your message.  Sun's 
> documentation states:
> > "When control returns from the method call, the Java 
> Virtual Machine has
> > made a best effort to reclaim space from all discarded 
> objects."  The one
> > line summary states "Runs the garbage collector".  Thus 
> just having the VM
> > ignore it seems a bit dubious; calling it as a hint that 
> this might be a
> > good time to run the collector is even more dubious; you 
> really need to know
> > that there has been a significant amount of allocation 
> since the last
> > collection, since it's likely the VM will unconditionally 
> go ahead and
> > collect.  And I think there's usually no good way to know that.
> 
> If you feel that is an important concern, some sort of
> System.getNumAllocationsSinceLastFullHeapScan() could be added.
I think most applications shouldn't bother with System.gc(); the potential
gain isn't worth the cost.  It's hard to insert such calls unless you know
about all threads in the system, which makes it dubious anyway.

I'm not sure it would make sense to add a standard call to inquire about the
number of allocations.  Different systems keep different statistics, and
adding new ones may not be cheap.  (Our collector roughly keeps track of
bytes allocated, but not objects allocated.)  Adding a gcj-specific call to
retrieve that (somewhere in the gnu.gcj part of the library) would probably
be OK.  Otherwise it might make more sense to add a new call with the
semantics you suggested, i.e. "collect if it makes sense, i.e. if I'd need
to collect soon anyway".

Thinking about this some more, I think the current System.gc() call actually
makes a little bit of sense if you run out of some non-memory resource, and
want to run both the collector and finalizers.  But it's usually not used
that way.  And I think that usage didn't work correctly with at least some
of the earlier Sun VMs.
> 
> 
> > Another problem is that this sort of opportunistic garbage 
> collection should
> > really be abortable if you get an unexpected request for 
> more work during
> > the GC.
> 
> If the world is frozen, how would you know that you had recieved such
> a request?
> 
Good question.  At the Java level it's not clear what the interface would
be.  At the C level, the collector regularly makes a (very restricted)
callback to ask whether to abort.  The callback could, for example, amke a
select call to check for waiting input.
> 
> 
> > > I thought that was the whole point of System.gc() -- it might not
> > > actually cause a GC; it's just a hint to the GC that "now 
> is a safe
> > > time to pause the application for a while". Sorta like 
> Thread.yield().
> 
> > I think Thread.yield() can be used correctly.
> 
> Unfortunately in a multithreaded application, a non-latency-critical
> thread might call Thread.yield() while a latency-critical thread was
> in a "bad place" to be halted. The yield() would provoke a VM-wide
> stop-the-universe for a full heap scan, which is now a good thing.
I'm sorry.  I didn't mean to imply that thread.yield() should trigger a GC.
I probably shouldn't have said anything about it.

> I still think System.gc() has the right connotations, since it is not
> a thread-specific operation. Would you approve of using it if there
> was a way for the appliation to know how much allocation had taken
> place since the last full heap scan?
> 
> If not, what would you suggest instead of System.gc()?
> 
If we really need a hint that this might be a good time to GC, I think we
need to add a different call for that purpose.  It would probably have to be
gcj-specific to start with, though it might be a good thing to try and
standardize.  My reading of the spec is that System.gc() is intended to
unconditionally trigger a full GC, which is not what you want.  But it is
what gcj currently does.

Hans