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

Sat Jan 26 23:15:00 GMT 2002

Daniel Jacobowitz wrote:
> My impression was that Java classes don't have RTTI available,

Java has much more complete RTTI available than C++, and it is
part of the standard (Sun) library specification. However, Java RTTI
is currently different and not complatible with C++ RTTI. What I've
suggested is implementing C++-compatble RTTI for Java classes - the
information is all there, it just doesn't follow the C++ ABI.
>>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.

Let me clarify that this (changing superclasses without re-compiling
derived classes) is not something GCJ has historically supported, and
it is not the default at this time. However, Bryce has recently
implemented support for this, and it is obviously a useful feature,
especially if it can be done at moderate cost. He may even be able
to convince us it should be the default!
In any case, we need vtables constructed at run-time for classes
loaded at run-time, It may be possible to handle this using
dynamic compilation (a JIT - Just-In-Time compiler), and gdb could
model this as if a shared library. But for now, dynamically
loaded code is interpreted, with no gdb support. It would be nice
if gdb had hooks to talking to interpreters, but that's a long-time dream.
Vtables for Java arrays coudl be handled would have to be handled
as C++ "vague linkage", so we just contruct them at run-time instead,
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/per/