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

[Simon Roberts]

Agreed, I believe there should be an hb relationship with this, if the
target is not alive.

On Mon, Apr 3, 2023, 04:50 Quan Anh Mai <qamai at openjdk.org> wrote:

> 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
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230403/da007773/attachment-0001.htm>