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

Bryce McKinlay
Wed Jan 23 20:31:00 GMT 2002

Per Bothner wrote:

> Bryce McKinlay wrote:
>> For binary compatibility, A.depth isn't known at compile time, 
>> because inserting new superclasses is an allowable binary compatible 
>> change. So, the bounds check is required.
> Well, we have not agreed on whether this model of binary compatibility
> should be the default.  Certainly for standard class it is reasonable
> to assume a fixed hierachy, and I think we do want to at least provide
> an option to resolve as much as possible at link or compile time. 

I agree "--no-binary-compatibility" should always been an option (and 
perhaps the default for static compilation), much like 
--no-bounds-check. I would like to make binary compatibility the default 
eventually though, assuming the performance impact is shown to be not 
too large and only when it is finished and well tested.

>> Also, If the ancestors were ordered this way, getClass() becomes 
>> expensive because B.class is _not_ at a fixed offset from the vtable 
>> pointer,
> getClass is not as important as instanceof or casts.  

Getting the class object through a vtable needs to be fast for things 
like interface type checks, if the itable is still to be referenced from 
the class. I guess we could put the pointer-to-itable in the vtable as 

> > type_info is for C++ type info, not the java class object, right?
> It could be both.

Ahh, I see. Although that wouldn't work if we were to put static class 
data in class objects (for improved performance and better JLS 
compliance), because the size of the class then wouldn't be constant.



More information about the Java mailing list