This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: gcj slower than JVM on RedHat/s390?
- From: Tom Tromey <tromey at redhat dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: "'Jeff Sturm'" <jsturm at one-point dot com>, Andy Faibishenko <AFAIBIS at transunion dot com>, java at gcc dot gnu dot org
- Date: 10 Apr 2003 22:16:34 -0600
- Subject: Re: gcj slower than JVM on RedHat/s390?
- References: <75A9FEBA25015040A761C1F74975667D01441FD3@hplex4.hpl.hp.com>
- Reply-to: tromey at redhat dot com
>>>>> "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.
As for shortening the allocation path -- I'm all for it. If you don't
want to write a patch, could you submit a PR? There are too many
little things like this we've forgotten about in the past.
Tom