Re: gcj: mem leaks & speed.

[Andrew Haley <aph at redhat dot com>]

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.
 > It may well be that some JVMs recognize that the allocation is dead
 > and remove it (probably not very useful in practice) or recognize
 > that l doesn't escape the loop body, and hence the Leak object can
 > be stack allocated (may be useful in practice). 

A compiler can trivially determine that the allocation is dead and
that the constructor does nothing.  For that reason, this code isn't
much use as a comparison: most Java code uses objects in between
creation and destruction.

I'm eager to add Java-specific optimizations to gcj, but I'm not
convinced that this one would be a big bonus.  However, when combined
with escape analysis and stack allocation of short-lived objects it
could well be useful.

 > AFAIK, gcj currently does neither.

That's right.

Andrew.