RFR: JDK-8033696: "assert(thread != NULL) failed: just checking" due to Thread::current() and JNI pthread interaction
david.holmes at oracle.com
Sun Feb 16 16:35:14 PST 2014
As per previous discussions I think this is okay. Normally we don't flag
changes with the bug ID but in this case I think it is obscure enough to
I've convinced myself that the order of destructor invocations doesn't
matter, as long as a simple linear traversal is done that checks the
values, nulls them and invokes the destructor (if any). However if the
implementation did this in two passes:
find all non-null values with destructors;
execute all destructors;
then our destructor would be called multiple times in the normal case,
as well as the bad case.
So we are relying on the linux and bsd implementation behaviour. We
already know that neither seem to follow the POSIX spec on this - hence
the bug. You've verified how linux behaves. But now we need to be clear
how different BSDs will behave - at least FreeBSD and OSX. Hopefully
someone from runtime can assist with the analysis on BSD.
On 11/02/2014 2:21 AM, Andreas Eriksson wrote:
> Could I please get reviews for this change.
> JBS: https://bugs.openjdk.java.net/browse/JDK-8033696
> Webrev: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.00/
> Mail discussion:
> JNI code is using pthread_key_create with a destructor to detach the
> thread from the JVM when the thread is exiting.
> For some flavors of Linux and BSD the JVM is also using the
> pthread_key_create, to store the Thread::current() value in a thread
> local storage.
> Since the thread local storage containing the thread pointer is erased
> (by pthread) before the JNI destructor runs, we run detachCurrentThread
> on a thread that has NULL as current thread.
> This fix uses a destructor for the thread pointer that restores the
> value, so that the JNI destructor can run detachCurrentThread successfully.
> More info in JBS.
> Native code regtest attached to JBS tested on Linux, but not on Mac
> since I don't have access to one.
> JPRT ran without a problem.
More information about the hotspot-runtime-dev