Re: gcj slower than JVM on RedHat/s390?

[Hans Boehm <Hans dot Boehm at hp dot com>]

On 10 Apr 2003, Tom Tromey wrote:

> >>>>> "Hans" == Boehm, Hans <hans_boehm at hp dot com> writes:
> 
> Hans> Allocation of short-lived memory is also known to be slower in
> Hans> gcj than many other JVMs.  (The allocation path is still
> Hans> suboptimal, the collector root set is too large, and the
> Hans> collector is not generational.
> 
> I've been meaning to mention this for a while now...
> 
> I think we should take another look at Jeff's old patch to explicitly
> label those sections of memory that need to be scanned.  This would be
> an incompatible change to CNI.  However, it sounds like it would be
> worth it.  Do you agree?  Or is the root set too large for some other
> reason?
> 
> We could add a call or a flag to disable this as a debugging aid --
> i.e., if you code works with the flag and fails without it, then
> you're probably missing a registration somewhere.
> 
I agree that this would be a good idea.

I still would prefer it if we could explicitly exclude non-roots instead.
But that sounds quite hard.

The flag to revert to the current root identification algorithm is
important, perhaps also for other reasons.  One of the Mono contributors
just pointed out that eventually it would be nice to be able to
support multiple GC client libraries in the same process.  That clearly
breaks if we explicitly register only gcj roots.

Ideally the flag should support using the "classic" root finding
algorithm on all addresses > some specified value, so that root
registration bugs can be tracked down with binary search.  That probably
needs to be implemented mostly in the collector.  I'll see what that
takes.

Hans

-- 
Hans Boehm
(hboehm at hpl dot hp dot com)