SapMachine 21 #2165: G1 should initiate the next concurrent cycle even before finishing a mixed phase if there are excessive hum. allocations by reinrich · Pull Request #2166 · SAP/SapMachine

reinrich · 2026-02-02T21:56:18Z

This pr introduces a new experimental option G1HumAllocPercentUntilConcurrent that controls the G1 enhancement described below. With its default value 0 the enhancement is disabled.

A value >0 is interpreted as threshold for humongous allocations given as percentage of the maximum heap size. The threshold limits humongous allocations between mixed evacuation pauses. If reached the current mixed phase is aborted in favor of a new concurrent marking cycle.

Without this enhancement G1 would not initiate concurrent marking in a mixed phase. The problem with this behavior is that the heap can fill up with humongous allocations while G1 waits for the next mixed evacuation pause that will be scheduled only when eden is full. If the heap is full of humongous objects before then a full gc is necessary.

Testing

The reproducer from

8355972: G1: Exclusive humongous allocations trigger unnecessary Full GC

doesn't show full gcs if the enhancement is enabled with -XX:+UnlockExperimentalVMOptions -XX:G1HumAllocPercentUntilConcurrent=30

Full command:

java -Xmx1g -Xlog:gc* -XX:+UnlockExperimentalVMOptions -XX:G1HumAllocPercentUntilConcurrent=30 HumongousGc.java

The change includes a regression test similar to the reproducer.

A patch with G1HumAllocPercentUntilConcurrent=10 is part of our nightly testing since January 30.

fixes #2165

SapMachine · 2026-02-02T22:11:31Z

Hello @reinrich, this pull request fulfills all formal requirements.

RealCLanger

Only a formal review, not a technical one. For that, @schmelter-sap or @TheRealMDoerr, please have a look. Thx.

test/hotspot/jtreg/gc/g1/TestHumongousAllocMixedPhase.java

src/hotspot/share/gc/g1/g1_globals.hpp

reinrich · 2026-02-05T10:18:16Z

Thanks Christoph. I've pushed the requested changes.

SapMachine · 2026-02-05T10:23:22Z

Hello @reinrich, this pull request fulfills all formal requirements.

TheRealMDoerr · 2026-02-05T11:00:43Z

src/hotspot/share/gc/g1/g1_globals.hpp

          "more than that number of cards to be used.")                     \
                                                                            \
+  /* SapMachine 2026-01-20 */                                               \
+  product(uintx, G1HumAllocPercentUntilConcurrent, 0, EXPERIMENTAL,         \


I think this name is only understandable for G1 nerds ;-)
Would be great if the name could indicate that we start a new concurrent full GC after the threshold has been reached. Maybe G1HumPercentConcFullGCThreshold?

I would wager that anyone who does not know the Parameter has to read the doc anyways. So stuffing in every related keyword doesn't really help.

Thus I would suggest something more readable like G1HumongousAllocThreshold.

What about G1MixedGCHumongousAllocThreshold? That name is similar to other options above.

The Mixed GC is cancelled and a (concurrent) Full GC started, right?
G1HumongousAllocFullGCThreshold would be more comprehensive for me. Can this only happen if a Mixed GC is running or why would you want to have MixedGC in the name?

The mixed gc phase (sequence of mixed evacuation pauses) is ended prematurely and a new cycle is initiated. Please have a look at G1MixedGCCountTarget which is related. It's that phase of mixed gcs where G1 wants to make use of the liveness info computed by the marking to evacuate old regions with a lot of unreachable objects. G1 won't start new marking before it is done with the mixed gcs. I thought that G1MixedGCHumongousAllocThreshold matches the existing option and is also descriptive.

Not the name I'd prefer from a Java developer's perspective, but ok. It's just a name of an experimental option and users can read the documentation which is good IMHO.

test/hotspot/jtreg/gc/g1/TestHumongousAllocMixedPhase.java

schmelter-sap

Some more cosmetic remarks. Looks good otherwise.

schmelter-sap · 2026-02-05T12:07:42Z

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

 }

