Сбой JVM в CompilerThread

Question

Мое java-приложение почти постоянно падает при попытке скомпилировать определенный метод (это всегда один и тот же метод) с SIGSEGV:

 A fatal error has been detected by the Java Runtime Environment:

  SIGSEGV (0xb) at pc=0x00002aaaab6642a5, pid=8348, tid=1087596864

 JRE version: 6.0_16-b01
 Java VM: Java HotSpot(TM) 64-Bit Server VM (14.2-b01 mixed mode linux-amd64 )
 Problematic frame:
 V  [libjvm.so+0x5332a5]

 An error report file with more information is saved as:
 hs_err_pid8348.log

 If you would like to submit a bug report, please visit:
   http://java.sun.com/webapps/bugreport/crash.jsp

Журнал сбоя (интересные части ...):

 A fatal error has been detected by the Java Runtime Environment:

  SIGSEGV (0xb) at pc=0x00002aaaab6642a5, pid=8348, tid=1087596864

 JRE version: 6.0_16-b01
 Java VM: Java HotSpot(TM) 64-Bit Server VM (14.2-b01 mixed mode linux-amd64 )
 Problematic frame:
 V  [libjvm.so+0x5332a5]

 If you would like to submit a bug report, please visit:
   http://java.sun.com/webapps/bugreport/crash.jsp

---------------  T H R E A D  ---------------

Current thread (0x00002aab1f7ac800):  JavaThread "CompilerThread0" daemon [_thread_in_native, id=8694, stack(0x0000000040c36000,0x00000000
40d37000)]

Я пытался создать дамп ядра и подключиться к нему, но не смог найти там CompilerThread (возможно, он был убит, если

)

Answer 1

Опубликуйте всю страницу (с дополнительной информацией о библиотеках) со стеком и больше, если сможете.Если вы видите дамп ядра, вы не увидите НИКАКОЙ нити.

Если проблема связана с zlib (ZipEntry), вам не повезло ...zlip с очень очень жирным шрифтом, и это происходит, если почтовый индекс изменяется после открытия.Я до сих пор удивляюсь, почему Sun / Oracle использует собственную библиотеку для обработки zip-файлов, поскольку выполнение ее на чисто java более стабильно и ... в 2 раза быстрее (с точки зрения производительности).

Answer 2

Вручную оптимизируйте используемый метод.

Current thread (0x00002aab1f7ac800): JavaThread "CompilerThread0" daemon [_thread_in_native, id=8694, stack(0x0000000040c36000,0x00000000 40d37000)]

Чуть ниже этой линии вы должны увидеть конкретный метод, который механизм горячей точки пытался оптимизировать.Вероятно, вы столкнулись с некоторым кодом в горячей точке, которая имеет некоторые проблемы.Будет очень трудно точно определить, какой код был использован и почему.

У меня возникла эта проблема, и я решил ее.Метод был написан очень неоптимизированным способом.Были созданы ненужные структуры данных, добавлены дополнительные циклы, а также дополнительные переменные созданы и использованы только один раз.Я итеративно оптимизировал все больше и больше этого метода, пока он, наконец, не выдал исключение после последней итерации, которая была довольно низкоуровневой, почти безумно оптимистичной.ошибка в некоторой подпрограмме оптимизации байт-кода, которая запускалась в движке горячей точки.Там почти нет возможности точно знать, что происходит.Но я думаю, что, оптимизируя код вручную, я оптимизировал байт-код таким образом, чтобы механизм горячей точки больше не выполнял подпрограмму с ошибками.

Я знаю, что в этом нет ничего определенного, но я надеюсь, чтоИстория может помочь вам и будущим посетителям.Желаем удачи!

Answer 3

Если это опция, вы можете исключить метод, вызывающий сбой, из среды выполнения, добавив этот параметр в вызов исполняемого файла java. -XX:CompileCommand=exclude,com/path/to/class/in/Jar$InnerClassIfAny.methodName

Имя класса и метода, которые вызывают сбой, можно найти в отчете о сбое (hs_err_pidxxxx.log) прямо над

--------------- P R O C E S S ---------------

знак.

Примечание: в среде Unix внутренний класс (если есть) должен быть экранирован следующим образом \$ вместо $.

Answer 4

JRE версии 6.0_16 довольно старая. Я рекомендую перейти на текущую версию JRE, очень вероятно, что этот сбой будет исправлен.