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 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.