有关此问题的更新 - 见下文.
我遇到了一个(至少对我来说是可重现的)JVM 崩溃(不是 OutOfMemoryError)(崩溃的应用程序是eclipse 3.6.2).但是,查看崩溃日志让我想知道:
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]
我使用的是 Windows XP 32 位 SP3.我有 4GB 内存.根据任务管理器,在启动应用程序之前,我有 2 GB 可用空间(+ 1 GB 系统缓存也可能被释放.).我肯定有足够的空闲 RAM.
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.
从开始到崩溃,我使用 visualvm 和 jconsole 记录了 JVM 内存统计信息.我获取了直到崩溃前最后一刻的内存消耗统计信息.
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:
我正在使用参数运行应用程序(jre 6 update 25,服务器 vm):
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
问题:
谁能帮我弄清楚这里出了什么问题?
Who can help me to figure out what is going wrong here?
(注意:我最近从 Eclipse 3.4.2 升级到 Eclipse 3.6.2,从 Java 5 升级到 Java 6.我怀疑崩溃和这些更改之间存在联系,因为我以前没有见过这些)
(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)
更新
这似乎是一个 JVM 错误 在 Java 6 Update 25 中引入,与新的 jit 编译器有关.另请参阅此博客条目.根据博客,这个错误的修复应该是下一个 java 6 更新的一部分.与此同时,我在崩溃期间获得了本机堆栈跟踪.我已经更新了上面的崩溃日志.
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.
建议的解决方法,使用 VM 参数 -XX:-DoEscapeAnalysis
有效(至少它显着降低了崩溃的可能性)
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 不正确.https:///blogs.sap.com/2019/10/07/does-32-bit-or-64-bit-jvm-matter-anymore/
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/
由于您使用的是 Windows-XP,因此您只能使用 32 位 JVM.
Since you are on Windows-XP you are stuck with a 32 bit JVM.
在 Windows 上的 32 位 VM 上,最大堆为 1.5GB.开始时您的内存为 1412MB,没有线程.您是否尝试减小交换堆栈大小 -Xss,是否尝试消除最初分配的 PermSize:-XX:PermSize=128m?听起来这是一个日食问题,而不是内存问题本身.
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.
您可以迁移到不同机器上的更新 JVM 或不同(64 位)JVM 吗?即使您的目标是 windows-XP,也没有理由在其上开发,除非您必须这样做.Eclipse 可以轻松地在远程机器上运行、调试和部署代码.
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 的 JVM 可以不同于您在 Eclipse 中运行或使用 Eclipse 运行的 JVM.Eclipse 是一头记忆猪.您可以消除不必要的 eclipse 插件以使用更少的 eclipse 内存,它提供了您可能不需要或不想要的开箱即用的东西.
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.
尝试清空引用(以消除循环不可回收的 GC 对象),重新使用分配的内存,使用单例,并分析您的内存使用情况以消除不必要的对象、引用和分配.其他提示:
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:
这篇关于Java 6 Update 25 VM 崩溃:内存不足的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!