JDK-8038423 : G1: Decommit memory within the heap
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-03-26
  • Updated: 2015-08-12
  • Resolved: 2014-08-19
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 8 JDK 9
8u40Fixed 9 b29Fixed
Related Reports
Blocks :  
JDK-8041506 - The test gc/g1/TestHumongousShrinkHeap.java reports that memory is not de-committed
Blocks :  
JDK-8054818 - Refactor HeapRegionSeq to manage heap region and auxiliary data
Blocks :  
JDK-8054819 - Rename HeapRegionSeq to HeapRegionManager
Blocks :  
JDK-8048084 - Need to abort concurrent next bitmap clear when marking is aborted during concurrent next bitmap clearing
Blocks :  
JDK-8048112 - G1 Full GC needs to support the case when the very first region is not available
Duplicate :  
JDK-8014716 - G1: heap (re-)sizing does not take card table alignment required into account
Relates :  
JDK-8055525 - Bigapp weblogic+medrec fails to startup after JDK-8038423
Relates :  
JDK-8060021 - Startup performance regressions after JDK-8038423
Relates :  
JDK-8055635 - Missing include in g1RegionToSpaceMapper.hpp results in unresolved symbol of fastdebug build without precompiled headers
Relates :  
JDK-8067469 - G1 ignores AlwaysPreTouch
Relates :  
JDK-8043766 - CMM Testing: 8u40 Decommit auxiliary data structures
Relates :  
JDK-8073632 - Make auxiliary data structures know their own translation factor
Relates :  
JDK-8042097 - G1: Remove ConcurrentMark::update_g1_committed()
Relates :  
JDK-8048086 - G1BlockOffsetSharedArray::compute_size() uses wrong alignment to calculate the amount of space to be reserved
Relates :  
JDK-8059758 - Footprint regressions with JDK-8038423
Relates :  
JDK-8041946 - CMM Testing: 8u40 an allocated humongous object at the end of the heap should not prevents shrinking the heap
Relates :  
JDK-8133456 - HeapRegionManager::shrink_by() iterates suboptimally across regions
Relates :  
JDK-8048085 - Aborting marking just before remark results in useless additional clearing of the next mark bitmap
Description
In some cases the ergonomics is trying to shrink a heap that is fairly empty, but fails due to allocated regions at the top of the heap that G1 chooses not to move for various reasons. To work around this without having to pay extra in performance by moving these regions, we should make it possible to decommit memory within the heap - i.e. make the heap capable of handling holes in the committed heap area.

This will require changes in freelist management, virtual space management, and misc parts of the GC code that assumes that the heap is one contiguous area.