On Wed, 13 Aug 2025 15:08:55 GMT, Leonid Mesnik <[email protected]> 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
