JDK-8158228 : C1 incorrectly folds mismatched loads from stable arrays
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • CPU: generic
  • Submitted: 2016-05-31
  • Updated: 2019-05-08
  • Resolved: 2017-08-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b126Fixed
Related Reports
Relates :  
JDK-8150180 - String.value contents should be trusted
Relates :  
JDK-8143407 - C1: @Stable array support
Description
The test from JCK-runtime suite fails in case of compilation mode for any VM (-Xcom).

For mixed mode and interpreter mode the test passes. See logs:

user@host:/export/local/sk$ ./jdk9_120_p1/bin/java -Xcomp -showversion NewTestCase
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+120)
Java HotSpot(TM) Minimal VM (build 9-ea+120, compiled mode)

method setIndex(int) return incorrect char
  returned char is f
  expected char is t
public void setIndex(int index)
user@host:/export/local/sk$ ./jdk9_120_p1/bin/java -Xint -minimal -showversion NewTestCase
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+120)
Java HotSpot(TM) Minimal VM (build 9-ea+120, interpreted mode)

OKAY
user@host:/export/local/sk$ ./jdk9_120_p1/bin/java -Xmixed -minimal -showversion NewTestCase
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+120)
Java HotSpot(TM) Minimal VM (build 9-ea+120, mixed mode)

OKAY
Comments
Fix verified by regression test.
07-08-2017
The problem is with C1's folding of stable values and was introduced by JDK-8143407 in JDK 9 b112. Workarounds: -XX:-FoldStableValues -XX:-TieredCompilation -XX:DisableIntrinsic=_getCharStringU
01-06-2016
Summary: Multiple tests fail since JDK 9 b110 because String.charAt() returns a wrong value for a constant string. In b110, JDK-8143407 enabled C1 to constant fold stable array elements and since JDK-8150180 String.value is constant. The problem is that C1 does not correctly fold mismatched loads from stable arrays. In this case, String.value is a stable byte[] and StringUTF16.charAt() is intrinsified as char load. Instead of a char load, C1 emits a byte load because it does not check for mismatched loads. I fixed this by passing the BasicType of the mismatched load to ciArray::element_value() to ensure the correct constant is emitted. I verified that both 'Lex06403.java' and 'NewTestCase.java' pass with the fix: http://cr.openjdk.java.net/~thartmann/8158228/webrev.00/
01-06-2016
I was able to reproduce this on x86 as well: java -Xcomp -XX:-CompactStrings NewTestCase method setIndex(int) return incorrect char returned char is f expected char is t public void setIndex(int index) It showed up on ARM only because CompactStrings is disabled by default.
31-05-2016
ILW = Incorrect result, reproducible with -Xcomp on ARM, disable _getCharStringU intrinsic = HML = P2
31-05-2016
Doesn't reproduce on x64. Seems to be arm only.
31-05-2016