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