Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8275527: Refactor forward pointer access #5955

Closed
wants to merge 14 commits into from

Conversation

rkennke
Copy link
Contributor

@rkennke rkennke commented Oct 14, 2021

Accessing the forward pointer is currently a little inconsistent. Some code paths call oopDesc::forwardee() / oopDesc::is_forwarded(), some code paths call forwardee() and check it for ==/!= NULL, some code paths even call markWord::decode_pointer() and markWord::is_marked() instead.

This change attempts to make the situation more consistent. For simple cases it preserves oopDesc::forwardee() / is_forwarded(), some cases need to use the markWord for consistency in concurrent GC, they now use markWord::forwardee() and markWord::is_forwarded(). Also, checking whether or not an object is forwarded is now consistently done using is_forwarded() and not by checking forwardee ==/!= NULL. This also resolves the mess in G1 full GC that changes not-forwarded objects to have a NULL (fake-) pointer. This is not necessary, because we can just as well use the lock bits to determine whether or not the object is forwarded.

Testing:

  • tier
  • tier2
  • hotspot_gc

Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955
$ git checkout pull/5955

Update a local copy of the PR:
$ git checkout pull/5955
$ git pull https://git.openjdk.java.net/jdk pull/5955/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5955

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5955.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Oct 14, 2021

👋 Welcome back rkennke! 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
Copy link

openjdk bot commented Oct 14, 2021

@rkennke The following labels will be automatically applied to this pull request:

  • hotspot
  • shenandoah

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

@openjdk openjdk bot added hotspot hotspot-dev@openjdk.org shenandoah shenandoah-dev@openjdk.org labels Oct 14, 2021
Copy link
Contributor

@tschatzl tschatzl left a comment

I like it. Lgtm.

@openjdk
Copy link

openjdk bot commented Oct 19, 2021

@rkennke this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout optimize-fwdptr
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

@openjdk openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Oct 19, 2021
@openjdk openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Oct 19, 2021
@rkennke rkennke changed the title Separate/refactor forward pointer access 8275527: Separate/refactor forward pointer access Oct 19, 2021
@rkennke
Copy link
Contributor Author

rkennke commented Oct 19, 2021

/cc hotspot-gc

@openjdk
Copy link

openjdk bot commented Oct 19, 2021

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

8275527: Refactor forward pointer access

Reviewed-by: tschatzl, stefank

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 1 new commit pushed to the master branch:

  • 0f23c6a: 8276926: Use String.valueOf() when initializing File.separator and File.pathSeparator

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

@openjdk openjdk bot added ready Pull request is ready to be integrated hotspot-gc hotspot-gc-dev@openjdk.org labels Oct 19, 2021
@openjdk
Copy link

openjdk bot commented Oct 19, 2021

@rkennke
The hotspot-gc label was successfully added.

@rkennke rkennke marked this pull request as ready for review Oct 19, 2021
@openjdk openjdk bot added the rfr Pull request is ready for review label Oct 19, 2021
@mlbridge
Copy link

mlbridge bot commented Oct 19, 2021

Webrevs

Copy link
Member

@stefank stefank left a comment

I like how the mark/is_marked/decode_pointer code gets cleaned up. And having an OopForwading class probably makes sense for parts of the code.

I'm less excited about the way the explicitly stack allocated OopForwarding objects make the code less readable. Take these two examples:

   assert(old->is_objArray(), "invariant");
-  assert(old->is_forwarded(), "invariant");
+  assert(OopForwarding(old).is_forwarded(), "invariant");
     oop new_obj = obj->is_forwarded() ? obj->forwardee()
                                        : _young_gen->copy_to_survivor_space(obj);
      OopForwarding fwd(obj);
      oop new_obj = fwd.is_forwarded() ? fwd.forwardee()
                                       : _young_gen->copy_to_survivor_space(obj);

I think both snippets were nicer to read in the earlier code. And there's a lot of those kind of changes in this patch.

