RFR: 8046943: RSA Acceleration

[Andrew Haley]

On 29/06/15 09:37, Vladimir Kozlov wrote:
> Hi, Andrew
> 
> Did you file RFE for this change?  8046943 is JEP.

No; I will do so.

> typo? "less" -> "more".
> 
> +     * number of ints in the number is less than this value we do not
> +     * use the intrinsic.
> +     */
> +    private static final int MONTGOMERY_INTRINSIC_THRESHOLD = 512;
> 
> trailing spaces:
> src/java.base/share/classes/java/math/BigInteger.java:273: Trailing whitespace
> src/java.base/share/classes/java/math/BigInteger.java:2770: Trailing whitespace
> 
> I ran changes through JPRT and linux/solaris passed - thanks.
> Next step - Windows:
> 
> C:\jprt\T\P1\s\hotspot\src\cpu\x86\vm\sharedRuntime_x86_64.cpp(26) : fatal error C1083: Cannot open include file: 
> 'alloca.h': No such file or directory

Hmm, okay.  This is going to be fun.  :-)

AFAIK OpenJDK builds with Visual Studio.  The VS equivalent of
alloca() is called _alloca() and its header file is <malloc.h>.  I'm
going to try to do this untested.  I think that autoconf will #include
malloc.h on Windows automagically, so all that I have to do is create
a #define for alloca() on Windows.

> I am fine with JDK changes.
> 
> Would be nice to have a test for this change. Do existing tests
> cover this code?

They do.  jdk/test/com/oracle/security/ucrypto/TestRSA looks like a
pretty thorough test.  If you make any mistake in the arithmetic RSA
decryption simply will not work: the result is corrupt.  The risks,
then, are mistakes such as accidental side-effects.  I don't know any
way to test for that.

The other possible think I could test for is unusual key sizes.  I'll
have a look.

> I agree that we should limit size when to invoke multiplyToLen
> intrinsic too. File bug I will assign it.

OK.

Andrew.