When archiving Java heap objects, the VM tries to allocate the archive regions near or at the Java heap top. Additional G1 regions are allocated when needed during the copying process. The allocated regions must be consecutive to accommodate all archived Java heap objects.

It is possible that the VM may see an already allocated region when trying to allocate new regions for archiving. In that case, the archiving would fail. During the early days of the Java heap object archiving work, I discussed with Thomas about one alternative, which was to copy the objects into a buffer outside the Java heap. That's the the solution 1) below.

Solution 1):
Allocate a buffer (no specific memory location requirement) and copy the heap objects to the buffer. Additional buffers can be allocated when needed, and they don't need to form a consecutive block of memory. The pointers within the copied Java objects need to be computed from the Java heap top as the 'real heap address' (so their runtime positions are at the heap top), instead of the buffer address. Region verification code also needs to be updated to reflect how the pointers are computed now.

Solution 2):
Find a range (consecutive heap regions) within the Java heap that is free. Copy the archive objects to that range. The pointer update and verification are similar to solution 1).

The solution 1 can be implemented now. Solution 2) has the benefit of not requiring additional memory for copying archived objects. That's important as I did run into insufficient memory at dump time in real use cases during the past year, so any memory saving at dump time is desirable.

It's better to go with 2) when the size of archive range is known before copying. With the planned work for class pre-initialization and enhanced object archiving support (JDK-8233887), it will be able to obtain (or have a good estimate of) the total size before copying. Solution 1 can be enhanced to use
heap memory when that happens.