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

[Paul Hohensee]

On Fri, 23 Jun 2023 14:41:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Unclean backport to improve `Thread.isAlive` performance, and provide grounds for more backports in the area.
>> 
>> The majority of conflicts are due to integration of Loom in JDK 19, which reshaped some Thread code. I tried to change as little in 17u as possible to avoid the change fan-out.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1 tier2 tier3`
>>  - [x] Linux AArch64 fastdebug `tier1 tier2 tier3`
>
> 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. 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.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk17u-dev/pull/1425#pullrequestreview-1495409962