This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: heap fragmentation?
- From: Tom Tromey <tromey at redhat dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, "Boehm, Hans" <hans_boehm at hp dot com>, java at gcc dot gnu dot org, boehm at acm dot org
- Date: 10 Jun 2002 21:47:29 -0600
- Subject: Re: heap fragmentation?
- References: <Pine.LNX.4.10.10206070037400.31022-100000@mars.deadcafe.org>
- Reply-to: tromey at redhat dot com
>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
Jeff> If all static members can be addressed at constant offsets from
Jeff> the class pointer, that takes care of the class initialization
Jeff> test we do now.
Could you explain this to me? It seems to me that we'll still need a
test, because the class will be dynamically created. So at an active
use site we'll have to see if it has been created, presumably by
making a synchronized method call. Hopefully I'm missing something.
Hmm, right now we seem to do "double checked locking" when checking
the class initialization status. At least that's what it looks like:
cmpb $12, _ZN4java4lang6System6class$E+74
setge %al
movb %al, -1(%ebp)
cmpb $0, -1(%ebp)
jne .L3
movl $_ZN4java4lang6System6class$E, (%esp)
call _Jv_InitClass
Isn't that a no-no?
Jeff> (gcj -C isn't quite ready for executable bytecode)
I know of a few `gcj -C' code generation bugs. They are all in Gnats.
Are these the ones you're referring to? Or are there more I don't
know about?
Note that the .class front end isn't perfect either. There is at
least one bug without a workaround in Gnats.
Tom