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

[Erik Österlund]

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