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

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Jun 29 08:37:44 UTC 2015

Hi, Andrew

Did you file RFE for this change? 8046943 is JEP.

typo? "less" -> "more".

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

I am fine with JDK changes.

Would be nice to have a test for this change. Do existing tests cover this code?

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

Thanks, Vladimir

On 6/26/15 9:25 AM, Andrew Haley wrote:

On 06/19/2015 09:34 AM, Andrew Haley wrote:

On 18/06/15 20:28, Vladimir Kozlov wrote:

Yes, it is a lot of handwriting but we need it to work on all OSs. Sure, I get that. I knew there would be a few goes around with this, but it's worth the pain for the performance improvement. I made some changes, as requested. Everything is now private static final. The libcall now only calls the runtime code: all allocation is done in Java code. I tested on Solaris using Solaris Studio 12.3 tools, and it's fine. There's one thing I'm not sure about. I now longer allocate scratch memory on the heap. That was only needed for extremely large integers, larger than anyone needs for crypto. Now, if the size of an integer exceeds 16384 bits I do not use the intrinsic, and this allows it to use stack-allocated memory for its scratch space. The main thing I was worried about is that the time spent in Montgomery multiplication. The runtime of the algorithm is O(N^2); if you don't limit the size, the time is unbounded, with no safepoint delay. This would mean that anyone who passed an absurdly large integer to BigInteger.modPow() would see the virtual machine apparently lock up and garbage collection would not run. I note that the multiplyToLen() intrinsic has the same problem. http://cr.openjdk.java.net/~aph/8046943-hs-3/ http://cr.openjdk.java.net/~aph/8046943-jdk-3/ Andrew.

More information about the hotspot-compiler-dev mailing list