Classification
|
Option
|
Description
|
Heap area size
|
-Xms
|
Heap area size
when starting JVM
|
-Xmx
|
Maximum heap area
size
|
|
New area size
|
-XX:NewRatio
|
Ratio of New area
and Old area
|
-XX:NewSize
|
New area size
|
|
-XX:SurvivorRatio
|
Ratio of Eden
area and Survivor area
|
Showing posts with label JVM. Show all posts
Showing posts with label JVM. Show all posts
JVM Options to Be Checked for GC Tuning
JVM performance optimization: Garbage collection
Posted in: JVM
Garbage collection (GC) is the process that aims to free up
occupied memory that is no longer referenced by any reachable Java
object, and is
an essential part of the Java virtual
machine's (JVM's) dynamic memory management system. In a typical garbage
collection
cycle all objects that are still
referenced, and thus reachable, are kept. The space occupied by
previously referenced objects
is freed and reclaimed to enable new
object allocation.
In order to understand garbage collection and the various GC approaches and algorithms, you must first know a few things about the Java platform's memory model.
Garbage collection and the Java platform memory model
When you specify the startup option-Xmx on the command line of your Java application (for instance: java -Xmx:2g MyApp) memory is assigned to a Java process. This memory is referred to as the Java heap (or just heap).
This is the dedicated memory address space where all objects created by
your Java program (or sometimes the JVM) will be
allocated. As your Java program keeps
running and allocating new objects, the Java heap (meaning that address
space) will
fill up. Eventually, the Java heap will be full, which means that an allocating thread is unable to find a large-enough consecutive section of free memory for the object it wants to allocate. At that point, the JVM determines that a garbage collection needs to happen and it notifies the garbage collector. A garbage collection can also be triggered when a Java program calls
System.gc(). Using System.gc()
does not guarantee a garbage collection. Before any garbage collection
can start, a GC mechanism will first determine whether
it is safe to start it. It is safe to
start a garbage collection when all of the application's active threads
are at a safe
point to allow for it, e.g. simply
explained it would be bad to start garbage collecting in the middle of
an ongoing object
allocation, or in the middle of executing a
sequence of optimized CPU instructions (see my previous article on
compilers),
as you might lose context and thereby mess
up end results. A garbage collector should never reclaim an actively referenced object; to do so would break the Java virtual machine specification. A garbage collector is also not required to immediately collect dead objects. Dead objects are eventually collected during subsequent garbage collection cycles. While there are many ways to implement garbage collection, these two assumptions are true for all varieties. The real challenge of garbage collection is to identify everything that is live (still referenced) and reclaim any unreferenced memory, but do so without impacting running applications any more than necessary.
Source: JavaWorld.com
