I usually have found that the garbage collector is the hardest-working thing in a java-web app (unfortunately) so when I noticed this new GC option in *Java HotSpot 14*, I figured it might help (potentially a lot w/ high-volume sites, which are the real GC churners). Has anybody tried the "Garbage-First garbage collector (G1)" with Xwiki? http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances suggests
CATALINA_OPTS="-server -Xms128m -Xmx1024m -XX:MaxPermSize=128m -Dfile.encoding=utf-8 -Djava.awt.headless=true -XX:+UseParallelGC -XX:MaxGCPauseMillis=100"
However these instructions don't work, as-is, since UseParallelGC is the default nowadays:
https://jdk6.dev.java.net/6uNea.html says: The parallel collector is still the default GC and is the most efficient GC
for common household usage. G1 is meant to be an alternative for the concurrent collector. It is designed to be more predictable and enable fast allocation with memory regions design.
Having actually worked on a variety of strange garbage collectors (for Lisp) where all of java's problems had already been solved decades ago ...this feels like a 1985-1990 flashback. :-) Here's more info Java SE 6 Update 14 Milestone Schedule b01 (1st available build) 02/11/09 FCS
Q2, 2009 *Feature List:*
- *Service Tag creation for Windows JRE (CR 6676849<http://bugs.sun.com/view_bug.do?bug_id=6676840> )*: For more information about Service Tag, check out this technical article <http://java.sun.com/developer/technicalArticles/productregistration/>.
- *Java HotSpot 14*: including the new garbage collector, G1, Big Decimal enhancements, TreeMap and HashMap enhancements, optimized compressed OOP code generation.
The Garbage-First garbage collector (G1) is currently in beta. It is not enabled by default. The parallel collector is still the default GC and is the most efficient GC for common household usage. G1 is meant to be an alternative for the concurrent collector. It is designed to be more predictable and enable fast allocation with memory regions design.
To use it: -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
For more information about GC & G1, please see:
- G1 Technical Session in JavaOne 2008<http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase> - Java SE 6 GC tunning<http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html> - Analysis of the Garbage-First Garbage Collection<http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf>
Niels http://nielsmayer.com PS: and will a different GC prevent sequences like this from happening?? see http://nielsmayer.com/happy-happy-joy-joy.txt PPS: some things that cause big-growth, like importing and exporting, might not grow as large with a "generation scavenging" style GC as provided by "Garbage-First Collection." Sometimes, just GCing a large structure being iterated-over uses a lot more memory than it needs to; because the gc is letting objects that should get collected early, like the incremental results of an iteration, "build up" and increase overall memory size while decreasing locality and cache-hits. This seems to cause a nearly exponential performance dropoff when very little memory churn might occur if only things got collected "at the right time." http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf suggests this new GC will help: 2.4 Generational GarbageFirst
Generational garbage collection [34, 26] has several advantages, which a collection strategy ignores at its peril. Newly allocated objects are usually more likely to become garbage than older objects, and newly allocated objects are also more likely to be the target of pointer modi cations, if only because of initialization. We can take advantage of both of these properties in Garbage-First in a flexible way. We can heuristically designate a region as young when it is chosen as a mutator allocation region. This commits the region to be a member of the next collection set. In return for this loss of heuristic flexibility, we gain an important benefit: remembered set processing is not required to consider modifications in young regions. Reachable young objects will be scanned after they are evacuated as a normal part of the next evacuation pause.
Note that a collection set can contain a mix of young and non-young regions. Other than the special treatment for remembered sets described above, both kinds of regions are treated uniformly.
...
2.5 Concurrent Marking
Concurrent marking is an important component of the system. It provides collector completeness without imposing any order on region choice for collection sets (as, for example, the Train algorithm of Hudson and Moss [22] does). Further, it provides the live data information that allows regions to be collected in \garbage-first" order. This section describes our concurrent marking algorithm.