RFR (S) 8150180: String.value contents should be trusted

[Aleksey Shipilev]

On 02/20/2016 01:40 AM, Christian Thalinger wrote:
>> On Feb 19, 2016, at 9:03 AM, John Rose <john.r.rose at oracle.com> wrote:
>> On Feb 19, 2016, at 9:57 AM, Christian Thalinger <christian.thalinger at oracle.com <mailto:christian.thalinger at 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