Maybe there's a hybrid approach where we could still have oopDesc::is_forwarded, oopDesc::forwardee, etc. but also have OopForwarding objects for those places that really need them? And then minimize the amount of places we use OopForwarding fwd(obj) and OopForwarding(obj)->forwardee() in the code?

@tschatzl
Copy link
Contributor

tschatzl commented Oct 20, 2021

@rkennke : could you close the superfluous CRs for this issue? You filed this one 9 times in total... (probably due to network issues yesterday). Thanks.

@tschatzl
Copy link
Contributor

tschatzl commented Oct 20, 2021

Never mind, already did that. I did not check if any of the duplicates contain more information than the one used for this PR though.

@rkennke
Copy link
Contributor Author

rkennke commented Oct 20, 2021

Never mind, already did that. I did not check if any of the duplicates contain more information than the one used for this PR though.

Oh dear! Thank you! Yes, when I tried to file the issue, bugs.o.j.n was down and/or very slow. Apparently every attempt actually went through, without actually sending back a confirmation.

@albertnetymk
Copy link
Member

albertnetymk commented Oct 20, 2021

sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files).

Overriding the markword to return null for non-forwarded objs is indeed a bit hacky. However, from a caller's perspective, this is the most intuitive one.

Taking G1FullGCCompactTask::G1CompactRegionClosure::apply as an example:

  HeapWord* destination = cast_from_oop<HeapWord*>(obj->forwardee());
  if (destination == NULL) {
    // Object not moving
    return size;
  }
  ...
  Copy::aligned_conjoint_words(obj_addr, destination, size);

destination is either null (obj is not moved) or the new location after moving; rather smooth and straightforward control flow.

I wonder if we can use this pattern without overriding the markdown. Here's a straw man proposal.

oop oopDesc::forwardee() const {
  auto mark_word = mark();
  bool is_forwarded = mark_word.is_marked();
  if (!is_forwarded) {
    return nullptr;
  }
  return cast_to_oop(mark_word.decode_pointer());
}

The intention is to load the markword only once. Additionally, callers can continue using the is_forwarded() / forwardee() pair, or switch to the forwardee() == nullptr pattern on a case-by-case basis if desired.

@rkennke
Copy link
Contributor Author

rkennke commented Oct 20, 2021

I like how the mark/is_marked/decode_pointer code gets cleaned up. And having an OopForwading class probably makes sense for parts of the code.

I'm less excited about the way the explicitly stack allocated OopForwarding objects make the code less readable. Take these two examples:

   assert(old->is_objArray(), "invariant");
-  assert(old->is_forwarded(), "invariant");
+  assert(OopForwarding(old).is_forwarded(), "invariant");
     oop new_obj = obj->is_forwarded() ? obj->forwardee()
                                        : _young_gen->copy_to_survivor_space(obj);
      OopForwarding fwd(obj);
      oop new_obj = fwd.is_forwarded() ? fwd.forwardee()
                                       : _young_gen->copy_to_survivor_space(obj);

I think both snippets were nicer to read in the earlier code. And there's a lot of those kind of changes in this patch.

Maybe there's a hybrid approach where we could still have oopDesc::is_forwarded, oopDesc::forwardee, etc. but also have OopForwarding objects for those places that really need them? And then minimize the amount of places we use OopForwarding fwd(obj) and OopForwarding(obj)->forwardee() in the code?

In the first snippet, there is only one usage of the mark-word, i.e. no problem to simplify that. However, in the 2nd snippet, the point is that we can avoid loading the mark-word twice, and if we want to do that, we need an enclosing scope. The alternative would be to do something like:
markWord mark = obj->mark();
oop fwd = mark->is_forwarded() ? mark->forwardee() : something_else();
... which is pretty much the same as what I proposed, except that the markWord and the logic is encapsulated in OopForwarding.

Notice that in some cases we actually already do that - those are the 'messy' cases where we deliberately load the mark-word once, and drag it through the code that needs it (sometimes not only for performance but also for correctness in the face of concurrency) - and the use is_marked() and decode_pointer() on it.

