The post on http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012... describes a (on first sight) trivial bug when parsing strings into Java Double objects. Runtime (java app hang): class runhang { public static void main(String[] args) { System.out.println("Test:"); double d = Double.parseDouble("2.2250738585072012e-308"); System.out.println("Value: " + d); } } DevTime (javac hang): class compilehang { public static void main(String[] args) { double d = 2.2250738585072012e-308; System.out.println("Value: " + d); } } The problem is that the estimation of halfUlp is too small in the case where the larger alternative is normal and the smaller is denormal. In this case, the first estimate for 2.22507385850720120e-308 is 2.225073858507200889...e-308, an error of -3.109754e-324 and the second is 2.225073858507201383...e-308, an error of 1.830902e-324 so the second should be chosen. Unfortunately, in the second case the calculated halfUlp is 2^-1076, which is wrong because the next lower number will be denormal. Because denormals don't have the implied 1 bit, they are less accurate than normals, so the next lower number will have the same precision as this number, not twice the precision. Therefore, the estimated halfUlp is too large: it must be 2^-1075. So, I think this may be the correct fix: --- /local/openjdk/jdk6/jdk/src/share/classes/sun/misc/FloatingDecimal.java 2011-02-01 15:28:10.550913741 +0000 +++ /local/icedtea6/openjdk/jdk/src/share/classes/sun/misc/FloatingDecimal.java2011-02-02 12:07:22.292913754 +0000 @@ -1549,7 +1548,7 @@ if ( (cmpResult = bigB.cmp( bigD ) ) > 0 ){ overvalue = true; // our candidate is too big. diff = bigB.sub( bigD ); - if ( (bigIntNBits == 1) && (bigIntExp > -expBias) ){ + if ( (bigIntNBits == 1) && (bigIntExp-1 > -expBias) ){ // candidate is a normalized exact power of 2 and // is too big. We will be subtracting. // For our purposes, ulp is the ulp of the Andrew.