TLS Performance Regression in JDK18+

Carter Kozak ckozak at ckozak.net
Mon Nov 7 17:50:41 UTC 2022


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


More information about the security-dev mailing list