You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Brian Minchau <mi...@ca.ibm.com> on 2006/11/17 22:26:36 UTC
Performance problem for Xalan-J on intel-dual core
Over the last week I've been working with Toadie (a Xalan user) who had
some very serious performance degradation with a webserver using Xalan.
On an intel dual-core machine it was 10 times slowdown than for a single
processor intel machine.
The problem occurs in this combination for the latest code:
- Intel dual-processor
- Sun JRE 5
Toadie's team was very capable and found that there was thread contention
with synchronized methods, either Xalan-J code or in JRE classes such as
java.util.Vector used by Xalan-J. This performance problem was so bad that
thread contention just screamed at us, and made it easy to fine the "hot"
synchronization spots. With their direction I changed Vector to the
unsynchronized ArrayList in a number of locations got back most of the
performance for them.
Toadie previously let me know that a single processor did not have this
problem, and recently checked that the IBM JRE 5 does not have the same
synchronization performance problem on the dual-core machine.
So heads up on Xalan's next multiprocessor performance problem.
Hats off to Toadie who did a great job of analysis, providing hardware to
do the analysis, and even the patches.
- Brian Minchau
mailto:minchau@apache.org
Re: Performance problem for Xalan-J on intel-dual core
Posted by Er...@inventivedesigners.com.
While I welcome any improvements in performance (we to rely heavily on
Xalan), I've in the meantime hit similar problems with other code as well
so I thought I could shed some light on the issue. It seems that there is
a serious performance regresion in the Sun 1.5 Windows vm implementation
when dealing with thread contention on x86 Multi Core processors. The
problems do not occur in jdk 1.4.2, nor in 1.6.0. I tracked it down to
having todo with the locking implementation used. It turns out that in jdk
1.6 synchronisation was improved using the intel PAUSE instruction, but in
previous vm's they usually resorted to Spinning to avoid heavy weight
locks. Now you don't want to use locks in a spinning fashion for non
multi-cpu x86 based systems. In JDK 1.4.2 spinning was always on, in 1.5
only when on a multiprocessor. I suspect that it incorrectly detects
multicore cpu's as not being multiprocessor. I did some tests and it turns
out that you can get jdk 1.5 pretty close to the other two, however I've
only seen this problem on windows, not sure if my linux machines have
other bottlenecks that cause them to behave differently or if its only
misdetected on windows. The situation worsens with the server vm.
My numbers were with -server -XX:+AggressiveHeap -Xms1024m -Xmx1024m
jdk 1.4.2_12 -> 12 seconds
jdk 1.5.0_07 - jdk 1.5.0._11 (all tested) -> 32-35s and clearly visible
degradation of processor usage and serious increase in privilliged kernel
time
jdk 1.6.0 -> 9s
jdk 1.5.0_xx with -XX:+UseSpinning -XX:+BiasedLocking -> 13s
The additional XX parameters were extremely helpfull in my case.
---------
Erik Vanherck - Product Delivery Manager
Inventive Designers
Visit http://www.inventivedesigners.com
Visit http://www.inventivedesigners.com/scriptura for Scriptura
information !
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Erik_Vanherck@inventivedesigners.com
"Computers in the future may weigh no more than 1.5 tons." - Popular
Mechanics, forecasting the relentless march of science, 1949
Brian Minchau <mi...@ca.ibm.com>
11/17/2006 10:26 PM
To
xalan-dev@xml.apache.org, xalan-j-users@xml.apache.org
cc
Subject
Performance problem for Xalan-J on intel-dual core
Over the last week I've been working with Toadie (a Xalan user) who had
some very serious performance degradation with a webserver using Xalan.
On an intel dual-core machine it was 10 times slowdown than for a single
processor intel machine.
The problem occurs in this combination for the latest code:
- Intel dual-processor
- Sun JRE 5
Toadie's team was very capable and found that there was thread contention
with synchronized methods, either Xalan-J code or in JRE classes such as
java.util.Vector used by Xalan-J. This performance problem was so bad
that
thread contention just screamed at us, and made it easy to fine the "hot"
synchronization spots. With their direction I changed Vector to the
unsynchronized ArrayList in a number of locations got back most of the
performance for them.
Toadie previously let me know that a single processor did not have this
problem, and recently checked that the IBM JRE 5 does not have the same
synchronization performance problem on the dual-core machine.
So heads up on Xalan's next multiprocessor performance problem.
Hats off to Toadie who did a great job of analysis, providing hardware to
do the analysis, and even the patches.
- Brian Minchau
mailto:minchau@apache.org
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Re: Performance problem for Xalan-J on intel-dual core
Posted by Brian Minchau <mi...@ca.ibm.com>.
Joe,
the idea of dropping support for JRE 1.1.8 ( indeed 1.1.x) was proposed on
the mailing lists with no negative responses. The response was essentially:
"about time this was done". The Xalan PMC voted on the issue and the motion
was passed. So now only 1.2 and up is supported as a runtime environment.
Since then a number of patches from Dave Brosius doing exactly what you
suggest were applied. Also in the last days other synchronization issues in
XALANJ-2344 and XALANJ-2336 also due to an over use of java.util.Vector
were applied to the code base.
The rest of the java.util.Vector, or other old over-synchronization will
probably be left alone unless it is a performance issue.
- Brian
keshlam@us.ibm.co
m
To
11/17/2006 04:44 xalan-dev@xml.apache.org
PM cc
xalan-dev@xml.apache.org,
xalan-j-users@xml.apache.org
Subject
Re: Performance problem for Xalan-J
on intel-dual core
We've known for a while that some part of Xalan are oversynchronized, due
to their use of the original Java heap and vector classes -- but we
couldn't move to the unsynchronized 1.2 Collection classes because we were
still committed to running on Java 1.1.8.
Now that Xerces has given up compatability with that version -- and I think
Xalan is doing likewise? -- it might be interesting to see what effect a
global replace of the old classes with their new versions would have on the
system. I don't think we're actually relying on their built-in
synchronization anywhere; the few places I can think of where we do some
inter-thread coordination are explicitly synchronized at the functional
level.
This cut-over would involve a lot of fiddling detail work, but should be
straightforward...
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (
http://www.ovff.org/pegasus/songs/threes-rev-11.html)
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Re: Performance problem for Xalan-J on intel-dual core
Posted by Brian Minchau <mi...@ca.ibm.com>.
Joe,
the idea of dropping support for JRE 1.1.8 ( indeed 1.1.x) was proposed on
the mailing lists with no negative responses. The response was essentially:
"about time this was done". The Xalan PMC voted on the issue and the motion
was passed. So now only 1.2 and up is supported as a runtime environment.
Since then a number of patches from Dave Brosius doing exactly what you
suggest were applied. Also in the last days other synchronization issues in
XALANJ-2344 and XALANJ-2336 also due to an over use of java.util.Vector
were applied to the code base.
The rest of the java.util.Vector, or other old over-synchronization will
probably be left alone unless it is a performance issue.
- Brian
keshlam@us.ibm.co
m
To
11/17/2006 04:44 xalan-dev@xml.apache.org
PM cc
xalan-dev@xml.apache.org,
xalan-j-users@xml.apache.org
Subject
Re: Performance problem for Xalan-J
on intel-dual core
We've known for a while that some part of Xalan are oversynchronized, due
to their use of the original Java heap and vector classes -- but we
couldn't move to the unsynchronized 1.2 Collection classes because we were
still committed to running on Java 1.1.8.
Now that Xerces has given up compatability with that version -- and I think
Xalan is doing likewise? -- it might be interesting to see what effect a
global replace of the old classes with their new versions would have on the
system. I don't think we're actually relying on their built-in
synchronization anywhere; the few places I can think of where we do some
inter-thread coordination are explicitly synchronized at the functional
level.
This cut-over would involve a lot of fiddling detail work, but should be
straightforward...
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (
http://www.ovff.org/pegasus/songs/threes-rev-11.html)
Re: Performance problem for Xalan-J on intel-dual core
Posted by ke...@us.ibm.com.
We've known for a while that some part of Xalan are oversynchronized, due
to their use of the original Java heap and vector classes -- but we
couldn't move to the unsynchronized 1.2 Collection classes because we were
still committed to running on Java 1.1.8.
Now that Xerces has given up compatability with that version -- and I think
Xalan is doing likewise? -- it might be interesting to see what effect a
global replace of the old classes with their new versions would have on the
system. I don't think we're actually relying on their built-in
synchronization anywhere; the few places I can think of where we do some
inter-thread coordination are explicitly synchronized at the functional
level.
This cut-over would involve a lot of fiddling detail work, but should be
straightforward...
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)
Re: Performance problem for Xalan-J on intel-dual core
Posted by ke...@us.ibm.com.
We've known for a while that some part of Xalan are oversynchronized, due
to their use of the original Java heap and vector classes -- but we
couldn't move to the unsynchronized 1.2 Collection classes because we were
still committed to running on Java 1.1.8.
Now that Xerces has given up compatability with that version -- and I think
Xalan is doing likewise? -- it might be interesting to see what effect a
global replace of the old classes with their new versions would have on the
system. I don't think we're actually relying on their built-in
synchronization anywhere; the few places I can think of where we do some
inter-thread coordination are explicitly synchronized at the functional
level.
This cut-over would involve a lot of fiddling detail work, but should be
straightforward...
______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
-- "Threes" Rev 1.1 - Duane Elms / Leslie Fish
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)