Initial Heap Size and other tweaks (gcj 3.2.3 on debian)

[Andrew Haley <aph at redhat dot com>]

karlm at MIT dot EDU writes:
 > I inherited an admittedly poor Java port of a Fortran simulation.
 > It allocates and de-allocates immutable complex number objects
 > with each operation performed on the values of a matrix of complex
 > numbers.
 > 
 > This is known to thrash the libgcj garbage collector.  I tried the
 > recomended method of reducing the frequency of garbage colelctions
 > by setting the environment variable GC_INITIAL_HEAP_SIZE to
 > 256000000.  This appears to not affect the initial heap size, unless
 > Linux only counts memory as used once it gets initially paged in
 > following a page fault.  In any case, even with "-O3 -fno-bounds-check
 > -fno-store-check -fomit-frame-pointer -static" the gcj-generated
 > native binary takes over 380 seconds to perform the main loop while
 > the IBM 1.4.0 JVM takes 25 seconds.

The IBM JIT has a number of Java specific optimizations.  In
particular, devirtualization allows many calls to the garbage
collector to be removed altogether.  

Also, the gcj inliner can only inline methods that are defined before
they are used, and it can only do so within a single source file.

Having said that, it is my view that this great disparity is a
pathological case.

 > The long-term solution is of course to use a mutable complex number
 > class (cleaner) or split the matrix into a matrix for the real part
 > and a matrix for the imaginary part (probably faster, but less clean).

It would be nice to use this code as a test case for some optimization
work.  I'd like to see it if that's possible.  Of course I'll keep it
confidential if you want.

Andrew.