Comparison of allocation trackers in JVM
Name
Viktor Karabut
Abstract
Memory leaks in Java are not the same as memory leaks in, for example, the C programming language. When a C-programmer wants to use memory on the heap, he should manually allocate a memory region. After application finishes using this memory, it should be manually freed. If the pointer to the allocated region is lost, then there is no appropriate way to release this memory. This situation is called a “memory leak”. In Java the Java Virtual Machine (JVM) handles all work with memory. When a developer wants to create and use a new object, the JVM allocates a necessary amount of memory. During an application’s life the JVM periodically checks for objects in memory that are not used anymore. Objects, which are not referenced, will be discarded and memory reclaimed to be used again. This process is called garbage collection. A memory leak in Java is a situation, where an application is not logically using objects, to which references still exist, meaning the Garbage Collector (GC) can’t mark them as unused and free memory. When memory management of JVM cannot allocate any more memory, java.lang.OutOfMemoryError exception is thrown.
When a developer is faced with an “OutOfMemoryError” on production server, he can try to reproduce the problem in a test environment. Unfortunately, oftentimes test environments do not allow for reproduction of such errors. It’s not always possible to mimic all parameters of a real environment. Developer often doesn’t have all required input data or he just does not know how and why the memory leak occurred. This can be also caused by all sorts of bureaucratic obstacles and barriers in large companies with separate operations and development departments and developers just do not have full access to machines in a real environment.
However, even if it is possible to search for memory leaks in a production environment – use of many developer’s tools, such as full-featured profilers is not possible, due to the memory and performance overhead not suitable for production environment. It is useful to apply all possible offline methods, such as analysis of heap dumps and collection of allocations’ logs. And when a memory leak is localized, only then it would be helpful to turn on an allocation tracker for a specific set of objects or allocation sites to find out what code is responsible for creating objects that are eventually leaked. In order to do it in a production environment, we need effective methods and algorithms for allocation tracking.
Memory allocations tracker is a tool, which works in runtime and logs memory allocation by specific objects or sites. Usually it is a part of a profiler, but standalone solutions also exist. The aim of this work is to review and compare existing open source solutions for allocation tracking in JVM.
The first chapter of this work describes benchmarking techniques, which will be used for comparison of different allocations trackers. In this work will SPECjvm2008 will be used. It is a benchmark suite for measuring the performance of a Java Runtime Environment (JRE). It contains several real life applications and benchmarks focusing on core java functionality. The SPECjvm2008 workload mimics a variety of common general-purpose application computations.
As SPECjvm2008 does not give any information about memory usage a lightweight JVM Tool Interface (JVM TI) agent was created. JVM TI allows a program to inspect the state and to control the execution of other application running in the JVM [1]. The agent works in a separate thread and writes memory usage statistics to a CSV file every second. The agent creates an insignificant overhead, so it does not distort the SPECjvm2008 results.
In the next chapters of this work open-source allocations trackers are reviewed. Their work principles, algorithms and memory structures are examined. For measuring allocations tracking efficiency the SPECjvm2008 suite will be run with every tested allocations tracking solution. The obtained data allows comparing memory and performance overhead of different approaches in memory allocations tracking. Chapter 2 introduces HPROF – an example profiler, shipped with the Oracle Java Development Kit (JDK) and uses the JVM TI. In chapter 3 we review the NetBeans profiler, previously known as JFluid. This is full-weight Java profiler integrated with the NetBeans IDE. Chapter 4 is about Eclipse Test and Performance platform. This is a collection of open- source frameworks and services that allows software developers to build test and performance tools. In the last chapter results of using Google’s Allocation Instrumenter are presented. It uses java.lang.instrument package and ASM Java byte code manipulation and analysis framework.
For each examined profiler brief description along with implementation details and benchmarking results are given.
Graduation Thesis language
English
Graduation Thesis type
Bachelor - Computer Science
Supervisor(s)
Vladimir Šor
Defence year
2012