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. > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
