On Wed, 25 Nov 2020 15:13:11 GMT, Erik Österlund <eosterl...@openjdk.org> wrote:
>> 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. >From this conversation the only change I can do is 'Turn (on_weak || >on_phantom) into !on_strong'. @fisk Is this correct? I am concern that it will include `unknown` decorator too. I agree with Erik to keep !no_keepalive because he prefer it and this is code supported by GC group. ------------- PR: https://git.openjdk.java.net/jdk/pull/1425
