On Sat, 21 Feb 2026 08:58:47 GMT, Serguei Spitsyn <[email protected]> wrote:
>> The function `JvmtiThreadState::process_pending_interp_only()` should >> protect the check with `state->is_pending_interp_only_mode()` and call to >> `JvmtiEventController::enter_interp_only_mode(state)` with the >> `JvmtiThreadState_lock`. Some level of optimization with a check of >> `seen_interp_only_mode()` is used as the code path of the >> `process_pending_interp_only()` is hot. Then the `seen_interp_only_mode()` >> has to be set somewhat earlier when the `is_pending_interp_only_mode()` is >> set. >> This issue was discovered when in the work on the PR update of >> https://bugs.openjdk.org/browse/JDK-8373367 . >> >> Testing: >> - TBD: mach5 tiers 1-5 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: missed volatile keyword in the var definition Changes requested by lmesnik (Reviewer). src/hotspot/share/prims/jvmtiThreadState.hpp line 215: > 213: // It is cleared by EnterInterpOnlyModeClosure handshake. > 214: bool is_pending_interp_only_mode() { > 215: return AtomicAccess::load(&_pending_interp_only_mode); Does it matter to made `Atomic<bool> _pending_interp_only_mode ` ? Seems the AtomicAccess is converted to `Atomic<T>` anywhere in the hotspot. ------------- PR Review: https://git.openjdk.org/jdk/pull/29800#pullrequestreview-3835414218 PR Review Comment: https://git.openjdk.org/jdk/pull/29800#discussion_r2836003668
