• 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

JDK 7	JDK 8	JDK 9
7u101Fixed	8u112Fixed	9 b102Fixed

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. 08-01-2016