JDK-6622432 : RFE: Performance improvements to java.math.BigDecimal
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.math
  • Affected Version: 6,7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_nevada,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-10-27
  • Updated: 2020-08-11
  • Resolved: 2009-01-30
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
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
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:

*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.


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.

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.

EVALUATION See comments for details of the fix.