[jdk17u-dev] RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM [v2]

[David Holmes]

On Fri, 23 Jun 2023 15:54:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Remove one line more
>>  - Merge branch 'master' into JDK-8305425-thread-is-alive
>>  - Adjust comment: drop the mention of non-existent FieldHolder
>>  - Touchups to minimize the difference
>>  - Backport 35cb303a2c0c8b32de257c02e012a1928a6b4594
>
> What I see in the PR:
> 
> 1. Remove JVM_IsThreadAlive. Straightforward.
> 2. OrderAccess::release() before nulling the native thread field in ensure_join. This looks like it should always have been there, independent of this PR, even when eetop wasn't volatile. Strictly speaking, there should be a storeload barrier after or as part of the call to set_thread() (which there isn't), but the store is done while the j.l.Thread object is locked, so no need.

@phohensee the memory ordering issues were discussed in detail in the original PR for this change in mainline.

-------------

PR Comment: https://git.openjdk.org/jdk17u-dev/pull/1425#issuecomment-1605000903