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

[Christian Thalinger]

> On Feb 19, 2016, at 4:05 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi,
> 
> Just a stupid question.
> 
> Your comment in String:
> 
> 140      * @implNote Note this field is not {@link Stable}, because we want
> 141      * LATIN1 (0) coder to fold too. {@link Stable} would not allow that,
> 142      * as it reserves the default value as "not initialized" value.
> 143      * Constant-folding this field is handled internally in VM.
> 144      */
> 145     private final byte coder;

Why don’t you change the values to:

    static final byte LATIN1 = 1;
    static final byte UTF16  = 2;

?

> 
> 
> Couldn't @Stable final instance fields constant-fold the default value too in general? I mean can't it be assumed that the final field has been set before JIT kicks in?
> 
> Regards, Peter
> 
> On 02/19/2016 12:55 PM, Aleksey Shipilev wrote:
>> Hi,
>> 
>> Please review a simple performance improvement in Strings:
>>   https://bugs.openjdk.java.net/browse/JDK-8150180
>> 
>> In short, we want VM to trust constant String contents, so that
>> "Foo".charAt(0) is folded. As far as current Hotspot goes, this is only
>> achievable with @Stable -- we need to trust the array contents:
>>   http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/
>> 
>> This, however, steps into the compiler bug caused by StringUTF16.getChar
>> intrinsic producing a mismatched load, that is then folded incorrectly.
>> So we instead rely on Java level folding in cases like these:
>>   http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/
>> 
>> ...and it works:
>>   http://cr.openjdk.java.net/~shade/8150180/notes.txt
>> 
>> While VM change looks like a workaround, Vladimir I. and me concluded
>> that @Stable folding code should just reject folding mismatched loads to
>> begin with. So, getChar intrinsic change is the actual fix. Vladimir I.
>> ought to add more assertions in @Stable folding code separately:
>>   https://bugs.openjdk.java.net/browse/JDK-8150186
>> 
>> Since this issue might trigger compiler bugs, I would like to push
>> through hs-comp to pass compiler nightlies.
>> 
>> Cheers,
>> -Aleksey
>> 
>