Final methods and the BC-ABI
Bryce McKinlay
bryce@mckinlay.net.nz
Thu Nov 6 23:00:00 GMT 2003
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?
Regards,
Bryce.
More information about the Java
mailing list