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

[Gerard Ziemski]

No, sorry I don't know of any machines with those OSes and I never used 
either one - use them from a virtual machine maybe?


cheers

On 2/24/2014 5:36 AM, Andreas Eriksson wrote:
> Thanks Gerard.
>
> Do you know if there are any machines with FreeBSD or OpenBSD that I 
> can test this on?
>
> Regards,
> Andreas
>
> On 2014-02-20 21:55, Gerard Ziemski wrote:
>> 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
>>>
>>
>
>