Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8261607

SA attach is exceeding JNI Local Refs capacity

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 17
    • Fix Version/s: 17
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b10

      Description

      If you run the ClhsdbFindPC test with -Xcheck:jni, you will see warnings like
       the following in the log:

      WARNING: JNI local refs: 33, exceeds capacity: 32
      at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(jdk.hotspot.agent@17-internal/Native Method)
      at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(jdk.hotspot.agent@17-internal/LinuxDebuggerLocal.java:355)
      - locked <0x00000000891ed9d8> (a sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal)
      at sun.jvm.hotspot.HotSpotAgent.attachDebugger(jdk.hotspot.agent@17-internal/HotSpotAgent.java:645)
      at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(jdk.hotspot.agent@17-internal/HotSpotAgent.java:583)
      at sun.jvm.hotspot.HotSpotAgent.setupDebugger(jdk.hotspot.agent@17-internal/HotSpotAgent.java:360)
      at sun.jvm.hotspot.HotSpotAgent.go(jdk.hotspot.agent@17-internal/HotSpotAgent.java:329)
      at sun.jvm.hotspot.HotSpotAgent.attach(jdk.hotspot.agent@17-internal/HotSpotAgent.java:155)
      - locked <0x00000000891e5d08> (a sun.jvm.hotspot.HotSpotAgent)
      at sun.jvm.hotspot.CLHSDB.attachDebugger(jdk.hotspot.agent@17-internal/CLHSDB.java:202)
      at sun.jvm.hotspot.CLHSDB.run(jdk.hotspot.agent@17-internal/CLHSDB.java:63)
      at sun.jvm.hotspot.CLHSDB.main(jdk.hotspot.agent@17-internal/CLHSDB.java:40)
      at sun.jvm.hotspot.SALauncher.runCLHSDB(jdk.hotspot.agent@17-internal/SALauncher.java:280)
      at sun.jvm.hotspot.SALauncher$$Lambda$1/0x0000000801001800.accept(jdk.hotspot.agent@17-internal/Unknown Source)
      at sun.jvm.hotspot.SALauncher.main(jdk.hotspot.agent@17-internal/SALauncher.java:483)

      The culprit seems to be fillThreadsAndLoadObjects(), which is called by attach0(). It allocates localrefs in a loop that is iterated through once per thread, and there is no releasing of these localrefs at the bottom of the loop, so it's no surprise that the capacity is being exceeded.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              cjplummer Chris Plummer
              Reporter:
              cjplummer Chris Plummer
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: