JEP 207: Leverage CPU Instructions to Improve SHA Performance on SPARC

AuthorJames Cheng
OwnerVladimir Kozlov
Created2014/06/06 20:35
Updated2014/10/06 22:14
TypeFeature
StatusClosed / Delivered
Componenthotspot / compiler
ScopeImplementation
Discussionhotspot dash dev at openjdk dot java dot net
EffortS
DurationS
Priority2
Reviewed byMikael Vidstedt, Vladimir Kozlov
Endorsed byMikael Vidstedt
Release8u40
Issue8046261

Summary

Improve SHA secure-hashing performance by adding C2 intrinsics for SPARC processors that have SHA instructions.

Motivation

SHA secure hashing is widely used in security applications and protocols. It's also used for JAR-file signing and verification. We should make it easy to get good performance out-of-the-box for processors that support SHA instructions in hardware.

Cryptographic operations such as SHA are generally compute-intensive and can become a source of performance bottlenecks if they are executed frequently. Specialized ISA support for these cryptographic operations offers significant performance improvements over regular Java JIT-compiled code. Using the SHA instructions through a native library gives a good performance improvement, but the JNI overhead limits performance gains in the cases of smaller data sizes. Adding intrinsics with SHA instructions would avoid the JNI overhead and give better performance for all sizes of data.

Description

The intent of this change is to improve the out-of-the-box performance of applications that use SHA.

The HotSpot compiler will generate SHA instructions automatically when the SPARC processor supports such instructions. A flag will be provided (-XX:-UseSHA) to turn this off if desired. Other CPU types are not affected.

This feature will be implemented only in the C2 compiler in the Server VM.

This feature is only applicable when the application is configured to use the SUN security provider. Hardware acceleration is achieved by adding intrinsics (i.e., stub routines) for methods such as sun.security.provider.SHA.implCompress, sun.security.provider.SHA2.implCompress, sun.security.provider.SHA5.implCompress, and sun.security.provider.DigestBase.implCompressMultiBlock in the cases of SHA/SHA2/SHA5.

Testing

This change can be tested by standard benchmarks and application-server test suites, either on systems that support SPARC SHA instructions or on systems that do not support SPARC SHA instructions to ensure that there are no unintended side effects.

Risks and Assumptions

This feature is only applicable when the application is configured to use the SUN provider for SHA operations. Currently on Solaris, by default, the OracleUcrypto and SunPKCS11 providers are ahead of SUN in the provider list. To use this feature, it is assumed that users can change the order of the providers list in the java.security properties file, modify the configuration files of the first two providers to skip SHA operations, or request the SUN provider explicitly in their source code.

Dependences

The HotSpot compiler change (JDK-8035968) depends on the security library change (JDK-8035974) to reach the full potential of the performance improvement in most cases. The library change helps the compiler to generate intrinsics for the multi-block processing loops which are used when the input data are equal to or larger than a block (64 bytes for SHA-1/SHA-224/SHA-256, or 128 bytes for SHA-384/SHA-512).

This change also depends on HotSpot compiler changes (JDK-8035605) to generate multi-block processing intrinsics.