From mark.reinhold at oracle.com Wed Oct 11 15:47:24 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 11 Oct 2017 08:47:24 -0700 (PDT) Subject: Result: New Project: JDK Message-ID: <20171011154724.A050ED2552@eggemoggin.niobe.net> Voting on the JDK Project, with me as the Lead [1], is now closed. Yes: 35 Veto: 0 Abstain: 0 (Four votes, cast by non-Members, were not counted.) According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the new Project and its initial Lead. - Mark [1] http://mail.openjdk.java.net/pipermail/announce/2017-September/000231.html From rob.mckenna at oracle.com Thu Oct 12 14:15:20 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 12 Oct 2017 15:15:20 +0100 Subject: Result: New Project: JDK Updates Message-ID: <20171012141520.GE4262@vimes> Voting on the JDK Updates Project, with me as the Lead [1], is now closed. Yes: 31 Veto: 0 Abstain: 0 (Three votes, cast by non-Members, were not counted.) According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the new Project and its initial Lead. -Rob http://mail.openjdk.java.net/pipermail/announce/2017-September/000232.html From john.r.rose at oracle.com Tue Oct 17 23:15:06 2017 From: john.r.rose at oracle.com (John Rose) Date: Tue, 17 Oct 2017 16:15:06 -0700 Subject: Result: New Project Metropolis Message-ID: Voting on the Metropolis Project with initial Lead Vladimir Kozlov [1] is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the new Project and its initial Lead. ? John [1] http://mail.openjdk.java.net/pipermail/announce/2017-September/000233.html From per.liden at oracle.com Wed Oct 25 19:45:23 2017 From: per.liden at oracle.com (Per Liden) Date: Wed, 25 Oct 2017 21:45:23 +0200 Subject: CFV: New Project: ZGC Message-ID: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@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 From ron.pressler at oracle.com Fri Oct 27 19:28:07 2017 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 27 Oct 2017 22:28:07 +0300 Subject: CFV: New Project: Loom Message-ID: I hereby propose the creation of Project Loom with myself as the Lead and the? HotSpot Group as the sponsoring Group. In accordance with the OpenJDK guidelines [1], this project will provide a? venue to explore and incubate Java VM features and APIs built on top of them? for the implementation of lightweight user-mode threads (fibers), delimited? continuations (of some form), and related features, such as explicit? tail-call [2]. The initial Reviewers and Committers will be:? * John Rose * Karen Kinnear * Alan Bateman * Brian Goetz * Mark Reinhold * Ron Pressler * Paul Sandoz * Frederic Parain * Erik Duveblad * Vladimir Ivanov The initial source of this project will be a clone of a JDK 10 repository.? Changes from the JDK 10 parent will be synced into Loom periodically. Similar? to Project Valhalla, we will follow a "commit first, review later" policy, as? code will not flow directly from the Loom repositories into the JDK? repositories, but instead will be done by a "curated merge" where select? changes are extracted into new changesets for incorporation into JDK? repositories when they are ready for inclusion.? Votes are due by by the end of November 10, 2017 (UTC). Only current OpenJDK Members [3] 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 [4].? Ron Pressler [1] http://openjdk.java.net/projects/#new-project? [2] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html [3] http://openjdk.java.net/census#members? [4] http://openjdk.java.net/projects/#new-project-vote?