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

Andrew Haley aph@cambridge.redhat.com
Tue Jan 29 08:59:00 GMT 2002


Per Bothner writes:
 > Andrew Haley wrote:
 > > 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. ...
 > > 
 > > However, I don't think that gcc has any general-purpose means to do
 > > this.
 > 
 > Well, I believe C++ uses multiple entry-points for handling
 > "this" adjustment as needed for multiple inheritance.

I has been proposed, but it hasn't been done yet.  According to Jason
Merrill, the proposed mechanism is "amorphous" at the present time.

According to Bernd Schmidt, however, flow can *already* cope with
multiple entry points.  Thr problem arises, however, because the back
ends, in particular prologue generation, aren't written with this in
mind.  Even worse, some back ends themselves make use of multiple
entry points and this is unlikely to inter-operate.

 > If we can't use that, we can always do have bar.foo make a plain
 > call to bar.foo.alreadyinitialzed.  After all there are no
 > variable-sized argument lists or structures passed by value in
 > Java, so this is easy.

This is a much easier solution and I'm going to investigate it.

 > It might produce slightly confusing stack traces, but that can be
 > fixed.

Yes, but with tail-recursion optimization the call would be turned
into a jump anyway.

Andrew.



More information about the Java mailing list