[External] : Re: TLS Performance Regression in JDK18+

[Anthony Scarpino]

On 11/7/22 9:50 AM, Carter Kozak wrote:
> 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've seen differences of 77ms/ops vs 90ms/ops between jdk17 & jdk19, so 
not as dramatic as yours, but I think I saw more memory usage than you 
did with other tools.  Benchmarks seldom, if ever, show real world usage.

Using the same jdk releases, I can show AES/GCM output went from 4.8GB/s 
to 6.8GB/sec between 17 and 19, but that is under difference conditions 
than this TLS benchmark.  So everything gets taken in a case by case 
basis and sometimes involve trade offs.

Tony

> 
>> 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