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

[Andrew Haley <aph at redhat dot com>]

Boehm, Hans writes:

 > I think Andrew already pointed out the root of the problem here.
 > The IBM JVM is probably avoiding a lot of the allocation
 > altogether.  Based on some very old comparisons, my recollection is
 > that the IBM collector is in the same ballpark as the gcj one.
 > 
 > The fact that the IBM JVM is successful at this suggests that a lot
 > of the allocation is done to hold complex numbers that are
 > effectively expression temporaries, and are never being stored in a
 > matrix with substantial lifetime.  Does that sound right?  (If it
 > was really the IBM collector that was a lot faster, that would
 > suggest to me that (a) it's generational, which I didn't think it
 > was, and (b) generational collection is a big win here.
 > Observation (b) would also lead me to the same conclusion,
 > i.e. much of the allocation is for temporaries.)

AFAIK the IBM collector allocates small data from per-thread regions,
which is not exactly generational but does have the advantage of
removing the need to do any locking.

However, I'm pretty sure that it's the aggressive elimination of
dynamic memory allocation that makes the difference in this case.

Andrew.