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

[Kirk Pepperdine]

Hi Per,

Thank you very much for the links. I watched the video for the JFokus event a while ago. Unfortunately I had to miss because other obligations and I think the session was leveled perfectly for the audience but it left me with a number of questions which I will now stash away until I’ve read all the other stuff. I am, just now, starting to get questions about ZGC. About all I’ve been able to say, having no hands on experience with it, is that there will always be trade-offs between allocators, the collector and mutator throughput and while this look very very promising, it’s still wait and see situation.

Regards,
Kirk

> On May 7, 2018, at 3:05 PM, Per Liden <per.liden at oracle.com> wrote:
> 
> 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