Re: GTK peer switching JNIEnv *?

[Robert Lougher]

Hi,

> > We triggered exactly the same bug with jamvm lately. Mark found out it
> > was a bug in jamvm handling JNIEnv* wrongly. I don't know if this was
> > a fix or a hack. But it helped. Perhaps its a bug in JCVM regarding
> > handling of JNIEnv.
> 
> It was kind of a hack. There was a real bug in how the JNIEnv was stack
> allocated which meant that even the same thread would not get the same
> JNIEnv each time. All threads now just get the same (static) JNIEnv
> which works for now.
> 

JamVM doesn't care which JNIEnv you use as it contains nothing but the
JNI function table pointer.  The stack allocation caused a problem
because the gtk peer code cached the pntr and tried to use it later
after the function had returned.

> > The GTK peer saves a JNIEnv* pointer for later use for the callback
> > methods. This is according to the JNI spec at least not absolutely
> > correct. The correct way would be to get the current JNIEnv* object
> > through the global JavaVM object. That is not done yet. Perhaps this
> > would help you and other VMs.
> 
> Yes, we should do it this way. We actually already store the_vm (JavaVM)
> when we initialize gtk+ together with the gdk_env (JNIEnv). Everywhere
> we use the stored gdk_env we should carefully look whether it is only
> used from the original gtk+ event thread (directly or through a
> callback) oitherwise we should get the JNIEnv from the_vm.
> 

This would also have fixed the problem with JamVM.  However, stack
allocation was a bad idea (I've even forgotten why I did it).  Making
it static means there's only ever one JNIEnv*, which is fine for JamVM
as it's got no thread-specific stuff in it.  The spec just says that
the "VM is guaranteed to pass the same interface pointer to a native
method when it makes multiple calls to the native method from the same
Java thread".  It would be an interesting question to ask if JNI code
should expect the JNIEnv* to be different for different threads. 
Opinions?

> Note that the gtk+ AWT peer code has recently (after 0.13) changed to
> use only one event thread. But there are probably code paths that can
> call into native code from a different (user) thread. I nice addition to
> the runtime jni support would be a (slow) debugging path to check for
> this at native method call time.
> 
> Cheers,
> 
> Mark
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath
> 
> 
> 
>