Re: GC statistics (was Re: big project ported)

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Jeff Sturm wrote:

> It may not be working correctly though... on the first collection it
> printed
>
>  Initiating full world-stop collection 2 after 16946220 allocd bytes
>  0 bytes in heap blacklisted for interior pointers
>  --> Marking for collection 2 after 16946220 allocd bytes + 14280 wasted
> bytes
>  Collection 1 reclaimed 0 bytes ---> heapsize = 67174400 bytes
>  World-stopped marking took 20 msecs
>  Bytes recovered before sweep - f.l. count = -103180
>  Immediately reclaimed 16848164 bytes in heap of size 67174400 bytes
>  12296 (atomic) + 32208 (composite) collectable bytes in use
>  Finalize + initiate sweep took 0 + 10 msecs
>
> and then immediately dumped core.  I guess we really need to upgrade
> boehm-gc...

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.

Unfortunately the times reported by the gc are cpu times, which are only accurate to
10ms on Linux. It should be fairly easy to change it to use gettimeofday() which
should give more accurate results. It would also be nice to be able to get a summary
of the time spent marking, sweeping, etc from both IBM and boehm and compare them.

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.

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

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.

regards

  [ bryce ]