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