We previously identified four phases of BigInteger performance improvement based on contributions from Alan Eliasen and Tim Buktu:
1) Multiplication and exponentiation - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 2) Conversion to string - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 3) Division - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014319 4) Multiplication and division of very large integers - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014320 The current status by phase is as follows: 1) 4837946 and 4646474 * Code reviewed by me and posted for public review - http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html. * Correctness verification partially complete. * Preliminary micro-benchmarking on development laptop. 2) 4641897 * Code reviewed by me but not yet posted. * Rudimentary micro-benchmarking on development laptop. 3) 8014319 No progress. 4) 8014320 No progress. On my development laptop, micro-benchmarking suggested that the values of the multiplication, squaring, and radix conversion algorithm crossover thresholds for phases 1 and 2 are significantly lower than they should be. On other, newer systems, the values appeared to be fairly close to appropriate values. The current plan is in effect first to identify reasonable values for these thresholds which do not exhibit performance regressions on the matrix of platforms of interest. The idea has also surfaced to define system properties by means of which the thresholds could be set by applications. Given the availability of such properties, the threshold values estimated by micro-benchmarking would be the default values if no system property were specified for the threshold of interest. Work on threshold evaluation and the review and validation testing of phase 3 will continue in parallel with other work, some of which will likely affect the same code in which case the changes will be merged. Brian
