CFV: New Project: ZGC

[coleen.phillimore at oracle.com]

Vote: yes

On 10/25/17 3:45 PM, Per Liden wrote:
> I hereby propose the creation of the ZGC Project with myself (Per 
> Liden) as the Lead and the HotSpot Group as the sponsoring Group.
>
> In accordance with the OpenJDK guidelines [1], this project will 
> provide a home for the continued development of the Z Garbage 
> Collector, also known as ZGC. ZGC is a new garbage collector optimized 
> for low latency and very large heaps. We've developed ZGC internally 
> at Oracle so far, and we're now open-sourcing it so as to broaden the 
> base of both contributors and users.
>
> ZGC has been designed with the following goals in mind:
> * Handle multi-terabyte heaps
> * GC pause times not exceeding 10ms
> * No more than 15% application throughput reduction compared to using G1
>
> We have strong ambitions to meet these goals for a large set of 
> relevant workloads. At the same time we want to acknowledge that we 
> don't see these goals as hard requirements for every conceivable 
> workload. We are however currently able to meet or exceed these goals 
> on some well-known industry standard benchmarks.
>
> At a glance, ZGC is a concurrent, currently single-generation, 
> region-based, incrementally compacting collector. Stop-The-World 
> phases are limited to root scanning, meaning GC pause times do not 
> increase with the heap- or live-set size.
>
> While there is still work to do, the design and implementation is 
> reasonably mature and stable. ZGC today executes the following GC 
> tasks/phases concurrently:
> * Marking
> * Reference processing (java.lang.ref.*)
> * Relocation set selection
> * Relocation/Compaction
>
> And we're actively working on making the remaining GC tasks/phases 
> concurrent. These are:
> * Weak root processing (StringTable, JNIWeakGlobalRefs)
> * Class unloading
>
> A core design principle/choice in ZGC is the use of load barriers in 
> combination with colored object pointers (i.e. colored oops). This is 
> what enables ZGC to do concurrent operations, such as object 
> relocation, while Java application threads are running. From a Java 
> thread's perspective, the act of loading a reference field in a Java 
> object is subject to a load barrier. In addition to an object address, 
> a colored object pointer contains information used by the load barrier 
> to determine if some action needs to be taken before allowing a Java 
> thread to use the pointer. For example, the object might have been 
> relocated, in which case the load barrier will detect the situation 
> and take appropriate action.
>
> Compared to alternative techniques, we believe the colored pointers 
> scheme offers some very attractive properties. To name a few:
>
> * It allows us to reclaim and reuse memory during the 
> relocation/compaction phase, before pointers pointing into the 
> reclaimed/reused regions have been fixed. This helps keep the general 
> heap overhead down. It also means that there is no need to implement a 
> separate mark-compact algorithm to handle "Full GC".
>
> * It allows us to have relatively few and simple GC barriers. This 
> helps keep the runtime overhead down. It also means that it's easier 
> to implement, optimize and maintain the GC barrier code in our 
> interpreter and JIT compilers.
>
> * We currently store marking and relocation related information in the 
> colored pointers. However, the versatile nature of this scheme allows 
> us to store any type of information (as long as we can fit it into the 
> pointer) and let the load barrier take any action it wants to based on 
> that information. We believe this will lay the foundation for many 
> future features. To pick one example, in a heterogeneous memory 
> environment, this could be used to track heap access patterns to guide 
> GC relocation decisions to move rarely used objects to "cold storage".
>
> Much of the remaining work involves addressing latency issues in 
> non-GC subsystems in HotSpot, such as being able to concurrently 
> unlink stale entries in the StringTable. We hope and expect to see a 
> fair bit of collaboration with people working on other garbage 
> collectors in areas where we have a common interest.
>
> Some of the work coming out of the ZGC project has already been seen, 
> either in the form of general improvements, or because a feature has 
> found use cases outside of ZGC, such as:
> * Atomics re-write
> * GC Barrier API
> * Thread local handshakes
>
> I (Per Liden) am a member of the HotSpot GC team at Oracle, and have 
> been working on JRockit and HotSpot projects for the past 8 years. I'm 
> the initial author of ZGC, but many people have made significant 
> contributions since then.
>
> Special thanks to Stefan Karlsson, who has been working with me on ZGC 
> since the very early phases of this project.
>
> The initial Reviewers and Committers will be (based on people who have 
> contributed to ZGC development within Oracle so far):
>
> * Stefan Karlsson (Reviewer)
> * Erik Österlund (Committer)
> * Mikael Gerdin (Committer)
> * Kim Barret (Committer)
> * Nils Eliasson (Committer)
> * Rickard Bäckman (Committer)
> * Roland Westrelin (Committer)
> * Coleen Philimore (Committer)
> * Robin Ehn (Committer)
> * Gerard Ziemski (Committer)
>
> The initial source of this project will be based on a clone of a JDK 
> 10 repository, plus the latest ZGC patch set. Changes from the JDK 10 
> parent will be synced into ZGC periodically. Change review policy will 
> be determined by the Lead and a consensus of Reviewers. Review is 
> expected to be relaxed initially, but made more strict as we get 
> closer to integration.
>
> The project will host at least the following mailing list:
>
> * zgc-dev for developers
>
> Votes are due by 23:59 CET on Wednesday, November 8, 2017.
>
> Only current OpenJDK Members [1] are eligible to vote on this motion. 
> Votes must be cast in the open on the discuss list. Replying to this 
> message is sufficient if your mail program honors the Reply-To header.
>
> For Lazy Consensus voting instructions, see [2].
>
> Regards,
> Per Liden
>
> [1] http://openjdk.java.net/census#members
> [2] http://openjdk.java.net/projects/#new-project-vote