RFR: 8346920: Serial: Support allocation in old generation when heap is almost full [v2]

Albert Mingkun Yang ayang at openjdk.org
Tue Jan 28 16:15:56 UTC 2025


On Tue, 28 Jan 2025 06:32:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Interesting. I said this because I observe the same behaviour (stuck running thousands of full GCs).

I can't reproduce it on my box. (I suspect the bm is not targeted to that problematic scenario, so diff boxes get diff objs layout. Not too surprising.) I'd expected `UseGCOverheadLimit` to kick in, but sth must have messed up...

> Only looked at this in the context of Serial, but this patch could still have this full GC problem...

I believe you are referring to a scenario where each young/full gc makes some progress, but the reclaimed memory is barely/just enough for the following single allocation, sth like `alloc(size) + alloc(size) + gc + alloc(size) + alloc(size) + gc`.

Since each gc reclaims some mem, it's diff from the scenario where the original bm captured. I believe `UseGCOverheadLimit` is meant for such scenario, where each gc is effective, but too much cpu-time is spent on gc in total.

(Serial doesn't support `UseGCOverheadLimit`; Parallel does, but according to your experiment, Parallel's support is incomplete... I will fix the Parallel case firstly as part of [JDK-8338977](https://bugs.openjdk.org/browse/JDK-8338977).)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23270#issuecomment-2619450483


More information about the hotspot-gc-dev mailing list