RFR: 8314573: G1: Heap resizing at Remark does not take existing eden regions into account

[Thomas Schatzl]

On Thu, 24 Aug 2023 07:50:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that tries to make the heap resizing policy at Remark more similar to the one after full GC?
>> 
>> The problem is that when calculating the amount of free regions to apply the Min/MaxHeapFreeRatio during Remark g1 does not consider that at Remark we might have already allocated lots of eden regions.
>> Which means that the heap appears fuller than it would be during full gc, which means that Remark sometimes expands very aggressively due to MinHeapFreeRatio setting. I.e. if at the time of remark pause free regions 
>> 
>> There should be no impact wrt to shrinking: MaxHeapFreeRatio is by default (70%) larger than the maximum eden/young gen size (G1MaxNewSizePercent = 60%), so there should be no additional shrinking (that would only lead to additional heap expansion later).
>> 
>> I am aware that fiddling with the values (MaxHeapFreeRatio/G1MaxNewSizePercent) may create a situation where g1 would immediately increase the heap afterwards due to young gen being able to be larger than MaxHeapFreeRatio (if G1MaxNewSizePercent > MaxHeapFreeRatio and G1 would use that large young gen). However this is no different to the current situation after full gc, so I would like to keep it as is. Also for the sake of not complicating this (imo) straightforward change.
>> 
>> A more comprehensive improvement to the problem would be [JDK-8238687](https://bugs.openjdk.org/browse/JDK-8238687), where we do the resizing when eden is empty after young gc, but I think this is out of scope here: this fix improves the situation recently reported to me where g1 suddenly started to expand a lot during Remark after upgrades, and should also fix the issue reported in https://bugs.openjdk.org/browse/JDK-6490394 in the last comment (which has been reported around 1 year after the push, which means likely it got overlooked).
>> 
>> Testing: tier1-3, internal perf testing with no changes
>> 
>> Thanks,
>>   Thomas
>
>> However this is no different to the current situation after full gc
> 
> I don't think they are the same -- in full-gc case eden is indeed empty, while in remark-pause the patch treats eden as empty even when it's not.
> 
> The version on master treats eden as full and do the heap resizing (expand/shrink). Can we permit only shrink in remark-pause, since eden liveness is unknown at that moment? (Remark-pause occurs not due to alloc-failure, so it is kind of logical not to expand the heap.)

Thanks @albertnetymk @kimbarrett for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/15400#issuecomment-1697538979