JDK-8262476 : Add filter to speed up CompileCommand lookup
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16,17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-02-26
  • Updated: 2021-03-30
  • Resolved: 2021-03-19
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 17
17 b15Fixed
Related Reports
Relates :  
JDK-8256508 - Improve CompileCommand flag
Description
While working on things related to JDK-8246402, I wrote a JMH that constantly loads new classes and creates a few instances of them in each iteration.
On my WS

16-b26:   451.955 �� 1.864  ops/s
16-b27:   394.893 �� 5.071  ops/s

Using perf top, I can see from b27 the test spends 5-7% of its time in CompilerOracle::has_option_value<double>
 even when the compilation has quieted down after the first few seconds of running.
I think this is related to https://bugs.openjdk.java.net/browse/JDK-8256508

   9.11%  [kernel]                 [k] read_hpet
   6.96%  libjvm.so                [.] CompilerOracle::has_option_value<double>
   4.01%  libjvm.so                [.] steal_work
   2.93%  [kernel]                 [k] do_syscall_64
   2.31%  libc-2.23.so             [.] vfprintf


The micro is here:

https://github.com/ericcaspole/jmh-jdk-microbenchmarks/blob/dyn-load-and-new/micros-jdk8/src/main/java/org/openjdk/bench/java/lang/DynamicLoading.java

Run it like:
$ numactl --membind=1 --cpunodebind=1 /opt/jdk-16-b27/bin/java -jar target/micros-jdk8-1.0-SNAPSHOT.jar DynamicLoading.loadAndSeveralNewInstance  -f 1 -i 8  -p instances=25 -p numberOfClasses=10  -jvmArgs "-XX:+PrintCompilation -XX:+UseParallelGC"

All that being said I dont know if other benchmarks see any regression from tihs one.
Comments
Changeset: 701fd9da Author: Nils Eliasson <neliasso@openjdk.org> Date: 2021-03-19 09:10:09 +0000 URL: https://git.openjdk.java.net/jdk/commit/701fd9da
19-03-2021
JMH adds a lot of inlining compilecommands. This causes a lot of extra time for the lookup of all the other commands that might not even have been added. Since the most common case is that no compilecommand is added - I will add a filter that can be quickly checked for a command type.
17-03-2021
There are 1216 option-matchers being traversed - most of them probably inlining related. They are all in the same list after the change. CompilerOracle::has_option_value would only have gone through the option ones before. I'll think about how to split them up.
15-03-2021
Nils, could you please have a look?
02-03-2021
ILW = Performance regression due to slow CompilerOracle::has_option_value, with microbenchmark, no known workaround = MMH = P3
02-03-2021