Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. OOPSLA/SPLASH’10 October 17–21, 2010, Reno/Tahoe, Nevada, USA. Copyright © 2010 ACM 978-1-4503-0203-6/10/10…$10.00. A Study of Java’s Non-Java Memory Kazunori Ogata Dai Mikurube † Kiyokuni Kawachiya Scott Trent Tamiya Onodera IBM Research – Tokyo 1623-14, Shimo-tsuruma, Yamato, Kanagawa 242-8502, Japan ogatak@jp.ibm.com Abstract A Java application sometimes raises an out-of-memory exception. This is usually because it has exhausted the Java heap. However, a Java application can raise an out-of- memory exception when it exhausts the memory used by Java that is not in the Java heap. We call this area non-Java memory. For example, an out-of-memory exception in the non-Java memory can happen when the JVM attempts to load too many classes. Although it is relatively rare to ex- haust the non-Java memory compared to exhausting the Java heap, a Java application can consume a considerable amount of non-Java memory. This paper presents a quantitative analysis of non-Java memory. To the best of our knowledge, this is the first in- depth analysis of the non-Java memory. To do this we cre- ated a tool called Memory Analyzer for Redundant, Un- used, and String Areas (MARUSA), which gathers memory statistics from both the OS and the Java virtual machine, breaking down and visualizing the non-Java memory usage. We studied the use of non-Java memory for a wide range of Java applications, including the DaCapo bench- marks and Apache DayTrader. Our study is based on the IBM J9 Java Virtual Machine for Linux. Although some of our results may be specific to this combination, we believe that most of our observations are applicable to other plat- forms as well. Categories and Subject Descriptors C.4 [Programming Languages]: Measurement techniques, D.2.5 [Software Engineering]: Testing and Debugging – debugging aids. General Terms Measurement, Experimentation. Keywords Java, memory footprint analysis, non-Java memory, Java native memory. 1. Introduction A Java application sometimes raises an out-of-memory exception. This is usually because it has exhausted the Java heap. A large application may use gigabytes of Java heap due to memory leaks or bloat [22]. With varying degrees of sophistication, many tools are available for analyzing the Java heap and for debugging the out-of-memory exceptions [21, 30]. However, a Java application can sometimes raise an out- of-memory exception because it has exhausted ‘non-Java’ memory, the memory region outside the Java heap. For example, this can happen when it attempts to load too many classes into the virtual machine. Although running out of non-Java memory is rare compared to running out of the Java heap, a typical Java application actually consumes a considerable amount of non-Java memory. As we will show later, the non-Java memory usage is as large as the Java heap for more than half of the DaCapo benchmarks [6] when the heap sizes are twice the minimum size re- quired for each benchmark. A Java Virtual Machine (JVM) uses non-Java memory for various purposes. It holds shared libraries, the class metadata for the loaded Java classes, the just-in-time (JIT) compiled code for Java methods, and the dynamic memory used to interact with the underlying operating system. In- terestingly, modern virtual machines tend to use more and more non-Java memory. For instance, beginning with Ver- sion 1.4.0, Sun's HotSpot Virtual Machine [29] optimizes reflective invocations [27] by dynamically generating ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ † Dai Mikurube is currently affiliated with Google Inc. 191