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

8305896: Alternative full GC forwarding #13582

Draft
wants to merge 127 commits into
base: master
Choose a base branch
from

Conversation

rkennke
Copy link
Contributor

@rkennke rkennke commented Apr 21, 2023

Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers (JDK-8294992) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.

I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.

It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.

We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.

With this, forwarding information would be encoded like this:

  • Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
  • Bit 2: Used for 'fallback'-forwarding (see below)
  • Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
  • Bits 4..31 The number of heap words from the target base address

This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.

All the table accesses can be done unsynchronized because:

  • Serial GC is single-threaded anyway
  • In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
  • G1 serial compaction is single-threaded

The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, JDK-8305898 would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).

The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).

I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.

Testing:

  • hotspot_gc -UseAltGCForwarding
  • hotspot_gc +UseAltGCForwarding
  • tier1 -UseAltGCForwarding
  • tier1 +UseAltGCForwarding
  • tier2 -UseAltGCForwarding
  • tier2 +UseAltGCForwarding

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-8305896: Alternative full GC forwarding (Enhancement - P4)

Reviewers

Contributors

  • Aleksey Shipilev <shade@openjdk.org>
  • Thomas Schatzl <tschatzl@openjdk.org>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13582

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

Using diff file

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

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Apr 21, 2023

👋 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 Apr 21, 2023

@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 JDK-8305896
git fetch https://git.openjdk.org/jdk.git 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 Apr 21, 2023
@openjdk
Copy link

openjdk bot commented Apr 21, 2023

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

  • hotspot-gc
  • 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-gc hotspot-gc-dev@openjdk.org shenandoah shenandoah-dev@openjdk.org labels Apr 21, 2023
@openjdk openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Apr 21, 2023
@rkennke rkennke marked this pull request as ready for review April 27, 2023 12:19
@openjdk openjdk bot added the rfr Pull request is ready for review label Apr 27, 2023
@mlbridge
Copy link

mlbridge bot commented Apr 27, 2023

Webrevs

@openjdk openjdk bot reopened this Sep 28, 2023
@openjdk
Copy link

openjdk bot commented Sep 28, 2023

@rkennke This pull request is now open

@bridgekeeper
Copy link

bridgekeeper bot commented Oct 27, 2023

@rkennke This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@openjdk openjdk bot added merge-conflict Pull request has merge conflict with target branch and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 7, 2023
@openjdk openjdk bot added ready Pull request is ready to be integrated rfr Pull request is ready for review and removed merge-conflict Pull request has merge conflict with target branch labels Dec 11, 2023
@bridgekeeper
Copy link

bridgekeeper bot commented Jan 8, 2024

@rkennke This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

@bridgekeeper bridgekeeper bot closed this Jan 8, 2024
@rkennke
Copy link
Contributor Author

rkennke commented Jan 19, 2024

/open

@openjdk openjdk bot reopened this Jan 19, 2024
@openjdk
Copy link

openjdk bot commented Jan 19, 2024

@rkennke This pull request is now open

@rkennke rkennke marked this pull request as draft January 19, 2024 13:05
@openjdk openjdk bot added merge-conflict Pull request has merge conflict with target branch and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 19, 2024
@openjdk openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Feb 19, 2024
@bridgekeeper
Copy link

bridgekeeper bot commented Mar 15, 2024

@rkennke This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@rkennke
Copy link
Contributor Author

rkennke commented Mar 15, 2024

Not yet

@openjdk openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-gc hotspot-gc-dev@openjdk.org merge-conflict Pull request has merge conflict with target branch shenandoah shenandoah-dev@openjdk.org
8 participants