Re: binary compatibility ABI

[Andrew Haley <aph at redhat dot com>]

Jeff Sturm writes:
 > On Wed, 10 Sep 2003, 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.