RFR: 8046943: RSA Acceleration
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 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.
More information about the hotspot-compiler-dev