CNI invocation API proposal

Fri Apr 13 14:33:00 GMT 2001

On 2001年4月13日, Cedric Berger wrote:
> Well, I don't know for CNI, but certainly not for JNI. if you want to
> "store" the returned object (in the stack or anywhere else), you'll have
> first to create a "global reference"

Right. For JNI the object can only be used as long as its local ref
exists, beyond that you must create a global ref or you lose it.
CNI doesn't have the concept of local/global refs as JNI does. Instead
both native code and Java are GC'ed. That's why I suggested the callback
mechanism for invocation... it seems more aligned with the design
philosophy of CNI.
If you really want to manage refs there is always JNI, which gcj supports
too.
> Ok, but this is not only a stack issue: what will append if you store the
> jobject in a malloc'd area for example (with malloc() called before the
> JVM was ever created)?

Bad things will happen. The CNI docs should say so (they may not, I
didn't look). In CNI the GC allocates memory for all Java objects, no
matter if you invoke `new' from Java or C++ code.
If you are integrating external code that uses malloc() you must
arrange to free() it eventually, generally with a finalizer. If the
external library can store pointers back to Java objects you must keep
another pointer somewhere the collector can find it.
There are rules to using JNI, as in CNI. But the rules are easier, I
think, and lend themselves to faster overall execution.
Jeff