[Gc] Re: Understanding why GC'ing increases to the double in time?

Martin Egholm Nielsen martin at egholm-nielsen.dk
Tue Feb 14 00:06:37 PST 2006

>>>An alternative is to just start over and drop the previous marking work
>>>when the client code needs cycles.  That's also already supported, but
>>>only works if the client resularly has enough idle time to allow the GC
>>>to complete.
>>Now, that sounds like an idea - but how do you interrupt when it's
>>going, and the (Java/application-) world is stopped?
>>This is really beginning to sound interesting to me, because my
>>interruptions are caused by external "interrupts"...

> At the GC level, you call GC_try_to_collect with a callback function,
> which is invoked periodically (probably order of every few msecs under
> normal circumstances) to see whether the collection should be aborted.
> Exporting this cleanly to the Java level is probably nontrivial,
> especially since the callback is rather restricted in what it can do.
> (This should be better documented.)
Well, I'm not in position to guess what those restrictions would be if 
the callback should go all the way back to Java (no allocations, and no 
new pointer references). But adding a callback to a pure C function 
would be ok - at least for me - e.g. to peek on signals on some hardware...
But still one would have to make GCJ not call "GC_gcollect" (that 
enforces "GC_never_stop_func" as stop-function), but instead some 
user-defined function. But this would require some clever work from the 
GCJ maesters if to be done in clean manner.

I guess your "every few msecs" is based on running on a non-embedded 
target? It wouldn't help me much if the period between two succeeding 
invocations on my slow target is "too large" :-)
I could ofcourse try measuring this - by hacking some time-measurement 
in the "never_stop_func"...

// Martin - closing in on the original proposal to find out what 
actually causes the doubling - it must be doubling of live data...

More information about the Gc mailing list