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

[Coleen Phillimore]

On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have the strange situation where calling `t.isAlive()` on a `java.lang.Thread` `t`, will call into the VM (via `alive()` then `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract its `JavaThread` pointer and compare it to null. We can simply read `eetop` directly in `Thread.alive()`:
>> 
>> boolean alive() {
>>   return eetop != 0;
>> } 
>> 
>> I also updated a comment in relation to `eetop`.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment from AlanB

This looks good.  Yes another RFE to rename eetop would be good but we shouldn't use our usual injected field mechanism to hide this from reflection because then we'd have to revert this and call into the JVM to fix it.  Also, we may want to also change the ensure.join() code in the VM to set eetop to zero directly to avoid one of the ObjectLockers in the vm.
We could add eetop (or its new name) to the excluded list in setAccessible().

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13287#pullrequestreview-1368976934