JDK 8 RFR 8029514: java/math/BigInteger/BigIntegerTest.java failing since thresholds adjusted in 8022181

Alan Eliasen eliasen at mindspring.com
Thu Dec 5 02:20:24 UTC 2013

> On 12/4/2013 1:34 PM, Brian Burkhalter wrote:
>> Hello,
>> Issue:    https://bugs.openjdk.java.net/browse/JDK-8029514
>> Webrev:    http://cr.openjdk.java.net/~bpb/8029514/webrev/
>> The problem causing this failure is that the method getLower() used by
>> Karatsuba multiplication is expected to return an unsigned value but
>> instead returns 'this' if the parameter 'n' is not greater than the
>> int-length of the BigInteger on which it is invoked. For
>> multiplications in which there is a negative factor this could result
>> in an incorrect product being obtained.
>> The BigIntegerTest is also updated to reflect the modified thresholds
>> (should have been in the patch for 8022181 but was not …).

   Hmmm... it looks like that patch is correct and necessary if
getLower() is receiving negative numbers.  I'm not quite sure what
happened there.  My vague recollection was that at one point the
arguments to Karatsuba multiply were conditioned to always be positive
in the multiply() dispatching function, but that's apparently not the
case in the current code.

   Thanks for letting me know about this.  I didn't see the earlier bug
report or the report that the thresholds were being changed.  It would
seem to me that the new thresholds are quite a bit higher than is
optimal for the architectures I tested on (Linux 64-bit and Windows 32
bit, and a bit of Raspberry Pi Arm); I intentionally set my thresholds
to be quite high and conservative.  Is there a particular architecture
that requires the thresholds to be set that high?  What performance
effect do those higher thresholds have on the most common architectures?

  Alan Eliasen
  eliasen at mindspring.com

More information about the core-libs-dev mailing list