binary compatibility ABI

Wed Sep 10 14:25:00 GMT 2003

Jeff Sturm writes:
 > On 2003年9月10日, Bryce McKinlay wrote:
 > > > Also, we can dispense with the call to initialize the class that
 > > > contains a static data member:
 > >
 > > I think that keeping the initialization check/call at the call (or
 > > field access) site gives us more opportunity to optimize it out at
 > > compile time. eg: hoisting it out of loops, eliminating it if class is
 > > already known to be initialized in the current method, keeping a local
 > > cache, etc.
 > 
 > Very good point. Libgcj hides a lot of class inits now, in 'new' or
 > 'instanceof' calls for example. The more these can be exposed the easier
 > they are to eliminate.
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.
 > (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.
Andrew.