On Thu, 21 Aug 2025 18:27:29 GMT, Patricio Chilano Mateo
<[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?
>>
>> 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?
>
>> 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.
Agree with @pchilano, the only oop handling should be done before JRT_BLOCK.
And the part dealing with with `exception_exit` will be implemented separately
in the:
https://github.com/openjdk/jdk/pull/26886
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3212200933
