Rasmussen's hint would work were the number parsing in Oracle's JDK implemented in in C.

Volatile keyword in Java does not guarantee writing to memory and reading it back (http://java.sun.com/docs/books/jls/third_edition/html/classe...), but using strictfp as a modifier to the method should cause the usage of strict IEEE 64-bit floating point.

Well, the underlying JVM is written in C (C++ actually) along with a bunch of assembly. I figured this needs to be fixed at the JVM level and as such the fix might very well be a single "volatile" addition like it was for PHP.

Yeah, the JVM is written in C++ but the problem is in Oracle's JDK written in Java. More specifically, line 1596 in FloatingDecimal.java (http://www.docjar.com/html/api/sun/misc/FloatingDecimal.java...) is the only place in the correctionLoop that can cause infinite looping. I do not purport to understand what the ulp-function does but clearly it does produce the denormal number we would want.

The interesting value here (dValue) is double but the method is without strictfp-qualifier and thus allowed to use not-quite IEEE-754 doubles.

Were the problem at JVM level, I would think that many numeric libraries written in Java would not work either and the problem would've been spotted earlier.

Edit: Thought Markdown syntax for links was in use here.

So a Java double by default allows extended precision beyond the actual double precision the type implies? I can see why it is useful for certain apps to have this capability, and it makes the problem for Java much like the problem for gcc. Most people don't know about it and can be bitten by it, as we have seen, but there are also apps that make use of this extra precision. And yes, I don't know much about Java internals.