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.
8u40Fixed 9 b40Fixed
Related Reports
Relates :  
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.
Thank you very much, Sergey, for finding the cause. I will investigate it and may simple revert the change in lcm.cpp

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?

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

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

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

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