RFR: 8254315: Shenandoah: Concurrent weak reference processing [v10]

[Zhengyu Gu]

On Wed, 21 Oct 2020 20:07:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp line 64:
>> 
>>> 62:   void load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr);
>>> 63:   void load_reference_barrier_native(MacroAssembler* masm, Register dst, Address load_addr, bool native);
>>> 64: 
>> 
>> is_native parameter seems weird. Maybe invert to is_weak_ref? 
>> BTW, I think I am seeing compressed oops in conc-stack-scanning.
>
> I think it's clearer as it is. The motivation for this is that native references are always oops, while weak reference's referents can be oops or narrowOops. Which means that we need to call a different method for native-refs (the always-oops entry point).
> The interesting differentiator is native vs. not-native, because one is always-oops, the other can be narrowOop. Weak vs not-weak is not as clear because there can also be weak/phantom native-refs.

The weird part is the method name, load_reference_barrier_**native**(), then you have parameter says that it may not be a native load and the parameter does nothing to hint the possible type differential. How about may_narrow_oop?

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

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