13 Aug
2009
13 Aug
'09
9:24 p.m.
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/clojure@googlegroups.com/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%.
14 Aug
14 Aug
8:21 a.m.
New subject: [xwiki-devs] Improve performance with new sun hotspot optimizations for Java 6u14?
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
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/clojure@googlegroups.com/msg17221.html
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/
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%.
8:17 p.m.
New subject: [xwiki-devs] Improve performance with new sun hotspot optimizations for Java 6u14?
On Thu, Aug 13, 2009 at 11:21 PM, Vincent Massol <vincent(a)massol.net> 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=…
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…
)
. 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.
15 Aug
15 Aug
2:24 a.m.
New subject: [xwiki-devs] Improve performance with new sun hotspot optimizations for Java 6u14?
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`'
whoever(a)example.com <<< ''" 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-T…
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]
9:53 a.m.
New subject: [xwiki-devs] Improve performance with new sun hotspot optimizations for Java 6u14?
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]
2:08 p.m.
New subject: [xwiki-devs] Improve performance with new sun hotspot optimizations for Java 6u14?
On Sat, Aug 15, 2009 at 09:53, Vincent Massol<vincent(a)massol.net> wrote:
On Aug 15, 2009, at 2:24 AM, Niels Mayer wrote:
[snip]
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.
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
--
Thomas Mortagne
[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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5564
days inactive
5566
days old
5 comments
3 participants
participants (3)
-
Niels Mayer -
Thomas Mortagne -
Vincent Massol