RFR: 8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status
David Holmes
dholmes at openjdk.java.net
Tue Aug 3 06:42:30 UTC 2021
On Tue, 3 Aug 2021 06:11:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> src/hotspot/share/services/threadService.cpp line 879:
>>
>>> 877: // If thread is still attaching then threadObj will be NULL.
>>> 878: _thread_status = threadObj == NULL ? JavaThreadStatus::NEW
>>> 879: : java_lang_Thread::get_thread_status(threadObj);
>>
>> I like the use of `JavaThreadStatus::NEW` here.
>>
>> Since L867 creates the _threadObj OopHandle, do you want to change both
>> uses of `threadObj` to `_threadObj()`? Is that still how we fetch the oop from
>> an OopHandle? Or even use `threadObj()`... Then we don't have to reason
>> about whether the `threadObj` oop is still good...
>
> I was thinking about the same. If we always use _threadObj() then there is no need to make sure the threadObj is still valid.
I'm not quite sure what point is being made here. We don't have to do anything to "make sure the threadObj is still valid" as we don't have any code here that could expose a "naked oop". We only need/want to use a handle when we have to ensure the oop is preserved across calls. That is not the case here.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4921
More information about the serviceability-dev
mailing list