Java 6 Update 25 VM crash: insufficient memory

Question

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)

Answer 1

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.