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 <qa...@openjdk.org> wrote:
> On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dhol...@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
>
