[9] RFR (XS): 8155781: C2: opaque unsafe access triggers an assert
Leonid Mesnik
leonid.mesnik at oracle.com
Thu Jul 21 16:48:04 UTC 2016
Thanks for fixing. Test looks good now.
Leonid
On 21.07.2016 19:47, Vladimir Ivanov wrote:
> Thanks, fixed (updated in place).
>
> Best regards,
> Vladimir Ivanov
>
> On 7/21/16 7:32 PM, Leonid Mesnik wrote:
>> Vladimir
>>
>> 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.
>>
>> Leonid
>>
>>
>> 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