RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v4]
Vladimir Kozlov
kvn at openjdk.java.net
Thu Jul 15 00:44:15 UTC 2021
On Wed, 14 Jul 2021 21:02:01 GMT, Smita Kamath <svkamath at openjdk.org> wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>
> Updated AES-GCM intrinsic to match latest Java Code
First, you need review from Tony for Java side changes.
Second, you need to extend tests in `test/hotspot/jtreg/compiler/codegen/aes/` to cover this implementation.
And, third, I think we need to put this on hold until the issue of big intrinsics stubs generation effect on startup is solved. See discussion in https://bugs.openjdk.java.net/browse/JDK-8270323
- code_size1 = 20000 LP64_ONLY(+10000), // simply increase if too small (assembler will crash if too small)
- code_size2 = 35300 LP64_ONLY(+25000) // simply increase if too small (assembler will crash if too small)
+ code_size1 = 20000 LP64_ONLY(+12000), // simply increase if too small (assembler will crash if too small)
+ code_size2 = 35300 LP64_ONLY(+37000) // simply increase if too small (assembler will crash if too small)
@sviswa7 please, note these changes too for our discussion.
src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7644:
> 7642: }
> 7643: if (UseAESIntrinsics) {
> 7644: if (VM_Version::supports_avx512_vaes() && VM_Version::supports_avx512vl() && VM_Version::supports_avx512dq()) {
Why duplicate already existing checks? Move code there and add comment for which intrinsic code is generated.
src/hotspot/cpu/x86/stubRoutines_x86.hpp line 36:
> 34: enum platform_dependent_constants {
> 35: code_size1 = 20000 LP64_ONLY(+12000), // simply increase if too small (assembler will crash if too small)
> 36: code_size2 = 35300 LP64_ONLY(+37000) // simply increase if too small (assembler will crash if too small)
This is almost 50% increase !!!
src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 333:
> 331: static_field(StubRoutines, _bigIntegerRightShiftWorker, address) \
> 332: static_field(StubRoutines, _bigIntegerLeftShiftWorker, address) \
> 333: static_field(StubRoutines, _galoisCounterMode_AESCrypt, address) \
Move up to other AESCrypt lines.
src/hotspot/share/opto/escape.cpp line 1111:
> 1109: strcmp(call->as_CallLeaf()->_name, "bigIntegerLeftShiftWorker") == 0 ||
> 1110: strcmp(call->as_CallLeaf()->_name, "vectorizedMismatch") == 0 ||
> 1111: strcmp(call->as_CallLeaf()->_name, "galoisCounterMode_AESCrypt") == 0 ||
Please, move new line where other AEScrypt methods listed.
src/hotspot/share/runtime/stubRoutines.cpp line 130:
> 128: address StubRoutines::_base64_encodeBlock = NULL;
> 129: address StubRoutines::_base64_decodeBlock = NULL;
> 130: address StubRoutines::_galoisCounterMode_AESCrypt = NULL;
Move up few lines
src/hotspot/share/runtime/stubRoutines.hpp line 212:
> 210: static address _base64_encodeBlock;
> 211: static address _base64_decodeBlock;
> 212: static address _galoisCounterMode_AESCrypt;
Move up few lines
src/hotspot/share/runtime/vmStructs.cpp line 592:
> 590: static_field(StubRoutines, _unsafe_arraycopy, address) \
> 591: static_field(StubRoutines, _generic_arraycopy, address) \
> 592: static_field(StubRoutines, _galoisCounterMode_AESCrypt, address) \
Move up to other AESCrypt declarations.
-------------
Changes requested by kvn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/4019
More information about the security-dev
mailing list