Mälueraldamiste jälgijate võrdlemine JVM’is
Date
2012
Authors
Journal Title
Journal ISSN
Volume Title
Publisher
Tartu Ülikool
Abstract
Mälueraldamiste jälgija (Memory allocation tracker) on tööriist, mis registreerib objektide loomisi JVM’is. Tavaliselt, mälueraldamiste jälgija on profileerija alamosa. Sams eksisteerivad ka eraldiseisvad lahendused. Töö põhieesmärk on läbi vaadata ja võrrelda olemasolevate avatud lähtekoodiga mälueraldamiste jälgijaid.
Selleks, et mõõta mälueraldamiste jälgijate effektivsus kasutasime SPECjvm2008 jõudlustestide komplekt. Mälu kasutamise mõõtmiseks oli kirjatud oma JVM TI agent, mis perioodiliselt kirjutab kasutatud mälu suurus CSV faili.
Töö käigus olid läbi vaadatud ja testitud selliseid mälueraldamiste jälgimise lahendusi:
• HRPOF – lihtne käsurea kasutajaliidesega profileerimise tööriist, mis pakutakse JavaDevelopment Kit (JDK) koosseisus.
• NetBeans profileerija – varem see oli eraldiseisav avatud lähtekoodiga uurimis proekt nimega JFluid. Praegu see on NetBeansi osa.
• TPTP profileerija – profileerija, mis kasutatakse Eclipse IDE’s.
• Project Allocation Instrumenter – mälu eraldamiste jälgija Google’st. On kirjutatud puhtas Javas. Kasutab java.lang.instrument API ja ASM raamistikku baitkoodi analüüsimiseks ja manipuleerimiseks.
Neljast kahel mäluereldamiste jälgijatel olid probleemid stabiilsusega. NetBeans valesti muutus javazoom.jl.decoder.huffcodetab klassi baitkoodi, mille pärast ei saanud mpegaudio testi käivitada. Eclipse TPTP profileerija ei suutnud edukalt oma tööd lõpetada mitmel korral erinevate jõudlustestide käivitamise ajal.
NetBeans profileerija on tehniliselt kõige arenenum ja kõike tõhusam mäluerdlamiste jälgimise lahendus. See ei ole üllatav, kuna Sun’i insenerid kirjutasid seda parrallelselt Java virtualse masina arenguga.
Kõige problemaatilisem mälueraldamiste jälgimise mõttes oli sunflow jõudlustest. Koos TPTP profileerijaga ta jooksis umbes 300 korda aeglasemalt. HPROF’i ja Allocation Instrumenter’i tulemused ei olnud määrkimväärselt paremad. Ainult NetBeans profileerija said enam-vähem efektiivselt töötada sellel testil.
Kõik läbi vaadatud lahendused, välja arvatud TPTP, kasutavad mälueraldamiste jälgmiseks baitkoodi manipuleerimist (ByteCode Instrumentation, BCI). Nad lisavad oma jälgimise meetodi väljakutse pärast iga objekti loomise baitkoodi (opcode new). TPTP oma tööks kasutab JVM TI sündmuseid.
Erilist huvi pakkub Allocation Instrumenter Google’st. See raamistik võimaldab kirjutada mälueraldamiste jälgijat puhtas Java keeles. Potensiaalselt see teeb lahendus platvorimst sõltumatuks. Kuid veel eksisteerivad lahendamata probleeme jõudlusega. Minu tulevikuplaanis on aru saada, kas saab teha mälueraldamiste jälgimist.
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.
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.