RFR: 8256011: Shenandoah: Don't resurrect finalizably reachable objects [v3]

[Aleksey Shipilev]

On Tue, 10 Nov 2020 10:15:22 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 984:
>> 
>>> 982:       calladdr = CAST_FROM_FN_PTR(address, ShenandoahRuntime::load_reference_barrier_strong);
>>> 983:     }
>>> 984:     name = "load_reference_barrier_strong";
>> 
>> Why not separate "load_reference_barrier_strong" and  "load_reference_barrier_strong_narrow"?
>
> Dunno. Could do that. Within one instance of JVM, we would never see both narrow/non-narrow versions, though.

I would be more straight-forward looking, AFAICS. Is there any code that actually matches those strings?

>> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 58:
>> 
>>> 56: 
>>> 57:   static bool is_strong_access(DecoratorSet decorators) {
>>> 58:     return (decorators & (ON_WEAK_OOP_REF | ON_PHANTOM_OOP_REF | ON_UNKNOWN_OOP_REF)) == 0;
>> 
>> Is this the same as `decorators & ON_STRONG_OOP_REF`?
>
> It is the same, but in my testing I found that ON_STRONG_OOP_REF is not always set (it is the default when no other ON_XYZ_OOP_REF is specified).

Ouch. That means we should never trust `ON_STRONG_OOP_REF`, and instead go for `SBS::is_strong_access`?

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

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