JEP 254: Compact Strings

[Jeremy Manson]

So, I'm pretty dubious, mostly because of the risks mentioned in the JEP.
If you need a flag-check and two code paths for every String method, that's
going to make the String class more slow and bloated, and make it very
difficult for the JIT compiler to do its job inlining and intrinsifying
calls to String methods.

At Google, we spent a fair bit of time last year climbing out of the
performance hole that trimming substrings dropped us into - we had a fair
bit of code that was based around substrings being approximately
memory-neutral, and it cost us a lot of GC overhead and rewriting to make
the change.  The JDK itself still has exposed APIs that make tradeoffs
based on cheap substrings (the URL(String) constructor does a lot of this,
for example).

The proposed change here has the potential of doing the opposite with most
String operations - trading off less GC overhead for more mutator cost.
But String operations are a pretty big chunk of CPU time, on the whole.
Does anyone really have a sense of how to make this kind of decision?  The
JEP seems mostly to be hoping that other organizations will do the testing
for you.

(I agree that it is worth doing some experimentation in this area, but I
wanted to say this early, because if I could reach back in time and tell
you *not* to make the substring change, I would.  We seriously considered
simply backing it out locally, but it would have been a lot of effort for
us to maintain that kind of patch, and we didn't want our performance
tradeoffs to be that much different from the stock JDK's.)

Jeremy

On Thu, May 14, 2015 at 4:05 PM, <mark.reinhold at oracle.com> wrote:

> New JEP Candidate: http://openjdk.java.net/jeps/254
>
> - Mark
>