8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly #11741

xmas92 · 2022-12-20T16:30:47Z

In a similar vain to 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.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly

Reviewers

Erik Österlund (@fisk - Reviewer) ⚠️ Review applies to e0d2eea4
Markus Grönlund (@mgronlun - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11741/head:pull/11741
$ git checkout pull/11741

Update a local copy of the PR:
$ git checkout pull/11741
$ git pull https://git.openjdk.org/jdk pull/11741/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 11741

View PR using the GUI difftool:
$ git pr show -t 11741

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11741.diff

Co-authored-by: Stefan Karlsson <stefank@openjdk.org>

bridgekeeper · 2022-12-20T16:32:18Z

👋 Welcome back aboldtch! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-12-20T16:34:47Z

@xmas92 The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2022-12-20T16:38:31Z

Webrevs

fisk

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.

xmas92 · 2023-01-02T08:34:05Z

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.

I agree, changed the terms used.

fisk

Looks good.

openjdk · 2023-01-02T13:25:27Z

@xmas92 This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly

Reviewed-by: eosterlund, mgronlun

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 171 new commits pushed to the master branch:

8b0133f: 8299259: C2: Div/Mod nodes without zero check could be split through iv phi of loop resulting in SIGFPE
d68de02: 8299845: Remove obsolete comments in DirtyCardToOopClosure::get_actual_top
debe587: 8298381: Improve handling of session tickets for multiple SSLContexts
eab1e62: 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack
c8a8388: 8299789: Compilation of gtest causes build to fail if runtime libraries are in different dirs
5f37cbe: 8297572: Remove unused PrecisionStyle::Precise
f95346e: 8299261: Clean up AWT D3D exports
195f313: 8287925: AArch64: intrinsics for compareUnsigned method in Integer and Long
3a66737: 8299525: RISC-V: Add backend support for half float conversion intrinsics
b7eb4e2: 8297306: Incorrect brackets in Javadoc for a constructor of IteratorSpliterator
... and 161 more: https://git.openjdk.org/jdk/compare/de8153cab76606350eb0ecc4302b23c52f0565a6...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

mgronlun · 2023-01-03T13:31:39Z

This is introducing some new, very complicated tagging scheme. I don't understand it. What is 0b011 ?

mgronlun · 2023-01-03T13:32:12Z

src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp

@@ -48,7 +48,7 @@ template <typename Delegate>
 void RootSetClosure<Delegate>::do_oop(oop* ref) {
  assert(ref != NULL, "invariant");
  assert(is_aligned(ref, HeapWordSize), "invariant");
-  if (*ref != NULL) {
+  if (NativeAccess<>::oop_load(ref) != nullptr) {


Why is this needed now?

The GC requires that load barriers to access oops in native storage. Currently the raw load works on all GCs as it only checks for null and all GCs encode null as NULL. But it is semantically wrong, and will not work with generational ZGC where there exist colored null which is not encoded as NULL.

Thanks. Should not the same construct be used in RawRootClosure? Or is it not needed there because the raw references to oops are not loaded through the Access Api?

Raw storage has no GC barriers so a null oop there must be NULL. The RawAccess API is really only used when dealing with narrowOop or templated generic code which can be either. RawAccess<>::oop_load(oop* ref) will just become a *ref. I think I used RawAccess everywhere initially ,but @fisk thought that it should not be used for raw oop*, not sure if there were some other reason behind it than it being unnecessary / obfuscating.

I think what I might have said is that RawAccess helps with compressed oop conversion and memory ordering sprinklings. If you don't need to do anything special with either of those and you just want a plain dereference of an oop*, then just doing a plain dereference achieves the same thing with a lot less templates. Using RawAccess can make it look like there is more to it than there really is. It's perfectly correct, but maybe just not needed and makes you scratch your head a bit when really there is nothing special to see at all.

mgronlun · 2023-01-03T13:32:51Z

src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.hpp

@@ -29,21 +29,33 @@
 #include "utilities/globalDefinitions.hpp"

 struct UnifiedOopRef {
+  static const uintptr_t tag_mask   = LP64_ONLY(0b111) NOT_LP64(0b011);
+  static const uintptr_t native_tag = 0b001;
+  static const uintptr_t raw_tag    = 0b010;


What is "raw", compared to "native"?

Native is native storage (not in java heap) which requires GC barriers. Raw is raw storage which does not require GC barriers. This is thread local storage, such as the handle area, stack, etc.

mgronlun · 2023-01-03T13:33:41Z

src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp

@@ -42,47 +42,60 @@ inline T UnifiedOopRef::addr() const {
 // this specialization provides a workaround.
 template<>
 inline uintptr_t UnifiedOopRef::addr<uintptr_t>() const {
-  return _value & ~uintptr_t(3);
+  return (_value & ~tag_mask) LP64_ONLY(>> 1);


Why a shift now as well?

I do not remember exactly. But I think there was some ref which on 64 bit which had the third bit set. That is this assert failed:
assert((reinterpret_cast<uintptr_t>(ref) & UnifiedOopRef::tag_mask) == 0, "Unexpected low-order bits");
I have to remove the shift and test again. I think it is strange given that ObjectAlignmentInBytes >= 8 but we added the shift for some reason. Or maybe I am just missing something obvious.

ObjectAlignmentInBytes is 4 by default on 32 bit VMs.

@fisk Why are the shifts needed on 64-bits?

Maybe the shift is needed in order to handle unaligned oops, as for code blob oops? The existing root processing logic has up to now skipped code blob oops, mainly because they were hard to encode. The rationale was that they are not roots in and of themselves. Now, we have seen several instances where chains are not found on iterations, so maybe the assumption on skipping code blob oops is wrong. With this encoding scheme in place, it would be possible to pass a closure for processing the code blob oops as well.

Sorry for the tardy response.

I think I forgot what the code was actually doing at the time of writing my previous answer. We are encoding narrowOop* and oop* here not narrowOop/oop. And narrowOop* are 4 byte aligned.

Thanks for the explanation, makes sense now.

mgronlun · 2023-01-03T13:34:10Z

src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp

+  assert(((reinterpret_cast<uintptr_t>(ref) LP64_ONLY(<< 1)) & UnifiedOopRef::tag_mask) == 0, "Unexpected low-order bits");
+  LP64_ONLY(assert(((reinterpret_cast<uintptr_t>(ref)) & (1ull << 63)) == 0, "Unexpected high-order bit"));
+  UnifiedOopRef result = { (reinterpret_cast<uintptr_t>(ref) LP64_ONLY(<< 1)) | tag };
+  assert(result.addr<T>() == ref, "sanity");


This is crazy hard to read.

Yeah. Refactoring out reinterpret_cast<uintptr_t>(ref) into a variable might help a bit at least. The assert just want to check that the lowest two bits are not set (the tagging does not destroy information) and that on 64 bit platforms the highest bit is not set (the shift does not destroy information).

Not sure if there is a better way to express those two invariants.

Maybe it would be easier to read the code if it was rewritten as (uncompiled):

uintptr_t value = reinterpret_cast<uintptr_t>(ref); #ifdef _LP64 // tag_mask is 3 bits. When ref is a narrowOop* we only have 2 alignment // bits, because of the 4 byte alignment of compressed oops addresses. // Shift up to make way for one more bit. assert((value & (1ull << 63)) == 0, "Unexpected high-order bit"); value <<= 1; #endif UnifiedOopRef result = { value | tag }; assert(result.addr<T>() == ref, "sanity");

mgronlun · 2023-01-03T13:35:10Z

src/hotspot/share/oops/accessBackend.hpp

@@ -1256,6 +1256,14 @@ namespace AccessInternal {
    inline bool operator !=(const T& other) const {
      return load<decorators | INTERNAL_VALUE_IS_OOP, P, T>(_addr) != other;
    }
+
+    inline bool operator ==(std::nullptr_t) const {


why std::nullptr_t?

This change is only here to facilitate being able to compare the OopLoadProxy object directly to nullptr instead of having to create and use an oop() / oop(NULL).

xmas92 · 2023-01-03T14:31:24Z

This is introducing some new, very complicated tagging scheme. I don't understand it. What is 0b011 ?

We have three storage/access types in the vm, Native, Raw, Heap. The two lower bits encode this. The only valid low bits are Heap: 0b00, Native: 0b01 and Raw: 0b10. Then each storage area can be use compressed oops or not. Which is the third bit.

0b011 would be an invalid tag.

mgronlun · 2023-01-03T16:17:14Z

This is introducing some new, very complicated tagging scheme. I don't understand it. What is 0b011 ?

We have three storage/access types in the vm, Native, Raw, Heap. The two lower bits encode this. The only valid low bits are Heap: 0b00, Native: 0b01 and Raw: 0b10. Then each storage area can be use compressed oops or not. Which is the third bit.

0b011 would be an invalid tag.

I see now it is the mask on 32-bit.

stefank · 2023-01-09T13:21:48Z

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 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:

Roots that requires the normal GC barriers (OopStorage, Global JNI Handle)
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.

xmas92 · 2023-01-12T12:35:56Z

/integrate

openjdk · 2023-01-12T12:38:31Z

Going to push as commit 89d3f3d.
Since your change was applied there have been 208 commits pushed to the master branch:

4b57334: 8278326: Socket close is not thread safe and other cleanup
036c808: 8298482: Implement ParallelGC NUMAStats for Linux
0ee8cac: 8299672: Enhance HeapDump JFR event
d716ec5: 8299179: ArrayFill with store on backedge needs to reduce length by 1
af8d3fb: 8264684: os::get_summary_cpu_info padded with spaces
78b1686: 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError
33f3bd8: Merge
945ef07: 8299862: OfAddress setter should disallow heap segments
636976a: 8299849: Revert JDK-8294461: wrong effectively final determination by javac
0abb87a: 8299227: host exif.org not found in link in doc comment
... and 198 more: https://git.openjdk.org/jdk/compare/de8153cab76606350eb0ecc4302b23c52f0565a6...master

Your commit was automatically rebased without conflicts.

openjdk · 2023-01-12T12:38:55Z

@xmas92 Pushed as commit 89d3f3d.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

UPSTREAM: UnifiedOopRef changes

6692c22

Co-authored-by: Stefan Karlsson <stefank@openjdk.org>

openjdk bot added the rfr Pull request is ready for review label Dec 20, 2022

openjdk bot added the hotspot hotspot-dev@openjdk.org label Dec 20, 2022

fisk suggested changes Dec 23, 2022

View reviewed changes

Use more suitible nomenclature: raw

e0d2eea

fisk approved these changes Jan 2, 2023

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 2, 2023

mgronlun suggested changes Jan 3, 2023

View reviewed changes

Add comment and cleanup assert

b82e899

stefank suggestion

9d9637a

mgronlun approved these changes Jan 10, 2023

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Jan 12, 2023

openjdk bot closed this Jan 12, 2023

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 12, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly #11741

8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly #11741

xmas92 commented Dec 20, 2022 •

edited by openjdk bot

Loading

bridgekeeper bot commented Dec 20, 2022

openjdk bot commented Dec 20, 2022

mlbridge bot commented Dec 20, 2022 •

edited

Loading

fisk left a comment

xmas92 commented Jan 2, 2023

fisk left a comment

openjdk bot commented Jan 2, 2023 •

edited

Loading

mgronlun commented Jan 3, 2023

mgronlun Jan 3, 2023

xmas92 Jan 3, 2023

mgronlun Jan 3, 2023

xmas92 Jan 3, 2023

fisk Jan 3, 2023

mgronlun Jan 3, 2023

xmas92 Jan 3, 2023

mgronlun Jan 3, 2023

xmas92 Jan 3, 2023

fisk Jan 3, 2023

mgronlun Jan 3, 2023 •

edited

Loading

mgronlun Jan 4, 2023 •

edited

Loading

xmas92 Jan 9, 2023

mgronlun Jan 10, 2023 •

edited

Loading

mgronlun Jan 3, 2023

xmas92 Jan 3, 2023

stefank Jan 9, 2023 •

edited

Loading

mgronlun Jan 3, 2023

xmas92 Jan 3, 2023

xmas92 commented Jan 3, 2023

mgronlun commented Jan 3, 2023

stefank commented Jan 9, 2023 •

edited

Loading

xmas92 commented Jan 12, 2023

openjdk bot commented Jan 12, 2023

openjdk bot commented Jan 12, 2023

8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly #11741

8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly #11741

Conversation

xmas92 commented Dec 20, 2022 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Dec 20, 2022

openjdk bot commented Dec 20, 2022

mlbridge bot commented Dec 20, 2022 • edited Loading

Webrevs

fisk left a comment

Choose a reason for hiding this comment

xmas92 commented Jan 2, 2023

fisk left a comment

Choose a reason for hiding this comment

openjdk bot commented Jan 2, 2023 • edited Loading

mgronlun commented Jan 3, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mgronlun Jan 3, 2023 • edited Loading

Choose a reason for hiding this comment

mgronlun Jan 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mgronlun Jan 10, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefank Jan 9, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xmas92 commented Jan 3, 2023

mgronlun commented Jan 3, 2023

stefank commented Jan 9, 2023 • edited Loading

xmas92 commented Jan 12, 2023

openjdk bot commented Jan 12, 2023

openjdk bot commented Jan 12, 2023

xmas92 commented Dec 20, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Dec 20, 2022 •

edited

Loading

openjdk bot commented Jan 2, 2023 •

edited

Loading

mgronlun Jan 3, 2023 •

edited

Loading

mgronlun Jan 4, 2023 •

edited

Loading

mgronlun Jan 10, 2023 •

edited

Loading

stefank Jan 9, 2023 •

edited

Loading

stefank commented Jan 9, 2023 •

edited

Loading