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