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

remove char[] allocation in new String(char[] buf) if buf does not escape

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P2
    • Resolution: Won't Fix
    • Affects Version/s: hs19
    • Fix Version/s: 10
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • CPU:
      sparc
    • OS:
      solaris_10

      Description

      For example, the char[] allocation you want to make sure is removed is the copying happening in new String(char[]):

          public static String _printBase64Binary(byte[] input, int offset, int len) {
              char[] buf = new char[((len + 2) / 3) * 4];
              int ptr = _printBase64Binary(input, offset, len, buf, 0);
              assert ptr == buf.length;
              return new String(buf);
          }
      1. Test.java
        0.6 kB
        Tobias Hartmann

        Issue Links

          Activity

          Hide
          kvn Vladimir Kozlov added a comment -
          Roland, can you look on this RFE? We now have arraycopy so this optimization should not be difficult to implement.
          Show
          kvn Vladimir Kozlov added a comment - Roland, can you look on this RFE? We now have arraycopy so this optimization should not be difficult to implement.
          Hide
          dsurber Douglas Surber added a comment -
          It is very unfortunate this has been moved to 10. This is a very important enhancement for JDBC drivers. A large fraction of the data in a database is characters. A large fraction of the execution time of a JDBC driver is constructing java.lang.String values from network bits. We have seen a 10% performance improvement in some benchmarks by removing one copy during String construction. Removing this copy will probably result in an even greater performance. Please reconsider.
          Show
          dsurber Douglas Surber added a comment - It is very unfortunate this has been moved to 10. This is a very important enhancement for JDBC drivers. A large fraction of the data in a database is characters. A large fraction of the execution time of a JDBC driver is constructing java.lang.String values from network bits. We have seen a 10% performance improvement in some benchmarks by removing one copy during String construction. Removing this copy will probably result in an even greater performance. Please reconsider.
          Hide
          thartmann Tobias Hartmann added a comment -
          Hi Douglas, unfortunately FC for JDK 9 is Dec 10, 2015 which is too close for this. I will address this for a JDK 9 update.
          Show
          thartmann Tobias Hartmann added a comment - Hi Douglas, unfortunately FC for JDK 9 is Dec 10, 2015 which is too close for this. I will address this for a JDK 9 update.
          Hide
          twisti Christian Thalinger added a comment -
          [~thartmann], how long do you think it would take you to implement this? Maybe we can get an exception from the release team.
          Show
          twisti Christian Thalinger added a comment - [~thartmann], how long do you think it would take you to implement this? Maybe we can get an exception from the release team.
          Hide
          thartmann Tobias Hartmann added a comment - - edited
          I had a closer look into this and actually there are some problems due to CompactStrings (JDK-8054307):
          String.value is now a byte[] instead of a char[] and therefore the String(char value[]) constructor was modified. Instead of a simple arraycopy into String.value, we now try to compress the characters from UTF16 (2 byte) into Latin1 (1 byte), see [1]. Even if CompactStrings is disabled, we cannot use an arraycopy because we have to copy chars between char[] and byte[] which is not possible with arraycopy. Currently, we use an intrinsic for this (see also JDK-8139132).

          So with the CompactStrings changes, this optimization is not applicable to String construction. However, this might still pay off as a general optimization independent of String construction: we try to avoid allocation if we know that the original array is not escaping and not updated after the copy operation.

          [~twisti], given this, it is more a question about priorities. I have some other high priority enhancements in need to get in before JDK 9 FC. What do you think?

          [1] http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/jdk/src/java.base/share/classes/java/lang/String.java.sdiff.html
          Show
          thartmann Tobias Hartmann added a comment - - edited I had a closer look into this and actually there are some problems due to CompactStrings ( JDK-8054307 ): String.value is now a byte[] instead of a char[] and therefore the String(char value[]) constructor was modified. Instead of a simple arraycopy into String.value, we now try to compress the characters from UTF16 (2 byte) into Latin1 (1 byte), see [1]. Even if CompactStrings is disabled, we cannot use an arraycopy because we have to copy chars between char[] and byte[] which is not possible with arraycopy. Currently, we use an intrinsic for this (see also JDK-8139132 ). So with the CompactStrings changes, this optimization is not applicable to String construction. However, this might still pay off as a general optimization independent of String construction: we try to avoid allocation if we know that the original array is not escaping and not updated after the copy operation. [~twisti], given this, it is more a question about priorities. I have some other high priority enhancements in need to get in before JDK 9 FC. What do you think? [1] http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/jdk/src/java.base/share/classes/java/lang/String.java.sdiff.html

            People

            • Assignee:
              thartmann Tobias Hartmann
              Reporter:
              kvn Vladimir Kozlov
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: