Bug ID: JDK-7041789 30% perf regression with c2/arm following 7017732

Versions (Unresolved/Resolved/Fixed)

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 7	JDK 8	Other
7Fixed	8Fixed	hs21Fixed

I noticed that I have a perf regression with the current hotspot code on c2/arm compared to measurements I did several weeks ago. So I went back in time and found that on the day I pushed c2/arm to hotspot repos, the perf problem already existed. I pinpointed the change that led to the regression to be:
 
changeset:   2226:c7f3d0b4570f
user:        never
date:        Fri Mar 18 16:00:34 2011 -0700
summary:     7017732: move static fields into Class to prepare for perm gen removal
 
Between this changeset and its parent, best execution time of the javac subtest of specjvm98 goes from ~10 seconds to ~20 seconds. If I run the javac test alone (rather than as the last test of the specjvm98 subtest series), best execution time is ~15 seconds. If I force JavaObjectsInPerm to true, execution time is back to ~10 seconds.
 
c2 JavaObjectsInPerm=false vs c2 JavaObjectsInPerm=true
 
============================================================================
t
  Benchmark         Samples        Mean     Stdev
  specjvm98               3       56.62      0.03
    compress              3       76.27      0.04
    javac                 3       19.16      0.06
    db                    3       24.79      0.02
    jack                  3       34.64      0.11
    mtrt                  3      162.04      0.03
    jess                  3       67.20      0.06
    mpegaudio             3      137.23      0.01
============================================================================
t2
  Benchmark         Samples        Mean     Stdev   %Diff    P   Significant
  specjvm98               3       74.95      0.00   32.37 0.002          Yes
    compress              3       80.06      0.00    4.96 0.188            *
    javac                 3       35.27      0.02   84.06 0.000          Yes
    db                    3       24.70      0.00   -0.39 0.803            *
    jack                  3       78.49      0.05  126.57 0.000          Yes
    mtrt                  3      177.45      0.01    9.51 0.018            *
    jess                  3       99.82      0.01   48.54 0.002          Yes
    mpegaudio             3      137.12      0.00   -0.08 0.884            *
============================================================================

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2aa9ddbb9e60

14-05-2011

EVALUATION During GC nmethods (compiled code) that have references into the young gen are scanned. The current test checks to see if a reference is into the perm gen. If it is not into the perm gen then the nmethod is marked as having a reference into the young gen. The fix is to implement a test that checks that a reference is into the young gen. The nmethods today have more references into the young gen because of objects that have been moved out of the perm gen and into the Java heap.

13-05-2011

SUGGESTED FIX Implement an is_scavengable() that accurately tests that a references is into the young generation. For G1 implement a conservative test that return true for all references with the exception of humongous objects. This conservative implementation for G1 is because G1 is logically generational and does not have a fixed young gen.

13-05-2011

Relates :	JDK-7048030 - is_scavengable changes causing compiler to embed more constants
Relates :	JDK-7047954 - VM crashes with assert(is_Mem()) failed: invalid node class