hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String (original) (raw)

Zhong Yu zhong.j.yu at gmail.com
Wed Nov 14 15:32:44 UTC 2012

The new implementation also introduces a new form of memory leak. Previously N substrings take O(N) space. Now it takes O(N*m) space where m is the average length of substrings.

Some applications may be double penalized by the new implementation - both CPU and memory go up.

On Wed, Nov 14, 2012 at 9:14 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

Changing String.substring() from O(1) to O(n) is a big deal; we may say it breaks compatibility.

Any code that intends to work across JDK versions before and after 7u6 cannot use the method, since its behavior is so different in different versions. Any deployment that upgrades JDK to 7u6 and later needs to review all its usages of substring(). That's a ton of work. A quick workaround might be to refactor all substring() usages to some oldsubstring() method that preserves O(1). Unfortunately oldsubstring() cannot exist, so there's no quick workaround possible. The memory leak problem of the old substring() method is well-known among Java programmers, it's not really a big problem today. For the uninitiated, they might expect that substring() is leak-free; but they might also expect that substring() is O(1). There's no apparent reason why favoring one is better than favoring the other. In the old implementation, there's a workaround to achieve leak-free, by new String(String). In the new implementation, there is no workaround to achieve O(1), unless the developer uses something other than String. It is basically impossible to change String to another type if it's part of a method signature. With all these problems, please reconsider this change and see if you should roll it back. Thanks. Zhong Yu

More information about the core-libs-dev mailing list