JDK-6905940 : Performance degradation introduced in 6.0_14-b03 related to pkcs11
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 6u14
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2009-12-01
  • Updated: 2010-05-17
  • Resolved: 2010-05-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6-poolResolved
Related Reports
Relates :  
JDK-6591117 - Poor preformance of PKCS#11 security provider compared to Sun default provider
Relates :  
JDK-4898484 - Cipher should optimize cases where only one buffer is a DirectBuffer
Relates :  
JDK-4898461 - Support for ECB and CBC/PKCS5Padding
Description
Customer application was upgraded from 1.6.0_12 -> 1.6.0_16
Their benchmark tests are taking an order of magnitude
The result are consistent:
- Runs with JRE 1.6.0_16 would take between 1100-1200s
- Runs with JRE 1.6.0_12 would take between 800-900s

Working with the customer we have isolated that the regression
was introduced in JDK 1.6.0_14

We had the customer run the testing with JDK hprof
running and noticed a lot of time being spent in PKCS11

We noticed that there were 2 bugs fixed in 6.0_14 
of interest both related to PKSC11
(4898461 & 4898484)

The fixes for these 2 bugs were put into 6.0_14-b03
To further isolate the regression we had
the customer test wtih 6.0_14-b02 and 6.0_14-b03

The customer has confirmed that the regression
was definitely introduced into 6.0_14-b03

The JDK performance comes inline with the performance of JDK 1.6.0_12 
when adding the following Java property.
"-Dsun.security.pkcs11.enable-solaris=false" 

Customer has all the latest Solaris 10/X86 crypto patches installed

A crytoadm list -mv is attached to this bug report

Test results are located at the following
/net/cores.east/cores/dir11/71714222/

Due to the complexity of the test benchmark, the custoemr is unable to 
provide a repro test case
Comments
EVALUATION With 4898461, SunPKCS11 provider supports more crypto algorithms such as DES, DESede, AES with ECB, CBC modes with PKCS5Padding, etc. As for 4898484, it's meant to optimize scenarios where only one of the input/output buffers is a direct buffer. The RFCs for SNMP v3 states the usage of DES with CBC mode and Padding. Thus, the performance difference could be that the DES/CBC/PKCS5Padding impl from SunPKCS11 provider isn't matching up with the one from SunJCE provider. But, without a testcase on hand, we need some troubleshooting on customer end to verify if this is the key factor. Lowering the priority since there are easy workarounds here (from most to least impact), i.e. disable SunPKCS11 provider or re-order the SunPKCS11 provider to a less-preferred position, or disable only certain PKCS11 mechanisms.
08-12-2009