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

[Daniel Jacobowitz <drow at mvista dot com>]

On Sun, Jan 27, 2002 at 03:30:51PM +1300, Bryce McKinlay wrote:
> 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?

That's currently how we figure out the 'real' type of an object. 
Obviously, this is something debuggers like to be able to do.

My impression was that Java classes don't have RTTI available,
generally.  I assume the information GDB wants is there somewhere; we
want to figure out a good way to get at it, in an ABI-defined manner if
possible.  But I'm not going there until I have some more time to spend
on C++ first.

> >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.

Thanks, that makes sense.  As does Tom's answer.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer