On Thu, 18 Dec 2025 13:32:53 GMT, Fredrik Bredberg <[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
>
> src/hotspot/share/runtime/javaThread.hpp line 966:
>
>> 964: void exit_critical() {
>> 965: assert(Thread::current() == this, "this must be current thread");
>> 966: if (_jni_active_critical-- == 1) {
>
> Suggestion:
>
> if (--_jni_active_critical == 0) {
>
> I know my suggested line really does the same as yours, but this way I feel
> it's easier to see that we re-enable suspension when the number of active
> critical regions are down to 0. I.e. I prefer pre-decrement and compare to 0,
> vs. post-decrement and compare to 1.
I prefer to view the transitions on the current count as being zero and one,
rather than the post-count being one and zero.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28884#discussion_r2632659327
