JDK-7054038 : Performance problem in 1.5 stringcoding.encode
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0u30
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-06-13
  • Updated: 2014-11-19
  • Resolved: 2011-10-12
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.
Other
5.0u33 b08Fixed
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.
21-06-2011