This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: binary compatibility ABI
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Bryce McKinlay <bryce at mckinlay dot net dot nz>, <java at gcc dot gnu dot org>
- Date: Wed, 10 Sep 2003 17:59:33 -0400 (EDT)
- Subject: Re: binary compatibility ABI
On Wed, 10 Sep 2003, Andrew Haley wrote:
> Well, kinda sorta. The first time a class is accessed it has to be
> initialized, but as long as we have to go through an indirection to
> invoke a method we might as well rewrite that indirection once the
> class is initialized.
That would help for initialization via static method call. How about
e.g. _Jv_AllocObject, which always does a _Jv_InitClass?
There's still room to shorten the allocation path quite a bit, and my
testing suggests it would be a significant win. One of my local patches
modifies gcj to emit GC_gcj_malloc calls directly when JVMPI isn't used.
> But TLS is slow.
I wonder if that's still true. On x86, TLS reads look about the same as
a normal read, e.g. for "__thread int x;" I get:
movl %gs:x@NTPOFF, %eax
Although this depends on having a recent kernel, gcc, binutils and glibc,
it's far better than using pthread_getspecific.
Jeff