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

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

Per Bothner wrote:

> The g++ v3 abi (http://www.codesourcery.com/cxx-abi/abi.html) specifies
> that each vtable contains an offset-to-top and a type_info pointer.
> These words are *before* the word pointed to by each object's vtable
> pointer. 


Well, actually, I've been considering using that space for the ancestors 
table in order to optimize type checking.

Given:

class A {}
class B extends A {}

Then B would have a vtable which looks something like:

[-2] &Object.class
[-1] &A.class
[0] &B.class  <-- vtable pointer points here
[1] GC descriptor
[2] &java.lang.Object.hashCode()
[3] ...etc

"b instanceof A" then becomes something like

"(b->vtbl[0]->depth - A.depth >= 0) && (b->vtbl[b->vtbl[0]->depth - 
A.depth] == A)"

... which is smaller than it looks because the whole subtraction part 
can be simplified by CSE, and certainly becomes small enough to be inlined.

You might think that having Object.class in the ancestors table is 
redundant, and it is for instanceof because it is statically known that 
the depth of Object is always 0, but it isn't for other things like 
array store checks because the element type of an array could be Object.

The reasons why we'd want this in the vtable rather than the class object:

- Conveniently, the class pointer is already at the zero-offset in the 
vtable, so not explicit check for "b->vtbl[0] == A" is needed.
- Class objects are statically allocated, but my fiendish masterplan is 
to have all vtables laid out at runtime. For binary compatibility we 
don't know how many superclasses a class has until runtime, because 
someone might insert a new superclass into the inheritance chain. So we 
don't know how big to make the class object.

Of course, we could keep the ancestors table in a separate object 
pointed to from the class object (what we do now), but I think the 
vtable approach is better because it has better locality and reduces the 
number of dereferences required. Runtime type checks are so common in 
Java that we really should optimize them as much as possible.

> So this change doesn't at this point have much effect, except adding two
> words for each Java class.  However, it brings us closer to abi
> compliance, making it less likely to confuse various tools such as
> debuggers.  I looked at this issue in the context of gdb crashing.  Now
> I'm not totally sure this patch is needed for gdb, since I also fixed
> some things in gdb itself.  In any case it seems like a good idea.
>
> Comments?  Anyone think I shouldn't check it in?


If it fixes gdb then I certainly have no objection, just that we may 
want to do something else eventually.

I think that having fast type checks is more important than having C++ 
RTTI info in Java objects, but others might disagree?

regards

Bryce.