Monitoring Jvm Performance: Tips For Optimal Java Virtual Machine Efficiency

Java Virtual Machine (JVM) is an integral part of any Java application and its performance directly impacts the application's performance. To ensure the smooth running of a Java Virtual Machine, it is important to monitor its performance and tweak it regularly to ensure peak performance. JVM performance monitoring involves tracking key performance indicators like heap memory, garbage collection, thread count, and application uptime in real time. This allows for the identification of potential issues and helps maintain business continuity. JVM monitoring tools provide insights into how the JVM is functioning, including CPU usage, memory usage, and activities of functions like Garbage Collection. These tools can also provide proactive alerts to help application operations and DevOps teams understand and troubleshoot any bottlenecks in the JVM that may be affecting application performance.

Heap memory management

Heap memory is the memory space that holds all the objects in your application. When there are more users accessing your application, performing a greater number of transactions, more and more objects containing request-specific data are created in heap memory.

Once the requests are served, these objects should be cleared or unreferenced. If they’re not, the objects will keep occupying the heap space, leaving no space for new objects. This leads to memory management issues, and your application may crash due to OutOfMemory (OOM) errors.

Heap memory issues can be split into two categories: scalability issues and improper coding practices.

Say your Java application has 2GB of heap space and you suddenly notice a spike in the number of users. This obviously increases the number of objects created in your JVM to serve these requests. This, in turn, consumes more heap memory, leading to application unavailability for certain users. This is a scalability issue.

When there is the usual traffic to your application but your application is performing poorly, one of the reasons could be that there are too many referenced objects in storage, occupying more heap. This type of issue needs to be taken care of while developing your application, as it relates to improper coding practices.

This is where monitoring heap memory comes in handy.

In the image above, we can see a sudden spike in the heap memory usage at a particular time. You can correlate the application response time with the number of requests and check if the spike is because of increased requests or an improper code base.

The heap is created when the JVM starts up and may increase or decrease in size while the application runs. The size of the heap can be specified using the –Xms VM option. The heap can be of fixed size or variable size, depending on the garbage collection strategy. The maximum heap size can be set using the –Xmx option. By default, the maximum heap size is set to 64 MB.

The heap is physically divided into two parts (or generations): the nursery (or young space/young generation) and the old space (or old generation).

The nursery is a part of the heap reserved for the allocation of new objects. When the nursery becomes full, garbage is collected by running a special young collection, where all the objects that have lived long enough in the nursery are promoted (moved) to the old space, thus freeing up the nursery for more object allocation. This garbage collection is called Minor GC. The nursery is divided into three parts: Eden Memory and two Survivor Memory spaces.

Important points about the nursery space:

• Most of the newly created objects are located in the Eden Memory space.
• When Eden space is filled with objects, Minor GC is performed, and all the survivor objects are moved to one of the survivor spaces.
• Minor GC also checks the survivor objects and moves them to the other survivor space. So, at a time, one of the survivor spaces is always empty.
• Objects that have survived many cycles of GC are moved to the old generation memory space. Usually, this is done by setting a threshold for the age of the nursery objects before they become eligible to be promoted to the old generation.

When the old generation becomes full, garbage is collected there, and the process is called old collection. Old generation memory contains the objects that are long-lived and survived after many rounds of Minor GC. Usually, garbage collection is performed in Old generation memory when it’s full. Old generation garbage collection is called Major GC and usually takes longer. The reasoning behind a nursery is that most objects are temporary and short-lived. A young collection is designed to be swift at finding newly allocated objects that are still alive and moving them away from the nursery. Typically, a young collection frees a given amount of memory much faster than an old collection or a garbage collection of a single-generational heap (a heap without a nursery).

The heap stores the actual objects. It is instantiated during the virtual machine startup. This memory is allocated for all class instances and arrays. The JVM provides the user control to initialize or vary the size of the heap as per the requirement. When a new keyword is used, the object is assigned space in the heap, but the reference to the same exists on the stack.

There are four types of references: strong, weak, soft, and phantom references. The difference among the types of references is that the objects on the heap they refer to are eligible for garbage collecting under different criteria.

Strong reference: Any object with a strong reference attached to it is not eligible for garbage collection. We can create a strong reference by using the following statement:

Object obj = new Object();

Weak Reference: It does not survive after the next garbage collection process. If we are unsure when the data will be requested again, in this condition, we can create a weak reference to it. In case the garbage collector processes, it destroys the object. When we try to retrieve that object again, we get a null value. It is defined in java.lang.ref.WeakReference class. We can create a weak reference by using the following statement:

WeakReference