RFR: 8356000: C1/C2-only modes use 2 compiler threads on low CPU count machines

Damon Fenacci dfenacci at openjdk.org
Mon May 5 07:26:45 UTC 2025


On Wed, 30 Apr 2025 19:00:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is an unfortunate limitation with default tiered policy that we would have at least 2 threads on 1 CPU machine: 1 thread for C1, and 1 thread for C2.
> 
> But if we select C1-only or C2-only modes, we _also_ get 2 compiler threads, for which we have no good reason. These threads would just step on each other toes. The fix changes the behavior for 1..3 CPU hosts in C1/C2-only configurations, by using 1 thread instead of 2 threads. The change for 1 CPU config is what we really need. The change in 2..3 CPU configs is an additional effect, but I think it is still good not to use 100%/66% of the CPUs in those configurations as well.
> 
> 
> $ for I in `seq 1 8`; do build/linux-x86_64-server-release/images/jdk/bin/java \
>   -XX:-TieredCompilation -XX:ActiveProcessorCount=${I} \
>   -XX:+PrintFlagsFinal 2>&1 | grep "CICompilerCount "; done
> 
> # Before
>      intx CICompilerCount                          = 2
>      intx CICompilerCount                          = 2
>      intx CICompilerCount                          = 2
>      intx CICompilerCount                          = 3
>      intx CICompilerCount                          = 3
>      intx CICompilerCount                          = 3
>      intx CICompilerCount                          = 3
>      intx CICompilerCount                          = 4
> 
> # After
>      intx CICompilerCount                          = 1
>      intx CICompilerCount                          = 1
>      intx CICompilerCount                          = 1
>      intx CICompilerCount                          = 3
>      intx CICompilerCount                          = 3
>      intx CICompilerCount                          = 3
>      intx CICompilerCount                          = 3
>      intx CICompilerCount                          = 4
> 
> 
> It is a minor bug in `CompilationPolicy::initialize`, but it gets in the way studying Leyden in tight CPU scenarios. 
> 
> Additional testing:
>  - [x] New regression test passes with the fix, fails without it
>  - [ ] GHA

Thanks @shipilev for fixing this (it might be a minor bug but still... inconsistent 🙂)

test/hotspot/jtreg/compiler/arguments/TestCompilerCounts.java line 64:

> 62:             ProcessBuilder pb = ProcessTools.createLimitedTestJavaProcessBuilder(args);
> 63:             OutputAnalyzer output = new OutputAnalyzer(pb.start());
> 64:             output.shouldHaveExitValue(0);

I was wondering if we should check the output as well, e.g. with a test that prints the actual number of compiler threads (like the one in the description, to make it a bit more like a regression test).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24972#pullrequestreview-2813980617
PR Review Comment: https://git.openjdk.org/jdk/pull/24972#discussion_r2072949819


More information about the hotspot-compiler-dev mailing list