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

[Jeff Sturm <jsturm at sigma6 dot com>]

Anthony Green wrote:
> 
> Jeff wrote:
> > Yes.  That's what I'm finding out too.  My code is greatly affected by
> > the frequency of allocation, not the overall size.
> 
> Can you build a statically linked version of your app?  One bad thing
> right now is that there are a lot of calls between libgcj.so and
> libgcjgc.so during gc.  Calls across shared library boundaries are
> slow.

The static binary runs about 30% faster, even at the start:

[jsturm@toronto test]$ ./unloader.static "select * from tblAECCatalog"
>/dev/null
select * from tblAECCatalog
1000 rows unloaded in 2.366 seconds (422.65427 rows/sec)
2000 rows unloaded in 4.812 seconds (415.6276 rows/sec)
3000 rows unloaded in 7.153 seconds (419.40445 rows/sec)
4000 rows unloaded in 9.608 seconds (416.31973 rows/sec)
5000 rows unloaded in 11.982 seconds (417.2926 rows/sec)

It's running with a 64MB heap, so I'd expect to see a "bump" every 10
seconds or so when garbage collection takes place.  I'm not seeing that
at all.  I suspect the real GC cost here is object allocation, not
collection.

When I get back into town next week I'll try some more experiments, like
building a libgcj without GC and letting the app run until it exhausts
memory.


-- 
Jeff Sturm
jsturm@sigma6.com