Final methods and the BC-ABI

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

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.