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