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

[David Holmes]

On 3/04/2023 9:27 pm, Simon Roberts wrote:
> Agreed, I believe there should be an hb relationship with this, if the 
> target is not alive.

You are both right - I did not recall the hb relationship between the 
last action of a thread and a call to isAlive that returns false. The 
existing code does not explicitly have it. In practice it was likely 
implicitly there due to the native call and VM thread state transitions 
but I'm not so sure.

Making eetop volatile would logically fix that, but the VM code that 
clears eetop would also need modifying to perform a volatile write.

Cheers,
David

> On Mon, Apr 3, 2023, 04:50 Quan Anh Mai <qamai at openjdk.org 
> <mailto:qamai at openjdk.org>> wrote:
> 
>     On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dholmes at openjdk.org
>     <mailto: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
> 
>     May I ask if we need some form of memory order here? Maybe an
>     aquiring load is necessary?
> 
>     -------------
> 
>     PR Comment:
>     https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776
>     <https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776>
>