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

Todd Lipcon todd at cloudera.com
Tue Mar 26 15:51:39 PDT 2013


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: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20130326/3473c7a8/attachment.html 


More information about the hotspot-gc-dev mailing list