On Wed, 18 Feb 2026 19:50:11 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 src/hotspot/share/prims/jvmtiThreadState.inline.hpp line 170: > 168: JvmtiThreadState* state = current->jvmti_thread_state(); > 169: > 170: if (state != nullptr && seen_interp_only_mode()) { // avoid > MutexLocker if possible Suggestion: if (state != nullptr && seen_interp_only_mode()) { // avoid holding JvmtiThreadState_lock if possible 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 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29800#discussion_r2835410588 PR Review Comment: https://git.openjdk.org/jdk/pull/29800#discussion_r2835414148
