On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <[email protected]> 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
