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

Peter Levart peter.levart at gmail.com
Fri Feb 19 14:05:12 UTC 2016


Just a stupid question.

Your comment in String:

  140      * @implNote Note this field is not {@link Stable}, because we 
  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

More information about the core-libs-dev mailing list