RFR: 8373839: Disable JVM TI suspension during JNI critical regions [v2]

Patricio Chilano Mateo pchilanomate at openjdk.org
Fri Dec 19 11:22:37 UTC 2025


On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> David Holmes has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Delay suspender whilst target is in-critical
>  - Revert "8373839: Disable JVM TI suspension during JNI critical regions"
>    
>    This reverts commit 7723275e4495cc1f514c531afe752210209617cc.

src/hotspot/share/runtime/suspendResumeManager.cpp line 64:

> 62:   }
> 63:   void do_thread(Thread* thr) {
> 64:     assert(thr != Thread::current(), "must be");

I think the target can execute this operation.

src/hotspot/share/runtime/suspendResumeManager.cpp line 70:

> 68:     // hang here. There is no way to time-out and abort the suspend request because
> 69:     // the API does not allow for that - if a thread is live then it can be suspended.
> 70:     if (target->in_critical_atomic()) {

I think the target could also pick up this operation in the native->vm transition in `ReleasexxxCritical` or even with nesting in `GetxxxCritical`, so we should check target is not current thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634756340
PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2634771987


More information about the serviceability-dev mailing list