JDK-8273297 : AES/GCM non-AVX512+VAES CPUs suffer after 8267125
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 18
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2021-09-02
  • Updated: 2022-03-17
  • Resolved: 2021-09-24
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 18
18 b17Fixed
Related Reports
Relates :  
JDK-8267125 - AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions
Relates :  
JDK-8283022 - com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java failing with -Xcomp after 8273297
Relates :  
JDK-8267125 - AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions
Relates :  
JDK-8274730 - AArch64: AES/GCM acceleration is broken by the fix for JDK-8273297
Relates :  
JDK-8275052 - AArch64: Severe AES/GCM slowdown on MacOS for short blocks
Relates :  
JDK-8274323 - compiler/codegen/aes/TestAESMain.java failed with "Error: invalid offset: -1434443640" after 8273297
Description
Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not support the new intrinsic. Tests run were crypto.full.AESGCMBench and crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.

The problem is each instance of GHASH allocates 96 extra longs for the AVX512+VAES intrinsic regardless if the intrinsic is used.  This extra table space should be allocated differently so that non-supporting CPUs do not suffer this penalty.  This issue also affects non-Intel CPUs too.
Comments
Changeset: 13e9ea9e Author: Smita Kamath <svkamath@openjdk.org> Committer: Anthony Scarpino <ascarpino@openjdk.org> Date: 2021-09-24 19:21:32 +0000 URL: https://git.openjdk.java.net/jdk/commit/13e9ea9e922030927775345b1abde1313a6ec03f
24-09-2021
Most likely solution is to have the intrinsic allocate the memory it needs. It may not be efficient allocate each intrinsic call, but a pointer could be passed back to the GHASH object with the allocated memory perhaps?
02-09-2021