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

Boehm, Hans hans.boehm at hp.com
Thu Feb 2 16:36:53 PST 2006


You don't want to disable JAVA_FINALIZATION.  That's likely to result in
a crash and no meaningful information.

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.

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.

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.

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.

Hans



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