RFC: JEP - ZGC: A Scalable Low-Latency Garbage Collector
per.liden at oracle.com
Mon May 7 13:05:50 UTC 2018
On 05/07/2018 02:20 PM, Kirk Pepperdine wrote:
>> On May 7, 2018, at 1:39 PM, Per Liden <per.liden at oracle.com> wrote:
>> On 05/07/2018 09:52 AM, Kirk Pepperdine wrote:
>>> I believe that there is a combination of both of these ideas from IBM and the Sun collectors that might eliminate the need for compaction leaving a pause time this bound either by TTSP or scan for roots time, which ever is greater. I’m wondering if anything like this has been discussed.
>> Pause times in ZGC are already bound by TTSP and root scanning. And large objects are never moved.
> Interesting, have you considered allocating large objects away from smaller ones or is this also the case with ZGC?
Large objects (i.e. large heap regions) are typically allocated in a
different part of the virtual address space, away from small heap
regions. However, we don't do this to fight fragmentation, we do this to
allow for a fast allocation path for small heap regions (finding a small
heap region is on average O(1)).
To fight fragmentation, we do the following:
1) We segregate object allocations based on size (small objects go into
small heap regions, medium objects into medium heap regions, etc).
2) We don't have a 1:1 mapping between physical memory (i.e. max heap
size) and virtual address space. Instead we reserve a lot more virtual
address space, which essentially means we guaranteed to find a hole in
the heap big enough for any allocation without having to do compaction
first (this of course assumes there are enough physical memory available
to back such allocation).
If you're interested in how ZGC works, I'd recommend heading over to the
ZGC wiki and have a look at the slides and video from our talk
at Jfokus back in February. There we cover some of these things.
More information about the hotspot-gc-dev