Proposal for small experimental change to compiler thread calculation.

[Mat Carter]

We've been looking at compiler queue load, both under dynamic and static configurations and added jdk.CompilerQueueUtilization to the JFR logging to help with this.

There's much discussion in JBS ([1], [2] and [3] amongst others) and on the mailinglists regarding 1 vs 2 queues, shared threads vs dedicated and the benefits/tradeoffs of dynamic compiler threads.

Our proposal is to allow the 1:2 ratio (c1:c2) to be overridden on the command line with a goal to allow experimentation that might help either solidify the rational around the current settings or set us on a new path to make some changes.  Further it could allow developers to fine tune the ratio for their workload specific needs.

Something like -XX:CICompilerThreadRatio="2:3" (default is "1:2" which matches the current settings)

Note that the math to calculate the allocation of CICompilerCounts to C1 and C2 would remain integer, ensuring that the default ratio of 1:2 allocates the same number of threads to C1 and C2 as it does today.

Other than adding a new command line option, the only change would be in the initialize method in src/hotspot/share/compiler/compilationPolicy.cpp

There's also a thought on setting the compiler threads explicitly that we're happy to table until later: -XX:CICompilerThreadCounts="3:4"; in this case we'd compute CICompilerCounts as the sum of C1 and C2 threads.

Thoughts and questions appreciated, thanks in advance
Mat

[1] https://bugs.openjdk.org/browse/JDK-8134507
[2] https://bugs.openjdk.org/browse/JDK-8198756
[3] https://bugs.openjdk.org/browse/JDK-8302264
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240703/a5b4b41c/attachment.htm>