Garbage Collector Ergonomics digest

the “ParallelGC” will report one issue: "Out-of-Memory Exceptions", I found one material related to this issue and they give some suggestions to avoid "OOM" issue:

Quote:

The parallel garbage collector (UseParallelGC) throws an
out-of-memory exception if an excessive amount of time is being
spent collecting a small amount of the heap.

To avoid this exception, you can increase the size of the heap.
You can also set the parameters -XX:GCTimeLimit=time-limit and
-XX:GCHeapFreeLimit=space-limit where:

time-limit:
The upper limit on the amount of time spent in garbage
collection in percent of total time (default is 98).

space-limit:
The lower limit on the amount of space freed during a garbage
collection in percent of the maximum heap (default is 2).

Here is the article called Garbage Collector Ergonomics
http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html

I also take the Java tuning White paper as a reference, which emphasis on the most important points of Java tuning:
http://java.sun.com/performance/reference/whitepapers/tuning.html

For heapsize part, it describe as following:

The maximum heap size of a Java application is limited by three factors: the process data model (32-bit or 64-bit) and the associated operating system limitations, the amount of virtual memory available on the system, and the amount of physical memory available on the system. The size of the Java heap for a particular application can never exceed or even reach the maximum virtual address space of the process data model. For a 32-bit process model, the maximum virtual address size of the process is typically 4 GB, though some operating systems limit this to 2 GB or 3 GB. The maximum heap size is typically -Xmx3800m (1600m) for 2 GB limits), though the actual limitation is application dependent. For 64-bit process models, the maximum is essentially unlimited. For a single Java application on a dedicated system, the size of the Java heap should never be set to the amount of physical RAM on the system, as additional RAM is needed for the operating system, other system processes, and even for other JVM operations. Committing too much of a system's physical memory is likely to result in paging of virtual memory to disk, quite likely during garbage collection operations, leading to significant performance issues. On systems with multiple Java processes, or multiple processes in general, the sum of the Java heaps for those processes should also not exceed the the size of the physical RAM in the system.

The next most important Java memory tunable is the size of if the young generation (also known as the NewSize). Generally speaking the largest recommended value for the young generation is 3/8 of the maximum heap size. Note that with the throughput and low pause time collectors it may be possible to exceed this ratio. For more information please see the discussions of the Young Generation Guarantee in the Tuning Garbage Collection with the 5.0 Java Virtual Machine document.

For GC algorithms you can choose from:

* The -XX:+UseParallelGC parallel (throughput) garbage collector, or
* The -XX:+UseConcMarkSweepGC concurrent (low pause time) garbage collector (also known as CMS)
* The -XX:+UseSerialGC serial garbage collector (for smaller applications and systems)

first two choices are most common for large server applications. The white paper give us a lot of tuning examples, I have to say "tuning is an art more than science, there is no silver bullet". Please keep your tuning work for always...

If you have any other questions:

1> remember FAQ, although it is based on JDK1.4.2, very helpful!
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

2> read "Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine" again:

http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html