JDK-8308103 : Massive (up to ~30x) increase in C2 compilation time since JDK 17
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-05-15
  • Updated: 2023-10-06
  • Resolved: 2023-07-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 JDK 21 JDK 22
17.0.10-oracleFixed 21.0.2Fixed 22 b07Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
I noticed that attached JavaFuzzer generated test runs significantly longer with -Xcomp due to an increase in compilation time with C2.

Command line:
java -Xmx1G -Xcomp -Xbatch -XX:CompileOnly=Test -XX:MaxRAMPercentage=4.16667 Test

JDK 16
real	0m0,383s
user	0m0,326s
sys	0m0,029s

JDK 17+23 (contains JDK-8252372)
real	0m0,483s
user	0m0,421s
sys	0m0,032s

JDK 17+35
real	0m4,388s
user	0m4,310s
sys	0m0,056s

JDK 18 and later
real	0m10,312s
user	0m10,116s
sys	0m0,140s

With 5s test timeout it fails since JDK-8267988 in JDK 17 b27.
With 8s test timeout it fails since JDK-8272873 in JDK 18 b13.

We seem to spend most time in here:

#0  0x00007ffff70d9608 in Unique_Node_List::remove (n=<optimized out>, this=<optimized out>) at /oracle/valhalla/open/src/hotspot/share/opto/node.hpp:1590
#1  Unique_Node_List::remove (this=0x7fffac2ede30, n=0x7fffae517ae0) at /oracle/valhalla/open/src/hotspot/share/opto/node.cpp:2944
#2  0x00007ffff64ea758 in Compile::remove_modified_node (n=0x7fffae517ae0, this=0x7fffd47d4a30) at /oracle/valhalla/open/src/hotspot/share/opto/compile.cpp:1237
#3  Compile::remove_useless_node (this=0x7fffd47d4a30, dead=0x7fffae517ae0) at /oracle/valhalla/open/src/hotspot/share/opto/compile.cpp:374
#4  0x00007ffff71e9ceb in PhaseIterGVN::remove_globally_dead_node (this=this@entry=0x7fffd47d23f0, dead=dead@entry=0x7fffae517ae0) at /oracle/valhalla/open/src/hotspot/share/opto/phaseX.cpp:1442
#5  0x00007ffff71eae1e in PhaseIterGVN::remove_dead_node (dead=0x7fffae517ae0, this=0x7fffd47d23f0) at /oracle/valhalla/open/src/hotspot/share/opto/phaseX.hpp:507
#6  PhaseIterGVN::subsume_node (this=0x7fffd47d23f0, old=0x7fffae517ae0, nn=0x7fffaea5fae0) at /oracle/valhalla/open/src/hotspot/share/opto/phaseX.cpp:1491
#7  0x00007ffff6ee8878 in PhaseIdealLoop::try_sink_out_of_loop (n=<optimized out>, this=0x7fffd47d1720) at /oracle/valhalla/open/src/hotspot/share/opto/loopopts.cpp:1821
#8  PhaseIdealLoop::try_sink_out_of_loop (this=0x7fffd47d1720, n=<optimized out>) at /oracle/valhalla/open/src/hotspot/share/opto/loopopts.cpp:1763
#9  0x00007ffff6ee8ad5 in PhaseIdealLoop::split_if_with_blocks_post (this=0x7fffd47d1720, n=<optimized out>) at /oracle/valhalla/open/src/hotspot/share/opto/loopopts.cpp:1618
#10 0x00007ffff6ee9eb4 in PhaseIdealLoop::split_if_with_blocks_post (n=0x7fffac383d08, this=0x7fffd47d1720) at /oracle/valhalla/open/src/hotspot/share/opto/loopopts.cpp:2001
#11 PhaseIdealLoop::split_if_with_blocks (this=this@entry=0x7fffd47d1720, visited=..., nstack=...) at /oracle/valhalla/open/src/hotspot/share/opto/loopopts.cpp:2001
#12 0x00007ffff6eda5cf in PhaseIdealLoop::build_and_optimize (this=this@entry=0x7fffd47d1720) at /oracle/valhalla/open/src/hotspot/share/opto/loopnode.cpp:4517
#13 0x00007ffff650d674 in PhaseIdealLoop::PhaseIdealLoop (mode=LoopOptsDefault, igvn=..., this=0x7fffd47d1720) at /oracle/valhalla/open/src/hotspot/share/opto/loopnode.hpp:1101

Running with -XX:-SplitIfBlocks or explicitly disabling PhaseIdealLoop::try_sink_out_of_loop brings back old speed.

This also shows with -XX:+CITime:

JDK 16:
Accumulated compiler times
----------------------------------------------------------
  Total compilation time   :   0,293 s

JDK 21:
Accumulated compiler times
----------------------------------------------------------
  Total compilation time   :   9,049 s


Comments
Fix request [17u] I backport this for parity with 17.0.10-oracle. Acceptable, typical C2 risk. Clean backport. Test passes (including 8312440)SAP nightly testing passed.
05-10-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1827 Date: 2023-10-04 07:55:53 +0000
04-10-2023

Fix request [21u] I backport this for parity with 17.0.10-oracle. 21u should not fall back. The backport deferral was meant for 21, not 21u. After it being backported to 17.0.10-oracle, the risk of bringing it to 21u should be acceptable as this will have much less exposure. Clean backport. Test passes (including 8312440). SAP nightly testing passed.
27-09-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u/pull/199 Date: 2023-09-25 07:23:44 +0000
25-09-2023

Deferral Request (JDK 21): Only P1-P2 fixes are allowed at this point and the fix has a bug tail (see JDK-8312440).
24-07-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk21/pull/141 Date: 2023-07-20 06:26:59 +0000
20-07-2023

Changeset: c6ab9c29 Author: Roland Westrelin <roland@openjdk.org> Date: 2023-07-19 11:31:49 +0000 URL: https://git.openjdk.org/jdk/commit/c6ab9c2905203e1ec897b3404f9179ff975d0054
19-07-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14732 Date: 2023-06-30 13:23:38 +0000
30-06-2023

Targeting this for JDK 22 for now. Please update the fix version if the fix is ready in time for JDK 21.
15-05-2023

ILW = Increase in C2 compilation time (up to ~30x), with -Xcomp and JavaFuzzer generated test, -XX:-SplitIfBlocks or disable affected method from compilation = HLM = P3
15-05-2023

Roland, could you please have a look?
15-05-2023