[9] RFR (XS): 8155781: C2: opaque unsafe access triggers an assert

[Vladimir Ivanov]

Updated version:
   http://cr.openjdk.java.net/~vlivanov/8155781/webrev.01/

I haven't pushed the initial fix yet, since I started looking into 
removing the checks. Unfortunately, recent migration of j.u.c to 
VarHandles made the problematic code shape much more frequent. I was 
asked to push the fix directly into jdk9/dev to reduce the noise in test 
results.

It turned out LibraryCallKit::inline_unsafe_load_store() doesn't need 
the check (no special cases for "wide" accesses), so I removed it.

I'll address the check in LibraryCallKit::inline_unsafe_access() 
separately (filed JDK-8162101), since I have to push it into hs-comp to 
avoid merge conflicts during hs -> dev integration.

Testing: JPRT (-testset hotspot), RBT (hs-tier0-comp; in progress).

Thanks!

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8162101

On 5/5/16 9:48 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8155781/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8155781
>
> The following code hits an assert in
> LibraryCallKit::inline_unsafe_access() during compilation of the
> following code:
>
>     int test(Object o) {
>         return UNSAFE.getInt(o, F_OFFSET);
>     }
>
> It baffles the compiler since such shape can be used to access both
> on-heap and off-heap memory (due to double-register addressing mode).
>
> The proposed fix is to convert the asserts into guards which revert to
> native calls in such cases.
>
> Testing: JPRT, RBT (hs-tier0-comp).
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov