RFR: 8296507: GCM using more memory than necessary with in-place operations

[Anthony Scarpino]

On Wed, 16 Nov 2022 18:19:30 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> It's possibly worth noting that while this is merely fixing a regression for x86, it's very likely a decent sized performance improvement on arm64, where intrinsics for AES-GCM (depending on JVM vendor) aren't added until after Java 17.
>
>> It's possibly worth noting that while this is merely fixing a regression for x86, it's very likely a decent sized performance improvement on arm64, where intrinsics for AES-GCM (depending on JVM vendor) aren't added until after Java 17.
> 
> That is why it refers to "combined intrinsic" more than spelling out AVX512.  The change affects all platforms

> Thanks for looking into this, @ascarpino!
> 
> In testing this using a local build, it improves performance in cases using heap buffers (a super-set of the socket case), however servers which use direct byte-buffers still exhibit a similar performance regression (heavy allocation compared to jdk17, ~10% slower TLS performance in HTTP+TLS benchmarks). It's possible that has a different root cause, but the outcome is strikingly similar.

Well the provided test ran with heap bytebuffers and direct bytebuffers are handled differently because it has to copy data for the intrinsic.  But that data allocation is pretty low and I believe was the same in 17.  So I'm not aware of a direct bytebuffer slowdown as you now report

-------------

PR: https://git.openjdk.org/jdk/pull/11121