During one of the JCAPS benchmark testing I ran into the following lock contention issue. The thread dump of the contention point is given below -

"p: thread-pool-1; w: 3" daemon prio=3 tid=0x090d7800 nid=0x37 waiting for monitor entry [0x31518000..0x31518c70]
  java.lang.Thread.State: BLOCKED (on  customer  monitor)
       at java.util.Collections$SynchronizedCollection.toString(Collections.java:1599)
       - waiting to lock <0x3fe503b0> (a java.util.Collections$SynchronizedRandomAccessList)
       at java.lang.String.valueOf(String.java:2827)
       at java.lang.StringBuilder.append(StringBuilder.java:115)
       at com.sun.enterprise.loader.EJBClassLoader.toString(EJBClassLoader.java:786)
       at java.lang.String.valueOf(String.java:2827)
       at java.lang.StringBuilder.append(StringBuilder.java:115)
       at com.sun.org. customer .xalan.internal.xsltc.dom.ObjectFactory.lookUpFactoryClass(ObjectFactory.java:220)
       at com.sun.org. customer .xalan.internal.xsltc.dom.XSLTCDTMManager.getDTMManagerClass(XSLTCDTMManager.java:101)

The associated code at com.sun.org. customer .xalan.internal.xsltc.dom.ObjectFactory.lookUpFactoryClass is

       debugPrintln("created new instance of " + providerClass +
                  " using ClassLoader: " + cl);

Even though the debug is not turned on, the entire String is required to be created before the debugPrintln method can be called. It is during the process of this String creating the lock is contented. A simple fix for this is to call the debugPrintln method only if DEBUG is enabled. I ran some experiments with that modification and got a 24% improvement in our microbenchmark.
Posted Date : 2008-04-01 00:36:52.0

During one of the JCAPS benchmark testing I ran into the following lock contention issue. The thread dump of the contention point is given below -

"p: thread-pool-1; w: 3" daemon prio=3 tid=0x090d7800 nid=0x37 waiting for monitor entry [0x31518000..0x31518c70]
  java.lang.Thread.State: BLOCKED (on object monitor)
       at java.util.Collections$SynchronizedCollection.toString(Collections.java:1599)
       - waiting to lock <0x3fe503b0> (a java.util.Collections$SynchronizedRandomAccessList)
       at java.lang.String.valueOf(String.java:2827)
       at java.lang.StringBuilder.append(StringBuilder.java:115)
       at com.sun.enterprise.loader.EJBClassLoader.toString(EJBClassLoader.java:786)
       at java.lang.String.valueOf(String.java:2827)
       at java.lang.StringBuilder.append(StringBuilder.java:115)
       at com.sun.org.apache.xalan.internal.xsltc.dom.ObjectFactory.lookUpFactoryClass(ObjectFactory.java:220)
       at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTMManagerClass(XSLTCDTMManager.java:101)

The associated code at com.sun.org.apache.xalan.internal.xsltc.dom.ObjectFactory.lookUpFactoryClass is

       debugPrintln("created new instance of " + providerClass +
                  " using ClassLoader: " + cl);

Even though the debug is not turned on, the entire String is required to be created before the debugPrintln method can be called. It is during the process of this String creating the lock is contented. A simple fix for this is to call the debugPrintln method only if DEBUG is enabled. I ran some experiments with that modification and got a 24% improvement in our microbenchmark.
Posted Date : 2008-04-01 00:36:52.0

During one of the JCAPS benchmark testing I ran into the following lock contention issue. The thread dump of the contention point is given below -

"p: thread-pool-1; w: 3" daemon prio=3 tid=0x090d7800 nid=0x37 waiting for monitor entry [0x31518000..0x31518c70]
  java.lang.Thread.State: BLOCKED (on object monitor)
       at java.util.Collections$SynchronizedCollection.toString(Collections.java:1599)
       - waiting to lock <0x3fe503b0> (a java.util.Collections$SynchronizedRandomAccessList)
       at java.lang.String.valueOf(String.java:2827)
       at java.lang.StringBuilder.append(StringBuilder.java:115)
       at com.sun.enterprise.loader.EJBClassLoader.toString(EJBClassLoader.java:786)
       at java.lang.String.valueOf(String.java:2827)
       at java.lang.StringBuilder.append(StringBuilder.java:115)
       at com.sun.org.apache.xalan.internal.xsltc.dom.ObjectFactory.lookUpFactoryClass(ObjectFactory.java:220)
       at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTMManagerClass(XSLTCDTMManager.java:101)

The associated code at com.sun.org.apache.xalan.internal.xsltc.dom.ObjectFactory.lookUpFactoryClass is

       debugPrintln("created new instance of " + providerClass +
                  " using ClassLoader: " + cl);

Even though the debug is not turned on, the entire String is required to be created before the debugPrintln method can be called. It is during the process of this String creating the lock is contented. A simple fix for this is to call the debugPrintln method only if DEBUG is enabled. I ran some experiments with that modification and got a 24% improvement in our microbenchmark.
Posted Date : 2008-04-01 00:36:52.0

N/A

Debug message construction should be avoided.
Posted Date : 2008-04-02 00:35:11.0

The patch, along with that for 6660724 has been verified by the JCAPS performance team. It is now available in JAXP 1.4 RI. Requests will be made for JDK integration.
Posted Date : 2008-05-14 18:43:11.0