Bug ID: JDK-8060252 JDK-7173584 compiler changes regress SPECjvm2008 on SPARC

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 9
9 b40Fixed

There is a 8% regression on specjvm2008:crypto.aes and 1.5% regression on specjvm2008:serial on SPARC caused by JDK-7173584. 

crypto.aes:
  before JDK-7173584: 2958.01 ops/m
  after JDK-7173584: 2305.47 ops/m
  current jdk9/jdk9:  2305.32 ops/m
  current jdk9/hs-comp: 2308.35 ops/m

serial:
  before JDK-7173584: 260.98 ops/m
  after JDK-7173584: 252.81 ops/m
  current jdk9/jdk9:  253.49 ops/m
  current jdk9/hs-comp:  253.93 ops/m

See the logs here:
 http://cr.openjdk.java.net/~shade/8060252/

[1] Current hs-comp is:
$ hg tip
changeset:   7208:2b1ea93ea45e
tag:         tip
user:        thartmann
date:        Mon Oct 13 12:30:37 2014 +0200
summary:     8046268: compiler/whitebox/ tests fail : must be osr_compiled

Performance returned back based on previous Aleksey's comment.
15-08-2017
Thanks for confirming, Aleksey.
22-10-2014
Confirmed, there is a comparable improvement: +8% on SPECjvm2008:crypto.*, and +1.5% on SPECjvm2008:serial.
22-10-2014
Thanks Roland, checking.
22-10-2014
The patch below appears to fix it. Can you confirm Aleksey? diff --git a/src/share/vm/opto/library_call.cpp b/src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp +++ b/src/share/vm/opto/library_call.cpp @@ -4611,6 +4611,8 @@ Node* dest_offset = argument(3); // type: int Node* length = argument(4); // type: int + AllocateArrayNode* alloc = tightly_coupled_allocation(dest, NULL); + // The following tests must be performed // (1) src and dest are arrays. // (2) src and dest arrays must have elements of the same BasicType @@ -4784,7 +4786,6 @@ return true; } - AllocateArrayNode* alloc = tightly_coupled_allocation(dest, NULL); ArrayCopyNode* ac = ArrayCopyNode::make(this, true, src, src_offset, dest, dest_offset, length, alloc != NULL, // Create LoadRange and LoadKlass nodes for use during macro expansion here // so the compiler has a chance to eliminate them: during macro expansion,
21-10-2014
Current hs-comp (includes the fix to JDK-8058746) still has the same issue, see the updated description. I have also fixed the benchmark mention: it is "crypto.aes", not "crypto.rsa".
14-10-2014
Unlikely, since the performance regression seems to be specific to SPARC. I would suspect something fishy with lowering the arraycopy macro node on SPARC. I can check the latest jdk9/hs-comp in the morning CET.
13-10-2014
Does the fix for JDK-8058746 help? Allocation elimination was broken for array copy case.
13-10-2014
ILW = H:Perf regression, M:Arraycopy is common: H:Unworkaroundable => P1
13-10-2014

Duplicate :	JDK-8058355 - SPECjvm2008-Serial performance regression on Solaris-SPARC starting with 9-b29
Relates :	JDK-8058746 - escape analysis special case code for array copy broken by 7173584
Relates :	JDK-8064703 - crash running specjvm98's javac following 8060252
Relates :	JDK-8058349 - SPECjbb2005 1.4% performance regression on Linux with 9-b29
Relates :	JDK-7173584 - Implement arraycopy as a macro node