On 02/20/2016 01:40 AM, Christian Thalinger wrote: >> On Feb 19, 2016, at 9:03 AM, John Rose <john.r.r...@oracle.com> wrote: >> On Feb 19, 2016, at 9:57 AM, Christian Thalinger >> <christian.thalin...@oracle.com <mailto:christian.thalin...@oracle.com>> >> wrote: >>> Why don’t you change the values to: >>> >>> static final byte LATIN1 = 1; >>> static final byte UTF16 = 2;
We've been over this during Compact Strings development. The idea that John has below is related to our actual insights leading to 0/1 instead of 1/2. The best thing you can do with 1/2 is, apparently: int length() { return value.length >> (coder - 1); } char charAt(int idx) { return getCharAt(idx * coder); // variant 1 return getCharAt(idx << (coder - 1)); // variant 2 } ...and you are better off not doing excess "-1" or non-strength-reducible multiplications in a very hot paths in String. Anyhow, that ship had sailed, and any change in coder definitions would require to respin an awful lot of Compact String testing, and probably revalidating lots of premises in the code. This is good as a thought experiment, but not practical at this point in JDK 9 development. > But if coder is stable for both values the compiler can constant fold the > if-statement for the shift value: > > int len = val.length >> (coder == LATIN1 ? 0 : 1); > > That should produce the same code and we would avoid: > > 143 * Constant-folding this field is handled internally in VM. The constant-folding story is not the only story you should care about. For most Strings, we do not know either String.value or String.coder statically. This particular constant-folding bit affects String concatenation with constants, but the solution to it cannot possibly regress an overwhelming case of non-constant Strings. Changing the coder designations *would* affect non-constant Strings. I would guess that the comment on "coder" field throws a reader into thinking that @Stable is the answer to constant folding woes. But VM already trusts final fields in String (e.g. String.value.arraylength is folded, see JDK-8149813) -- as the part of TrustStaticNonFinalFields machinery, which hopefully some day would get exposed to other fields. Frozen arrays would hit the final (pun intended) nail into String.value folding. @Stable hack is doing that today; but that's a hack, for a very performance-sensitive corner in JDK. Hopefully the rewritten comments spell it better: http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02/ http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/ Cheers, -Aleksey