RFC: JEP - ZGC: A Scalable Low-Latency Garbage Collector

[Per Liden]

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[1] and have a look at the slides[2] and video[3] from our talk 
at Jfokus back in February. There we cover some of these things.

[1] https://wiki.openjdk.java.net/display/zgc/Main
[2] http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf
[3] https://www.youtube.com/watch?v=tShc0dyFtgw

/Per