High memory usage / leaks was: Best mailing list for JVM embedding

[Bernd Eckenfels]

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-bounces at openjdk.java.net> im Auftrag von Robert Marcano <robert at 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.Bateman at 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.

>