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

[Andreas Eriksson]

Great, thanks.

/Andreas

On 2014-02-24 13:15, Dmitry Samersoff wrote:
> Andreas,
>
> I'll check it on FreeBSD 9.x
>
> -Dmitry
>
> On 2014-02-24 15:36, 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
>