RFR: 8254315: Shenandoah: Concurrent weak reference processing [v12]
Aleksey Shipilev
shade at openjdk.java.net
Wed Oct 28 18:59:49 UTC 2020
On Tue, 27 Oct 2020 11:47:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 360:
>>
>>> 358:
>>> 359: if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
>>> 360: load_reference_barrier_native(masm, dst, src, (decorators & IN_NATIVE) == 0);
>>
>> I am a bit confused. If we introduce the local variable, would it be `maybe_narrow_oop`? How does it relate to `IS_NATIVE`? Also, see that `use_load_reference_barrier_native` already tests `IS_NATIVE`.
>
> Yeah, this is confusing. Zhengyu also stumbled over this. Notice that (decorators & IN_NATIVE) == 0 tests for 'is *not* native'. The point is that native-access is *always* uncompressed-oops, while accessing a referent is narrowOop or oop depending on UseCompressedOops. Hence the distinction. If you have a good suggestion on how to make this less confusing, I'd appreciate it.
But that's the thing that gets my head spinning. Why do we call into `lrb_native` for referents? This contradicts the idea that "native-access is always uncompressed-oops". I think this tries to overload "native" with more meaning that it is equipped to carry.
I think at very least it should say:
if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
// API impedance: when used on native refs, lrb-native necessarily works with full oops,
// but when used for weak/phantom refs, it might need to work with narrow oops.
// Therefore, we need to ask barrier code to look back at UseCompressedOops and
// decide, when lrb-native is not IN_NATIVE. TODO: Resolve this API impedance.
bool maybe_narrow_oop = (decorators & IN_NATIVE) == 0;
load_reference_barrier_native(masm, dst, src, maybe_narrow_oop);
} else {
load_reference_barrier(masm, dst, src);
}
-------------
PR: https://git.openjdk.java.net/jdk/pull/505
More information about the shenandoah-dev
mailing list