On 1/22/19 8:50 PM, Bernd Eckenfels wrote:
I don’t think the launcher is doing this, it is the class loader, that’s
nothing new. You can turn on verbose security debug to see it in all versions.
Yes, and it only verifies the signature(s) on the JAR. It doesn't
validate the certificate chain.
--Sean
--
https://Bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> im Auftrag von Robert
Marcano <rob...@marcanoonline.com>
Gesendet: Mittwoch, Januar 23, 2019 2:18 AM
An: Alan Bateman
Cc: OpenJDK Dev list; core-libs-dev Libs
Betreff: Re: High memory usage / leaks was: Best mailing list for JVM embedding
On Tue, Jan 22, 2019, 5:53 AM Alan Bateman <alan.bate...@oracle.com wrote:
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
Greeting. Sure, I will work on a distributable reproduction of the problem
today but it is new to me that the java launcher do JARs verification now.
If it is doing it I doesn't make sense to me, because a self signed or
unrecognized CA doesn't trigger a validation error.
