Integrated: 8370325: G1: Disallow GC for TLAB allocation
Thomas Schatzl
tschatzl at openjdk.org
Thu Oct 23 07:08:21 UTC 2025
On Wed, 22 Oct 2025 07:59:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> 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
This pull request has now been integrated.
Changeset: 027aea9d
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/027aea9d2e0dff29fcd00fa7074ca955066929ec
Stats: 28 lines in 2 files changed: 9 ins; 5 del; 14 mod
8370325: G1: Disallow GC for TLAB allocation
Reviewed-by: iwalulya, ayang
-------------
PR: https://git.openjdk.org/jdk/pull/27932
More information about the hotspot-gc-dev
mailing list