RFR: 8364628: Serial: Refactor SerialHeap::mem_allocate_work [v2]
Albert Mingkun Yang
ayang at openjdk.org
Thu Aug 14 12:18:11 UTC 2025
On Thu, 14 Aug 2025 09:14:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>>
>> - Merge branch 'master' into sgc-mem-allocate
>> - sgc-mem-allocate
>
> src/hotspot/share/gc/serial/serialHeap.cpp line 312:
>
>> 310: if (!is_tlab) {
>> 311: // If it's too large for young-gen or heap is too full.
>> 312: if (size > heap_word_size(_young_gen->capacity_before_gc()) || _is_heap_almost_full) {
>
> I'm not sure inlining (and removing now unused) helper `should_try_older_generation_allocation`
> is an improvement.
The decision whether a particular allocation, after that fails with young-gen, should use old-gen or not is largely caller-specific. There are three places where we perform old-gen-allocation after failed young-gen-allocation, one in `mem_allocate_work` and two in `satisfy_failed_allocation`. In the first case, we wanna limit old-gen-allocation to large objs only, because it's desirable to have regular young-gc that can keep the footprint low.
Having a dedicate API named `should_try_older_generation_allocation` can give the wrong impression that this method provides the global policy for old-gen-allocation.
Therefore, I think it's clearer to inline it to its sole caller. (There are other cleanup PRs in the pipeline to simplify the logic of `DefNewGeneration::should_allocate` and `TenuredGeneration::should_allocate` to further streamline the flow of this method.)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26619#discussion_r2276463080
More information about the hotspot-gc-dev
mailing list