JEP 177: Optimize java.text.DecimalFormat.format
Author  Joseph D. Darcy 
Owner  Joe Darcy 
Created  2013/02/10 20:00 
Updated  2014/11/03 23:59 
Type  Feature 
Status  Closed / Delivered 
Component  corelibs 
Scope  JDK 
Discussion  core dash libs dash dev at openjdk dot java dot net 
Effort  M 
Duration  L 
Priority  4 
Reviewed by  Alan Bateman, Olivier Lagneau 
Endorsed by  Mark Reinhold 
Release  8 
Issue  8046167 
Summary
Optimize java.text.DecimalFormat.format
by taking advantage of
numerical properties of integer and floatingpoint arithmetic to
accelerate cases with two or three digits after the decimal point.
Goals
Make common usages of DecimalFormat
faster.
Success Metrics
At least a 2X speedup on microbenchmarks of interest.
Description
The decimal format conversions of most interest are for those with two and three digits after the decimal point. Rather than perform expensive floatingpoint divisions to isolate and round the fractional digits, a floatingpoint multiply of the fractional portion by 100.0 or 1000.0 can be performed, the product converted to an integer value, and then the resulting integer converted to decimal. While this process is faster, care must be taken to avoid doublerounding and other numerical hazards.
Case analysis using properties of which fractional decimal values can be exactly represented in binary reduces rounding postmultiply to a look up table style computation.
Testing
Besides running existing JCK and regression tests, new tests targeting the boundary cases of the optimized code path will be developed. In addition, the performance of the code will be assessed using microbenchmarks on contemporary hardware platforms.
Risks and Assumptions
Exploratory work with the optimized implementation revealing a
longstanding numerical bug in DecimalFormat
: some near halfway cases
did not round correctly. The specification of DecimalFormat
is being
amended in Java SE 8 to clearly require correct rounding all the time.
Impact

Compatibility: On JDK 7, (correct) but altered numerical behavior will only be enabled under an aggressive optimization flag to limit behavioral compatibility impact in that release train. In Java SE 8, the correct numerical behavior will always be required by the specification.

Performance/scalability: Many common cases will go faster with the new algorithm; other cases will fall back to using the older code.

TCK: Some new test cases in JCK 8 would be helpful.