benchmark result

Boehm, Hans
Mon Dec 6 21:39:00 GMT 2004

The real cost here is in tracing these "immortal" objects.  If the
GC needs to look at them at all, there is probably not a lot to be

Turning on the generational GC might help, since it would reduce the
frequency at which the immortal objects are traced.
But I think it would take some effort to make that work well.
It's not currently supported with gcj.  (This is where Sun's
GC wins on many, but not all, workloads.  It's unlikely that we can
match it without moving objects.  But we should be able to get closer.)

Increasing the heap size (GC_INITIAL_HEAP_SIZE) should reduce the
time spent in GC_mark_from, at the expense of using more memory.
If you have a multiprocessor, turning on parallel marking might also
be a good idea.  (On a Pentium 4, the gcj version is a bit misconfigured,
and you won't get full benefit.  You really need to turn on USE_MARK_BYTES
(a macro in the source not accessible with configure options) as well.)

There are plans to do something about the amount of time spent in the
allocation routines themselves.  The GC7 marker also seems to be a bit,
but not hugely, faster.


> -----Original Message-----
> From: 
> []On Behalf Of
> Mathieu Lacage
> Sent: Monday, December 06, 2004 7:07 AM
> To: Andrew Haley
> Cc:
> Subject: Re: benchmark result
> On Mon, 2004-12-06 at 13:56 +0000, Andrew Haley wrote:
> > We could improve the performance of these collection classes with
> > little work.  What is required is someone to study the code, do some
> > profiling, and fix things.
> I will look into this when I find some time.
> >  > An interesting optimization which is clearly impossible with the
> >  > sun JDK would be to mark this huge growing data structure as
> >  > outside of the scope of the GC. I have no idea whether 
> or not this
> >  > is even remotely possible with gcj (hint: I am willing to follow
> >  > any advice which gives ideas on how to do this, even those
> >  > including hacking gcj itself).
> > 
> > Chapter 5 of the Real-Time Specification for Java describes 
> the class
> > ImmortalMemory, which has methods such as newArray(Class, 
> number) and
> > newInstance(Class).  We could implement that simply by switching the
> > memory allocator.  I don't know if the gc would continue to 
> function.
> > Hans?
> I looked at the spec and I think that it does not do exactly what I
> want. Objects allocated within this MemoryArea can contain 
> references to
> objects allocated on the normal Heap which means that the GC 
> still needs
> to scan them and the specification explicitely allows this to 
> happen and
> requests implementors to do something about it.
> In my case, I can manage to allocate only within a special MemoryArea
> all the objects referenced by my immortal structure. Maybe I should
> rewrite my code in some "real language" ;-).
> thanks for your suggestions,
> Mathieu
> -- 

More information about the Java mailing list