CNI with interpreted and BC ABI compiled code

[Tom Tromey]

>>>>> "Robert" == Robert Schuster <theBohemian@gmx.net> writes:

Robert> So could any of you describe why CNI is not usable by
Robert> interpreted and BC-ABI compiled code?

The basic thing is that CNI only generates code using the C++ ABI
right now.  This means things like offsets of fields, vtable slots,
names of classes, methods, etc, are compiled in.  So, if you change
the interpreted or BC-compiled class, the CNI code will silently (if
you are unlucky) do the wrong thing.  Or if the CNI code requires a
class which is interpreted, you will see (ld or ld.so -- not libgcj)
link errors.

There's a smaller issue with the interpreter.  If you load an
interpreted class, how would you know it wants to use CNI for its
native methods?  I guess we'd have to add something like JNI's
"register natives" call or the like.  Or maybe some internal call to
mark the code as "CNI-using" and then implement C++ name mangling in
libgcj (easier than it sounds, there's code in both gcc and gcjx).

Robert> Can the following be a feasible solution for the above
Robert> mentioned problem?  When a CNI SO is loaded and a symbol
Robert> cannot be found, the runtime inspects the symbol name,
Robert> calculates the class/field/method which is requested. If it
Robert> exists a suitable accessor is created. Finally a symbol is
Robert> dynamically created (is that possible?) which points at the
Robert> accessor.

Unfortunately AFAIK this isn't possible.

Tom