JDK-8046261 : JEP 207: Leverage CPU Instructions to Improve SHA Performance on SPARC
  • Type: JEP
  • Component: hotspot
  • Sub-Component: compiler
  • Priority: P2
  • Status: Closed
  • Resolution: Delivered
  • Fix Versions: 8u40
  • Submitted: 2014-06-06
  • Updated: 2014-10-06
  • Resolved: 2014-10-06
Related Reports
Relates :  
Relates :  
Relates :  
Description
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.