RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength, where possible [v2]
shade at openjdk.java.net
Fri Jul 9 10:48:51 UTC 2021
On Thu, 8 Jul 2021 18:40:33 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:
> Revert C2 changes
Looks okay to me, I am testing.
One nit: lets assert no UNKNOWN decorators are passed to AccessBarrier methods that do not do the UNKNOWN resolve?
More information about the hotspot-gc-dev