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

Boehm, Hans hans_boehm@hp.com
Tue Apr 29 17:46:00 GMT 2003


> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.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



More information about the Java mailing list