RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays
vladimir.x.ivanov at oracle.com
Wed Jun 1 13:38:47 UTC 2016
Thanks for taking care of the bug.
> 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. Also tested with JPRT and RBT (running).
As I understand the only source of mismatched accesses are String
(Unsafe accesses are the main source of mismatched accesses, but C1
doesn't optimize them).
Can you issue UnsafeObjectOp instead of LoadIndexed/StoreIndexed in
GraphBuilder::append_char_access or does C1 produce less efficient code
for unsafe accesses?
Otherwise, I suggest to mark LoadIndexed/StoreIndexed as mismatched (or
introduce UnsafeLoadIndexed/UnsafeStoreIndexed node) and check that in
Mismatch detection is more complex than just comparing basic types (see
Type::make_constant_from_array_element() & check_mismatched_access(),
though some checks are C2-specific).
Since C1 doesn't optimize unsafe accesses, I suggest to confine the fix
to String intrinsics.
>  https://bugs.openjdk.java.net/browse/JDK-8143407
>  https://bugs.openjdk.java.net/browse/JDK-8150180
More information about the hotspot-compiler-dev