In this series of simulating and troubleshooting performance problems in Kotlin, let’s discuss how to simulate the ‘java.lang.OutOfMemoryError: Java Heap space’ problem. ‘java.lang.OutOfMemoryError: Java Heap space’ will be thrown by the application, when it generates more objects than the maximum configured heap size.

Video: To see the visual walk-through of this post, click below:

https://youtu.be/y9Iydjrnix8

Kotlin OutOfMemoryError Program
Here is a sample Kotlin program, which generates the ‘java.lang.OutOfMemoryError: Java Heap space’ problem.
package com.buggyapp
   class OOMDemo {
      var myMap = HashMap<Any, Any>() @Throws(Exception::class)
      fun start() {
          while (true) {
            var counter = 1000000;
            myMap["key$counter"] = ("Large stringgggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + "ggggggggggggggggggggggggggggggggggggggggggggggggggggg"
            + counter)
            ++counter
         }
      }
    }

This Sample Kotlin program contains an ‘OOMDemo’ class. This class contains the ‘start()’ method. This method keeps inserting records into the HashMap infinitely. When HashMap grows beyond maximum heap size (i.e. -Xmx), the ‘java.lang.OutOfMemoryError: Java Heap space’ will be thrown. The below diagram illustrates the records present in the HashMap.



Fig: HashMap causing OutOfMemoryError

When we executed the above program, as expected, ‘java.lang.OutOfMemoryError: Java heap space’ was thrown in a few seconds.

Even though this is a hypothetical example that simulates ‘java.lang.OutOfMemoryError’, this is how a typical memory leak happens in enterprise applications. When records get inserted into a data structure (like HashMap, ArrayList, Set, etc), and never get removed, java.lang.OutOfMemoryError will be thrown.

How to troubleshoot OutOfMemoryError?
You can diagnose OutOfMemoryError either through a manual or automated approach.

Manual approach
In the manual approach, you will need to capture heap dump as the first step. Heap dump is a snapshot of memory and it shows all the objects in memory, values contained by those objects, and their references. You can capture heap dump using one of the 7 approaches given here. But an important criteria is: You need to capture the heap dump right before OutOfMemoryError is thrown. If you are going to capture a heap dump, after OutOfMemoryError has occurred, then leaking objects can get garbage collected, and it will become hard (or even impossible) to diagnose the problem. Once heap dumps are captured, you need to import the heap dumps from your production servers to your local machine. From your local machine, you can use heap dump analysis tools like jHat, HeapHero to analyze the heap dumps.

Automated approach
On the other hand, you can also use yCrash open source script, which would capture 360-degree data (GC log, 3 snapshots of thread dump, heap dump, netstat, iostat, vmstat, top, top -H,…) from your application stack within a minute and generate a bundle zip file. You can then either manually analyze these artifacts or upload it to yCrash server for automated analysis.

We used the Automated approach. Once the captured artifacts were uploaded to the yCrash server, it instantly generated the below root cause analysis report highlighting the source of the problem.






Fig: yCrash tool pointing out the root cause of OutOfMemoryError

Above is the heap dump analysis report from the tool which precisely points out that the HashMap (i.e., myMap) data structure present in the ‘com.yc.OOMApp’ to be the root cause of memory leak. Also the tool is reporting that this HashMap is holding 100% of memory. Equipped with this information one can easily go ahead and fix the problematic code.