CNI with interpreted and BC ABI compiled code

[Andrew Haley]

Robert Schuster writes:

 > due to my porting work on GCJ I was confronted with CNI for some
 > time and as some of you know. I like CNI very much ... so much that
 > I dont wan't to use JNI any more for all of my own projects. :)
 > 
 > There is however a caveat: With the neat CNI in place the GIJ
 > runtime will not be able to make use of BC ABI compiled classes any
 > longer. This limitation bothers me since the time I was first
 > introduced to it last year when I worked on the 'lazy linker'
 > issue.

Let's be clear about this.  CNI programs can call BC ABI compiled code
as long as that BC code is compiled with "-fno-indirect-classes".
This is an undocumented option that I only intended to be used when
building libgcj, which is a hybrid of BC and non-BC code.  This option
will probably go away once CNI is compatible with the BC ABI.

However, CNI programs used in this way cannot make use of any of the
BC guarantees.  If you change anything that the CNI code depends on,
you'll have to recompile the CNI code.

 > Last week I woke up early with my mind being busy thinking about
 > the reasons for the limitation and how one could fix it. It quickly
 > turned out that I need more information about the reasons for the
 > CNI issue.
 > 
 > I can't promise that I will be able to fix the issue soon but at
 > least I can gather all the information for it and put it into GCC's
 > Wiki so I (or someone else) can use that as a reference later.
 > 
 > So could any of you describe why CNI is not usable by interpreted
 > and BC-ABI compiled code?

CNI code is fine when called from interpreted code; libgcj depends on
that.  CNI code is also fine when called from BC-ABI compiled code.

 > And a few questions: When trying to load a CNI SO in the runtime
 > with System.loadLibrary() I get an error about missing
 > symbols. These symbols are all the things I used at the C++ level
 > but which belong to the Java implementation.

What do you mean by "belong to the Java implementation" ?

 > Why Java 'symbols' are nowhere available for the linker is clear to
 > me: They only exist as bytecode.

Right, so you need to compile the bytecode classes so CNI can see
them.  Either that, or write thunks in Java and BC-compile those.  So,
the CNI code could call the BC-compiled Jaca code, and that could call
the BC-compiled code.  Rather clumsy, but it would work.

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

The dynamic linker (ld.so) would kill the program before that
happened.

Andrew.