FYI, some potentially useful info here: http://n2.nabble.com/Does-JDK6u14-%22Garbage-First-garbage-collector-%28G1%29%22-work-and-or-improve-Xwiki-performance-size-mem-locality--tp2344358p2344358.html Does JDK6u14 "Garbage-First garbage collector (G1)" work and/or improve Xwiki performance/size/mem-locality? *Date:* Feb 17, 2009; 05:13pm *Author:* Niels Mayer *XWiki- Dev* (http://n2.nabble.com/XWiki--Dev-f475773.html) 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. 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: 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. To counter my excitement at the new GC, the "early access" version consistently segfaulted I haven't tried again on the official release: http://nielsmayer.com/xwiki/bin/view/fedora10/64bitJavaAppletIn64BitFirefox#Comments Niels Mayer <http://nielsmayer.com/xwiki/bin/view/XWiki/NielsMayer> | Feb 19, 2009 05:52:38 GMT-08:00 For info on 6u14's new GC and potential usefulness for use with java web apps, see: <http://n2.nabble.com/Does-JDK6u14-%22Garbage-First-garbage-collector-%28G1%29%22-work-and-or-improve-Xwiki-performance-size-mem-locality--tp2344358p2344358.html> http://n2.nabble.com/Does-JDK6u14-%22Garbage-First-garbage-collector-%28G1%29%22-work-and-or-improve-Xwiki-performance-size-mem-locality--tp2344358p2344358.html <http://n2.nabble.com/forum/PrintPost.jtp?post=2344358> http://n2.nabble.com/forum/PrintPost.jtp?post=2344358 (cancel the print dialog: this gives you the complete message w/o extra crap). Unfortunately, when running with VM Arguments: jvm_args: -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -Xms256m -Xmx768m -XX:PermSize=256m -XX:MaxPermSize=768m -Djava.awt.headless=true … java_command: org.apache.catalina.startup.Bootstrap start You get a SIGSEGV (which obviates the whole point of garbage-collection): A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb) at pc=0x0000000000e9c621, pid=13441, tid=114968912 JRE version: 6.0_14-b01 Java VM: OpenJDK 64-Bit Server VM (14.0-b10 mixed mode linux-amd64 ) Problematic frame: V [libjvm.so+0x296621] The SIGSEGV happens because of new Garbage Collector, as invoked by "-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC". It dies after running for less than an hour: Current thread (0x000000004149f000): ConcurrentGCThread [stack: 0x0000000000000000,0x0000000000000000] [id=13448] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000001600000050 … elapsed time: 2916 seconds This issue doesn't occur with the default GC invoked with jvm_args: -Xms256m -Xmx768m -XX:PermSize=256m -XX:MaxPermSize=768m -Djava.awt.headless=true" I guess that's why this is an "Early Access" release. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
