JDK-8354727 : CompilationPolicy creates too many compiler threads when code cache space is scarce
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25,26
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-04-15
  • Updated: 2025-05-09
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 26
26Unresolved
Related Reports
Relates :  
JDK-8356000 - C1/C2-only modes use 2 compiler threads on low CPU count machines
Relates :  
JDK-8177899 - Tests fail due to code cache exhaustion on machines with many cores
Description
The test from 'tier1' set compiler/codecache/CheckSegmentedCodeCache.java failed on the Xeon(R) 6780E with log:
#make test TEST="compiler/codecache/CheckSegmentedCodeCache.java"
...
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
   jtreg:test/hotspot/jtreg/compiler/codecache/CheckSegmentedCodeCache.java
>>                                                       1     0     1     0     0 <<
==============================

# cat ./build/linux-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_codecache_CheckSegmentedCodeCache_java/compiler/codecache/CheckSegmentedCodeCache.jtr
...
Command line: [/workloads/openjdk_ws/jdk_mainline/build/linux-x86_64-server-release/images/jdk/bin/java -cp /workloads/openjdk_ws/jdk_mainline/build/linux-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_codecache_CheckSegmentedCodeCache_java/classes/0/compiler/codecache/CheckSegmentedCodeCache.d:/workloads/openjdk_ws/jdk_mainline/test/hotspot/jtreg/compiler/codecache:/workloads/openjdk_ws/jdk_mainline/build/linux-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_codecache_CheckSegmentedCodeCache_java/classes/0/test/lib:/workloads/openjdk_ws/jdk_mainline/test/lib:/workloads/openjdk_ws/jtreg/build/images/jtreg/lib/javatest.jar:/workloads/openjdk_ws/jtreg/build/images/jtreg/lib/jtreg.jar -XX:+SegmentedCodeCache -XX:ReservedCodeCacheSize=10M -XX:NonNMethodCodeHeapSize=6M -XX:ProfiledCodeHeapSize=5M -XX:NonProfiledCodeHeapSize=5M -version ]
[2025-04-15T22:38:08.104095879Z] Gathering output for process 261772
[2025-04-15T22:38:08.116838151Z] Waiting for completion for process 261772
[2025-04-15T22:38:08.117198087Z] Waiting for completion finished for process 261772
----------System.err:(19/1070)----------
 stdout: [Error occurred during initialization of VM
Not enough space in non-nmethod code heap to run VM: 6144K < 7312K
];
 stderr: []
 exitValue = 1

java.lang.RuntimeException: 'Invalid code heap sizes' missing from stdout/stderr
Comments
Thanks for the details, Vladimir. I'll target this to JDK 26.
09-05-2025
The call to 'Runtime.getRuntime().availableProcessors()" returns #288 i.e. all #288 cores available for java for target server.
22-04-2025
Similar to JDK-8177899 which I fixed years ago. Looks like the upper limit is not strict enough.
22-04-2025
ILW = Error during VM startup due to OOM in code cache (too many compiler threads created by ergonomics), with small code cache on system with many CPU cores, increase code cache size or set CICompilerCount manually = HLL = P4
22-04-2025
Okay, thanks for verifying. So it seems that CompilationPolicy::initialize does not correctly compute the number of compiler threads that should be used based on the available code cache space. [~vaivanov] Could you please check what os::active_processor_count() returns?
22-04-2025
With extra option "-XX:CICompilerCount=21" the test also passed on the Xeon 6780.
16-04-2025
Yes, you are right. The core count on the E-cores based server (Xeon 6780E) are 36: # ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:+PrintFlagsFinal -version |grep -i count int ActiveProcessorCount = -1 {product} {default} intx CICompilerCount = 36 {product} {ergonomic} while on the Xeon 8480+ it set to 21: # ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:+PrintFlagsFinal -version|grep -i count int ActiveProcessorCount = -1 {product} {default} intx CICompilerCount = 21 {product} {ergonomic}
16-04-2025
Maybe the CICompilerCount computed by CICompilerCountPerCPU is too high. Could you share the output of -XX:+PrintFlagsFinal on that machine? I get the same failure when manually setting -XX:CICompilerCount=36, i.e. when running java -XX:+SegmentedCodeCache -XX:ReservedCodeCacheSize=10M -XX:NonNMethodCodeHeapSize=6M -XX:ProfiledCodeHeapSize=5M -XX:NonProfiledCodeHeapSize=5M -XX:CICompilerCount=36 -version Error occurred during initialization of VM Not enough space in non-nmethod code heap to run VM: 6144K < 7312K But code in CompilationPolicy::initialize is supposed to set CICompilerCount to a low enough value such that the compiler buffers still fit in the code cache.
16-04-2025
[~vaivanov] Unfortunately, I don't have access to this particular architecture. Does the issue reproduce with SDE for you?
16-04-2025
Similar failure also reported for tests: compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java: Verify processing of options related to code heaps sizing. compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java: Verify that PrintCodeCache option print correct information. On the Xeon Xeon(R) 8480+ these tests reports 'passed'.
15-04-2025