RFR: 8046943: RSA Acceleration
vladimir.kozlov at oracle.com
Mon Jun 29 08:37:44 UTC 2015
Did you file RFE for this change? 8046943 is JEP.
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;
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.
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.
More information about the hotspot-compiler-dev