On Wed, 25 Nov 2020 08:43:04 GMT, Vladimir Ivanov <[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/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`? I don't think we have any !in_heap && on_weak loads today. But if we did, they would indeed need read barriers. We need read barrier if the the reference isn't provably strong... unless it's an AS_NO_KEEPALIVE access. That also reflects why the variable is called no_keepalive instead of keepalive; it is to reflect the shared decorator name used all over the place. I don't mind inverting it though, but personally found it easier to read when the names match our decorators. ------------- PR: https://git.openjdk.java.net/jdk/pull/1425
