This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: patch to bring java vtables closer to g++ abi conformance
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
well.
> > 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.
regards
Bryce.