On 22/01/2019 4:48 am, Robert Marcano wrote:
:
So the question now is, why signed jars could affect the memory usage
of an application (we aren't doing JAR verification on our custom
launcher, yet), just by being on the java.class.path? IIRC the
initial application classpath JARs were never verified previously (by
the java launcher alone, without JNLP around).
Note: Tested with JARs signed with a self signed certificate and with
one signed with a private CA. At most, signing the JARs could slow
down the start up if it is now expected to these being verified by
the java launcher (is it true?) but not higher memory usage and no
reductions after a GC cycle but constants heap size increases.
Signed JARs can be expensive to verify, esp. on first usage as the
verification is likely to result in early loading of a lot of security
classes and infrastructure. If you can narrow down the apparently memory
leak to a small test case with analysis to suggest it's a JDK bug then
it would be good to get a bug submitted.
-Alan
