JDK-8354727 : CompilationPolicy creates too many compiler threads when code cache space is scarce
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 23,25,26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-04-15
  • Updated: 2025-07-03
  • Resolved: 2025-06-25
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
26 b04Fixed
Related Reports
Causes :  
JDK-8311248 - Refactor CodeCache::initialize_heaps to simplify adding new CodeCache segments
Causes :  
JDK-8360641 - TestCompilerCounts fails after 8354727
Duplicate :  
JDK-8359685 - Test stress/compiler/deoptimize/Test.java fails Out of space in CodeCache
Duplicate :  
JDK-8359659 - CompilationPolicy::initialize: fix calculation of compiler buffer size in the case of c2_only
Relates :  
JDK-8177899 - Tests fail due to code cache exhaustion on machines with many cores
Relates :  
JDK-8360641 - TestCompilerCounts fails after 8354727
Relates :  
JDK-8356000 - C1/C2-only modes use 2 compiler threads on low CPU count machines
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 Manuel, see also JDK-8360641 for this.
26-06-2025
[~mbaesken], you are right. I see the same thing. I'll look into it further.
26-06-2025
Hi , now the test compiler/arguments/TestCompilerCounts.java fails on multiple (all ?) platforms. The jtr file contains : java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value I reverted your change and the new error is gone. Could you please check ?
26-06-2025
Changeset: f2ef8097 Branch: master Author: Manuel Hässig <mhaessig@openjdk.org> Date: 2025-06-25 13:00:08 +0000 URL: https://git.openjdk.org/jdk/commit/f2ef809719cbb14f90a0a5f673e10e7c74fa0f45
25-06-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25872 Date: 2025-06-18 13:11:53 +0000
18-06-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25830 Date: 2025-06-16 13:10:34 +0000
17-06-2025
[~shade], I filed JDK-8359659 for your fix, since the fix for this issue does not require me to touch compilationPolicy.cpp.
16-06-2025
A pull request was submitted for review. Branch: pr/25791 URL: https://git.openjdk.org/jdk/pull/25770 Date: 2025-06-12 07:19:40 +0000
13-06-2025
JDK-8311248 refactored CodeCache::initialize_heap() and introduced a new validation that checks that the NonNMethodCodeHeap does not require more memory than specified with -XX:NonNMethodCodeHeapSize or otherwise available within the RequiedCodeCacheSize. In this specific case, the commandline passes -XX:NonNMethodCodeHeapSize=6M. But since the calculation of the number of compiler threads uses the RequiredCodeCacheSize as reference, the very large core count of 288 causes more compiler threads than can fit in the NonNMethodCodeHeapSize of 6MiB.
11-06-2025
Please also take in this (reversed) hunk, if you are doing the fix in this area: https://github.com/openjdk/jdk/pull/24972/commits/c43b18a6681acb541be1b3bdadbd635070a2d58d
04-06-2025
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