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