Experiences using GCJ as an embedded compiler

[Per Bothner]

> Clever, but it makes C++/Java compatibility a bit messy.  I suppose that you
> could declare the C++ header file with a bunch of dummy virtual functions
> to fill in the `ancestors' slots.

Note that cc1plus knows about Java classes, and treats them specially.
So it is possible to use a different vtable layout.  However, that
does complicate some things, so it may not be worth it.  It is almost
as good to put the ancestor table in the Class object, rather than the
vtable.  The disadvantage is an extra level of indirection.  Or we
can put the ancestor table at *negative* offsets before the vtable proper.

> BTW, isn't CLASS_DEPTH(OCLS) always 1, since the first element of ancestors
> would always be the first subclass of java.lang.Object?  Seems that if
> `ancestors' contains a vector of all a class's superclasses, then
> CLASS_SUBCLASS_OF() should really be:

I think you missed this comment:

// If we order this table from current classes down by decreasing depth,
// we can combine the ancestors table with the pointer to the actual classs.

This, ancestors[0] is the object's actual class.

> We still want the run-time interface between `gcj'
> and invoking a method to be the following, no???
>
>  jnative
>   _Jv_LookupInterfaceMethod(jclass cl, jclass xface, int vtableIndex)
>   {
>   }

Well, this is just LOOKUP_INTERFACE, and that is simple enough that
it can and probably should be inlined.

> Since most classes don't implement
> very many interfaces (few more than 2 as your statistics show),
> even a linear scan through the implemented interfaces would be fast.

But there is still the overhead of a subroutine call, a loop, and
some comparisons.  Just doing some indirect lookups is much better.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner