JDK-6382773 : Cipher.init() causes extremely long pauses and CPU pegged at 100% level
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 5.0u6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-02-08
  • Updated: 2010-04-02
  • Resolved: 2006-03-23
Related Reports
Duplicate :  
Description
Operating System: Windows XP
OS version: Version 5.1 (build 2600.xpap2.050301-1526: Service Pack 1)
Product Name: JRE
Product version: 1.5.0_06-b05
Hardware platform: Dell workstation, Intel Pentium 4 2.80 GHz w/ 1GB of RAM

Full problem description: A client program calling Ciper.init() [with Sun's JCE provider] will cause a long pause and CPU pegged at 100% level. E.g., it took 90-110 seconds for a jar size of 10 Mb.  The conditions for this to occur: (1) the client code resides in a large jar file and (2) the jar file is signed. Customer have test the same against JRE 1.5.0_01 and the same problem does not exist. They tested that if the jar file is not signed then the problem also does not exist. They are forced to package the classes that call Cipher.init into a different, very small jar file, as a temporary work-around.  But Customer would like NOT to separate the jar file, and would like to find out what is the root cause for this strange behavior.

Comments
EVALUATION Several pings to the escalating customer went unanswered, and received today the following message from ###@###.###: ===begin=== I have not heard back from the customer, but in my own testing here I verified that this bug no longer exists in 5.0u7. I plan to close my escalation on the assumption that this is fixed for the customer also, you may want to close the bug as a duplicate of 6354728 as I believe you were planning. ===end=== Therefore, I'm closing this as a duplicate of 6354728. Please reopen if the situation has not resolved itself.
23-03-2006

EVALUATION I've done some testing within Sun and find this fixed in 5.0u7 b01. My testcase was CipherPerformanceTest.java built into a jar file containing the contents of rt.jar, and I tested a signed and unsigned jar file. The bad case with 1.5.0_04: java -classpath ./NewRT15s.jar CipherPerformanceTest encrypt testfile keyfile Generating key TripleDES for file keyfile Saved key to file keyfile Encrypting file testfile Done. real 15m50.83s user 12m57.56s sys 0m26.94s ..where using the unsigned jar the times were: real 0m9.79s user 0m8.08s sys 0m1.15s The bad case sure enough spends time with a stack like: "main" prio=10 tid=0x00036f78 nid=0x1 runnable [0xffbfd000..0xffbfe278] at java.util.HashMap.transfer(HashMap.java:476) at java.util.HashMap.resize(HashMap.java:455) at java.util.HashMap.addEntry(HashMap.java:745) at java.util.HashMap.put(HashMap.java:395) at sun.net.www.protocol.jar.URLJarFile.getManifest(URLJarFile.java:119) at java.util.jar.JarFile.getInputStream(JarFile.java:395) - locked <0xb9f95d38> (a sun.net.www.protocol.jar.URLJarFile) at javax.crypto.SunJCE_d.b(DashoA12275) ...etc... Testing with 5.0u7 b01: java -classpath ./NewRT15s.jar CipherPerformanceTest encrypt testfile keyfile Generating key TripleDES for file keyfile Saved key to file keyfile Encrypting file testfile Done. real 0m31.06s user 0m20.31s sys 0m4.08s ..and the unsigned jar: real 0m15.70s user 0m8.25s sys 0m2.54s Testing on Windows is good also: 11 minutes to run using the signed jar file with 5u4 goes to < 1 minute with 5u7 b01.
22-02-2006

EVALUATION I agree that this is most likely the same cause as 6354728. Since it involves the Cipher class, I had been following this issue from the JCE end in the JDC forums, but was not able to get an early version of 5.0u7 out to a customer without an escalation in place. This sounds like we finally have the escalation we need to get someone to test this out. Even though the root cause of this bug is a classses_security bug, I'm going to move this into the JCE category so that people doing JCE-only searches will be able to find it. This will be closed as a duplicate to 6354728 when we get word the issue has been resolved. If this is *NOT* the problem, I'll look into it further. Kevin, can you get the customer to please try a recent build of 5.0u7, and see if this fix addresses the issue? Thanks.
22-02-2006

WORK AROUND By reducing the size of the signed jar file, you can lessen the impact caused by this bug. Split your app into the bits that must be signed and not signed. *** (#1 of 1): [ UNSAVED ] ###@###.###
22-02-2006