RFR: 8378194: Protect process_pending_interp_only() work with JvmtiThreadState_lock [v3]

Leonid Mesnik lmesnik at openjdk.org
Sat Feb 21 09:10:09 UTC 2026


On Sat, 21 Feb 2026 08:58:47 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
>
> 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


More information about the serviceability-dev mailing list