Wednesday 3 February 2016

Basic understanding of Memory leaks

A memory leak occurs when object references that are no longer required are still maintained unnecessarily. However many times, it's difficult detect or difficult to interpret from the detected logs by any tool.

There are many reasons why the memory issues happen, however few primary reasons are


1. Java heap memory leaks- Java objects are created continuously without being released.

2. Native memory leaks - any continuously memory growing causing issues outside heap area.
3. Resource Constraints: If the available memory is too little to allocate or fragmented a lot that unable to allocate new objects.

Here we will discuss more about Heap Memory Issues.

The very basic symptom of a memory leak is outOfMemoryError. However all outOfMemoryError doesn't imply the memory leaks and all memory leaks doesn't come from outOfMemoryError issues.


Memory Leaks happen, When we are holding references to objects, preventing the Garbage Collector to clean them up.

Another potential source of these OOM issue arises with the use of Finalizers in a class. The objects of this type don't have their memory reclaimed, instead queued up for finalization post GC. If the finalizer thread cannot keep up with the finalization queue, then the Java heap could fill up causing an OOM.

The Straight forward method of finding memory leaks in application would be

1. Identify Symptoms.
2. Enable Verbose GC
3. Profiling
4. Analysis

1. Identify Symptoms. - When an OOM occurs, Need to identify if this is a normal memory exhaustion or a memory leak.


2. Enable Verbose GC -  One of the quickest ways to assert that you indeed have a memory leak is to enable verbose garbage collection. The -verbosegc argument allows you to generates a trace each time the garbage collection (GC) process is begun. That is, as memory is being garbage-collected, summary reports are printed to standard error, giving you a sense of how your memory is being managed.


3. Profiling- Different JVMs offer different ways to generate trace files to reflect heap activity, which typically include detailed information about the type and size of objects. This is called profiling the heap.

4. Analysis- The trace generated by the JVM comes in different format by different tools. However the analysis idea is same behind all. Find a block of objects that shouldn't be there and if these objects accumulate instead of releasing.

Tuesday 2 February 2016

Basic Understanding of JVM

Java Virtual Machine (JVM) is an abstract computing machine that enables a computer to run a Java program. A run time instance of JVM run one application. When a Java application starts, a run time instance starts and ends/dies when the application dies/closes/completes. Java application runs inside its own JVM.

Java Runtime Environment (JRE) is composed of the Java API and the JVM. The role of the JVM is to read the Java application through the Classloader and execute it along with the Java API.


The JVM specification gives a lot of leeway to implementors regarding the implementation details. Since Java 1.3, JRE from Oracle contains a JVM called HotSpot. It has been designed to be a high-performance JVM.

To speed-up code execution, HotSpot relies on just-in-time compilation. To speed-up object allocation and garbage collection, HotSpot uses generational heap.

Generational heap

The Java virtual machine heap is the area of memory used by the JVM for dynamic memory allocation.
In HotSpot the heap is divided into generations:
  • The young generation stores short-lived objects that are created and immediately garbage collected.
  • Objects that persist longer are moved to the old generation (also called the tenured generation). This memory is subdivided into (two) Survivors spaces where the objects that survived the first and next garbage collections are stored.
The permanent generation (or permgen) was used for class definitions and associated metadata prior to Java 8. Permanent generation was not part of the heap.The permanent generation was removed from Java 8.

JVM Structure




JVM Responsibility


  • Loading, verifying, and executing the byte code
  • Providing a runtime environment for execution of bytecode
  • Memory management and garbage collection
Memory management and garbage collection: Lets discuss about the heap area.

Heap memory :  This is the region of memory where objects are stored. Any object, whose size cannot be determined during compilation time would be stored in Heap, i;e - Instances of Classes. Size of any standard object (belongs to fundamental data types) can be determined during compilation and placed in stack in memory.


Whenever a class or array is created in a running java application, memory is allocated in the single heap inside the JVM. Each application runs inside its own JVM and have respective heap area. All thread share the heap space inside one application. JVM has an instruction to allocate memory, but can't deallocate. The deallocation of memory is managed by JVM and the process is called Garbage Collection.


The heap memory contains Garbage Collected heap. This area of heap actually contains the objects. It deallocate memory when these objects are no longer required or referenced in the code.This process of memory deallocation is called Garbage Collection (GC). This GC works on the basis of Reference Counting and Mark & Sweep method.


Next chapter is on Memory Leaks