Skip to content

Conversation

@tschatzl
Copy link
Contributor

@tschatzl tschatzl commented Oct 22, 2025

Hi all,

please review this change to the object allocation path to only allow direct allocation after failing TLAB allocation doing GCs.

Currently, when allocating an object, G1 (or actually any collector) first allocates from TLABs, then allocates from outside TLABs.

When G1 can't find space for a TLAB in the current region, it passes on control to G1CollectedHeap::attempt_allocation[_slow] that first tries to allocate that memory using a new region, or if that fails, do a GC. Potential allocation outside TLABs that would follow TLAB-allocation does the same.

G1's behavior to do a GC during failed TLAB allocation is problematic for the UseGCOverheadLimit functionality (https://bugs.openjdk.org/browse/JDK-8212084): if the GC overhead limit triggers in a TLAB allocation, it returns null for that TLAB allocation.
Control will be passed to outside-tlab allocation as described above. Since the garbage collections for TLAB allocations did free some memory (but because of exceeded gc overhead we returned null for the TLAB allocation), that allocation/collection for this outside-tlab allocation will succeed and return non-null to the mutator, effectively swallowing the information that GC overhead has been exceeded.

I split this out from the UseGCOverheadLimit change because I thought it is somewhat standalone, but I can merge it.

Testing: tier1-5, performance neutral after some tests

Hth,
Thomas


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-8370325: G1: Disallow GC for TLAB allocation (Enhancement - P4)

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27932

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

Using diff file

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

Using Webrev

Link to Webrev Comment

Hi all,

  please review this change to the allocation path to only allow one path doing GCs during that time.

Currently, when allocating an object, G1 (or actually any collector) first allocates from TLABs, then allocates from outside TLABs.

When G1 can't find space for a TLAB in the current region, it passes on control to `G1CollectedHeap::attempt_allocation[_slow]` that first tries to allocate a new region, or do a GC. Allocation from outside TLABs does the same.

G1's behavior to do a GC during failed TLAB allocation is problematic for the `UseGCOverheadLimit` functionality I'm also working on: if the GC overhead limit triggers in a particular operation, returning null for that TLAB allocation. This will will cause another GC right away trying to allocate outside TLAB. Since the garbage collections for TLAB allocations did free some memory (but because of exceeded gc overhead we returned null for the TLAB allocation), that allocation/collection for this outside-tlab allocation will succeed, effectively swallowing the attempt to tell the mutator that GC overhead has been exceeded.

Testing: tier1-5, performance neutral after some tests

Hth,
  Thomas
@bridgekeeper
Copy link

bridgekeeper bot commented Oct 22, 2025

👋 Welcome back tschatzl! 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 Oct 22, 2025

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

8370325: G1: Disallow GC for TLAB allocation

Reviewed-by: iwalulya, ayang

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

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 openjdk bot changed the title 8370325 8370325: G1: Only one source of GC operations during object allocation Oct 22, 2025
@openjdk openjdk bot added the hotspot-gc hotspot-gc-dev@openjdk.org label Oct 22, 2025
@openjdk
Copy link

openjdk bot commented Oct 22, 2025

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

@openjdk openjdk bot added the rfr Pull request is ready for review label Oct 22, 2025
@mlbridge
Copy link

mlbridge bot commented Oct 22, 2025

Webrevs

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Oct 22, 2025
Copy link
Member

@albertnetymk albertnetymk left a comment

Choose a reason for hiding this comment

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

Maybe the title can be revised a bit -- sth like "G1: Disallow GC for TLAB allocation".

@tschatzl tschatzl changed the title 8370325: G1: Only one source of GC operations during object allocation 8370325: G1: Disallow GC for TLAB allocation Oct 22, 2025
@tschatzl
Copy link
Contributor Author

Maybe the title can be revised a bit -- sth like "G1: Disallow GC for TLAB allocation".

Much better, thanks!

@tschatzl
Copy link
Contributor Author

Thanks @albertnetymk @walulyai for your reviews
/integrate

@openjdk
Copy link

openjdk bot commented Oct 23, 2025

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

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Oct 23, 2025
@openjdk openjdk bot closed this Oct 23, 2025
@openjdk openjdk bot removed the ready Pull request is ready to be integrated label Oct 23, 2025
@tschatzl tschatzl deleted the submit/8370325-only-one-cause-for-gc branch October 23, 2025 07:05
@openjdk openjdk bot removed the rfr Pull request is ready for review label Oct 23, 2025
@openjdk
Copy link

openjdk bot commented Oct 23, 2025

@tschatzl Pushed as commit 027aea9.

💡 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

Development

Successfully merging this pull request may close these issues.

3 participants