Re: patch to bring java vtables closer to g++ abi conformance

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Daniel Jacobowitz wrote:

>>For binary compatibility, there isn't a symbol for the vtable at all 
>>because the vtable isn't laid out until runtime.
>>
>
>Then we will need to come up with a solution for this eventually. 
>Probably one involving RTTI.
>

An alternative would be to access the vtable for a class via its java 
Class object. Class objects are likely to continue to be statically 
generated, except where the class itself is generated at runtime (such 
as interpreted/proxy/remote classes).

Its probably obvious, but what does GDB need the vtable symbol for anyway?

>I still don't understand why runtime vtable's are really necessary, but I don't know anything about the GCJ runtime at all.
>

Because a superclass is allowed to change without breaking binary 
compatablity. In the C++ ABI, changing the layout of virtual methods in 
a class requires recompilation of any code that uses or extends that 
class. Otherwise, the offsets for given virtual methods in the vtable is 
likely to be inconsistent between the binary object which defines the 
class and that which refers to/uses it. In Java, however, it is 
permitted (required by the language specification, in fact) to insert, 
remove, and reorder virtual methods without breaking code that was 
previously compiled against older versions of that class. Because we 
don't know if this has happened until runtime, the gcj runtime must 
compare the virtual methods defined by a class against those defined by 
its superclass (before or during class initialization), and match them 
up so that any overridden methods occupy the same vtable offset as they 
do in the superclass vtable.

regards

Bryce.