8385632: ZGC: Incorrect object undo in relocation race for relocation workers

[jsikstro]

Hello,

When a relocation worker races with a mutator and the relocation worker loses, it should attempt to undo its last allocation as a way to potentially save some space.

When the relocation worker loses the race, it passes on the object allocated by the mutator in its call to ZPage::undo_alloc_object, not the object the relocation worker just allocated.

Since relocation workers and mutators have totally separate target pages, we will never end up in a scenario where a mutator allocation can end up on a page that a relocation worker also allocates on. ZPage::undo_alloc_object only undos an allocation if it was the most recent one, by checking if the object's offset into the heap is the same offset as the page's top. This means the undo will never succeed if the object is not on the page also passed to undo_alloc_object. In practice this means that this bug is benign, resulting in one waste relocation worker allocation in the event of a race occurring.

On the mutator side, if the mutator loses the race it calls ZHeap::undo_alloc_object_for_relocation, which gets the correct page for an object via ZHeap::page, so we don't have the same issue there.

The fix is simple, we just make sure we pass the object allocated by the relocation worker in the call to undo_alloc_object.

This might be relevant to backport, so I suggest we add more robustness to the undo-paths in a follow-up RFE, making sure that we're not trying to undo object allocations in a page it doesn't belong to, so we can more easily catch bugs like this in the future.

Testing:

• Running Oracle's tier1-4 ZGC tests

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

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

Issue

• JDK-8385632: ZGC: Incorrect object undo in relocation race for relocation workers (Bug - P5)

Reviewers

• Stefan Karlsson (@stefank - Reviewer)
• Axel Boldt-Christmas (@xmas92 - Reviewer)
• Thomas Schatzl (@tschatzl - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 31322

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jsikstro! 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]

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

8385632: ZGC: Incorrect object undo in relocation race for relocation workers

Reviewed-by: stefank, aboldtch, tschatzl

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 26 new commits pushed to the master branch:

• 2820c78: 8385408: C2: no reachable node should have no use
• 3760d75: 8384104: Obsolete Xmaxjitcodesize
• 9536b7f: 8384964: Add an entry count to the MallocSiteTable
• ... and 23 more: https://git.openjdk.org/jdk/compare/9ed5af9939f9064889c24958b728efad07dcea5f...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.

[openjdk]

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

• hotspot-gc

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.

[openjdk]

The total number of required reviews for this PR has been set to 2 based on the presence of this label: hotspot-gc. This can be overridden with the /reviewers command.

[stefank]

Looks good! Thanks for fixing!

[mlbridge]

Webrevs

• 00: Full (800aa7b3)

[xmas92]

lgtm.

[jsikstro]

Thank you for the reviews everyone!
/integrate

[openjdk]

Going to push as commit 64d6cba.
Since your change was applied there have been 29 commits pushed to the master branch:

• 9acd9f8: 8381965: NullPointerException in TypeAnnotationPositions
• 3f2002d: 8384507: Incorrect vector reassociation for signed saturating addition
• 05a6580: 8385583: RISC-V: Debugger very slow during stepping
• ... and 26 more: https://git.openjdk.org/jdk/compare/9ed5af9939f9064889c24958b728efad07dcea5f...master

Your commit was automatically rebased without conflicts.

[openjdk]

@jsikstro Pushed as commit 64d6cba.

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