Dmitry Nadezhin wrote:
Hello Joe,
Thank you for the sponsorship of the bug 4421494.
I can also prepare a fix for another related bug 4396272
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272
The bug 4396272 is blinking because it occurs only when HotSpot
chooses double value set and it doesn't occur
with double-extended-exponent value set.
The suggested fix will be in FloatingDecimal too, though in other line.
What is more convenient to you
a) if I combine both fixes of 4421494 and 4396272 in a single
changeset now;
b) if I postpone submitting of the fix 4396272 until 4421494 is in the
JDK
?
If the first fix is just a one-liner, combining the two fixes is easier
overall.
Cheers,
-Joe
-Dima
Dmitry Nadezhin wrote:
http://bugs.sun.com/view_bug.do?bug_id=4421494
https://bugs.openjdk.java.net/show_bug.cgi?id=100119
Summary: This old bug report says that Double.parseDouble(s) hangs
for decimal strings
in range (Double.MIN_NORMAL-0.5*Double.MIN_VALUE,Double.MIN), and
returns
incorrect result for decimal string
Double.MIN_NORMAL-0.5*Double.MIN_VALUE.
This is because current code in FloatingDecimal.doubleValue()
incorrectly
defines the condition when nextDown(dValue) - dValue ==
-0.5*ulp(dValue). The
current code considers that these are all numbers 2^n which are
represented as
normal doubles, and nexDown(dValue) - dValue == -1.0*ulp(dValue) for
other
doubles (subnormal or not 2-powers).
However, this is not correct for dValue == Double.MIN_VALUE, because
nextDown(Double.MIN_NORMAL) - Double.MIN_NORMAL ==
-1.0*ulp(Double.MIN_NORMAL).
The suggested change
- if ( (bigIntNBits == 1) && (bigIntExp >
-expBias) ){
+ if ( (bigIntNBits == 1) && (bigIntExp >
-expBias+1) ){
redefines the condition so that dValue == Double.MIN_NORMAL doesn't
satisfy it.
-Dima
Hello.
Thank you for the proposed fix; that certainly sounds like a
plausible cause of the problem.
I'm a bit swamped now, but I'll try to look at verifying the fix and
sponsoring getting it back into the JDK within the next few weeks.
-Joe
