CFV: New Project: ZGC

[Roman Kennke]

Hi Volker,

FWIW, I have to agree with Dalibor and John Rose on this.

I have not seen any signs of bad intent or even attempts to sabotage 
towards Shenandoah from Oracle. Quite the contrary: Oracle employees 
have always been supportive of it, and helpful in moving it forward, and 
when something got stuck (like you mention the process of creating the 
actual project), it has been communicated well enough. I have to give 
Oracle credits for that.

I have already voted yes to this, and why shouldn't I?

Yes, it would have been nice to discuss this beforehand.
Yes, it would have been even greater if Oracle had released it from the 
early phases of work, rather than when it's presumably almost done.
Yes, it would have been even more greater if we have had a chance to 
collaborate on one single project.

That's a bunch of would-have's and could-have's. But that's how Oracle 
('s employees) decides to work, and that's the situation we have now, 
and I am ok with that, even if I decide to work differently ;-)

I do think it's better to move it into an open source project rather 
than let it rot in a lab or bake it into a commercial fork or any other 
alternative scenario. I can only welcome Oracle to do that.

There are already very noticable synergies between the two projects, 
most notably right now in the collaboration on the GC interface. From 
the looks of it, it will finally confine each GC to their own source 
dirs and files, as opposed to sprinkle their stuff all over the place. 
As a platform dev, you've got to like that too.
 From the description of ZGC project, there will be even more synergies 
between ZGC and Shenandoah in the future: for example, concurrent 
weak-ref processing, concurrent class-unloading, concurrent this and 
that. A couple of those things are already solved in Shenandoah and ZGC 
might pick this up, and vice versa. This is great stuff IMO. I should 
also mention the (somewhat independent) effort to deflate monitors 
concurrently, which is not directly GC related, but will help reduce 
everybody GC's pause times too.

As for CMS: the current efforts to improve the GC interface have already 
led to isolate CMS fairly well, with some finishing touchups and Erik's 
barrier set refactoring, there will be no more CMS specific code around 
all over the place anymore. Not sure if this is enough to get some 
'community support' for it, but at least it doesn't hurt everybody else 
in the runtime and compilers anymore. It may well end up being 
deprecated but alive forever (or at least as there is one user using it)?

The only issue that might arise out of it is confusion of end users, 
should both Shenandoah and ZGC end up in regular OpenJDK builds (and I 
think they will... after all, why not?). But that doesn't justify to 
keep one or the other out of it either. And frankly, this is quite 
typical Java. The JVM has almost everthing duplicated and triplicated 
already: JITs, GUI toolkits, XML parsers, concurrency, aarch64 ports and 
who knows what else... now we're gonna have 2 large-heap GCs too. I 
think that's fine.

Best regards, Roman


> Hi Per,
>
> first of all I want to notice that you haven't gone through the
> optional but nevertheless recommended [1] step of discussing your
> project before proposing and voting for it. This is unfortunate,
> because it again confirms the impression that projects started by
> Oracle are somehow treated preferentially compared to projects
> proposed by external contributors.
>
> For example the Shenandoah project had to go through a six month
> interrogation [2,3] process before they could finally start the call
> for voting on their project creation.
>
> I think it would be beneficial for the OpenJDK project if internal and
> external contributors would be treated equally (well :)
>
> Conceptually I would be very interested in the relationship between
> ZGC and Shenandoah as they obviously both have the same goals and
> maybe even share some of the same ideas. As Shenandoah is in the
> OpenJDK since more than two years and publicly available even longer,
> I suppose you are aware of it.
>
> 1. What are the benefits / advantages of ZGC over Shenandoah?
> 2. Does it make sense to have both, ZGC and Shenandoah in the main code line?
> 2.1 If yes, why?
> 2.2 If no, why you propose ZGC at all and not contribute to
> Shenandoah? It's there since more than two years! That you already
> worked on ZGC for some time as well doesn't count here because we (the
> OpenJDK community) couldn't see that and had no chance to contribute
> to it.
> 3. Oracle has just deprecated CMS and other collectors because
> according to Oracle it was just too expensive to maintain that many
> collectors in parallel. Now I wonder how yet another new collector
> fits into the picture?
>
> The answer to all these question would be important for me before
> casting a qualified vote.
>
> Thank you and best regards,
> Volker
>
> [1] http://openjdk.java.net/projects/#new-project
> [2] http://mail.openjdk.java.net/pipermail/discuss/2015-February/003680.html
> [3] http://mail.openjdk.java.net/pipermail/discuss/2015-August/003767.html
>
> On Wed, Oct 25, 2017 at 9:45 PM, Per Liden <per.liden at oracle.com> 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