Java 6 Update 25 VM崩溃:内存不足 [英] Java 6 Update 25 VM crash: insufficient memory

问题描述

有关此问题的更新-参见下文.

我遇到了(至少对我而言是可复制的)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]

我正在使用Windows XP 32位SP3.我有4GB的RAM. 在启动应用程序之前，根据任务管理器，我有2 GB的可用空间(+ 1 GB的系统缓存，也可能会释放).我肯定有足够的可用RAM.

从开始到崩溃，我使用visualvm和jconsole记录了JVM内存统计信息. 我获取了直到崩溃前最后一刻的内存消耗统计信息.

统计信息显示以下分配的内存大小:

• 堆大小: 751 MB(已使用248 MB)
• 非堆大小(PermGen和代码缓存): 150 MB(已使用95 MB)
• 内存管理区域(Edenspace，Old-gen等)的大小: 350 MB
• 线程堆栈大小: 17 MB (根据 oracle 并且由于51个线程正在运行)

我正在使用以下参数运行应用程序(jre 6 update 25，服务器虚拟机):

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

问题:

• 当VM和OS上明显有足够的内存时，为什么JVM崩溃?
  通过以上设置，我认为我无法达到2GB的32位限制(1124MB + 192MB + 96MB +线程堆栈<2GB).在任何其他情况下(堆分配过多)，我宁愿期望OutOfMemoryError而不是JVM崩溃

谁可以帮助我弄清楚这里出了什么问题?

(注意:我最近从Eclipse 3.4.2升级到Eclipse 3.6.2，从Java 5升级到Java6.我怀疑崩溃和这些更改之间存在联系，因为我之前从未见过这些东西)

更新

这似乎是JVM错误 在 Java 6 Update 25 中引入，与新的jit编译器有关.另请参见此博客条目. 根据博客，此错误的修复应该是下一个Java 6更新的一部分. 同时，我在崩溃期间获得了本机堆栈跟踪.我已经更新了上面的崩溃日志.

使用VM参数-XX:-DoEscapeAnalysis的建议解决方法有效(至少显着降低了崩溃的可能性)

Windows的32位JVM上的

解决方案

2GB不正确. https://blogs.sap.com/2019/10/07/does-32-bit-or-64-bit-jvm-matter-anymore/

由于您使用的是Windows XP，因此您只能使用32位JVM.

在Windows上的32位VM上，最大堆为1.5GB.您从没有线程开始就拥有1412MB的空间.您是否尝试减小交换堆栈大小-Xss，并尝试消除最初分配的PermSize:-XX:PermSize = 128m?听起来这是一个月食问题，而不是一个内存问题.

您可以转移到另一台机器上的较新的JVM或不同的(64位)JVM吗?即使您的目标是Windows-XP，也没有理由在其上进行 develop 的开发，除非您必须这样做. Eclipse可以轻松地在远程机器上运行，调试和部署代码.

Eclipse的JVM可能不同于您在Eclipse或Eclipse中运行的事物的JVM. Eclipse是记忆中的猪.您可以消除不必要的eclipse插件以减少eclipse内存，它附带了您可能不需要或不需要的东西.

尝试使引用无效(以消除循环上无法收集的GC对象)，重新使用分配的内存，使用单例，并分析内存使用情况以消除不必要的对象，引用和分配.其他提示:

• 优先使用静态内存分配，即每个VM分配一次 动态.
• 避免在函数内创建临时对象-考虑使用reset()方法，该方法可以允许对象重复使用
• 避免String突变和自动装箱类型的突变.

For an update of this question - see below.

I experience a (reproducible, at least for me) JVM crash (not an OutOfMemoryError) (The application which crashes is eclipse 3.6.2). However, looking at the crash log makes me wonder:

#
# 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]

I am using Windows XP 32-bit SP3. I have 4GB RAM. Before starting the application I had 2 GB free according to the task manager (+ 1 GB system cache which might be freed as well.). I am definitely having enough free RAM.

From the start till the crash I logged the JVM memory statistics using visualvm and jconsole. I acquired the memory consumption statistics until the last moments before the crash.

The statistics shows the following allocated memory sizes:

• HeapSize: 751 MB (used 248 MB)
• Non-HeapSize(PermGen & CodeCache): 150 MB (used 95 MB)
• Size of memory management areas (Edenspace, Old-gen etc.): 350 MB
• Thread stack sizes: 17 MB (according to oracle and due the fact that 51 threads are running)

I am running the application (jre 6 update 25, server vm) using the parameters:

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

Question:

• Why does the JVM crash when there's obviously enough memory on the VM and OS?
  With the above settings I think that I cannot hit the 2GB 32-bit limit (1124MB+192MB+96MB+thread stacks < 2GB). In any other case (too much heap allocation), I would rather expect an OutOfMemoryError than a JVM crash

Who can help me to figure out what is going wrong here?

(Note: I upgraded recently to Eclipse 3.6.2 from Eclipse 3.4.2 and from Java 5 to Java 6. I suspect that there's a connection between the crashes and these changes because I haven't seen these before)

UPDATE

It seems to be a JVM bug introduced in Java 6 Update 25 and has something to do with the new jit compiler. See also this blog entry. According to the blog, the fix of this bug should be part of the next java 6 updates. In the meanwhile, I got a native stack trace during a crash. I've updated the above crash log.

The proposed workaround, using the VM argument -XX:-DoEscapeAnalysis works (at least it notably lowers the probability of a crash)

解决方案

2GB on 32-bit JVM on Windows is incorrect. https://blogs.sap.com/2019/10/07/does-32-bit-or-64-bit-jvm-matter-anymore/

Since you are on Windows-XP you are stuck with a 32 bit JVM.

The max heap is 1.5GB on 32 bit VM on Windows. You are at 1412MB to begin with without threads. Did you try decreasing the swap stack size -Xss, and have you tried eliminating the PermSize allocated initially: -XX:PermSize=128m? Sounds like this is an eclipse problem, not a memory-problem per-se.

Can you move to a newer JVM or different (64-bit) JVM on a different machine? Even if you are targeting windows-XP there is no reason to develop on it, unless you HAVE to. Eclipse can run, debug and deploy code on remote machines easily.

Eclipse's JVM can be different then the JVM of things you run in or with eclipse. Eclipse is a memory pig. You can eliminate unnecessary eclipse plug-ins to use less eclipse memory, it comes with things out of the box you probably don't need or want.

Try to null out references (to eliminate circularly un-collectible GC objects), re-use allocated memory, use singletons, and profile your memory usage to eliminate unnecessary objects, references and allocations. Additional tips:

• Prefer static memory allocation, i.e allocate once per VM as opposed to dynamically.
• Avoid creation of temporary objects within functions - consider a reset() method which can allow the object to reused
• Avoid String mutations and mutation of auto boxed types.

这篇关于Java 6 Update 25 VM崩溃:内存不足的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！