benchmark result

Mon Dec 6 15:08:00 GMT 2004

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
--