RFR(L): 8002074: Support for AES on SPARC

Shrinivas Joshi shrinivas.joshi at oracle.com
Thu Nov 14 18:34:16 PST 2013


Hi,

Can I please request reviews for the following change? Target JDK 
release for this change would be the next update of JDK 8 / JDK 9.

Thanks,
-Shrinivas

RFE: https://bugs.openjdk.java.net/browse/JDK-8002074
Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/

Summary: This change adds intrinsics/stub routines support for 
single-block and multi-block (as used by Cipher Block Chaining mode) AES 
encryption and decryption operations on the SPARC platform. These 
intrinsics are available only when the application is configured to use 
SunJCE crypto provider. These stubs make use of efficient hardware AES 
instructions and thus offer significant performance improvements over 
JITed code. AES intrinsics are enabled by default on SPARC platforms 
that support AES instructions. They can be explicitly enabled or 
disabled on the command-line using UseAES and UseAESIntrinsics JVM flags.

Summary of source code changes:
    * src/cpu/sparc/vm/assembler_sparc.hpp
       - Adds support for all 3-operand and 4-operand SPARC AES 
instructions. Also adds support for floating-point XOR (FXORs/FXORd) 
instructions. FXOR instructions are used in the AES stub routines
    * src/cpu/sparc/vm/stubGenerator_sparc.cpp
       - Defines stubs for single-block and multi-block AES encryption 
and decryption routines supporting all key sizes (128-bit, 192-bit and 
256-bit).
       - Current SPARC AES decryption instructions are not compatible 
with SunJCE expanded decryption key format. Thus decryption stubs read 
the original key (passed as an input parameter) and perform decryption 
key expansion using hardware instructions.
       - Multi-block decryption stub can perform decryption for 2 * 
16-byte blocks at a time.
       - Encryption stubs use SunJCE expanded encryption key as their is 
no incompatibility issue between SPARC AES encryption instructions and 
SunJCE expanded encryption keys.
    * src/cpu/sparc/vm/sparc.ad, src/cpu/x86/vm/x86.ad and 
src/share/vm/opto/matcher.hpp
       - The additional original key array reference parameter is 
required only on the SPARC platform. This code guards it from being 
passed to the x86 AES stub routines.
    * src/cpu/sparc/vm/vm_version_sparc.cpp, 
src/cpu/sparc/vm/vm_version_sparc.hpp and 
src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp
       - Detect AES capabilities of the underlying CPU.
       - Enable UseAES and UseAESIntrinsics flags if the underlying CPU 
supports AES instructions and neither of them is explicitly disabled on 
the command-line. Generate warning message if either of these flags are 
enabled on the command-line whereas the underlying CPU does not support 
AES instructions.
    * src/share/vm/classfile/vmSymbols.hpp
       - Fix for "8012900: CICO ignores AAD in GCM mode" changes return 
type of com.sun.crypto.provider.CipherBlockChaining.encrypt() and 
com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to int. 
Method signature in intrinsics definition had to be changed accordingly.
    * src/share/vm/opto/library_call.cpp
       - Adds a new method to read 'lastKey' field of 
com.sun.crypto.provider.AESCrypt class which holds the original key.
       - Passes additional input parameter, original key array 
reference, to the AES stubs only on the SPARC platform.
       - Addresses change in return value from 'void' to 'int' in case 
of multi-block CBC stubs.
    * src/share/vm/opto/runtime.cpp
       - Reads the additional input parameter (original key reference) 
only on SPARC platform.
       - Addresses change in return value from 'void' to 'int' in case 
of multi-block CBC stubs.
    * hotspot/test/compiler/7184394/TestAESMain.java
       - This test case was contributed as part of the x86 AES 
intrinsics work by Tom Deneau @AMD. Fixed incorrect nano-second to 
milli-second conversion code. Added warm-up phase since this test case 
can also be used for performance testing.

Testing: jtreg, ctw, nsk and JPRT


More information about the hotspot-compiler-dev mailing list