Hi, Andrew
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;
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.
