8357218: G1: Remove loop in G1CollectedHeap::try_collect_fullgc #25296

albertnetymk · 2025-05-19T06:49:57Z

Simple removing unnecessary loop in "caller" of VM_G1CollectFull, because an explicit full-gc always run-to-completion.

Test: tier1-3

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-8357218: G1: Remove loop in G1CollectedHeap::try_collect_fullgc (Enhancement - P4)

Reviewers

Kim Barrett (@kimbarrett - Reviewer)
Thomas Schatzl (@tschatzl - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25296

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-05-19T06:50:35Z

👋 Welcome back ayang! 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 · 2025-05-19T06:51:05Z

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

8357218: G1: Remove loop in G1CollectedHeap::try_collect_fullgc

Reviewed-by: kbarrett, 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 27 new commits pushed to the master branch:

e961b13: 8356165: System.in in jshell replace supplementary characters with ??
f8d7f66: 8356998: Convert -Xlog:cds to -Xlog:aot (step 2)
7077535: 8356595: Convert -Xlog:cds to -Xlog:aot (step1)
... and 24 more: https://git.openjdk.org/jdk/compare/969708bd8f0de49f641eab3881cb15712aa34f1e...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 · 2025-05-19T06:51:58Z

@albertnetymk 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.

mlbridge · 2025-05-19T06:55:30Z

Webrevs

kimbarrett · 2025-05-19T08:12:26Z

src/hotspot/share/gc/g1/g1CollectedHeap.cpp

-
-    // Request is trivially finished.
-    if (!GCCause::is_explicit_full_gc(cause) || op.gc_succeeded()) {
-      return op.gc_succeeded();


Complete removal of this part isn't correct. The premise of this change, that "full-gc always
run-to-completion" is not correct. A _g1_periodic_collection may be cancelled:

jdk/src/hotspot/share/gc/g1/g1VMOperations.cpp

Lines 39 to 48 in 50a7c61

bool VM_G1CollectFull::skip_operation() const {

// There is a race between the periodic collection task's checks for

// wanting a collection and processing its request. A collection in that

// gap should cancel the request.

if ((_gc_cause == GCCause::_g1_periodic_collection) &&

(G1CollectedHeap::heap()->total_collections() != _gc_count_before)) {

return true;

}

return VM_GC_Operation::skip_operation();

}

Such a collection is not an explicit full-gc, so that part of the test may be true, when this function
returns false because the gc did not succeed.

Updated the description. The overall result of !GCCause::is_explicit_full_gc(cause) || op.gc_succeeded() is always true.

(Somehow comments seem to have disappeared, probably my fault. anyway:)

This method returns false if the VM op has not been executed (skipped). The new code always returns true, which is wrong afaict.

tschatzl · 2025-05-19T08:46:48Z

src/hotspot/share/gc/g1/g1CollectedHeap.cpp

@@ -1864,24 +1864,12 @@ bool G1CollectedHeap::try_collect_fullgc(GCCause::Cause cause,
                                         const G1GCCounters& counters_before) {


There does not seem to be a reason to keep this helper method. It's the same complexity as the attempt to do a young collection in try_collect() now.

Or move the attempt to do a young collection to a helper method for consistency.

Fwiw, there is G1CollectedHeap::do_collection_pause()that might fit exactly already.

This reverts commit 666cc5a.

kimbarrett · 2025-05-19T14:33:12Z

src/hotspot/share/gc/g1/g1CollectedHeap.cpp

+                        counters_before.total_full_collections(),
+                        cause);
+    VMThread::execute(&op);
+    return op.prologue_succeeded();


They might now be the same value, but gc_succeeded() seems like a better semantic fit here.
Looking around a little, it's not obvious why prologue_succeeded() is ever the right name for a
client-accessible test for what seems like gc-completion. But that's a separate issue.

How about introducing a local var to better reflect the semantics?

// GCs always run-to-completion once prologue succeeds. bool is_gc_succeeded = op.prologue_succeeded(); return is_gc_succeeded;

This way we don't need to maintain a "redundant" field in VM_G1CollectFull.

(Thomas also asked whether the same field in VM_G1CollectForAllocation is actually needed -- seems that _gc_succeeded == prologue_succeeded() holds as well, so we can potential remove that one as well.)

If you dislike the suggestion, I will add back the removed field.

The field does not need to be re-added in the full gc VM op, just add an accessor gc_succeeded() that returns the internal prologue_succeeded().

I will file a bug for removing the _gc_succeeded field in VM_G1CollectForAllocation, because it is always true if doit ran.

I think the question that clients care about is whether the gc succeeded.
Whether the prologue succeeded or not might be used as part of the
implementation of that. That is, I think gc_succeeded ought to be part of the
public API for GC operations, and prologue_succeeded shouldn't be, with some
gc_succeeded operations being implemented as just a call to
prologue_succeeded.

That probably shouldn't be part of this change though. Instead, I'd prefer
this change maintain the status quo in this area. Or do what @tschatzl
suggested, which I saw as I was about to post this.

Added back the API.

I think the question that clients care about is whether the gc succeeded.
Whether the prologue succeeded or not might be used as part of the
implementation of that. That is, I think gc_succeeded ought to be part of the
public API for GC operations, and prologue_succeeded shouldn't be, with some
gc_succeeded operations being implemented as just a call to
prologue_succeeded.

Agree. Filed JDK-8357307.

kimbarrett · 2025-05-20T07:09:25Z

src/hotspot/share/gc/g1/g1CollectedHeap.cpp

+                        counters_before.total_full_collections(),
+                        cause);
+    VMThread::execute(&op);
+    return op.prologue_succeeded();


I think the question that clients care about is whether the gc succeeded.
Whether the prologue succeeded or not might be used as part of the
implementation of that. That is, I think gc_succeeded ought to be part of the
public API for GC operations, and prologue_succeeded shouldn't be, with some
gc_succeeded operations being implemented as just a call to
prologue_succeeded.

That probably shouldn't be part of this change though. Instead, I'd prefer
this change maintain the status quo in this area. Or do what @tschatzl
suggested, which I saw as I was about to post this.

kimbarrett

Looks good.

albertnetymk · 2025-05-20T13:14:49Z

Thanks for review.

/integrate

openjdk · 2025-05-20T13:15:50Z

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

1a97eb4: 8355515: Clarify the purpose of forcePass() and forceFail() methods
ab985a7: 8341544: Restore fence() in Mutex
0db5511: 8354969: Add strdup function for ResourceArea
... and 28 more: https://git.openjdk.org/jdk/compare/969708bd8f0de49f641eab3881cb15712aa34f1e...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-05-20T13:16:02Z

@albertnetymk Pushed as commit e6750a5.

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

g1-remove-full-gc-loop

233a5d1

openjdk bot changed the title ~~8357218~~ 8357218: G1: Remove loop in G1CollectedHeap::try_collect_fullgc May 19, 2025

openjdk bot added the rfr Pull request is ready for review label May 19, 2025

openjdk bot added the hotspot-gc [email protected] label May 19, 2025

kimbarrett suggested changes May 19, 2025

View reviewed changes

tschatzl reviewed May 19, 2025

View reviewed changes

albertnetymk added 4 commits May 19, 2025 15:50

review

722aac3

review

666cc5a

Revert "review"

22c5225

This reverts commit 666cc5a.

review

93c6e99

kimbarrett suggested changes May 19, 2025

View reviewed changes

kimbarrett suggested changes May 20, 2025

View reviewed changes

review

f5768f8

tschatzl approved these changes May 20, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 20, 2025

kimbarrett approved these changes May 20, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label May 20, 2025

openjdk bot closed this May 20, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 20, 2025

albertnetymk deleted the g1-remove-full-gc-loop branch May 20, 2025 13:18

	bool VM_G1CollectFull::skip_operation() const {
	// There is a race between the periodic collection task's checks for
	// wanting a collection and processing its request. A collection in that
	// gap should cancel the request.
	if ((_gc_cause == GCCause::_g1_periodic_collection) &&
	(G1CollectedHeap::heap()->total_collections() != _gc_count_before)) {
	return true;
	}
	return VM_GC_Operation::skip_operation();
	}

		@@ -1864,24 +1864,12 @@ bool G1CollectedHeap::try_collect_fullgc(GCCause::Cause cause,
		const G1GCCounters& counters_before) {

8357218: G1: Remove loop in G1CollectedHeap::try_collect_fullgc #25296

8357218: G1: Remove loop in G1CollectedHeap::try_collect_fullgc #25296

Uh oh!

Conversation

albertnetymk commented May 19, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented May 19, 2025

Uh oh!

openjdk bot commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented May 19, 2025

Uh oh!

mlbridge bot commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kimbarrett left a comment

Choose a reason for hiding this comment

Uh oh!

albertnetymk commented May 20, 2025

Uh oh!

openjdk bot commented May 20, 2025

Uh oh!

openjdk bot commented May 20, 2025

Uh oh!

Uh oh!

albertnetymk commented May 19, 2025 •

edited by openjdk bot

Loading

openjdk bot commented May 19, 2025 •

edited

Loading

mlbridge bot commented May 19, 2025 •

edited

Loading