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: [EMAIL PROTECTED] "Computers in the future may weigh no more than 1.5 tons." - Popular Mechanics, forecasting the relentless march of science, 1949 Brian Minchau <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] -------------------------------------------------- Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer
