On Mon, Nov 7, 2022, at 11:57, Anthony Scarpino wrote: > Yes, I was able to reproduce this.
Glad to hear it. > The memory usage is related to a > necessary java change for the AVX512 intrinsic. It doesn't show up much > in the crypto performance tests, but TLS triggers it more often, driving > up the memory usage even though the performance is only slightly affected. In my synthetic benchmark, TLS_AES_128_GCM_SHA256 average time increased from 90ms/op to 160ms/op, a 78% regression. TLS_AES_128_GCM_SHA256 increased from 100ms/opt o 170ms/op, a 70% regression. I don't think this is an entirely accurate of standard TLS usage (especially because connections aren't reused) but I do believe the regression in practice is greater than 10%. I don't have much data from jdk19 in production, but historically, heavy allocations have impacted latency (or resource utilization depending on the GC) across an application, especially one that's already allocating heavily. > I have to see if I can change the code path without hurting the > decryption performance gains from the AVX512 intrinsic. That would be fantastic, thank you! Thanks, Carter Kozak