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