[Gc] Re: Understanding why GC'ing increases to the double in time?
Martin Egholm Nielsen
martin at egholm-nielsen.dk
Fri Feb 3 04:16:17 PST 2006
> You don't want to disable JAVA_FINALIZATION. That's likely to result in
> a crash and no meaningful information.
I wont then :-)
> Building the collector without SILENT defined will get you more
> statistics, which might be useful. In particular, it should be possible
> to verify that the amount of live heap memory is not drastically
I'll do that...
> Some sort of profile would also be useful. But I'm not sure my earlier
> suggestion was helpful. The collector is almost certainly spending it's
> time in mark_from. It would be mildly useful to confirm that. It would
> be more useful to confirm that this is not being called through the
> finalization code.
Ok... I haven't progressed in the profiling area just yet... Isn't it
possible to put in some debug info in the finalization code to clarify
whether this is the case?
> If you have a way of getting a reasonable number of randomly timed stack
> traces of the GC in action, that might tell us if something is grossly
Yes, that would certainly be the easy way - however I have no idea how -
> And it would be useful to verify that nothing is running in parallel
> with the collector, i.e. when GC_stopped_mark() is called. If so,
> that's also a correctness issue.
Arggh... I need that sofisticated profiler to do anything, it seems :-)
>>From: gc-bounces at napali.hpl.hp.com
>>[mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Martin
>>Sent: Thursday, February 02, 2006 3:28 AM
>>To: gc at napali.hpl.hp.com
>>Subject: [Gc] Re: Understanding why GC'ing increases to the
>>double in time?
>>>>The first (very) expensive collection overflows and then grows the
>>>>mark stack. That is expected to be expensive, but
>>>>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
>>>>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
>>Collection 3 finished ---> heapsize = 13996032 bytes
>>World-stopped marking took 190 msecs Complete collection took
>>(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 +
>>Collection 4 finished ---> heapsize = 13996032 bytes
>>World-stopped marking took 340 msecs Complete collection took
>>--- 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
>>making things grow.
>>So where to go from now?
>>What happens if I disable JAVA_FINALIZATION?
>>Gc mailing list
>>Gc at linux.hpl.hp.com
More information about the Gc