RFR 8223482: Unsupported ciphersuites may be offered by a TLS client

[Xuelei Fan]

Thank you for the benchmarking.

On 5/23/2019 3:19 PM, Martin Balao wrote:
> Hi Xuelei,
> 
> I've developed a new benchmark to measure SSLContext loading:
> http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_v0.tar.gz
> 
> Results:
> http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_v0_results_v0
> 
> Summary
> 
> WITHOUT 8223482 FIX
> ============================================================
> 
> Benchmark                                  Mode  Cnt       Score
> Error  Units
> SSLContextLoading.test_SSLContextLoading  thrpt   10  437456.584 ±
> 25620.210  ops/s
> 
> WITH 8223482 FIX (Webrev.01)
> ============================================================
> 
> Benchmark                                  Mode  Cnt       Score
> Error  Units
> SSLContextLoading.test_SSLContextLoading  thrpt   10  491894.639 ±
> 27959.271  ops/s
> 
> 
> However, I'm not sure that this is what you suggested. If we measure
> "SSLContext.getInstance("TLSv1.2")" alone in a loop, we will have the
> class static initializer executed only once unless we generate enough
> memory pressure for the garbage-collector to get rid of the class.
It is not as the static initialization get run once only.

I think you could simplify the test without using the benchmark tool, 
just measure the start time, end time of the loading one time for each 
testing, and check it with different providers.  No need to be accuracy, 
a roughly number is sufficient to get an idea if the impact is acceptable.

Thanks,
Xuelei

> I've
> verified this not only with static analysis but setting a breakpoint.
> Thus, and considering SSLContextImpl.getApplicableCipherSuites is only
> called from class static initializers, I would have not expected
> performance degradation there.
> 
> Look forward to your answer.
> 
> Kind regards,
> Martin.-
>