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

[Peter Levart]

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;


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
>