問題描述
有關此問題的更新 - 見下文.
我遇到了一個(至少對我來說是可重現的)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:
- HeapSize:751 MB(使用 248 MB)
- 非堆大小(PermGen & CodeCache):150 MB(使用 95 MB)
- 內存管理區域的大小(Edenspace、Old-gen 等):350 MB
- 線程堆棧大小:17 MB(根據 oracle 并且由于有 51 個線程正在運行)
- 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)
我正在使用參數運行應用程序(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
問題:
- 為什么當 VM 和 OS 上的內存明顯足夠時 JVM 會崩潰?
使用上述設置，我認為我無法達到 2GB 32 位限制(1124MB+192MB+96MB+線程堆棧 <2GB).在任何其他情況下(堆分配過多)，我寧愿期待 OutOfMemoryError 而不是 JVM 崩潰
誰能幫我弄清楚這里出了什么問題?
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:
- 更喜歡靜態內存分配，即每個虛擬機分配一次，而不是動態.
- 避免在函數中創建臨時對象 - 考慮一個允許對象重用的 reset() 方法
- 避免字符串突變和自動裝箱類型的突變.
這篇關于Java 6 Update 25 VM 崩潰:內存不足的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！