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.