Thread::current() and JNI pthread interaction

Andreas Eriksson andreas.eriksson at
Wed Feb 5 03:47:41 PST 2014


I'm investigating a bug where JNI code (attached, compilation 
instructions below) is using pthread_key_create with a destructor to 
detach the thread from the JVM when the thread is exiting.
This solution works well when running on Solaris or a 32 bit JVM on 
Linux, but when run on 64 bit JVM on Linux the threads hang when detaching.

It turns out that for 64 bit Linux the JVM is also using the 
pthread_key_create, to store the Thread::current() value in a thread 
local storage.
Ssince the thread local storages are reset in Thread::~Thread 
(ThreadLocalStorage::set_thread(NULL)), before the JNI destructor runs, 
we run detachCurrentThread on a thread that has NULL as current thread.
With a product build this breaks locks/monitors, and the threads hang. 
With a debug build an assert in Thread::current() is hit instead.

Everything works if detachCurrentThread is called from the main logic 

Is this considered a bug, or maybe this behavior is expected?


Compile native:
# 64bit
gcc -shared -fpic  -o  -I$JAVA_HOME/include 
-I$JAVA_HOME/include/linux -lstdc++ Callback_Native.cpp

# 32bit
gcc -v -m32 -shared -fpic  -o  -I$JAVA_HOME/include 
-I$JAVA_HOME/include/linux -lstdc++ Callback_Native.cpp

Compile java (from callback/src/main/java):
$JAVA_HOME/bin/javac com/test/callback/
$JAVA_HOME/bin/javac com/test/callback/

To run: (from callback/src/main/java)
$JAVA_HOME/bin/java -Djava.library.path=$NATIVE com.test.callback.App
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callback_jni.tar.gz
Type: application/gzip
Size: 3508 bytes
Desc: not available
Url : 

More information about the hotspot-runtime-dev mailing list