Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable

[Sean Mullan]

Hi Xuelei,

For JDK 9, the EC impl is defined to be in its own module 
(jdk.crypto.ec). How does it affect this fix if that module is not 
available/installed?

--Sean

On 12/01/2015 07:49 AM, Xuelei Fan wrote:
> Hi,
>
> Please review the fix for JDK-8133070:
>
>     http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/
>
> In (Open)JDK 6, EC cipher suites get supported by Java.  However, there
> is no default EC provider in JDK 6 at that time.  In order to support
> third part's EC algorithm JCE provider dynamically, it is hard-coded to
> check the cipher suite availability dynamically for EC algorithms in
> SunJSSE provider.
>
> Here is an example update in CipherSuite.java for the checking:
>
>    -   static final boolean DYNAMIC_AVAILABILITY = false;
>    +   static final boolean DYNAMIC_AVAILABILITY = true;
>
> The dynamically checking impacts the performance significantly as:
> 1. the check of the availability is expensive as it involves crypto
> operations.
> 2. a cache is used to maintain the availability of bulk ciphers in order
> to mitigate the #1 performance impact.  However, access and update to
> the cache need to be synchronized.
> 3. in order to support dynamically checking, the cache may be cleared if
> a particular cipher is not found or a new SSLContext is generated. As
> bring the performance impact of #1 back again.
>
> Later, AEAD algorithm is defined by Java.  The same mechanism is used to
> support AEAD ciphers.
>
> Now, EC and GCM algorithms are supported in JDK crypto providers. The
> hard-coded checking can get improved.  This fix updates:
> 1. remove the dynamically checking of cipher suite availability.
> 2. remove the cipher suite availability cache accordingly (need no
> synchronization accordingly)
> 3. other updates that impact by the availability checking.
>
> The performance improvement is tested with the following simple case.
> Run the following code 1000, 2000, 3000 times in single thread mode and
> measure the millisecond for each:
>
> ---------
> String[] cipherSuites =
>          {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"};
> for (int i = 0; i < loops; i++) {  // loops: 1000, 2000, 3000
>      SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>      engine.getEnabledCipherSuites();
>      engine.getSupportedCipherSuites();
> }
> ---------
>
> The milliseconds for each test case (less is better) look like:
>
>      loops   |  old    |  fixed
>     ---------+---------+----------
>     1000     |  2736   |  735
>     ---------+---------+----------
>     2000     |  3718   |  746
>     ---------+---------+----------
>     3000     |  4750   |  765
>     ---------+---------+----------
>
> This fix improves the performance.
>
> The existing regression testing get passed.  No new regression test is
> planned as this is a performance enhancement fix.
>
> Thanks,
> Xuelei
>