Tuning (JRockit JVM) Memory Management System
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 Management.
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 slower
- 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 collection
- 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 bytes.
- Best performance, set -Xms to the same size as the maximum heap size
- The -Xms value cannot exceed the value set for -Xmx
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 bytes.
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 collector, -Xgc:genpar
- 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 heap.
- 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 with -Xgc:.
- 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.
- throughput uses as little CPU resources as possible for garbage collection
- 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 Real Time)
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 collector
- gencon - two-generational mostly concurrent garbage collector
- When a static garbage collection strategy is selected, the garbage collection strategy will not change automatically in runtime.
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 fragmentation.
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 collection.
- 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 objects around.
- when the garbage collection time is too long it might be beneficial to reduce the compaction area to reduce the pause times.
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 pause
- 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 compaction area.
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 garbage collections
- Large heap with a lot of objects may take several seconds to perform
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 -XXlargeObjectLimit:size -XXminBlockSize: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