CFV: New Project: ZGC

[Roman Kennke]

Vote: yes

Am 25. Oktober 2017 21:45:23 MESZ schrieb Per Liden <per.liden at oracle.com>:
>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

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.