RFR: 8225770: ZGC: C2: Generates on_weak instead of on_strong barriers

[Stefan Karlsson]

Thanks, Erik.

StefanK

On 2019-07-02 17:34, Erik Österlund wrote:
> Hi Stefan,
>
> Looks good.
>
> Thanks,
> /Erik
>
> On 2019-07-02 14:43, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to fix a bug in C2 that causes it to 
>> generate on_weak load barriers when it should generate on_strong load 
>> barriers.
>>
>> http://cr.openjdk.java.net/~stefank/8225770/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8225770
>>
>> The bug is in the following code:
>> static bool load_has_weak_barrier(LoadNode* load)     { return 
>> ((load->barrier_data() & WeakBarrier) != 0); }
>>
>> The load_has_weak_barrier will return true when barrier_data() 
>> returns WeakBarrier (3), as expected, but it will also return true 
>> when barrier_data() only returns RequireBarrier (1), because '(1 & 3) 
>> != 0' is true.
>>
>> The difference between on_weak and on_strong barriers is that the 
>> former blocks accesses to dead objects, even if the weak reference 
>> hasn't been cleaned out yet. This only happens in the so called 
>> resurrection blocked window, where the GC traverses over the 
>> discovered references and either fixes the referents or clear them 
>> (set to null) if they are dead.
>>
>> Usually, all references have been cleaned by the marking cycle. 
>> However, the references in the object graph only reachable through 
>> j.l.r.Finalizer.referents will have the finalizable bit set. Also, 
>> these objects will not be considered "strongly live". The only way 
>> for these objects to be reached by the Java threads is if they are 
>> exposed by finalize() functions. When Java threads encounters 
>> references from such exposed objects, the on_strong load barrier will 
>> remove the finalizable bit, and the Java thread can proceed as 
>> normal. The on_weak load barriers should not be applied to these 
>> references. If they are (because of, for example, the bug that this 
>> patch fixes) the load barrier will first fail the fast path, because 
>> of the finalizable bit, then in the slow path it will find that the 
>> object is indeed not "strongly live" and will therefore (incorrectly) 
>> return null.
>>
>> This has been tested with the original test and the reproducing 
>> command line described in the bug report. I've also run this through 
>> tier 1-7.
>>
>> The fix is intended to go into both 13 and 14. For 14 I also intend 
>> to add verification code to quickly catch similar bugs in the future. 
>> See JDK-8227085.
>>
>> Thanks,
>> StefanK
>