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

8314935: Shenandoah: Unable to throw OOME on back-to-back Full GCs #15500

Closed

Conversation

earthling-amzn
Copy link
Contributor

@earthling-amzn earthling-amzn commented Aug 30, 2023

Retry allocations until at least one full gc is complete, do not spin unnecessarily when gc is not making progress.


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-8314935: Shenandoah: Unable to throw OOME on back-to-back Full GCs (Bug - P4)

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15500

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

Using diff file

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

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Aug 30, 2023

👋 Welcome back wkemper! 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 openjdk bot changed the title 8314935: Shenandoah: Unable to throw OOME on back-to-back Full GCs 8314935: Shenandoah: Unable to throw OOME on back-to-back Full GCs Aug 30, 2023
@openjdk openjdk bot added the rfr Pull request is ready for review label Aug 30, 2023
@openjdk
Copy link

openjdk bot commented Aug 30, 2023

@earthling-amzn 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 Aug 30, 2023
@mlbridge
Copy link

mlbridge bot commented Aug 30, 2023

Webrevs

Copy link
Contributor

@kdnilsen kdnilsen left a comment

Choose a reason for hiding this comment

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

Thanks. Looks good to me.

Copy link
Member

@ysramakrishna ysramakrishna left a comment

Choose a reason for hiding this comment

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

A couple of comments about harmonizing the code in GenShen tip with that here, but otherwise looks good.

@@ -40,7 +40,8 @@ class ShenandoahCollectorPolicy : public CHeapObj<mtGC> {
private:
size_t _success_concurrent_gcs;
size_t _success_degenerated_gcs;
size_t _success_full_gcs;
// Written by control thread, read by mutators
volatile size_t _success_full_gcs;
size_t _alloc_failure_degenerated;
size_t _alloc_failure_degenerated_upgrade_to_full;
Copy link
Member

Choose a reason for hiding this comment

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

In GenShen tip, _alloc_failure_degenerated_upgrade_to_full is also declared volatile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

_alloc_failure_degenerated_upgrade_to_full is only changed on a safepoint, so it shouldn't need any additional synchronization.

Copy link
Member

Choose a reason for hiding this comment

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

OK, as long as this resolves in genshen tip.

@@ -82,6 +83,10 @@ class ShenandoahCollectorPolicy : public CHeapObj<mtGC> {
size_t cycle_counter() const;

void print_gc_stats(outputStream* out) const;

size_t full_gc_count() const {
Copy link
Member

Choose a reason for hiding this comment

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

Is it worthwhile to harmonize this with tip and rename to get_fullgc_count() ?
Unless the idea is to change genshen tip to use full_gc_count() like here when you pull these changes down.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I went with the style convention established by cycle_counter. I don't feel strongly about this. If you prefer get_full_gc_count, I can change that here (otherwise, I'll change genshen to use full_gc_count).

Copy link
Member

Choose a reason for hiding this comment

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

full_gc_count is fine; so long as these eventually get resolved in genshen tip.

@openjdk
Copy link

openjdk bot commented Sep 2, 2023

@earthling-amzn 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:

8314935: Shenandoah: Unable to throw OOME on back-to-back Full GCs

Reviewed-by: kdnilsen, ysr

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

  • 86a18f5: 8314604: j.text.DecimalFormat behavior regarding patterns is not clear
  • bd47781: 8315554: C1: Replace "cmp reg, 0" with "test reg, reg" on x86
  • 25e85db: 8307468: CDS Lambda Proxy classes are regenerated in dynamic dump
  • 024133b: 8311964: Some jtreg tests failing on x86 with error 'unrecognized VM options' (C2 flags)
  • 62a953f: 8315689: G1: Remove unused init_hash_seed
  • cfc1489: 8315579: SPARC64 builds are broken after JDK-8304913
  • f6c203e: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API
  • a01b3fb: 8288660: JavaDoc should be more helpful if it doesn't recognize a tag
  • ba1a463: 8315377: C2: assert(u->find_out_with(Op_AddP) == nullptr) failed: more than 2 chained AddP nodes?
  • a258fc4: 8315648: Add test for JDK-8309979 changes
  • ... and 66 more: https://git.openjdk.org/jdk/compare/df5e6e5d482e70b33612639b3c1c04eaa1ed361e...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@ysramakrishna) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Sep 2, 2023
result = allocate_memory_under_lock(req, in_new_region);
}

while (result == nullptr && tries <= ShenandoahFullGCThreshold) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just want to point out, the description of ShenandoahFullGCThreshold does not cover this use case (also, the original code here was not concerned with full GCs):

      "How many back-to-back Degenerated GCs should happen before going to a Full GC."

@earthling-amzn
Copy link
Contributor Author

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Sep 6, 2023
@openjdk
Copy link

openjdk bot commented Sep 6, 2023

@earthling-amzn
Your change (at version f397fc6) is now ready to be sponsored by a Committer.

@ysramakrishna
Copy link
Member

Reviewed!

/sponsor

@openjdk
Copy link

openjdk bot commented Sep 7, 2023

Going to push as commit 716201c.
Since your change was applied there have been 97 commits pushed to the master branch:

  • 4c6d7fc: 8315795: runtime/Safepoint/TestAbortVMOnSafepointTimeout.java fails after JDK-8305507
  • 7e7ab6e: 8315877: ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-aarch64
  • 0c865a7: 8315637: JDK-8314249 broke libgraal
  • 683672c: 8292692: Move MethodCounters inline functions out of method.hpp
  • 9bf3dee: 8314831: NMT tests ignore vm flags
  • b74805d: 8315863: [GHA] Update checkout action to use v4
  • 1cae0f5: 8315220: Event NativeLibraryLoad breaks invariant by taking a stacktrace when thread is in state _thread_in_native
  • 8f7e29b: 8313422: test/langtools/tools/javac 144 test classes uses com.sun.tools.classfile library
  • 8557205: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint
  • 2fd870a: 8315444: Convert test/jdk/tools to Classfile API
  • ... and 87 more: https://git.openjdk.org/jdk/compare/df5e6e5d482e70b33612639b3c1c04eaa1ed361e...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Sep 7, 2023
@openjdk openjdk bot closed this Sep 7, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Sep 7, 2023
@openjdk
Copy link

openjdk bot commented Sep 7, 2023

@ysramakrishna @earthling-amzn Pushed as commit 716201c.

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

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 integrated Pull request has been integrated shenandoah shenandoah-dev@openjdk.org
3 participants