Continuing from the end of this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022399.html ...
Issue: https://bugs.openjdk.java.net/browse/JDK-4891331 Webrev: http://cr.openjdk.java.net/~bpb/4891331/webrev.2 After running more micro-benchmark performance tests using a threshold on the int-length of BigInteger above which squaring code is used for multiply(this), the value 20 appears more apropos. This is the value in the updated webrev. This threshold appears to prevent regressions across the array of machines tested (Linux, Mac, Windows, AMD, Intel). In some cases of course, the threshold prevents performance improvement which would otherwise occur. This is the cost of avoiding regressions. It should be noted that a small regression, on the order of 1%-3% is often observed for the case of unity int-length, i.e., when the BigInteger is equivalent to an int. This is apparently the cost of the added conditional val == this. It does not seem to me however to be of sufficient import to argue against going forward with the patch. Thanks, Brian
