binary compatibility ABI

[Andrew Haley]

Jeff Sturm writes:
 > 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?

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.