GC statistics (was Re: big project ported)

Wed Oct 27 09:47:00 GMT 1999

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