RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly
Erik Ă–sterlund
eosterlund at openjdk.org
Fri Dec 23 09:47:49 UTC 2022
On Tue, 20 Dec 2022 16:30:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
> In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately.
>
> Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA.
>
> Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead.
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.
-------------
Changes requested by eosterlund (Reviewer).
PR: https://git.openjdk.org/jdk/pull/11741
More information about the hotspot-dev
mailing list