Controlling the garbage collector (GC) at RT?

[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.
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 might end up in this situation not doing so...
>>>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.
Exactly.

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

> 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.
Will the memory claimed during an off-period never be reclaimed, even 
when unused?

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

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

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