> On Feb 19, 2016, at 1:22 PM, Aleksey Shipilev <aleksey.shipi...@oracle.com> > wrote: > > 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:
That comment is better. > http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02/ > http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/ > > Cheers, > -Aleksey > >
