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

[David Holmes]

On Wed, 20 Aug 2025 16:48:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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 one additional commit since the last revision:
> 
>   fixed comment.

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?

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

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