Why a sawtooth shaped graph?

buch11 picture buch11 · Aug 28, 2011 · Viewed 12.9k times · Source

When I run the below mentioned code using NetBeans, the allocated heap size graph resembles a sawtooth shape. I am attaching the screen capture from JVisualVM which shows the heap allocation graph in with a sawtooth shape. The program is a simple infinite loop printing "Hello, World!" into the console.

public class HelloWorld {
    public static void main(String a[]){
        while(true) {
            System.out.println("Hello, World!");
        }
    }
}

enter image description here Can anyone explain the reason behind the shape of the graph of used heap?

PS: This happens even if I run it without using NetBeans, so it is most likely not related to NetBeans...

Answer

Vineet Reynolds picture Vineet Reynolds · Aug 29, 2011

The sawtooth pattern in the heap usage can be explained by the fact that several local variables are created during the invocation of the System.out.println invocation. Most notably in the Oracle/Sun JRE, several HeapCharBuffer instances are created in the young generation, as noted in the following snapshot obtained using the memory profiler of VisualVM:

Visual VM - Memory snapshot

The interesting bit is in the number of live objects that are present on the heap. The sawtooth pattern results from the young-gen garbage collection cycle that occurs when the eden space fills up; since there is no heavy computational activity performed in the program, the JVM is able to execute several iterations of the loop, resulting in the eden space (of 4MB is in size) filling up. The succeeding young-gen collection cycle then clears out most of the garbage; it is almost always the whole of the eden space, unless the objects are still in use, as indicated by the following gc trace obtained from VisualVM:

Visual VM GC probes

The behavior of the sawtooth pattern can thus be explained by a series of object allocations in rapid succession that fill up the eden space, triggering a young gen garbage collection cycle; this process repeats cyclically with no delays as the underlying JVM process is not preempted by another process, and the main thread within the JVM that is responsible for the object allocations is also not preempted by another thread.