Live Set and memory leaks

Some part of the below post are taken or remastered from Oracle JRockit: The Definitive Guide by Marcus Hirt. Buy the book for more :)

"Live set" definition

Live set is the java object that the application is using acively while running.

To be more technical...

Live set usually refers to the space in memory that live objects are occupying on the heap. Live objects are objects that either refered by other objects that are live or objects that are in the root set.  Live objects also refered as "in use". A live object might not be garbage collected (because it is considered to be used be the JVM!).  Root set is the set of objects that are reachable "from the beggining". This is the set of objects present in

·         registers and the

·         local stack frame in the thread context of the stopped for gargbage collection Java threads. (The threads that are stopped for garbage collection might have objects in the local stack frame of their thread context. These object are also part of the root set)

Example of Live Set

Live set is the objects that our application use. When for example we request a page, this pages's object are loaded in to memory, and to be more specific to the live set. If we leave the page, these objects should be marked for GC because there not used anymore. So later GC will run and free the memory of those objects. If there is an problem these object are not marked for GC and left in live set, but the application cannot use them anymore. So these objects are lost or "leaked" and the memory that they occupy is lost or "leaked" causing the memory leak.

Tuning tips

Live set and fragmentation is a good measure of how full the heap is and it is only calculated and updated on every garbage collection.

What to look for depends on the system. Ideally the system should be well utilized, but not saturated. A good rule of thumb for most setups would be to keep the Occupied Heap (Live Set + Fragmentation) to half or less than half of the max heap. This keeps the garbage collection ratio down.

Having a very large percentage of the heap filled with live objects will increase the garbage collector overhead, as GCs will have to be run more frequently. If the Live Set + Fragmentation dial remains steady on a high level and garbage collection performance is an issue, increasing the heap size will improve performance.

If the trend is for the Live Set + Fragmentation dial instead to steadily increase over time, there is probably a memory leak in the application. This basically means that after each garbage collection, there is less free memory left on the heap. It is very likely that we have a memory leak, and that, if we continue to let this application run, we will end up with an OutOfMemoryError. We can check memory leaks with  The Memory Leak Detector

Example

Below an obvious example of a memory leak.

The increasing execution of the GC (the less memory left the more often GC runs) is causing as performance problems. The Red areas are GC execution.

Dig more: 

• Oracle JRockit: The Definitive Guide by Marcus Hirt. THis is an excellent book about JRockit.