Tuning (JRockit JVM) Memory Management System - v1.5
- Memory management is all about allocation of objects.
- finds a free spot for the new object, while another part garbage
collects old objects to create more free space for new objects.
- Minimizes the overhead inflicted by garbage collection and makes
object allocation fast.
- You can read more about how memory management in the Oracle
JRockit JVM works in Java (JVM) Memory
Below are the most important options available for tuning the
memory management system in the JVM
1) Optimizing Memory Allocation Performance
2) Selecting and Tuning a Garbage Collector
3) Tuning the Compaction of Memory
4) Optimizing Memory Allocation Performance
Optimizing Memory Allocation Performance
Setting the Heap Size
- The heap size has an impact on allocation speed, garbage
collection frequency and garbage collection times.
- Small heap will become full quickly and must be garbage
collected more often.
- Also prone to more fragmentation, making object allocation
- Heap that is larger than the available physical memory in the
system must be paged out to disk, which leads to long access
times or even application freezes, especially during garbage
- Command line options: -Xms: -Xmx:
- Note: -Xms does not limit the total amount of memory
that the JVM can use.
- Format: -Xms size [g|G|m|M|k|K]
- If you do not add a unit, you will get the exact value in
- Best performance, set -Xms to the same size as the maximum
- The -Xms value cannot exceed the value set for -Xmx for
java -Xgcprio:throughput -Xmx:64m -Xms:64m myApp
-server mode: 25% of the amount of free physical memory in the
system, up to 64 MB and at least 8 MB
-client mode: 25% of the amount of free physical memory in the
system, up to 16 MB and at least 8 MB
If the nursery size is set with -Xns, the default initial heap
size will be scaled up to at least twice the nursery size.
The initial Java heap cannot be set to a smaller value than 8
MB, which is the minimum Java heap size. If you attempt to set it
to a smaller value, JRockit JVM defaults to 8 MB.
Note:-Xmx does not limit the total amount of memory
that the JVM can use.
Format: -Xmx size [g|G|m|M|k|K]
If you do not add a unit, you will get the exact value in
The -Xmx option and -Xms option in combination are used to
limit the Java heap size.
The Java heap can never grow larger than -Xmx.
Set a fixed heap size by setting -Xms = -Xmx
Default Maximum Heap Sizes depends on Platform and varies
between 50% to 75% of available physical memory up to 1 to 2 GB
If both -Xmx and -Xms are specified the value of -Xmx must be
larger than or equal to that of -Xms.
If both -Xmx and -Xns are specified the value of -Xmx must be
larger than or equal to that of -Xns.
The minimum value for -Xmx is 16 MB.
Reduce the memory usage for address references on 64-bit
systems, the JRockit JVM can use compressed references.
Compressed references reduce the address references to 32
bits, and can be used as long as the entire heap can be addressed
with 32 bits
Setting the Nursery and Keep Area Size
- Command line option: -Xns: nursery size
- The size of the nursery has an impact on allocation speed, GC
frequency and GC times.
- An optimal nursery size for maximum application throughput is
such that as many objects as possible are garbage collected by
young collection rather than old collection.
- dynamic garbage collection mode optimized for throughput,
-Xgcprio:throughput, and the static generational parallel garbage
- You can also use -Xns to set a static nursery size when
running a dynamic garbage collector (-XgcPrio)
- The nursery size value cannot exceed the maximum value set for
- The keep area size has an impact on both old collection and
young collection frequency
- A large keep area causes more frequent young collections,
while a keep area that is too small causes more frequent old
collections when objects are promoted prematurely.
Selecting and Tuning a Garbage Collector
- Select a dynamic garbage collection mode by using the command
line option -XgcPrio:, or set a static garbage collector
- The dynamic garbage collection modes adjust the memory
management system in runtime, optimizing for a specific goal
depending on which mode is used
- The garbage collector is optimized for application
- throughput uses as little CPU resources as possible for
- Use throughput mode for applications that demand a high
throughput but are not very sensitive to the occasional long
garbage collection pause.
- Throughput mode is default when the JVM runs in -server
mode (which is default), or can be enabled with the command
line option -XgcPrio:throughput
java -XgcPrio:throughput JavaRefreshApplication
- The garbage collector is optimized for short pauses.
- GC will work concurrently with the Java application when
necessary, in order to avoid pausing the Java threads.
- This inflicts a slight performance overhead to the
application, as the concurrent GC demands more system
resources (CPU time and memory) than the parallel garbage
collector that is used for optimal throughput.
- The target pause time is by default 200 ms (Oracle JRockit
java -XgcPrio:pausetime -XpauseTarget:500ms JavaRefreshApplication
- The garbage collector is optimized for very short and
deterministic pause times.
- The garbage collector will aim on keeping the garbage
collection pauses below a given pause target.
- Running on slower hardware, with a different heap size
and/or with more live data might break the deterministic
behavior or cause performance degradation over time
- On faster hardware or less live data might allow you to set
a lower pause target.
- The pause target for deterministic mode is by default 30 ms
java -XgcPrio:deterministic -XpauseTarget:500ms JavaRefreshApplication
Selecting a Static Garbage Collection Strategy
- singlepar - single-generational parallel garbage collector
(same as parallel)
- genpar - two-generational parallel garbage collector
- singlecon - single-generational mostly concurrent garbage
- gencon - two-generational mostly concurrent garbage collector
- When a static garbage collection strategy is selected, the
garbage collection strategy will not change automatically in
java -Xgc:gencon JavaRefreshApplication
Tuning the Concurrent Garbage Collection Trigger
when you use concurrent GC, it will dynamically adjusts when to
start an old generation garbage collection in order to avoid
running out of free heap space.
java -XXgcTrigger=30 JavaRefreshApplication
Tuning the Compaction of Memory
- Compaction is the process of moving chunks of allocated space
towards the lower end of the heap
- create contiguous free memory at the upper end
- Compaction is the garbage collector's main weapon against
You can adjust the Compaction by 4 ways
- Setting the Compaction Ratio
- Setting a static compaction ratio will force the JVM to
compact a specified percentage of the heap at each old
- A high compaction ratio keeps down the fragmentation on the
heap but increases the compaction pause times
- The idea is to look at a part of the heap and move all the
live objects in that part together to create larger consecutive
areas of free space
- While the JVM is compacting the heap, all threads that want to
access objects have to stand still because the JVM is moving the
- when the garbage collection time is too long it might be
beneficial to reduce the compaction area to reduce the pause
java -XXcompactRatio:10 JavaRefreshApplication
Set in a 500 MB heap, the garbage collector will compact 50 MB of
the heap at each garbage/old collection.
Setting the Compact Set Limit
- Compaction is the process of moving live objects closer
together in the Java heap to create larger free areas that can be
used for allocation of large objects.
- When running non-deterministic garbage collection, the number
of references to the compaction area will affect the compaction
- You cannot use -XXcompactSetLimit together with any of the
following options: -XXnoCompaction, -XXfullCompaction ,
java -XXcompactSetLimit:10000 JavaRefreshApplication
sets the compaction limit to 10,000 references to objects in the
Turning Off Compaction
- To turn off compaction entirely we use this command.
- use this command at startup to disable it
java -XXnoCompaction JavaRefreshApplication
Using Full Compaction
- Used when some applications are not sensitive to garbage
collection pauses or perform old collections very infrequently.
- Maximizes the object allocation performance between the
- Large heap with a lot of objects may take several seconds to
java -XXfullCompaction JavaRefreshApplication
Optimizing Memory Allocation Performance
- Apart from optimizing the garbage collection to clear space for
object allocation, you can tune the object allocation itself to
maximize the application throughput
- Command line options: -XXtlaSize:min=size, preferred=size
- The thread local area (TLA) is a chunk of free space reserved
on the heap
- A thread can allocate small objects in its own TLA without
synchronizing with other threads
- The thread local area size influences the allocation speed, but
can also have an impact on garbage collection frequency.
java -XXtlaSize:min=1k,preferred=512k JavaRefreshApplication