On Fri, 19 Dec 2025 06:16:28 GMT, David Holmes <[email protected]> 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
