JDK-8225217 : Backout: JDK-8224814: Remove dead JNIHandleBlock freelist code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-06-04
  • Updated: 2019-08-15
  • Resolved: 2019-06-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13 JDK 14
13 b24Fixed 14Fixed
Related Reports
Relates :  
JDK-8193222 - EnsureLocalCapacity() should maintain capacity requests through multiple calls
Relates :  
JDK-8224814 - Remove dead JNIHandleBlock freelist code
Description
The following was seen in a test run:

stdout: [WARNING: JNI local refs: 76, exceeds capacity: 75
    at jdk.internal.util.SystemProps$Raw.vmProperties(java.base/Native Method)
    at jdk.internal.util.SystemProps$Raw.cmdProperties(java.base/SystemProps.java:253)
    at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:55)
    at java.lang.System.initPhase1(java.base/System.java:1997)

while executing the runtime/jni/checked/TestCheckedEnsureLocalCapacity.java test.

The warning threshold is set to 32 for "limit < 32" and limit+32 in all other cases. So in this case the call to EnsureLocalCapacity has been made with a limit of 41 (there are 2 pre-existing live handles under graal) and we're actually creating more than 32 refs beyond that. We may have been creeping toward the end of that 32 buffer for some time and this change just put it over.
Comments
Updated ILW = MHM = P3 While we observed the issue through -Xcheck:jni the actual problem affects normal JNI code as well.
04-06-2019
The conclusion from discussions is that jni_DeleteLocalRef was broken by the removal of the free-list, and that the free-list was actually being used, but it was hard to see. The proposal is to backout JDK-8224814 for 13 and re-do in 14.
04-06-2019
Note, JVMCI may call JNIHandles::make_local() for NULL in some cases: http://hg.openjdk.java.net/jdk/jdk/file/8e31e083fe3c/src/hotspot/share/jvmci/jvmciEnv.cpp#l1360
04-06-2019
Reversing `is_in_reserved` part of JDK-8224814 changes fixed the issue: http://hg.openjdk.java.net/jdk/jdk/rev/47d928ba8733#l1.19
04-06-2019
Note, JVMCI used JNIHandleBlock: http://hg.openjdk.java.net/jdk/jdk/file/7c49133fc1bc/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#l72
04-06-2019
I reproduced issue in latest CI build by running runtime/jni/checked/TestCheckedEnsureLocalCapacity.java test with Graal and UrgentJVMCI: -javaoptions:'-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -XX:+TieredCompilation -XX:+EagerJVMCI -ea -esa' Test start failing after jdk-13-1207 which has next changesets: JDK-8224814 Remove dead JNIHandleBlock freelist code
04-06-2019
ILW = MHM = P4
04-06-2019
Update: running the test normally we have 35 out of the 41 requested handles (plus space for another 32 at least). Running the test under graal that changes slightly to 42 requested handles. So we should be bumping the limit a little, but we still have plenty of slack. So it must be local changes that are introducing all the additional JNI handles.
04-06-2019