RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4]
Patricio Chilano Mateo
pchilanomate at openjdk.org
Thu Aug 14 00:04:11 UTC 2025
On Wed, 13 Aug 2025 15:08:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
>> The method
>> get_jvmti_thread_state()
>> should be called only while thread is in vm state.
>>
>> The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state.
>>
>> The fix was found using jvmti stress agent and thus no additional regression test is required.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>
> - added _
> - wong phase
src/hotspot/share/prims/jvmtiExport.cpp line 1838:
> 1836: {
> 1837: ThreadInVMfromJava tiv(thread);
> 1838: state = get_jvmti_thread_state(thread);
The issue I see is that `get_jvmti_thread_state()` can safepoint for virtual threads (and now also for platform threads because of `~ThreadInVMfromJava`), which brings us back to the bug 8255452 was trying to fix: if there is a return oop at the top of the stack, it could become invalid if a GC occurs. I think we will have to unconditionally save the return value in case it's an oop, before doing anything else.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2274899453
More information about the serviceability-dev
mailing list