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

[Anjul]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130325/ae5aeaa4/attachment.htm>