RE: Controlling the garbage collector (GC) at RT?

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

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> 
> 
> >>And in relation to that thread, what is the effect of adjusting
> >>GC_free_space_divisor? (Maybe I should take that back in the 
> >>old thread)
> > GC_free_space_divisor basically sets the heap occupancy, i.e.
> > how full you are willing to have the heap become before the heap
> > is expanded.  It also trades off GC frequency against space usage.
> > The GC_..._HEAP_SIZE values effectively override it.  In a normal
> > workstation environment, with unknown heap requirements, it's
> > usually better to set GC_free_space_divisor.  In an embedded
> > environment, it may not be what you want.
> Well, now I'm slightly confused. Because as David wrote:
> 
> "If you have the divisor set too low in conjunction with a limited 
> maximum heap size you can run into a situation where there 
> are many of 
> these pools that have some free space in them, but there is no memory 
> left to expand the pool of a pool for a given size object."

I think there was a bug in this area, whose fix never made it into the
gcc tree.  (I just posted it to java-patches, along with some others.)
But this should be, and I believe is, very rare, at least if you
don't set GC_free_space_divisor below the default.  (That probably
doesn't help David, if his application runs into it.)  As I mentioned
parenthetically, the current heuristic, which depends on the ratio
of newly allocated memory to total heap size, can also be problematic on
rare occasions.  This isn't really fixable until GC version 7 is
merged in, since it requires some major changes to the collector.
But I've never personally seen that problem.
> Will the memory claimed during an off-period never be reclaimed, even 
> when unused?
It will be, but only for GC reuse.  In the default configuration, it would
not be returned to the OS.
> 
> > A better strategy may be to preemptively collect before a "critical"
> > state.  
> Technically, "before" can be interpreted as "after" a 
> "critical" state - 
> given that not much happens memorywise inbetween the critical states 
> (and not much does). Hence, we're back in the scenario I suggested :-)
> 
> I would rather not do it "just before" the critical state - that is, 
> it's not possible, because entering the critical state is 
> triggered from 
> the outside, hence I actually don't know when is "just 
> before". I just 
> suddenly know "now it's time" - and then no more time can be afforded 
> wasted.
The collector does provide for "abortable" collection.  You can start a
collection, passing a function that tells the collector if it should abort,
usually by throwing away partial GC results.  The general experience is
that this is rarely useful, but it might be in your case.

It also does not currently have a Java interface.  And if the gcj GC
ever changed, it might be harder to reimplement.
> 
>  > But you really only want to do this if a minimum amount
> > of memory has been allocated since the last GC.  (I think there
> > really should have been a System.maybeGc() with those semantics.
> Isn't that actually how the System.gc() should be interpreted?
Unfortunately, System.gc() has at least 2 possible legitimate
uses, and they require different semantics here.

In your case, the maybeGC interpretation makes sense.  If you are out of
something like file descriptors, and you want to run the gc and
finalizers, then you want the "run the GC now unconditionally"
semantics.  (The latter doesn't really appear to work anyway, since
the spec isn't clear enough about what System.runFinalization()
does, etc.  But in an ideal world ...)

Hans