-
Bug
-
Resolution: Duplicate
-
P2
-
9, 10
In 9b116 SPECjvm2008.sparse-large regressed by about 10% compared to 9b115 on x64.
Analysis (see comments) showed that this is some bad interaction between some compiler optimization and the changes to the concurrent marking cycle.
In particular, in 9b116 the work done during marking has been split into two concurrent phases, marking as usual (before the Remark phase), and calculating live data information (after Remark and before Cleanup).
In general, this decreased the length of concurrent cycles significantly. Now, this benchmark seems to starve the CPU the marking (and the control) threads get. Now since we have some additional work to do (previously Remark and Cleanup basically occur back-to-back so for some reason this is "okay"), this lengthens the concurrent phase and decreases G1 performance significantly.
This problem goes away with -XX:+UseCountedLoopSafepoints.
Analysis (see comments) showed that this is some bad interaction between some compiler optimization and the changes to the concurrent marking cycle.
In particular, in 9b116 the work done during marking has been split into two concurrent phases, marking as usual (before the Remark phase), and calculating live data information (after Remark and before Cleanup).
In general, this decreased the length of concurrent cycles significantly. Now, this benchmark seems to starve the CPU the marking (and the control) threads get. Now since we have some additional work to do (previously Remark and Cleanup basically occur back-to-back so for some reason this is "okay"), this lengthens the concurrent phase and decreases G1 performance significantly.
This problem goes away with -XX:+UseCountedLoopSafepoints.
- duplicates
-
JDK-8186027 C2: loop strip mining
-
- Resolved
-
- relates to
-
-
- Resolved
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Resolved
-