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

[Erik Österlund]

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
>>