Can remapping/unmapping virtual memory make Java Garbage Collection go faster?

Jesper Wilhelmsson jesper.wilhelmsson at
Tue Mar 26 15:40:29 PDT 2013

Hi Anjul,

Similar things have been done before. The example I come to think about right 
now is the mapping collector [1], but I know there have been other work on this 
as well.


Anjul skrev 26/3/13 6:35 AM:
> Garbage collectors move data to eliminate holes in virtual memory both to make
> new allocations faster and to make it feasible to allocate large contiguous chunks.
> In modern 64-bit OSes two significant optimization possibilities seem to arise.
> One is to simply not do compaction. Instead, unmap pages that contain no live
> objects and keep allocating new objects to further and further areas of virtual
> memory by mapping pages in. On a 64-bit system this could be pretty sustainable.
> The other possibility is that if a large object does need to be compacted/moved
> to a different virtual address, then the pages that contain it could simply be
> remapped to a different area of virtual memory without copying any data.
> There would be extra work, relative to copying, for reorganizing the page
> tables, but I think that might be logarithmically smaller.
> This seems to ensure that there is no hole larger than a page. Sparsely occupied
> pages could be copied as usual or with some bookkeeping used for allocating
> small objects.
> Is there a problem in this scheme? Are there any JVMs out there that do this or
> are shortly expected to do so?

More information about the hotspot-gc-dev mailing list