To reduce image size CRaC aggressively cleans up heap before checkpointing. The implementation of this is GC-dependent. For G1 it means uncommitting all free regions. This leads to several problems:
1. Committed heap becomes almost full which makes G1 invoke another GC. In worst case it is a full GC that occurs on restore noticeably prolonging after-restore start-up.
2. After restore G1 has to expand the heap back to its pre-checkpoint size (roughly). By default this process is gradual and requires multiple GCs to be performed, the first of which are likely to be mixed or even full because the heap is still small. This may lead to sub-par performance, i.e it constitutes after-restore warm-up.

Serial and Parallel GCs cleanup free memory by uncommitting it and immediately committing it back — on Linux, which is currently the only platform with real C/R engines existing, the effect of this is that the memory deems available to the VM although it is not yet actually reserved by the OS (unless -XX:+AlwaysPreTouch is used). For existing engines it is enough to not actually record the memory into the checkpoint image, and GCs do not have to invoke the logic of committing the memory (which requires a GC in case of G1).

It is proposed to do the same for G1 to solve both of the problems stated above.