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