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.
I've not look deep into this issue yet but it seems the approach below can be
used to avoid suspends in JNI critical sections:
HandshakeOperation* HandshakeState::get_op_for_self(bool allow_suspend, bool
check_async_exception) {
assert(_handshakee == Thread::current(), "Must be called by self");
assert(_lock.owned_by_self(), "Lock must be held");
assert(allow_suspend || !check_async_exception, "invalid case");
#if INCLUDE_JVMTI
if (allow_suspend && _handshakee->is_disable_suspend()) {
<== !!!
// filter out suspend operations while JavaThread is in disable_suspend mode
allow_suspend = false;
}
#endif
if (!allow_suspend) {
return _queue.peek(no_suspend_no_async_exception_filter);
} else if (check_async_exception && !_async_exceptions_blocked) {
return _queue.peek();
} else {
return _queue.peek(no_async_exception_filter);
}
}
The `_handshakee->in_critical_atomic()` can be checked directly in the
`HandshakeState::get_op_for_self()` or the `_handshakee->is_disable_suspend()`
can be set instead.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684247689
