JDK-8085903 : New fix for memory leak in ProtectionDomain cache
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-06-05
  • Updated: 2017-12-14
  • Resolved: 2016-01-13
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.
7u101Fixed 8u112Fixed 9 b102Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Fix for JDK-8058547 failed in that it's caused a regression. See JDK-8077418.

Using this record to code a new fix.
The memory leak occurs when custom Permissions are used in a policy file, for example: grant codeBase "file:${user.home}/app/" { permission SomePermission "foo"; }; In the example above, the SomePermission is created as an UnresolvedPermission instance when the policy file is initially parsed and then later resolved and instantiated as a SomePermission object when a permission check on SomePermission is triggered. It uses the same classloader of the SomePermission instance that is passed in. The policy file also caches the set of permissions granted to each ProtectionDomain. This cache avoids parsing the policy file and re-calculating the granted permissions each time a permission for a ProtectionDomain is checked. The memory leak occurs because the SomePermission class contains a strong reference to the ClassLoader which loaded it which in turn contains a strong reference to the ProtectionDomain associated with classes loaded by that ClassLoader, and which is also the key used in the cache. Because it is a loop of strong references, the entry will remain in the cache indefinitely, and each time a new ClassLoader is created that loads a custom Permission, another entry will be placed in the cache, etc. And this is true even though WeakReferences are currently used for the key, because the strong reference to the ProtectionDomain prevents them from being cleared. Thus, the most reasonable solution I have found is to wrap the PermissionCollection cache value in a SoftReference which will allow the PermissionCollection values to cleared by the GC if necessary. The code is written such that the PermissionCollection that has been GC-ed can be re-calculated by parsing the policy file again if necessary.