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


Reply via email to