-
Bug
-
Resolution: Fixed
-
P1
-
9
-
b110
-
Verified
This seems to reproduce only with String code, when @Stable is placed over String.value field with JDK-8150180:
public final class String
implements java.io.Serializable, Comparable<String>, CharSequence {
+ @Stable
private final byte[] value;
Then after we compile charAt() over a constant String, we are cut out higher bytes.
Steps to reproduce:
1. Get the test: http://cr.openjdk.java.net/~shade/8150186/TestStableStrings.java
2. Run, get:
java.lang.IllegalStateException: Failed, got = 45, but needed 1069
at TestStableStrings.main(TestStableStrings.java:15)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
at java.lang.Thread.run(Thread.java:804)
1069 is 100_00101101b, while 45 is 101101b, so we cut out half of the char.
Test passes with -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_getCharStringU, which indicates the potential trouble with intrinsic.
Test passes with -XX:-FoldStableValues, which may indicate that intrinsic generates an access that @Stable machinery then misoptimizes.
AFAIU, StringUTF16.getChar produces a "char" load over byte[] array. LoadNode::Value code that folds stable array elements ignores that load type, and reads the constant off the array with the array type, e.g. "byte" -- see memnode.cpp::fold_stable_ary_elem. Everything goes downhill from there. This seems to be a generic problem with @Stable folding over mismatched accesses.
We avoid this withJDK-8150180 by special-casing the constant values in intrinsic. However, some other code shapes may expose the same problem, see JDK-8150517. The compiler code should really assert the mismatched loads when folding @Stable, and bail on mismatch.
public final class String
implements java.io.Serializable, Comparable<String>, CharSequence {
+ @Stable
private final byte[] value;
Then after we compile charAt() over a constant String, we are cut out higher bytes.
Steps to reproduce:
1. Get the test: http://cr.openjdk.java.net/~shade/8150186/TestStableStrings.java
2. Run, get:
java.lang.IllegalStateException: Failed, got = 45, but needed 1069
at TestStableStrings.main(TestStableStrings.java:15)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
at java.lang.Thread.run(Thread.java:804)
1069 is 100_00101101b, while 45 is 101101b, so we cut out half of the char.
Test passes with -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_getCharStringU, which indicates the potential trouble with intrinsic.
Test passes with -XX:-FoldStableValues, which may indicate that intrinsic generates an access that @Stable machinery then misoptimizes.
AFAIU, StringUTF16.getChar produces a "char" load over byte[] array. LoadNode::Value code that folds stable array elements ignores that load type, and reads the constant off the array with the array type, e.g. "byte" -- see memnode.cpp::fold_stable_ary_elem. Everything goes downhill from there. This seems to be a generic problem with @Stable folding over mismatched accesses.
We avoid this with
- duplicates
-
JDK-8150517 FoldStableValues code needs to be revisited for compressed strings
-
- Closed
-
-
JDK-8150515 sun/tools/jrunscript/* tests fail with "Expected an operand but found var"
-
- Closed
-
- relates to
-
JDK-8151020 [TESTBUG] UnsafeGetStableArrayElement::testL_* fail intermittently
-
- Resolved
-
-
JDK-8150817 Many @Stable related test failures after JDK-8150186 was pushed
-
- Closed
-
-
JDK-8150180 String.value contents should be trusted
-
- Resolved
-
-
JDK-8181833 [Graal] UnsafeGetStableArrayElement.java fails with "assertNotEquals: expected 1 to not equal 1"
-
- Closed
-
(1 relates to)