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

[Aleksey Shipilev]

On Wed, 28 Oct 2020 19:55:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> 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);
>>     }
>
> I thought about it today. This whole idea of 'LRB-native' is flawed. What it does is prevent resurrection of objects when loading from a field or off-heap-location that is 'weak' or 'phantom'. This has nothing to do with -native. It has to do with the field being not-strong. For this reason I think we should call that variant of LRB something like LRB-weak instead. This warrants a larger reshuffling that I'd do either before or after this change goes in. I'd probably also merge our 3(!) different runtime LRB impls into one, with templated path to prevent resurrection, etc. I guess the 2 interpreter LRB entries can also be unified, and differ only in the target entry being called.
> 
> The only distinction for which IN_NATIVE is relevant is for figuring out whether or not the reference is compressed or not. That is all.

OK, so that would resolve the `TODO` I suggested in the code comment above, right? If so, we can just put in the code comment for now.

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

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