RFR: 8277434: tests fail with "assert(is_forwarded()) failed: only decode when actually forwarded"

[Thomas Schatzl]

On Mon, 29 Nov 2021 08:07:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Ooof, so a relaxed forwardee installation comes with an odd invariant like this. I linked JDK-8204524 to this issue, to track where the forwardee installation was relaxed.
> 
> The fix for this particular issue looks fine to me, thanks.
> 
> A few follow-up questions about the general issue here. How is it not affecting the other places where G1 accesses `obj->forwardee()`, like in `G1ScanClosureBase::prefetch_and_push` or `G1ParScanThreadState::do_partial_array`? Also, it is not theoretically clear how would "All uses of a forwardee must take care to avoid reading from it without performing additional synchronization", given that the trouble had already happened on writer side, and there is little a reader can do to recover?

Both cases examine the original object in the collection set only; for the first example there is an explicit check on `is_in_cset` before the call (`G1ScanEvacuatedObjClosure::do_oop_work` is also only ever called from the thread that copied the object too; but all `G1ScanClosureBase::prefetch_and_push` are guarded by an `is_in_cset` check). `from_obj` in `G1ParScanThreadState::do_partial_array` is always in the collection set, i.e.

    assert(_g1h->is_in_reserved(from_obj), "must be in heap.");

could be rephrased as `g1h->is_in_cset(from_obj)`.

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

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