I agree with 1100 for this review (JDK7). I think that we shouldn't change from 1100 to 768 in JDK8 because this is a small performance enhancement. This will save time for fixing other bugs.
The performance enhancement could be smarter if we replace constant MAX_NDIGIT by some piece-linear function function maxNDigit(decExponent). See: http://cr.openjdk.java.net/~bpb/nDigits/java/double.pdf I'd like to postpone this to JDK9 . On Sat, Sep 14, 2013 at 4:39 AM, Brian Burkhalter < brian.burkhal...@oracle.com> wrote: > I would suggest leaving it at 1100 for this review (JDK7) and to 768 > (0x003) in JDK8. The latter will require another issue to be filed. > > On Sep 12, 2013, at 9:25 PM, Dmitry Nadezhin wrote: > > > For me, it is the only consideration. > > I'm sure in 768 because I proved it formally using ACL2 tool. > > > > > > On Fri, Sep 13, 2013 at 7:45 AM, David M. Lloyd <david.ll...@redhat.com > >wrote: > > > >> If that's the only consideration then just use 0x300 instead, which is > >> easier to read *and* makes more sense anyway, in the context of the > test. > >> > >> > >> On 09/12/2013 10:13 PM, Dmitry Nadezhin wrote: > >> > >>> Should we change conservative constant 1100 to optimal constant 768 ? > >>> My opinion is no (in JDK7), because the constant 1100 has lower cost of > >>> review. > >>> I mean that chances that a reviewer approves 1100 are higher than > chances > >>> that [s]he approves 768. >
