binary compatibility ABI

Thu Sep 11 14:32:00 GMT 2003

Jeff Sturm writes:
 > On 2003年9月10日, 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?
Well, perhaps we can't avoid class initialization checks in every
case, but in many cases we can. Maybe this case can be improved too:
we call _Jv_AllocObject and then new(), but we don't have to do it
that way.
 > 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.
Sure is. I remember many years ago dedicating a register to be a
theread pointer, and very nice it was too. I'm glad we've got around
to doing it on Linux.
Andrew.