[xwiki-devs] Improve performance with new sun hotspot optimizations for Java 6u14?
The latest Sun JDK 6 <http://java.sun.com/javase/6/webnotes/6u14.html> has optional performance optimization for threading. Since Xwiki running in a web-container is thread-intensive, I'm wondering whether performance improvements like Escape Analysis<http://en.wikipedia.org/wiki/Escape_analysis> will be noticed for Xwiki. How about for its increasing amount of work happening out of Groovy scripts? Much attention has been given by Sun, IBM, BEA and others to optimize lock
management and synchronization in their respective Java 6 virtual machine offerings. Features like biased locking, lock coarsening, lock elision by escape analysis and adaptive spin locking are all designed to increase concurrency by allowing more effective sharing amongst application threads.
http://www.infoq.com/articles/java-threading-optimizations-p1 http://www.infoq.com/articles/java-threading-optimizations-p2 http://blog.xebia.com/2007/12/21/did-escape-analysis-escape-from-java-6/ http://blog.xebia.com/2009/02/18/jvm-threading-optimizations-revisited/ http://blog.juma.me.uk/2008/12/17/objects-with-no-allocation-overhead/ <http://blog.xebia.com/2007/12/21/did-escape-analysis-escape-from-java-6/> http://java.dzone.com/articles/escape-analysis-java-6-update <http://java.dzone.com/articles/escape-analysis-java-6-update> Niels http://nielsmayer.com PS: I need to try this experiment again with the non-early access version http://nielsmayer.com/xwiki/bin/view/fedora10/64bitJavaAppletIn64BitFirefox#... PPS: in clojure land (will this also apply to Groovy?) http://www.mail-archive.com/[email protected]/msg17221.html
I'm getting a very significant performance improvement by adding a couple of JVM parameters (using jdk 1.6.0_14). They are:
-XX:+DoEscapeAnalysis
-XX:+UseBiasedLocking (I think the -server flag is required for those two flags to do anything).
...
My runtime with n = 5,000,000 goes from ~7.5 seconds to ~4.5 seconds.
... I actually just confirmed that, on my computer at least, those flags have
basically no effect on the java version and a big difference on the clojure one.
... -XX:+AggressiveOpts improves another 5-10%.
Hi Niels, Cool. If you come to conclusive results it might be great to creata a "JVM Tuning" section on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances with the result of your findings. Thanks -Vincent On Aug 13, 2009, at 9:24 PM, Niels Mayer wrote:
The latest Sun JDK 6 <http://java.sun.com/javase/6/webnotes/ 6u14.html> has optional performance optimization for threading. Since Xwiki running in a web-container is thread-intensive, I'm wondering whether performance improvements like Escape Analysis<http://en.wikipedia.org/wiki/Escape_analysis> will be noticed for Xwiki. How about for its increasing amount of work happening out of Groovy scripts?
Much attention has been given by Sun, IBM, BEA and others to optimize lock
management and synchronization in their respective Java 6 virtual machine offerings. Features like biased locking, lock coarsening, lock elision by escape analysis and adaptive spin locking are all designed to increase concurrency by allowing more effective sharing amongst application threads.
http://www.infoq.com/articles/java-threading-optimizations-p1 http://www.infoq.com/articles/java-threading-optimizations-p2 http://blog.xebia.com/2007/12/21/did-escape-analysis-escape-from-java-6/ http://blog.xebia.com/2009/02/18/jvm-threading-optimizations- revisited/ http://blog.juma.me.uk/2008/12/17/objects-with-no-allocation-overhead/ <http://blog.xebia.com/2007/12/21/did-escape-analysis-escape-from-java-6/
http://java.dzone.com/articles/escape-analysis-java-6-update <http://java.dzone.com/articles/escape-analysis-java-6-update> Niels http://nielsmayer.com
PS: I need to try this experiment again with the non-early access version http://nielsmayer.com/xwiki/bin/view/fedora10/64bitJavaAppletIn64BitFirefox#...
PPS: in clojure land (will this also apply to Groovy?) http://www.mail-archive.com/[email protected]/msg17221.html
I'm getting a very significant performance improvement by adding a couple of JVM parameters (using jdk 1.6.0_14). They are:
-XX:+DoEscapeAnalysis
-XX:+UseBiasedLocking (I think the -server flag is required for those two flags to do anything).
...
My runtime with n = 5,000,000 goes from ~7.5 seconds to ~4.5 seconds.
...
I actually just confirmed that, on my computer at least, those flags have
basically no effect on the java version and a big difference on the clojure one.
...
-XX:+AggressiveOpts improves another 5-10%.
On Thu, Aug 13, 2009 at 11:21 PM, Vincent Massol <[email protected]> wrote:
If you come to conclusive results it might be great to creata a "JVM Tuning" section on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances with the result of your findings.
I'd be happy to update "Performances" with my results. However, before recommending more widely, I'd like to hear results from others who try out the optimization in a "real world" environment. I'm testing it now with a "clone" of a 6-way virtual-wiki setup on a computer on my network at home. My impressions from running it for over 24 hours is that it works well and "feels" faster -- noticeably faster -- than prior without the optimization. However, "feel' can be deceiving, and I have no numbers, nor am I running in a high-volume/high-load situation that would be a more appropriate test. When 2.0 final is released, I'll upgrade various "live" sites and add the optimization -- at that point I'll have a better idea if this helps, or if there are any "real world" downsides. The bottom line is that the application seems to run fine using "-XX:+DoEscapeAnalysis -XX:+UseBiasedLocking -XX:+AggressiveOpts": no new problems or bugs were noticed by adding the compilation optimizations. I think it would be a good idea to try it out on http://xwiki.org (which could use a "free" perf boost) or http://myxwiki.org and get some real world results. :-) My tomcat process looks like: F S UID PID PPID C PRI NI ADDR SZ WCHAN RSS PSR STIME TTY TIME CMD 0 S tomcat 8804 1 0 80 0 - 462172 futex_ 469116 1 Aug13 ? 9:04 /usr/java/default/bin/java -server -Xms160m -Xmx1024m -XX:PermSize=160m -XX:MaxPermSize=320m -XX:+DoEscapeAnalysis -XX:+UseBiasedLocking -XX:+AggressiveOpts -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 -DjavaEncoding=UTF-8 -Djava.awt.headless=true -Djava.library.path=/usr/lib64 -classpath :/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat6 -Dcatalina.home=/usr/share/tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp -Djava.util.logging.config.file=/usr/share/tomcat6/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start Using: XWiki 2.0M2, Sun's jdk-1.6.0_14-fcs.x86_64, Fedora's tomcat6-6.0.18-6.2.fc10.noarch, tomcat-native-1.1.16-1.fc10.x86_64, tomcat6-lib-6.0.18-6.2.fc10.noarch, tomcat6-servlet-2.5-api-6.0.18-6.2.fc10.noarch, on "Linux 2.6.27.29-170.2.78.fc10.x86_64 #1 SMP Fri Jul 31 04:16:20 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux" All running on a $500 AMD Opteron 1220 2.80GHz Dual Core "server" http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=4... Niels http://nielsmayer.com PS: also, needing revisiting, Sun HotSpot's G1 Garbage collector, which IMHO may have major performance impact on an application like Xwiki, which probably spends a lot of time creating and garbage-collecting lots of "young" objects. ( http://n2.nabble.com/Does-JDK6u14-"Garbage-First-garbage-collector-(G1)"-work-and-or-improve-Xwiki-performance-size-mem-locality--td2344358.html#a2344358<http://n2.nabble.com/Does-JDK6u14-%22Garbage-First-garbage-collector-(G1)%22-work-and-or-improve-Xwiki-performance-size-mem-locality--td2344358.html#a2344358> ) . As volume increases, the time to collect young objects doesn't increase anywhere close to linear in a real-world system, so optimizations on short-lived memory objects can have significant performance impact in a real world system. Last time I tried the G1 collector, (in an early-access release from Sun, not the "customer ship" version) it had a sergmentation fault after about an hour of being pounded by search-engine hits from all over the planet.
Some really useful looking flags suggested here http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html
-XX:OnOutOfMemoryError="mail -s 'OOM on `hostname` at `date`' [email protected] <<< ''" as a way to send out email when there's an OutOfMemoryError. Poor-man's monitoring!
-XX:+HeapDumpOnOutOfMemoryError -XX:+PrintCompilation prints out the name of each Java method Hotspot
decides to JIT compile. The list will usually show a bunch of core Java class methods initially, and then turn to methods in your application. In JRuby, it eventually starts to show Ruby methods as well.
-XX:+PrintGCDetails includes the data from -verbose:gc but also adds
information about the size of the new generation and more accurate timings.
-XX:+TraceClassLoading and -XX:+TraceClassUnloading print information class
loads and unloads. Useful for investigating if you have a class leak or if old classes (like JITed Ruby methods in JRuby) are getting collected or not.
Trying this out on Xwiki 2.0M2 gives some interesting, voluminous results: http://nielsmayer.com/xwiki-catalina-with-PrintGCDetails-PrintCompilation-Tr... I notice a huge amount of "loading" happening regarding jPython!! -- this seems excessive to have Xwiki "out of box" loading up jPython when Groovy and Velocity are "built in." And it appears all this loading is for the "{{code}}" macro. Seems like it would be lighter-weight (esp for high-volume situations) to use Javascript in the browser for highlighting code (Bespin?) instead of on the server requiring a whole extra scripting language. Alternately, is there a way of having jython only load when the {{code}} macro is used in a document, and then, only when language=java, html, or xml but not language=none?? Seems like that would be a big performance win right there. [Loaded org.xwiki.rendering.parser.HighlightParser from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-code-2.0-milestone-2.jar] [Loaded org.xwiki.rendering.parser.AbstractHighlightParser from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-code-2.0-milestone-2.jar] [Loaded org.xwiki.rendering.internal.parser.pygments.PygmentsParser from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-code-2.0-milestone-2.jar] [Loaded org.python.core.PyObject from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PySequence from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyBaseString from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyString from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyUnicode from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.xwiki.rendering.parser.Syntax from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-api-2.0-milestone-2.jar] [Loaded org.python.util.PythonInterpreter from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] ... [Loaded org.xwiki.rendering.macro.box.BoxMacroParameters from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-box-2.0-milestone-2.jar] [Loaded org.xwiki.rendering.macro.code.CodeMacroParameters from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-code-2.0-milestone-2.jar] [Loaded $Proxy28 from org.apache.catalina.loader.WebappClassLoader] [Loaded org.python.core.PyException from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyCode from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyFile from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyFileWriter from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyStringMap from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyModule from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.CompilerFlags from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.CodeFlag from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.Version from file:/usr/java/xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] ... This is with the following flags: tomcat 24048 4.2 28.7 1784472 554800 ? Sl 16:29 1:46 /usr/java/default/bin/java -server -Xms160m -Xmx1024m -XX:PermSize=160m -XX:MaxPermSize=320m -XX:+DoEscapeAnalysis -XX:+UseBiasedLocking -XX:+AggressiveOpts -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintCompilation -XX:+PrintGCDetails -XX:+TraceClassLoading -XX:+TraceClassUnloading -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 -DjavaEncoding=UTF-8 -Djava.awt.headless=true -Djava.library.path=/usr/lib64 -classpath :/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat6 -Dcatalina.home=/usr/share/tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp -Djava.util.logging.config.file=/usr/share/tomcat6/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start Niels http://nielsmayer.com PS: I also tried out the promising-sounding "-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC". It still segfaults. Hopefully, they'll get it right in JDK 7:
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0x00007f15ca60653a, pid=23777, tid=139729915439440 # JRE version: 6.0_14-b08 # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16 mixed mode
linux-amd64 )
# Problematic frame: # V [libjvm.so+0x19c53a]
On Aug 15, 2009, at 2:24 AM, Niels Mayer wrote: [snip]
I notice a huge amount of "loading" happening regarding jPython!! -- this seems excessive to have Xwiki "out of box" loading up jPython when Groovy and Velocity are "built in." And it appears all this loading is for the "{{code}}" macro. Seems like it would be lighter-weight (esp for high-volume situations) to use Javascript in the browser for highlighting code (Bespin?) instead of on the server requiring a whole extra scripting language.
3 things: 1) We did it on the server voluntarily. We want the result to be available for all renderers + it'll work for browsers without javascript enabled. 2) The Jython interpreter should only be initialized once. When this happens it takes a very long time (on the order of 1-2 seconds) but once it's done it should be much faster 3) Ideally we would have used a java framework except we didn't find any good one.
Alternately, is there a way of having jython only load when the {{code}} macro is used in a document, and then, only when language=java, html, or xml but not language=none?? Seems like that would be a big performance win right there.
Yes re language = none it's probably a good idea. For the conditional loading, we need to check but I thought this is what it was doing. Also as I said above it's only loaded once so you just need to call a page when you start your server and thereafter all queries should run just fine without calling the jython interpreter at all. I'll let Thomas provide more info since he's the one who wrote this. Thanks -Vincent
[Loaded org.xwiki.rendering.parser.HighlightParser from file:/usr/ java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-code-2.0- milestone-2.jar] [Loaded org.xwiki.rendering.parser.AbstractHighlightParser from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro- code-2.0-milestone-2.jar] [Loaded org.xwiki.rendering.internal.parser.pygments.PygmentsParser from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro- code-2.0-milestone-2.jar] [Loaded org.python.core.PyObject from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PySequence from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyBaseString from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyString from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyUnicode from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.xwiki.rendering.parser.Syntax from file:/usr/java/ xe-20m2/WEB-INF/lib/xwiki-core-rendering-api-2.0-milestone-2.jar] [Loaded org.python.util.PythonInterpreter from file:/usr/java/ xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] ... [Loaded org.xwiki.rendering.macro.box.BoxMacroParameters from file:/ usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-box-2.0- milestone-2.jar] [Loaded org.xwiki.rendering.macro.code.CodeMacroParameters from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro- code-2.0-milestone-2.jar] [Loaded $Proxy28 from org.apache.catalina.loader.WebappClassLoader] [Loaded org.python.core.PyException from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyCode from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyFile from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyFileWriter from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyStringMap from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyModule from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.CompilerFlags from file:/usr/java/xe-20m2/ WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.CodeFlag from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.Version from file:/usr/java/xe-20m2/WEB-INF/lib/ jython-standalone-2.5.0-xwiki.jar] ...
This is with the following flags: tomcat 24048 4.2 28.7 1784472 554800 ? Sl 16:29 1:46 / usr/java/default/bin/java -server -Xms160m -Xmx1024m - XX:PermSize=160m -XX:MaxPermSize=320m -XX:+DoEscapeAnalysis -XX: +UseBiasedLocking -XX:+AggressiveOpts -XX: +HeapDumpOnOutOfMemoryError -XX:+PrintCompilation -XX: +PrintGCDetails -XX:+TraceClassLoading -XX:+TraceClassUnloading - Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 - DjavaEncoding=UTF-8 -Djava.awt.headless=true -Djava.library.path=/ usr/lib64 -classpath :/usr/share/tomcat6/bin/bootstrap.jar:/usr/ share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat6 -Dcatalina.home=/usr/share/ tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/ temp -Djava.util.logging.config.file=/usr/share/tomcat6/conf/ logging.properties - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start
Niels http://nielsmayer.com
PS: I also tried out the promising-sounding "-XX: +UnlockExperimentalVMOptions -XX:+UseG1GC". It still segfaults. Hopefully, they'll get it right in JDK 7:
# A fatal error has been detected by the Java Runtime Environment: # SIGSEGV (0xb) at pc=0x00007f15ca60653a, pid=23777, tid=139729915439440 # JRE version: 6.0_14-b08 # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 ) # Problematic frame: # V [libjvm.so+0x19c53a]
On Sat, Aug 15, 2009 at 09:53, Vincent Massol<[email protected]> wrote:
On Aug 15, 2009, at 2:24 AM, Niels Mayer wrote:
[snip]
I notice a huge amount of "loading" happening regarding jPython!! -- this seems excessive to have Xwiki "out of box" loading up jPython when Groovy and Velocity are "built in." And it appears all this loading is for the "{{code}}" macro. Seems like it would be lighter-weight (esp for high-volume situations) to use Javascript in the browser for highlighting code (Bespin?) instead of on the server requiring a whole extra scripting language.
3 things:
1) We did it on the server voluntarily. We want the result to be available for all renderers + it'll work for browsers without javascript enabled. 2) The Jython interpreter should only be initialized once. When this happens it takes a very long time (on the order of 1-2 seconds) but once it's done it should be much faster 3) Ideally we would have used a java framework except we didn't find any good one.
Alternately, is there a way of having jython only load when the {{code}} macro is used in a document, and then, only when language=java, html, or xml but not language=none?? Seems like that would be a big performance win right there.
Yes re language = none it's probably a good idea.
For the conditional loading, we need to check but I thought this is what it was doing. Also as I said above it's only loaded once so you just need to call a page when you start your server and thereafter all queries should run just fine without calling the jython interpreter at all.
I'll let Thomas provide more info since he's the one who wrote this.
Jython interpreter is loaded at code macro initialization and the same interpreter is used for all macros. language=none does not execute any jython but as i said the interpreter is simply loaded the first time component manager called the macro for initialization.
Thanks -Vincent
[Loaded org.xwiki.rendering.parser.HighlightParser from file:/usr/ java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-code-2.0- milestone-2.jar] [Loaded org.xwiki.rendering.parser.AbstractHighlightParser from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro- code-2.0-milestone-2.jar] [Loaded org.xwiki.rendering.internal.parser.pygments.PygmentsParser from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro- code-2.0-milestone-2.jar] [Loaded org.python.core.PyObject from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PySequence from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyBaseString from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyString from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyUnicode from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.xwiki.rendering.parser.Syntax from file:/usr/java/ xe-20m2/WEB-INF/lib/xwiki-core-rendering-api-2.0-milestone-2.jar] [Loaded org.python.util.PythonInterpreter from file:/usr/java/ xe-20m2/WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] ... [Loaded org.xwiki.rendering.macro.box.BoxMacroParameters from file:/ usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro-box-2.0- milestone-2.jar] [Loaded org.xwiki.rendering.macro.code.CodeMacroParameters from file:/usr/java/xe-20m2/WEB-INF/lib/xwiki-core-rendering-macro- code-2.0-milestone-2.jar] [Loaded $Proxy28 from org.apache.catalina.loader.WebappClassLoader] [Loaded org.python.core.PyException from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyCode from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyFile from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyFileWriter from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyStringMap from file:/usr/java/xe-20m2/WEB- INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.PyModule from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.CompilerFlags from file:/usr/java/xe-20m2/ WEB-INF/lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.core.CodeFlag from file:/usr/java/xe-20m2/WEB-INF/ lib/jython-standalone-2.5.0-xwiki.jar] [Loaded org.python.Version from file:/usr/java/xe-20m2/WEB-INF/lib/ jython-standalone-2.5.0-xwiki.jar] ...
This is with the following flags: tomcat 24048 4.2 28.7 1784472 554800 ? Sl 16:29 1:46 / usr/java/default/bin/java -server -Xms160m -Xmx1024m - XX:PermSize=160m -XX:MaxPermSize=320m -XX:+DoEscapeAnalysis -XX: +UseBiasedLocking -XX:+AggressiveOpts -XX: +HeapDumpOnOutOfMemoryError -XX:+PrintCompilation -XX: +PrintGCDetails -XX:+TraceClassLoading -XX:+TraceClassUnloading - Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 - DjavaEncoding=UTF-8 -Djava.awt.headless=true -Djava.library.path=/ usr/lib64 -classpath :/usr/share/tomcat6/bin/bootstrap.jar:/usr/ share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat6 -Dcatalina.home=/usr/share/ tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/ temp -Djava.util.logging.config.file=/usr/share/tomcat6/conf/ logging.properties - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start
Niels http://nielsmayer.com
PS: I also tried out the promising-sounding "-XX: +UnlockExperimentalVMOptions -XX:+UseG1GC". It still segfaults. Hopefully, they'll get it right in JDK 7:
# A fatal error has been detected by the Java Runtime Environment: # SIGSEGV (0xb) at pc=0x00007f15ca60653a, pid=23777, tid=139729915439440 # JRE version: 6.0_14-b08 # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 ) # Problematic frame: # V [libjvm.so+0x19c53a]
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (3)
-
Niels Mayer -
Thomas Mortagne -
Vincent Massol