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

[Patricio Chilano Mateo]

On Thu, 21 Aug 2025 01:58:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To fix the actual, simple, problem of being in the wrong state, it seems to me that this earlier suggestion is far easier to understand:
> 
> ```
>   {
>     ThreadInVMfromJava __tiv(thread);
>     state = get_jvmti_thread_state(thread);
>   }
> ```
> 
> With the proposed deferral of the `get_jvmti_thread_state` and the deferred check for `is_interp_only_mode` I am left wondering if it is okay to call:
> 
> ```
> current_frame.interpreter_frame_result(&oop_result, &value);
> current_frame.interpreter_frame_expression_stack_size() > 0
> ```
> 
> if we may not be in interp_only mode?
> 
`InterpreterRuntime::post_method_exit` is only called from the interpreter, so the top frame should always be interpreted.


> If the concern is the overhead of `ThreadInVMfromJava` can't we cheat here and use a direct state change as we are going from one safepoint-unsafe state to another?
>
I think that once we transition to vm there is no point in going back to Java to then possibly transition back to vm. The only reason to delay the transition was to have the `result` Handle be created outside of the `JRT_BLOCK` scope, so that we are able to restore the return oop (if any) after the last safepoint. That means we could move `JRT_BLOCK` even further up, right after declaring the locals.

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

PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3211660186