Can remapping/unmapping virtual memory make Java Garbage Collection go faster?
jesper.wilhelmsson at oracle.com
Tue Mar 26 15:40:29 PDT 2013
Similar things have been done before. The example I come to think about right
now is the mapping collector , but I know there have been other work on this
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