This doesn't make sense for very small code cache sizes. A simple approach would be to limit the number of threads dependent on the code cache size.
A more complex approach is to allocate the compiler threads on demand depending on the compile queue lengths.
New implementation: -XX:+UseDynamicNumberOfCompilerThreads, active by default
It only starts 1 compiler thread per type (C1 and C2/Graal) at startup and the value determined by CICompilerCount is only used as an upper limit for compiler threads.
Additional threads get started depending on the compile queue sizes and the available memory. C2/Graal threads get started up to a number of half of their compile queue length. The start gets prevented when the operating system reports that the available memory is less than 200MB per C2/Graal compiler thread.
Similarly, C1 threads get started up to a number of one fourth of their compile queue length and the start gets prevented when the available memory is less than 100MB per C1 compiler thread.
Idle compiler threads die after some time (500 ms for C1, 100 ms for C2/Graal) in reverse order of their creation. One thread of each type is kept alive. It's also possible to keep all started ones alive by using the diagnostic flag -XX:-ReduceNumberOfCompilerThreads.
CompilerThread creation and death can be traced by activating the diagnostic flag -XX:+TraceCompilerThreads.
- csr for
-
JDK-8201235 Lazy allocation of compiler threads
- Closed
- relates to
-
JDK-8177899 Tests fail due to code cache exhaustion on machines with many cores
- Resolved
-
JDK-8213086 Compiler thread creation should be bounded by available space in memory and Code Cache
- Resolved
-
JDK-8303767 Identify and address the likely causes of glibc allocator fragmentation
- Open
-
JDK-8209670 CompilerThread releasing code buffer in destructor is unsafe
- Resolved
-
JDK-8202152 test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
- Resolved
-
JDK-8205499 C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads
- Resolved
-
JDK-8324983 Race in CompileBroker::possibly_add_compiler_threads
- Resolved
-
JDK-8209889 RedefineStress tests crash
- Resolved
-
JDK-8316661 CompilerThread leaks CodeBlob memory when dynamically stopping compiler thread in non-product
- Resolved
-
JDK-8213014 Crash in CompileBroker::make_thread due to OOM
- Resolved
-
JDK-8343205 CompileBroker::possibly_add_compiler_threads excessively polls available memory
- Resolved
-
JDK-8233193 Incorrect bailout from possibly_add_compiler_threads
- Resolved
-
JDK-8209671 With dynamic compiler threads the compiler-thread count is not maintained in a thread-safe manner
- Closed
-
JDK-8302264 Improve dynamic compiler threads creation
- Open