This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Final methods and the BC-ABI
- From: Andrew Haley <aph at redhat dot com>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: Java <java at gcc dot gnu dot org>
- Date: Fri, 7 Nov 2003 11:01:00 +0000
- Subject: Final methods and the BC-ABI
- References: <1624A114-10AB-11D8-B072-003065F97F7C@mckinlay.net.nz>
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.