JDK-6490394 : G1: Allow heap shrinking / memory unmapping after reclaiming regions during Remark
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-11-06
  • Updated: 2023-08-18
  • Resolved: 2018-10-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12
12 b18Fixed
Related Reports
Blocks :  
JDK-8071913 - Filter out entries to free/uncommitted regions during iteration
Relates :  
JDK-8314573 - G1: Heap resizing at Remark does not take existing eden regions into account
Relates :  
JDK-8204089 - JEP 346: Promptly Return Unused Committed Memory from G1
Relates :  
JDK-8213898 - CDS dumping of springboot asserts in G1ArchiveAllocator::alloc_new_region
Relates :  
JDK-8238686 - G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc
Sub Tasks
JDK-8211756 :  
Release Note: G1 May Uncommit Memory During Marking Cycle - Closed
Description
Right now G1 can only expand the heap outside of full GC, never shrink it.

Given that G1 does incrementally compact the heap, it might be a good opportunity to do that whenever regions are actually made available again (GC cleanup, possibly at the end of the mixed gc cycle).
Comments
I backported this change to our internal JDK11, in the attempt to save memory. However I found that in some cases this change could increase memory footprint, because the heap can expand during Remark. One example is DaCapo h2 benchmark with "-s huge -n 3", -Xms100m -Xmx4g. Without this change, the heap expands to around 1.3G to 1.6G. With this change, the heap expands to 2.1G to 2.6G. The benchmark runs slightly faster, and uses 9-10% less CPU with this change due to the larger heap, but the memory footprint (peak RSS) increased by around 700MB. I attached the results (with 20 trials) and sample GC logs for h2. This is a significant behavior change. Especially if the application tightly depends on the old behavior of lower memory footprint, it could be disastrous if the memory footprint suddenly increased from JDK11 to JDK12. Is it expected can the memory footprint could increase with this change? Could we fix it so that it only shrinks the heap during remark, but never expands it?
08-08-2019
URL: http://hg.openjdk.java.net/jdk/jdk/rev/08041b0d7c08 User: tschatzl Date: 2018-10-31 12:44:27 +0000
31-10-2018
The remark pause poses an interesting place to try to uncommit memory after reclaiming completely empty regions. Other places like end of mixed phase could be done in a different CR too.
07-09-2018
JDK-8071913 blocks this issue: as long as g1 tries to scan through regions that have already been freed, we cannot unmap memory of these regions.
02-02-2015
Actually G1 could reclaim regions after any action that frees up space in the old generation, after marking when reclaiming fully empty regions, or mixed GCs.
22-05-2014