JEP 254: Compact Strings (original) (raw)

Jeremy Manson jeremymanson at google.com
Sat May 16 00:34:57 UTC 2015

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

More information about the core-libs-dev mailing list