RFR: 8046943: RSA Acceleration (original) (raw)

Andrew Haley aph at redhat.com
Mon Jun 29 09:32:47 UTC 2015

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 MONTGOMERYINTRINSICTHRESHOLD = 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\sharedRuntimex8664.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.

More information about the hotspot-compiler-dev mailing list