RFR (S): 8226411: C2: Avoid memory barriers around off-heap unsafe accesses
vladimir.x.ivanov at oracle.com
Fri Dec 6 15:19:58 UTC 2019
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().
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