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

[Stefan Karlsson]

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