+// SapMachine 2026-01-20: force G1 marking in mixed phase in case of excessive hum. allocations
+bool G1Policy::force_concurrent_ending_mixed_phase(bool hum_alloc) {


The method name makes it look like it does ending the phase instead of just deciding if it should be stopped.

schmelter-sap · 2026-02-05T12:14:00Z

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

-               (cause == GCCause::_wb_breakpoint)) {
+               (cause == GCCause::_wb_breakpoint) ||
+               // SapMachine 2026-01-20: force G1 marking in mixed phase in case of excessive hum. allocations
+               (force_concurrent_ending_mixed_phase(cause == GCCause::_g1_humongous_allocation))) {


It seems the hum_alloc boolean argument in the call to force_concurrent_ending_mixed_phase is only needed for this code.
You could use ?: here and remove the argument form the call, since hum_alloc being false just means the method returns false.

In need_to_start_conc_mark() I wanted to make the call only if called by attempt_allocation_humongous() in order to change the behavior as little as possible. I've changed the callers to make the call only if a hum. alloc. is going on. Is that ok?

schmelter-sap · 2026-02-05T12:19:43Z

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

-      log_debug(gc, ergo)("Initiate concurrent cycle (%s requested concurrent cycle)",
-                          (cause == GCCause::_wb_breakpoint) ? "run_to breakpoint" : "user");
+      // SapMachine 2026-01-20: force G1 marking in mixed phase in case of excessive hum. allocations
+      log_debug(gc, ergo)("Initiate concurrent cycle (%s)", GCCause::to_string(cause));


Wouldn't that change the log output for all kinds of GC causes?

But it's incorrect anyway. The causes related to the code cache are logged as "user requested". I can revert my change and print s.th. different for cause == GCCause::_g1_humongous_allocation. Shall I?

Can this disturb anyone who is parsing the logs? Otherwise, the change looks fine to me.

Could be. I've reverted my change but kept the new output for the new case _g1_humongous_allocation.

reinrich · 2026-02-05T16:17:32Z

Thanks for the reviews! Please have a look at the commits where I addressed them.

SapMachine · 2026-02-05T16:18:21Z

Hello @reinrich, this pull request fulfills all formal requirements.

SapMachine · 2026-02-05T21:28:26Z

Hello @reinrich, this pull request fulfills all formal requirements.

TheRealMDoerr

I think this is a helpful feature. The implementation LGTM. I've checked that the test fails without the fix and passes with it.

reinrich · 2026-02-06T15:30:14Z

Thanks Martin. As mentioned in our daily I've done some further testing with another synthetic gc test that's hopefully a little bit more realistic than the reproducer from 8355972. The test fills the heap with short- and medium-lived and also with permanent objects and then keeps allocating - also humogous objects. I've adapted the test to pause allocations about every 10s except for humongous objects. This triggers stw full gcs. With the enhancement these can be avoided mostly.

RealCLanger · 2026-02-06T15:37:01Z

Please squash when merging. :)

v1

ba16b0a

reinrich requested review from TheRealMDoerr and schmelter-sap February 5, 2026 09:42

RealCLanger requested changes Feb 5, 2026

View reviewed changes

Feedback Christoph

59c2a4e

TheRealMDoerr reviewed Feb 5, 2026

View reviewed changes

test/hotspot/jtreg/gc/g1/TestHumongousAllocMixedPhase.java Outdated Show resolved Hide resolved

schmelter-sap approved these changes Feb 5, 2026

View reviewed changes

reinrich added 4 commits February 5, 2026 16:54

Rename vm option

9e07eb0

Rename force_concurrent_ending_mixed_phase

ac55356

Remove parameter

1cf0927

Use less whitespace in test

b9aa2c3

Preserve log output

e8ad7f4

TheRealMDoerr approved these changes Feb 6, 2026

View reviewed changes

RealCLanger approved these changes Feb 6, 2026

View reviewed changes

Conversation

reinrich commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SapMachine commented Feb 2, 2026

Uh oh!

RealCLanger left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

reinrich commented Feb 5, 2026

Uh oh!

SapMachine commented Feb 5, 2026

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!

Uh oh!

schmelter-sap left a comment

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!

reinrich commented Feb 5, 2026

Uh oh!

SapMachine commented Feb 5, 2026

Uh oh!

SapMachine commented Feb 5, 2026

Uh oh!

TheRealMDoerr left a comment

Choose a reason for hiding this comment

Uh oh!

reinrich commented Feb 6, 2026

Uh oh!

RealCLanger commented Feb 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

reinrich commented Feb 2, 2026 •

edited

Loading