GC statistics (was Re: big project ported)

[Jeff Sturm]

Bryce McKinlay wrote:
> Hmm, it works okay for me - did you rebuild all of libgcj against the modified gc? I
> had this problem until I did a full "make clean && make". I am using GC 5.0_alpha1
> however.

OK.  I hadn't done that.

> After a few very un-scientific tests I am inclined to agree with your conclusion
> that gc is the major source of performance problems in libgcj. Boehm is fairly
> competitive (ie just slightly slower) in tests which allocate small numbers of large
> objects (eg 20,000 byte arrays of 100 bytes each), but poor in tests which allocate
> large numbers of small objects (eg 2,000,000 "Bytes"). IBM takes around 2 secs on my
> P2-233 for each iteration of the 2,000,000 byte tests where as Boehm is taking 10
> secs +. Boehm is spending up to 900ms marking for each gc iteration, when IBM is
> spending maybe 30ms.

Yes.  That's what I'm finding out too.  My code is greatly affected by
the frequency of allocation, not the overall size.


> Also, with IBM the heap stabilizes at around 28MB for this test while in libgcj the
> heap keeps growing to 140MB+ if I dont call Runtime.gc()

Yow.  Did you mess with GC_free_space_divisor, or leave it at 4?


> After seeing this I decided to experiment with boehm's incremental mode (which
> requires MPROTECT_VDB, which breaks multithreaded read() calls in libgcj, but for
> testing purposes seems to work well enough). Incremental seems to have a detrimental
> effect on the small-number-of-large-object cases (~20% slowdown) but does improve
> the large-number-of-objects case somewhat: down to around 6-7secs. Still nowhere
> near IBM's times though.

MPROTECT_VDB is an ugly hack... in my opinion incremental mode needs
kernel support, like /proc on Solaris.  It's interesting though that it
improved your results.

-- 
Jeff Sturm
jsturm@sigma6.com