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

[Jesper Wilhelmsson]

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?
>