JDK-6969165 : remove char[] allocation in new String(char[] buf) if buf does not escape
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs19
  • Priority: P2
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2010-07-14
  • Updated: 2016-05-04
  • Resolved: 2016-05-04
Related Reports
Relates :  
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);
    }

Comments
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
06-11-2015

[~thartmann], how long do you think it would take you to implement this? Maybe we can get an exception from the release team.
05-11-2015

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.
05-11-2015

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.
05-11-2015

Roland, can you look on this RFE? We now have arraycopy so this optimization should not be difficult to implement.
21-05-2015