RFR: 8305425: Thread.isAlive0 doesn't need to call into the VM [v2]
    David Holmes 
    dholmes at openjdk.org
       
    Mon Apr  3 22:41:45 UTC 2023
    
    
  
On Mon, 3 Apr 2023 09:36:39 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:
> 
>   Comment from AlanB
Simpler fix for the HB issue is to make alive() synchronized.
Not sure how Virtual Threads are supposed to act here.
> At very least we should add the comment that the field carries the native thread pointer ...
I can do that.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1495076660
    
    
More information about the hotspot-runtime-dev
mailing list