title: Java 6 Update 25 VM crash: insufficient memory
body: <p><strong><em>For an update of this question - see below.</em></strong></p>
  
  <p>I experience a (reproducible, at least for me) JVM <strong>crash</strong> (<strong>not an OutOfMemoryError</strong>)
  (The application which crashes is eclipse 3.6.2).
  However, looking at the crash log makes me wonder:</p>
  
  <pre><code>#
  # 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]
  </code></pre>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>The statistics shows the following allocated memory sizes:</p>
  
  <ul>
  <li>HeapSize: <strong>751 MB (used 248 MB)</strong></li>
  <li>Non-HeapSize(PermGen &amp; CodeCache): <strong>150 MB (used 95 MB)</strong></li>
  <li>Size of memory management areas (Edenspace, Old-gen etc.): <strong>350 MB</strong></li>
  <li>Thread stack sizes: <strong>17 MB</strong>  (according to <a href="http://blogs.oracle.com/LetTheSunShineIn/entry/windows_java_exe_default_thread" rel="nofollow noreferrer">oracle</a> and due the fact that  51 threads are running)</li>
  </ul>
  
  <p>I am running the application (jre 6 update 25, server vm) using the parameters:</p>
  
  <pre><code>-XX:PermSize=128m
  -XX:MaxPermSize=192m
  -XX:ReservedCodeCacheSize=96m
  -Xms500m
  -Xmx1124m
  </code></pre>
  
  <p><strong>Question:</strong></p>
  
  <ul>
  <li><strong>Why does the JVM crash when there's obviously enough memory on the VM and OS?</strong><br>
  With the above settings I think that I cannot hit the 2GB 32-bit limit (1124MB+192MB+96MB+thread stacks &lt; 2GB). In any other case (too much heap allocation), I would rather expect an OutOfMemoryError than a JVM crash</li>
  </ul>
  
  <p>Who can help me to figure out what is going wrong here?</p>
  
  <p>(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)</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p><strong><a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7040769" rel="nofollow noreferrer">It seems to be a JVM bug</a></strong> introduced in <strong>Java 6 Update 25</strong> and has something to do with the new jit compiler. See also <a href="http://jojava.blogspot.com/2011/05/jvm-crashes-with-6u25-c2-tiered.html" rel="nofollow noreferrer">this blog entry.</a>
  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.</p>
  
  <p>The proposed workaround, using the VM argument <code>-XX:-DoEscapeAnalysis</code> works (at least it notably lowers the probability of a crash)</p>