Java7 Hotspot Loop Bug Details
After Java7's GA release last week, an issue was discovered with one of the optimisations enabled by default with the new JIT. Although originally identified by a use-case in the Lucene search indexer, the problem may be more widespread in other codebases as well.
This prompted a number of alarmist articles, such as “Don't use Java 7 for anything” which implied that all loops were problematic. In fact, although there is a valid bug (in which loops may be incorrectly unrolled or cause SIGSEGV crashes), this optimisation bug has been present since Java 6 if either the
-XX:+AggressiveOpts optimisations are enabled.
In fact, the problem only occurs with specific loops (those which uses conditions which may be mutated by the loop body), as noted in the fix. The problem doesn't occur when running in
-Xint (in interpreted mode) but does occur when
-server mode, which most server-side applications are likely to use.
The fix will be available with Java 7 update 1 due to the public pressure on the bug's revelation if not seriousness. However, since Java 7 has only just been released it would be unlikely to be used in production environments yet, and it wouldn't be the first issue to be found (and subsequently fixed in a later release). In the meantime, the issue notes this specific optimisation can be switched off with
Uwe Schindler, who identified the original problem with the Lucene and Solr projects, has a detailed story behind the bug, including the reactions (and over-reactions) that subsequently occurred. He does however note that the reaction over twitter and subsequent posts are likely to have raised the priority of the bug and of its inclusion in Java 7 update 1 instead of being delayed out to Java 7 update 2. However, he notes that although the high priority bug (which causes the SIGSEGV) is likely to be included in Java 7 update 1, there are still two other bugs which can cause problems that are still rated as medium priority.
Since these optimisations kick in after the loop has executed a minimum of 10,000 times, it may not be something that is seen by many tests, as Robert Muir explains in detail. Fixes have been made available and will be available in a future Java 7 update. In the meantime, using the flag to disable the LoopPredicate optimisation will allow Java 7 to run without experiencing any of these problems.
"Don't use Java 7" seems like good advice at this point
While I agree that it's alarmist to suggest that all loops are problematic, I can't think of any reason why someone would switch to using Java 7 in production at the moment.
Nobody should. I can see it for prototyping new development with an expectation to go into production with a later JDK 7 release.
Oracle clearly screwed up here, and that message needs to go out loud and clear.
That's a little bit alarmist. It is not as if Oracle would need the blogosphere to cry havoc to be aware of it. Remember when Java SE 6u21 came out and the developers rightly changed the COMPANY_NAME string in jvm.dll to "Oracle"?
That broke every Eclipse version since 3.3. And that was because Eclipse was looking at the COMPANY_NAME string to pass jvm arguments (instead of using the kosher way via the java.vm.vendor property.)
The breakage was arguably NOT Oracle's fault (as it wasn't a bug of the JVM but on clients for not relying on JVM properties), and the company did not have an obligation to fix it. And yet, Oracle quickly reverted back that change, removing its name from the property that is rightfully theirs.
So what precedence exists that requires "the message to go out loud and clear"? And a bug like that, although undesirable, it should not be unexpected. It's not like they are implementing web pages (it's an advanced JVM with a state-of-the-art JIT to boot.) Bugs will happen; this is the first major release (which no one should use it in production anyways); and Oracle will fix it rather quickly (as historical precedence suggests) in the next milestone release.
Plus, there are workarounds - don't use -XX:+OptimizeStringConcat or -XX:+AggressiveOpts. Very few would actually need that, and I'll posit that those who truly need these aren't candidates for jumping into the JDK 7 bandwagon yet.
Check out this article for a different perspective on the bug, not being that bad.