This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: heap fragmentation?
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Tom Tromey <tromey at redhat 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: Wed, 12 Jun 2002 14:29:22 -0400 (EDT)
- Subject: Re: heap fragmentation?
On 10 Jun 2002, Tom Tromey wrote:
> 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.
No, my thinking was fuzzy. What I was getting at is: since we need need
a class pointer to test initialization anyway, why not use that class
pointer to address the static variable? If the compiler knew the offset
from the class object to static members, that would be easy.
> cmpb $12, _ZN4java4lang6System6class$E+74
> setge %al
> movb %al, -1(%ebp)
> cmpb $0, -1(%ebp)
> jne .L3
> movl $_ZN4java4lang6System6class$E, (%esp)
> call _Jv_InitClass
Typical x86 code. Aside from the double-check idiom, look at similar
output for sparc64:
sethi %hh(_ZN1a6class$E), %o0
sethi %lm(_ZN1a6class$E), %o1
or %o0, %hm(_ZN1a6class$E), %o0
sllx %o0, 32, %o0
add %o0, %o1, %o0
call _Jv_InitClass, 0
or %o0, %lo(_ZN1a6class$E), %o0
Six instructions just to load the class pointer. (Wonder why I didn't get
the init test?) Following that I get six insns per static data member.
With a short example:
class a {
static int x;
static int y;
static int sum() {
return x + y;
}
}
the sum() method has 23 instructions, not to mention run-time
relocations. I'd be motivated to reduce that. My application compiles to
over 10MB text and 6MB data+bss, and it isn't large at all.
Hans and Bryce explained the locking issues well, I won't add anything.
> 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?
I don't know, I haven't had time to investigate beyond discovering that
the "gcj -C"-compiled jar wouldn't run with the JDK.
Jeff