[Gc] Re: Understanding why GC'ing increases to the double in time?
Martin Egholm Nielsen
martin at egholm-nielsen.dk
Thu Feb 2 03:28:25 PST 2006
>> The first (very) expensive collection overflows and then grows the mark
>> stack. That is expected to be expensive, but shouldn't affect later
>> collections. This should go away if you increase
>> INITIAL_MARK_STACK_SIZE (in mark.c). It would be interesting to see if
>> that changes later GC times as well. If so, I would suspect a GC bug.
>> If you can easily rebuild the collector, I think that would be a
>> worthwhile experiment. The fact that the mark stack overflow occurs
>> exactly at the transition is suspicious.
> That will be easily done - I'll try later today (or tomorrow)...
And today was the day. But nevertheless the result didn't change:
--- 8< 8< 8< ---
Initiating full world-stop collection 4 after 240752 allocd bytes
--> Marking for collection 4 after 240752 allocd bytes + 0 wasted bytes
Collection 3 finished ---> heapsize = 13996032 bytes
World-stopped marking took 190 msecs
Complete collection took 210 msecs
(MEN comment: Touch the "magic" part of the application)
Initiating full world-stop collection 5 after 2517136 allocd bytes
--> Marking for collection 5 after 2517136 allocd bytes + 39040 wasted bytes
Collection 4 finished ---> heapsize = 13996032 bytes
World-stopped marking took 340 msecs
Complete collection took 350 msecs
--- 8< 8< 8< ---
I increased the initial heap size to 14megs, in order to make sure no
further allocations were needed when "touching" the part of application
making things grow.
So where to go from now?
What happens if I disable JAVA_FINALIZATION?
More information about the Gc