RFR: 8085903: New fix for memory leak in ProtectionDomain cache

Sean Mullan sean.mullan at oracle.com
Tue Jan 12 15:01:10 UTC 2016


Hi Ivan,

On 01/12/2016 09:38 AM, Ivan Gerasimov wrote:
> Hi Sean!
>
> On 12.01.2016 16:26, Sean Mullan wrote:
>> I received a private comment that there may be cases where the map's
>> value is reclaimed by the garbage collector, but the key still exists.
>> If that ProtectionDomain is subsequently used for permission checks, a
>> Map.putIfAbsent method will not replace the value.
>>
>> So, I have added an additional check for this case in the PDCache.put
>> method, and it instead uses the Map.replace method. Updated webrev:
>>
>
> Wouldn't it be a little bit more efficient to use merge() here?
>
> Something like:
> pdMap.merge(weakPd, v, (pv, nv) -> pv.get() != null ? pv : nv);

Yes - good catch!

Will update and send out new webrev after a round of testing ...

Thanks,
Sean

>
> Sincerely yours,
> Ivan
>
>> http://cr.openjdk.java.net/~mullan/webrevs/8085903/webrev.01/
>>
>> --Sean
>>
>> On 01/08/2016 03:06 PM, Sean Mullan wrote:
>>> Please review this fix for a memory leak in the ProtectionDomain cache
>>> (which maps each ProtectionDomain to their granted
>>> PermissionCollection). The memory leak only occurs if custom permissions
>>> are used in a policy file.
>>>
>>> http://cr.openjdk.java.net/~mullan/webrevs/8085903/webrev.00/
>>>
>>> Custom permissions cause a chain of strong references that link back to
>>> the ProtectionDomain key used in the map, preventing it from being
>>> removed (and also preventing the custom permission's URLClassLoader from
>>> being garbage collected). This fix wraps the PermissionCollection in a
>>> SoftReference which allows the objects to be garbage collected in
>>> response to memory demand.
>>>
>>> Thanks,
>>> Sean
>>
>



More information about the security-dev mailing list