[14] RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses

[Vladimir Ivanov]

Thanks, Erik!

Best regards,
Vladimir Ivanov

On 09.12.2019 18:59, Erik Österlund wrote:
> Hi Vladimir,
> 
> On 2019-12-06 16:19, Vladimir Ivanov wrote:
>> Hi Erik,
>>
>> I like your idea. Here's updated version:
>>   http://cr.openjdk.java.net/~vlivanov/8226411/webrev.01
> 
> Looks good!
> 
>> While browsing the code, I noticed that changes in 
>> G1BarrierSetC2::load_at_resolved() aren't required (need_cpu_mem_bar 
>> is used for oop case). But I decided to keep them to keep it 
>> (relatively) close to C2Access::needs_cpu_membar().
> 
> Sounds reasonable.
> 
> Thanks,
> /Erik
> 
>> Best regards,
>> Vladimir Ivanov
>>
>> On 05.12.2019 23:14, Erik Österlund wrote:
>>> Hi,
>>>
>>> Could we use the existing IN_NATIVE decorator instead of introducing 
>>> a new decorator that seems to be an alias for the same thing? The 
>>> decorator describing its use (IN_NATIVE) says it is for off-heap 
>>> accesses pointing into the heap. We can just remove from the comment 
>>> the part presuming it is a reference.
>>>
>>> What do you think?
>>>
>>> Thanks,
>>> /Erik
>>>
>>>> On 5 Dec 2019, at 20:16, Vladimir Kozlov 
>>>> <vladimir.kozlov at oracle.com> wrote:
>>>>
>>>> CCing to GC group.
>>>>
>>>> Looks fine to me but someone from GC land have to look too.
>>>>
>>>> I wish we have more concrete indication for off-heap access instead 
>>>> of guessing it based on how we address memory through Unsafe API.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>>> On 11/29/19 7:42 AM, Vladimir Ivanov wrote:
>>>>> http://cr.openjdk.java.net/~vlivanov/8226411/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8226411
>>>>> There were a number of fixes in C2 support for unsafe accesses 
>>>>> recently which led to additional memory barriers around them. It 
>>>>> improved stability, but in some cases it was redundant. One of 
>>>>> important use cases which regressed is off-heap accesses [1]. The 
>>>>> barriers around them are redundant because they are serialized on 
>>>>> raw memory and don't intersect with any on-heap accesses.
>>>>> Proposed fix skips memory barriers around unsafe accesses which are 
>>>>> provably off-heap (base == NULL).
>>>>> It (almost completely) recovers performance on the microbenchmark 
>>>>> provided in JDK-8224182 [1].
>>>>> Testing: tier1-6.
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8224182
>>>
>