> 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
On Wed, 5 Apr 2023 08:48:04 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test tweaks
>
> Yes, I suspect having isAlive be synchronized would have had side-effects and
> maybe deadlock in some
On Wed, 5 Apr 2023 08:37:26 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 08:19:32 GMT, Aleksey Shipilev wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reformat comment block
>
> test/jdk/java/lang/Thread/IsAlive.java line 38:
>
>> 36: try {
>> 37:
On Mon, 3 Apr 2023 13:57:52 GMT, Aleksey Shipilev wrote:
>>> This looks interesting. I think it is time to rename eetop to
>>> javaThreadAddr ...
>>
>> Feel free to file a RFE but not as part of this PR. :)
>
>> > This looks interesting. I think it is time to rename eetop to
>> > javaThreadAdd
> 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
On Wed, 5 Apr 2023 07:23:03 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
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
> 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
On Tue, 4 Apr 2023 22:50:00 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
On Tue, 4 Apr 2023 09:22:29 GMT, Aleksey Shipilev wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Ensure HB relationship exists; additional explanatory comments
>
> src/java.base/share/classes/java/lang/Thread.java
On Mon, 3 Apr 2023 22:41:44 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 Mon, 3 Apr 2023 09:36:39 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
On Mon, 3 Apr 2023 12:32:35 GMT, David Holmes wrote:
> > This looks interesting. I think it is time to rename eetop to
> > javaThreadAddr ...
>
> Feel free to file a RFE but not as part of this PR. :)
Well, when this thing is considered in isolation, it changes the clear
`isAlive0()` call to
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
On Mon, 3 Apr 2023 09:36:39 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 Mon, 3 Apr 2023 11:39:43 GMT, Aleksey Shipilev wrote:
> This looks interesting. I think it is time to rename eetop to javaThreadAddr
> ...
Feel free to file a RFE but not as part of this PR. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494240185
On Mon, 3 Apr 2023 10:47:55 GMT, Quan Anh Mai wrote:
> May I ask if we need some form of memory order here? Maybe an aquiring load
> is necessary?
What is it that you think needs ordering?
-
PR Comment: https://git.openjdk.org/jdk/pull/13287#issuecomment-1494238641
On Mon, 3 Apr 2023 09:36:39 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 Mon, 3 Apr 2023 09:36:39 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 Mon, 3 Apr 2023 07:53:00 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comment from AlanB
>
> src/java.base/share/classes/java/lang/Thread.java line 231:
>
>> 229: /* Reserved for exclus
> 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
On Mon, 3 Apr 2023 07:17:59 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` pointer an
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
`
34 matches
Mail list logo
