RFR: 8256390: ZGC: Relocate in-place instead of having a heap reserve [v2]

Per Liden pliden at openjdk.java.net
Fri Nov 20 12:55:07 UTC 2020

On Thu, 19 Nov 2020 14:59:00 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Per Liden has updated the pull request incrementally with one additional commit since the last revision:
>>   Review Stefank
> src/hotspot/share/gc/z/zForwarding.cpp line 136:
>> 134:     ZStatTimer timer(ZCriticalPhaseRelocationStall);
>> 135:     ZLocker<ZConditionLock> locker(&_ref_lock);
>> 136:     while (Atomic::load(&_ref_count) != 0) {
> It would appear that we want acquire semantics for the _ref_count. The lock in this scope will give the load load_release() semantics. In practice, that boils down to the same fencing on all current platforms. But it is semantically incorrect in terms of memory model guarantees. I don't think we need to optimize this path, so just doing a load_acquire here seems more clear IMO. Unless I missed something. I see the elision of acquire on a few other double-locked patterns, and think we should consistently not do that.

Will fix!


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

More information about the hotspot-gc-dev mailing list