RFR: 8378194: Protect process_pending_interp_only() work with JvmtiThreadState_lock

Alex Menkov amenkov at openjdk.org
Fri Feb 20 23:01:44 UTC 2026


On Wed, 18 Feb 2026 19:50:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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


More information about the serviceability-dev mailing list