RFR: JDK-8033696: "assert(thread != NULL) failed: just checking" due to Thread::current() and JNI pthread interaction

[David Holmes]

Hi Andreas,

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 
warrant that.

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;
rinse-repeat

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.

Thanks,
David

On 11/02/2014 2:21 AM, Andreas Eriksson wrote:
> Hi,
>
> 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:
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>
>
> Summary:
> 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.
>
> Testing:
> 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.
>
> Regards,
> Andreas