RFR(M): 8152172: PPC64: Support AES intrinsics
Hiroshi H Horii
HORII at jp.ibm.com
Fri Mar 25 01:17:04 UTC 2016
Thank you for your reviewing.
Is it possible to modify the type of sessionK from Object to int?
We can guess, the type was designed for flexibility. However, only int
to store elements of sessionK, so far. In addition, this field is private.
Though adding checkcast is another solution, it produces overheads.
I attached an additional patch (generated with hg diff -g) to jdk
I would like to ask thoughts about this change of java code.
IBM Research - Tokyo
Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote on 03/24/2016 09:09:11:
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-compiler-
> dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>
> Cc: "Doerr, Martin" <martin.doerr at sap.com>, Tim Ellison
> <Tim_Ellison at uk.ibm.com>, "Simonis, Volker" <volker.simonis at sap.com>
> Date: 03/24/2016 09:19
> Subject: Re: RFR(M): 8152172: PPC64: Support AES intrinsics
> I think we need to add gen_checkcast for objAESCryptKey node since
> java code has no guarantee that sessionK array elements are
> initialized with int. Or we should modify java code to declare
> as int.
> Note, intrinsics are correctly handle case when
> On 3/22/16 8:47 AM, Hiroshi H Horii wrote:
> > Dear all:
> > Can I please request reviews for the following change?
> > This change was created for JDK 9 to enable POWER8's AES
> > instructions for AES calculation.
> > This request follows this discussion.
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-
> > Description:
> > This change adds stub routines support for single-block AES
> > encryption and decryption operations on the POWER8 platform.
> > They are available only when the application is configured to
> > use SunJCE crypto provider on little endian.
> > These stubs make use of efficient hardware AES instructions
> > and thus offer significant performance improvements over
> > JITed code on POWER8 as on x86 and SPARC. AES stub routines
> > are enabled by default on POWER8 platforms that support AES
> > instructions (vcipher). They can be explicitly enabled or
> > disabled on the command-line using UseAES and
> > UseAESIntrinsics JVM flags. Unlike x86 and SPARC, vcipher
> > and vnchiper of POWER8 need the same round keys of AES.
> > Therefore, inline_aescrypt_Block in library_call.cpp calls the
> > stub with AESCrypt.sessionK as round keys.
> > Summary of source code changes:
> > *src/cpu/ppc/vm/assembler_ppc.hpp
> > *src/cpu/ppc/vm/assembler_ppc.inline.hpp
> > - Adds support for vrld instruction to rotate vector register
> > with left doubleword.
> > *src/cpu/ppc/vm/stubGenerator_ppc.cpp
> > - Defines stubs for single-block AES encryption and decryption
> > routines supporting all key sizes (128, 192 and 256-bit).
> > - Current POWER AES decryption instructions are not compatible
> > with SunJCE expanded decryption key format. Thus decryption
> > stubs read the expanded encryption keys (sessionK) with
> > descendant order.
> > - Encryption stubs use SunJCE expanded encryption key as their
> > is no incompatibility issue between POWER8 AES encryption
> > instructions and SunJCE expanded encryption keys.
> > *src/cpu/ppc/vm/vm_version_ppc.cpp
> > - Detects AES capabilities of the underlying CPU by using
> > has_vcipher().
> > - Enables 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/opto/library_call.cpp
> > - Passes the first input parameter, reference to sessionK to
> > AES stubs only on the POWER platform.
> > *src/share/vm/opto/graphKit.cpp
> > - Supports T_NARROWOOP type for GraphKit::load_array_element.
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
> > Webrev:
> > Regards,
> > Hiroshi
> > -----------------------
> > Hiroshi Horii,
> > IBM Research - Tokyo
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 982 bytes
Desc: not available
More information about the hotspot-compiler-dev