Garbage Collectors - IBM JVM

TL;DR

-Xgcpolicy:gencon (default in V8)-Xgcpolicy:optthruput (previously default)
-Xgcpolicy:optavgpause
-Xgcpolicy:balanced



Details:

Garbage collector in IBM JVM, just as other GCs collects unused, dead, objects from the heap in order to recover some memory so it is able to allocate new objects on the heap. IBM JVM provides several GC algorithms:

• -Xgcpolicy:gencon
• Unused objects are removed, and the survivors are allocated in survivor spaces. After some time it is promoted to the Tenure space.

• -Xgcpolicy:optthruput (previously default)
• This algorithm works as MSC (Mark-Sweep-Compact). This means in the first run collector marks live objects, in the second run sweeps unused objects, and compacts the free space. This is being done in parallel. MSC process differs between different JVMs.

• -Xgcpolicy:optavgpause
• This policy can be used when the application can't tolerate long pauses in exchange for overall throughput. System tries to determine when next GC would be needed and then runs concurrent GC. before allocating new objects, some GC would be done.

• -Xgcpolicy:balanced
• This is a new in V8 collector policy. different regions of a heap map are dealt individually. More information soon

Read more on:
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.60%2Fdiag%2Fappendixes%2Fcmdline%2Fcommands_gc.html

Garbage Collection Options and Functions

Garbage collection options:

In addition to one of the previous posts regarding memory management options in various JVMs, now it is time to present some options for the GC (Garbage Collector)

Select specific collector:

• -XX:+UseSerialGC
• -XX:+UseParallelGC
• -XX:+UseParallelOldGC (combine with -XX:+UseParallelGC)
• -XX:+UseConcMarkSweepGC
• -Xnoclassgc is to disable garbage collection for permanent generation

Tune the Parallel GC:

• -XX:ParallelGCThreads=n - limit parallel threads by 'n'
• -XX:MaxGCPauseMilis=n - limit pause in miliseconds
• -XX:GCTimeRatio=n - throughput (percentage of CPU time spent on application

Increase debug level:

• -XX:+PrintGC - get basic information
• -XX:+PrintGCDetails - get verbose information
• -XX:+PrintGCTimeStamps - add timestamps
• -XX:+HeapDumpOnOutOfMemoryError very useful :)

Garbage Collectors - JRockit

TL;DR

• Dynamic (default one)

• Throughput – for maximum throughput (default):  –XgcPrio:throughput

• Pausetime – for short and even pause times: –XgcPrio:pausetime

• Deterministic – for very short and deterministic pause times (requires Oracle JRockit Real Time)

• Static (1x Generational, 2x Concurrent, 1x Parallel)

• Generational

• Generational Copy: -Xgc:gencopy

• Concurrent

• Single-spaced mostly concurrent: –Xgc:singlecon

• Generational mostly concurrent: –Xgc:gencon

• Parallel

• General parallel: –Xgc:genpar

Details:

Static:

• Generational Copy:
• best to use with small heap and for testing purposes
• splits heap into generations

• Generational parallel collector:

• causes longer pauses/ stop-the-world
• multiple threads to speed up the process
• segments the heap into nursery and tenured generations (objects that survive two cycles are promoted from nursery to tenured generation)
• use when the application has many short lived objects
• Concurrent:

• Single-spaced mostly concurrent collector:
• almost no pauses
• works concurrently
• uses entire heap
• will not pause the application as long as it can collect dead objects
• Generational mostly concurrent collector:
• frequent stop-the-world
• splits the heap -> parallel on nursery, concurrent on tenured generation
• shorter nursery will cause more objects in tenured, hence more stop-the-world
• Parallel:
• Single-spaced parallel collector:

• causes longer pauses/ stop-the-world
• multiple threads to speed up the process
• does not segment heap into multiple generations
• use when the application has more long lived objects

Dynamic:

Throughput:

"The higher the memory throughput the shorter is the time between the two events. Moreover, the higher the memory throughput the smaller the heap you will need."

 PauseTime:

