Utilizing Object Reference Graphs and Garbage Collection Roots to Detect Memory Leaks in Ofline Memory Monitoring Markus Weninger Institute for System Software, CD Labor MEVSS, Johannes Kepler University Linz, Austria markus.weninger@jku.at Elias Gander CD Labor MEVSS, Johannes Kepler University Linz, Austria elias.gander@jku.at Hanspeter Mössenböck Institute for System Software, Johannes Kepler University Linz, Austria hanspeter.moessenboeck@jku.at ABSTRACT Complex software systems often sufer from performance problems caused by memory anomalies such as memory leaks. While the proliferation of objects is rather easy to detect using state-of-the- art memory monitoring tools, extracting a leak’s root cause, i.e., identifying the objects that keep the accumulating objects alive, is still poorly supported. Most state-of-the-art tools rely on the dominator tree of the object graph and thus only support single- object ownership analysis. Multi-object ownership analysis, e.g., when the leaking objects are contained in multiple collections, is not possible by merely relying on the dominator tree. We present an efcient approach to continuously collect GC root information (e.g., static felds or thread-local variables) in a trace-based memory monitoring tool, as well as algorithms that use this information to calculate the transitive closure (i.e., all reachable objects) and the GC closure (i.e., objects that are kept alive) for arbitrary heap object groups. These closures allow to derive various metrics for heap object groups that can be used to guide the user during memory leak analysis. We implemented our approach in AntTracks, an ofine memory monitoring tool, and demonstrate its usefulness by comparing it with other widely used tools for memory leak detection such as the Eclipse Memory Analyzer. Our evaluation shows that collecting GC root information tracing introduces about 1% overhead, in terms of run time as well as trace fle size. CCS CONCEPTS · Software and its engineering → Software maintenance tools; Software defect analysis; · Information systems → Clustering and classifcation; · Theory of computation → Data structures design and analysis; KEYWORDS Memory Monitoring, Memory Leak, Pointer Analysis, Garbage Collection, Graph Closure, ManLang’18, September 12ś14, 2018, Linz, Austria © 2018 Copyright held by the owner/author(s). Publication rights licensed to the Association for Computing Machinery. This is the author’s version of the work. It is posted here for your personal use. Not for redistribution. The defnitive Version of Record was published in 15th International Conference on Managed Languages & Runtimes (ManLang’18), September 12ś14, 2018, Linz, Austria, https://doi.org/10.1145/3237009.3237023. ACM Reference Format: Markus Weninger, Elias Gander, and Hanspeter Mössenböck. 2018. Utilizing Object Reference Graphs and Garbage Collection Roots to Detect Memory Leaks in Ofine Memory Monitoring. In 15th International Conference on Managed Languages & Runtimes (ManLang’18), September 12ś14, 2018, Linz, Austria. ACM, New York, NY, USA, 13 pages. https://doi.org/10.1145/3237009. 3237023 1 INTRODUCTION Modern programming languages such as Java or C# rely on garbage collection to relieve the programmer from freeing allocated memory manually. The garbage collector (GC) tries to free heap space by removing dead objects that are not reachable from root objects anymore. Examples for root objects are objects referenced by GC roots such as static felds or thread-local variables. Since these objects cannot be reclaimed by the GC, they also keep alive all other objects that are directly or indirectly referenced by them. This reveals one of the drawbacks of garbage collection. Since programmers are no longer required to free memory manually, they tend to use object allocations more carelessly. However, even in garbage-collected languages, careless handling of memory can lead to anomalies such as memory leaks. A memory leak occurs when objects that are not needed anymore are still unintentionally reachable and can therefore not be garbage collected. Detecting the presence of a memory leak is often relatively easy. A simple chart displaying an application’s growing memory usage may be enough to detect such a leak. Yet, it is difcult to track down a memory leak’s root cause, i.e., to identify which objects are leaking and which objects are responsible for that by keeping the leaking objects alive. Most state-of-the-art memory monitoring tools analyze the heap based on the object graph in conjunction with its dominator tree [25]. The object graph is a representation of the heap state, where each object is represented as a node, and the references between objects are represented as edges. The dominator tree of an object graph describes a keeps-alive relationship between the objects. If an object A dominates an object B and A is collectible by the GC, also B is collectible. While the dominator tree may help to fnd memory leaks where a single object is responsible, e.g., when all leaking objects are contained in a single large list, it fails to provide insight in situations where multiple objects are keeping objects alive (e.g., in multiple collections) [6]. AntTracks [4, 21ś23] is a memory monitoring tool for Java based on the Java Hotspot™ VM [30]. During an application’s execution, it records various events such as object allocations, object moves during garbage collection, or pointer information. Based on such