[jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as strong [v4]
zgu at openjdk.java.net
Thu Jul 8 14:01:54 UTC 2021
On Thu, 8 Jul 2021 12:47:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> We've observed test failures in jcstress, see:
>> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
>> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
>> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
>> - [x] the provided jcstress test
>> - [x] hotspot_gc_shenandoah
>> - [x] tier1
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> Fix assert
src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 643:
> 641: }
> 642: #endif
> 643: load_store = kit->gvn().transform(new ShenandoahLoadReferenceBarrierNode(NULL, load_store, access.decorators() & ~ON_UNKNOWN_OOP_REF));
This load should go through slow path when GC is in progress, right? Should let slow path to resolve the strength? sounds there is possibility to resurrect dead oop.
More information about the hotspot-gc-dev