RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly [v3]

[Stefan Karlsson]

On Mon, 2 Jan 2023 08:34:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hmm. So we have IN_NATIVE accesses tagged as encode_in_native, and essentially AS_RAW accesses encoded as encode_non_barriered. I usually don't pick on naming, but the term "non-barriered" seems to stray away from already established terminology. I would prefer if the mentions of "non_barriered" changed to "as_raw" for consistency.

The following is not blocking this review, but could maybe be a starting point for a future discussion:

FWIW, I think that as_raw is doesn't explain "why" we are not using a normal IN_NATIVE access. Maybe that's also why Markus said:
> What is "raw", compared to "native"?

It's also an "AS" property and not an "IN" property, so it talks about "how" to perform the access and not what kind of root it is. I wanted to hint about what kind of root it was when I chose the name non-barriered.

Taking a step back, ZGC deals with two categories of roots:
1) Roots that requires the normal GC barriers (OopStorage, Global JNI Handle)
2) Roots that requires an "externalized" GC barrier to be applied before the root is accessed (Threads, frames, nmethods)

We use different terminology for these, like:
a) colored vs uncolored roots
b) barriered vs non-barriered (Maybe I'm the only one who is using these terms)

(a) is ZGC centric, and (b) tries to be more generic.

Neither of these are good names, but I think it would be beneficial to have good names for these. It would help explain why we can use "raw" access for the latter, and hopefully help the readability of the code. Maybe this is taking it too far, but if we have good names we could split IN_NATIVE into two, and tag each call site appropriately depending on root type.

-------------

PR: https://git.openjdk.org/jdk/pull/11741