RFR: 8355756: G1HeapSizingPolicy::full_collection_resize_amount should consider allocation size [v3]

Albert Mingkun Yang ayang at openjdk.org
Fri May 16 05:39:53 UTC 2025


On Mon, 5 May 2025 09:50:33 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this change to account for pending allocations when deciding how much to shrink the heap after a full gc. Otherwise, we shrink the heap only to trigger an expansion to satisfy the allocation request that triggered the full gc.
>> 
>> Testing: Tier 1-3
>
> Ivan Walulya 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 five additional commits since the last revision:
> 
>  - use align_up_to_region_byte_size
>  - Merge remote-tracking branch 'upstream/master' into full_collection_resize_amount
>  - Thomas Review
>  - nit
>  - refactor full collection

Since all invocations of full-GC go through the following version, it is the de facto full-GC entry point:


  bool do_full_collection(bool clear_all_soft_refs,
                          bool do_maximal_compaction,
                          size_t allocation_word_size);


The newly-add argument is at a different level of abstraction compared to the existing parameters, so this part feels like a small detour -- mostly caused by a preexisting design issue. If that design issue were resolved, we likely wouldn't need this extra argument at all. With that in mind, what do you think about addressing the underlying design problem first (or doing so alongside an improved `full_collection_resize_amount` policy)?

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

PR Comment: https://git.openjdk.org/jdk/pull/24944#issuecomment-2885685487


More information about the hotspot-gc-dev mailing list