<div dir="auto"><div dir="auto">Agreed, I believe there should be an hb relationship with this, if the target is not alive.</div><div dir="auto"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 3, 2023, 04:50 Quan Anh Mai <<a href="mailto:qamai@openjdk.org" target="_blank" rel="noreferrer">qamai@openjdk.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <<a href="mailto:dholmes@openjdk.org" rel="noreferrer noreferrer" target="_blank">dholmes@openjdk.org</a>> wrote:<br>
<br>
>> 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()`:<br>
>> <br>
>> boolean alive() {<br>
>>   return eetop != 0;<br>
>> } <br>
>> <br>
>> I also updated a comment in relation to `eetop`.<br>
>> <br>
>> Testing: tiers 1-3<br>
>> <br>
>> Thanks<br>
><br>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:<br>
> <br>
>   Comment from AlanB<br>
<br>
May I ask if we need some form of memory order here? Maybe an aquiring load is necessary?<br>
<br>
-------------<br>
<br>
PR Comment: <a href="https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776" rel="noreferrer noreferrer noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776</a><br>
</blockquote></div></div>