[13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity"

[Valerie Peng]

Well, I initially tried to use the computeIfAbsent, and I really like 
how the resulting code looks. But then as I checked the javadoc of the 
computeIfAbsent method, it seems that the provider verification code 
does not meet the criteria of short, simple requirement of the mapping 
func. In addition, the verification of 3rd party provider may trigger 
the verification of other providers which means updating the other 
mappings of the same map which the javadoc says the mapping func *must 
not* do. I don't know the internals of ConcurrentHashMap, would this 
possibly lead to a deadlock? So, I just followed the existing model of 
sync'ing on JceSecurity class. I didn't proceed with performance 
measuring of computeIfAbsent given the above reason.

Valerie

On 5/16/2019 2:12 AM, Alan Bateman wrote:
> On 15/05/2019 20:11, Valerie Peng wrote:
>> I updated the webrev to switch to ConcurrentHashMap. The javadoc spec 
>> of computeIfAbsent method cautioned that the mapping func should be 
>> short and simple and must not attempt to update other mappings of 
>> this map. Provider verification code does not quite fit the above 
>> criteria for the mapping. So, I did not use computeIfAbsent method 
>> and just made minor update to webrev.01 with Xuelei's suggestion of 
>> re-checking the cache again inside the synchronized block.
>>
>> http://cr.openjdk.java.net/~valeriep/7107615/webrev.03/
>>
>> Comments?
> Does it need to synchronize on JceSecurity.class? I'm mostly wondering 
> if it can use computeIfAbsent.
>
> -Alan