On Thu, 1 Apr 2021 15:51:55 GMT, Jamil Nimeh <[email protected]> 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
