Bug ID: JDK-8072434 JDK-8064457: introduces performance regressions in 9-b47

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: 9

Priority: P2
Status: Closed
Resolution: Fixed
OS: linux_oracle_6.0,solaris_11
CPU: x86_64,sparc_64

Submitted: 2015-02-03
Updated: 2017-08-17
Resolved: 2015-02-06

JDK 9
9 b52Fixed

Performance measurement of 9-b47 shows 2-8% performance regressions across a broad range of benchmarks. Solaris-Sparc, Linux-x64, and Solaris-x64 show the most impact.

Using a subset of benchmarks: 
    - javacjdk7 across the 3 platforms ~ to check cross platform effect,
    - SPECjvm2008-MPEG and -Serial on Solaris-Sparc only.

I ran a quick check of the before and after builds (provided by Coleen) for the integration of 
JDK-8064457 -- Introduce compressed oops mode "disjoint base" and improve compressed heap handling.

Those results show similar regression levels on the benchmark subset.

I've started two sets of measurements... (1) A full coverage run of 9-b47 with the new fix in place. When this is complete, we'll compare it to the original 9-b47 results that identified the regressions. This will help identify what has been resolved by the fix. However, that will leave an understanding gap a particular regression only recovers partially. (2) A full coverage run of the before- and after-integration builds of the original coop change This comparison will give us an indication of how much of each regression was due to the original change, which will help us better understand whether the new fix is recovering the expected amounts. All this will take awhile to run, but should have the results to start looking at by Monday.
06-02-2015
Thanks for the info... We'd still need either: - 9-b47 equivalent build with the change backed out, or - 9-b47 equivalent build with the fix added. A post-9-b47 build will have other changes that we can't have fin place or a 9-b47 performance measurement.
04-02-2015
Hi, I don't know about your policies, but I posted a fix, maybe testing with this is more easy? http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017039.html Best regards, Goetz.
04-02-2015
Coleen, We are going to need a 9-b47 equivalent build with this change backed out so that we can assess what other performance regressions may be in the build (not caused by this change). We'll need that fairly soon. Thx!
04-02-2015
The code before your change also tried to place the CompressedClassSpace above the heap so that it could be decoded without a base, but still managed to get zero based for 30G. There appears to be a difference in this calculation then. This setting CompressedClassSpace was because of a regression in nashorn performance benchmark in bug https://bugs.openjdk.java.net/browse/JDK-8024927 (which I'm trying to see why it's not open).
04-02-2015
That's because CompressedClassSpace+30G+HeapBaseMinAddress > 32G. If you set HeapBaseMinAddress=2G it works, because that forces the heap on that boundary. It was required that the code leaves space to place the CompressedClassSpace above the heap (virtualspace.cpp:510). I would like to change that. Best regards, Goetz.
04-02-2015
Coleen asked for the following from a machine the regression was measured on: Gathered from a T4-1 with 128GB using jdk9-b47.... # ./jdk9-b47/bin/java -XX:+PrintCommandLineFlags -version -XX:InitialHeapSize=2139095040 -XX:MaxHeapSize=27913093120 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b47) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b47, mixed mode) Gathered from an x64 with 256GB using jdk9-b37 .... # ./jdk9-b47/bin/java -XX:+PrintCommandLineFlags -version -XX:InitialHeapSize=2147483648 -XX:MaxHeapSize=32210157568 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b47) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b47, mixed mode)
04-02-2015
That would seem to line-up with why we also see a SPECjbb2005-Tuned regression. That benchmark doesn't rely of ergo heap sizing, it explicitly sizes the heap. -server -Xmx30g -Xms30g -Xmn26g -XX:+AggressiveOpts -XX:+UseNUMA
03-02-2015
The Heap size is based on ergonomics in this experiment with a machine 256G Memory. It looks like -Xmx30g gives compressed oops disjoint mode with the Goetz change and give zero based with the previous version.
03-02-2015
It looks like we're now getting disjoint heap based rather than zero based compressed oops. After build 2015-02-02 23:48:37 [AG][53359] ["java" -server -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version -cp "/aurora/sandbox/refworkload/applications/hello/j2se" hw] 2015-02-02 23:48:37 [AG][53359] [] 2015-02-02 23:48:37 [AG][53359] [Stdout:] 2015-02-02 23:48:38 [AG][53359] [] 2015-02-02 23:48:38 [AG][53359] [Protected page at the reserved heap base: 0x0000001000000000 / 4194304 bytes] 2015-02-02 23:48:38 [AG][53359] [] 2015-02-02 23:48:38 [AG][53359] [heap address: 0x0000001000400000, size: 26620 MB, Compressed Oops mode: Non-zero disjoint base: 0x0000001000000000, Oop shift amount: 3] 2015-02-02 23:48:38 [AG][53359] [] 2015-02-02 23:48:38 [AG][53359] [Narrow klass base: 0x0000001680000000, Narrow klass shift: 0] 2015-02-02 23:48:38 [AG][53359] [Compressed class space size: 1073741824 Address: 0x0000001680000000 Req Addr: 0x0000001680000000] 2015-02-02 23:48:38 [AG][53359] [] 2015-02-02 23:48:38 [AG][53359] [Stderr:] 2015-02-02 23:48:38 [AG][53359] [java version "1.9.0-internal"] 2015-02-02 23:48:38 [AG][53359] [Java(TM) SE Runtime Environment (build 1.9.0-internal-20150105230931.cphillim.jdk9-goetz-compr-b00)] 2015-02-02 23:48:38 [AG][53359] [Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-20150105230931.cphillim.jdk9-goetz-compr-b00, mixed mode)] 2015-02-02 23:48:38 [AG][53359] [Refworkload terminated due to verification failure of component j2se] unset LD_PRELOAD refworkload ended with exit code 0 2015-02-02 23:48:38 [AG][53359] [Refworkload is over] Before build 2015-02-02 23:49:38 [AG][56323] ["java" -server -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version -cp "/aurora/sandbox/refworkload/applications/hello/j2se" hw] 2015-02-02 23:49:38 [AG][56323] [] 2015-02-02 23:49:38 [AG][56323] [Stdout:] 2015-02-02 23:49:38 [AG][56323] [] 2015-02-02 23:49:38 [AG][56323] [heap address: 0x0000000180400000, size: 26620 MB, Compressed Oops mode: Zero based, Oop shift amount: 3] 2015-02-02 23:49:38 [AG][56323] [] 2015-02-02 23:49:38 [AG][56323] [Narrow klass base: 0x0000000800000000, Narrow klass shift: 0] 2015-02-02 23:49:38 [AG][56323] [Compressed class space size: 1073741824 Address: 0x0000000800000000 Req Addr: 0x0000000800000000] 2015-02-02 23:49:38 [AG][56323] [] 2015-02-02 23:49:38 [AG][56323] [Stderr:] 2015-02-02 23:49:38 [AG][56323] [java version "1.9.0-internal"] 2015-02-02 23:49:38 [AG][56323] [Java(TM) SE Runtime Environment (build 1.9.0-internal-20150105122749.mtobiass.hs-rt-b00)] 2015-02-02 23:49:38 [AG][56323] [Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-20150105122749.mtobiass.hs-rt-b00, mixed mode)] 2015-02-02 23:49:39 [AG][56323] [Refworkload terminated due to verification failure of component j2se] unset LD_PRELOAD refworkload ended with exit code 0 2015-02-02 23:49:39 [AG][56323] [Refworkload is over]
03-02-2015