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

[Per Liden]

Hi,

On 05/07/2018 11:11 AM, Simone Bordet wrote:
> Hi,
> 
> On Mon, Apr 30, 2018 at 7:45 AM, Per Liden <per.liden at oracle.com> wrote:
>> Hi,
>>
>> We're looking at submitting the ZGC JEP to become Candidate. But first we'd
>> like to solicit feedback.
>>
>> http://openjdk.java.net/jeps/8197831
> 
> FWIW, I have high hopes for this collector :)
> 
> Given the discussion thread with Per and Gil about the
> similarities/differences with Azul's C4, I was wondering whether
> making ZGC multi-generation has been considered and why it's been
> decided to not make it multi-generation, since Azul went from single
> to multi generation from Pauseless to C4.

 From what we've seen, a single generation actually works really well 
for many workloads. Having said that, making ZGC multi-generational is 
something we've been thinking about. We've also been looking at a few 
alternative schemes, like thread-local GC and hot/cold areas. We don't 
know yet which path we will choose here. Future feedback, 
experimentation and benchmarking will help guide this decision. The 
"first stable version" of ZGC will have a single generation.

> 
> Also, I remember using JRockit's deterministic collector with great
> results, so I was wondering if there is (or willing to produce) a
> comparison table between the two.

JRockit's DetGC is quite different from ZGC, both in terms of the goals 
and how they are designed. Here's a super-quick comparison:

DetGC is a single-generation, single-threaded, concurrent marking, 
stop-the-world partial-compacting, concurrent sweeping GC. It was 
initially designed to keep a 30ms max pause, a with 1G heap (30% 
live-set). There were workloads where it did better (10ms max pause on a 
3G heap). DetGC basically operate under a time limit in stop-the-world 
phases, compacting as much as it can in this time.

ZGC, is (currently) a single-generation, multi-threaded, concurrent 
marking, concurrent compacting GC. Stop-the-world work is limited to 
root-scanning. This means is can scale to much larger heaps, without 
affecting pause times. This also means ZGC can do more compaction 
(concurrently), and thereby it's much less sensitive to fragmentation 
issues (which is typically DetGC's achilles' heel).

> 
> Finally, I'd like to know the plans with regard to JIT integration
> with regards to C2 and Graal.
> Integrate with both, or only one of them ?

We have C1 and C2 support today. Graal support will come later.

cheers,
Per