Bug ID: JDK-8240256 Better resource cleaning for SunPKCS11 Provider

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 11	JDK 17	JDK 8
11.0.14-oracleFixed	17 b26Fixed	8u311Fixed

Submitter complaining that Sessions seen left on heap after numerous SunPKCS11 providers and initialized and logged out from.

# jcmd 170515 GC.class_histogram | grep pkcs11.Sess
 558:            35           1680  sun.security.pkcs11.SessionManager
 559:            70           1680  sun.security.pkcs11.SessionManager$Pool
 614:            35           1400  sun.security.pkcs11.Session
 615:            35           1400  sun.security.pkcs11.SessionRef
# jcmd 170515 GC.class_histogram | grep pkcs11.Sess
 535:            38           1824  sun.security.pkcs11.SessionManager
 536:            76           1824  sun.security.pkcs11.SessionManager$Pool
 585:            38           1520  sun.security.pkcs11.Session
 586:            38           1520  sun.security.pkcs11.SessionRef

Fix Request (11u): Should get backported for parity with 11.0.14-oracle. Actual fix applies cleanly, but the tests need resolution. Review: https://github.com/openjdk/jdk11u-dev/pull/352
15-09-2021
Changeset: bdeaeb47 Author: Sean Coffey <coffeys@openjdk.org> Date: 2021-06-03 06:45:06 +0000 URL: https://git.openjdk.java.net/jdk/commit/bdeaeb47d0155b9f233274cff90334e8dd761aae
03-06-2021
Work is still progressing on this issue. I'm attempting various framework edits to clean up the small number of pool sessions that are idling but it's a complex scenario. Examples: 1. Sessions have to be routinely created to determine the status of the pkcs11 Token insert/remove operations. In current design, the pool sessions can be used. (via TokenPoller) 2. Also, Sessions operate a referent list design whereby any keys/artifacts from a pkcs11 derived operation prevent the Session from being "released". I was hoping to hear from the submitter as to why a re-design is required here. It turns out to be a very conscious design effort to have a maximum of 10 idling Sessions per PKCS11 Provider. IS the submitter creating multiple SunPKCS11 Providers in production code or is this for a test demo purposes only?
10-04-2020
An update on current status. To summarize, each SunPKCS11 Provider has a SessionManager to control PKCS11 sessions. These sessions are grouped into two pools per Provider, one for holding object sessions and one for holding operation sessions. The sessions are pooled in order to minimize the number of C_OpenSession() and C_CloseSession() that have to be made. A small number of idling sessions are left in each pool (5 per pool) - This would be a maximum of 10 idling sessions plus working sessions per SunPKCS11 Provider. It most likely explains what the Cu is seeing. I'm reviewing the design to see if we can have some sort of logout mechanism which destroys all sessions in the pool. It would be less efficient but appears to be a use case that Cu is looking for. If they keep SunPKCS11 use to one instance (most common), they should only have a maximum of 10 sessions left in the JVM pool.
10-04-2020

CSR :	JDK-8262226 - Better resource cleaning for SunPKCS11 Provider
Relates :	JDK-8161536 - sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with ProviderException
Relates :	JDK-8269034 - AccessControlException for SunPKCS11 daemon threads
Relates :	JDK-8268167 - MultipleLogins.java failure on macosx-aarch64

JDK-8272907 :	Release Note: New SunPKCS11 Configuration Properties - Closed
JDK-8273024 :	Update PKCS#11 Reference Guide with new attributes in provider configuration file - Resolved