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

JVM should not switch hotspot JIT off forever if CodeCacheSize limit is reached

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 7u65
    • Fix Version/s: None
    • Component/s: hotspot
    • Subcomponent:
    • CPU:
      x86_64
    • OS:
      linux_redhat_5.0
    • Verification:
      Verified

      Description

      FULL PRODUCT VERSION :


      A DESCRIPTION OF THE PROBLEM :
      1.7 JVM's (starting with Java 1.7.0_4) set ReservedCodeCacheSize option to the default value of 48MB. Once the Code Cache size reaches this limit, JVM switches the hotspot off *forever*.

      This results in the immediate performance decrease for all not yet "compiled" code and gradual "slow" performance decrease for already "compiled" code which was "too long" time in the cache and is removed from cache later.

      Unfortunately there is no way back - once the JVM decides to switch to the interpreted mode, it never switches back even if the CodeCache memory is freed again.

      See also
      http://www.jroller.com/andyl/entry/switching_jvm_options_at_runtime
      https://bugs.eclipse.org/bugs/show_bug.cgi?id=459267
      http://blogs.atlassian.com/2012/05/codecache-is-full-compiler-has-been-disabled/

      THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

      THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

      REGRESSION. Last worked in version 6u45

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Start Eclipse JVM with small code cache limit, for example -XX:ReservedCodeCacheSize=20M. Do some work, run full build etc.
      Open jconsole and observe the memory pool "Code Cache". Before it reaches the limit, the pool size grows and shrinks, but as soon as it hits the upper limit, it always shrinks and never grows again - because no hotspot compilation happens anymore. After the code cache limit is reached, Eclipse starts to behave very slow - performance degrades with the time.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      I would expect that once the code cache limit is reached, the JVM does not switch the hotsot compilation off but just releases the cached memory. Another possibility would be that if the hotspot is switched off, it will be switched on as soon as there is enough code cache memory released.
      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
      Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=

      REPRODUCIBILITY :
      This bug can be reproduced often.

      CUSTOMER SUBMITTED WORKAROUND :
      Start JVM with big code cache limit, like -XX:ReservedCodeCacheSize=256M.

        Issue Links

          Activity

          Hide
          aroy Abhijit Roy added a comment -
          Please check with JDK 8u40ea(https://jdk8.java.net/archive/8u40-b05.html) or 9ea(https://jdk9.java.net/). let us know if you still see the same problem and provide any stand alone test case/setup instructions to reproduce it.
          Show
          aroy Abhijit Roy added a comment - Please check with JDK 8u40ea( https://jdk8.java.net/archive/8u40-b05.html ) or 9ea( https://jdk9.java.net/ ). let us know if you still see the same problem and provide any stand alone test case/setup instructions to reproduce it.
          Hide
          twisti Christian Thalinger added a comment -
          Java heap and code cache are two different things. Your test will not show the issue.
          Show
          twisti Christian Thalinger added a comment - Java heap and code cache are two different things. Your test will not show the issue.
          Hide
          aroy Abhijit Roy added a comment -
          It is a duplicate issue of JDK-8051955. Therefore, closing this issue as closed/duplicate.
          Show
          aroy Abhijit Roy added a comment - It is a duplicate issue of JDK-8051955 . Therefore, closing this issue as closed/duplicate.

            People

            • Assignee:
              aroy Abhijit Roy
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: