On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov <[email protected]> wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>
> Ran new test with Shenandoah. Found only one issue. As result I disable
> PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination.
> Someone from Shenandoah team have to test changes if that is enough.
src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 123:
> 121:
> 122: ins_encode %{
> 123: if (barrier_data() != 0) { // barrier could be elided by
> ZBarrierSetC2::analyze_dominating_barriers()
Maybe keep a bit reserved for `ZLoadBarrierElided` to just map it to `0`? The
former is preferred because it keeps the info that there was a barrier data
attached in the first place.
src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 623:
> 621: // Also we need to add memory barrier to prevent commoning reads
> 622: // from this field across safepoint since GC can change its value.
> 623: bool need_read_barrier = (((on_weak || on_phantom) && !no_keepalive) ||
There's a slight change: `in_heap && (on_weak || ...)` turns into `(on_weak
...) || (in_heap ...)`. It will introduce a read barrier for `!in_heap &&
on_weak` case. Does it occur in practice?
Another one: `on_weak` turns into ((on_weak ...) && !no_keepalive).
My interpretation is no read barrier needed when `NO_KEEPALIVE` flag is used
and currently a redundant barrier is issued.
Maybe replace `!no_keepalive` with just `keep_alive`? The former is harder to
parse.
The check grows bigger and bigger. Maybe it's time to split it?
Turn `on_weak || on_phantom` into `!is_strong`?
-------------
PR: https://git.openjdk.java.net/jdk/pull/1425
