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: 2020-02-07
  • 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 :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8211756 :  
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

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