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

[David Holmes]

Hi Thomas,

Back from vacation ...

I appreciate the effort to fix this problem, however ... :)

> Thomas Stüfe thomas.stuefe at gmail.com
> Mon Jul 17 07:00:01 UTC 2017
> 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-current-or-null-shall-not-assert/webrev.00/webrev/
> 
> 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).

... those kind of initialization order changes are exactly what the 
assertion was supposed to detect! It can be dangerous to use various VM 
facilities "too soon" in the initialization sequence. The change in 
JDK-8183925 needs a close examination IMHO before relaxing this guard. :(

> 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*.

Yes but because the current thread has not yet been set, not because 
we're executing the code well before any VM initialization has been 
performed! :(

> 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).

It's also used in the mobile-dev project IIRC, but they don't have 
JDK-8183925 applied.

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

Definitely!

Cheers,
David

> Thanks,
> 
> Thomas
>