RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current thread is in native state [v4]
David Holmes
dholmes at openjdk.org
Mon May 20 03:53:03 UTC 2024
On Fri, 17 May 2024 22:31:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
>> The JvmtiTrace::safe_get_thread_name sometimes crashes when called while current thread is in native thread state.
>>
>> It happens when thread_name is set for tracing from jvmti functions.
>> See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnter.xsl#L649
>>
>> The setup is called and the thread name is used in tracing before the thread transition. There is no good location where this method could be called from vm thread_state only. Some functions like raw monitor enter/exit never transition in vm state. So sometimes it is needed to call this function from native thread state.
>>
>> The change should affect JVMTI trace mode only (-XX:TraceJVMTI).
>>
>> Verified by running jvmti/jdi/jdb tests with tracing enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>
> wrong thread state
Okay now I get it. Even once the function is made truly safe, we are always calling it from an unsafe state and so will get the default `Thread::name` response. So now, after any transition to the VM the name is read again to get a good value. This seems a good enhancement though I have to wonder if the apparent changing of the thread name in the tracing might cause problems. The tracing really needs to include a unique thread identifier.
Thanks
src/hotspot/share/prims/jvmtiEventController.cpp line 961:
> 959: JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent event_type, bool added) {
> 960: int *count_addr;
> 961:
Nit: this file doesn't need to be touched.
-------------
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19275#pullrequestreview-2065287663
PR Review Comment: https://git.openjdk.org/jdk/pull/19275#discussion_r1606209679
More information about the serviceability-dev
mailing list