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

[Tony Hosking]

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 http://www.azulsystems.com/products/zing/c4-java-garbage-collector-wp.

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 cloudera.com> 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: http://dl.acm.org/citation.cfm?id=1993491&dl=ACM&coll=DL&CFID=197266941&CFTOKEN=89353319
> 
> -Todd
> 
> On Tue, Mar 26, 2013 at 3:40 PM, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> 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] http://dl.acm.org/citation.cfm?id=1346281.1346294&coll=DL&dl=GUIDE&CFID=197206966&CFTOKEN=64021895
> 
> 
> 
> 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...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130327/bf9c597e/attachment.htm>