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.giulie...@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
