On Fri, 2 Sep 2022 20:33:37 GMT, David Holmes <[email protected]> wrote:
>> This is an MR which partially reverts JDK-8289091 such that
>> JavaThread::threadObj() does not call Thread::current().
>>
>> A JVMTI operation could call threadObj() and clear the Windows GetLastError
>> value.
>>
>> Partial, because I haven't reverted changes in JavaThread::print_on_error(),
>> they aren't connected to the problems seen.
>
> src/hotspot/share/runtime/javaThread.cpp line 165:
>
>> 163: oop JavaThread::threadObj() const {
>> 164: // Using Thread::current_or_null_safe() here risks that calling
>> threadObj() can
>> 165: // overwrite a native thread local, e.g. JVMTI operations clearing
>> GetLastError on Windows.
>
> Suggestion:
>
> // Ideally we would verify the current thread is oop_safe when this is
> called, but as we can
> // be called from a signal handler we would have to use
> Thread::current_or_null_safe(). That
> // has overhead and also interacts poorly with GetLastError on Windows due to
> the use of TLS.
> // Instead callers must verify oop safe access.
Thanks David, will update comment and check Dan is OK with this.
-------------
PR: https://git.openjdk.org/jdk/pull/10147
