gcj: mem leaks & speed.

Mon Feb 2 11:11:00 GMT 2004

Andrew Haley wrote:
>Hans Boehm writes:
> > [Comments added below.]
> > 
> > > Also, while trying to track down memory use, I wrote the following
> > > class:
> > >
> > > public class Leak {
> > > public static void main(String[] argv) {
> > > long start = System.currentTimeMillis();
> > > for (int i = 0;; i++) {
> > > Leak l = new Leak();
> > > if (i % 100000000 == 0) {
> > > long curr = System.currentTimeMillis();
> > > System.out.println(i / 100000000 + ": " + (curr - start));
> > > }
> > > }
> > > }
> > > }
> > >
> > > This runs 10x as slow in gcj as it does in java on windows (~6x on
> > > linux) If you remove the "Leak l = new Leak();" line, the speed
> > > becomes rather similar to java. Why is class creation so slow? (or is
> > > it GC cleanup that is slow?)
>> > The garbage collector used by gcj does not handle very short-lived
> > objects as efficiently as most JVMs, though it sometimes performs
> > better for applications that alternately allocate and drop very large
> > linked structures. This example exercises short-lived allocation to
> > the extreme.
>>That's interesting. Could you briefly tell use why the gc has this
>property, and if anything can or should be done about that?
>> > A factor of 10 is a larger difference than I would have expected.
>If I understand correctly, in Hotspot, unreferenced short-lived object are
never copied out of the "eden space", so basically in that example there is
no garbage to collect at all, even without advanced jit analysis. so it is
not surprising hotspot is very fast. (i.e. when eden fills up, eden is just
reset and new Leak object gets allocated from the beginning again. should
help with cache locality too)
Cedric