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

[Gerard Ziemski]

hi Andreas,

Mac OS X appears to work similarly and the pthread_key destructor 
appears to be only called once.

So it appears that OS X also does not follow the POSIX spec, but even if 
(when) it does in the future, the destructor will be called at most 
PTHREAD_DESTRUCTOR_ITERATIONS times (which on Mac OS X is currently set 
to 4), so if we keep our destructor as simple as it is we should be OK.

Thank you for the fix.


cheers

On 2/16/2014 6:35 PM, David Holmes wrote:
> 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
>