Bug ID: JDK-6622432 RFE: Performance improvements to java.math.BigDecimal

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6	JDK 7	Other
6u14 b01Fixed	7Fixed	OpenJDK6Fixed

The profiling results from running derby benchmark inside SPECJvm2007 shows significant performance issue in our implementation of BigDecimal code. Here are couple hot methods showing inside both Sun & other profiling tools:

*setScale
*precision
*BigDecimal(...) /* various constructors. */

The other data point from some low level profiling tool shows we have significant higher number of division/multiplication operations than some of our competitors.

http://hg.openjdk.java.net/jdk/jdk/rev/dd6d609861f0
11-08-2020
EVALUATION One of the changes for the BigInteger improvement is to remove the implicit initialization for a few of fields such as "bitCount", "bitLength" & "lowestSetBit". The removal of initialization for "lowestSetBit" will affect the largest BigInteger values people working with theoretically. Generally speaking, BigInteger wasn't designed to handle such case, but standing on the cautious side is always good, so I am going to file a CCC request to cover that.
21-11-2008
EVALUATION I have a webrev at http://javaweb.sfbay/~xl116366/webrev/bigdecimal_opt for review. To ease future reference, here are some highlights for the changes which affect the performance significantly. 1. Make TENPOWERS array to be expandable so that we don't have to construct BigInteger of ten's power repeatedly. The default maximum size of the array is 304 which means it can hold up to 10**303. 2. Make digitLength to work efficiently by avoiding division operation which is generally considered as expensive. Use the TENPOWERS array which is now expandable, we can now apply the same trick for computing the integer length to these big integers. 3. Clean up MathContext to avoid creating unnecessary BigInteger objects, drop "dropDigits". 4. Have a trusted version of divide method to avoid repeatedly roundingMode checks.
07-12-2007
EVALUATION See comments for details of the fix.
29-10-2007

Duplicate :	JDK-6832035 - BigInteger and MutableBigInteger should use Integer bit-twiddling methods
Duplicate :	JDK-6348370 - java.math.BigInteger is not thread-safe immutable
Relates :	JDK-8035279 - Clean up internal deprecations in BigInteger
Relates :	JDK-2169668 - java.math.BigInteger.ZERO.multiply(null)
Relates :	JDK-8245304 - Re-examine ThreadLocal usage in java.math.BigDecimal
Relates :	JDK-6838776 - Defer initialization of static fields in java.math.BigInteger
Relates :	JDK-6876282 - BigDecimal's divide(BigDecimal bd, RoundingFormat r) produces incorrect result
Relates :	JDK-6837951 - Incorrect answer while summing serialized / deserialized BigDecimals
Relates :	JDK-6819773 - BigDecimal.divide(BigDecimal,int,int) throws ArrayIndexOutofBoundsException under some circumstances
Relates :	JDK-6806261 - BigDecimal.longValueExact() method throws NullPointerException