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

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 `old_substring()`
> method that preserves O(1). Unfortunately `old_substring()` 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