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

[Robert Marcano]

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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190122/bc822920/attachment-0001.html>