On Tue, 4 Apr 2023 22:50:00 GMT, David Holmes <[email protected]> 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:
>
> Fix copyright year
Actually I'm now thinking that introducing a synchronized method here could
cause compatibility issues. While people shouldn't generally synchronize on
Thread objects, if they do have threads locking themselves, whilst other
threads check isAlive(), then we could introduce problems.
Making the `eetop` field volatile instead would address that, but it would mean
that the VM also has to perform a volatile store (release_store) when setting
`eetop` to 0 during thread termination.
Or may be I should just let sleeping dogs lie and leave this as-is?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1496704371