Given that I have not been able to show performance benefits, I could revert cases like you mentioned to their original form, and consolidate the implementation into markWord, unless we prefer the most efficient solution everywhere. ?

@stefank
Copy link
Member

stefank commented Oct 20, 2021

I don't think we should make the code more complicated by using the micro optimized version unless we can measure the benefits. IMHO, it is harder to read and it makes it more difficult to know if the read-once of was done for correctness purposes or not. I understand that that other reviewers might disagree with my view, and if that's the case, then I'll back off.

Some concrete feedback on the current patch:

I don't like that we store the oop in the OopForwarding. That oop gets snuck into functions via the fwd variable. That makes it less obvious that the functions depend on the old oop. Code like the following becomes more obscure, when you don't immediately see that it operates on the original (old) object:

  const oop forward_ptr = fwd.forward_to_atomic(obj, memory_order_relaxed);
  if (forward_ptr == NULL) {

I wonder if it wouldn't make sense to make forward_to_atomic static, just like the forward_to is static? That way we wouldn't have to store _obj in OopForwarding, and I think the code would be more decoupled and easier to read.

@stefank
Copy link
Member

stefank commented Oct 20, 2021

Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in:
stefank@58732bc

and here it is on-top of your branch:
master...stefank:pr_5955

@rkennke
Copy link
Contributor Author

rkennke commented Oct 20, 2021

Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: stefank@58732bc

and here it is on-top of your branch: master...stefank:pr_5955

Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: stefank@58732bc

and here it is on-top of your branch: master...stefank:pr_5955

Thanks! Yes this is indeed better. I will merge into this PR as soon as I get to it.

Copy link
Member

@stefank stefank left a comment

A few more comments:

static void forward_to(oop obj, oop fwd) {
verify_forwardee(obj, fwd);
markWord m = markWord::encode_pointer_as_mark(fwd);
assert(m.decode_pointer() == fwd, "encoding must be reversable");
obj->set_mark(m);
}

// Like "forward_to", but inserts the forwarding pointer atomically.
// Exactly one thread succeeds in inserting the forwarding pointer, and
// this call returns "NULL" for that thread; any other thread has the
// value of the forwarding pointer returned and does not modify "this".
oop forward_to_atomic(oop p, atomic_memory_order order = memory_order_conservative) const {
verify_forwardee(_obj, p);
markWord compare = mark();
markWord m = markWord::encode_pointer_as_mark(p);
assert(m.decode_pointer() == p, "encoding must be reversable");
markWord old_mark = _obj->cas_set_mark(m, compare, order);
if (old_mark == compare) {
return NULL;
} else {
return cast_to_oop(old_mark.decode_pointer());
}
}
Copy link
Member

@stefank stefank Oct 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The forward_to functions uses functions in oop.inline.hpp. They need to be split out into a oopForwarding.inline.hpp file.

if (object->forwardee() != NULL) {
// Object should not move but mark-word is used so it looks like the
// object is forwarded. Need to clear the mark and it's no problem
// since it will be restored by preserved marks.
object->init_mark();
} else {
Copy link
Member

@stefank stefank Oct 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain why this was removed?

Copy link
Contributor Author

@rkennke rkennke Oct 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The G1 Full GC code decoded the fwdptr without checking if object is actually forwarded (i.e. by checking the lowest two mark word bits), and then compare the result with NULL. In order for this to work, it modifies the mark word of not forwarded objects to prototype mark. This is all quite messy and can be avoided by checking is_forwarded() before actually decoding the fwdptr.

#include "oops/oop.inline.hpp"
#include "oops/oopForwarding.hpp"
Copy link
Member

@stefank stefank Oct 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The patch is inconsistent w.r.t. the include order between oop.inline.hpp and oopForwarding.hpp.

static void verify_forwardee(oop obj, oop forwardee) {
#ifdef ASSERT
#if INCLUDE_CDS_JAVA_HEAP
assert(!Universe::heap()->is_archived_object(forwardee) && !Universe::heap()->is_archived_object(obj),
"forwarding archive object");
#endif
#endif
}
Copy link
Member

@stefank stefank Oct 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should preferable be in a .cpp file, though it seems excessive to introduce one just for this case. Since it is only used by the forward_to functions, maybe add it to the suggested oopForwarding.inline.hpp file?

markWord m = o->mark();
if (!m.is_marked()) {
return copy_unmarked_to_survivor_space<promote_immediately>(o, m);
OopForwarding fwd(o);
if (!fwd.is_forwarded()) {
return copy_unmarked_to_survivor_space<promote_immediately>(o, fwd);
Copy link
Member

@stefank stefank Oct 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this copy_unmarked should be renamed to copy_unforwarded?

@rkennke
Copy link
Contributor Author

rkennke commented Oct 28, 2021

I've removed OopForwarding altogether, and only kept the actual refactorings and cleanups. Can you please re-review?

@rkennke rkennke changed the title 8275527: Separate/refactor forward pointer access 8275527: Refactor forward pointer access Oct 28, 2021
stefank
stefank approved these changes Nov 1, 2021
Copy link
Member

@stefank stefank left a comment

Thanks for doing this change. This looks good to me. I've added a comment below that I think would be nice to get resolved somehow, though I don't need to re-review if you update with any of the suggestions.

inline bool is_forwarded() const { return is_marked(); }
inline oop forwardee() const {
assert(is_forwarded(), "only decode when actually forwarded");
return cast_to_oop(decode_pointer());
}
};
Copy link
Member

@stefank stefank Nov 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This brings the forwarded/forwardee terminology into the markWord. The markWord was previously decoupled from those to concepts. I would personally let those function names stay in oopDesc and not leak down into the markWord. If you do want to keep it here, could you update the comments at the top that describes the bits?

//    [ptr             | 11]  marked             used to mark an object

Copy link
Contributor Author

@rkennke rkennke Nov 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I am not quite sure about this. We have a couple of places where we need to use the markWord direcly, and they read m.is_marked() (when it really means is_forwarded, even though it's the same in the implementation), and then goes on to cast_to_oop(m.decode_pointer()) which reads more ugly than simply m.forwardee() which also comes with an assert and the cast.

I reverted the markWord change and related call-sites now. Maybe this warrants more thinking/discussion.

@rkennke
Copy link
Contributor Author

rkennke commented Nov 18, 2021

/integrate

@openjdk
Copy link

openjdk bot commented Nov 18, 2021

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

  • 36bd4a3: 8277404: Test VMDeprecatedOptions.java failing with Unable to create shared archive file
  • 57eb864: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
  • 8db0c36: 8277414: ProblemList runtime/CommandLine/VMDeprecatedOptions.java on windows-x64
  • 03473b4: 8270874: JFrame paint artifacts when dragged from standard monitor to HiDPI monitor
  • ce0f00f: 8276093: Improve naming in closures to iterate over card sets
  • 5d249c4: 8275071: [macos] A11y cursor gets stuck when combobox is closed
  • 354a34e: 8277336: Improve CollectedHeap::safepoint_workers comments
  • 276bfcd: 8277407: javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile after JDK-8276058
  • d93b238: 8277180: Intrinsify recursive ObjectMonitor locking for C2 x64 and A64
  • 00c388b: 8259643: ZGC can return metaspace OOM prematurely
  • ... and 105 more: https://git.openjdk.java.net/jdk/compare/a0b84453b087ff368a32b93729c5b30fda22ed48...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Nov 18, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Nov 18, 2021
@openjdk
Copy link

openjdk bot commented Nov 18, 2021

@rkennke Pushed as commit 89b125f.

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

@rkennke rkennke deleted the optimize-fwdptr branch Nov 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org hotspot-gc hotspot-gc-dev@openjdk.org integrated Pull request has been integrated shenandoah shenandoah-dev@openjdk.org
4 participants