RFR: 8357445: G1: Time-Based Heap Uncommit During Idle Periods [v4]

[Ivan Walulya]

On Thu, 17 Jul 2025 01:50:59 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> **Implements:** https://bugs.openjdk.org/browse/JDK-8357445
>> 
>> Implement time-based heap uncommit for G1 during idle periods.
>> 
>> Key changes:
>> - Added G1HeapEvaluationTask for periodic heap evaluation
>> - Switch from G1ServiceTask to PeriodicTask for improved scheduling
>> - Implemented time-based heap sizing policy with configurable uncommit delay
>> - Added region activity tracking with last access timestamps
>> - Integrated VM_G1ShrinkHeap operation for safe heap shrinking
>> - Added new G1 flags: G1UseTimeBasedHeapSizing, G1TimeBasedEvaluationIntervalMillis, G1UncommitDelayMillis, G1MinRegionsToUncommit
>> - Added 'sizing' log tag for heap sizing operations
>> 
>> Comprehensive Test Coverage:
>> - Enhanced TestG1RegionUncommit: minimum heap boundaries, concurrent allocation/uncommit scenarios
>> - Enhanced TestTimeBasedHeapSizing: humongous object handling, rapid allocation cycles, edge cases
>> - Enhanced TestTimeBasedRegionTracking: concurrent region access, lifecycle transition validation
>> - Enhanced TestTimeBasedHeapConfig: parameter boundary values, small heap configurations
>> 
>> This ensures time-based heap uncommit works correctly while maintaining all safety guarantees and test expectations.
>
> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357445: Remove redundant record_activity calls and leftover initialize call
>   
>   - Remove record_activity() from retirement methods as hr_clear() is always last
>   - Remove leftover initialize() call since initialization moved to constructor
>   - Remove unused G1 includes from vmOperations after moving VM_G1ShrinkHeap

Hi,

There appears to be a disconnect between the `get_uncommit_candidates` logic and the actual heap shrinking performed by `G1CollectedHeap::shrink`. While `G1HeapSizingPolicy::evaluate_heap_resize` determines the number of bytes to shrink (via shrink_bytes) and passes this to the heap shrink logic, the regions identified as uncommit candidates are not explicitly communicated or prioritized during the shrink operation.

As a result, the heap may be shrunk without necessarily uncommitting the specific regions previously marked as uncommit candidates. This can lead to a scenario where those regions remain committed even after the shrink, potentially triggering repeated shrink attempts in subsequent calls to `G1HeapSizingPolicy::evaluate_heap_resize`.

Is this understanding correct?

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

PR Comment: https://git.openjdk.org/jdk/pull/26240#issuecomment-3084463449