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 <qa...@openjdk.org
<mailto:qa...@openjdk.org>> wrote:
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes <dhol...@openjdk.org
<mailto: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
<https://git.openjdk.org/jdk/pull/13287#issuecomment-1494094776>
