Обновленную информацию по этому вопросу см. ниже.
Я испытываю (воспроизводимый, по крайней мере, для меня) JVM сбой (не OutOfMemoryError) (аварийное завершение приложения - eclipse 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]
Я использую 32-разрядную версию Windows XP SP3. У меня 4 ГБ ОЗУ. Перед запуском приложения у меня было 2 ГБ свободного места в соответствии с диспетчером задач (+ 1 ГБ системного кеша, который также мог быть освобожден). У меня определенно достаточно свободной оперативной памяти.
С самого начала до сбоя я регистрировал статистику памяти JVM с помощью visualvm и jconsole. Статистику потребления памяти я получил до последних моментов перед сбоем.
Статистика показывает следующие размеры выделенной памяти:
- HeapSize: 751 МБ (использовалось 248 МБ)
- Non-HeapSize (PermGen и CodeCache): 150 МБ (использовалось 95 МБ)
- Размер областей управления памятью (Edenspace, Old-gen и т. Д.): 350 МБ
- Размер стека потоков: 17 МБ (согласно oracle и из-за того, что работает 51 поток)
Я запускаю приложение (jre 6 update 25, server vm), используя параметры:
-XX:PermSize=128m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=96m
-Xms500m
-Xmx1124m
Вопрос:
- Почему происходит сбой JVM, когда очевидно, что на виртуальной машине и ОС достаточно памяти?
Я думаю, что с указанными выше настройками я не могу достичь 32-разрядного лимита в 2 ГБ (1124 МБ + 192 МБ + 96 МБ + поток стеки ‹2ГБ). В любом другом случае (слишком много выделения кучи) я бы скорее ожидал OutOfMemoryError, чем сбой JVM
Кто может помочь мне разобраться в том, что здесь не так?
(Примечание: я недавно обновился до Eclipse 3.6.2 с Eclipse 3.4.2 и с Java 5 до Java 6. Я подозреваю, что существует связь между сбоями и этими изменениями, потому что я не видел их раньше)
ОБНОВЛЕНИЕ
Похоже, это ошибка JVM введен в Java 6 Update 25 и имеет какое-то отношение к новому компилятору jit. См. Также эту запись в блоге. Согласно блогу, исправление этой ошибки должно быть частью следующих обновлений Java 6. Между тем, во время сбоя у меня была трассировка нативного стека. Я обновил приведенный выше журнал сбоев.
Предлагаемый обходной путь с использованием аргумента VM -XX:-DoEscapeAnalysis работает (по крайней мере, он заметно снижает вероятность сбоя)
PermSizeдо512mи добавите-XX:PermSize=512m, ошибка по-прежнему возникает? - person Buhake Sindi schedule 14.06.2011-XX:+DoEscapeAnalysis. Однако я не использую этот вариант. - person MRalwasser schedule 14.06.2011-XX:-DoEscapeAnalysis? - person Vineet Reynolds schedule 14.06.2011