Improved Garbage Collection performance

John Neil jneil@atrove.com
Thu Dec 4 06:09:00 GMT 2003



>> Following a post from Jeff Sturm, I tried two relatively simple
>> modifications to gcj and boehm garbage collection and was able to gain 
>> a
>> 200-300% improvement on a full garbage collection (from ~150ms to 
>> ~50ms).
>
>Wow - this suggests that this optimization will go a long way towards 
>closing the GC-performance gap we seem to have compared to recent 
>hotspot VMs.
>
>Incidentally, I recently stumbled across this "real world", 
>allocation-intensive app which performs poorly with GCJ relative to JRE 
>1.4.2:

I haven't sent in these modifications, as they are for a proprietary OS and
I'm still waiting for my paper work.  Unfortunately I can't try this
application (easily) as the modifications were made for a specific embedded
system which does not have a file system.  The embedded environment provides
easier control over memory layouts and the likes, however in theory I see no
reason why this could not be applied to other systems like unix.  

However I would like to try this if somebody is willing to assist with some
of the memory layout/linker stuff.  I use a cygwin under XP.

The basic steps are as follows;

Modify the gcj (class.c) to place all static members which are classes into
a separate section, I called mu GCJCLASS.  Modify some of the native files
to place static/global variables into this section also.  Them modify the
boehm data segement registration to only scan this new section.  Naturally
this new section has to be added to the linker file.  I'm not sure the
impact on this on dynamically loaded libraries, I only statically link.

Add an additional function to be invoked during the gc mark phase (I called
it from (register_thread_structures) which scans the JCR_LIST looking for
initialised class (state > precompiled) and then register the roots from
these classes.  The registrartion function is basically the same as the
Jv_MarkObj function.

I was also able to further reduce the scan of the stacks as I know the exact
range of valid stack data, which also enabled me to remove the "clear stack"
function called on every GC_malloc.    

Cheers
John






More information about the Java mailing list