JNI calls that don't return

[ian.rogers at manchester.ac.uk (Ian Rogers)]

Thanks for the replies. I have worked further on this and the particular 
issue isn't with GC barriers but with M-to-N threading. In theory if 1 
of the M threads becomes blocked in a JNI call then the other threads 
should be moved onto another of the N underlying native threads. 
Unfortunately, as it's possible to call back into the JVM, the JVM's 
yield code can schedule another thread on the same native thread before 
realising the 1st thread is blocked and now its possibly handling a 
second blocked thread but now on the same native thread. Scheduling 
blocked 2 native threads running on the same native thread requires a 
rewrite to the underlying native thread library. For the gtk peers this 
is done by enabling the portable native sync code, but my experience is 
that this is currently broken (and using it is not advised as it would 
inhibit the using JVM from being used as a plugin in a gthreaded 
application). In any case having a fixed number of N underlying threads 
will probably also become a problem. Anyway, I have a small proposed 
change to gdk_threads_enter for JVMs with M-to-N threading (in gtkpeer.h):

#define M_TO_N_JAVA_THREADING 1

#if M_TO_N_JAVA_THREADING
#define gdk_threads_enter()                          \
{                                                    \
  JNIEnv *env = cp_gtk_gdk_env();                    \
  while(g_mutex_trylock(gdk_threads_mutex) == FALSE){ \
         jclass thread_class = (*env)->FindClass (env, 
"java/lang/Thread"); \
         jmethodID thread_yield_mth = (*env)->GetStaticMethodID (env, 
thread_class, "yield", "()V"); \
         (*env)->CallStaticVoidMethod (env, thread_class, 
thread_yield_mth); \
  } \
  g_mutex_unlock(gdk_threads_mutex); \
  gdk_threads_enter();                               \
}
#endif

it prevents 2 java threads on the same native thread becoming deadlocked 
on the gdk_threads_mutex. Unfortunately the gdk_threads_mutex is 
supposed to be private, but I think accessing it here is suitable.

I think removing the portable native sync code and having specific fixes 
for M-to-N threading is an appropriate change. What are others opinions?

As part of this would it be possible to have versions of JNI routines 
that don't return that at least call Java yield in the case of being on 
a M-to-N threaded JVM?

Thanks,

Ian Rogers