RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4]

[Leonid Mesnik]

On Thu, 14 Aug 2025 17:56:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 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.
>
> Thank you @pchilano and @sspitsyn for finding and explaining the issue.
> I need some more time to understand how to better correctly preserve the result oop in post_method_exit before we can starting read jvmti_state.

I reviewed the logic and it seems, that `exception_exit` is not needed here. The 'post_method_exit' is called only when method exits normally. The `notice_unwind_due_to_exception`happens if method exit because of exception.
I added a regression test that demonstrate the problem. The upcall method is not handled correctly before this fix. 
Also, it means that result should be always valid and it is always needed to handle result. There is no way to avoid safepoints in this method even MethodExit is not enabled.
However, JNIHandle is needed for events only and shouldn't be created until events are enabled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2284151989