" The longer the pause, the more unresponsive your system will be. The worst pause time and the average pause time are the two most interesting values you can use for tuning the system."

Garbage Collectors - HotSpot

TL;DR

Types of Garbage Collectors in HotSpot:

• Serial
• Parallel
• Concurrent (CMS)

Young Generation Collectors:

1. -XX:+UseSerialGC
2. -XX:+UseParallelGC (Use parallel for Young, Serial for Old)
3. -XX:+UseParNewGC

Old Generation Collectors:

1. -XX:+UseParallelOldGC (Parallel Young and Old)
2. -XX:+UseConcMarkSweepGC –XX:-UseParNewGC (Concurrent Mark Sweep with Serial Young)
3. -XX:+UseConcMarkSweepGC –XX:+UseParNewG (Concurrent Mark Sweep + Parallel Young)

Additional note:

-XX:+DisableExplicitGC - prevent calls to System.gc()

Details:

Serial collector:

-XX:+UseSerialGC

Serial Collector - runs in single thread. No communication overhead between the threads. Used for mini data sets (<100MB). This collector is quick but suited for single CPU machines.

Parallel collector:

-XX:+UseParallelGC

and (optionally) enable parallel compaction with

-XX:+UseParallelOldGC 

-XX:+UseParNewGC

This type of collector is similar to the serial collector, but runs with multiple threads and does the minor collection in these threads. Be default:

N garbage collector threads = N CPUs on the host.

We can take the control over the number of threads by using the following option:

-XX:ParallelGCThreads=[number of threads]

Concurrent collector:

-XX:+UseConcMarkSweepGC 

One thread is used during initial mark and remark phase. For the concurrent marking and sweeping, CMS thread runs along the application threads. Used when the short pauses and response time are crucial.


In this collector parallel version of the young generation collector is used. For the Old/ Tenured generation, serial collector is used.


Concurrent low pause collector:

-Xincgc ™ or -XX:+UseConcMarkSweepGC

This collector is used to collect Old Generation and is done concurrently with the running application, however application is still paused for short amounts of time during the collection.. A parallel version of the young generation copying collector is used with the concurrent collector. 

Incremental low pause collector:

-XX:+UseTrainGC

This is currently not under the development, and has not changed since the J2SE Platform version 1.4.2

Note:


ParallelGC partially implies the -XX:+UseConcMarkSweepGC and should not (this doesn't mean you can't use it ;) ) be used in the same cmd line.

Garbage Collection (GC)

Garbage Collection is integral part of the JVM (Java Virtual Machine) and it is used to reclaim memory occupied by the unused objects.

When the application runs, it creates objects. Once the object is created it occupies some memory. When the object is not used/ referenced it can be considered as unused and will remain in the memory until the garbage collector claims the memory occupied by this object.

Objects at first are created and put in the Young Generation space. After some time can be moved (Partial/ Minor Garbage Collection) into the Old Generation space. Once the Young and Old Generation is FULL, Full Garbage Collection is run. 

This operation might impact the flow of the application, as it might take a very long time to complete. During this operation application becomes unresponsive.

To avoid this, we can tune the JVM Heap/ other settings. Different JVMs have different GC policy algorithms which will be discussed in the next posts.

Examples:

If we add the following option to the command line for the JVM:

-verbose:gc

we will get the information about the heap and result of the garbage collection for each collection.

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

In this scenario we can see two minor GC and one Full/ Major GC.

• First numbers stand for the size of live objects before and after the GC.
• Numbers in parentheses represent memory space usable for java objects (perm/ survivor spaces not included).
• Secs stands for the amount of time in seconds that was taken to perform the action

[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]

Here the second numbers represent the heap usage reduction (196016K -> 133633K(261184K)



If we want to get even more details on the GC results we can add the following options:

-XX:+PrintGCDetails

If we add:

-XX:+PrintGCTimeStamps

we will get additional information regarding timestamps when the GC occurred  Based on such results we can see how often GC occurs.