Re: about non-compatible optimization (was: Re: patch to bring java vtables closer to g++ abi conformance)

[Andrew Haley <aph at cambridge dot redhat dot com>]

Tuomas Leikola writes:
 > 
 > ----- Original Message -----
 > From: "Bryce McKinlay" <bryce@waitaki.otago.ac.nz>
 > To: "Tuomas Leikola" <tuomas.leikola@digia.com>
 > Cc: <java@gcc.gnu.org>; <shudo@computer.org>
 > Sent: Tuesday, January 29, 2002 2:25 AM
 > Subject: Re: about non-compatible optimization (was: Re: patch to bring java
 > vtables closer to g++ abi conformance)
 > 
 > 
 > > However the real reason static is so
 > > much slower here is due to GCJ adding a class initialization check to
 > > the start of every static method. I think we can do better by putting
 > > this check at the call site rather than in the method.
 > 
 > ouch. is there a way to avoid this? -finitialize-all-classes-at-startup or
 > something

No, because it's vital that classes are initialized in correct
dependency order.  This avoids the nasty C++ problem with dependency
order between static initializers.

The Right Way to solve this problem, IMO, is to have two entry points
to each method, like this:

bar.foo:
    call InitializeClass (bar)
bar.foo.alreadyinitialzed:
    ... the rest

And the single level of indirection that we already have for calls
into shared objects suffices here: we just rewrite the entry in the
PLT.  For statically linked programs we'd need to add the indirection,
or maybe we could rewrite the actuall calling instruction itself
(eek!)

However, I don't think that gcc has any general-purpose means to do
this.  There are mechanisms to allow multiple entry points which are
back-end specific, for example to optimize stack alignment.  We could
use the same technique in a machine dependent way.  

However, I'd much prefer to solve the problem in a way that is useful
for all target architectures.

Andrew.