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. :(