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
