RFR: 8263107: PSPromotionManager::copy_and_push_safe_barrier needs acquire memory barrier

[Kim Barrett]

On Mon, 7 Jun 2021 14:34:56 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I have trouble understanding (2). I have no idea how it can happen that reading the same volatile memory location a second time can retrieve an older value. Regarding JDK-8229169, age() and age_top() read different sizes. The ordering issue was related to different Bytes which weren't read before AFAICS.

Dredging through the Standard, the C++ memory model does require read-read
coherence, i.e. if there are sequential reads of an "atomic object" then the
second cannot obtain an older value than the first. (C++14 1.9/13-14,
1.10/14, 1.10/18). Of course, we're outside the Standard, since we aren't
using std::atomic<>.  But it seems likely to be okay to assume read-read
coherence for our Atomic accesses.

It's unclear to me what the Standard says about a case like JDK-8229169. The
code is reading a 32bit value, then later reading a 64bit value from the
same location. That can't be described within the Standard, since "atomic
object" is defined in terms of std::atomic<>. C++20 adds std::atomic_ref<>
which can temporarily make an existing object atomic, but that doesn't cover
something like this either.  So maybe the reordering behavior leading to
that bug report is allowed?  Of course, that code is also outside the
Standard since it is writing to one union member and reading from another.

Be that as it may, I've found a way to entirely bypass the whole question.
Rather than using cas_forward_to and later rereading the forwardee, instead
use forward_to_atomic and use the returned forwardee.

Mostly done re-running tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4371