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