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

Xuelei Fan xuelei.fan at oracle.com
Fri May 24 20:17:14 UTC 2019

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?

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

 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.


More information about the security-dev mailing list