This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: binary compatibility ABI
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'Andrew Haley'" <aph at redhat dot com>,Jeff Sturm <jsturm at one-point dot com>
- Cc: Bryce McKinlay <bryce at mckinlay dot net dot nz>, java at gcc dot gnu dot org
- Date: Wed, 10 Sep 2003 10:31:49 -0700
- Subject: RE: binary compatibility ABI
> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com]
> > (As an aside, I know there's been discussions before about static
> > vs. local boolean flags to track class initializations. What
> > about using TLS on platforms that support it (i.e. x86/linux)?
> > Each thread would check a thread-local boolean variable before
> > calling _Jv_InitClass, so it would have to attempt class
> > initialization at most once per class. I can't think of a reason
> > that would violate Java's memory model.)
>
> But TLS is slow.
>
I haven't been following this in enough detail, but:
Is it possible to somehow detect an uninitialized class using one of the
values that must be loaded anyway to access the field?
If you use a separate static field to check for initialization then you usually
have a memory read ordering issue between the flag read and the field read.
However if the value you test for initialization is used to compute the address
of the field itself, you still have a problem on Alpha, but on all other
architectures that we considered, the two reads appear to be ordered. Thus
testing a static location, since you have to load it anyway, shouldn't be
more expensive than the local test. (On Alpha you would need either a read
barrier or a separate approach.)
You still need a (write or release) memory barrier when you actually
perform the initialization, but that has minimal performance impact.
With the new Java memory model spec, this is analogous to the approach
used to guarantee that final fields of well-behaved objects end up with
the correct value.
Hans