Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable
Xuelei Fan
xuelei.fan at oracle.com
Tue Dec 8 12:28:39 UTC 2015
Ping ...
On 12/1/2015 8:49 PM, 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
>
More information about the security-dev
mailing list