RE: GC_enable_incremental()

["Boehm, Hans" <hans dot boehm at hp dot com>]

This is live data size or heap size?

The pause time is expected to be very roughly proportional to
static data size plus live data size.  The heap size should
matter little.  And the static data size is probably fairly
fixed, since a lot comes from libgcj itself.

There in fact does appear to be some part of the GC pause
that I can't completely account for, and haven't had a chance
to track down.

It might be worth looking at strace output
to see what the timing is for the signals used to stop the world.
In theory, the world stop time should be proportional to the
number of threads.  This if that's the culprit, then adding more
threads should make it appreciably worse.  My guess would have been
that on Linux it would take a lot of signals and context switches
to consume 57msecs.

Hans

> -----Original Message-----
> From: DHollenbeck [mailto:dick@softplc.com]
> Sent: Thursday, September 09, 2004 9:48 AM
> To: Boehm, Hans
> Cc: java@gcc.gnu.org
> Subject: Re: GC_enable_incremental()
> 
> 
> :
> 
> >3) I'm not sure it would help that much, since most of the GC time
> >in your context (tiny heap, I presume?) is probably spent tracing the
> >huge root set, and that will still happen with the world stopped.
> >There are plans to fix this, but it hasn't happened.
> >  
> >
> 
> I think most of the 57 msecs might be coming from the 
> mechanism used to 
> "stop the world", not the scanning of the root set.  Is this possible?
> 
> I get the same results with a 4 megabyte heap as with a 32 mb 
> heap, both 
> lead to intermittent 57 msec delays.
> 
> Dick
>