Heap dumps in JDK 11



OutOfMemoryError is an exception handled by the JVM and usually means the application is not properly sized or it is taking more than what its memory intended size. It can be direct development team issues, sometimes an actual leak (in native or heap) or an issue on the deployment with an undersized heap. Regardless of how it came up, OOME should be addressed.

Automatic generation For automatically generating heap dumps on JDK 11, in case of OOME, is pretty straight forward, following the previous versions – just add the flag when calling java – and when the OOME happens the heap dump will be automatically generated:


This is interesting given some container have ExitOnOutOfMemoryerror flag, so on OOME event, the JVM will exist and most of the times we will see the pod terminating code153 or code 0 – given only one container per pod so the container just exists.

Manual generation: given jcmd avaliable one can generate a heap dump or VM.info as well – both very useful for heap and native investigations respectively.


$ java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/JDK11/java_application

Generated file

The generated file will be java_pid[number].hprof – hprof is a type of file. For its analysis I most of the times use Eclipse MTA – pretty straightforward opening the file. I think I have blog posts about querying the data from the heap and completing the analysis.


For testing, I used the scripts from here – but be aware that some tests have perm generation, which is deprecated on JDK 8 forward, now it is metaspace, so native memory.

Actually, the second example is pretty straight forward –  Error 2 – GC Overhead limit exceeded

// Java program to illustrate
// GC Overhead limit exceeded
import java.util.*;
public class Wrapper {
public static void main(String args[]) throws Exception
        Map m = new HashMap();
        m = System.getProperties();
        Random r = new Random();
        while (true) {
            m.put(r.nextInt(), "randomValue");

But I didn’t run with his suggestion and instead, run it without it. Just to see how long it would take. I regretted because the file is huge, given the hprof was a photochart of the entire jvm heap memory at the time is generated.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s