RFR: 8212184: Incorrect oop ref strength used for referents in FinalReference
Per Liden
per.liden at oracle.com
Tue Oct 16 11:55:51 UTC 2018
Hi Kim,
On 10/15/2018 08:55 PM, Kim Barrett wrote:
>> On Oct 15, 2018, at 10:42 AM, Per Liden <per.liden at oracle.com> wrote:
>>
>> AccessBarrierSupport::resolve_unknown_oop_ref_strength() returns an incorrect oop ref strength for referents in FinalReference objects. It currently returns ON_WEAK_OOP_REF when it should return ON_STRONG_OOP_REF. This is not really an issue for any GC except ZGC when using the ZHeapIterator to walk the heap while resurrection is blocked.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212184
>> Webrev: http://cr.openjdk.java.net/~pliden/8212184/webrev.0
>>
>> /Per
>
> src/hotspot/share/gc/shared/accessBarrierSupport.cpp
> 32 if (!java_lang_ref_Reference::is_referent_field(base, offset) ||
> 33 java_lang_ref_Reference::is_final(base)) {
> 34 ds |= ON_STRONG_OOP_REF;
>
> This doesn't seem right. Doesn't this give the wrong answer for G1?
>
> I'm not even sure "strong" is the right answer for ZGC in the
> described context.
>
> What am I missing?
>
There's no way for a mutator to get hold of the referent (except via
Unsafe, which we've said we don't care about anyway). The only time we
would randomly step on a referent in a Finalizer is when we're doing
heap iteration in ZGC.
An alternative, to perhaps make this more explicit, would be to have an
ON_FINAL_OOP_REF, but it would end up doing the same thing as
ON_STRONG_OOP_REF.
/Per
More information about the hotspot-gc-dev
mailing list