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

Tony Hosking hosking at
Tue Mar 26 16:26:24 PDT 2013

Indeed.  Compressor also does similar tricks.
Both the Azul concurrent collector and Compressor are described in our recent book: "The Garbage Collection Handbook", coauthored with Richard Jones and Eliot Moss.
Both the papers referred to below are also definitely worth a read.
Plus more on Pauseless and Zing at

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484

On Mar 27, 2013, at 9:51 AM, Todd Lipcon <todd at> wrote:

> The Azul concurrent collector also makes heavy use of virtual memory tricks.
> The downside of implementing these methods is typically that mucking with VM mappings can be very inefficient: there's a process-wide lock involved, and it also causes TLB shootdowns to invalidate prior mappings. So, doing it fine grained costs a lot, and you need to be relatively clever to get good performance. (Azul uses a kernel module with bulk remap operations and the ability to multiply map physical memory to multiple virtual locations at the same time).
> I highly recommend reading the paper, though:
> -Todd
> On Tue, Mar 26, 2013 at 3:40 PM, Jesper Wilhelmsson <jesper.wilhelmsson at> wrote:
> 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.
> /Jesper
> [1]
> 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?
> -- 
> Todd Lipcon
> Software Engineer, Cloudera

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the hotspot-gc-dev mailing list