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

[Xuelei Fan]

The benchmark result looks good to me.  I still have a few questions. 
Read inlines, please.

On 5/24/2019 12:16 PM, Martin Balao wrote:
> Hi Xuelei,
> 
> Thanks for your reply.
> 
> I think I now know what you mean.
> 
> Here it's a new benchmark:
> http://cr.openjdk.java.net/~mbalao/webrevs/8223482/benchmark_sslcontextloading_manual_v0.tar.gz
> 
> In this new benchmark we measure the following sequence:
> 
> long startTime = System.currentTimeMillis();
> ctx = SSLContext.getInstance("TLSv1.2");
> long stopTime = System.currentTimeMillis();
> 
> The SSLContext class gets initialized per run.
> 
> We test both NON_FIPS (SunJCE) and FIPS (SunPKCS11) providers.
> 
> Results summary (100 runs per case):
> 
> FIPS_with_8223482_webrev01.txt average: 314.33 ms
> NON_FIPS_with_8223482_webrev01.txt average: 817.91 ms
> 
If I understand correctly, you run the test with the patch of webrev01?
    http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/


> FIPS_without_8223482_webrev01.txt average: 358.42 ms
> NON_FIPS_without_8223482_webrev01.txt average: 771.34 ms
> 
If I understand correctly, you run the test with the pacth of webrev00?
    http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/

 From the above numbers, the FIPS_with_8223482_webrev01 is better than 
FIPS_without_8223482_webrev01, but NON_FIPS_with_8223482_webrev01 is 
worse than NON_FIPS_without_8223482_webrev01.  It is a little bit 
strange to me.

Did you have the numbers for the latest JDK build, without any patch?


> So, yes, it seems that there is a ~6% startup impact on SunJCE. These
> numbers are not accurate though because of using
> System.currentTimeMillis to measure, they provide just a rough idea.
> 
A rough idea is okay.  Maybe, you can use nanoseconds.  But it is not 
really necessary.

Thanks,
Xuelei