I think hashMap.put() may be similar or more effective than hashMap.putIfAbsent(). Is there a case that the key/weakPd is the same, but the value/pc is different?
Xuelei On 1/12/2016 11:01 PM, Sean Mullan wrote: > 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 >>> >>
