(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
