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

Thomas Stüfe thomas.stuefe at gmail.com
Tue Jul 18 18:45:04 UTC 2017

Thank you Coleen!

On Tue, Jul 18, 2017 at 6:05 PM, <coleen.phillimore at oracle.com> wrote:

> Seems good.  I'll check it in for you.
> Coleen
> On 7/18/17 9:02 AM, Thomas Stüfe wrote:
>> Hi Folks,
>> may I please have a second review and a sponsor?
>> This is a bit of an annoying issue, it causes endless recursions on AIX
>> because error reporting stumbles over itself when calling
>> Thread::current().
>> Thanks! ..Thomas
>> On Mon, Jul 17, 2017 at 9:00 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
>> 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-
>>> 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).
>>> 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

More information about the hotspot-dev mailing list