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

Leonid Mesnik leonid.mesnik at oracle.com
Thu Jul 21 16:32:39 UTC 2016


I think that test should fail if it is executed on the client/minimal 
without additional '-XX:+IgnoreUnrecognizedVMOptions'.  Could you please 
add corresponding '@requires' tag of '-XX:+IgnoreUnrecognizedVMOptions' 
if you

think that it would be useful to run it on the jdk build without C2.


On 21.07.2016 16:49, Vladimir Ivanov wrote:
> 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

More information about the hotspot-compiler-dev mailing list