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

[Xuelei Fan]

Good, I have no further comment for this update.  Please go ahead.

I think there is a possible improvement by calling 
Cipher.getInstance(algorithm) only one time for each transformation 
algorithm.  But may not worthy as the duplicated transformation 
algorithm number is still small.  I'm fine if you want to leave it as it is.

Thank you so much for your patient, especially for doing the benchmarking.

Thanks,
Xuelei

On 5/24/2019 1:53 PM, Martin Balao wrote:
> Hi Xuelei,
> 
> On 5/24/19 5:17 PM, Xuelei Fan wrote:
>> If I understand correctly, you run the test with the patch of webrev01?
>>     http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/
>>
> 
> Yes, this is correct.
> 
>>
>>> 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/
> 
> No, this is not correct. "without_8223482" means no patch at all, just
> the base line JDK (at revision fb0cfce19262, 2019-05-23).
> 
> In my opinion, it makes no sense to continue measuring Webrev.00 because
> it has a considerable impact as shown by previous benchmarks.
> 
>>
>>  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.
> 
> Yes, looks strange that FIPS with patch is better than without patch.
> However, we need to consider that the difference is not a big one and
> the margin of error we have. If you ask me, I'd say they are roughly the
> same.
> 
>>
>> Did you have the numbers for the latest JDK build, without any patch?
> 
> As I said, "without" means the latest JDK without any patch.
> 
> Kind regards,
> Martin.-
>