On Tue, 6 May 2025 08:29:36 GMT, Serguei Spitsyn <sspit...@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 increment and decremented. This is confusing because this value should 
> only take values `0` and `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

Changes requested by lmesnik (Reviewer).

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.

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

PR Review: https://git.openjdk.org/jdk/pull/25060#pullrequestreview-2819254877
PR Review Comment: https://git.openjdk.org/jdk/pull/25060#discussion_r2076039987

Reply via email to