[jdk9] RFR: 8080273: JCA Signature provider service loading bottlenecks

[Seán Coffey]

Ivan,

apologies for late review. I like the approach taken. It should help 
minimize contention. I'd have to highlight though that most contention 
seen in this area will be probably down to lack of raw CPU power. As RSA 
key lengths continue to grow, more CPU calculations will become 
necessary. The new intrinsics work recently completed will also benefit 
this area. [1]

I was a bit confused around why you're calling modPow earlier in 
iterBlindingRandomPair now but got it in the end. It won't be a wasted 
cycle in any case as per your notes.  Looks good to me. It would be good 
for you to get a member of Security team to review this.

[1] https://bugs.openjdk.java.net/browse/JDK-8153189

Regards,
Sean.

On 23/05/2016 12:41, Ivan Gerasimov wrote:
> Hello!
>
> It has been observed that under some circumstances a scalability 
> bottleneck may be observed, when accessing the internal 
> BlindingParameters structure in the sun.security.rsa.RSACore class.
>
> It is proposed to slightly reorganize the code around, to reduce the 
> possible contention.
>
> Would you please help review the proposal?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080273
> WEBREV: http://cr.openjdk.java.net/~igerasim/8080273/00/webrev/
>
> Three things are done here:
> 1) The instance of BlindingParameters is confined to the current 
> thread, so no synchronization is necessary when creating the next 
> BlindingRandomPair;
> 2) Extra instances of BlindingParameters, which are created due to 
> concurency, aren't thrown away but reused;
> 3) Only perform { u = u.modPow(BIG_TWO, n);  v = v.modPow(BIG_TWO, n); 
> } when needed, thus save the last unused calculation.
>
> Comments, suggestions are very welcome!
>
> With kind regards,
> Ivan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160531/9293616c/attachment.htm>