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