JDK-6998860 : Signed jar file verification is currently creating many extra new Sun providers.
- Type: Bug
- Component: security-libs
- Sub-Component: java.security
- Affected Version: 7
- Priority: P2
- Status: Closed
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2010-11-10
- Updated: 2014-10-06
- Resolved: 2011-03-07
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.
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 | JDK 7 |
|---|---|
6u25Fixed  |
7 b123Fixed |
Related Reports
|
Relates :
|
Description
Use a debugger to walk through a simple call to:
new SecureRandom().nextInt();
It appears as though signed jar file verification is creating a new Sun provider for each jar entry that's being verified.
In the attachments:
1.txt vs. 2.txt: There are 15 slightly different calls of the same stack.
sun.security.pkcs11.SunPKCS11.d(SunPKCS11.java:456)
calls into loadClass, which does a findClass, which brings in the URLClassLoader, which brings in JarFile, which tries to verify the Manifest via the ManifestEntryVerifier, which creates a MessageDigest, which gets a new instance of the SunProvider.
Each time we try to load a new class, we do the same thing over/over again. This seems very wasteful, and we should be grabbing the Provider if it's already been initialized.
3.txt vs. 4.txt are similar to 1/2, but just using a different new instance paths.
< sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java)
< sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
---
> sun.reflect.GeneratedConstructorAccessor1.newInstance
27,28c26,28
There are 22 of these. :(
Comments
|