 | | | Performance problem for Xalan-J on intel-dual core | Performance problem for Xalan-J on intel-dual core 2007-03-07 - By Erik_Vanherck@(protected)
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@(protected)
"Computers in the future may weigh no more than 1.5 tons." - Popular
Mechanics, forecasting the relentless march of science, 1949
Brian Minchau <minchau@(protected)>
11/17/2006 10:26 PM
To
xalan-dev@(protected), xalan-j-users@(protected)
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@(protected)
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">My numbers were with -server -XX:
+AggressiveHeap
-Xms1024m -Xmx1024m</font>
<br>
<br><font size=2 face="sans-serif">jdk 1.4.2_12 -> 12 seconds</font>
<br><font size=2 face="sans-serif">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</font>
<br><font size=2 face="sans-serif">jdk 1.6.0 -> 9s</font>
<br><font size=2 face="sans-serif">jdk 1.5.0_xx with -XX:+UseSpinning -XX:
+BiasedLocking
-> 13s</font>
<br>
<br><font size=2 face="sans-serif">The additional XX parameters were extremely
helpfull in my case.</font>
<br>
<br><font size=2 face="sans-serif">---------<br>
<br>
Erik Vanherck - Product Delivery Manager<br>
Inventive Designers <br>
Visit http://www.inventivedesigners.com<br>
Visit http://www.inventivedesigners.com/scriptura for Scriptura information
!<br>
<br>
Phone: +32 - 3 - 8210170<br>
Fax: +32 - 3 - 8210171<br>
Email: Erik_Vanherck@(protected)<br>
<br>
"Computers in the future may weigh no more than 1.5 tons." -
Popular Mechanics, forecasting the relentless march of science, 1949 <
/font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Brian Minchau <minchau@(protected)
.ibm.com></b>
</font>
<p><font size=1 face="sans-serif">11/17/2006 10:26 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">xalan-dev@(protected), xalan-j-users@(protected)
.apache.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Performance problem for Xalan-J on intel-dual
core</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2><br>
Over the last week I've been working with Toadie (a Xalan user) who had<br>
some very serious performance degradation with a webserver using Xalan.<br>
<br>
On an intel dual-core machine it was 10 times slowdown than for a single<br>
processor intel machine.<br>
<br>
The problem occurs in this combination for the latest code:<br>
- Intel dual-processor<br>
- Sun JRE 5<br>
<br>
<br>
Toadie's team was very capable and found that there was thread contention<br>
with synchronized methods, either Xalan-J code or in JRE classes such as<br>
java.util.Vector used by Xalan-J. This performance problem was so
bad that<br>
thread contention just screamed at us, and made it easy to fine the "hot
"<br>
synchronization spots. With their direction I changed Vector to the<br>
unsynchronized ArrayList in a number of locations got back most of the<br>
performance for them.<br>
<br>
Toadie previously let me know that a single processor did not have this<br>
problem, and recently checked that the IBM JRE 5 does not have the same<br>
synchronization performance problem on the dual-core machine.<br>
<br>
So heads up on Xalan's next multiprocessor performance problem.<br>
<br>
Hats off to Toadie who did a great job of analysis, providing hardware
to<br>
do the analysis, and even the patches.<br>
<br>
<br>
- Brian Minchau<br>
mailto:minchau@(protected)<br>
<br>
</font></tt>
<br><hr/><p style="font-size: 9pt; font-family: Verdana, Arial, Helvetica, sans
-serif;">Inventive Designers' Email Disclaimer:<br/><a href="http://www
.inventivedesigners.com/email-disclaimer">http://www.inventivedesigners.com
/email-disclaimer</a></p><br>
|
|
|