4 ms·
I remember when everyone was bashing PHP (http://news.ycombinator.com/item?id=2066084 http://news.ycombinator.com/item?id=2066084) when they were bitten by the
by pilif 16y ago
I remember when everyone was bashing PHP (http://news.ycombinator.com/item?id=2066084 http://news.ycombinator.com/item?id=2066084) when they were bitten by the same issue. Then there were articles about this being maybe a GCC bug or at least design issue but people were still saying that it's PHP's duty to take care of this.
I was always afraid that this might bite other environments too as the code that caused the issue in PHP was apparently taken from elsewhere (see http://blog.andreas.org/display?id=9 http://blog.andreas.org/display?id=9 for a detailed analysis of the problem). Now this is turning out to be true.
- SingAlong 16y agoRasmus just tweeted about it: Java's turn to deal with the x87 register issue. Here's a hint Oracle, "volatile" http://twitter.com/rasmus/status/32365768603602944 http://twitter.com/rasmus/status/32365768603602944
- eonwe 16y agoRasmussen'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/classes.html#36930 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.
- rll 16y agoWell, 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.
- eonwe 16y agoYeah, 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.html#1591 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.
- rll 16y agoSo 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.
- Uchikoma 16y agoYes, astonishing how Oracle (and others) didn't check their code when this surfaced in PHP to determine if they are affected too.
- gaius 16y agoYet not astonishing how the GCC team didn't fix it once, for everyone? PS I am pretty sure Oracle, at least on Sun, used SPARCworks compiler, not GCC, from linking C++ against their libs.
- pilif 16y agoThey did fix it in 4.5 by having you to pass -fexcess-precision=standard Which apparently defaults to not being standard compliant.
- krakensden 16y agoit depends on how you define 'standard compliant', and fiddling with floating point behavior tends to break programs and make people angry.