On Wed, 16 Nov 2022 18:19:30 GMT, Anthony Scarpino <ascarp...@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
