On Thu, 1 Apr 2021 15:51:55 GMT, Jamil Nimeh <jni...@openjdk.org> wrote:

>> Hi,
>> 
>> I need a review of the locking change to the RSA blinding code. The problem 
>> was reported that multithreaded performance suffered because there was one 
>> global lock on the many blindings operation.  The change reduces locking by 
>> using a ConcurrentLinkedQueue to store the different BlindingParameters that 
>> other threads maybe using.  The queue size is limited to prevent sudden 
>> surges in stored BlindingParameters and a WeakHashMap is still used so the 
>> objects can be freed when no longer used.  Performance doubles under high 
>> load.
>> 
>> thanks
>> 
>> Tony
>
> src/java.base/share/classes/sun/security/rsa/RSACore.java line 414:
> 
>> 412:                 if (!u.equals(BigInteger.ZERO) &&
>> 413:                     !v.equals(BigInteger.ZERO)) {
>> 414: 
> 
> Is it ever possible that u could be equal to BigInteger.ZERO?  The only place 
> I see a new BlindingRandomPair created is within the scope of the 
> BlindingParameters object, and it has a guard in its constructor that resets 
> u to BigInteger.ONE if u is zero.  Or is this check to guard against the 
> reset of u/v down around line 416-419 (recalculated when reusable)?

The both values are never zero now as the old code used zero to define the 
parameters needed to be reset.  I don't think this zero check is necessary.. 
let me try something else that fits with the isReusable() here and the one 
below when putting it into the queue

-------------

PR: https://git.openjdk.java.net/jdk/pull/3296

Reply via email to