Final methods and the BC-ABI

Andrew Haley aph@redhat.com
Fri Nov 7 11:02:00 GMT 2003


Bryce McKinlay writes:
 > The binary compatibility spec says that the "final" modifier can be 
 > added or removed from a method without breaking binary compatibility 
 > (except in the case where a class actually tries to override that 
 > method). This means that, under the BC-ABI, final methods must always 
 > get a vtable entry and use it for dispatch between binaries. Otherwise, 
 > a vtable call which is made to a non-final method would no longer work 
 > because that method will no longer have a vtable entry, and conversely, 
 > a non-vtable call to a final method which is changed to be non-final 
 > would then not have the correct virtual call semantics.
 > 
 > Currently, the compiler does not generate vtable entries at all for 
 > final methods under the "current" ABI. This poses a problem in that 
 > --indirect-dispatch code will not be able to inter-operate with 
 > "current ABI" code. So, I propose that the compiler be changed to 
 > generate vtable entries for all final methods.
 > 
 > I don't think that this will hurt performance. PIC calls through the 
 > PLT are known to be slow, so for dynamically linked old-ABI code it 
 > will likely be a performance improvement in most cases. In addition, we 
 > currently have to generate an explicit null-pointer check for each 
 > final call. If we use the vtable, that check can be removed, which 
 > likely more than offsets the cost of the vtable lookup.
 > 
 > Of course, the compiler must only necessarily use vtable dispatch for 
 > final calls that might cross a binary boundary - calls within a binary 
 > can still be easily optimized (in-lined for example).
 > 
 > Comments?

Yes.  :-)

>From an implementation point of view, all that we have to do is
generate code to go via the vtable for all such calls and then make
sure that java_get_callee_fndecl() knows how to unpick them.  Inlining
will then work just fine.

Andrew.



More information about the Java mailing list