On Fri, 20 Feb 2026 22:58:37 GMT, Alex Menkov <[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 > > src/hotspot/share/prims/jvmtiThreadState.inline.hpp line 175: > >> 173: assert(state->get_thread() == current, "sanity check"); >> 174: assert(!state->is_interp_only_mode(), "sanity check"); >> 175: JvmtiEventController::enter_interp_only_mode(state); > > I think it makes sense to add `assert(JvmtiThreadState_lock->is_locked()` in > `JvmtiEventController::enter_interp_only_mode` to avoid similar issues in the > future Good suggestion, thanks. Addressed now. Added assert to both `JvmtiThreadState::enter_interp_only_mode()` and `JvmtiThreadState::leave_interp_only_mode()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29800#discussion_r2835976881
