From Alan.Bateman at oracle.com Sun Oct 1 01:43:32 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Oct 2017 02:43:32 +0100 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: <9f7a93d8-b588-42fd-e29c-993aabe49437@oracle.com> Vote: yes From doug.simon at oracle.com Sun Oct 1 06:50:06 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 1 Oct 2017 08:50:06 +0200 Subject: CFV: New Project: Metropolis In-Reply-To: <9f7a93d8-b588-42fd-e29c-993aabe49437@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> <9f7a93d8-b588-42fd-e29c-993aabe49437@oracle.com> Message-ID: Vote: yes Sent from my iPhone > On 1 Oct 2017, at 3:43 am, Alan Bateman wrote: > > Vote: yes From laurent.daynes at oracle.com Sun Oct 1 12:16:52 2017 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Sun, 1 Oct 2017 14:16:52 +0200 Subject: CFV: New Project: Metropolis In-Reply-To: <20170930104939.359077166@eggemoggin.niobe.net> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> <640A9E7D-B452-4488-B092-E123A08F15BE@oracle.com> <20170930104939.359077166@eggemoggin.niobe.net> Message-ID: <59D0DCB4.9060008@oracle.com> Vote: yes Laurent Daynes From laurent.daynes at oracle.com Sun Oct 1 12:35:42 2017 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Sun, 1 Oct 2017 14:35:42 +0200 Subject: CFV: New Project: JDK In-Reply-To: <3E46D1DB-15B1-4183-94DE-C0B82A800496@oracle.com> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> <23147d88-4207-abb5-8b21-50220b3bd18a@oracle.com> <3E46D1DB-15B1-4183-94DE-C0B82A800496@oracle.com> Message-ID: <59D0E11E.8060607@oracle.com> Vote: yes Laurent Daynes From laurent.daynes at oracle.com Sun Oct 1 12:35:59 2017 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Sun, 1 Oct 2017 14:35:59 +0200 Subject: CFV: New Project: JDK Updates In-Reply-To: <8F680133-65B8-4348-9263-1C32B11F5BE6@oracle.com> References: <20170927133908.GA6441@vimes> <0247b19c-d0b4-eb6d-bfe6-8d8a53baddf0@oracle.com> <8F680133-65B8-4348-9263-1C32B11F5BE6@oracle.com> Message-ID: <59D0E12F.3000203@oracle.com> Vote: yes Laurent Daynes From mandy.chung at oracle.com Mon Oct 2 03:23:46 2017 From: mandy.chung at oracle.com (mandy chung) Date: Sun, 1 Oct 2017 20:23:46 -0700 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: Vote: yes Mandy From adinn at redhat.com Mon Oct 2 10:44:34 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 2 Oct 2017 11:44:34 +0100 Subject: CFV: New Project: Metropolis In-Reply-To: <640A9E7D-B452-4488-B092-E123A08F15BE@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> <640A9E7D-B452-4488-B092-E123A08F15BE@oracle.com> Message-ID: <6fe61598-b4bf-6db2-ba5c-1c1b5351d9ff@redhat.com> Vote: yes >> On Sep 29, 2017, at 10:43 PM, John Rose wrote: >> >> I hereby propose the creation of the Metropolis Project with Vladimir >> Kozlov 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 advanced "Java-on-Java" >> implementation techniques for HotSpot, the OpenJDK implementation of >> the Java virtual machine. Our starting point is earlier proposals [2] >> for using the Graal compiler and AOT static compilation technology to >> replace the HotSpot server compiler, and possibly other components of >> HotSpot. >> >> Vladimir Kozlov is the current HotSpot Group Lead, and the technical >> lead of the Oracle HotSpot compiler group. He has been working on Java >> for over 14 years, focusing on the VM, and making many contributions >> to the OpenJDK. Most recently, he has worked on the implementation of >> the JDK 9 AOT technology. >> >> There will be no defined Reviewers for this project. The initial >> Committers and Authors will include the union of the Committer and >> Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. >> Reviewers and Leads from these projects will be included as Committers >> for Metropolis. Notwithstanding the previous lists, the initial >> committers will also include the following: >> >> * Gavin Bierman >> * Remi Forax >> * Bernd Mathiske >> * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) >> * Yudi Zheng (Graal Author, to be Metropolis Committer) >> >> (Note: We believe it is the case that anyone not named here, who has >> expressed interest in Metropolis, is already a member of the JDK 10 >> Committer list, or one of the other lists mentioned above. If not, >> please send me a reminder, so we can make an adjustment.) >> >> Votes are due by the end of Saturday October 14, 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]. >> >> John Rose >> >> [1] http://openjdk.java.net/projects/#new-project >> [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html >> [3] http://openjdk.java.net/census#members >> [4] http://openjdk.java.net/projects/#new-project-vote >> [5] http://openjdk.java.net/census#graal >> [6] http://openjdk.java.net/census#panama >> [7] http://openjdk.java.net/census#jdk10 From maurizio.cimadamore at oracle.com Mon Oct 2 13:04:46 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 2 Oct 2017 14:04:46 +0100 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: Vote: yes Maurizio On 30/09/17 06:43, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov 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 advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 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]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From magnus.ihse.bursie at oracle.com Mon Oct 2 13:35:14 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 2 Oct 2017 15:35:14 +0200 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: Vote: yes /Magnus On 2017-09-30 07:43, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov 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 advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 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]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From Peter.B.Kessler at Oracle.COM Mon Oct 2 17:28:57 2017 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Mon, 2 Oct 2017 10:28:57 -0700 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: Vote: yes ... peter On 09/29/17 10:43 PM, John Rose wrote: > I hereby propose the creation of the Metropolis Project .... From augustnagro at gmail.com Mon Oct 2 21:25:16 2017 From: augustnagro at gmail.com (August Nagro) Date: Mon, 02 Oct 2017 21:25:16 +0000 Subject: Status of AppCDS Message-ID: Hello, Both Class Data Sharing (CDS) [1] and AppCDS [2] are very interesting but seemingly neglected features of the Java Platform, offering the ability to reduce startup time. Class Data Sharing is the global cache stored in /lib/[arch]/server/classes.jsa, and circumvents long class-loading times by caching the JVM?s internal representation of system jars and memory-mapping them in during startup. The feature's documentation [1] has been updated for Java 9, but I have yet to see a JDK or JRE installation that can use it without manually generating the archive. In every case I've encountered, the file needs to first be created (and given appropriate access permissions) with admin access, and then generated by `java -Xshare:dump`. AppCDS extends the same feature to user libraries. It works well, but has been experimental since (before?) JDK 8 and is commercial. Java has been criticized for its slow startup times. Improvements would enable command line utilities, the realistic use of JShell .jsh scripts (currently takes >4 seconds for hello world on my Mac [3]), and other applications. I'm not sure how *CDS concerts with other OpenJDK efforts like AOT compilation, but it offers the advantage of architecture independency and the ability to be shared across multiple JVMs. Is *CDS doomed for deprecation, or will it be improved? Without work to CDS or changes to AppCDS, the current state is not very usable. Regards, August Nagro [1]: https://docs.oracle.com/javase/9/vm/class-data-sharing.htm [2]: http://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-31503FCE-93D0-4175-9B4F-F6A738B2F4C4 [3]: Executing command `jshell helloworld.jsh`, with file containing ``` System.out.println("hello world"); /exit ``` From kevin.walls at oracle.com Tue Oct 3 08:36:26 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 3 Oct 2017 09:36:26 +0100 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes From kevin.walls at oracle.com Tue Oct 3 08:38:42 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 3 Oct 2017 09:38:42 +0100 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: Vote: yes From james.laskey at oracle.com Tue Oct 3 12:10:38 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 3 Oct 2017 09:10:38 -0300 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: Vote: Yes > On Sep 30, 2017, at 2:43 AM, John Rose wrote: > > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov 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 advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 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]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From Roger.Riggs at Oracle.com Tue Oct 3 14:06:42 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 Oct 2017 10:06:42 -0400 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: <85421a01-03ea-1c94-5573-b88db01e1b78@Oracle.com> Vote: Yes On 9/30/2017 1:43 AM, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov as the Lead and the HotSpot Group as the sponsoring Group. From cthalinger at twitter.com Tue Oct 3 14:33:17 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 3 Oct 2017 07:33:17 -0700 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: <2F699579-95CD-4FA6-B295-FF620F36CC7E@twitter.com> Vote: yes > On Sep 29, 2017, at 10:43 PM, John Rose wrote: > > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov 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 advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 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]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From brent.christian at oracle.com Tue Oct 3 21:45:13 2017 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 3 Oct 2017 14:45:13 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes From dalibor.topic at oracle.com Wed Oct 4 09:06:00 2017 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 4 Oct 2017 11:06:00 +0200 Subject: CFV: New Project: Metropolis In-Reply-To: <20170930104939.359077166@eggemoggin.niobe.net> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> <640A9E7D-B452-4488-B092-E123A08F15BE@oracle.com> <20170930104939.359077166@eggemoggin.niobe.net> Message-ID: <6EECC09B-54BA-4B40-831F-2584F8242EC1@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From jitendra.enania at in.ibm.com Wed Oct 4 09:54:25 2017 From: jitendra.enania at in.ibm.com (Jitendra Singh) Date: Wed, 4 Oct 2017 15:24:25 +0530 Subject: Query regarding support of OpenJDK 8 on linuxppc64le with RHEL 7.2 Message-ID: Hi, I would like to know whether OpenJDK 8 is tested/supported on linuxppc64le with RHEL 7.2 or not ? With Thanks and Regards, Jitendra Singh. From david.holmes at oracle.com Wed Oct 4 10:09:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Oct 2017 20:09:18 +1000 Subject: Query regarding support of OpenJDK 8 on linuxppc64le with RHEL 7.2 In-Reply-To: References: Message-ID: <5e0d5297-3dae-487b-fe3e-cf1dac237a4e@oracle.com> Hi, On 4/10/2017 7:54 PM, Jitendra Singh wrote: > > Hi, > > I would like to know whether OpenJDK 8 is tested/supported on linuxppc64le > with RHEL 7.2 or not ? Probably best to ask on ppc-aix-port-dev at openjdk.java.net Also see: http://cr.openjdk.java.net/%7Esimonis/ppc-aix-port/ https://adoptopenjdk.net/releases.html?variant=openjdk8#ppc64le_linux David ----- > With Thanks and Regards, > Jitendra Singh. > From karen.kinnear at oracle.com Thu Oct 5 19:12:52 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 5 Oct 2017 15:12:52 -0400 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: vote: yes Karen > On Sep 30, 2017, at 1:43 AM, John Rose wrote: > > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov 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 advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 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]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From karen.kinnear at oracle.com Thu Oct 5 19:14:10 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 5 Oct 2017 15:14:10 -0400 Subject: CFV: New Project: JDK In-Reply-To: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> References: <20170926134505.929E8CA2E5@eggemoggin.niobe.net> Message-ID: <96DD9EDF-5C8E-4925-8FCD-BCECCD2F1C7B@oracle.com> vote: yes Karen > On Sep 26, 2017, at 9:45 AM, mark.reinhold at oracle.com wrote: > > I hereby propose the creation of the JDK Project, with me as the Lead and > the Governing Board as the sponsoring Group. > > The goal of this Project will be to produce open-source reference > implementations of the Java SE Platform, to be specified by JSRs in the > Java Community Process. Unlike past JDK Release Projects, which produced > just one feature release and then terminated, this long-running Project > will produce all future JDK feature releases. Per my recent proposal > [1][2] to accelerate the release cadence of the Java SE Platform and the > JDK, this Project will ship a feature release every six months according > to a strict, time-based model. > > The Project's repositories will be initialized from those of the JDK 10 > Project, and that Project will terminate. Features for the release will > be proposed and tracked via the JEP Process [3], as usual. > > The Authors, Committers, and Reviewers of this Project will initially be > those of the JDK 10 Project [4]. I expect the first items of discussion > amongst these contributors to include the schedule for the March 2018 > release and the version-string scheme. > > Votes are due by 17:00 UTC on Tuesday, 10 October [5]. > > Only current OpenJDK Members [6] 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 [7]. > > - Mark > > > [1] https://mreinhold.org/blog/forward-faster > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3] http://openjdk.java.net/jeps > [4] http://openjdk.java.net/census#jdk10 > [5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+JDK+Project+CFV&iso=20171010T1700 > [6] http://openjdk.java.net/census#members > [7] http://openjdk.java.net/projects/#new-project-vote From kumar.x.srinivasan at oracle.com Thu Oct 5 20:57:27 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 05 Oct 2017 13:57:27 -0700 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: <59D69CB7.7080705@oracle.com> Vote: yes On 9/29/2017 10:43 PM, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov 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 advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 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]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From dtrebbien at gmail.com Thu Oct 5 21:27:02 2017 From: dtrebbien at gmail.com (Daniel Trebbien) Date: Thu, 5 Oct 2017 16:27:02 -0500 Subject: Submitting a JEP Message-ID: Hello, I have an idea for enhancing the Java programming language ( https://github.com/dtrebbien/JEP-Unreachable-Assertions ). It is my understanding that in order to change the Java programming language, a JSR will need to be written, but that a good first step is to submit a JDK Enhancement Proposal to gauge support for the idea. I read JEP 1: JDK Enhancement-Proposal & Roadmap Process (http://openjdk.java.net/jeps/1 ) and followed the instructions: I wrote a draft JEP using the template ( http://openjdk.java.net/jeps/2 ) and emailed my Markdown file to "jep dash submit at openjdk dot java dot net", converted back to a valid email address. That was five days ago and I have not received a response. It could very well be that people are busy. I would like to confirm, though, that the emailing procedure is still used now that JEPs are being migrated to the JDK Bug System (http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html ). Is "jep dash submit at openjdk dot java dot net" actively monitored? Daniel From ysr1729 at gmail.com Thu Oct 5 23:21:44 2017 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 5 Oct 2017 16:21:44 -0700 Subject: Group Proposal, for discussion: Vulnerability Group Message-ID: Hi Mark, all -- What's the current status of this group/proposal? What's the process for requesting membership in the group? thanks, -- ramki Ref: http://mail.openjdk.java.net/pipermail/discuss/2017-August/004267.html From ysr1729 at gmail.com Thu Oct 5 23:26:31 2017 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 5 Oct 2017 16:26:31 -0700 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: Vote: yes On Fri, Sep 29, 2017 at 10:43 PM, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov 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 advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK > 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 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]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017- > September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > > From ysr1729 at gmail.com Thu Oct 5 23:30:14 2017 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 5 Oct 2017 16:30:14 -0700 Subject: CFV: New Project: JDK Updates In-Reply-To: <20170927133908.GA6441@vimes> References: <20170927133908.GA6441@vimes> Message-ID: Vote: yes On Wed, Sep 27, 2017 at 6:39 AM, Rob McKenna wrote: > I hereby propose the creation of the "JDK Updates" Project with myself > as the Lead and the Build Group as the sponsoring Group. The goal of > this Project will be to produce JDK Updates on top of the JDK Project > currently under discussion. [1] > > I've been involved as a maintainer of the JDK 8 Updates Project [2] > since Dec 2013 and have been involved with managing all aspects of > a JDK Updates Project. I work as an engineer in the Oracle Java > Platform Group where JDK updates are key for delivering bug fixes > to end users > > This will be a long running project responsible for producing all > future updates to the feature releases. [3] The Project's repositories > will initially be open for select critical bug fixes only. The first > release of this project will focus on the updates for the JDK 9 > Project. [4] > > The initial Authors/Committers/Reviewers will be anyone who holds a > role in the JDK 8 Updates, JDK 9 & JDK 10 projects and has contributed > at least one changeset. The most senior role across those Projects > will be granted in this Project > > Votes are due by 23:59 UTC on October 11th. > > Only current OpenJDK Members [5] 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 [6] > > Regards > > Rob > > [1] http://mail.openjdk.java.net/pipermail/discuss/2017- > September/004281.html > [2] http://openjdk.java.net/projects/jdk8u > [3] http://mail.openjdk.java.net/pipermail/announce/2017- > September/000231.html > [4] http://openjdk.java.net/projects/jdk9 > [5] http://openjdk.java.net/census#members > [6] http://openjdk.java.net/projects/#new-project-vote > > From brian.goetz at oracle.com Fri Oct 6 03:17:28 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 5 Oct 2017 23:17:28 -0400 Subject: Submitting a JEP In-Reply-To: References: Message-ID: <62619bbc-dd39-bb09-3b0d-4dde1671771e@oracle.com> The proposal is a bad fit for the assertion facility, since the assertion facility is designed to be disabled, and what you want is something that can't be disabled. But here's an alternative: ??? throw new UnreachableAssertionException("why"); This doesn't need a language feature.? It doesn't even need a special exception class: ??? throw new AssertionError("Unreachable: blah blah"); Adding language features has a significant cost; we prefer to spend that where there are not practical alternatives. On 10/5/2017 5:27 PM, Daniel Trebbien wrote: > Hello, > > I have an idea for enhancing the Java programming language ( > https://github.com/dtrebbien/JEP-Unreachable-Assertions ). It is my > understanding that in order to change the Java programming language, a JSR > will need to be written, but that a good first step is to submit a JDK > Enhancement Proposal to gauge support for the idea. I read JEP 1: JDK > Enhancement-Proposal & Roadmap Process (http://openjdk.java.net/jeps/1 ) > and followed the instructions: I wrote a draft JEP using the template ( > http://openjdk.java.net/jeps/2 ) and emailed my Markdown file to "jep dash > submit at openjdk dot java dot net", converted back to a valid email > address. > > That was five days ago and I have not received a response. It could very > well be that people are busy. I would like to confirm, though, that the > emailing procedure is still used now that JEPs are being migrated to the > JDK Bug System (http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html ). > > Is "jep dash submit at openjdk dot java dot net" actively monitored? > > Daniel From daniel.fuchs at oracle.com Fri Oct 6 09:20:00 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 6 Oct 2017 10:20:00 +0100 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: <74d3b3aa-2795-f407-f9db-8102ad5cd88a@oracle.com> Vote: yes On 30/09/2017 06:43, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov as the Lead and the HotSpot Group as the sponsoring Group. From david.lloyd at redhat.com Fri Oct 6 12:24:42 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 6 Oct 2017 07:24:42 -0500 Subject: Submitting a JEP In-Reply-To: <62619bbc-dd39-bb09-3b0d-4dde1671771e@oracle.com> References: <62619bbc-dd39-bb09-3b0d-4dde1671771e@oracle.com> Message-ID: On Thu, Oct 5, 2017 at 10:17 PM, Brian Goetz wrote: > The proposal is a bad fit for the assertion facility, since the assertion > facility is designed to be disabled, and what you want is something that > can't be disabled. I believe that in the document, Mr. Trebbien explicitly explained why the assertion facility is a bad fit, and was specifically not suggesting it be used, but rather using it as an example and template for the new feature. > But here's an alternative: > > throw new UnreachableAssertionException("why"); > > This doesn't need a language feature. It does, because you cannot put "throw" statements in places where the compiler has statically determined that control flow cannot reach, which is a key part of the justification of the feature described in the document. This is a feature that I for one have sorely missed for many years now, especially in more complex state-oriented code where exit points cannot be made visually clear. > It doesn't even need a special > exception class: > > throw new AssertionError("Unreachable: blah blah"); > > Adding language features has a significant cost; we prefer to spend that > where there are not practical alternatives. > > > > > On 10/5/2017 5:27 PM, Daniel Trebbien wrote: >> >> Hello, >> >> I have an idea for enhancing the Java programming language ( >> https://github.com/dtrebbien/JEP-Unreachable-Assertions ). It is my >> understanding that in order to change the Java programming language, a JSR >> will need to be written, but that a good first step is to submit a JDK >> Enhancement Proposal to gauge support for the idea. I read JEP 1: JDK >> Enhancement-Proposal & Roadmap Process (http://openjdk.java.net/jeps/1 ) >> and followed the instructions: I wrote a draft JEP using the template ( >> http://openjdk.java.net/jeps/2 ) and emailed my Markdown file to "jep dash >> submit at openjdk dot java dot net", converted back to a valid email >> address. >> >> That was five days ago and I have not received a response. It could very >> well be that people are busy. I would like to confirm, though, that the >> emailing procedure is still used now that JEPs are being migrated to the >> JDK Bug System (http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html ). >> >> Is "jep dash submit at openjdk dot java dot net" actively monitored? >> >> Daniel > > -- - DML From dtrebbien at gmail.com Fri Oct 6 14:30:02 2017 From: dtrebbien at gmail.com (Daniel Trebbien) Date: Fri, 6 Oct 2017 09:30:02 -0500 Subject: Submitting a JEP In-Reply-To: References: <62619bbc-dd39-bb09-3b0d-4dde1671771e@oracle.com> Message-ID: On Fri, Oct 6, 2017 at 7:24 AM, David Lloyd wrote: > On Thu, Oct 5, 2017 at 10:17 PM, Brian Goetz > wrote: > > The proposal is a bad fit for the assertion facility, since the assertion > > facility is designed to be disabled, and what you want is something that > > can't be disabled. > > I believe that in the document, Mr. Trebbien explicitly explained why > the assertion facility is a bad fit, and was specifically not > suggesting it be used, but rather using it as an example and template > for the new feature. > Specifically, in the Alternatives section ( https://github.com/dtrebbien/JEP-Unreachable-Assertions/blob/master/jep.md#alternatives ), I discuss why neither allowing the proposed "unreachable assertions" to be disabled, nor amending ?14.21 Unreachable Statements to allow unreachable `assert false' statements, is preferred. The JLS specifies in ?14.10 that an assertion is either enabled or disabled. However, the JLS does not specify how assertions are enabled or disabled. Unless I am mistaken, there is no standard way to guarantee that assertions compiled into a CLASS file will be disabled at runtime. Therefore, unless the distributor of Java software uses some sort of post-compilation assertion stripping from CLASS files, the programmers must assume that assertions might be enabled at runtime. > But here's an alternative: > > > > throw new UnreachableAssertionException("why"); > > > > This doesn't need a language feature. > > It does, because you cannot put "throw" statements in places where the > compiler has statically determined that control flow cannot reach, > which is a key part of the justification of the feature described in > the document. > > This is a feature that I for one have sorely missed for many years > now, especially in more complex state-oriented code where exit points > cannot be made visually clear. > Yes. ?14.21 Unreachable Statements requires unreachable statements to be compile-time errors, so you currently cannot place a statement like `throw new UnreachableAssertionException("why");' at points defined to be unreachable. From neugens.limasoftware at gmail.com Fri Oct 6 15:14:30 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 6 Oct 2017 17:14:30 +0200 Subject: Submitting a JEP In-Reply-To: References: <62619bbc-dd39-bb09-3b0d-4dde1671771e@oracle.com> Message-ID: I'm reading the proposal a bit and I don't think it's a very good idea to introduce another keyword. While it may be nice to have such statement, effectively you are promoting bad programming use cases. If we take the stack overflow link as an example, it's clear that the developer could simply rearrange his code to be more stable by using some of the advanced features of Java like classes and inheritance ;) or at worse by just documenting the need to add the return after the else branch In all the other examples you give in the proposal, unless I'm misreading them, it seem that they are not unreachable statements in a sense that can the statically defined, but are simply cases that the developer "knows" they won't happen, but they may, and so they can be solved by an assert or by a runtime exception. So the only use case I see is the stack overflow one, but it seems to me this is just bad code practices, which is branching points with multiple return statements, that is always asking for troubles. In the short term future we will get enhanced switches with patterns, which turns switches into expression, and it makes the stack overflow example a lot easier to write without side effects. Cheers, Mario 2017-10-06 16:30 GMT+02:00 Daniel Trebbien : > On Fri, Oct 6, 2017 at 7:24 AM, David Lloyd wrote: > >> On Thu, Oct 5, 2017 at 10:17 PM, Brian Goetz >> wrote: >> > The proposal is a bad fit for the assertion facility, since the assertion >> > facility is designed to be disabled, and what you want is something that >> > can't be disabled. >> >> I believe that in the document, Mr. Trebbien explicitly explained why >> the assertion facility is a bad fit, and was specifically not >> suggesting it be used, but rather using it as an example and template >> for the new feature. >> > > Specifically, in the Alternatives section ( > https://github.com/dtrebbien/JEP-Unreachable-Assertions/blob/master/jep.md#alternatives > ), I discuss why neither allowing the proposed "unreachable assertions" to > be disabled, nor amending ?14.21 Unreachable Statements to allow > unreachable `assert false' statements, is preferred. > > The JLS specifies in ?14.10 that an assertion is either enabled or > disabled. However, the JLS does not specify how assertions are enabled or > disabled. > > Unless I am mistaken, there is no standard way to guarantee that assertions > compiled into a CLASS file will be disabled at runtime. Therefore, unless > the distributor of Java software uses some sort of post-compilation > assertion stripping from CLASS files, the programmers must assume that > assertions might be enabled at runtime. > >> But here's an alternative: >> > >> > throw new UnreachableAssertionException("why"); >> > >> > This doesn't need a language feature. >> >> It does, because you cannot put "throw" statements in places where the >> compiler has statically determined that control flow cannot reach, >> which is a key part of the justification of the feature described in >> the document. >> >> This is a feature that I for one have sorely missed for many years >> now, especially in more complex state-oriented code where exit points >> cannot be made visually clear. >> > > Yes. ?14.21 Unreachable Statements requires unreachable statements to be > compile-time errors, so you currently cannot place a statement like `throw > new UnreachableAssertionException("why");' at points defined to be > unreachable. -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From david.lloyd at redhat.com Fri Oct 6 15:45:41 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 6 Oct 2017 10:45:41 -0500 Subject: Submitting a JEP In-Reply-To: References: <62619bbc-dd39-bb09-3b0d-4dde1671771e@oracle.com> Message-ID: On Fri, Oct 6, 2017 at 10:14 AM, Mario Torre wrote: > I'm reading the proposal a bit and I don't think it's a very good idea > to introduce another keyword. > > While it may be nice to have such statement, effectively you are > promoting bad programming use cases. I disagree. The use case for this *construct* (I say "construct" because it doesn't have to be a statement, and really that's bikeshedding at this point) is where the code in question is complex, not necessarily because it is done "badly" but because there is no other reasonable choice. Yes you can replace a switch statement with a class hierarchy, but what if that increases your code size from 100s of K to 1000s? What if you're writing something for a small environment (embedded or cloud) where code density is important? What if you're writing a DFA like this one [1] (note how my throw must be commented out here) where introducing inheritance or other "proper OO" techniques would increase complexity and decrease performance beyond an acceptable margin? It is not realistic to assume that all code should be structured in one way, or that inheritance is always an option; there is no programming language yet for which this kind of assumption is reasonable. In Java in particular, such compromises are and always will be necessary. You cannot establish the requirements for the size and shape of the output based on enforcing certain coding techniques and tools; instead you must choose the techniques and tools which allow you to meet the requirements of your software. Java is still a procedural language no matter how much we might wish to pretend otherwise, and procedural languages are subject to certain realities and constraints. This construct eases one such constraint and would result in better code, not worse. Consider for example that your IDE of choice could highlight locations where unreachability is asserted, yet static analysis shows that reaching the code is possible. In this case the user would be inclined to document why the condition is actually unreachable, which only helps maintainability down the road. [1] https://github.com/wildfly/wildfly-common/blob/master/src/main/java/org/wildfly/common/expression/Expression.java#L376 -- - DML From dtrebbien at gmail.com Fri Oct 6 17:15:37 2017 From: dtrebbien at gmail.com (Daniel Trebbien) Date: Fri, 6 Oct 2017 12:15:37 -0500 Subject: Submitting a JEP In-Reply-To: References: <62619bbc-dd39-bb09-3b0d-4dde1671771e@oracle.com> Message-ID: On Fri, Oct 6, 2017 at 10:14 AM, Mario Torre wrote: > I'm reading the proposal a bit and I don't think it's a very good idea > to introduce another keyword. > > While it may be nice to have such statement, effectively you are > promoting bad programming use cases. > > If we take the stack overflow link as an example, it's clear that the > developer could simply rearrange his code to be more stable by using > some of the advanced features of Java like classes and inheritance ;) > or at worse by just documenting the need to add the return after the > else branch > This wasn't explicitly stated in my proposal, but I am the one who asked the question on Stack Overflow. In my case, the code in question (part of my SLF4J Helper plugin for NetBeans IDE; http://plugins.netbeans.org/plugin/72557/slf4j-helper ) performs static analysis of Java code through its representation as Java compiler tree object hierarchies and javax.lang.model types. It is not particularly easy programming because I have to try to understand and handle without exception every possible object hierarchy representing an expression tree that the plugin might see in attempting to analyze some piece of Java code. This is complicated by things like ErroneousTree ( https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/ErroneousTree.html ) and ErrorType ( https://docs.oracle.com/javase/8/docs/api/javax/lang/model/type/ErrorType.html ) whose existence implies to me that the object hierarchies that my plugin could encounter might not even correspond to well-formed code. If all branches of the if-else if-else chain ended with a return statement, then you're right that I could factor out that code into a helper method and return the result of calling that helper method in the switch case. But, not all branches return something. Some branches continue or break an enclosing loop, for example. I do have comments explaining the need to prevent fall-through. This is not a very nice solution, however, because like Mr. Lloyd's DFA parsing example, the code does not fit on one screen. So, I could duplicate the comments at the top and bottom, but still not see them depending on where I am in the code. > > In all the other examples you give in the proposal, unless I'm > misreading them, it seem that they are not unreachable statements in a > sense that can the statically defined, but are simply cases that the > developer "knows" they won't happen, but they may, and so they can be > solved by an assert or by a runtime exception. > > So the only use case I see is the stack overflow one, but it seems to > me this is just bad code practices, which is branching points with > multiple return statements, that is always asking for troubles. > > In the short term future we will get enhanced switches with patterns, > which turns switches into expression, and it makes the stack overflow > example a lot easier to write without side effects. This seems like Rust's pattern matching. Practically everything in Rust can be used as an expression, including `match', which is similar to the `switch' statement in Java. For example, here is some Rust code that I wrote to parse Valgrind suppression files: https://github.com/dtrebbien/valgrind-rs/blob/4b26c6f/src/lib.rs#L196 This updates the parsing state based on the result of `match' on the current parsing state. While nifty, I don't think "expression switches" would address the problem. From sanhong.lsh at alibaba-inc.com Mon Oct 9 12:26:18 2017 From: sanhong.lsh at alibaba-inc.com (=?UTF-8?B?5p2O5LiJ57qiKOS4iee6oik=?=) Date: Mon, 09 Oct 2017 20:26:18 +0800 Subject: Call for Discussion: New Project: Loom Message-ID: <012d01d340f9$ceeae010$6cc0a030$@alibaba-inc.com> Hi Ron, I are very excited about this proposal to add lightweight threads to Java. As I have talked at JVMLS [1], our own customized OpenJDK version has implemented some similar mechanism proposed by loom(we called this as Wisp internally), which is already widely deployed in Alibaba production environment. A couple of core ecommerce applications (running in very large scale cluster) are running on top of Wisp. By this way, we achieved 10+% CPU saving, lots of thread context switches could be reduced by transferring from thread to coroutine. More specifically, our implementation is relying on the continuation primitive support made by [2] , which is part of MLVM project. Moreover, we added our own scheduler(fully written in Java) to support coroutine yielding at almost all possibly blocked places in OpenJDK, including: - Java synchronization(compiled & runtime code change) - J.U.C - Java network IO - Java disk IO Our goal is to allow Java developers to write in synchronous but gain performance of asynchronous for free, they just change a couple of line of code and do some parameter configuration, the control transferring between coroutines is totally handled by underlying JDK transparently. We are interested in contributing to this project. [1]: https://www.slideshare.net/sherrylso/optimizing-jvm-at-alibaba-for-ecommerce -apps-running-on-100000-servers [2]: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/4cd7d914b0e3/coro-simple.p atch From stuart.marks at oracle.com Tue Oct 10 23:56:14 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 10 Oct 2017 16:56:14 -0700 Subject: CFV: New Project: Metropolis In-Reply-To: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> References: <16B1ECA1-1504-4CBE-A7A8-E0D8F551E2F5@oracle.com> Message-ID: Vote: yes On 9/29/17 10:43 PM, John Rose wrote: > I hereby propose the creation of the Metropolis Project with Vladimir > Kozlov 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 advanced "Java-on-Java" > implementation techniques for HotSpot, the OpenJDK implementation of > the Java virtual machine. Our starting point is earlier proposals [2] > for using the Graal compiler and AOT static compilation technology to > replace the HotSpot server compiler, and possibly other components of > HotSpot. > > Vladimir Kozlov is the current HotSpot Group Lead, and the technical > lead of the Oracle HotSpot compiler group. He has been working on Java > for over 14 years, focusing on the VM, and making many contributions > to the OpenJDK. Most recently, he has worked on the implementation of > the JDK 9 AOT technology. > > There will be no defined Reviewers for this project. The initial > Committers and Authors will include the union of the Committer and > Author sets from the following projects: Graal[5], Panama[6], and JDK 10[7]. > Reviewers and Leads from these projects will be included as Committers > for Metropolis. Notwithstanding the previous lists, the initial > committers will also include the following: > > * Gavin Bierman > * Remi Forax > * Bernd Mathiske > * Ekaterina Pavlova (JDK 10 Author, to be Metropolis Committer) > * Yudi Zheng (Graal Author, to be Metropolis Committer) > > (Note: We believe it is the case that anyone not named here, who has > expressed interest in Metropolis, is already a member of the JDK 10 > Committer list, or one of the other lists mentioned above. If not, > please send me a reminder, so we can make an adjustment.) > > Votes are due by the end of Saturday October 14, 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]. > > John Rose > > [1] http://openjdk.java.net/projects/#new-project > [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004343.html > [3] http://openjdk.java.net/census#members > [4] http://openjdk.java.net/projects/#new-project-vote > [5] http://openjdk.java.net/census#graal > [6] http://openjdk.java.net/census#panama > [7] http://openjdk.java.net/census#jdk10 > From gnu.andrew at redhat.com Wed Oct 11 15:59:12 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 11 Oct 2017 16:59:12 +0100 Subject: Open source TCK was: JDK 9: General Availability In-Reply-To: <6133525e-b684-2587-2a9b-8a235e1cc364@redhat.com> References: <6133525e-b684-2587-2a9b-8a235e1cc364@redhat.com> Message-ID: On 24 September 2017 at 07:46, Andrew Haley wrote: > On 24/09/17 00:51, David Herron wrote: >> You make a compelling case and I largely agree with the goal of "open >> sourcing" the TCK's. Doing so would go a long way towards truly opening >> the OpenJDK project. >> >> There is a practical question regarding the primary use for the >> TCK's - which is to certify compliance with the specifications. >> >> An open source software project is free to be downloaded, modified, >> and the modified version distributed at will. > > Not necessarily: there are variants of free licences which don't > permit some sections to be changed. But it doesn't really matter what > licence is used for the TCK itself: the Java Compatible badge would be > reserved for implementations which had passed TCK Version n.n, as > posted at java.net. That would be the canonical one true TCK. Sure, > people would be able to hack their own copies of the TCK, but what > would be the point? The purpose of passing the TCK is to ensure > compatibility with other implementations. There isn't any motive to > claim compliance with a private version of the TCK. > I tend to agree with Andrew on this. Passing the TCK is already a process based more on trust than source code licensing. It is taken as part of making such an assertion that the TCK is being run as shipped with only approved exclusions. On the other hand, I think trust in the TCK itself could be improved by making the source code public. Only then is it possible for anyone to verify that the TCK is testing against the specification, rather than a particular implementation. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Oct 11 17:48:19 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 11 Oct 2017 19:48:19 +0200 Subject: An impassioned plea on version numbers In-Reply-To: References: Message-ID: <981f906b-c9f2-1029-b619-34987d0c070e@redhat.com> On 09/22/2017 08:04 PM, Stephen Colebourne wrote: > I propose that versions should simply increase incrementally. > March 2018 - v10 > September 2018 - v11 > March 2019 - v12 > September 2019 - v13 Yes, that makes more sense than year.month. Maybe x.y.z semver-like scheme is better, and 9.0 already fits there. I have been living with the proposed scheme in my mind, on the off-chance the novelty of it displeases me, but no, it does not bode well. Quick! What is the version of the next LTS release? And the one after that? Can you do it without a chart? Actually, I can't even do that for Ubuntu. I have to remember that Ubuntu 16.04 is LTS, not the 16.10. But I did downloaded and installed some Ubuntu images only much later realizing they were not LTS, because those minor numbers are different. Remembering that only e.g. Java 8.*, and Java 10.*, and Java 12.* are LTSes would be much, much easier. Another perspective: current proposal answers "when the JDK was released", which is not the same as "what the JDK is". It might appear easier for JDK developers who have JDK roadmaps firmly committed in their heads, but not for ordinary folks. Mark promised a more substantial reply after JavaOne. No pressure ;) Thanks, -Aleksey From gnu.andrew at redhat.com Wed Oct 11 21:59:49 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 11 Oct 2017 22:59:49 +0100 Subject: Query regarding support of OpenJDK 8 on linuxppc64le with RHEL 7.2 In-Reply-To: <5e0d5297-3dae-487b-fe3e-cf1dac237a4e@oracle.com> References: <5e0d5297-3dae-487b-fe3e-cf1dac237a4e@oracle.com> Message-ID: On 4 October 2017 at 11:09, David Holmes wrote: > Hi, > > On 4/10/2017 7:54 PM, Jitendra Singh wrote: >> >> >> Hi, >> >> I would like to know whether OpenJDK 8 is tested/supported on linuxppc64le >> with RHEL 7.2 or not ? > > > Probably best to ask on ppc-aix-port-dev at openjdk.java.net > > Also see: > > http://cr.openjdk.java.net/%7Esimonis/ppc-aix-port/ > https://adoptopenjdk.net/releases.html?variant=openjdk8#ppc64le_linux > > David > ----- > > > >> With Thanks and Regards, >> Jitendra Singh. >> > Yes, you can install it via: # yum install java-1.8.0-openjdk Note that the latest versions are only available on the latest version of RHEL 7, 7.4, so you should strongly consider upgrading to that version. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From peter.lawrey at gmail.com Thu Oct 12 05:22:18 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Thu, 12 Oct 2017 06:22:18 +0100 Subject: An impassioned plea on version numbers In-Reply-To: <981f906b-c9f2-1029-b619-34987d0c070e@redhat.com> References: <981f906b-c9f2-1029-b619-34987d0c070e@redhat.com> Message-ID: I favour the version of Java to change when there is a break in backward compability in the Java language. Ie code written for 18.3 wont compile on 9 if var is used. Bumping the major version without a major changing in the spec conveys less information imho. I would favour Java spec version counter.date of release. Unless the plan is to break backward compatability every 6 months assuming you utilise the latest language featues. I guess the question is if you don't know when a java language spec might change but you want to announce version numbers years in advance and stick to them. Thus the intent is not to imply anything by the version number other than a date. Regards Peter. On 11 Oct. 2017 6:49 pm, "Aleksey Shipilev" wrote: > On 09/22/2017 08:04 PM, Stephen Colebourne wrote: > > I propose that versions should simply increase incrementally. > > March 2018 - v10 > > September 2018 - v11 > > March 2019 - v12 > > September 2019 - v13 > > Yes, that makes more sense than year.month. Maybe x.y.z semver-like scheme > is better, and 9.0 > already fits there. I have been living with the proposed scheme in my > mind, on the off-chance the > novelty of it displeases me, but no, it does not bode well. Quick! What is > the version of the next > LTS release? And the one after that? Can you do it without a chart? > > Actually, I can't even do that for Ubuntu. I have to remember that Ubuntu > 16.04 is LTS, not the > 16.10. But I did downloaded and installed some Ubuntu images only much > later realizing they were not > LTS, because those minor numbers are different. Remembering that only e.g. > Java 8.*, and Java 10.*, > and Java 12.* are LTSes would be much, much easier. > > Another perspective: current proposal answers "when the JDK was released", > which is not the same as > "what the JDK is". It might appear easier for JDK developers who have JDK > roadmaps firmly committed > in their heads, but not for ordinary folks. > > Mark promised a more substantial reply after JavaOne. No pressure ;) > > Thanks, > -Aleksey > > From volker.simonis at gmail.com Thu Oct 12 07:38:54 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 Oct 2017 09:38:54 +0200 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> <20170824141617.454386468@eggemoggin.niobe.net> Message-ID: Hi, what's the current status of this group/proposal? Can you please at least post a final version of the "OPENJDK VULNERABILITY GROUP NONDISCLOSURE AND LICENSE AGREEMENT"? The one you cite (http://cr.openjdk.java.net/~mr/ojvg/ojvg-ndla-draft-2017-01-23.pdf) is still marked as "Draft". I really want to get this agreement signed by my employer but I'm currently stuck because it makes little sense to sign a draft document. Thank you and best regards, Volker On Tue, Sep 5, 2017 at 8:38 PM, Martijn Verburg wrote: > Hi Mark, > > Apologies for the radio silence. I was going to suggest edits de-emphasising > Oracle's leadership / central role in this group, not because Oracle > doesn't deserve to or have the right to lead, but more that I wanted to see > the principles of shared vulnerability ownership (across all the vendors) > front and center in the proposal. > > After a careful re-read of the doc I've realised that my impression was > plain wrong and that the shared ownership is very much advocated. > > Thanks again for proposing this important group, it's really good to see! > > > > Cheers, > Martijn > > On 24 August 2017 at 22:16, wrote: > >> 2017/8/24 10:33:41 -0700, martijnverburg at gmail.com: >> > Totally applaud this idea! I have some suggested wording changes that >> > might be easiest to suggest as a diff or some sort of track changes on >> the >> > original text. Do you have a preferred mechanism for that type of >> feedback? >> >> If you'd like to propose a patch, I've posted the Markdown source here: >> >> http://cr.openjdk.java.net/~mr/ojvg/ojvg.md >> >> - Mark >> From daniel.latremoliere at gmail.com Thu Oct 12 15:48:36 2017 From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=) Date: Thu, 12 Oct 2017 17:48:36 +0200 Subject: An impassioned plea on version numbers In-Reply-To: References: <20170925065651.77408868@eggemoggin.niobe.net> Message-ID: <4abcb7a8-6b95-7867-01e5-b9467857df3b@gmail.com> Another possibility (more developer-friendly in my opinion) could be: * increase minor version with each feature release (currently expected each six months). * increase major version / reinit minor version with each core feature removal [1] (e.g. serialization, finalizers). My two cents, Daniel. [1]: Never say never. From cnewland at chrisnewland.com Thu Oct 12 22:20:16 2017 From: cnewland at chrisnewland.com (Chris Newland) Date: Thu, 12 Oct 2017 23:20:16 +0100 Subject: An impassioned plea on version numbers In-Reply-To: References: <981f906b-c9f2-1029-b619-34987d0c070e@redhat.com> Message-ID: <73652c4489db9890ea6b661c70e8e8fe.squirrel@excalibur.xssl.net> +1 to this suggestion of spec.date Regarding https://twitter.com/rafaelcodes/status/905474910599905280 I would appreciate if there was a published mapping between the external release version and the various internal version numbers; Class file version HotSpot version (to identify log formats) Security baseline Ideally (imho) these would increment only when there was an external effect that tools needed to know about. Kind regards, Chris -- @chriswhocodes | https://github.com/AdoptOpenJDK/jitwatch On Thu, October 12, 2017 06:22, Peter Lawrey wrote: > I favour the version of Java to change when there is a break in backward > compability in the Java language. Ie code written for 18.3 wont compile on > 9 if var is used. Bumping the major version without a major changing in > the spec conveys less information imho. > > I would favour > > > Java spec version counter.date of release. > > > Unless the plan is to break backward compatability every 6 months > assuming you utilise the latest language featues. > > I guess the question is if you don't know when a java language spec might > change but you want to announce version numbers years in advance and > stick to them. Thus the intent is not to imply anything by the version > number other than a date. > > Regards Peter. > > > On 11 Oct. 2017 6:49 pm, "Aleksey Shipilev" wrote: > > >> On 09/22/2017 08:04 PM, Stephen Colebourne wrote: >> >>> I propose that versions should simply increase incrementally. >>> March 2018 - v10 >>> September 2018 - v11 >>> March 2019 - v12 >>> September 2019 - v13 >>> >> >> Yes, that makes more sense than year.month. Maybe x.y.z semver-like >> scheme is better, and 9.0 already fits there. I have been living with the >> proposed scheme in my mind, on the off-chance the novelty of it >> displeases me, but no, it does not bode well. Quick! What is the version >> of the next LTS release? And the one after that? Can you do it without a >> chart? >> >> Actually, I can't even do that for Ubuntu. I have to remember that >> Ubuntu >> 16.04 is LTS, not the >> 16.10. But I did downloaded and installed some Ubuntu images only much >> later realizing they were not LTS, because those minor numbers are >> different. Remembering that only e.g. Java 8.*, and Java 10.*, >> and Java 12.* are LTSes would be much, much easier. >> >> Another perspective: current proposal answers "when the JDK was >> released", which is not the same as "what the JDK is". It might appear >> easier for JDK developers who have JDK roadmaps firmly committed in their >> heads, but not for ordinary folks. >> >> Mark promised a more substantial reply after JavaOne. No pressure ;) >> >> >> Thanks, >> -Aleksey >> >> >> > From mark.reinhold at oracle.com Fri Oct 13 00:48:02 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Oct 2017 17:48:02 -0700 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> <20170824141617.454386468@eggemoggin.niobe.net> Message-ID: <20171012174802.149720830@eggemoggin.niobe.net> 2017/10/12 0:38:54 -0700, volker.simonis at gmail.com: > what's the current status of this group/proposal? We've been a bit, um, busy with other activities over the past few weeks. The status is that most people are happy with the proposal at a high level, but based on feedback we need to make a few minor revisions to the NDA/license document. That will necessarily involve lawyers, so it will take a bit of time, and I know better than to try to predict how much time. I'll let you know more when I know more. - Mark From ysr1729 at gmail.com Fri Oct 13 18:03:20 2017 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 13 Oct 2017 11:03:20 -0700 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: <20171012174802.149720830@eggemoggin.niobe.net> References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> <20170824141617.454386468@eggemoggin.niobe.net> <20171012174802.149720830@eggemoggin.niobe.net> Message-ID: Thanks Mark. What's the process & timeframe for obtaining membership to the group (presumably after the revised version of the document is out?). -- ramki On Thu, Oct 12, 2017 at 5:48 PM, wrote: > 2017/10/12 0:38:54 -0700, volker.simonis at gmail.com: > > what's the current status of this group/proposal? > > We've been a bit, um, busy with other activities over the past few > weeks. > > The status is that most people are happy with the proposal at a high > level, but based on feedback we need to make a few minor revisions to > the NDA/license document. That will necessarily involve lawyers, so > it will take a bit of time, and I know better than to try to predict > how much time. I'll let you know more when I know more. > > - Mark > From volker.simonis at gmail.com Sat Oct 14 07:17:21 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 14 Oct 2017 07:17:21 +0000 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> <20170824141617.454386468@eggemoggin.niobe.net> <20171012174802.149720830@eggemoggin.niobe.net> Message-ID: Srinivas Ramakrishna schrieb am Fr. 13. Okt. 2017 um 20:03: > Thanks Mark. > > What's the process & timeframe for obtaining membership to the group > (presumably after the revised version of the document is out?). > Hi Ramki, As far as I know this is still all TBD and to be decided and there's nothing you or I could do except asking from time to time :) Regards, Volker > -- ramki > > On Thu, Oct 12, 2017 at 5:48 PM, wrote: > >> 2017/10/12 0:38:54 -0700, volker.simonis at gmail.com: >> > what's the current status of this group/proposal? >> >> We've been a bit, um, busy with other activities over the past few >> weeks. >> >> The status is that most people are happy with the proposal at a high >> level, but based on feedback we need to make a few minor revisions to >> the NDA/license document. That will necessarily involve lawyers, so >> it will take a bit of time, and I know better than to try to predict >> how much time. I'll let you know more when I know more. >> >> - Mark >> > > From mark.reinhold at oracle.com Mon Oct 16 14:10:44 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 16 Oct 2017 07:10:44 -0700 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> <20170824141617.454386468@eggemoggin.niobe.net> <20171012174802.149720830@eggemoggin.niobe.net> Message-ID: <20171016071044.959448477@eggemoggin.niobe.net> 2017/10/13 11:03:20 -0700, ysr1729 at gmail.com: > What's the process & timeframe for obtaining membership to the group > (presumably after the revised version of the document is out?). http://cr.openjdk.java.net/~mr/ojvg/#membership - Mark From neugens.limasoftware at gmail.com Mon Oct 16 15:43:00 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 16 Oct 2017 17:43:00 +0200 Subject: Free Java Dev Room Call For Participation Message-ID: We are pleased to announce the Call for Participation in the FOSDEM 2018 Free Java DevRoom! This year FOSDEM Free Java DevRoom will be on Saturday the 3th of February 2018 in Bruxelles, Belgium, with the usual events and meetings surrounding the main show on Friday, Saturday and Sunday on that weekend; please, refer to the FOSDEM website for the schedule of the whole event: https://fosdem.org/ The Free Java DevRoom has become unique in that it has attracted hackers from very different Free Software Java projects, giving the opportunity to bring together companies of various sizes, different project communities, mainstream core Java developers, alternative Java language implementations and runtimes, and everything that form the Free Java Universe, everybody participating to share their knowledge in an atmosphere of cooperation and friendly competition. The Java Community has never been more vibrant than now, and it's moving faster and is more modular than ever: a real "Jigsaw Falling Into Place" and back together into a perfect picture! Those are indeed very exciting times, and we are all part of it! So, come and share your experiences at the Java Dev Room at FOSDEM! As always, check out our wiki for more details on the conference: https://wiki.debian.org/Java/DevJam/2018/Fosdem And join the Free Java DevoRoom mailing list [java-devroom at lists.fosdem.org]: https://lists.fosdem.org/listinfo/java-devroom *** IMPORTANT *** Fosdem organisers have expressed the desire to record and stream everything, and like every year we will do our best to record the sessions by default. We will use the same format as last year, so please submit one (or more) 25 minute talk proposal(s) by the 1st of December 2017, 23.59 CET on the mailing list. We will also select a small number of 45 minutes talk. If you wish to submit a 45 minutes talk please state this in the proposal, all proposals will be considered to be of 25 minute by default otherwise. A template for submitting a talk can be found at: http://wiki.debian.org/Java/DevJam/2016/Fosdem/CallForParticipation Tracks will be announced around 10th of December on the mailing list. Please join us! --The Free Java DevRoom Committee -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From volker.simonis at gmail.com Tue Oct 17 14:05:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 17 Oct 2017 16:05:18 +0200 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: <20171016071044.959448477@eggemoggin.niobe.net> References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> <20170824141617.454386468@eggemoggin.niobe.net> <20171012174802.149720830@eggemoggin.niobe.net> <20171016071044.959448477@eggemoggin.niobe.net> Message-ID: Hi Mark, while our legal team reviewed the Vulnerability Group proposal, they complained that the term "rough consensus" is never defined, neither in the Vulnerability Group proposal nor in the OpenJDK Bylaws. Would it be possible to rephrase "rough consensus" as "lazy consensus" which is defined in the Bylaws? I understand that in the Bylaws, "lazy consensus" is defined with respect to voting and we don't want to have a vote for every decision but on the other hand, the definition of "lazy consensus" as "not having any veto" seems appropriate to me in the context where "rough consensus" is currently being used in the Vulnerability Group proposal. If that's is not possible, the Vulnerability Group proposal should define in more detail what it means by "rough consensus". Thank you and best regards, Volker On Mon, Oct 16, 2017 at 4:10 PM, wrote: > 2017/10/13 11:03:20 -0700, ysr1729 at gmail.com: >> What's the process & timeframe for obtaining membership to the group >> (presumably after the revised version of the document is out?). > > http://cr.openjdk.java.net/~mr/ojvg/#membership > > - Mark From mark.reinhold at oracle.com Thu Oct 19 15:10:19 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Oct 2017 08:10:19 -0700 Subject: An impassioned plea on version numbers In-Reply-To: <20170925065651.77408868@eggemoggin.niobe.net> References: <20170925065651.77408868@eggemoggin.niobe.net> Message-ID: <20171019081019.249708643@eggemoggin.niobe.net> 2017/9/25 6:56:51 -0700, mark.reinhold at oracle.com: > 2017/9/22 11:04:05 -0700, Stephen Colebourne : >> While I am super happy to see Java 9 released I remain strongly opposed to >> the proposed version number scheme from now on. Here is why: >> >> ... > > Thanks for your impassioned plea. You make some reasonable arguments. > I'll reply at length after JavaOne. I've replied over on the jdk-dev list: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html I suggest we continue the discussion there, rather than here. - Mark From hohensee at amazon.com Thu Oct 19 18:22:25 2017 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 19 Oct 2017 18:22:25 +0000 Subject: Accelerating the JDK release cadence In-Reply-To: <558a0322-6a73-74ca-a71f-32a35878a3b0@redhat.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> <558a0322-6a73-74ca-a71f-32a35878a3b0@redhat.com> Message-ID: We at Amazon are interested in whether or not there will be longer term support CPUs for both 6-month (hereinafter termed ?feature?) and LTS releases, primarily to support transitions from one release to the next. The current proposal implies a transition period of three months (the overlap between the lifetimes of a release and the last CPU for the previous release). We?re used to thinking in terms of a year?s worth of overlap, which would mean five CPUs for feature and fifteen for LTS releases rather than respectively two and eleven. Questions: 1. How long will the CPU cycles be for both feature and LTS releases? 2. Will Oracle push the source for all CPUs to OpenJDK upon release? 3. Would the community (perhaps the Adoption project) be able/allowed to produce additional ?sanctioned? CPUs via backports from LTS and later feature release CPUs? Note that our understanding is that JDKs 9 and 18.3 are both feature releases, thus the LTS release previous to JDK 18.9 is JDK 8. If there were a year?s worth of CPU overlap between LTS releases, that would mean support for JDK 8 would end in September 2019. A three-month transition time will make it difficult to adopt the feature release train in production. That would mean no production use or adoption of both JDKs 9 and 18.3. Thanks, Paul On 9/24/17, 12:06 AM, "discuss on behalf of Andrew Haley" wrote: On 22/09/17 17:02, Volker Simonis wrote: > On Fri, Sep 22, 2017 at 5:49 PM, Andrew Haley wrote: >> On 22/09/17 15:34, Volker Simonis wrote: >>> Hi Mark, >>> >>> can you please detail what the statements from your blog regarding the >>> LTS releases means for the OpenJDK: >>> >>> "Every three years, start?ing in Sep?tem?ber of 2018, the fea?ture >>> re?lease will be a long-term sup?port re?lease. Up?dates for these >>> re?leases will be avail?able for at least three years and quite >>> pos?si?bly longer, de?pend?ing upon your ven?dor." >>> >>> Does this mean that Oracle will provide updates for the LTS versions >>> in the OpenJDK for at least three years? According to the "Oracle Java >>> SE Support Roadmap" [1] Oracle plans to offer much longer support time >>> frames for LTS releases. How is this going to work. Will Oracle step >>> back as lead of the corresponding LTS update projects after three >>> years (much as this was done for jdk7u for example) and leave the >>> project up to the community while doing its own LTS support from >>> private repos? >> >> That is pretty how it works now. > > Yes, but I think jdk7 was supported nearly 5 years by Oracle while > 18.9 maybe only three years? August 2011 was the jdk7 GA, and Oracle EOL'd it April 2015. Three years, eight months. >> While it'll be a PITA to handle >> divergent repos, we do know how to do it. > > Especially because there will be new releases every six month so it > will potentially become harder to identify and downport security and > bug fixes from an increasing number of new release branches. I don't think that the porting will be especially onerous. The six- monthly releases won't live for very long and won't differ from each other very much, so backports will hopefully be a NOP. I can't immediately see any motivation for anyone to want to do long-term support on a six-monthly release, but if they really want to that's up to them. Fedora EOL happens one month after the GA of the next-but-one release, and I'd expect Java to be the same. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Oct 19 20:41:58 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Oct 2017 21:41:58 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> <558a0322-6a73-74ca-a71f-32a35878a3b0@redhat.com> Message-ID: <9289cad4-d0fe-0c1d-d366-875eb35bde64@redhat.com> On 19/10/17 19:22, Hohensee, Paul wrote: > 1. How long will the CPU cycles be for both feature and LTS releases? > 2. Will Oracle push the source for all CPUs to OpenJDK upon release? > 3. Would the community (perhaps the Adoption project) be > able/allowed to produce additional ?sanctioned? CPUs via backports > from LTS and later feature release CPUs? IMO this is the wrong way of thinking about it. We're creating the Vulnerability Group, which will be responsible for much of the work of creating the update. We will be able to create updates for any release we want. However, there's no way that we're going to be able to create and back-ports for very many minor releases. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Thu Oct 19 20:56:49 2017 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 19 Oct 2017 20:56:49 +0000 Subject: Accelerating the JDK release cadence In-Reply-To: <9289cad4-d0fe-0c1d-d366-875eb35bde64@redhat.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> <558a0322-6a73-74ca-a71f-32a35878a3b0@redhat.com> <9289cad4-d0fe-0c1d-d366-875eb35bde64@redhat.com> Message-ID: <46CEB190-E8DA-4C3D-AAEC-5247818F5958@amazon.com> What are the constraints on doing so? On 10/19/17, 1:42 PM, "Andrew Haley" wrote: On 19/10/17 19:22, Hohensee, Paul wrote: > 1. How long will the CPU cycles be for both feature and LTS releases? > 2. Will Oracle push the source for all CPUs to OpenJDK upon release? > 3. Would the community (perhaps the Adoption project) be > able/allowed to produce additional ?sanctioned? CPUs via backports > from LTS and later feature release CPUs? IMO this is the wrong way of thinking about it. We're creating the Vulnerability Group, which will be responsible for much of the work of creating the update. We will be able to create updates for any release we want. However, there's no way that we're going to be able to create and back-ports for very many minor releases. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Oct 19 21:09:44 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Oct 2017 22:09:44 +0100 Subject: Accelerating the JDK release cadence In-Reply-To: <46CEB190-E8DA-4C3D-AAEC-5247818F5958@amazon.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> <558a0322-6a73-74ca-a71f-32a35878a3b0@redhat.com> <9289cad4-d0fe-0c1d-d366-875eb35bde64@redhat.com> <46CEB190-E8DA-4C3D-AAEC-5247818F5958@amazon.com> Message-ID: <8d779f26-5bc6-4668-9283-3fa0942a0095@redhat.com> On 19/10/17 21:56, Hohensee, Paul wrote: > What are the constraints on doing so? Skilled labour; opportunity cost. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bourges.laurent at gmail.com Fri Oct 20 08:19:53 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 20 Oct 2017 10:19:53 +0200 Subject: Upgrading gcc arch ? In-Reply-To: References: Message-ID: Hi, I wonder if it is time to compile c/c++ code with a more recent cpu architecture (x86-64 is quite old: only SSE ?) to take benefit of performance optimizations offered by recent CPU and compilers (AVX...). Of course that means such builds would be specific to a CPU class and that will require build changes to make multiple flavors depending on the CPU classes ... See gcc -mtune argument: https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/x86-Options.html " ?sandybridge? Intel Sandy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AES and PCLMUL instruction set support. ?ivybridge? Intel Ivy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C instruction set support. ?haswell? Intel Haswell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2 and F16C instruction set support. ?broadwell? Intel Broadwell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX and PREFETCHW instruction set support. ?skylake? Intel Skylake CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC and XSAVES instruction set support. ?bonnell? Intel Bonnell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. ?silvermont? Intel Silvermont CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL and RDRND instruction set support. ?knl? Intel Knight's Landing CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, AVX512F, AVX512PF, AVX512ER and AVX512CD instruction set support. ?skylake-avx512? Intel Skylake Server CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, PKU, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC, XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ and AVX512CD instruction set support. " Comments are welcome, Laurent From peter.lawrey at gmail.com Fri Oct 20 08:31:34 2017 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Fri, 20 Oct 2017 09:31:34 +0100 Subject: Upgrading gcc arch ? In-Reply-To: References: Message-ID: I know the drive is toward smaller builds, but it would be good to auto select the CPU level at run time. I suspect however, this is something the OpenJDK (or a vendor supporting it) could do. Perhaps code which is CPU model sensitive could be placed in a small shared library with multiple versions and the appropriate build selected at runtime or on installation. Regards, Peter. ? On 20 October 2017 at 09:19, Laurent Bourg?s wrote: > Hi, > > I wonder if it is time to compile c/c++ code with a more recent cpu > architecture (x86-64 is quite old: only SSE ?) to take benefit of > performance optimizations offered by recent CPU and compilers (AVX...). > > Of course that means such builds would be specific to a CPU class and that > will require build changes to make multiple flavors depending on the CPU > classes ... > > See gcc -mtune argument: > https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/x86-Options.html > > " > ?sandybridge? > Intel Sandy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, > SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AES and PCLMUL instruction set support. > ?ivybridge? > Intel Ivy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, > SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C > instruction set support. > ?haswell? > Intel Haswell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, > SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, > FMA, BMI, BMI2 and F16C instruction set support. > ?broadwell? > Intel Broadwell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, > SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, > RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX and PREFETCHW instruction set > support. > ?skylake? > Intel Skylake CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, > SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, > FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC and > XSAVES instruction set support. > ?bonnell? > Intel Bonnell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 > and SSSE3 instruction set support. > ?silvermont? > Intel Silvermont CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, > SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL and RDRND instruction set > support. > ?knl? > Intel Knight's Landing CPU with 64-bit extensions, MOVBE, MMX, SSE, > SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, > FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, AVX512F, > AVX512PF, AVX512ER and AVX512CD instruction set support. > ?skylake-avx512? > Intel Skylake Server CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, > SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, PKU, AVX, AVX2, AES, PCLMUL, FSGSBASE, > RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC, > XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ and AVX512CD instruction set > support. > > " > > Comments are welcome, > Laurent > From volker.simonis at gmail.com Tue Oct 24 08:12:30 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 24 Oct 2017 10:12:30 +0200 Subject: OpenJDK Community TCK and EA TCK License Agreement V 3.0 Message-ID: Hi, I have some questions regarding the new "OpenJDK Community TCK and EA TCK License Agreement V 3.0" [1]. In the "RECITALS" section, what exactly does "Java SE 9 Specification (or later, as indicated by Oracle in writing to you)" mean? 1. Does the new license agreement V 3.0 also cover upcoming version of the Java SE TCK (i.e. 18.3, 18.9)? That would be actually nice because it would free us from going through this process every six month now. On the other hand, how can "as indicated by Oracle in writing to you" be interpreted? 2. Will Oracle automatically contact every signatory if new versions of the TCK will become available and grant them the rights to use the new versions as well? If question 2 will be answered with "Yes", there's a problem with section "7.0 TERM AND TERMINATION" which defines the term of the OCTLA with respect to "Effective Date" which is the date the initial OCTLA was submitted and signed. So for subsequent versions, the term will become shorter and shorter. 3. Shouldn't the term of the OCTLA be defined with respect to the first general availability date of a TCK? Otherwise signatories who sign it later will get longer access compared to early singers. It could also lead to multiple singing requests. I.e. I could sign the OCTLA for JDK 8 once again now in 2017 to get another 3 + 5 years coverage in addition to the 3 + 5 year I got in 2014 when I singed it the first time. >From the "RECITALS" section and the definition of "EA TCK" as "pre-release version of the TCK subsequent to the most generally available version of the TCK" I understand that a successful signing of OCTLA V 3.0 gives me access to all the subsequent version of EA TCKs. 4. Is it correct that a successful signing of OCTLA V 3.0 gives me access to all the subsequent version of EA TCKs? If question 4 will be answered with "Yes" there's again the problem with the "7.0 TERM AND TERMINATION" section which effectively reduces the rights to use all the subsequent version of EA TCKs to 3 + 5 years. 5. Why doesn't the OCTLA V 3.0 automatically covers subsequent versions of the TCK in the same, simple way it does for EA TCK versions? That would drastically simply the access to the TCKs in the presence of a high cadence, six-month Java SE release cycle. Thank you and best regards, Volker [1] http://openjdk.java.net/legal/OCTLA-JDK9+.pdf From fabtud at gmail.com Tue Oct 24 08:24:02 2017 From: fabtud at gmail.com (Fabio Tudone) Date: Tue, 24 Oct 2017 11:24:02 +0300 Subject: Call for Discussion: New Project: Loom Message-ID: Hi all, @Ron I think Project Loom is a great initiative; as a Quasar contributor I'm definitely interested in it and I'd like to contribute to it as well. Thanks, -- Fabio Tudone From donald.smith at oracle.com Tue Oct 24 12:27:11 2017 From: donald.smith at oracle.com (Donald Smith) Date: Tue, 24 Oct 2017 14:27:11 +0200 Subject: OpenJDK Community TCK and EA TCK License Agreement V 3.0 In-Reply-To: References: Message-ID: <8DF8A575-F5FB-4F37-8C17-6A4A048E9C82@oracle.com> Inline. Apologies if terse, sent from mobile device. > On Oct 24, 2017, at 10:12 AM, Volker Simonis wrote: > > Hi, > > I have some questions regarding the new "OpenJDK Community TCK and EA > TCK License Agreement V 3.0" [1]. > > In the "RECITALS" section, what exactly does "Java SE 9 Specification > (or later, as indicated by Oracle in writing to you)" mean? > > 1. Does the new license agreement V 3.0 also cover upcoming version of > the Java SE TCK (i.e. 18.3, 18.9)? Yes. > That would be actually nice because it would free us from going > through this process every six month now. Thank you! > On the other hand, how can > "as indicated by Oracle in writing to you" be interpreted? It means we will, in writing, inform you when a new version is covered. > 2. Will Oracle automatically contact every signatory if new versions > of the TCK will become available and grant them the rights to use the > new versions as well? For some definition of "automatically", yes. > If question 2 will be answered with "Yes", there's a problem with > section "7.0 TERM AND TERMINATION" which defines the term of the OCTLA > with respect to "Effective Date" which is the date the initial OCTLA > was submitted and signed. So for subsequent versions, the term will > become shorter and shorter. The initial term is as intended. The term can always be extended, we have done this for some signatories on JDK 6. So at an LTS if someone wants to reset the term, we can easily do so if mutually agreed. > 3. Shouldn't the term of the OCTLA be defined with respect to the > first general availability date of a TCK? No, see above. > Otherwise signatories who sign it later will get longer access > compared to early singers. It could also lead to multiple singing > requests. I.e. I could sign the OCTLA for JDK 8 once again now in 2017 > to get another 3 + 5 years coverage in addition to the 3 + 5 year I > got in 2014 when I singed it the first time. Again, see my comment above. This has always been the case and we extend the OCTLA term as needed and mutually agreed. > From the "RECITALS" section and the definition of "EA TCK" as > "pre-release version of the TCK subsequent to the most generally > available version of the TCK" I understand that a successful signing > of OCTLA V 3.0 gives me access to all the subsequent version of EA > TCKs. Earlier OCTLA agreements did not permit EA access, so the OCLTLA TCK for 7, 8 and 9 were only available at GA. Now we can give EA access to the gratis OCTLA like commercial licensees. This is a great thing, finally. > 4. Is it correct that a successful signing of OCTLA V 3.0 gives me > access to all the subsequent version of EA TCKs? When notified by Oracle in writing, yes. It's an EA of the TCK 9 or later, as indicated by Oracle. > If question 4 will be answered with "Yes" there's again the problem > with the "7.0 TERM AND TERMINATION" section which effectively reduces > the rights to use all the subsequent version of EA TCKs to 3 + 5 > years. Again, the initial term is correct. If there's a particular TCK you want a particular term on later, it can be discussed. > 5. Why doesn't the OCTLA V 3.0 automatically covers subsequent > versions of the TCK in the same, simple way it does for EA TCK > versions? See above, you're presuming the ea is a separate thing from the TCK. It's not. It's the EA. This now puts the gratis OCTLA on equal footing to the commercial agreements on EA access and versioning when indicated by Oracle, vastly simplifying things. > That would drastically simply the access to the TCKs in the presence > of a high cadence, six-month Java SE release cycle. That's what we have done, thanks! - Don > > Thank you and best regards, > Volker > > > [1] http://openjdk.java.net/legal/OCTLA-JDK9+.pdf From volker.simonis at gmail.com Tue Oct 24 13:24:32 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 24 Oct 2017 06:24:32 -0700 Subject: OpenJDK Community TCK and EA TCK License Agreement V 3.0 In-Reply-To: <8DF8A575-F5FB-4F37-8C17-6A4A048E9C82@oracle.com> References: <8DF8A575-F5FB-4F37-8C17-6A4A048E9C82@oracle.com> Message-ID: Hi Donald, thanks a lot for the quick clarifications! After your explanations I agree that access to the TCK has really been simplified although the need for manually resetting the term from time to time still seems weird to me. On the other hand, we always need room for further improvement :) I hope the EA TCKs for the upcoming Java releases will be published in a timely manner such that signatories can really use them. Thanks again and best regards, Volker On Tue, Oct 24, 2017 at 5:27 AM, Donald Smith wrote: > Inline. > > Apologies if terse, sent from mobile device. > >> On Oct 24, 2017, at 10:12 AM, Volker Simonis wrote: >> >> Hi, >> >> I have some questions regarding the new "OpenJDK Community TCK and EA >> TCK License Agreement V 3.0" [1]. >> >> In the "RECITALS" section, what exactly does "Java SE 9 Specification >> (or later, as indicated by Oracle in writing to you)" mean? >> >> 1. Does the new license agreement V 3.0 also cover upcoming version of >> the Java SE TCK (i.e. 18.3, 18.9)? > Yes. > >> That would be actually nice because it would free us from going >> through this process every six month now. > Thank you! > >> On the other hand, how can >> "as indicated by Oracle in writing to you" be interpreted? > It means we will, in writing, inform you when a new version is covered. > >> 2. Will Oracle automatically contact every signatory if new versions >> of the TCK will become available and grant them the rights to use the >> new versions as well? > For some definition of "automatically", yes. > >> If question 2 will be answered with "Yes", there's a problem with >> section "7.0 TERM AND TERMINATION" which defines the term of the OCTLA >> with respect to "Effective Date" which is the date the initial OCTLA >> was submitted and signed. So for subsequent versions, the term will >> become shorter and shorter. > The initial term is as intended. The term can always be extended, we have done this for some signatories on JDK 6. So at an LTS if someone wants to reset the term, we can easily do so if mutually agreed. > >> 3. Shouldn't the term of the OCTLA be defined with respect to the >> first general availability date of a TCK? > No, see above. > >> Otherwise signatories who sign it later will get longer access >> compared to early singers. It could also lead to multiple singing >> requests. I.e. I could sign the OCTLA for JDK 8 once again now in 2017 >> to get another 3 + 5 years coverage in addition to the 3 + 5 year I >> got in 2014 when I singed it the first time. > Again, see my comment above. This has always been the case and we extend the OCTLA term as needed and mutually agreed. > >> From the "RECITALS" section and the definition of "EA TCK" as >> "pre-release version of the TCK subsequent to the most generally >> available version of the TCK" I understand that a successful signing >> of OCTLA V 3.0 gives me access to all the subsequent version of EA >> TCKs. > Earlier OCTLA agreements did not permit EA access, so the OCLTLA TCK for 7, 8 and 9 were only available at GA. Now we can give EA access to the gratis OCTLA like commercial licensees. This is a great thing, finally. > >> 4. Is it correct that a successful signing of OCTLA V 3.0 gives me >> access to all the subsequent version of EA TCKs? > When notified by Oracle in writing, yes. It's an EA of the TCK 9 or later, as indicated by Oracle. > >> If question 4 will be answered with "Yes" there's again the problem >> with the "7.0 TERM AND TERMINATION" section which effectively reduces >> the rights to use all the subsequent version of EA TCKs to 3 + 5 >> years. > Again, the initial term is correct. If there's a particular TCK you want a particular term on later, it can be discussed. > >> 5. Why doesn't the OCTLA V 3.0 automatically covers subsequent >> versions of the TCK in the same, simple way it does for EA TCK >> versions? > See above, you're presuming the ea is a separate thing from the TCK. It's not. It's the EA. This now puts the gratis OCTLA on equal footing to the commercial agreements on EA access and versioning when indicated by Oracle, vastly simplifying things. > >> That would drastically simply the access to the TCKs in the presence >> of a high cadence, six-month Java SE release cycle. > That's what we have done, thanks! > > - Don > >> >> Thank you and best regards, >> Volker >> >> >> [1] http://openjdk.java.net/legal/OCTLA-JDK9+.pdf > From neugens at redhat.com Tue Oct 24 15:29:23 2017 From: neugens at redhat.com (Mario Torre) Date: Tue, 24 Oct 2017 17:29:23 +0200 Subject: OpenJDK Community TCK and EA TCK License Agreement V 3.0 In-Reply-To: References: <8DF8A575-F5FB-4F37-8C17-6A4A048E9C82@oracle.com> Message-ID: On Tue, Oct 24, 2017 at 3:24 PM, Volker Simonis wrote: > Hi Donald, > > thanks a lot for the quick clarifications! > > After your explanations I agree that access to the TCK has really been > simplified although the need for manually resetting the term from time > to time still seems weird to me. On the other hand, we always need > room for further improvement :) I hope the EA TCKs for the upcoming > Java releases will be published in a timely manner such that > signatories can really use them. Even better, an open source TCK ;) Cheers, Mario From hohensee at amazon.com Tue Oct 24 16:55:19 2017 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 24 Oct 2017 16:55:19 +0000 Subject: Accelerating the JDK release cadence In-Reply-To: <8d779f26-5bc6-4668-9283-3fa0942a0095@redhat.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> <558a0322-6a73-74ca-a71f-32a35878a3b0@redhat.com> <9289cad4-d0fe-0c1d-d366-875eb35bde64@redhat.com> <46CEB190-E8DA-4C3D-AAEC-5247818F5958@amazon.com> <8d779f26-5bc6-4668-9283-3fa0942a0095@redhat.com> Message-ID: <207A9E2A-E794-424D-B01E-3849F93E0B6E@amazon.com> To close out this thread, Oracle has published a support roadmap here: http://www.oracle.com/technetwork/java/javase/tech/eol-135779.html Thanks, Paul On 10/19/17, 2:10 PM, "Andrew Haley" wrote: On 19/10/17 21:56, Hohensee, Paul wrote: > What are the constraints on doing so? Skilled labour; opportunity cost. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From donald.smith at oracle.com Wed Oct 25 14:35:56 2017 From: donald.smith at oracle.com (Donald Smith) Date: Wed, 25 Oct 2017 16:35:56 +0200 Subject: Accelerating the JDK release cadence In-Reply-To: <207A9E2A-E794-424D-B01E-3849F93E0B6E@amazon.com> References: <20170906144928.13997AA82D@eggemoggin.niobe.net> <59097c63-6cdb-41a5-ac3a-9f78d1cf0786@redhat.com> <558a0322-6a73-74ca-a71f-32a35878a3b0@redhat.com> <9289cad4-d0fe-0c1d-d366-875eb35bde64@redhat.com> <46CEB190-E8DA-4C3D-AAEC-5247818F5958@amazon.com> <8d779f26-5bc6-4668-9283-3fa0942a0095@redhat.com> <207A9E2A-E794-424D-B01E-3849F93E0B6E@amazon.com> Message-ID: <4B75B210-F268-40BC-B7BB-17CA17401759@oracle.com> FWIW, the support roadmap linked below is Oracle JDK and commercial products specific. It doesn't reflect what may be happening within various OpenJDK builds. Apologies if terse, sent from mobile device. > On Oct 24, 2017, at 6:55 PM, Hohensee, Paul wrote: > > To close out this thread, Oracle has published a support roadmap here: > > http://www.oracle.com/technetwork/java/javase/tech/eol-135779.html > > Thanks, > > Paul > > On 10/19/17, 2:10 PM, "Andrew Haley" wrote: > > On 19/10/17 21:56, Hohensee, Paul wrote: >> What are the constraints on doing so? > > Skilled labour; opportunity cost. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From stefan.karlsson at oracle.com Wed Oct 25 20:25:59 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 25 Oct 2017 22:25:59 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <5856a387-91e6-75d7-56d6-b6908a659747@oracle.com> Vote: YES StefanK On 2017-10-25 21:45, 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 From john.r.rose at oracle.com Wed Oct 25 20:55:56 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 25 Oct 2017 13:55:56 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: yes! On Oct 25, 2017, at 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. From thomas.schatzl at oracle.com Wed Oct 25 21:11:38 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 25 Oct 2017 23:11:38 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <5856a387-91e6-75d7-56d6-b6908a659747@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <5856a387-91e6-75d7-56d6-b6908a659747@oracle.com> Message-ID: <1508965898.8931.1.camel@oracle.com> Vote: yes Thomas > On 2017-10-25 21:45, 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 :) From coleen.phillimore at oracle.com Wed Oct 25 20:52:44 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 25 Oct 2017 16:52:44 -0400 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <8cab78ec-450f-2c8e-5377-fa4204c62558@oracle.com> 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 From vladimir.kozlov at oracle.com Wed Oct 25 23:49:19 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 Oct 2017 16:49:19 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <080ce2c3-f91b-610c-c3dc-5a3ff8f0fb51@oracle.com> 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 From ioi.lam at oracle.com Thu Oct 26 00:22:04 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 25 Oct 2017 17:22:04 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <7f633b42-9c28-314c-2326-2d0dabeae1e0@oracle.com> 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 From Peter.B.Kessler at Oracle.COM Thu Oct 26 00:54:09 2017 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Wed, 25 Oct 2017 17:54:09 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: yes ... peter 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. > ... From david.holmes at oracle.com Thu Oct 26 02:19:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Oct 2017 12:19:21 +1000 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <1b0cc49a-fc29-8ec6-af72-e3c40640b879@oracle.com> Vote: yes. David On 26/10/2017 5:45 AM, 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. From roman at kennke.org Thu Oct 26 06:54:04 2017 From: roman at kennke.org (Roman Kennke) Date: Thu, 26 Oct 2017 08:54:04 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: yes Am 25. Oktober 2017 21:45:23 MESZ schrieb Per Liden : >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. From dalibor.topic at oracle.com Thu Oct 26 07:50:09 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 26 Oct 2017 09:50:09 +0200 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <3d2f8d4c-b207-3393-89a7-cc753b3223e5@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From neugens.limasoftware at gmail.com Thu Oct 26 07:57:13 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 26 Oct 2017 07:57:13 +0000 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: Yes Cheers, Mario On Wed 25. Oct 2017 at 22:23, 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 > From Alan.Bateman at oracle.com Thu Oct 26 08:17:34 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Oct 2017 09:17:34 +0100 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <6bbef8a7-5acb-079c-b518-c377b81fa871@oracle.com> Vote: yes From erik.helin at oracle.com Thu Oct 26 08:32:51 2017 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 26 Oct 2017 10:32:51 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: yes Thanks, Erik On 10/25/2017 09: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 From markus.gronlund at oracle.com Thu Oct 26 08:36:12 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 26 Oct 2017 01:36:12 -0700 (PDT) Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: yes -----Original Message----- From: Per Liden Sent: den 25 oktober 2017 21:45 To: announce at openjdk.java.net Subject: CFV: New Project: ZGC 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 magnus.ihse.bursie at oracle.com Thu Oct 26 09:17:56 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Oct 2017 11:17:56 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <3bc2a06b-0081-e3ab-dceb-be6552890346@oracle.com> Vote: yes /Magnus On 2017-10-25 21:45, 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 From Roger.Riggs at Oracle.com Thu Oct 26 13:19:13 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 26 Oct 2017 09:19:13 -0400 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <26fae6e9-eed1-b80e-75e7-79d1a3b97e52@Oracle.com> Vote: Yes On 10/25/2017 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. From volker.simonis at gmail.com Thu Oct 26 15:42:48 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Oct 2017 17:42:48 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: 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 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 From kumar.x.srinivasan at oracle.com Thu Oct 26 17:16:04 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 26 Oct 2017 10:16:04 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <59F21854.3030604@oracle.com> Vote: yes On 10/25/2017 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 From aph at redhat.com Thu Oct 26 17:20:38 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Oct 2017 18:20:38 +0100 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <0052df15-3123-6f5e-c089-e8f7805d0866@redhat.com> On 26/10/17 16:42, Volker Simonis wrote: > 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. Yep. It would be unfortunate if it appeared that all this was being done without the preparation required of external contributors. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Thu Oct 26 20:33:47 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 26 Oct 2017 22:33:47 +0200 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <3c024792-8f36-b917-ef07-28c11df2c87e@oracle.com> On 26.10.2017 17:42, Volker Simonis wrote: > 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. The Shenandoah discussion in February had run its course within 9 days. Once Roman wanted to initiate the vote on the Project in March, it became clear that the HotSpot Group Lead at the time was no longer at Oracle, and no longer actively acting as Group Lead, and therefore unable to get to sponsor the Project, as required in the Bylaws for the vote. [0] While an inactive Group Lead could have been removed by votes of the HotSpot Group's Members (or in exceptional circumstances, by a vote of the Governing Board), I think that it's preferable for a person that is no longer acting as a Group Lead to resign if no longer interested in the role, than to attempt to vote them out. The resignation happened three months later, in June. [1] The vote for a new Group Lead was completed by the end of June. [2] The Governing Board confirmed the new Group Lead in July. [3] The delay between the initial discussion of Shenandoah and the Project vote had nothing to do with interrogations of any kind. cheers, dalibor topic [0] http://mail.openjdk.java.net/pipermail/discuss/2015-March/003701.html [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018933.html [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019273.html [3] http://mail.openjdk.java.net/pipermail/gb-discuss/2015-July/thread.html -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From brian.goetz at oracle.com Thu Oct 26 21:08:01 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 26 Oct 2017 17:08:01 -0400 Subject: CFV: New Project: ZGC In-Reply-To: <8cab78ec-450f-2c8e-5377-fa4204c62558@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <8cab78ec-450f-2c8e-5377-fa4204c62558@oracle.com> Message-ID: 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 > From john.r.rose at oracle.com Thu Oct 26 23:23:48 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 26 Oct 2017 16:23:48 -0700 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> On Oct 26, 2017, at 8:42 AM, Volker Simonis wrote: > 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. So, a proposed contribution "doesn't count" if it in any way overlaps with previously contributed software? Of course it counts. As open-source people we are skeptical of closed-source projects, but (a) they count intrinsically, as hard won experience (even if won in the dark), and (b) when opened up, they count as welcome help, previously inaccessible. Your comments are very understandable (except for the bit I just quoted), but try to see it from our viewpoint also. "Why didn't you contribute to Shenandoah?" Because we had an internally funded alternative that seemed more promising to us, which we couldn't share. Is Oracle the only company with internally funded changes to the OpenJDK? No. But we are one that is aggressively out-streaming ours, now. Oracle's new direction announced at JavaOne is that we are going to be moving Java forward faster. To move faster in this case is to get ZGC out into the light of day, as quickly as possible. I'm sorry this seems unfair to you, when compared to actions in previous years. I don't think we were unfair, but even if we were, we are on record as eager to distribute responsibility for OpenJDK development fairly. The current vote is our move to get our very promising code out as quickly as possible. I hope that's enough reason to overlook any perception of unfairness. Put another way: Would you really prefer that we keep ZGC wraps while we replay the Shenandoah cross-examination, to some suggested number of months? Wouldn't it be better to get the code bases out there and then figure out what to do with them? Of course it would. That's why I voted yes! Do you have an alternative suggestion for accelerating a fair and open examination of our sudden riches of GC technology? That's what I want; I have to think that's what everyone wants. Best wishes, ? John From volker.simonis at gmail.com Fri Oct 27 07:07:40 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 27 Oct 2017 09:07:40 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <3c024792-8f36-b917-ef07-28c11df2c87e@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <3c024792-8f36-b917-ef07-28c11df2c87e@oracle.com> Message-ID: On Thu, Oct 26, 2017 at 10:33 PM, dalibor topic wrote: > On 26.10.2017 17:42, Volker Simonis wrote: >> >> 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. > > > The Shenandoah discussion in February had run its course within 9 days. > > Once Roman wanted to initiate the vote on the Project in March, it became > clear that the HotSpot Group Lead at the time was no longer at Oracle, and > no longer actively acting as Group Lead, and therefore unable to get to > sponsor the Project, as required in the Bylaws for the vote. [0] > > While an inactive Group Lead could have been removed by votes of the HotSpot > Group's Members (or in exceptional circumstances, by a vote of the Governing > Board), I think that it's preferable for a person that is no longer acting > as a Group Lead to resign if no longer interested in the role, than to > attempt to vote them out. > > The resignation happened three months later, in June. [1] The vote for a > new Group Lead was completed by the end of June. [2] The Governing Board > confirmed the new Group Lead in July. [3] > > The delay between the initial discussion of Shenandoah and the Project vote > had nothing to do with interrogations of any kind. > It is true that the delay in project creation was also caused by some administrative hiccups but the general impression remains that everything Oracle wants within the project proceeds quickly and smoothly while this is not always the case for requests from external contributors. > cheers, > dalibor topic > > [0] http://mail.openjdk.java.net/pipermail/discuss/2015-March/003701.html > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018933.html > [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019273.html > [3] http://mail.openjdk.java.net/pipermail/gb-discuss/2015-July/thread.html > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment From adinn at redhat.com Fri Oct 27 08:10:35 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 Oct 2017 09:10:35 +0100 Subject: CFV: New Project: ZGC In-Reply-To: <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> Message-ID: <39efe8d5-69bb-2fdd-2610-c177259456b0@redhat.com> Hi John, Thanks for posting very honest and fair responses to Volker's questions. On the surface it may look as if this is Oracle getting preferential treatment but I fully accept your point that this is really just a retro-active fix to ensure that work already done, **in different circumstances and under different constraints than those which apply now**, is neither dropped nor stashed away with the loss of any opportunity for the community to profit from it. On 27/10/17 00:23, John Rose wrote: > Do you have an alternative suggestion for accelerating a fair > and open examination of our sudden riches of GC technology? > That's what I want; I have to think that's what everyone wants. That's really the key question and clearly my answer is no. I'll also note that creating ZGC as a project does not preclude OpenJDK members making their own assessment of the merits of the project, deciding whether they wish to donate their own effort to it, or taking part in any eventual discussion of a proposal for inclusion into the mainline. Volker does raise a legitimate concern regarding the cost of this project to OpenJDK project members' time and focus. However, since it appears that much time and investment has already been made (as I said before, in different circumstances and under different constraints than those which apply now) and since there is already a 'work in progress' capable of being presented and reviewed I think the best way to resolve questions regarding possible costs and benefits will be to create the project, upload the source and let it progress or idle on its own merits (as has happened with Oracle's ARM64 port vs the AArch64 port). I'll post my vote accordingly. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Oct 27 08:11:44 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 Oct 2017 09:11:44 +0100 Subject: CFV: New Project: ZGC In-Reply-To: <5856a387-91e6-75d7-56d6-b6908a659747@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <5856a387-91e6-75d7-56d6-b6908a659747@oracle.com> Message-ID: <955ad85d-35a1-2694-918c-b554e5d670d9@redhat.com> Vote: Yes > On 2017-10-25 21:45, 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 regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From roman at kennke.org Fri Oct 27 08:20:37 2017 From: roman at kennke.org (Roman Kennke) Date: Fri, 27 Oct 2017 10:20:37 +0200 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <2bf59e7b-2941-23be-36f9-0a1071fec011@kennke.org> 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 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 From volker.simonis at gmail.com Fri Oct 27 08:24:42 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 27 Oct 2017 10:24:42 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> Message-ID: On Fri, Oct 27, 2017 at 1:23 AM, John Rose wrote: > On Oct 26, 2017, at 8:42 AM, Volker Simonis > wrote: > > 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. > > > So, a proposed contribution "doesn't count" if it in any way overlaps > with previously contributed software? Of course it counts. > > As open-source people we are skeptical of closed-source projects, > but (a) they count intrinsically, as hard won experience (even if > won in the dark), and (b) when opened up, they count as welcome > help, previously inaccessible. > > Your comments are very understandable (except for the bit I just > quoted), but try to see it from our viewpoint also. > I didn't wanted to say the whole contribution doesn't count. After all, children can't be hold accountable for their parent's faults :) > "Why didn't you contribute to Shenandoah?" Because we had an > internally funded alternative that seemed more promising to us, > which we couldn't share. Is Oracle the only company with internally > funded changes to the OpenJDK? No. But we are one that is > aggressively out-streaming ours, now. > > Oracle's new direction announced at JavaOne is that we are going > to be moving Java forward faster. To move faster in this case is to > get ZGC out into the light of day, as quickly as possible. I'm sorry > this seems unfair to you, when compared to actions in previous > years. I don't think we were unfair, but even if we were, we are > on record as eager to distribute responsibility for OpenJDK > development fairly. The current vote is our move to get our > very promising code out as quickly as possible. I hope that's > enough reason to overlook any perception of unfairness. > Yes, I indeed think that this is extremely unfair! Especially with regards to RedHat who invested a great amount of time and resources into Shenandoah. And this doesn't happen for the first time. We had the same story with the ARM port. The community requested it for a long time but Oracle didn't wanted to contribute it to the OpenJDK. So RedHat jumped in and did a whole new ARM64 bit port from scratch and donated it to the OpenJDK. Only after this new port was done and functional, Oracle then decided to also donate its ports (both 64 and 32 bit) to the project. This is at least a huge waste of efforts and not the way how trusted partners should work together in an Open Source project! > Put another way: Would you really prefer that we keep ZGC > wraps while we replay the Shenandoah cross-examination, to > some s uggested number of months? Wouldn't it be better to > get the code bases out there and then figure out what to do > with them? Of course it would. No, of course I don't want to delay the opening of the code base. But strictly speaking, getting the code base out is independent from starting a new OpenJDK project. What I really want is to get a short technical overview of the ZGC project from the project owner which outlines where ZGC differs from Shenandoah, where it is superior and where it is inferior and why it makes sense to have both in the OpenJDK. A vote is obviously not the right place for such a discussion that's why after all, a discussion is recommended before doing the vote. You know there are two sorts of Open Source projects. The first kind is done in good faith to grow and foster the project together with the community. OpenJDK is such a kind of project and I really appreciate that it was created. But there's also a second kind of Open Source projects which are only open sourced because a company doesn't care any more about that project and just wants to transfer the responsibility for the project to the community. Notice that this is still better than simply burying the project, but usually not a great starting point for an Open Source project. I tend to add Oracle's aforementioned ARM ports to this second category because it doesn't seem that a lot of effort went into these ports after their contribution (at least by far not that much as went into RedHat's AARCH64 port). Taking into account Oracle's concerns about having to support too many GCs in HotSpot, I think it is legitimate and important to understand what kind of an Open Source project ZGC will be. > > That's why I voted yes! > > Do you have an alternative suggestion for accelerating a fair > and open examination of our sudden riches of GC technology? > That's what I want; I have to think that's what everyone wants. > I'm not at all against a new GC nor am I against ZGC. I'm only against one participant of the OpenJDK project being treated special compared to others. RedHat is trying very hard to integrate Shenandoah into the HotSpot [1]. If now suddenly a similar GC appears out of the dark and will be integrated right away into the HotSpot main line code that would really a fatal message towards all other external contributors. Who ever would like to do any serious investments into OpenJDK any more ? Instead, I really wish all OpenJDK participants (including Oracle) would work closer together to avoid redundant efforts in the future. Regards, Volker [1] http://openjdk.java.net/jeps/189 > Best wishes, > ? John From shade at redhat.com Fri Oct 27 08:56:12 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 27 Oct 2017 10:56:12 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> Message-ID: <57516718-6f99-88ea-76a9-343ea09412c9@redhat.com> On 10/27/2017 01:23 AM, John Rose wrote: > On Oct 26, 2017, at 8:42 AM, Volker Simonis wrote: >> 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. > > Put another way: Would you really prefer that we keep ZGC > wraps while we replay the Shenandoah cross-examination, to > some suggested number of months? Wouldn't it be better to > get the code bases out there and then figure out what to do > with them? Of course it would. Sure it would, and I am happy it happens! The inception of the project should not be blocked by the overlapping existing projects: show us the code, and all that, is in effect here. The same way anyone can do a Sandbox branch with whatever woozy idea that comes to mind, anyone with enough resources should be able to incept the project. It would of course be much nicer if ZGC was not developed under cover, so the community would have the opportunity to contribute, reconcile community roadmaps with its existence, and plan for adoption. What Volker taps into here, is the game-theoretical argument. The next big external contributor would face a dilemma: either it should invest heavily into the open project and get it out at its own expense, or it should patiently wait for Oracle to open its stash and contribute a similar project. The risk in doing the open-source project that runs into collision with late Oracle contribution is basically the opportunity cost for the contributor, which would make contributing less appealing. And the probability of such collision happening is non-ignorable, having at least two firm instances of this happening (AArch64 back then, and Shenandoah/ZGC today). Since we seem to agree there is no foul play on Oracle part here, and that we are dealing with the aftermath of Oracle closeness, this is less of an issue for Shenandoah. This might not be as true for the contributors after us who might think differently (after all, the prevalence of "Oracle is evil" mindset is astounding out there :/), without having the insights into project undercurrents. If we understand that we want the community around OpenJDK, we need to understand the late contributions like these -- however technically sound -- do have the social impact on the entire project. The successful open-source project is not exactly about pushing out the code, it is about the social dynamics that makes the large-scale community work possible. In my mind, it is important for at least Architects to recognize that, and accept Volker's concerns as legitimate. IMO, it would be enough at this point to accept that the past did suck, and we are dealing with its fallout, and would try to not get into this situation again. -Aleksey From adinn at redhat.com Fri Oct 27 09:07:11 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 Oct 2017 10:07:11 +0100 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> Message-ID: <717b63d2-0de3-55fc-617c-263b3c016c53@redhat.com> Hi Volker, On 27/10/17 09:24, Volker Simonis wrote: > Yes, I indeed think that this is extremely unfair! Especially with > regards to RedHat who invested a great amount of time and resources > into Shenandoah. And this doesn't happen for the first time. We had > the same story with the ARM port. The community requested it for a > long time but Oracle didn't wanted to contribute it to the OpenJDK. So > RedHat jumped in and did a whole new ARM64 bit port from scratch and > donated it to the OpenJDK. Only after this new port was done and > functional, Oracle then decided to also donate its ports (both 64 and > 32 bit) to the project. This is at least a huge waste of efforts and > not the way how trusted partners should work together in an Open > Source project! The picture you present here makes it look like we acted in response to Oracle withholding their ARM32 port. Furthermore, to the unwary reader, your presentation of the case may also suggest they were holding out on work they had started or were seriously considering on an AArch64 port. I'd just like to clarify that Andrew Haley and I started work on the AArch64 port because it was recognised to be a critical element of Red Hat's strategic commitment to support a complete, open source AArch64 server stack. That decision was /not/ influenced by the existence of Oracle's proprietary ARM32 port. Also, we commenced work well before AArch64 hardware was available and -- I believe -- some time before Oracle began work on their ARM64 port. Any concern on Red Hat's part that Oracle might implement a proprietary ARM64 port was far outweighed by Red Hat's urgent need to be an important stakeholder in a fully open source JVM for AArch64 (ditto actually for x86 -- which is why so many Red Hat staff are members of the OpenJDK project(s)). > You know there are two sorts of Open Source projects. The first kind > is done in good faith to grow and foster the project together with the > community. OpenJDK is such a kind of project and I really appreciate > that it was created. But there's also a second kind of Open Source > projects which are only open sourced because a company doesn't care > any more about that project and just wants to transfer the > responsibility for the project to the community. Notice that this is > still better than simply burying the project, but usually not a great > starting point for an Open Source project. I tend to add Oracle's > aforementioned ARM ports to this second category because it doesn't > seem that a lot of effort went into these ports after their > contribution (at least by far not that much as went into RedHat's > AARCH64 port). Taking into account Oracle's concerns about having to > support too many GCs in HotSpot, I think it is legitimate and > important to understand what kind of an Open Source project ZGC will > be. Well, you answer your own concern here, I think. If OpenJDK is the sort of project where things get done in good faith (and I agree it is) then surely any attempt to use it to put ZGC out to grass or bury it will only backfire. I don't actually think it sounds like ZGC is going to be moribund or dead on arrival but let's find out. > I'm not at all against a new GC nor am I against ZGC. I'm only against > one participant of the OpenJDK project being treated special compared > to others. RedHat is trying very hard to integrate Shenandoah into the > HotSpot [1]. If now suddenly a similar GC appears out of the dark and > will be integrated right away into the HotSpot main line code that > would really a fatal message towards all other external contributors. > Who ever would like to do any serious investments into OpenJDK any > more ? Instead, I really wish all OpenJDK participants (including > Oracle) would work closer together to avoid redundant efforts in the > future. I believe you started to stray at the 'If' in the middle of that paragraph, specifically at clause 2 of the encompassed 'and'. The proposal being voted on here is not to "integrate [anything] right away into the HotSpot main line code". As such, I see no fatal message being delivered. This is simply an offer of potentially valuable code from an active project participant. The most important message I read here is one we have already seen Oracle acknowledge: that contributing their efforts to an open project is a better way forward than trying to withhold and privately maintain a proprietary alternative. I'm very grateful that they wish to make their work available to the community and I hope we can all benefit from their offer, whether that means profiting from retaining both GCs, eventually incorporating features from ZGC into Shenandoah and letting ZGC drop, or vice versa with Shenandoah eventually being dropped. I'd welcome all those outcomes so long as we get to choose the right one on the right terms. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From roman at kennke.org Fri Oct 27 09:27:06 2017 From: roman at kennke.org (Roman Kennke) Date: Fri, 27 Oct 2017 11:27:06 +0200 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> Message-ID: <70614133-e13d-e0bf-8c06-03bc102742f5@kennke.org> >> development fairly. The current vote is our move to get our >> very promising code out as quickly as possible. I hope that's >> enough reason to overlook any perception of unfairness. >> > Yes, I indeed think that this is extremely unfair! Especially with > regards to RedHat who invested a great amount of time and resources > into Shenandoah. It feels a bit strange for me to be in a situation to quasi-defend Oracle's actions (and when I say Oracle, I mean its employees that are involved in OpenJDK)? ;-) But I disagree here. I do not feel like I've been treated unfair. Nobody owes anything to anybody else. Oracle decides to work the way they do, and it's their choice. I decide to work differently, and that's my choice. Proposing to open source ZGC now is a move in the right direction IMO. Thanks, Roman From volker.simonis at gmail.com Fri Oct 27 09:29:38 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 27 Oct 2017 11:29:38 +0200 Subject: CFV: New Project: ZGC In-Reply-To: <57516718-6f99-88ea-76a9-343ea09412c9@redhat.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> <57516718-6f99-88ea-76a9-343ea09412c9@redhat.com> Message-ID: On Fri, Oct 27, 2017 at 10:56 AM, Aleksey Shipilev wrote: > On 10/27/2017 01:23 AM, John Rose wrote: >> On Oct 26, 2017, at 8:42 AM, Volker Simonis wrote: >>> 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. >> >> Put another way: Would you really prefer that we keep ZGC >> wraps while we replay the Shenandoah cross-examination, to >> some s uggested number of months? Wouldn't it be better to >> get the code bases out there and then figure out what to do >> with them? Of course it would. > > Sure it would, and I am happy it happens! The inception of the project should not be blocked by the > overlapping existing projects: show us the code, and all that, is in effect here. The same way > anyone can do a Sandbox branch with whatever woozy idea that comes to mind, anyone with enough > resources should be able to incept the project. > > It would of course be much nicer if ZGC was not developed under cover, so the community would have > the opportunity to contribute, reconcile community roadmaps with its existence, and plan for adoption. > > What Volker taps into here, is the game-theoretical argument. The next big external contributor > would face a dilemma: either it should invest heavily into the open project and get it out at its > own expense, or it should patiently wait for Oracle to open its stash and contribute a similar > project. The risk in doing the open-source project that runs into collision with late Oracle > contribution is basically the opportunity cost for the contributor, which would make contributing > less appealing. And the probability of such collision happening is non-ignorable, having at least > two firm instances of this happening (AArch64 back then, and Shenandoah/ZGC today). > > Since we seem to agree there is no foul play on Oracle part here, and that we are dealing with the > aftermath of Oracle closeness, this is less of an issue for Shenandoah. This might not be as true > for the contributors after us who might think differently (after all, the prevalence of "Oracle is > evil" mindset is astounding out there :/), without having the insights into project undercurrents. > > If we understand that we want the community around OpenJDK, we need to understand the late > contributions like these -- however technically sound -- do have the social impact on the entire > project. The successful open-source project is not exactly about pushing out the code, it is about > the social dynamics that makes the large-scale community work possible. In my mind, it is important > for at least Architects to recognize that, and accept Volker's concerns as legitimate. IMO, it would > be enough at this point to accept that the past did suck, and we are dealing with its fallout, and > would try to not get into this situation again. > I would be happy if that would be the outcome of my grumbling and promise to hold my peace forever :) > -Aleksey > From aph at redhat.com Fri Oct 27 14:50:37 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Oct 2017 15:50:37 +0100 Subject: CFV: New Project: ZGC In-Reply-To: <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <1AB0949A-30BD-4872-B95F-63B9FB754D94@oracle.com> Message-ID: I sympathize with both side of this discussion. Of course I'd prefer to see all JDK software freed: my response has always been you say yes, let a hundred flowers blossom and a hundred schools of thought contend. However, I'm also painfully aware of how it feels to be outside Oracle working on OpenJDK. When we started the Shenandoah project at Red Hat, we had no particular worries about how well it would perform: our biggest worry was "Will Oracle allow us to contribute this to OpenJDK?" In the end we decided that we were going to do it anyway, and if needs be we'd maintain it outside OpenJDK's core repository, but it remained a significant worry for a long time, and Shenandoah is still not in. You could argue that our fears were misplaced, but they were real. This near-duplication of projects doesn't encourage any would-be contributor to work on OpenJDK. It makes it hard to build trust. Somehow we need to turn OpenJDK into a more open-source project, one that encourages all participants. (I'm hoping that the change to time-based releases will help with that, but it's another matter.) Oracle developers are the gatekeepers for the core projects, and it sometimes appears that decisions are made as a _fait accompli_ and merely announced to the OpenJDK project. Up to now it's been arguable that it's natural that Oracle should lead all of these projects because they were the primary authors and provided the bulk of the engineering effort. But we've been working on this together for ten years now, and it is no longer the case that Oracle is the only organization with the expertise to contribute in a major way. So yes, let's open ZGC. But let's also try to work together so that we can share the heavy lifting and deliver the best GC technology to the people who really matter, our users. On 27/10/17 00:23, John Rose wrote: > Put another way: Would you really prefer that we keep ZGC > wraps while we replay the Shenandoah cross-examination, to > some suggested number of months? Wouldn't it be better to > get the code bases out there and then figure out what to do > with them? Of course it would. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From karen.kinnear at oracle.com Fri Oct 27 16:02:00 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 27 Oct 2017 12:02:00 -0400 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: yes Karen > On Oct 25, 2017, at 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 From per.liden at oracle.com Fri Oct 27 17:12:45 2017 From: per.liden at oracle.com (Per Liden) Date: Fri, 27 Oct 2017 19:12:45 +0200 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <4d9fff84-ca9a-d481-36be-e23f2e1c457d@oracle.com> Hi Volker, On 2017-10-26 17:42, Volker Simonis wrote: [...] > 1. What are the benefits / advantages of ZGC over Shenandoah? In my proposal I outlined some of the benefits we expect to achieve through the current ZGC design. With respect to an evaluation of specifics of the ZGC implementation with other approaches, I believe that's something that makes most sense to discuss once the ZGC code is actually open source, and starts to move ahead as part of the OpenJDK Community in a Project of its own, rather than in a vacuum. > 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. As Roman and Andrew have already mentioned, there are multiple possible outcomes here (pick one, have both, merge them, etc), and only time and experience with both code bases will help us here. This is just a proposal for a new, independent ZGC project. It's not a proposal to merge ZGC into the JDK itself. An important part here is that we make sure that adding GCs doesn't come with an explosion in maintenance cost. The ongoing collaboration between Oracle and Red Hat on the GC and Barrier APIs is key to making sure that doesn't happen. > 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 CMS code base is complex to maintain. It's also not a collector we at Oracle believe is a good foundation for any future work. By deprecating CMS we've freed up resources at Oracle that can be invested in collectors we believe will serve everyone better going forward. cheers, Per From poonam.bajaj at oracle.com Fri Oct 27 19:20:47 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Fri, 27 Oct 2017 12:20:47 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: Yes Thanks, Poonam On 10/25/2017 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 From john.r.rose at oracle.com Sat Oct 28 01:38:16 2017 From: john.r.rose at oracle.com (John Rose) Date: Fri, 27 Oct 2017 18:38:16 -0700 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <39D98DA1-3B05-4AC5-8513-2F05FF687239@oracle.com> Vote: yes! From vladimir.kozlov at oracle.com Sat Oct 28 02:02:48 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 27 Oct 2017 19:02:48 -0700 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: Vote: yes On 10/27/17 12:28 PM, Ron Pressler wrote: > 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 > > From mandy.chung at oracle.com Sat Oct 28 02:50:50 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 27 Oct 2017 19:50:50 -0700 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <6f6b20ff-6389-1fd5-38c6-dbbaf621f465@oracle.com> Vote: yes Mandy From stefan.karlsson at oracle.com Sat Oct 28 06:54:45 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Sat, 28 Oct 2017 08:54:45 +0200 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <37f3b3cf-6552-f1c8-3e61-a9c8affe1453@oracle.com> Vote: yes StefanK On 2017-10-27 21:28, Ron Pressler wrote: > 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 > > From Alan.Bateman at oracle.com Sat Oct 28 07:32:29 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 28 Oct 2017 08:32:29 +0100 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: Vote: yes From erik.helin at oracle.com Sat Oct 28 09:34:50 2017 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 28 Oct 2017 11:34:50 +0200 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <1df8fb32-155a-513a-a0c3-2df95da748f4@oracle.com> Vote: yes Thanks, Erik On 10/27/2017 09:28 PM, Ron Pressler wrote: > 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 > > From david.holmes at oracle.com Sat Oct 28 12:06:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 28 Oct 2017 22:06:12 +1000 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: Vote: yes David On 28/10/2017 5:28 AM, Ron Pressler wrote: > 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 > > From markus.gronlund at oracle.com Sat Oct 28 12:13:39 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Sat, 28 Oct 2017 05:13:39 -0700 (PDT) Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <8c15f797-3a5b-4791-8a94-5c8043265f91@default> Vote: Yes -----Original Message----- From: Ron Pressler Sent: den 27 oktober 2017 21:28 To: announce at openjdk.java.net Subject: CFV: New Project: Loom 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? From sadhak001 at gmail.com Sat Oct 28 15:21:20 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sat, 28 Oct 2017 15:21:20 +0000 Subject: discuss Digest, Vol 126, Issue 8 In-Reply-To: References: Message-ID: That sounds awesome. Thanks for sharing this with us. Cheers Mani On Tue, 10 Oct 2017 12:57 , wrote: > Send discuss mailing list submissions to > discuss at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/discuss > or, via email, send a message with subject or body 'help' to > discuss-request at openjdk.java.net > > You can reach the person managing the list at > discuss-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of discuss digest..." > > > Today's Topics: > > 1. Re: Call for Discussion: New Project: Loom > (=?UTF-8?B?5p2O5LiJ57qiKOS4iee6oik=?=) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 09 Oct 2017 20:26:18 +0800 > From: "=?UTF-8?B?5p2O5LiJ57qiKOS4iee6oik=?=" > > To: , > Subject: Re: Call for Discussion: New Project: Loom > Message-ID: <012d01d340f9$ceeae010$6cc0a030$@alibaba-inc.com> > Content-Type: text/plain; charset="gb2312" > > Hi Ron, > > I are very excited about this proposal to add lightweight threads to > Java. > > > > > As I have talked at JVMLS [1], our own customized OpenJDK version has > implemented some similar mechanism proposed by loom(we called this as Wisp > internally), which is already widely deployed in Alibaba production > environment. A couple of core ecommerce applications (running in very > large > scale cluster) are running on top of Wisp. By this way, we achieved 10+% > CPU saving, lots of thread context switches could be reduced by > transferring > from thread to coroutine. > > > > More specifically, our implementation is relying on the continuation > primitive support made by [2] , which is part of MLVM project. Moreover, > we added our own scheduler(fully written in Java) to support coroutine > yielding at almost all possibly blocked places in OpenJDK, including: > > - Java synchronization(compiled & runtime code change) > > - J.U.C > > - Java network IO > > - Java disk IO > > Our goal is to allow Java developers to write in synchronous but gain > performance of asynchronous for free, they just change a couple of line of > code and do some parameter configuration, the control transferring between > coroutines is totally handled by underlying JDK transparently. > > > > We are interested in contributing to this project. > > > > [1]: > > https://www.slideshare.net/sherrylso/optimizing-jvm-at-alibaba-for-ecommerce > -apps-running-on-100000-servers > > > [2]: > > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/4cd7d914b0e3/coro-simple.p > atch > > > > End of discuss Digest, Vol 126, Issue 8 > *************************************** > -- @theNeomatrix369 * | **Blog ** | *@adoptopenjdk | Dev communities *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From volker.simonis at gmail.com Mon Oct 30 00:25:49 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 29 Oct 2017 17:25:49 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <4d9fff84-ca9a-d481-36be-e23f2e1c457d@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> <4d9fff84-ca9a-d481-36be-e23f2e1c457d@oracle.com> Message-ID: Hi Per, thanks for your further clarifications. Please be assured that all the concerns I've raised so far are solely related to the overall OpenJDK participation rules. I just want to make sure we avoid redundancy as much as possible and work together trustfully and with equal rights. I always welcome technical contributions and I'm happy to support this new project with my vote. Best regards, Volker On Fri, Oct 27, 2017 at 10:12 AM, Per Liden wrote: > Hi Volker, > > On 2017-10-26 17:42, Volker Simonis wrote: > [...] >> >> 1. What are the benefits / advantages of ZGC over Shenandoah? > > > In my proposal I outlined some of the benefits we expect to achieve through > the current ZGC design. > > With respect to an evaluation of specifics of the ZGC implementation with > other approaches, I believe that's something that makes most sense to > discuss once the ZGC code is actually open source, and starts to move ahead > as part of the OpenJDK Community in a Project of its own, rather than in a > vacuum. > >> 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. > > > As Roman and Andrew have already mentioned, there are multiple possible > outcomes here (pick one, have both, merge them, etc), and only time and > experience with both code bases will help us here. This is just a proposal > for a new, independent ZGC project. It's not a proposal to merge ZGC into > the JDK itself. > > An important part here is that we make sure that adding GCs doesn't come > with an explosion in maintenance cost. The ongoing collaboration between > Oracle and Red Hat on the GC and Barrier APIs is key to making sure that > doesn't happen. > >> 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 CMS code base is complex to maintain. It's also not a collector we at > Oracle believe is a good foundation for any future work. By deprecating CMS > we've freed up resources at Oracle that can be invested in collectors we > believe will serve everyone better going forward. > > cheers, > Per From volker.simonis at gmail.com Mon Oct 30 00:26:03 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 29 Oct 2017 17:26:03 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: Vote: yes On Wed, Oct 25, 2017 at 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 From magnus.ihse.bursie at oracle.com Mon Oct 30 08:03:22 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 30 Oct 2017 09:03:22 +0100 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: Vote: yes /Magnus On 2017-10-27 21:28, Ron Pressler wrote: > 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 > > From aph at redhat.com Mon Oct 30 09:20:05 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Oct 2017 09:20:05 +0000 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: Vote: yes On 27/10/17 20:28, Ron Pressler wrote: > I hereby propose the creation of Project Loom with myself as the Lead and the? > HotSpot Group as the sponsoring Group. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Mon Oct 30 11:21:15 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 30 Oct 2017 12:21:15 +0100 Subject: CFV: New Project: ZGC In-Reply-To: References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: <889a38ed-57e9-004a-19ef-237ac21e473b@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From james.laskey at oracle.com Mon Oct 30 12:12:01 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 30 Oct 2017 09:12:01 -0300 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <08B9B7C6-5957-4706-AD34-37D9AEA432BD@oracle.com> Vote: Yes > On Oct 27, 2017, at 4:28 PM, Ron Pressler wrote: > > 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 > > From Roger.Riggs at Oracle.com Mon Oct 30 13:37:15 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 30 Oct 2017 09:37:15 -0400 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <7a0035fe-b37d-ed2d-22d3-7a51e0406119@Oracle.com> Vote: Yes On 10/27/2017 3:28 PM, Ron Pressler wrote: > I hereby propose the creation of Project Loom with myself as the Lead and the > HotSpot Group as the sponsoring Group. > From joe.darcy at oracle.com Mon Oct 30 16:49:00 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 30 Oct 2017 09:49:00 -0700 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <30b86347-5e4b-800f-5d13-a4a290682df1@oracle.com> Vote: yes -Joe From gnu.andrew at redhat.com Mon Oct 30 18:30:39 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 30 Oct 2017 18:30:39 +0000 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: On 25 October 2017 at 20:45, 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 Vote: Yes -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From stuart.marks at oracle.com Mon Oct 30 21:36:04 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 30 Oct 2017 14:36:04 -0700 Subject: CFV: New Project: ZGC In-Reply-To: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> References: <16d110f9-735c-1c48-0f5e-9e9ede2e1416@oracle.com> Message-ID: 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 From stuart.marks at oracle.com Mon Oct 30 21:36:19 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 30 Oct 2017 14:36:19 -0700 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: <5d497a35-b42f-0407-e77e-66fd39d5bc8e@oracle.com> Vote: yes On 10/27/17 12:28 PM, Ron Pressler wrote: > 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 > > From rodrigo.morales at polymtl.ca Mon Oct 30 22:29:42 2017 From: rodrigo.morales at polymtl.ca (Morales Rodrigo) Date: Mon, 30 Oct 2017 18:29:42 -0400 Subject: Are these patches were generated by human of by a tool? Message-ID: <89cf4e4f-c84b-5433-44de-41dd77d23f2f@polymtl.ca> Dear Developers, we are performing an empirical study at Polytechnique Montreal on software anti-patterns and refactoring and we need your inputs . We contact you because of your experience onJava developement. The context consists of 20 refactoring patches proposed by developers and an automated software tool. Your task (if you accept) consists on *identifying *if the refactoring patches were generated by adeveloperor by software tool, and tovotethem according to their quality. Your participation will allow us to collect data to understand the perspective of developers about refactoring and to improve automated approaches. This survey isanonymousand the collected data will be keptconfidential By answering this survey you could participate (optional) in a raffle for an*Amazon Card*with a value of*80 CAD*. Thanks for your contribution ! Survey link: http://www.swat.polymtl.ca/rmorales/refacturing/index.html Kind Regards, Rodrigo Morales Polytechnique Montreal http://www.swat.polymtl.ca/rmorales/ --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From brent.christian at oracle.com Tue Oct 31 17:31:54 2017 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 31 Oct 2017 10:31:54 -0700 Subject: CFV: New Project: Loom In-Reply-To: References: Message-ID: Vote: Yes On 10/27/2017 12:28 PM, Ron Pressler wrote: > I hereby propose the creation of Project Loom with myself as the Lead and the > HotSpot Group as the sponsoring Group. > From laurent.daynes at oracle.com Tue Oct 31 18:05:39 2017 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Tue, 31 Oct 2017 19:05:39 +0100 Subject: CFV: New Project: ZGC Message-ID: <59F8BB73.60503@oracle.com> Vote: yes On 25 October 2017 at 20:45, 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 Vote: Yes -- Andrew Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From laurent.daynes at oracle.com Tue Oct 31 18:06:15 2017 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Tue, 31 Oct 2017 19:06:15 +0100 Subject: CFV: New Project: Loom Message-ID: <59F8BB97.6060100@oracle.com> Vote: yes On 10/27/17 12:28 PM, Ron Pressler wrote: > 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 > >