[PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

[Brian Burkhalter]

Hi Raffaello,

Here is the webrev version of the patch:

http://cr.openjdk.java.net/~bpb/4511638/webrev.00/

On Sep 26, 2018, at 10:39 AM, raffaello.giulietti at gmail.com wrote:

> To address and overcome both issues, a new specification in the form of
> Javadoc associated to Double.toString(double) and Float.toString(float)
> is proposed, along with a clean-room re-implementation.

Thank you for the contribution.

> The intent of the specification is to explicitly separate the
> determination of the unique decimal number to represent the floating
> point argument (double/float) from its formatting as a String.
> 
> The clean-room implementation enjoys the following properties:
> * […]
> * The new Double.toString(double) speedup with respect to the current
> implementation, according to jmh, is better than 13x when measured over
> bitwise uniformly distributed random samples.

I have corroborated this performance improvement on my MacBook Pro.

> * In the case of Double.toString(double), as it is infeasible to test
> all results, several billions of random doubles have been extensively
> tested.

I likewise ran a “round trip” test similar to

Random.nextLong() -> Double.longBitsToDouble -> d0
d0 -> Double.toString -> Double.valueOf -> d1
Compare d0 vs. d1

which ran for 40 hours (366 billion round trips) on my MacBook Pro without error.

> Since there's a change in the specification, according to my sponsor and
> the formalities it has to undergo a CSR.

I will update the CSR.

> The submitted code contains both the changes to the current
> implementation and extensive jtreg tests.
> 
> While I've struggled to keep the code within the 80 chars/line limit,
> mercurial still generates longer lines. Thus, to avoid possible problems
> with the email systems, the code is submitted both inline and as an
> attachment. Hope at least one copy makes its way without errors.

Sounds good.

Thanks,

Brian