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

Albert Mingkun Yang ayang at openjdk.org
Wed May 14 15:12:52 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

I find it a bit odd that `G1CollectedHeap::do_full_collection` (the full-gc entry API) takes this additional argument for heap-resizing only, as I tend to think the heap-resizing part (and possibly some related logic) should *not* be considered part of full-GC. This seems to be a preexisting design: for example, at the end of `G1FullCollector::complete_collection`, the list of `heap->...` invocations suggests that this logic actually belongs to the heap. In other words, the heap should be notified upon full-GC completion and perform the necessary work accordingly—not have full-GC operate on the heap as it sees fit.

Also, as written in the ticket:

> It is not a major issue, as the shrinking does not actually uncommit the regions, just marks these regions for uncommitting concurrently, so the expansion is just undoing this marking. 

Since no OS-level commit/uncommit (the actual expensive operation) is happening, I'm not sure that fixing this issue is a net win if it comes at the cost of changing the full-GC entry API.

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

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


More information about the hotspot-gc-dev mailing list