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

Tue Jan 29 03:56:00 GMT 2002

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.