United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7041789 30% perf regression with c2/arm following 7017732
JDK-7041789 : 30% perf regression with c2/arm following 7017732

Details
Type:
Bug
Submit Date:
2011-05-04
Status:
Closed
Updated Date:
2011-08-02
Project Name:
JDK
Resolved Date:
2011-07-18
Component:
hotspot
OS:
linux
Sub-Component:
gc
CPU:
arm
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs21
Fixed Versions:
hs21 (b14)

Related Reports
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

Description
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            *
============================================================================

                                    

Comments
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.
                                     
2011-05-13
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.
                                     
2011-05-13
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2aa9ddbb9e60
                                     
2011-05-14



Hardware and Software, Engineered to Work Together