JDK-8209544 : AES encrypt performance regression in jdk11b11
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2018-08-15
  • Updated: 2022-01-05
  • Resolved: 2018-09-07
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 11 JDK 12
11.0.3Fixed 12 b11Fixed
Related Reports
Relates :  
JDK-8200303 - C2 should leverage profiling for lookupswitch/tableswitch
Relates :  
JDK-8211451 - ~2.5% regression on compression benchmark starting with 12-b11
Description
In jdk11b11 was introduces performance regression. 
up to -5% on Linux_x64

Guilty commit is: 
http://hg.openjdk.java.net/jdk/jdk11/rev/d84f06a0cae1


JMH options to execute: 
oracle.micro.benchmarks.crypto.small.AESBench.encrypt  -p algorithm=AES/ECB/NoPadding

Crypto microbenchmarks are available in Aurora "Standard Submit" 
under Benchmarks-> Micros -> Micros-Crypto
Comments
Fix Request This bug fixes a performance regression introduced by JDK-8200303 in 11. The fix tweaks c2 code generation. The fix was pushed in 12 in september. There was one follow up bug (a performance regression: JDK-8211451). I will request backport approval for this one as well. Patch applies cleanly.
17-12-2018
URL: http://hg.openjdk.java.net/jdk/jdk/rev/7e6b86eb7914 User: roland Date: 2018-09-07 07:45:07 +0000
07-09-2018
Thanks for verifying Sergey!
28-08-2018
I've checked and confirm that the patch removes regression.
20-08-2018
So the testcase from the open performance tests is: org.openjdk.bench.javax.crypto.small.AESBench.encrypt, right? perfasm reports that 70% of the time is spent in stubs (StubRoutines::aescrypt_encryptBlock) where UseSwitchProfiling makes no difference. 20+% is spent in com.sun.crypto.provider.CipherCore::doFinal which has a single lookupswitch in the hot code path. There's a difference in the code sequence generated: With -XX:-UseSwitchProfiling: 0x00007f9c3056ec50: cmp $0x7,%ecx ╭ 0x00007f9c3056ec53: je 0x00007f9c3056ee42 ;*lookupswitch {reexecute=0 rethrow=0 return_oop=0} With -XX:+UseSwitchProfiling: 0x00007f59a456ec52: add $0xfffffff9,%eax 0x00007f59a456ec55: cmp $0x1,%eax 0x00007f59a456ec58: jb 0x00007f59a456eeba ;*lookupswitch {reexecute=0 rethrow=0 return_oop=0} which is not as good. That seems to be the only difference. Attached patch tweaks the generated code for the sequence above so it's the same in both cases. Sergey, can you verify if the performance regression goes away?
17-08-2018
ILW = 5% performance regression, AES microbenchmark on x86, -XX:-UseSwitchProfiling = MMM = P3
16-08-2018
If use -XX:-UseSwitchProfiling there are no regression.
15-08-2018
Benchmarks are accessible here: http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ hg: http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks As for -XX:-UseSwitchProfiling - I'll check this.
15-08-2018
[~skuksenko] Is benchmark accessible outside Oracle? Is running with -XX:-UseSwitchProfiling restore performance?
15-08-2018