On Wed, 20 Aug 2025 16:48:56 GMT, Leonid Mesnik <[email protected]> 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
