RFR: 8262316: Reducing locks in RSA Blinding

[Anthony Scarpino]

On Thu, 1 Apr 2021 15:51:55 GMT, Jamil Nimeh <jnimeh at 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