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

[Todd Lipcon]

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<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/20130326/3473c7a8/attachment.htm>