RFR(xs): 8184339: Thread::current_or_null() should not assert if Posix TLS is not yet initialized

[Thomas Stüfe]

On Mon, Jul 17, 2017 at 10:33 PM, Daniel D. Daugherty <
daniel.daugherty at oracle.com> wrote:

> On 7/17/17 1:00 AM, Thomas Stüfe wrote:
>
>> Hi all,
>>
>> may I please have reviews + a sponsor for the following fix:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8184339
>> webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8184339-Thread-cu
>> rrent-or-null-shall-not-assert/webrev.00/webrev/
>>
>
> src/share/vm/runtime/thread.hpp
>     No comments.
>
> Thumbs up! Thanks for the clear analysis in the bug.
>
> Dan
>
>
Thanks Dan!


>
> The problem is caused by the fact that Posix TLS cannot be used before it
>> is initialized. It is initialized in os::init(). If we use Posix TLS (eg
>> via Thread::current()) before, we assert. It is used now (since
>> JDK-8183925
>> <https://bugs.openjdk.java.net/browse/JDK-8183925>) before os::init()
>> (see
>> callstack in bug description).
>>
>> There are two functions, Thread::current() and Thread::current_or_null().
>> The latter should not assert if Posix TLS is not yet available but return
>> NULL instead. This is what callers expect: this function is safe to call,
>> but it might not return a valid Thread*.
>>
>> Note that this issue currently only comes up at AIX, because AIX is the
>> only platform using Posix TLS for Thread::current() - all other platforms
>> use Compiler-based TLS (__thread variables).
>>
>> However, we want to keep the Posix TLS code path alive, so this may also
>> affect other platforms. There have been compiler bugs in the past (e.g.
>> gcc
>> + glibc) leading to errors when using compiler-based TLS, so it is good to
>> have a reliable fallback.
>>
>> Thanks,
>>
>> Thomas
>>
>
>