Java 6 Update 25 Сбой виртуальной машины: недостаточно памяти - PullRequest
Новая
       34

Java 6 Update 25 Сбой виртуальной машины: недостаточно памяти

20 голосов
/ 14 июня 2011

Обновление этого вопроса - см. Ниже.

Я испытываю (воспроизводимый, по крайней мере для меня) jvm сбой ( не OutOfMemoryError ) (сбой приложения - затмение 3.6.2).Однако, глядя на журнал сбоев, я удивляюсь: 

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 65544 bytes for Chunk::new
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.

Current thread (0x531d6000):  JavaThread "C2 CompilerThread1" daemon 
[_thread_in_native, id=7812, stack(0x53af0000,0x53bf0000)]

Stack: [0x53af0000,0x53bf0000],  sp=0x53bee860,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x1484aa]
V  [jvm.dll+0x1434fc]
V  [jvm.dll+0x5e6fc]
V  [jvm.dll+0x5e993]
V  [jvm.dll+0x27a571]
V  [jvm.dll+0x258672]
V  [jvm.dll+0x25ed93]
V  [jvm.dll+0x260072]
V  [jvm.dll+0x24e59a]
V  [jvm.dll+0x47edd]
V  [jvm.dll+0x48a6f]
V  [jvm.dll+0x12dcd4]
V  [jvm.dll+0x155a0c]
C  [MSVCR71.dll+0xb381]
C  [kernel32.dll+0xb729]

Я использую Windows XP 32-bit SP3.У меня 4 ГБ оперативной памяти.Перед запуском приложения у меня было 2 ГБ свободного места в соответствии с диспетчером задач (+ 1 ГБ системного кэша, который также может быть освобожден).У меня определенно достаточно свободной оперативной памяти.

С самого начала и до сбоя я регистрировал статистику памяти jvm с помощью visualvm и jconsole.Я получил статистику потребления памяти до последних мгновений до сбоя.

Статистика показывает следующие выделенные размеры памяти:

  • Размер кучи: 751 МБ (используется 248 МБ)
  • Non-HeapSize (PermGen & CodeCache): 150 МБ (используется 95 МБ)
  • Размер областей управления памятью (Edenspace, Old-gen и т. Д.): 350 МБ
  • Размеры стека потоков: 17 МБ (в соответствии с oracle и из-за того, что запущен 51 поток)

Я запускаю приложение (jre 6 update 25, vm сервера), используя параметры: 

-XX:PermSize=128m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=96m
-Xms500m
-Xmx1124m

Вопрос:

  • Почему происходит сбой jvm, когда на виртуальной машине и операционной системе явно достаточно памяти?
    При указанных выше настройках я думаю, что не могу достичь 32-битного предела в 2 ГБ (1124 МБ + 192 МБ + 96 МБ + потокстеки <2 ГБ).В любом другом случае (слишком большое выделение кучи) я предпочел бы ожидать ошибку OutOfMemoryError, а не аварию jvm </li>

Кто может помочь мне выяснить, что здесь происходит не так?

(Примечание: я недавно обновился до Eclipse 3.6.2 с Eclipse 3.4.2 и с Java 5 до Java 6. Я подозреваю, что существует связь между сбоями и этими изменениями, потому что я не видел их раньше)

ОБНОВЛЕНИЕ

Кажется, что это ошибка jvm , представленная в Java 6 Update 25 и есть чем занятьсяс новым JIT-компилятором.См. Также эту запись в блоге. Согласно блогу, исправление этой ошибки должно быть частью следующего обновления Java 6.Тем временем я получил трассировку собственного стека во время сбоя.Я обновил приведенный выше журнал сбоев.

Предложенный обходной путь с использованием аргумента vm -XX:-DoEscapeAnalysis работает (по крайней мере, он заметно снижает вероятность сбоя)

Ответы [ 2 ]

1 голос
/ 10 июля 2012

Я наткнулся на похожую проблему на работе. Мы установили -Xmx65536M для нашего приложения, но продолжали получать точно такие же ошибки. Забавно то, что ошибки возникали всегда в то время, когда наше приложение фактически выполняло довольно легкие вычисления, условно говоря, и, следовательно, было далеко от этого предела.

Мы нашли возможное решение проблемы онлайн: http://www.blogsoncloud.com/jsp/techSols/java-lang-OutOfMemoryError-unable-to-create-new-native-thread.jsp, и, похоже, это решило нашу проблему. После снижения -Xmx до 50G у нас не было ни одной из этих проблем.

Что на самом деле происходит в деле, нам все еще неясно.

0 голосов
/ 14 июня 2011

JVM имеет свои собственные ограничения, которые остановят его задолго до того, как он достигнет пределов физической или виртуальной памяти.Вам необходимо настроить размер кучи, соответствующий другому из флагов -X.(Я думаю, что это что-то креативное, например -XHeapSizeLimit, но я проверю через секунду.)

Вот и мы :

-Xmsn Укажите начальный размерв байтах пула выделения памяти.Это значение должно быть кратно 1024 больше 1 МБ.Добавьте букву k или K для обозначения килобайт, или m или M для обозначения мегабайт.Значение по умолчанию составляет 2 МБ.Примеры: 

   -Xms6291456
   -Xms6144k
   -Xms6m

-Xmxn Укажите максимальный размер в байтах пула выделения памяти.Это значение должно быть кратно 1024 больше 2 МБ.Добавьте букву k или K для обозначения килобайт, или m или M для обозначения мегабайт.Значение по умолчанию составляет 64 МБ.Примеры: 

   -Xmx83886080
   -Xmx81920k
   -Xmx80m
...