JDK-6682459 : Lock contention due to debug print
- Type: Bug
- Component: xml
- Sub-Component: javax.xml.transform
- Affected Version: 6u6
- Priority: P3
- Status: Closed
- Resolution: Fixed
- OS: solaris_10
- CPU: sparc
- Submitted: 2008-04-01
- Updated: 2012-04-25
- Resolved: 2008-05-14
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| Other | JDK 6 | JDK 7 |
|---|---|---|
| 1.4.0 1.4Fixed | 6u14Fixed  |
7Fixed |
Description
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.
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.
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.
Comments
|