Please refer to Closed Bug report : 4252910 

JDK version: Solaris 1.2.2_09

 xxxxx '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. customer .ivj.eab.record.cobol.CobolRecordAttributes.<init> [6]    
       com. customer .ivj.eab.record.cobol.CobolRecordAttributes.fillBytes[3]  
       com. customer .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. customer .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]       

N/A

Generally speaking it's preferable to move to a newer JRE rather than backporting individual performance improvements to an older one.  There was a huge overall performance improvement going from 1.2 to 1.3, and additional improvements going from 1.3 to 1.4.

If this problem is sufficiently critical to warrant an escalation leading to a patch, the "Suggested Fix" is *not* the best strategy.  The ThreadLocal implementation was rewritten twice, first in 1.3 and then in 1.4.  While the 1.3 implementation fixes the concurrency bottleneck of the 1.2 implementation and is substantially faster, it does have potentially bad object retention characteristics under certain usage patterns--loosely speaking, it has a potential memory leak.  The 1.4 implementation fixes this object retention problem, and it is much, much faster even than the 1.3 implementation.  Therefore, It is strongly recommended that the 1.4 implementation (rather than the 1.3 implementation) be backported.

  xxxxx@xxxxx   2002-04-12
================================================

JPSE has backported the 1.4 ThreadLocal implementation to 1.2.2_13 and 1.2.2_013

  xxxxx@xxxxx   2002-04-26

It would be a good idea to anonymize the classnames in the 
item description if your intent is to disguise the identity of 
whomever reported the problem.  Otherwise, it's pretty easy 
to figure out who "xxxxxx Bank" is.

sdjlkqshlk jqslh fhaljkn