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

[David Holmes]

On Mon, 22 Dec 2025 21:30:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> 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.
> 
> Update: It looks like my suggestion above is not useful as the target thread can be suspended when it is in native and then try to enter a JNI critical section.

@sspitsyn The use of `is_disable_suspend` is what was originally proposed but it does not work as it does not do what might be expected. Further none of these suggestions deep in the handshake code deal with the problem that the thread requesting the suspend has to block as long as any target is "in critical". I cannot see a relatively simple solution to this, but rather we would need a new (and complex) protocol for trying to deal with this. One possible approach may be to use a Dekker-style dual check and also permit JNI-critical to be blocked if a suspend request is pending.

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3684317025