On Thu, 21 Aug 2025 01:58:23 GMT, David Holmes <[email protected]> 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
