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

Vitaly Davidovich vitalyd at gmail.com
Thu Nov 15 00:58:47 UTC 2012

Personally, I feel like the concern is a bit overstated:

  1. the n in O(n) is likely actually fairly small in practice (at least in what I'd consider sane code)
  2. I think a lot of people that worry about perf probably aren't using substring() anyway
  3. copying char[] is optimized by jit - this is basically a memcpy()-like call, which modern machines handle well
  4. the upside is strings are 8 bytes smaller
  5. .NET substring() has always allocated new storage (via an optimized internal VM call) and never shared the char[] and I haven't come across any complaints or seen serious perf problems myself (granted I seldom use substring)

So I don't know if this is anything to worry about in practice.

Sent from my phone On Nov 14, 2012 5:26 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:

On 06/03/2012 11:35 PM, Mike Duigou wrote: > [I trimmed the distribution list] > > On Jun 3 2012, at 13:44 , Peter Levart wrote: > >> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: >>> Changeset: 2c773daa825d >>> Author: mduigou >>> Date: 2012-05-17 10:06 -0700 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d >>> >>> 6924259: Remove offset and count fields from java.lang.String >>> Summary: Removes the use of shared character array buffers by String along >>> with the two fields needed to support the use of shared buffers. >> Wow, that's quite a change. > Indeed. It was a long time in development. It is a change which is expected to be overall beneficial though and in the general case a positive win.

Wow! If the previous behavior of substring() was once a bug, by now it has become a well known feature. People know about it, and people depend on it. This change is a big surprise. Changing O(1) to O(n) is a breach of contract. It'll break lots of old code; and meanwhile lots of new code are still being written based on the old assumption. After people learned about the new behavior, they need to comb through and rewrite their code. The worst part is the same code performs very differently on different versions of JDK. What's a programmer supposed to do if his code targets JDK6 and above? If the cost of strings are no longer certain, what else can we believe in? Is there any chance in hell to roll it back? Maybe add a new method for the new behavior? Zhong Yu

More information about the core-libs-dev mailing list