RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses
erik.osterlund at oracle.com
Mon Dec 9 15:59:39 UTC 2019
On 2019-12-06 16:19, Vladimir Ivanov wrote:
> Hi Erik,
> I like your idea. Here's updated version:
> 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().
> Best regards,
> Vladimir Ivanov
> On 05.12.2019 23:14, Erik Österlund wrote:
>> 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?
>>> 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.
>>>> On 11/29/19 7:42 AM, Vladimir Ivanov wrote:
>>>> 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 . 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 .
>>>> Testing: tier1-6.
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>  https://bugs.openjdk.java.net/browse/JDK-8224182
More information about the hotspot-gc-dev