Java 7 была выпущена вчера, и некоторые ребята из сообщества Apache Lucene & Apache Solr быстро столкнулись с парой проблем, которые привели их к тому, что они активно отвергают Java 7, и посоветовали кому-то еще сделать то же самое. Член общего управления Apache Lucene Уве Шиндлер сделал даже общее предупреждение . Но что именно не так с Java 7, и почему бы вам не использовать его, подождав почти пять лет? Давайте посмотрим на это.
Дело не в Java 7, а в JVM
Прежде всего, речь идет не о Java 7 в целом, а о JSM HotSpot. Релиз GA содержит три ошибки ( 7070134 ,
7044738 и
7068051 ), которые могут повлиять на пользователей с ошибками
JVM или с ошибочными вычислениями.
Hotspot аварийно завершает работу с sigsegv от PorterStemmer
. Первая проблема связана с неправильной оптимизацией компилятора, которая изменила оптимизацию цикла. Проблема в том, что эта функция JVM
включена по
умолчанию, поэтому вы должны явно отключить ее, добавив -XX: -UseLoopPredicate в качестве аргумента. Если вы хотите попробовать это самостоятельно, смахните на
Stemmer.java , разумную базу данных толстых слов (есть некоторые там) и скомпилируйте и запустите ее для текстового файла. Что вы увидите, так это то, что ваша JVM падает с фатальной ошибкой.
# A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000026536da, pid=5432, t id=6568 # # JRE version: 7.0-b135 # Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b05 mixed mode windows-amd64 compressed oops) # Problematic frame: # J Stemmer.step4()V
Это происходит непосредственно во время выполнения кода, поэтому вы не будете испытывать это с JDK 1.6. Особенно Lucene имеет некоторые более недавние работы происходит с помощью более гибкого механизма индексации на основе алгоритма
называется
PulsingCodec особенно это сильно зависит от ошибки.
Оптимизация с циклическим развертыванием приводит к неверному результату.
Эта ошибка относится к части «неправильных вычислений» моего вводного раздела. В очень редких случаях, когда
компиляция OSR (On-Stack Replacement)
выполняется для вложенных циклов, поток управления прерывается и зависимости памяти не учитываются. Это приводит к дублированию клонов, которые изменяют результаты. (Если вы хотите узнать больше о
деталях компиляции, взгляните на этот
старый обзор
(PDF)
Минимальный обходной путь — добавить -XX: LoopUnrollLimit = 1 в качестве аргумента.
Предикат цикла клонирования при отключении цикла
Это
ошибка, которая относится к более старому
запросу функции . Это
введение, наконец, привело к новой ошибке. Недействительные статистические данные jvm приводят к сбою jvm с оптимизацией цикла снова.
Нижняя линия
Вы могли бы быть затронуты. В настоящее время, в основном, только если у вас есть некоторые части в вашем программном обеспечении, которые широко используют методы оптимизации, которые не работают. Но для средних случаев использования это не повлияет на вас. В целом это также повлияет на пользователей Java 6, но только если они используют параметры оптимизации, которые по умолчанию включены в Java 7 (-XX: + OptimizeStringConcat или -XX: + AggressiveOpts). Эти проблемы были обнаружены только за 5 дней до официальной Java 7 выпуска, поэтому у Oracle не было времени, чтобы исправить эти ошибки. На данный момент кажется, что они пытаются включить это либо в следующий, либо во второй сервисный выпуск. И наконец, что не менее важно, исходный код открыт, поэтому любой, кто достаточно упрям, чтобы в него вникнуть, может исправить ситуацию.
С http://blog.eisele.net/2011/07/dont-use-java-7-are-you-kidding-me.html