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
> Martin Egholm Nielsen
> 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.

(Currently GC_free_space_divisor actually controls the fraction of
the heap that must be allocated between GC's, which is not quite
heap occupancy.  In GC7.0alpha1, it actually controlls the amount
of allocation between GCs as a fraction of live data.  That's still
not really occupancy, but I think it behaves much better than the
current scheme, and probably better than if we really measured
heap occupancy.  In particular, it remains stable even if fragmentation
becomes unexpectedly high.  Unfortunately GC6.x normally has no idea
how much live data there is in the heap.)
> 
> > The collector tries to take such an explicit setting as a 
> strong hint
> > that it should actually be using that much of the heap before 
> > collecting.
> Sure, but I'm trying to avoid GC while the application is in a
> "critical" state. Doing as you suggest, wouldn't that just make things
> worse in case it starts collecting when it reaches the roof?
> Then there's a lot to collect...
A GC normally does something like

1) Acquire allocation lock.
2) Clear mark bits.
3) Stop the world.
4) Mark all directly reachable objects
5) Start the world.
6) Do finalization stuff, including marking from finalizable objects.
7) For each block in the heap, reclaim it if it's entirely empty.
	Otherwise enqueue for later sweeping.
8) Release allocation lock.

Note that in Java you probably can't do much while the allocation lock
is held.

(Sweeping is done occasionally during allocation.  Those pauses are
very brief (small numbers of microseconds?), and usually affect
only one thread.  I don't think you would ever notice them.)

Step 4 above dominates. Its running time depends only on live data
size, not heap size.  Steps 2 and 7 actually do look at the header
for each block in the heap, and hence take time proportional to the
heap size.  But since they don't actually look at the data blocks,
the absolute times are relatively small, perhaps 10-15% of the total.

Thus the GC time actually doesn't vary a lot with the amount of memory
reclaimed.  Basically, if you collect less frequently, you spend
correspondingly less time collecting.   The pause times are basically
the same.
> 
> Am I the only one that think a GCJ interface for controlling the GC
> would be neat?
I certainly wouldn't object.

You do have to be a little careful with repeatedly turning on and off
the GC.  The problem is that if you run out of memory with the GC off,
the heap will grow.  If you have a long running application, which
turns the GC off at random intervals, the heap is likely to grow
without bounds, though slowly.

A better strategy may be to preemptively collect before a "critical"
state.  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.
As it stands, you can do the equivalent with gcj-specific C calls.)

Hans

> 
> // Martin
> 
> >>-----Original Message-----
> >>From: java-owner@gcc.gnu.org 
> >>[mailto:java-owner@gcc.gnu.org]On Behalf Of
> >>Bryce McKinlay
> >>Sent: Wednesday, February 02, 2005 12:07 PM
> >>To: Martin Egholm Nielsen
> >>Cc: java@gcc.gnu.org
> >>Subject: Re: Controlling the garbage collector (GC) at RT?
> >>
> >>
> >>Martin Egholm Nielsen wrote:
> >>
> >>
> >>>Does GCJ somehow support controlling the GC at runtime?
> >>>That is, e.g. configure it for different behaviour:
> >>>
> >>>1) Run as you usually do
> >>>2) Please do not not run unless it is really needed
> >>>3) Don't run at all (let application die if it must)
> >>>
> >>>Point 2 is actually what I'm after, but I'm reconsidering (as I'm 
> >>>writing) if it actually makes any sense.
> >>
> >>
> >>The Boehm GC has the functions GC_enable() and GC_disable() 
> >>which should 
> >>do basically what you want. We don't have an interface to 
> call these 
> >>directly from Java, however, you could perhaps add your own 
> interface 
> >>and call the GC functions directly via CNI.
> >>
> >>See boehm-gc/include.gc.h
> >>
> >>Bryce
> >>
> >>
> > 
> > 
> 
> 
>