-
Bug
-
Resolution: Fixed
-
P1
-
1.2.2_11
-
013
-
sparc
-
solaris_2.5
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2053638 | 1.4.0 | Chris Hegarty | P1 | Resolved | Fixed | 1.4 |
JDK-2053637 | 1.3.1_05 | Chris Hegarty | P1 | Resolved | Fixed | 05 |
JDK-2053636 | 1.2.2_13 | Chris Hegarty | P1 | Resolved | Fixed | 13 |
Please refer to Closed Bug report : 4252910
JDK version: Solaris 1.2.2_09
IBM's customer, KBC Bank, is experiencing bad performance and bad scaling behaviour in their production environment. Within their application code, they do a lot of string manipulations and this seems to cause excessive lock contention within the java.lang.ThreadLocal method when they run stress tests (stress testing with AKTools 1.9.0 + thread analyses with WebSphere ThreadAnalyser).
The JVM 1.2.2 implementation of the java.lang.ThreadLocal class uses a synchronized mapping from threads -> values. This leads to heavy lock contention and limited scalability in string-intensive applications (which is the case for this application).
Thread analysis:
java.lang.Thread.join seems to be currently executing on 4 servlet threads.
Servlets affected:
com.kbc.alg.ifs.d0.servletcomponents.KBCServlet [4 occurrances]
Callers (servlet threads only):
com.kbc.knt.ifs.c0.task.C0l0201.ohlPsnGeg [1]
com.kbc.knt.ifs.c1.task.C1l0105.ohlPsnDet [2]
java.util.Collections$SynchronizedMap.get seems to be currently executing on 40 servlet threads and 4 non-servlet threads.
Since 90% (40 out of 44) of the threads doing servlet work seem to be executing this method, it would seem that there is some possibility that this method and its call path may warrant investigation. Servlets affected:
com.kbc.alg.ifs.d0.servletcomponents.KBCServlet [40 occurrances]
Callers (servlet threads only):
java.lang.ThreadLocal.get [8]
java.lang.ThreadLocal.set [9]
com.ibm.ivj.eab.record.cobol.CobolRecordAttributes.<init> [6]
com.ibm.ivj.eab.record.cobol.CobolRecordAttributes.fillBytes[3]
com.ibm.ivj.eab.record.cobol.CobolRecordAttributes.convertFromStringToByteArray [5] com.kbc.knt.ifs.c1.dispatcher.C1p61OptItf$Opt01RekZn.<init> [2]
com.kbc.knt.ifs.c0.dispatcher.C0p23OptItf$OptXxDetGeg.<init> [2]
com.ibm.ivj.eab.record.cobol.CobolRecordAttributes.setCodePage [1] com.kbc.knt.ifs.cs.dispatcher.Csp27OptItf$OptTpsTab.<init> [1]
com.kbc.knt.ifs.cs.dispatcher.Csp27IptItf.setIptFysCtr [1]
JDK version: Solaris 1.2.2_09
IBM's customer, KBC Bank, is experiencing bad performance and bad scaling behaviour in their production environment. Within their application code, they do a lot of string manipulations and this seems to cause excessive lock contention within the java.lang.ThreadLocal method when they run stress tests (stress testing with AKTools 1.9.0 + thread analyses with WebSphere ThreadAnalyser).
The JVM 1.2.2 implementation of the java.lang.ThreadLocal class uses a synchronized mapping from threads -> values. This leads to heavy lock contention and limited scalability in string-intensive applications (which is the case for this application).
Thread analysis:
java.lang.Thread.join seems to be currently executing on 4 servlet threads.
Servlets affected:
com.kbc.alg.ifs.d0.servletcomponents.KBCServlet [4 occurrances]
Callers (servlet threads only):
com.kbc.knt.ifs.c0.task.C0l0201.ohlPsnGeg [1]
com.kbc.knt.ifs.c1.task.C1l0105.ohlPsnDet [2]
java.util.Collections$SynchronizedMap.get seems to be currently executing on 40 servlet threads and 4 non-servlet threads.
Since 90% (40 out of 44) of the threads doing servlet work seem to be executing this method, it would seem that there is some possibility that this method and its call path may warrant investigation. Servlets affected:
com.kbc.alg.ifs.d0.servletcomponents.KBCServlet [40 occurrances]
Callers (servlet threads only):
java.lang.ThreadLocal.get [8]
java.lang.ThreadLocal.set [9]
com.ibm.ivj.eab.record.cobol.CobolRecordAttributes.<init> [6]
com.ibm.ivj.eab.record.cobol.CobolRecordAttributes.fillBytes[3]
com.ibm.ivj.eab.record.cobol.CobolRecordAttributes.convertFromStringToByteArray [5] com.kbc.knt.ifs.c1.dispatcher.C1p61OptItf$Opt01RekZn.<init> [2]
com.kbc.knt.ifs.c0.dispatcher.C0p23OptItf$OptXxDetGeg.<init> [2]
com.ibm.ivj.eab.record.cobol.CobolRecordAttributes.setCodePage [1] com.kbc.knt.ifs.cs.dispatcher.Csp27OptItf$OptTpsTab.<init> [1]
com.kbc.knt.ifs.cs.dispatcher.Csp27IptItf.setIptFysCtr [1]
- backported by
-
JDK-2053636 (thread) Need fix for Performance issue with ThreadLocal in Java 1.2.2_XX
- Resolved
-
JDK-2053637 (thread) Need fix for Performance issue with ThreadLocal in Java 1.2.2_XX
- Resolved
-
JDK-2053638 (thread) Need fix for Performance issue with ThreadLocal in Java 1.2.2_XX
- Resolved