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

JDK-8307314: Implementation: Generational Shenandoah (Experimental) #14185

Closed
wants to merge 306 commits into from

Conversation

kdnilsen
Copy link

@kdnilsen kdnilsen commented May 26, 2023

OpenJDK Colleagues:

Please review this proposed integration of Generational mode for Shenandoah GC under https://bugs.openjdk.org/browse/JDK-8307314.

Generational mode of Shenandoah is enabled by adding -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational to a command line that already specifies -XX:+UseShenandoahGC. The implementation automatically adjusts the sizes of old generation and young generation to efficiently utilize the entire heap capacity. Generational mode of Shenandoah resembles G1 in the following regards:

  1. Old-generation marking runs concurrently during the time that multiple young generation collections run to completion.
  2. After old-generation marking completes, we perform a sequence of mixed collections. Each mixed collection combines collection of young generation with evacuation of a portion of the old-generation regions identified for collection based on old-generation marking information.
  3. Unlike G1, young-generation collections and evacuations are entirely concurrent, as with single-generation Shenandoah.
  4. As with single-generation Shenandoah, there is no explicit notion of eden and survivor space within the young generation. In practice, regions that were most recently allocated tend to have large amounts of garbage and these regions tend to be collected with very little effort. Young-generation objects that survive garbage collection tend to accumulate in regions that hold survivor objects. These regions tend to have smaller amounts of garbage, and are less likely to be collected. If they survive a sufficient number of young-generation collections, the “survivor” regions are promoted into the old generation.

We expect to refine heuristics as we gain experience with more production workloads. In the future, we plan to remove the “experimental” qualifier from generational mode, at which time we expect that generational mode will become the default mode for Shenandoah.

Testing: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, HyperAlloc, and multiple AWS production workload simulators. We test on Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows x64.


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
  • Change requires CSR request JDK-8307343 to be approved

Issues

  • JDK-8307314: Implementation: Generational Shenandoah (Experimental) (Sub-task - P4)
  • JDK-8307343: Implementation: JEP 404: Generational Shenandoah (Experimental) (CSR)

Reviewers

Contributors

  • Aleksey Shipilev <shade@openjdk.org>
  • Roman Kennke <rkennke@openjdk.org>
  • David Alvarez <alvdavi@openjdk.org>
  • Joshua Cao <jcao@openjdk.org>
  • Martin Doerr <mdoerr@openjdk.org>
  • Zhengyu Gu <zgu@openjdk.org>
  • William Kemper <wkemper@openjdk.org>
  • Bernd Mathiske <bmathiske@openjdk.org>
  • Kelvin Nilsen <kdnilsen@openjdk.org>
  • Y. Srinivas Ramakrishna <ysr@openjdk.org>
  • Wade Hennessey <wadehenn@amazon.com>
  • Celine Wu <cfumiwu@amazon.com>
  • Christian Young <cyyoungm@amazon.com>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14185

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

Using diff file

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

Webrev

Link to Webrev Comment

shipilev and others added 30 commits May 4, 2021 11:27
Reviewed-by: rkennke
Co-authored-by: Bernd Mathiske <bmathiske@openjdk.org>
Reviewed-by: rkennke
Reviewed-by: rkennke
Reviewed-by: rkennke
Reviewed-by: rkennke
Reviewed-by: rkennke
Reviewed-by: rkennke
Reviewed-by: rkennke
Reviewed-by: rkennke
Reviewed-by: zgu, shade
Reviewed-by: shade
Reviewed-by: rkennke
When generational Shenandoah is used, there may be an additional
alignment related heap size adjustment that the test should be cognizant
of. Such alignment might also happen in the non-generational case, but
in this case the specific size used in the test was affected on machines
with larger than usual os page size settings.

The alignment related adjustment would have affected all generational
collectors (except perhaps Gen Z). In the future, we might try and relax
this alignment constraint.alignment.
@kdnilsen
Copy link
Author

kdnilsen commented Jun 7, 2023

Hi Thomas,

Thank you for your followup comments. I am in total agreement that it is a shame the challenges we have faced and the progress we have made is not better documented in the history of JBS tickets. I have been the worst offender. I apologize.

