CFV: New Project: ZGC

[Stuart Marks]

Vote: yes

On 10/25/17 12: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