On Tue, 6 May 2025 18:29:22 GMT, Leonid Mesnik <lmes...@openjdk.org> wrote:
>> This is a minor cleanup for the JVMTI `interp_only_mode` implementation
>> which includes the following changes:
>> - The `interp_only_mode` in `JavaThread` is represented with a counter
>> which is incremented and decremented. This is confusing because this value
>> should only take values `0` or `1`. Asserts are placed to make sure it is
>> never going out of bounds. The `interp_only_mode` in a `JavaThread` is
>> checked by the interpreter chunks which expect it to be an `integer`. This
>> cleanup has no intention to make it a boolean.
>> - The function `JvmtiThreadState::process_pending_interp_only()` does a
>> sync on the `JvmtiThreadState_lock` which is not really needed and is being
>> removed. It is called in a `VTMS` transition and so, can not clash with the
>> `SetEventNotificationMode` because it sets a `JvmtiVTMSTransitionDisabler`.
>>
>> Testing:
>> - TBD: Mach5 tiers 1-6
>
> src/hotspot/share/runtime/javaThread.hpp line 1177:
>
>> 1175: bool is_interp_only_mode() { return
>> (_interp_only_mode != 0); }
>> 1176: int get_interp_only_mode() { return
>> _interp_only_mode; }
>> 1177: int set_interp_only_mode(int val) { return _interp_only_mode
>> = val; }
>
> Ther get_interp_only_mode() /set_interp_only_mode(int val) also might be
> eliminated and replaced by set/clear instead.
Good suggestion, thanks. Updated, it is being tested now.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25060#discussion_r2076576748
