RFR: Move barriers into typeArrayOop.hpp direct memory accessors

Roman Kennke rkennke at redhat.com
Fri Feb 16 13:01:37 UTC 2018


typeArrayOop.hpp has a bunch of direct memory accessors (*_at_addr() ).
Those are used for both directly reading and writing primitive array
contents (e.g. using memcpy). We used to employ our barriers *before*
calling into those accessors, with the rationale that we don't know
whether the caller wants to read or write. However, it turns out that
it's fairly difficult to track when upstream adds new users, and a quick
check yields many places in code where those accessors are used without
any barriers.

I propose to place pessimistic write barriers into those accessors for
now, and remove all the barriers in callers. The potential performance
loss seems the less evil compared to corrupted memory due to missing
barriers.

http://cr.openjdk.java.net/~rkennke/typearray-barriers/webrev.00/

I also filed an upstream bug to use the Access API, and distinguish
between reads and writes:
https://bugs.openjdk.java.net/browse/JDK-8198286

Passes: hotspot_gc_shenandoah (fastdebug)

Ok?


More information about the shenandoah-dev mailing list