JDK-8177899 : Tests fail due to code cache exhaustion on machines with many cores
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,9,10,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-03-31
  • Updated: 2021-01-13
  • Resolved: 2018-10-30
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 11 JDK 12
11.0.5-oracleFixed 12 b18Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  

fail on machine with a lot of cores

 stdout: [Error occurred during initialization of VM
Not enough space in non-nmethod code heap to run VM: 20480K < 21475K
 stderr: []
 exitValue = 1

Please note, tests failed on Intel Xeon hosts with -XX:UseAVX=3 
We have suspicious test failures like these in 8u on large machines, might make sense to backport.

Fix Request JDK11u The VM didn't come up on a SPARC machine due to too high upper limit of compiler threads leading to misconfigured code cache. Original change does not apply cleanly and needs manual resolution. JDK11u backport was reviewed: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001271.html We tested the backport in our nightly tests sucessfully.


This is still an issue (see JDK-8212727). Re-opening.

NAI after JDK-8198756

the easy fix would be to add -XX:CICompilerCount=2 to the affected tests. but we might also want to think about changing the default value of CICompilerCount to take code cache size into consideration and not just number of cpus.

ILW = Testbug (code heap size is set too low for VM to start up), only on systems with many cores, no workaround = MMH = P3

The machine has 256 cores and the VM therefore creates 36 compiler threads. Each compiler thread requires extra space in the code cache for temporary buffers: java -XX:+TieredCompilation -XX:TieredStopAtLevel=0 -XX:+SegmentedCodeCache -XX:+PrintCodeCache [...] CodeHeap 'non-nmethods': size=25396Kb used=20889Kb max_used=20889Kb free=4506Kb bounds [0x00007f89bdbca000, 0x00007f89bf03a000, 0x00007f89bf497000] total_blobs=358 nmethods=19 adapters=217 We require 20889Kb in the non-nmethods code heap but the VM is started with 20480Kb.

#> java -XX:InitialCodeCacheSize=4m -XX:ReservedCodeCacheSize=8m -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+160) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+160, mixed mode) #>java -XX:ReservedCodeCacheSize=8m -XX:InitialCodeCacheSize=4m -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+160) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+160, mixed mode)