One aspect of this problem is that our work has included a large degree of uncertainty and "research", and it is not always clear to us what needs to be addressed until after we finish and test certain fixes as integrated with a variety of other fixes. We will commit to being more engaged with JBS from this point forward, both for any further work done on the Shenandoah branch, and definitely for work done on tip.

You are correct that the change is to N, the number of times in a row that we perform degenerated GC before we automatically upgrade to Full GC. It is still possible that we will upgrade to Full GC before N is reached, because there are other situations, such as lack of progress by degenerated GC, that will cause us to upgrade to Full even before N is reached.

The comment is still valid as written. During degenerated GC, the mutator threads are all blocked, so the ONLY kind of allocation failure that can occur during degenerated GC is a GC-worker-thread allocation for the purpose of evacuating memory. If we experience an "evacuation failure" during degenerated GC. we will upgrade to Full GC.

@openjdk
Copy link

openjdk bot commented Jun 7, 2023

@kdnilsen 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 merge-generational-shenandoah
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 merge-conflict Pull request has merge conflict with target branch and removed ready Pull request is ready to be integrated labels Jun 7, 2023
@kdnilsen kdnilsen force-pushed the merge-generational-shenandoah branch from 8b2edd9 to 240d413 Compare June 7, 2023 16:42
@openjdk
Copy link

openjdk bot commented Jun 7, 2023

@kdnilsen Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

@openjdk openjdk bot added ready Pull request is ready to be integrated and removed merge-conflict Pull request has merge conflict with target branch labels Jun 7, 2023
@tstuefe
Copy link
Member

tstuefe commented Jun 7, 2023

Hi Thomas,

Thank you for your followup comments. I am in total agreement that it is a shame the challenges we have faced and the progress we have made is not better documented in the history of JBS tickets. I have been the worst offender. I apologize.

Please, no need to apologize. I understand that during early development one needs to move quickly. I just thought that your team's experience with tuning Shenandoah is valuable, and it is regrettable when it is lost.

You are correct that the change is to N, the number of times in a row that we perform degenerated GC before we automatically upgrade to Full GC. It is still possible that we will upgrade to Full GC before N is reached, because there are other situations, such as lack of progress by degenerated GC, that will cause us to upgrade to Full even before N is reached.

The comment is still valid as written. During degenerated GC, the mutator threads are all blocked, so the ONLY kind of allocation failure that can occur during degenerated GC is a GC-worker-thread allocation for the purpose of evacuating memory. If we experience an "evacuation failure" during degenerated GC. we will upgrade to Full GC.

Thank you for the thorough explanation.

@tstuefe
Copy link
Member

tstuefe commented Jun 7, 2023

I won't be able to give reasonable input here in the short time left before RDP1. Nor am I the most qualified to do so.

Just wanted to re-iterate that I see this rushed review with worry. Nothing I have not said already, and of course, it does not diminish the massive effort behind this JEP.

Process-wise, when talking about Lilliput integration we touched on the idea of moving RDP1 down to a sooner date. I still think this makes sense.

@kdnilsen
Copy link
Author

kdnilsen commented Jun 7, 2023

We would like to thank everyone who has taken time to review and provide feedback on our pull request. Given the risks identified during the review process and the lack of time available to perform the thorough review that such a large contribution of code requires, we have decided to close this PR at the current time. We will seek to target JDK 22.

@kdnilsen kdnilsen closed this Jun 7, 2023
@theRealAph
Copy link
Contributor

We would like to thank everyone who has taken time to review and provide feedback on our pull request. Given the risks identified during the review process and the lack of time available to perform the thorough review that such a large contribution of code requires, we have decided to close this PR at the current time. We will seek to target JDK 22.

Thank you for this. It's the right decision. In hindsight, there never was a highly-likely prospect of getting such a substantial and interwoven patch successfully reviewed in such a short time, even with the most skilful and experienced team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build build-dev@openjdk.org hotspot hotspot-dev@openjdk.org ready Pull request is ready to be integrated rfr Pull request is ready for review serviceability serviceability-dev@openjdk.org shenandoah shenandoah-dev@openjdk.org