JDK-8220089 : G1 reuse survivor region as eden region at the end of gc
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-03-04
  • Updated: 2019-11-14
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.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8225484 - Investigate removal of survivor rate groups for survivor regions
Blocks :  
JDK-8218049 - Survivor MemoryMXBean used() size granularity is region based
Relates :  
JDK-8225478 - Make G1CMRootRegions independent of HeapRegions
Relates :  
JDK-8225484 - Investigate removal of survivor rate groups for survivor regions
Relates :  
JDK-8224155 - Change all survivor regions to eden at the end of gc
Relates :  
JDK-8210473 - JEP 345: NUMA-Aware Memory Allocation for G1
Description
Currently G1 has a strict separation of survivor and eden regions in that at the end of gc it fills up that region with dummy object(s).

This means that a lot of space (1/2 region on average) may be wasted every GC.

Depending on the young gen and region size this can add up to a significant of space over many collections, causing unnecessary additional GCs, i.e. significant performance degradation. It may also decrease PLAB size due to that additional waste, i.e. perf degradation during  GC due to increased PLAB refills (to be verified).

Particularly in case of an extension of NUMA support where you may use a survivor allocation region per NUMA node, this would result in waste of 1/2 region per NUMA node on average which may cause single-digit throughput regressions due to more GCs and smaller PLABs compared to a single survivor allocation region with more NUMA nodes.

Since G1 turns survivor into an eden region at the start of young gc anyway, and is otherwise mostly equal to an (otherwise unused) eden region, one option could be to instead of filling up the survivor alloc region with dummy objects to turn it into eden region(s) at the end of gc and use the remaining space immediately for next mutator allocation.
Comments
MemoryMXBeans should count a retained region as a survivor not as a mutator region. I.e. the behavior mentioned above should be fixed and webrev.1 addresses it.
09-04-2019
Data used for MemoryMXBeans are updated at the end of gc which happens after survivor region -> mutator region conversion.
28-03-2019
People might be surprised that there are no survivor regions anywhere at mutator time; imho this is not a big deal - survivor regions are in the end some help to explain the algorithm (i.e. where do evacuated objects end up during gc), but otherwise really similar to eden regions. For backwards compatibility MemoryMXBeans may still report Survivor space metrics as before. Or maybe there isn't actually need to do anything fancy but load the remainder of the survivor alloc region into the mutator alloc region.
04-03-2019
Some potential problems that might need to be looked at if this is implemented as suggested: - the collection set may or may not use information about whether a region is/has been a survivor region somewhere. - G1 re-calculates eden size based on current remembered set sizes; a change must make sure it does not change the behavior significantly - The card table of the survivor region that is reused must be properly filled as "young" which I believe it does already - memory usage accounting should consider these half-filled regions, particularly the MemoryMXBeans in some way.
04-03-2019