United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7054038 Performance problem in 1.5 stringcoding.encode
JDK-7054038 : Performance problem in 1.5 stringcoding.encode

Details
Type:
Bug
Submit Date:
2011-06-13
Status:
Closed
Updated Date:
2012-03-20
Project Name:
JDK
Resolved Date:
2011-10-12
Component:
core-libs
OS:
generic
Sub-Component:
java.lang
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u30
Fixed Versions:
5.0u33 (b08)

Related Reports
Backport:
Backport:
Backport:

Sub Tasks

Description
SHORT SUMMARY: PERFORMANCE PROBLEM IN 1.5 STRINGCODING.ENCODE

INDICATORS:
Bottleneck around 5.0 sun.io.Converters.getDefaultEncodingName()
method when called heavily.

  The customer sees  performance degradation in 1.5.0 when compared to 6.0
  with StringCoding.encode method.   This is due to Lock Contention. They 
have
  tracked the issue to the following method  
  sun.io.Converters.getDefaultEncodingName() .  Looks like this path is not
  taken in 6.0 .  The test case to reproduce the issue is attached.
  
  Issue Clarification
  ===================
  The problem can be traced back to the following stack trace:
         at sun.io.Converters.getDefaultEncodingName(Converters.java:160)
          - waiting to lock <36538fd0> (a java.lang.Class)
          at java.lang.StringCoding.encode(StringCoding.java:452)
          at java.lang.String.getBytes(String.java:984)
 
  
COUNTER INDICATORS:
TRIGGERS:

See above.

KNOWN WORKAROUND: N/A
PRESENT SINCE: 1.5.0
HOW TO VERIFY: N/A
NOTES FOR SE: 
Seem to be 5.0 only. 6.0 code reported not to exhibit the same lock 
contention  even though the sun.io.Converters.getDefaultEncodingName() method 
looks to have the same behaviour around the lock monitor. Same fix should be 
ported to later JDK families all the same.

Suggested fix looks reasonable :

  Suggested Fix  for 5.0:
  
  In StringEncoding.java getDefaultEncodingName() acquires the lock every 
time
  the method is called, which will impact on the performance.
  public static String getDefaultEncodingName() {
          synchronized (lock) { <<< lock here
              if (defaultEncoding == null) {
              }
          }
          return defaultEncoding;
      }
  Our suggestion is if we will check for null first and then acquire a lock,
  then getDefaultEncodingName() function will not acquire a lock always and 
we
  will see better performance.
  
  if (defaultEncoding == null) {<<< add this line
          synchronized (lock) {
              }
          }
          return defaultEncoding;
      }
  
  With above mentioned changes the customer is seeing a better performance in
  the test case with 1.5.0.

REGRESSION: N/A

                                    

Comments
EVALUATION

don't acquire the lock if defaultEncoding variable has already been set.
                                     
2011-06-21



Hardware and Software, Engineered to Work Together