-
Enhancement
-
Resolution: Unresolved
-
P4
-
9, 10
-
generic
-
generic
We use CompilerOracle through the CompileCommand in JMH. We use it a lot: every benchmark comes with a few compiler commands which forces/breaks inlining in key points. When we have lots of benchmarks in the single suite, all those compiler commands add up. Then, when Hotspot compiles the workload methods, it consults with CompilerOracle. CompilerOracle now uses the linear search to match the compile commands against the method names, and that search may take up to 10-20% of total compilation time when you we are dealing with thousands of compile commands. The overhead, obviously, grows linearly with the number of compile commands, and, by extension, the number of benchmarks in the suite (even if we don't run them at all!).
This affects the compile-time-sensitive benchmarks in the performance runs, and we can only partially mitigate that on JMH side (CODETOOLS-7901024), but after that our hands are tight, and the rest can only be fixed on VM side. At very least, search for the exact matches in a hash table, not linearly.
This affects the compile-time-sensitive benchmarks in the performance runs, and we can only partially mitigate that on JMH side (
- is blocked by
-
JDK-8046155 JEP 165: Compiler Control
- Closed
- relates to
-
JDK-8241557 Avoid cloning DirectiveSet at runtime if -XX:CompileCommand is set
- Open
-
JDK-8159999 Control flow in BasicMatcher::matches could be improved
- Closed
-
JDK-8065641 JEP-JDK-8046155: Compiler Control - Performance Plan
- Resolved
-
CODETOOLS-7901024 More compact CompilerHints match lines, trying to avoid linear search in CompilerOracle
- Closed