JDK-8264903 : 2-3x slowdown when executing with -Xcomp after JDK-8219555
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2021-04-08
  • Updated: 2021-04-13
  • Resolved: 2021-04-13
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
17Resolved
Related Reports
Relates :  
Description
Seeing a considerable increase in execution time of JCK runtime testsuite with VM Options '-Xcomp -Xbatch'.
As compared to JDK17b12 (approx. 2h30m), execution time is almost doubled for JDK17b13 (approx. 5h) with these VM options.
*Please note* without these VM options, the execution time is same for both JDK17b12 & JCK17b13 i.e. approx. 1hr.

Comments
Igor said: "I disabled it because ���already profiled��� with Xcomp means 0 invocations. So we would not compile a method at level 3 if it���s in the queue, we would immediately change its level to 2." I.e. -Xcomp works as intended now and the slowdown is expected. I'm closing this as "Not an Issue".
13-04-2021

So the question is: Can we live with a 2-3x slowdown with -Xcomp or should we revert that change? [~iveresov], what do you think?
13-04-2021

I've narrowed it down to JDK-8219555. time 968/bin/java -Xcomp -version java version "17-ea" 2021-09-14 LTS Java(TM) SE Runtime Environment (build 17-ea+13-LTS-968) Java HotSpot(TM) 64-Bit Server VM (build 17-ea+13-LTS-968, compiled mode, sharing) real 0m0,298s user 0m0,252s sys 0m0,038s time 969/bin/java -Xcomp -version java version "17-ea" 2021-09-14 LTS Java(TM) SE Runtime Environment (build 17-ea+13-LTS-969) Java HotSpot(TM) 64-Bit Server VM (build 17-ea+13-LTS-969, compiled mode, sharing) real 0m0,533s user 0m0,529s sys 0m0,010s This is the problematic change: https://github.com/openjdk/jdk/commit/1f9ed905#diff-61e5ea4a1005ac734363813040f72b1d8cacabec5003c330d676e9152acf4268R679 It disabled switching the compilation level to CompLevel_limited_profile instead of using CompLevel_full_profile if the method is already fully profiled (and -Xcomp is used).
13-04-2021

ILW = Performance regression, with -Xcomp, no workaround but remove -Xcomp = HLM = P3
12-04-2021

Changes that went into JDK 17 b13: https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20JDK%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%2217%22%20AND%20component%20%3D%20hotspot%20AND%20%22Resolved%20In%20Build%22%20%3D%20b13%20AND%20Subcomponent%20%3D%20compiler%20ORDER%20BY%20resolved%20DESC
08-04-2021