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