JDK-8059780 : SPECjvm2008-MPEG performance regressions on x64 platforms
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u40,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris,windows
  • CPU: x86_64
  • Submitted: 2014-10-06
  • Updated: 2017-08-08
  • Resolved: 2014-11-03
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 8 JDK 9
8u40Fixed 9 b40Fixed
Related Reports
Relates :  
Description
The SPECjvm2008-MPEG sub-benchmark shows a performance regression on all x64 platforms (linux, windows, solaris) with both the default parallel garbage collector and the G1 garbage collector.
Comments
Thank you very much, Sergey, for finding the cause. I will investigate it and may simple revert the change in lcm.cpp
24-10-2014

1. Making UseFPUForSpilling is on by default doesn't cause regression. Moreover, it masks the regression, because of turning it on on always show slightly higher scores than cases when FPUForSpilling is turned off (on all builds). 2. Wrapping superword.cpp modifications with UseNewCode shows that there is no impact to mpegaudio. The real culprit is modicatons in lcm.cpp: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/comparison/76913ad3cd41/src/share/vm/opto/lcm.cpp When I covered both places in lcm.cpp under UseNewCode (old version with 'map' vs new version with 'remove') - I found the regression. I didn't find generated code diff (too much code) - but would it be enough information for solving the problem?
24-10-2014

Several changes were made tin 8052081 which could affect performance. 1. -XX:+UseFPUForSpilling is on by default on CPUs with SSE4.2 (before it was under -XX:+AggressiveOpts). It is easy to check if ti the cause since the flag is product flag. 2. Changes to vectorization which is not under flag it should be visible only by analyzing compiled code. You we can instrument VM by guarding this new code with UseNewCode diagnostic flag: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/comparison/76913ad3cd41/src/share/vm/opto/superword.cpp
17-10-2014

regression caused by https://bugs.openjdk.java.net/browse/JDK-8052081 commit. Looking into generated code.
17-10-2014

Sergey, please investigate. This may be related to JDK-8056955 reported against JDK 9.
10-10-2014

Drops are large and notable at 3-5%. Applying initial ILW (med, high, high); P=2
07-10-2014