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

[Albert Mingkun Yang]

On Mon, 27 Jan 2025 14:58:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Parallel has the same problem right?

Parallel also has the problem of fragmentation, where a single large obj in the beginning of eden can cause a large hole in the end of old-gen, because objs can't cross generation boundary.

Parallel doesn't have the problem of running >1000 GCs before exit, captured by the attached bm, because Parallel implements `UseGCOverheadLimit`. (For this particular bm with the selected heap-size, this problematic scenario doesn't occur for Parallel. One can even dodge this problematic scenario in Serial by using a diff heap-size, e.g. 200m instead of 100m.)

This PR mitigates the fragmentation problem to some extent, and it solves the many-gc-before-exit problem.

> When we have a promotion failure and the following full fails to evacuate eden, maybe we should just bail rather than allocating in old.

That's another way to address the many-gc-before-exit problem. However, end users may get surprised with this "premature" OOM when heap still has a sizable margin till 100%. (Ofc, this is pure speculation.)

I believe the newly introduced field, `_is_heap_almost_full`, can also be used to impl what you proposed. IOW, this field enables us to detect and react to "emergency" state. (Just to make it explicit, this allocating-in-old-gen when heap is tight has been in Serial for long, and was mistakenly removed in JDK-8333786.) As for which approach is "better", we probably need to assess it after cleaning up some other related code/logic, e.g. heap/generation-resizing.

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

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