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:+OptimizeStringConcat or -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 -XX:-UseLoopPredicate flag.
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.