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

[David Holmes]

On Tue, 4 Apr 2023 22:50:00 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:
> 
>   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