This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Garbage collector stopping my world for half a second


Hi guys,

> Could you remind me what your platform is?
It's my embedded 133 Mhz PPC405EP - so it's nothing like the pc analogies you mention ;-(

> For a modern PC, with a heap size of 8MB, and assuming the root size is
> reasonable, 60 msecs should be on the high side. (The GC time should be
> roughly proportional to <live data size> + <root size>. On a GC_Bench
> variant, the marker seems to scan roughly 200-250MB/sec on a single 2
> GHz P4 Xeon. There is a bit of other overhead associated with
> collections, but that's the lion's share.)
> > Unless you're on a very slow processor, the 360msecs seems anomalous to
> me. It would be useful to understand what's going on during that time.
> Presumably paging is not an issue?
So, yes it's a slow processor, I guess... And there is no paging, no.

 > More generally, the GC provides some support for incremental collection,
 > but AFAIK that's not really supported by gcj, and hence may take some
 > effort to get to work for your application.
Bummer! :-)
But I stumbled across some "SMALL_CONFIG" parameter stuff googling old postings, and ofcourse the "divisor" variable, as well.
However, I never got a feeling of how this latter parameter would affect things...


With gcj our root set is way, way too big.  Fixing this is at the top
of my list of things to fix.
But, since I've seen gc-times of 60 msecs for a simple test-example, I guess the root-set scanning-time is below (~equal to) this time, and similar regardless the other application?! If this is the case, the remainder 300 msecs is <live data size>...

Best regards,
 Martin Egholm


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]