[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
> increasing.
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
> wrong.
Yes, that would certainly be the easy way - however I have no idea how - 
yet...

> 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 :-)

// Martin

>>-----Original Message-----
>>From: gc-bounces at napali.hpl.hp.com 
>>[mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Martin 
>>Egholm Nielsen
>>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?
>>
>>
>>Hi,
>>
>>
>>>>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?
>>
>>BR,
>>  Martin
>>
>>_______________________________________________
>>Gc mailing list
>>Gc at linux.hpl.hp.com 
>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
> 



More information about the Gc mailing list