gcj: mem leaks & speed.

Mon Feb 2 10:50:00 GMT 2004

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.