Java 6 Update 25 VM崩溃：内存不足
有关此问题的更新 - 请参阅下文。
我遇到了（可重现，至少对我来说）JVM 崩溃（不是内存不足错误） （崩溃的应用程序是 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 内存。 在启动应用程序之前，根据任务管理器，我有 2 GB 可用空间（+ 1 GB 系统缓存也可能被释放。）。我绝对有足够的可用内存。
从开始到崩溃，我使用 VisualVM 和 jconsole 记录了 JVM 内存统计信息。 我获取了崩溃前最后一刻的内存消耗统计信息。
统计信息显示以下分配的内存大小：
- HeapSize：751 MB（已用 248 MB）
- Non-HeapSize（PermGen 和 CodeCache）：150 MB（已用 95 MB）
- 大小内存管理区域（Edenspace、Old-gen 等）：350 MB
- 线程堆栈大小：17 MB（根据 oracle 并且由于 51 个线程正在运行）
我正在运行该应用程序（jre 6 更新） 25、服务器虚拟机）使用参数：
-XX:PermSize=128m
-XX:MaxPermSize=192m
-XX:ReservedCodeCacheSize=96m
-Xms500m
-Xmx1124m
问题：
- 为什么当虚拟机上明显有足够的内存并且操作系统？
通过上述设置，我认为我无法达到 2GB 32 位限制（1124MB+192MB+96MB+线程堆栈<2GB）。在任何其他情况下（太多的堆分配），我宁愿期待 OutOfMemoryError 而不是 JVM 崩溃
谁可以帮助我找出这里出了什么问题？
（注：我最近从 Eclipse 3.4.2 升级到 Eclipse 3.6.2，并从 Java 5 升级到 Java 6。我怀疑崩溃和这些更改之间存在联系，因为我以前没有见过这些）
更新< /strong>
看来这是 Java 6 Update 25 中引入的 JVM bug，与新的 jit 编译器有关。另请参阅此博客条目。 根据该博客，该错误的修复应该是下一个 java 6 更新的一部分。 与此同时，我在崩溃期间获得了本机堆栈跟踪。我已经更新了上面的崩溃日志。
建议的解决方法，使用 VM 参数 -XX:-DoEscapeAnalysis 有效（至少它显着降低了崩溃的可能性）
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)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
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 位虚拟机上的最大堆为 1.5GB。在没有线程的情况下，您的初始大小为 1412MB。您是否尝试过减小交换堆栈大小 -Xss，并且是否尝试过消除最初分配的 PermSize：-XX:PermSize=128m？听起来这是一个日食问题，而不是内存问题本身。
您能否迁移到较新的 JVM 或不同机器上的不同（64 位）JVM？即使您的目标是 windows-XP，也没有理由在其上进行开发，除非您必须这样做。 Eclipse 可以轻松地在远程计算机上运行、调试和部署代码。
Eclipse 的 JVM 可能与您在 Eclipse 中运行或与 Eclipse 一起运行的事物的 JVM 不同。 Eclipse 是一只记忆猪。您可以消除不必要的 Eclipse 插件以使用更少的 Eclipse 内存，它附带了您可能不需要或不想要的开箱即用的东西。
尝试清空引用（以消除循环不可收集的 GC 对象）、重新使用分配的内存、使用单例并分析内存使用情况以消除不必要的对象、引用和分配。其他提示：
动态地。
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:
to dynamically.
我认为 @ggb667 已经解决了 JVM 崩溃的原因。 32 位 Windows 体系结构限制将 Java 应用程序的可用 RAM 限制为 1.5GB1 ...而不是您猜测的 2GB。此外，您还忽略了包含可执行文件的代码段、共享库、本机堆和“其他内容”所占用的地址空间。
基本上，这不是 JVM 错误。您只是在对抗硬件和操作系统的限制。
有一个可能的解决方案，其形式是某些版本的 PAE（物理地址扩展）支持视窗。根据该链接，带有 PAE 的 Windows XP 可为用户进程提供高达 4GB 的可用地址空间。但是，有关设备驱动程序支持的一些注意事项。
另一种可能的解决方案是减少最大堆大小，并采取其他措施来减少应用程序的内存利用率；例如，在 Eclipse 中减少工作空间中“打开”项目的数量。
另请参阅：Windows XP 上的 Java 最大内存
1 - 不同来源关于实际限制有不同的说法，但它明显小于 2GB。坦率地说，实际限制是多少并不重要。
在理想的世界中，这个问题不应该再引起任何人的实际兴趣。 2020 年：
无论哪种方式，您都不应该在此系统上运行 Eclipse。说真的，您可以花几百美元购买一台具有更多内存的新 64 位机器，这样您就可以运行最新的操作系统和最新的 Java 版本。您应该使用that来运行Eclipse。
如果您确实需要在具有旧版本 Java 的旧 32 位机器上进行 Java 开发（因为您买不起较新的机器），建议您使用简单的文本编辑器和 Java 6 JDK 命令行工具（以及第 3 方 Java 构建工具，如 Ant、Maven、Gradle）。
最后，如果您仍在尝试运行/维护陷入 Java 6 的 Java 软件，那么您确实应该尝试摆脱这个困境。您的生活只会变得更加困难：
您/您的组织应该在七年前处理这个问题。
I think that @ggb667 has nailed it with the reason your JVM is crashing. 32-bit Windows architectural constraints limit the available RAM for a Java application to 1.5GB1 ... not 2GB as you surmised. Also, you have neglected to include the address space occupied by the code segment of the executable, shared libraries, the native heap, and "other things".
Basically, this is not a JVM bug. You are simply running against the limitations of your hardware and operating system.
There is a possible solution in the form of PAE (Physical Address Extension) support in some versions of Windows. According to the link, Windows XP with PAE makes available up to 4GB of usable address spaces to user processes. However, there are caveats about device driver support.
Another possible solution is to reduce the max heap size, and do other things to reduce the application's memory utilization; e.g. in Eclipse reduce the number of "open" projects in your workspace.
See also: Java maximum memory on Windows XP
1 - Different sources say different things about the actual limit, but it is significantly less than 2GB. To be frank, it doesn't matter what the actual limit is.
In an ideal world this question should no longer be of practical interest to anyone. In 2020:
Either way, you should not be running Eclipse on this system. Seriously, you can get a new 64-bit machine for a few hundred dollars with more memory, etc that will allow you to run an up-to-date operating system and an up-to-date Java release. You should use that to run Eclipse.
If you really need to do Java development on an old 32-bit machine with an old version of Java (because you can't afford a newer machine) you would be advised to use a simple text editor and the Java 6 JDK command line tools (and a 3rd-party Java build tool like Ant, Maven, Gradle).
Finally, if you are still trying to run / maintain Java software that is stuck on Java 6, you should really be trying to get out of that hole. Life is only going to get harder for you:
You / your organization should have dealt with this issue this SEVEN years ago.
我在工作中偶然发现了类似的问题。我们为我们的应用程序设置了 -Xmx65536M 但不断收到完全相同类型的错误。有趣的是，相对而言，错误总是发生在我们的应用程序实际上进行相当轻量级计算的时候，因此远未接近这个限制。
我们在网上找到了该问题的可能解决方案： http://www.blogsoncloud.com/jsp/techSols/java-lang-OutOfMemoryError-unable-to-create-new-native-thread.jsp ，它似乎解决了我们的问题。将 -Xmx 降低到 50G 后，我们就不再遇到这些问题了。
我们仍然不清楚此案到底发生了什么。
I stumbled upon a similar problem at work. We had set -Xmx65536M for our application but kept getting exactly the same kind of errors. The funny thing is that the errors happened always at a time when our application was actually doing pretty lightweight calculations, relatively speaking, and was thus nowhere near this limit.
We found a possible solution for the problem online: http://www.blogsoncloud.com/jsp/techSols/java-lang-OutOfMemoryError-unable-to-create-new-native-thread.jsp , and it seemed to solve our problem. After lowering -Xmx to 50G, we've had none of these issues.
What actually happens in the case is still somewhat unclear to us.
JVM 有其自身的限制，在达到物理或虚拟内存限制之前就会停止运行。您需要调整的是堆大小，它与另一个 -X 标志有关。 （我认为这是像 -XHeapSizeLimit 这样的创意，但我会稍后检查。）
我们开始：
The JVM has its own limits that will stop it long before it hits the physical or virtual memory limits. What you need to adjust is the heap size, which is with another one of the -X flags. (I think it's something creative like -XHeapSizeLimit but I'll check in a second.)
Here we go: