JVM Memory Structure

JVM Memory Structure

As experience has shown, sometimes a sort of uncertainty may arise on the subject of Java Virtual Machine (JVM) memory structure and other related aspects such as sizes of various kinds of memory, live and dead objects, etc.

In this article, we shall try to illuminate these issues to clear up the point.

Heap and Non-Heap Memory

The JVM memory consists of the following segments:

 

• Heap Memory, which is the storage for Java objects
• Non-Heap Memory, which is used by Java to store loaded classes and other meta-data
• JVM code itself, JVM internal structures, loaded profiler agent code and data, etc.

 

Heap

The JVM has a heap that is the runtime data area from which memory for all class instances and arrays are allocated. It is created at the JVM start-up.

The heap size may be configured with the following VM options:

 

• -Xmx<size> - to set the maximum Java heap size
• -Xms<size> - to set the initial Java heap size

 

By default, the maximum heap size is 64 Mb.

Heap memory for objects is reclaimed by an automatic memory management system which is known as a garbage collector. The heap may be of a fixed size or may be expanded and shrunk, depending on the garbage collector's strategy.

Non-Heap

Also, the JVM has memory other than the heap, referred to as non-heap memory. It is created at the JVM startup and stores per-class structures such as runtime constant pool, field and method data, and the code for methods and constructors, as well as interned Strings.

Unfortunately, the only information JVM provides on non-heap memory is its overall size. No detailed information on non-heap memory content is available.

The abnormal growth of non-heap memory size may indicate a potential problem, in this case you may check up the following:

 

• If there are class loading issues such as leaked loaders. In this case, the problem may be solved with the help of Class loaders view.
• If there are strings being massively interned. For detection of such problem,Allocation recording may be used.

 

If the application indeed needs that much of non-heap memory and the default maximum size of 64 Mb is not enough, you may enlarge the maximum size with the help of -XX:MaxPermSize VM option. For example, -XX:MaxPermSize=128m sets the size of 128 Mb.

Heap and non-heap memory usage telemetry is shown on the "Memory" tab:

Allocated and Used Memory

Allocated and used memory sizes are shown on the graphs for both heap and non-heap.

The allocated memory is an overall amount of memory allocated by the JVM, whileused memory is the amount of memory which is actually in use.

Obviously, the allocated memory cannot be less than the used memory. The exact amount of allocated memory is determined by the JVM internal strategies.

Used Heap Memory: Live and Dead Objects

Used heap memory consists of live and dead objects.

Live objects are accessible by the application and will not be a subject of garbage collection.

Dead objects are those which will never be accessible by the application but have not been collected yet by the garbage collector. Such objects occupy the heap memory space until they are eventually collected by the garbage collector.

Note that Class list view in memory telemetry shows both live and dead objects. You may observe the decreasing number of objects when garbage collection occurs automatically or it is forced with the help of the corresponding toolbar button.

Object Sizes in Memory Snapshots

In memory snapshots, all views show only live objects. And all the sizes you deal with are of the live objects, too. The exception is Dead Objects view.

Objects size in "Memory" tab can be less than the used memory shown in "Telemetry". This may be due to:

 

• Used memory consists of both live and dead objects. While only live objects are shown in "Memory" tab.
• By default, all objects which are only weak- or soft-referenced are treated as dead objects. Please consider the corresponding Help topic.

 

Shallow and Retained Sizes

All individual objects, as well as sets of objects have their shallow and retainedsizes.

Shallow size of an object is the amount of allocated memory to store the object itself, not taking into account the referenced objects. Shallow size of a regular (non-array) object depends on the number and types of its fields. Shallow size of an array depends on the array length and the type of its elements (objects, primitive types). Shallow size of a set of objects represents the sum of shallow sizes of all objects in the set.

Retained size of an object is its shallow size plus the shallow sizes of the objects that are accessible, directly or indirectly, only from this object. In other words, the retained size represents the amount of memory that will be freed by the garbage collector when this object is collected. In general, retained size is an integral measure, which helps to understand the structure (clusterization) of memory and the dependences between object subgraphs, as well as find potential roots of those subgraphs.

Dead objects are shown only with shallow size, as they do not actually retain any other objects.

Read more about shallow and retained sizes.