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

["Boehm, Hans" <hans_boehm at hp dot com>]

> -----Original Message-----
> From: Andrew Haley [mailto:aph at redhat dot com]
>
> 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.
So do we.  THREAD_LOCAL_ALLOC is usually defined, at least on X86.  That causes boehm.cc to do the right thing and define GC_MALLOC to invoke GC_local_malloc, etc.  If we're regularly acquiring a lock for small object allocations, that's a bug.

We can also do parallel collections with --enable-parallel-mark.  I'm not sure whether the IBM VM can on Linux/X86. (I know that some IBM JVMs also do this.)  For gcj, it's not enabled by default, since it slows down the uniprocessor case slightly.
> 
> However, I'm pretty sure that it's the aggressive elimination of
> dynamic memory allocation that makes the difference in this case.
> 
I would think that's most of it.  I'm sure we also still have a longer allocation path.  And the IBM JDK may generate better code for floating point operations.  (But based on the slowdown from Fortran, that's probably in the noise here.)

Hans