JEP 254: Compact Strings

[Aleksey Shipilev]

(getting back to this)

Hi Jeremy,

On 05/16/2015 03:34 AM, Jeremy Manson wrote:
> 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.

Yes, we know that's a potential problem, e.g. outlined here:
 http://cr.openjdk.java.net/~shade/density/equals.txt

The hope is that the string coder check would be amortized by the
substantial performance improvement with the ubiquitous Latin1
(optimized) operations. Also, getting a few code generation quirks
kicked out may further offset the perceived performance costs of doing
this (you can do such a trick every so often, but not all the time).


> 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.

The thing is, many mutator ops on Strings are also improved, because the
data become more easily cacheable and/or require less steps to complete
(think vectorization that takes 2x less instructions).


> 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.

It is not true that JEP hopes to have other organizations to do testing
for it. The JEP tries to illuminate that this is a performance-sensitive
change, so early testing and feedback is very appreciated. So, if you
have the String-intensive workloads in your org, can you try and run the
prototype JDK against it? Our early runs on our workloads of interest
show the appealing improvements.

That is, the decision to integrate this is not done yet, as we don't
have the complete performance picture and/or fully-tested prototype. In
other words, there are quite a few blank spots to fill out. Your data
may be the part of that picture when we decide to integrate in JDK 9.


> (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.)

This is your golden ticket: if you come back with concrete data in your
hands saying that the particular tradeoff the JEP made is not sensible
for your applications, it would be considered in the decision to
integrate. But, it should be a real data and/or contrived benchmark
simulating the real-world scenario, not just theoretical appeals -- we
know how misguided those can get.


Thanks,
-Aleksey