CNI invocation API proposal

[Cedric Berger]

Jeff Sturm wrote:

> On Fri, 13 Apr 2001, Cedric Berger wrote:
> > Does the GC really need to know the stack bottom?
> > What I mean is that there should be *no* java object on the
> > stack before a thread enters the VM when it executes it's
> > first call to a java object, right?
> > the GC should only need to scan the stack of a thread from
> > this point to the top:
>
> But once the thread is attached, it is free to return from the calling
> function, call a java method and save the result in a stack frame below
> the point where it attached.

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"

> > I.E: JNI/CNI:CallVoidMethod could be implemented this way:
> >
> > CallVoidMethod() {
> >     JavaPeer peer = getPeerOneWayOrAnother();
> >     if(peer.stackBottom == 0)
> >         peer.stackBottom = currentStack;
> >     reallyCallJavaMethod();
> > }
>
> Suppose your example returned a jobject instead of void.  Supposing the
> thread attached as a side effect of calling getPeerOnewayOrAnother() how
> do you ensure the returned object is visible to GC?

This should be done manually by the calling code one way or another.

> JNI uses local refs to track the returned object, making it unnecessary to
> conservatively scan the native stack.  But unless you are diligent with
> DeleteLocalRef() you introduce memory leaks that way.  In JNI I found
> myself frequently detaching for just that reason.  So I'd like to avoid
> the global/local ref stuff entirely when I am not in JNI.

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)?