CFV: New Project: ZGC

[Brian Goetz]

Vote: yes

On 10/25/2017 4:52 PM, coleen.phillimore at oracle.com wrote:
> 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
>