Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7054038

Performance problem in 1.5 stringcoding.encode

    Details

    • Subcomponent:
    • Resolved In Build:
      b08
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Not verified

      Backports

        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

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  coffeys Sean Coffey
                  Reporter:
                  shadowbug Shadow Bug
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: