On Wed, 5 Apr 2023 06:56:57 GMT, Alan Bateman wrote:
>> Being a private field it won't appear in any javadoc that anyone is ever
>> likely to read. Only developers will see this (or need to see it) when they
>> read the source code.
>
> It's just a bit inconsistent with the other comments, no b
On Wed, 5 Apr 2023 04:37:27 GMT, David Holmes wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 235:
>>
>>> 233:and reset to zero when the thread terminates. A non-zero value
>>> indicates this thread
>>> 234:isAlive().
>>> 235: */
>>
>> Maybe JavaDocify this
On Wed, 5 Apr 2023 04:35:27 GMT, David Holmes wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 1846:
>>
>>> 1844: /**
>>> 1845: * Returns true if this thread is alive.
>>> 1846: * This method is non-final so it can be overridden.
>>
>> Suggestion:
>>
>> * Thi
On Wed, 5 Apr 2023 04:04:11 GMT, ExE Boss wrote:
>> David Holmes has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Switch from using synchronized to using a volatile eetop field
>> - Added Shipilev's test (with a small addition)
>
> src
On Wed, 5 Apr 2023 02:30:15 GMT, David Holmes 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` pointe
On Wed, 5 Apr 2023 02:30:15 GMT, David Holmes 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` pointe
On Wed, 5 Apr 2023 02:30:15 GMT, David Holmes 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` pointe
> 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`
> dir
