OpenJDK reported issue - http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html

While working my way through Tomcat's memory leak protection / detection/ fixing code, I have found an issue that remains unresolved in the latest JDK 9 source.

The poller thread created by the SunPKCS11 class does not explicitly set
the context class loader so it inherits the current context class
loader. If the current context class loader when this code is triggered
happens to be one that is meant to be disposable (e.g. a web application
class loader) the class loader will be pinned in memory until the Thread
stops. This prevents the class loader from being GC'd when no longer
required and triggers a memory leak.

Given that the creation of this thread depends on various factors,
including hardware configuration, the issue is fairly rare but we have
seen instances of it reported [1].

The fix looks to be trivial. Something along the lines of the following
around line 820 of SunPKCS11:

t.setContextClassLoader(SunPKCS11.class.getClassLoader());

If I can provide any further information or if there is better place /
way to submit this then please do let me know.

Mark

[1] http://markmail.org/message/sykuo32eeknwsaqk