Differences

This shows you the differences between two versions of the page.

--- java [2012/12/06 17:29]
194.249.198.48
+++ java [2012/12/07 12:29]
a
@@ Line 12: / Line 12: @@
-===== Tunning  =====
+===== Tuning  =====
 {{ :memoryjvm.png?nolink |}}
@@ Line 43: / Line 43: @@
 ==== Choosing the garbage collector ====
+In Sun/Oracle JVM you have a choice of three garbage collectors, each built for different use case.
+  * **Serial collector** - single-threaded, **+XX:UseSerialGC**
+  * **Parallel collector** - does small passes in parallel, **+XX:UseParallelGC** and **+XX:UseParallelOldGC**
+  * **Concurrent collector** - does most of the collection in other threads, minimizes pauses, **+XX:UseConcMarkSweepGC**
+=== Serial collector ===
+Is the efficient (no intra-thread communication) of the three. Stops the world while running collection.
+**Best for**: applications running on single-core, applications with small datasets (up to 100MB), applications with no pause-time requirements
+=== Parallel collector ===
+Does minor collection (eden) in parallel thus greatly reducing garbage collection overhead on multi-core machines. With **+XX:UseParallelOldGC** is also does major collection and compation in parallel thus further reducing pause time for garbage collection on multi-core machines. It uses more memory and has slower full-passes than serial collector.
+**Best for**: applications with medium to large datasets (100MB+), applications that run on multi-core machines, application where peak throughput is the priority and pauses of 1 sec are acceptable.
+=== Concurrent collector ===
+Does most of it's work concurrently while other application threads are still running. It keeps garbage collection pauses the shortest possible at the expense of total garbage collection time and increased memory usage. The maximum response time is achieved at the cost of total application throughput so this GC may reduce total application performance at the expense of maximizing response time.
+**Best for**: applications with medium to large datasets (100MB+) which require minimal response time (with pauses required to be less than 1 sec).
+<note important>
+** Concurrent GC on machines with 2 cores **
+During each concurrent GC phase a whole core is pinned to the GC and is not available to the rest of the application. Due to long running passes of concurrent GC this may not be desireable on machines with only two cores.
+Enabling **incremental mode** for concurrent GC will cause the GC to do each pass in several phasses while relinquishing CPU to the application inbetween. This causes the core to be available to the application for more time at the expense of further prolonging the GC passes. Incremental mode is enabled with **-XX:+CMSIncrementalMode**.
+</note>
+[[http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html|More information on Java GC tuning at Oracle.]]
 ===== Good/best practices =====