This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Controlling the garbage collector (GC) at RT?
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