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
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 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
11 matches
Mail list logo
