From jiefu at tencent.com Tue Jun 1 03:38:58 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Tue, 1 Jun 2021 03:38:58 +0000 Subject: CFV: New JDK Committer: Hui Shi (hshi) Message-ID: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> I hereby nominate Hui Shi (hshi) [1] to JDK Committer. Hui Shi is a member of Tencent JDK team and working on OpenJDK development. He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. Votes are due by 4:00 UTC, 15 Jun 2021. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks. Best regards, Jie [1] https://openjdk.java.net/census#hshi [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#committer-vote From david.holmes at oracle.com Tue Jun 1 04:08:28 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Jun 2021 14:08:28 +1000 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: <81b6ab76-9ca4-761b-4b92-74f653a52c97@oracle.com> Vote: yes Thanks, David On 1/06/2021 1:38 pm, jiefu(??) wrote: > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK development. > > He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote > From johnsjiang at tencent.com Tue Jun 1 04:26:43 2021 From: johnsjiang at tencent.com (=?iso-2022-jp?B?am9obnNqaWFuZygbJEI5Pmg1GyhCKQ==?=) Date: Tue, 1 Jun 2021 04:26:43 +0000 Subject: CFV: New JDK Committer: Hui Shi (hshi)(Internet mail) References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> <81b6ab76-9ca4-761b-4b92-74f653a52c97@oracle.com> Message-ID: Vote: yes Best regards, John Jiang From stefan.karlsson at oracle.com Tue Jun 1 08:11:24 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 1 Jun 2021 10:11:24 +0200 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: <6963d7cd-4ecb-1fc7-887e-6da0812ad95c@oracle.com> Vote: yes StefanK On 2021-06-01 05:38, jiefu(??) wrote: > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK development. > > He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote From vladimir.x.ivanov at oracle.com Tue Jun 1 09:34:06 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 1 Jun 2021 12:34:06 +0300 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: <636724a7-20a0-7218-5e03-27d03cebfc1c@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 01.06.2021 06:38, jiefu(??) wrote: > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. From sgehwolf at redhat.com Tue Jun 1 09:46:29 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Jun 2021 11:46:29 +0200 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: <83185ed054ef7088cd4fc5c2d1170eb8c77f6823.camel@redhat.com> Vote: yes. On Tue, 2021-06-01 at 03:38 +0000, jiefu(??) wrote: > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. From zgu at redhat.com Tue Jun 1 13:32:37 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Jun 2021 09:32:37 -0400 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: <0020839d-6e28-9cdb-21bb-03eb15094a0a@redhat.com> Vote: yes -Zhengyu On 5/31/21 11:38 PM, jiefu(??) wrote: > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK development. > > He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote > From neugens.limasoftware at gmail.com Tue Jun 1 14:32:10 2021 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 1 Jun 2021 16:32:10 +0200 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: Vote: Yes, Cheers, Mario > On 1. Jun 2021, at 05:38, jiefu(??) wrote: > > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK development. > > He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ From lois.foltan at oracle.com Tue Jun 1 15:39:43 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 1 Jun 2021 11:39:43 -0400 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: Vote: yes Lois On 5/31/2021 11:38 PM, jiefu(??) wrote: > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK development. > > He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote From mark.reinhold at oracle.com Tue Jun 1 17:48:28 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 01 Jun 2021 10:48:28 -0700 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> Message-ID: <20210601104828.806937556@eggemoggin.niobe.net> 2021/5/19 16:14:03 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 406: Pattern Matching for switch (Preview) > https://openjdk.java.net/jeps/406 > > Summary: Enhance the Java programming language with pattern matching > for switch expressions and statements, along with extensions to the > language of patterns. Extending pattern matching to switch allows > an expression to be tested against a number of patterns, each with a > specific action, so that complex data-oriented queries can be expressed > concisely and safely. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Wednesday, 26 May, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From mark.reinhold at oracle.com Tue Jun 1 17:51:34 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 01 Jun 2021 10:51:34 -0700 Subject: JEP proposed to target JDK 17: 306: Restore Always-Strict Floating-Point Semantics In-Reply-To: <20210520230934.91CC63E4902@eggemoggin.niobe.net> References: <20210520230934.91CC63E4902@eggemoggin.niobe.net> Message-ID: <20210601105134.975492671@eggemoggin.niobe.net> 2021/5/20 16:09:34 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 306: Restore Always-Strict Floating-Point Semantics > https://openjdk.java.net/jeps/306 > > Summary: Make floating-point operations consistently strict, rather > than have both strict floating-point semantics (strictfp) and subtly > different default floating-point semantics. This will restore the > original floating-point semantics to the language and VM, matching the > semantics before the introduction of strict and default floating-point > modes in Java SE 1.2. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Thursday, 27 May, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From mark.reinhold at oracle.com Tue Jun 1 18:01:19 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 01 Jun 2021 11:01:19 -0700 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> Message-ID: <20210601110119.354658@eggemoggin.niobe.net> 2021/5/21 16:03:47 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 411: Deprecate the Security Manager for Removal > https://openjdk.java.net/jeps/411 > > Summary: Deprecate the Security Manager for removal in a future > release. The Security Manager dates from Java 1.0. It has not been the > primary means of securing client-side Java code for many years, and it > has rarely been used to secure server-side code. To move Java forward, > we intend to deprecate the Security Manager for removal in concert with > the legacy Applet API (JEP 398). > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Friday, 28 May, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 17. Hearing no objections from JDK Project Committers or Reviewers, I?ve target this JEP to JDK 17. - Mark From mark.reinhold at oracle.com Tue Jun 1 18:04:36 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 1 Jun 2021 11:04:36 -0700 (PDT) Subject: JEP proposed to target JDK 17: 415: Context-Specific Deserialization Filters Message-ID: <20210601180436.2EC183E5C98@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 415: Context-Specific Deserialization Filters https://openjdk.java.net/jeps/415 Summary: Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Tuesday, 8 June, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mike.rettig at gmail.com Tue Jun 1 18:48:37 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Tue, 1 Jun 2021 13:48:37 -0500 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: <20210601104828.806937556@eggemoggin.niobe.net> References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> <20210601104828.806937556@eggemoggin.niobe.net> Message-ID: >From the JEP: > It may be the case that future compilers of the Java language will emit warnings for legacy switch statements that are not complete. It would be ideal to add a compiler switch to make it an error instead of a warning on incomplete switches. Mike From brian.goetz at oracle.com Tue Jun 1 19:32:57 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 1 Jun 2021 15:32:57 -0400 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> <20210601104828.806937556@eggemoggin.niobe.net> Message-ID: We try very hard to stay away from this technique, for several reasons.? First, the language *has* a definition; compilers should, in general, implement that, not second-guess it.? And second, it doesn't scale; the endgame of that approach is that we end up with an ever-growing set of flags (possibly interacting!) for enforcing the top 10,000 most popular coding styles.? This is something better handled by IDEs or static analysis tools, where you can configure them to bark on the patterns you find problematic. But, you do have the option of using -Werror, which offers zero-tolerance for warnings, and then can turn on the lint warning categories of your choice. On 6/1/2021 2:48 PM, Mike Rettig wrote: > From the JEP: >> It may be the case that future compilers of the Java language will emit > warnings for legacy switch statements that are not complete. > > It would be ideal to add a compiler switch to make it an error instead of a > warning on incomplete switches. > > Mike From mike.rettig at gmail.com Tue Jun 1 20:32:15 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Tue, 1 Jun 2021 15:32:15 -0500 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> <20210601104828.806937556@eggemoggin.niobe.net> Message-ID: On Tue, Jun 1, 2021 at 2:33 PM Brian Goetz wrote: > We try very hard to stay away from this technique, for several reasons. > First, the language *has* a definition; compilers should, in general, > implement that, not second-guess it. And second, it doesn't scale; the > endgame of that approach is that we end up with an ever-growing set of > flags (possibly interacting!) for enforcing the top 10,000 most popular > coding styles. This is something better handled by IDEs or static analysis > tools, where you can configure them to bark on the patterns you find > problematic. > > But, you do have the option of using -Werror, which offers zero-tolerance > for warnings, and then can turn on the lint warning categories of your > choice. > Is this a style issue or a legacy code issue? Given that sealed types are being introduced with completeness, then it has to be a legacy code issue. With jigsaw, warnings were introduced to identify problematic code. These warnings later became errors. I hope the same treatment can be given to incomplete switches. Mike From forax at univ-mlv.fr Tue Jun 1 20:39:40 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 Jun 2021 22:39:40 +0200 (CEST) Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> <20210601104828.806937556@eggemoggin.niobe.net> Message-ID: <1863259912.1343080.1622579980395.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mike Rettig" > ?: "Brian Goetz" > Cc: "mark reinhold" , "jdk-dev" > Envoy?: Mardi 1 Juin 2021 22:32:15 > Objet: Re: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) > On Tue, Jun 1, 2021 at 2:33 PM Brian Goetz wrote: > >> We try very hard to stay away from this technique, for several reasons. >> First, the language *has* a definition; compilers should, in general, >> implement that, not second-guess it. And second, it doesn't scale; the >> endgame of that approach is that we end up with an ever-growing set of >> flags (possibly interacting!) for enforcing the top 10,000 most popular >> coding styles. This is something better handled by IDEs or static analysis >> tools, where you can configure them to bark on the patterns you find >> problematic. >> >> But, you do have the option of using -Werror, which offers zero-tolerance >> for warnings, and then can turn on the lint warning categories of your >> choice. >> > > Is this a style issue or a legacy code issue? Given that sealed types are > being introduced with completeness, then it has to be a legacy code issue. > With jigsaw, warnings were introduced to identify problematic code. These > warnings later became errors. I hope the same treatment can be given to > incomplete switches. It's the difference between an API point like setAccessible for jigsaw and a language construct, the statement switch, language constructs are forever not APIs. > > Mike R?mi From mike.rettig at gmail.com Tue Jun 1 20:48:26 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Tue, 1 Jun 2021 15:48:26 -0500 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: <1863259912.1343080.1622579980395.JavaMail.zimbra@u-pem.fr> References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> <20210601104828.806937556@eggemoggin.niobe.net> <1863259912.1343080.1622579980395.JavaMail.zimbra@u-pem.fr> Message-ID: On Tue, Jun 1, 2021 at 3:39 PM Remi Forax wrote: > ----- Mail original ----- > > It's the difference between an API point like setAccessible for jigsaw and > a language construct, the statement switch, > language constructs are forever not APIs. > > R?mi > The API point setAccessible is still forever. It just requires some options to enable it. The same can be done with switch or any other language construct that is deemed legacy. Mike From forax at univ-mlv.fr Tue Jun 1 20:55:55 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 1 Jun 2021 22:55:55 +0200 (CEST) Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> <20210601104828.806937556@eggemoggin.niobe.net> <1863259912.1343080.1622579980395.JavaMail.zimbra@u-pem.fr> Message-ID: <766746210.1344709.1622580955887.JavaMail.zimbra@u-pem.fr> > De: "Mike Rettig" > ?: "Remi Forax" > Cc: "Brian Goetz" , "mark reinhold" > , "jdk-dev" > Envoy?: Mardi 1 Juin 2021 22:48:26 > Objet: Re: JEP proposed to target JDK 17: 406: Pattern Matching for switch > (Preview) > On Tue, Jun 1, 2021 at 3:39 PM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> ----- Mail original ----- >> It's the difference between an API point like setAccessible for jigsaw and a >> language construct, the statement switch, >> language constructs are forever not APIs. >> R?mi > The API point setAccessible is still forever. It just requires some options to > enable it. The same can be done with switch or any other language construct > that is deemed legacy. setAccessible can be deprecated, so it's not forever, the hope is that the use of setAccessible will decay, and java.lang.invoke.Lookup will be used instead. > Mike R?mi From brian.goetz at oracle.com Tue Jun 1 21:07:45 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 1 Jun 2021 17:07:45 -0400 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> <20210601104828.806937556@eggemoggin.niobe.net> Message-ID: <8f0efa07-39c0-2bb0-84aa-93f64902560c@oracle.com> > Is this a style issue or a legacy code issue? Given that sealed types > are being introduced with completeness, then it has to be a legacy > code issue. With jigsaw, warnings were introduced to identify > problematic code. These warnings later became errors.? I hope the same > treatment can be given to incomplete switches. We hope that we can eventually upgrade these warnings to errors, after a sufficient period of notice.? But that could take a while. In the meantime, the language permits incomplete legacy statement switches. From mike.rettig at gmail.com Wed Jun 2 00:54:38 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Tue, 1 Jun 2021 19:54:38 -0500 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: <766746210.1344709.1622580955887.JavaMail.zimbra@u-pem.fr> References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> <20210601104828.806937556@eggemoggin.niobe.net> <1863259912.1343080.1622579980395.JavaMail.zimbra@u-pem.fr> <766746210.1344709.1622580955887.JavaMail.zimbra@u-pem.fr> Message-ID: On Tue, Jun 1, 2021 at 3:56 PM wrote: > > > setAccessible can be deprecated, so it's not forever, the hope is that the > use of setAccessible will decay, and java.lang.invoke.Lookup will be used > instead. > I'd certainly prefer a compile time failure to a runtime incompatibility. A compile time problem can be fixed immediately while a runtime error might be impossible to fix due to lack of ownership of the offending code. Deprecation of setAccessible would be okay with me, but actual removal is an impossibility given its widespread use. It is forever. Mike From felix.yang at huawei.com Wed Jun 2 02:02:23 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 2 Jun 2021 02:02:23 +0000 Subject: New JDK Committer: Hui Shi (hshi) Message-ID: Vote: yes > > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK > development. > > He has authored and co-authored 23 changes [2] to JDK project, many of > which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 > memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in > Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author- > name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c92 > 9a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote From tobias.hartmann at oracle.com Wed Jun 2 11:28:32 2021 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 2 Jun 2021 13:28:32 +0200 Subject: Result: New JDK Committer: Yi Yang Message-ID: Voting for Yi Yang [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Tobias [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005563.html From vicente.romero at oracle.com Wed Jun 2 17:45:30 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 2 Jun 2021 13:45:30 -0400 Subject: CFV: New JDK Committer: Guoxiong Li Message-ID: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. Guoxiong Li has contributed 39 patches to JDK [3], many of which are non-trivial, most of them in the javac compiler area. Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Vicente [1]https://openjdk.java.net/census [2]https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits From vicente.romero at oracle.com Wed Jun 2 17:48:37 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 2 Jun 2021 13:48:37 -0400 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <1eacadb4-b082-6218-ddc2-89cd0b5283b4@oracle.com> sorry that some of the links were off, please reply to this mail On 6/2/21 1:45 PM, Vicente Romero wrote: > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are > non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census > [2]https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > From jonathan.gibbons at oracle.com Wed Jun 2 17:51:25 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 2 Jun 2021 10:51:25 -0700 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <9876dbca-2472-ddf0-b755-3cf7fb342467@oracle.com> Vote: yes On 6/2/21 10:45 AM, Vicente Romero wrote: > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are > non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census > [2]https://openjdk.java.net/projects/#committer-vote > > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > > > From vicente.romero at oracle.com Wed Jun 2 17:53:40 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 2 Jun 2021 13:53:40 -0400 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <51f51861-827d-77f7-aea8-fa24e78354fd@oracle.com> vote: yes On 6/2/21 1:45 PM, Vicente Romero wrote: > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census > [2]https://openjdk.java.net/projects/#committer-vote > [3]https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits From james.laskey at oracle.com Wed Jun 2 18:10:09 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 2 Jun 2021 18:10:09 +0000 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <3433A14F-BAFE-4D28-92A6-2D56190AD781@oracle.com> Vote: yes ?? > On Jun 2, 2021, at 2:46 PM, Vicente Romero wrote: > > ?I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census > [2]https://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > From daniel.fuchs at oracle.com Wed Jun 2 18:22:41 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Jun 2021 19:22:41 +0100 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: Vote: yes best regards, -- daniel On 02/06/2021 18:45, Vicente Romero wrote: > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. From joe.darcy at oracle.com Wed Jun 2 18:40:16 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 2 Jun 2021 11:40:16 -0700 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <6649cfb0-245c-4382-f3f2-a8ad099458b5@oracle.com> Vote: yes -Joe On 6/2/2021 10:45 AM, Vicente Romero wrote: > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are > non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census > [2]https://openjdk.java.net/projects/#committer-vote > > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > > > From jan.lahoda at oracle.com Wed Jun 2 19:10:34 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 2 Jun 2021 21:10:34 +0200 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: Vote: yes Jan On 02. 06. 21 19:45, Vicente Romero wrote: > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are > non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census > [2]https://openjdk.java.net/projects/#committer-vote > > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > > > From vladimir.kozlov at oracle.com Wed Jun 2 19:56:45 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 Jun 2021 12:56:45 -0700 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: <1e37138f-da57-b352-9ab4-666705375032@oracle.com> Vote: yes Thanks, Vladimir K On 5/31/21 8:38 PM, jiefu(??) wrote: > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK development. > > He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote > From harold.seigel at oracle.com Wed Jun 2 20:03:40 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 2 Jun 2021 16:03:40 -0400 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <1eacadb4-b082-6218-ddc2-89cd0b5283b4@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> <1eacadb4-b082-6218-ddc2-89cd0b5283b4@oracle.com> Message-ID: <3417febc-77e4-4467-b764-4f4b6b91f30f@oracle.com> Vote: Yes Harold On 6/2/2021 1:48 PM, Vicente Romero wrote: > sorry that some of the links were off, please reply to this mail > > On 6/2/21 1:45 PM, Vicente Romero wrote: >> I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. >> >> Guoxiong Li has contributed 39 patches to JDK [3], many of which are >> non-trivial, most of them in the javac compiler area. >> >> Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. >> >> Only current JDK Committers [1] are eligible to vote on this >> nomination. Votes must be cast in the >> open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Best regards, >> Vicente >> >> [1]https://openjdk.java.net/census >> [2]https://openjdk.java.net/projects/#committer-vote >> [3] >> https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits >> > From lihuaming3 at huawei.com Thu Jun 3 01:11:28 2021 From: lihuaming3 at huawei.com (lihuaming (A)) Date: Thu, 3 Jun 2021 01:11:28 +0000 Subject: =?utf-8?B?562U5aSNOiBOZXcgSkRLIENvbW1pdHRlcjogR3VveGlvbmcgTGk=?= In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <51463e9ef6534cae892071f38cb154a8@huawei.com> Vote: yes -----????----- ???: jdk-dev [mailto:jdk-dev-retn at openjdk.java.net] ?? Vicente Romero ????: 2021?6?3? 1:46 ???: jdk-dev at openjdk.java.net ??: CFV: New JDK Committer: Guoxiong Li I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. Guoxiong Li has contributed 39 patches to JDK [3], many of which are non-trivial, most of them in the javac compiler area. Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Vicente [1]https://openjdk.java.net/census [2]https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits From joel.p.borggren-franck at oracle.com Thu Jun 3 07:44:43 2021 From: joel.p.borggren-franck at oracle.com (Joel Borggren-Franck) Date: Thu, 3 Jun 2021 07:44:43 +0000 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: Vote: yes cheers /Joel > On 2 Jun 2021, at 19:45, Vicente Romero wrote: > > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census > [2]https://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > From adinn at redhat.com Thu Jun 3 08:35:13 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 3 Jun 2021 09:35:13 +0100 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <3dc22fb5-ab00-97bf-8f94-d0ba8449694c@redhat.com> Vote: yes On 02/06/2021 18:45, Vicente Romero wrote: > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are > non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census? > [2]https://openjdk.java.net/projects/#committer-vote > > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > > > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From neugens.limasoftware at gmail.com Thu Jun 3 08:44:04 2021 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 3 Jun 2021 10:44:04 +0200 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <3dc22fb5-ab00-97bf-8f94-d0ba8449694c@redhat.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> <3dc22fb5-ab00-97bf-8f94-d0ba8449694c@redhat.com> Message-ID: <5a7e9a09-0a5b-407a-ba8c-66028ebf4aed@Canary> Vote: yes, Cheers, Mario ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ > On Thursday, Jun 03, 2021 at 10:35, Andrew Dinn wrote: > Vote: yes > > On 02/06/2021 18:45, Vicente Romero wrote: > > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are > > non-trivial, most of them in the javac compiler area. > > > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the > > open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [2]. > > > > Best regards, > > Vicente > > > > [1]https://openjdk.java.net/census > > [2]https://openjdk.java.net/projects/#committer-vote > > > > [3] > > https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > > > > > > > > -- > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From felixxfyang at tencent.com Thu Jun 3 08:56:07 2021 From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=) Date: Thu, 3 Jun 2021 08:56:07 +0000 Subject: New JDK Committer: Hui Shi (hshi)(Internet mail) Message-ID: <86DE38AA-1037-47DE-8965-65356A63E8A9@tencent.com> Vote: yes Cheers, Felix Yang ?? 2021/6/3 ??3:58??jdk-dev ?? Vladimir Kozlov? ??: Vote: yes Thanks, Vladimir K On 5/31/21 8:38 PM, jiefu(??) wrote: > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK development. > > He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote > From jiefu at tencent.com Thu Jun 3 09:07:56 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Thu, 3 Jun 2021 09:07:56 +0000 Subject: New JDK Committer: Guoxiong Li Message-ID: Vote: yes Best regards, Jie ?On 2021/6/3, 4:45 PM, "jdk-dev on behalf of Mario Torre" wrote: Vote: yes, Cheers, Mario ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ > On Thursday, Jun 03, 2021 at 10:35, Andrew Dinn wrote: > Vote: yes > > On 02/06/2021 18:45, Vicente Romero wrote: > > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are > > non-trivial, most of them in the javac compiler area. > > > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the > > open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [2]. > > > > Best regards, > > Vicente > > > > [1]https://openjdk.java.net/census > > [2]https://openjdk.java.net/projects/#committer-vote > > > > [3] > > https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > > > > > > > > -- > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From maurizio.cimadamore at oracle.com Thu Jun 3 10:10:26 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 11:10:26 +0100 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <66077837-0c44-e04f-3325-7f1ac637df6e@oracle.com> Vote: yes! Maurizio On 02/06/2021 18:45, Vicente Romero wrote: > I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. > > Guoxiong Li has contributed 39 patches to JDK [3], many of which are > non-trivial, most of them in the javac compiler area. > > Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Vicente > > [1]https://openjdk.java.net/census > [2]https://openjdk.java.net/projects/#committer-vote > > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits > > > From maurizio.cimadamore at oracle.com Thu Jun 3 10:11:00 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 11:11:00 +0100 Subject: CFV: New JDK Committer: Guoxiong Li In-Reply-To: <1eacadb4-b082-6218-ddc2-89cd0b5283b4@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> <1eacadb4-b082-6218-ddc2-89cd0b5283b4@oracle.com> Message-ID: <2c4341bd-dc34-c540-c5a8-af80f8f23cc5@oracle.com> Vote: yes! Maurizio On 02/06/2021 18:48, Vicente Romero wrote: > sorry that some of the links were off, please reply to this mail > > On 6/2/21 1:45 PM, Vicente Romero wrote: >> I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. >> >> Guoxiong Li has contributed 39 patches to JDK [3], many of which are >> non-trivial, most of them in the javac compiler area. >> >> Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. >> >> Only current JDK Committers [1] are eligible to vote on this >> nomination. Votes must be cast in the >> open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Best regards, >> Vicente >> >> [1]https://openjdk.java.net/census >> [2]https://openjdk.java.net/projects/#committer-vote >> [3] >> https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits >> > From felixxfyang at tencent.com Thu Jun 3 11:34:57 2021 From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=) Date: Thu, 3 Jun 2021 11:34:57 +0000 Subject: New JDK Committer: Guoxiong Li(Internet mail) In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <2E5AF86E-330A-4E87-9C6C-696A3BF1D967@tencent.com> Vote: Yes Thanks, Felix Yang ?? 2021/6/3 ??1:47??jdk-dev ?? Vicente Romero? ??: I hereby nominate Guoxiong Li (lgxbslgx) to JDK Committer. Guoxiong Li has contributed 39 patches to JDK [3], many of which are non-trivial, most of them in the javac compiler area. Votes are due by Wednesday, June 16th 2021 at 10:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Vicente [1]https://openjdk.java.net/census [2]https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Guoxiong+Li%22&type=commits From mark.reinhold at oracle.com Thu Jun 3 15:11:04 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 3 Jun 2021 08:11:04 -0700 (PDT) Subject: JDK 17 enters Rampdown Phase One next week Message-ID: <20210603151104.799543E61EC@eggemoggin.niobe.net> JDK 17 enters Rampdown Phase One next week on Thursday, 10 June. Changes intended for JDK 17 should be in the main-line repository (https://github.com/openjdk/jdk) by 15:00 UTC on that day [1]. At that time we?ll fork the main line to the JDK 17 stabilization repository, jdk17, and promote next week?s build and all remaining JDK 17 builds from there. We?ll semi-automatically merge changes pushed to jdk17 into the main-line repository, as we have in previous feature-release transitions. This means that: - If you make a change in JDK 17 then you needn?t do any extra work to get it into the main line, though if a merge conflict arises then you might be asked to help resolve it. - If you need to make a change in both JDK 17 and the main line then just push it to JDK 17, and wait for the automatic merge to complete. Changes pushed to the main line after 15:00 UTC next Thursday will be bound for JDK 18 only, unless they?re subsequently back-ported to JDK 17. The Rampdown Phase One process is defined in JEP 3 [2]. To answer a potential FAQ: Now that we?ve moved over to Git, why don?t we just use a branch in the main-line repository for JDK 17 stabilization work? A few of us have given that some thought, but a change of that scope requires a fair amount of preparation and coordination. We hope to revisit that option for JDK 18. - Mark [1] https://time.is/1500_10_June_2021_in_UTC/Stockholm/London/Boston/San_Francisco?JDK_17_Rampdown_Phase_One [2] https://openjdk.java.net/jeps/3 From qingfeng.yy at alibaba-inc.com Sat Jun 5 02:02:37 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Sat, 05 Jun 2021 10:02:37 +0800 Subject: =?UTF-8?B?UmU6IENGVjogTmV3IEpESyBDb21taXR0ZXI6IEh1aSBTaGkgKGhzaGkp?= In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: Vote: yes Best regards, Yang ------------------------------------------------------------------ From:jiefu(??) Send Time:2021 Jun. 1 (Tue.) 11:39 To:jdk-dev Subject:CFV: New JDK Committer: Hui Shi (hshi) I hereby nominate Hui Shi (hshi) [1] to JDK Committer. Hui Shi is a member of Tencent JDK team and working on OpenJDK development. He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. Votes are due by 4:00 UTC, 15 Jun 2021. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks. Best regards, Jie [1] https://openjdk.java.net/census#hshi [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#committer-vote From mark at lawinegevaar.nl Sat Jun 5 09:53:21 2021 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 5 Jun 2021 11:53:21 +0200 Subject: Java 2.0 migration planning. JEP's for removal. In-Reply-To: References: Message-ID: <0c038c5e-13d8-db79-1f7f-b5804ffa90f5@lawinegevaar.nl> On 24-05-2021 03:09, jini at zeus.net.au wrote: > Thinking we are going to need to maintain two separate forks of our > software to support both Java 2.0 and Java 1.8 to 1.17. Java 2 was the marketing term for Java 1.2 back in the 1998. There is no Java 1.17, it's Java 17. Mark -- Mark Rotteveel From kim.barrett at oracle.com Mon Jun 7 01:34:43 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Jun 2021 01:34:43 +0000 Subject: CFV: New JDK Committer: Hui Shi (hshi) In-Reply-To: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> References: <98D9A257-DA2B-4B7C-A0D9-67B09413618E@tencent.com> Message-ID: vote: yes > On May 31, 2021, at 11:38 PM, jiefu(??) wrote: > > I hereby nominate Hui Shi (hshi) [1] to JDK Committer. > > > > Hui Shi is a member of Tencent JDK team and working on OpenJDK development. > > He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. > > Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. > > In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. > > > > Votes are due by 4:00 UTC, 15 Jun 2021. > > > > Only current JDK Committers [3] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://openjdk.java.net/census#hshi > > [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits > > https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 > > [3] https://openjdk.java.net/census > > [4] https://openjdk.java.net/projects/#committer-vote From jiefu at tencent.com Mon Jun 7 01:59:09 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Mon, 7 Jun 2021 01:59:09 +0000 Subject: FW: New JDK Committer: Hui Shi (hshi) In-Reply-To: <9C5C2EFF-2CB1-4AB5-B780-86C67E37F363@tencent.com> References: <9C5C2EFF-2CB1-4AB5-B780-86C67E37F363@tencent.com> Message-ID: Forward it since my previous voting didn't get into the correct jdk-dev mailing list. ?On 2021/6/7, 9:35 AM, "jiefu(??)" wrote: Vote: yes Best regards, Jie ------------------------------------------------------------------ From:jiefu(??) Send Time:2021 Jun. 1 (Tue.) 11:39 To:jdk-dev Subject:CFV: New JDK Committer: Hui Shi (hshi) I hereby nominate Hui Shi (hshi) [1] to JDK Committer. Hui Shi is a member of Tencent JDK team and working on OpenJDK development. He has authored and co-authored 23 changes [2] to JDK project, many of which are non-trivial. Before he joined Tencent, he mainly worked on aarch64, including general C2 memory barrier optimizations, aarch64 intrinsic refactoring and bug fixing. In the last 8 months, he had contributed 10 optimizations/fixes found in Tencent products into JDK project. Votes are due by 4:00 UTC, 15 Jun 2021. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks. Best regards, Jie [1] https://openjdk.java.net/census#hshi [2] https://github.com/openjdk/jdk/search?o=desc&q=author-name%3A%22Hui%20Shi%22&s=committer-date&type=commits https://github.com/openjdk/jdk/commit/aba22656829913d5f8d619a184c929a7de8431e4 [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#committer-vote From volker.simonis at gmail.com Tue Jun 8 10:34:29 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Jun 2021 12:34:29 +0200 Subject: CFV: New JDK Committer: Xin Liu Message-ID: I hereby nominate Xin Liu (xliu) to JDK Committer. Xin is a member of the Corretto team at Amazon and has contributed 42 patches in the JDK project since 2018 [1]. He mostly works on the C2 JIT compiler and has recently authored the support for asynchronous logging. A list of selected patches can be found at the end of this mail. Votes are due by 12:00 CET June 22, 2021. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thank you and best regards, Volker [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#committer-vote Selected patches: 1. 8222670: pathological case of JIT recompilation and code cache bloat https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 2. 8229450: C2 compilation fails with assert(found_sfpt) failed https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 3. 8022574: remove HaltNode code after uncommon trap calls https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 5. 8151779: Some intrinsic flags could be replaced with one general flag https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 6. 8206075: On x86, assert on unbound assembler Labels used as branch target https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 7. 8254369: Node::disconnect_inputs may skip precedences https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f 8. 8261675: ObjectValue::set_visited(bool) sets _visited false https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a 10. 8229517: Support for optional asynchronous/buffered logging https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 11. 8257800: CompileCommand TypedMethodOptionMatcher::parse_method_pattern() may over consume https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 12. 8251464: make Node::dump(int depth) support indent https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 From jiefu at tencent.com Tue Jun 8 10:48:29 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Tue, 8 Jun 2021 10:48:29 +0000 Subject: New JDK Committer: Xin Liu(Internet mail) In-Reply-To: References: Message-ID: Vote: yes. Best regards, Jie ?On 2021/6/8, 6:36 PM, "jdk-dev on behalf of Volker Simonis" wrote: I hereby nominate Xin Liu (xliu) to JDK Committer. Xin is a member of the Corretto team at Amazon and has contributed 42 patches in the JDK project since 2018 [1]. He mostly works on the C2 JIT compiler and has recently authored the support for asynchronous logging. A list of selected patches can be found at the end of this mail. Votes are due by 12:00 CET June 22, 2021. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thank you and best regards, Volker [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#committer-vote Selected patches: 1. 8222670: pathological case of JIT recompilation and code cache bloat https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 2. 8229450: C2 compilation fails with assert(found_sfpt) failed https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 3. 8022574: remove HaltNode code after uncommon trap calls https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 5. 8151779: Some intrinsic flags could be replaced with one general flag https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 6. 8206075: On x86, assert on unbound assembler Labels used as branch target https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 7. 8254369: Node::disconnect_inputs may skip precedences https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f 8. 8261675: ObjectValue::set_visited(bool) sets _visited false https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a 10. 8229517: Support for optional asynchronous/buffered logging https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 11. 8257800: CompileCommand TypedMethodOptionMatcher::parse_method_pattern() may over consume https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 12. 8251464: make Node::dump(int depth) support indent https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 From thomas.stuefe at gmail.com Tue Jun 8 11:01:09 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 8 Jun 2021 13:01:09 +0200 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: Vote: yes On Tue, Jun 8, 2021 at 12:35 PM Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] > https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch > target > > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > From qingfeng.yy at alibaba-inc.com Tue Jun 8 11:05:31 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Tue, 08 Jun 2021 19:05:31 +0800 Subject: =?UTF-8?B?UmU6IENGVjogTmV3IEpESyBDb21taXR0ZXI6IFhpbiBMaXU=?= In-Reply-To: References: Message-ID: Vote:yes Best regards, Yang ------------------------------------------------------------------ From:Volker Simonis Send Time:2021 Jun. 8 (Tue.) 18:46 To:jdk-dev Subject:CFV: New JDK Committer: Xin Liu I hereby nominate Xin Liu (xliu) to JDK Committer. Xin is a member of the Corretto team at Amazon and has contributed 42 patches in the JDK project since 2018 [1]. He mostly works on the C2 JIT compiler and has recently authored the support for asynchronous logging. A list of selected patches can be found at the end of this mail. Votes are due by 12:00 CET June 22, 2021. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thank you and best regards, Volker [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#committer-vote Selected patches: 1. 8222670: pathological case of JIT recompilation and code cache bloat https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 2. 8229450: C2 compilation fails with assert(found_sfpt) failed https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 3. 8022574: remove HaltNode code after uncommon trap calls https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 5. 8151779: Some intrinsic flags could be replaced with one general flag https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 6. 8206075: On x86, assert on unbound assembler Labels used as branch target https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 7. 8254369: Node::disconnect_inputs may skip precedences https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f 8. 8261675: ObjectValue::set_visited(bool) sets _visited false https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a 10. 8229517: Support for optional asynchronous/buffered logging https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 11. 8257800: CompileCommand TypedMethodOptionMatcher::parse_method_pattern() may over consume https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 12. 8251464: make Node::dump(int depth) support indent https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 From vladimir.x.ivanov at oracle.com Tue Jun 8 11:24:23 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 8 Jun 2021 14:24:23 +0300 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: <77e3020c-527f-c10e-2ab1-9870a47da5d1@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 08.06.2021 13:34, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. From matthias.baesken at sap.com Tue Jun 8 11:26:31 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 8 Jun 2021 11:26:31 +0000 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: Vote : Yes Best regards, Matthias From felixxfyang at tencent.com Tue Jun 8 11:29:28 2021 From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=) Date: Tue, 8 Jun 2021 11:29:28 +0000 Subject: New JDK Committer: Xin Liu(Internet mail) In-Reply-To: References: Message-ID: Vote: Yes Cheers, Felix Yang ?? 2021/6/8 ??6:35??jdk-dev ?? Volker Simonis? ??: I hereby nominate Xin Liu (xliu) to JDK Committer. Xin is a member of the Corretto team at Amazon and has contributed 42 patches in the JDK project since 2018 [1]. He mostly works on the C2 JIT compiler and has recently authored the support for asynchronous logging. A list of selected patches can be found at the end of this mail. Votes are due by 12:00 CET June 22, 2021. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thank you and best regards, Volker [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#committer-vote Selected patches: 1. 8222670: pathological case of JIT recompilation and code cache bloat https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 2. 8229450: C2 compilation fails with assert(found_sfpt) failed https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 3. 8022574: remove HaltNode code after uncommon trap calls https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 5. 8151779: Some intrinsic flags could be replaced with one general flag https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 6. 8206075: On x86, assert on unbound assembler Labels used as branch target https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 7. 8254369: Node::disconnect_inputs may skip precedences https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f 8. 8261675: ObjectValue::set_visited(bool) sets _visited false https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a 10. 8229517: Support for optional asynchronous/buffered logging https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 11. 8257800: CompileCommand TypedMethodOptionMatcher::parse_method_pattern() may over consume https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 12. 8251464: make Node::dump(int depth) support indent https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 From adinn at redhat.com Tue Jun 8 11:44:56 2021 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 8 Jun 2021 12:44:56 +0100 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: <08ddeaf9-6c7e-0164-6efa-901bcdc9552c@redhat.com> Vote: yes On 08/06/2021 11:34, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch target > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Tue Jun 8 11:48:47 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 Jun 2021 13:48:47 +0200 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: <17a43305f536da19a866d0f2697f652cc49a5f9a.camel@redhat.com> Vote: yes. On Tue, 2021-06-08 at 12:34 +0200, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. From christian.hagedorn at oracle.com Tue Jun 8 11:52:32 2021 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 8 Jun 2021 13:52:32 +0200 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: <03d648e4-c4b0-ad76-7426-b14516cf3a00@oracle.com> Vote: Yes Best regards Christian On 08.06.21 12:34, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch target > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > From volker.simonis at gmail.com Tue Jun 8 12:13:40 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Jun 2021 14:13:40 +0200 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: Vote: yes Volker Simonis schrieb am Di., 8. Juni 2021, 12:34: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] > https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch > target > > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > From zgu at redhat.com Tue Jun 8 12:30:02 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 8 Jun 2021 08:30:02 -0400 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: <41784fca-2df1-8eed-74ad-990a73a5451c@redhat.com> Vote: yes. -Zhengyu On 6/8/21 6:34 AM, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch target > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > From david.holmes at oracle.com Tue Jun 8 12:44:28 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Jun 2021 22:44:28 +1000 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: Vote: yes Cheers, David On 8/06/2021 8:34 pm, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch target > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > From hohensee at amazon.com Tue Jun 8 14:02:18 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 8 Jun 2021 14:02:18 +0000 Subject: CFV: New JDK Committer: Xin Liu Message-ID: Vote: yes. ?-----Original Message----- From: jdk-dev on behalf of Volker Simonis Date: Tuesday, June 8, 2021 at 3:35 AM To: jdk-dev Subject: CFV: New JDK Committer: Xin Liu I hereby nominate Xin Liu (xliu) to JDK Committer. Xin is a member of the Corretto team at Amazon and has contributed 42 patches in the JDK project since 2018 [1]. He mostly works on the C2 JIT compiler and has recently authored the support for asynchronous logging. A list of selected patches can be found at the end of this mail. Votes are due by 12:00 CET June 22, 2021. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thank you and best regards, Volker [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#committer-vote Selected patches: 1. 8222670: pathological case of JIT recompilation and code cache bloat https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 2. 8229450: C2 compilation fails with assert(found_sfpt) failed https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 3. 8022574: remove HaltNode code after uncommon trap calls https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 5. 8151779: Some intrinsic flags could be replaced with one general flag https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 6. 8206075: On x86, assert on unbound assembler Labels used as branch target https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 7. 8254369: Node::disconnect_inputs may skip precedences https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f 8. 8261675: ObjectValue::set_visited(bool) sets _visited false https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a 10. 8229517: Support for optional asynchronous/buffered logging https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 11. 8257800: CompileCommand TypedMethodOptionMatcher::parse_method_pattern() may over consume https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 12. 8251464: make Node::dump(int depth) support indent https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 From suenaga at oss.nttdata.com Tue Jun 8 15:07:15 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 9 Jun 2021 00:07:15 +0900 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: Vote: yes Yasumasa On 2021/06/08 19:34, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch target > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > From vladimir.kozlov at oracle.com Tue Jun 8 15:29:57 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 8 Jun 2021 08:29:57 -0700 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: <3cd73391-67c1-d8f1-1270-675dc07c4ad8@oracle.com> Vote: yes Thanks, Vladimir K On 6/8/21 3:34 AM, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch target > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > From christoph.langer at sap.com Tue Jun 8 19:10:26 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 Jun 2021 19:10:26 +0000 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Volker > Simonis > Sent: Dienstag, 8. Juni 2021 12:34 > To: jdk-dev > Subject: CFV: New JDK Committer: Xin Liu > > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author- > name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=com > mitter-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72 > f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f > 079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89 > b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61 > 896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa > 2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch > target > > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759 > c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c39 > 32b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738f > c8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407 > d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633 > 777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306 > 128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3 > 628450c796 From mark.reinhold at oracle.com Wed Jun 9 00:07:05 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 08 Jun 2021 17:07:05 -0700 Subject: JEP proposed to target JDK 17: 415: Context-Specific Deserialization Filters In-Reply-To: <20210601180436.2EC183E5C98@eggemoggin.niobe.net> References: <20210601180436.2EC183E5C98@eggemoggin.niobe.net> Message-ID: <20210608170705.632269642@eggemoggin.niobe.net> 2021/6/1 11:04:36 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 415: Context-Specific Deserialization Filters > https://openjdk.java.net/jeps/415 > > Summary: Allow applications to configure context-specific and > dynamically-selected deserialization filters via a JVM-wide filter > factory that is invoked to select a filter for each individual > deserialization operation. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Tuesday, 8 June, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From peter.firmstone at zeus.net.au Wed Jun 9 01:35:25 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 9 Jun 2021 11:35:25 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. Message-ID: Apologies in advance if this seems like paranoid security. As you are likely now aware, we have been using SecurityManager a little differently than recommended as we adapted it to our requirements. Sometimes it's not always easy to explain or obvious why something is done in a certain way. It's clear we can use StackWalker to implement AccessController functionality.? And it's also clear we can use ThreadLocal or Scope Local's to preserve the user Subject across threads. Going forward we will need low level hooks in the JDK for our authentication layer, clearly this is an opportunity to further simplify and improve our authentication layer. Because we use a remote service architecture, with proxy's, the proxy's are dynamically granted permission's after Service Authentication, these permissions also require the user principal to be logged in, we may have a number of services on the stack, for example to participate in a transaction. We have a tool to generate least privilege policy files. There are two reasons we do this: 1. Simplicity of administration and auditing of policy files. 2. Limit the permissions of code, and grant certain permissions to users to ensure users are authenticated before allowing data parsing. An example of item two, is our services require users to be logged in to ensure that any data provided by the user is a trusted data source (we still check the data).?? We re-implemented a subset of Java Serialization and have a DeSerializationPermission, which is granted to Principals of users. If a user is not logged in, data cannot be de-serialized, because the code alone doesn't have permission to do so. Hopefully modules and packages will have strong encapsulation in future so we don't need permission's like java.lang.RuntimePermission "accessClassInPackage.*"? No doubt we will need to create our own Permission's. We would like to be able to limit data parsing, like XML or Java de-serialization, to logged in users only. We don't break encapsulation, in future we will only use reflection to call public methods and constructors (we are currently in the process of doing so).?? Our build systems use Maven, our build is modular. I would also like to request that all JDK modules be given ProtectionDomain's following SecurityManager deprecation. Currently some modules have null ProtectionDomain's to show they have AllPermission.? However we don't grant AllPermission to code in practise, we like to grant certain Permission's to Principal's, not code, where the Principal is the source of data, indicating the user has been authenticated and we only grant what's necessary and no more. Examples of permission's granted to JDK modules in POLP policy files, taken from a test harness: grant codebase "jrt:/jdk.security.jgss" { ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; ??? permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; }; grant codebase "jrt:/jdk.crypto.mscapi" { ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; ??? permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; ??? permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; }; grant codebase "jrt:/jdk.localedata" { ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "jrt:/jdk.security.auth" { ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; ??? permission javax.security.auth.AuthPermission "modifyPrincipals"; ??? permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; ??? permission javax.security.auth.AuthPermission "modifyPublicCredentials"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; ??? permission java.lang.RuntimePermission "getProtectionDomain"; }; Example of POLP grant to code with principal, code alone cannot access these, in case you are wondering, we use this to secure the RMI Registry using stateless TLSv1.3, it's used by our Service Watchdog, or Service Activation framework called Phoenix, it's the sole use we have of the Java RMI JRMP protocol, in cases where this isn't used we can disable Java Serialization completely: grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", ??? principal javax.security.auth.x500.X500Principal "CN=Phoenix" { ??? permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; ??? permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; ??? permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; ??? permission java.io.FilePermission "harness\\trust\\truststore", "read"; ??? permission java.net.SocketPermission "localhost:1098", "listen,resolve"; }; If we really want to get into detail, instances of GrantPermission shows the permissions that are granted dynamically, in this case you can see that provided the Mahalo Service is run with it's principal CN=Mahalo, it has permission to de-serialize a MarshalledObject (it doesn't actually unmarshall it though, it uses it for equals comparison), the GrantPermission shows that it grants permission to de-serialize (ATOMIC, which means atomic input validation, prior to object creation), after authenticating the proxy's service. grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/mahalo-service-3.1.1-SNAPSHOT.jar", ??? principal javax.security.auth.x500.X500Principal "CN=Mahalo" { ??? permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; ??? permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; ??? permission org.apache.river.phoenix.dl.MonitorPermission "net.jini.activation.arg.ActivationMonitor.inactiveObject"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Mahalo\"", "connect"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Mahalo\"", "listen"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Mahalo\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; ??? permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1024-", "connect,resolve"; ??? permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1024-", "accept,resolve"; ??? permission java.net.SocketPermission "localhost:0", "listen,resolve"; ??? permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Phoenix\\\"\", \"connect\";"; ??? permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\"; net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Outrigger\\\"\", \"connect\";"; ??? permission net.jini.security.GrantPermission "org.apache.river.api.io.DeSerializationPermission \"ATOMIC\"; org.apache.river.api.io.DeSerializationPermission \"MARSHALL\"; org.apache.river.api.io.DeSerializationPermission \"ATOMIC\"; java.lang.RuntimePermission \"accessClassInPackage.com.sun.proxy\", \"\";"; ??? permission javax.security.auth.AuthPermission "getSubject"; ??? permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "delete"; ??? permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "write"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\mahalo-dl-3.1.1-SNAPSHOT.jar", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\mahalo-service-3.1.1-SNAPSHOT.jar", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\mahalo.keystore", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\outrigger.keystore", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; ??? permission java.lang.RuntimePermission "getClassLoader"; ??? permission java.lang.RuntimePermission "modifyThread"; ??? permission net.jini.discovery.DiscoveryPermission "QATestDefaultGroup_DESKTOP-R0ORPA2_1623111918992"; }; -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From ningsheng.jian at arm.com Wed Jun 9 03:13:06 2021 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 9 Jun 2021 11:13:06 +0800 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: <867b08af-514e-edb2-b5a0-de54d2e63bb2@arm.com> Vote: yes Thanks, Ningsheng On 6/8/21 6:34 PM, Volker Simonis wrote: > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch target > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 > From sean.mullan at oracle.com Wed Jun 9 15:07:33 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Jun 2021 11:07:33 -0400 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: On 6/8/21 9:35 PM, Peter Firmstone wrote: > I would also like to request that all JDK modules be given > ProtectionDomain's following SecurityManager deprecation. Currently some > modules have null ProtectionDomain's to show they have AllPermission. > However we don't grant AllPermission to code in practise, we like to > grant certain Permission's to Principal's, not code, where the Principal > is the source of data, indicating the user has been authenticated and we > only grant what's necessary and no more. As described in JEP 411, there are no plans to deprecate ProtectionDomain at this time. --Sean From peter.firmstone at zeus.net.au Thu Jun 10 02:49:09 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 10 Jun 2021 12:49:09 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: Hi Sean, Sorry I've confused you. What I should have said is a ProtectionDomain with a null CodeSource. What I mean to ask is, where ProtectionDomain is created with a null CodeSource, in Class::getProtectionDomain() can we have CodeSource's that represents system modules instead of null? A CodeSource with URL's like jrt:/jdk.* or jrt:/java.*? for system modules? Hopefully my comments below will make a little more sense now. Regards, Peter. On 10/06/2021 1:07 am, Sean Mullan wrote: > > > On 6/8/21 9:35 PM, Peter Firmstone wrote: >> I would also like to request that all JDK modules be given >> ProtectionDomain's following SecurityManager deprecation. Currently >> some modules have null ProtectionDomain's to show they have >> AllPermission.? However we don't grant AllPermission to code in >> practise, we like to grant certain Permission's to Principal's, not >> code, where the Principal is the source of data, indicating the user >> has been authenticated and we only grant what's necessary and no more. > > As described in JEP 411, there are no plans to deprecate > ProtectionDomain at this time. > > --Sean From felix.yang at huawei.com Thu Jun 10 05:57:35 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 10 Jun 2021 05:57:35 +0000 Subject: New JDK Committer: Xin Liu Message-ID: <2ec31c508bc74ba0b66e2f4fa74cd341@huawei.com> Vote: yes > > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 JIT > compiler and has recently authored the support for asynchronous logging. A > list of selected patches can be found at the end of this mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author- > name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=com > mitter-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e7 > 2f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f > 079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e8 > 9b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61 > 896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa > 2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch > target > > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759 > c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3 > 932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738f > c8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407 > d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633 > 777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306 > 128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a > 3628450c796 From Alan.Bateman at oracle.com Thu Jun 10 06:22:24 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Jun 2021 07:22:24 +0100 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: On 10/06/2021 03:49, Peter Firmstone wrote: > Hi Sean, > > Sorry I've confused you. > > What I should have said is a ProtectionDomain with a null CodeSource. > > What I mean to ask is, where ProtectionDomain is created with a null > CodeSource, in Class::getProtectionDomain() can we have CodeSource's > that represents system modules instead of null? > > A CodeSource with URL's like jrt:/jdk.* or jrt:/java.*? for system > modules? This is already the case for system modules that are mapped to the platform or application class loaders. I think your question is about modules that are mapped to the boot loader and whether they should get a unique PD that includes a useful code source rather than using a "shared" PD. That would be changing long standing behavior and would require careful analysis to see if anything would break. -Alan From peter.firmstone at zeus.net.au Thu Jun 10 06:37:04 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 10 Jun 2021 16:37:04 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: Thanks Alan, You've hit the nail on the head. In policy implementations, a null CodeSource in PD, is assigned AllPermission.?? So it would require adding grant statements for these modules in the default policy file that ships with the JVM. I thought it's an opportunity to make ProtectionDomain a little more useful if it maps to modules. Gut feel is it would be relatively low risk, but as you correctly state, would require testing. I'm not able to lodge on Jira, but I thought this would be worthy update. Regards, Peter. On 10/06/2021 4:22 pm, Alan Bateman wrote: > On 10/06/2021 03:49, Peter Firmstone wrote: >> Hi Sean, >> >> Sorry I've confused you. >> >> What I should have said is a ProtectionDomain with a null CodeSource. >> >> What I mean to ask is, where ProtectionDomain is created with a null >> CodeSource, in Class::getProtectionDomain() can we have CodeSource's >> that represents system modules instead of null? >> >> A CodeSource with URL's like jrt:/jdk.* or jrt:/java.*? for system >> modules? > > This is already the case for system modules that are mapped to the > platform or application class loaders. I think your question is about > modules that are mapped to the boot loader and whether they should get > a unique PD that includes a useful code source rather than using a > "shared" PD. That would be changing long standing behavior and would > require careful analysis to see if anything would break. > > -Alan From mark.reinhold at oracle.com Thu Jun 10 16:40:36 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 10 Jun 2021 09:40:36 -0700 (PDT) Subject: JDK 17 is now in Rampdown Phase One Message-ID: <20210610164036.AEC0D3E87F6@eggemoggin.niobe.net> Per the JDK 17 schedule [1], we are now in Rampdown Phase One. The overall feature set is frozen. No further JEPs will be targeted to this release. We?ve forked the main-line source repository to the jdk17 stabilization repository (https://github.com/openjdk/jdk17). Any changes pushed to the main line are now bound for JDK 18, as noted previously [2]. The stabilization repository is open for select bug fixes and, with approval, late enhancements per JEP 3, the JDK Release Process [3]. If you?re responsible for any of the bugs on the RDP 1 candidate-bug list [4] then please see JEP 3 for guidance on how to handle them. - Mark [1] https://openjdk.java.net/projects/jdk/17/#Schedule [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005660.html [3] https://openjdk.java.net/jeps/3 [4] https://j.mp/jdk-rdp-1 From peter.firmstone at zeus.net.au Sat Jun 12 03:01:56 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 12 Jun 2021 13:01:56 +1000 Subject: JEP 411: Updates to alternatives Message-ID: Noticing the updates made to JEP 411 Alternatives, I think I might have a minimalist alternative, you may find interesting: Remove: 1. SecurityManager 2. Policy provider and implementation 3. Permission checks in JDK code addressed by improvements to encapsulation, eg RuntimePermission "access class in package" and? ReflectPermission, these are no longer necessary, however I would recommend retaining checks at System::getProperty and setProperty, as these may contain security sensitive information (eg keystore and truststore). 4. doPrivileged calls within the JVM other than those which preserve context across threads, most permissions that "leak" are addressed at #3 above, and POLP tooling can capture other permissions.? It would appear that doPrivileged is more appropriate for application code, rather than JDK code. 5. I'm not sure about removing doPrivileged calls intended to preserve context within OpenJDK. Changes (improvements): 1. Make Guard::check a default method, that delegates to a provider, with a single method (eg Authority::confirm(Guard)) that does nothing by default.? Remove all implementing instances of Permission::check. (this could be backported easily). SecurityManager methods are just permission checks, existing use cases of SecurityManager can be supported with this one method.?? This could be back ported to Java 8, so libraries that currently support all supported Java versions can continue to do so.? All calls to SecurityManager methods in JDK code can be replaced by the corresponding permission check. 2. Add permission checks to data parsers (eg deserialization), this allows implementations to grant these permissions only to users, if there is not an authenticated user, then the data received by the parser cannot be trusted. 3. "Modules that are mapped to the boot loader get a unique ProtectionDomain that includes a useful code source rather than using a "shared" PD."?? This allows permission to be granted to users, (not code) so certain privileged operations, such as data parsing cannot be performed without an authenticated user, eg deserialization.? When data can only be trusted from authenticated users. Removal of AccessController and AccessControlContext have greater impact.?? AccessController's stack walk is high scaling (I haven't observed any contention, I assume it's non blocking and thread confined?), it's certainly very performant, it could be replaced internally by StackWalker to reduce OpenJDK's maintenance burden, although it isn't clear what the performance impact might be, but it will no doubt performance improvement is possible. With SecurityManager gone, no implementation and no policy provider, it simply provides the mechanics for an authorization layer without all the baggage, allowing both simple and complex implementations.? It's not for sandboxing untrusted code. Improvements will allow it to be utilised by developers, to prevent consumption of untrusted code or data and to limit the privileges of trusted code and users to principles of least privilege. It should also simplifies many tests, as JDK code only need confirm Permission checks are made and functionality of the AccessController and AccessControlContext methods if these are retained (I would prefer to see that, at least for JAAS compatibility). -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Sun Jun 13 10:34:32 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 13 Jun 2021 20:34:32 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: <3bcc71f4-fc19-1fa0-4ede-ecd9d71ce3b9@oracle.com> References: <07a4cddc-916e-a0cc-5b6a-5a42d847ea90@zeus.net.au> <3bcc71f4-fc19-1fa0-4ede-ecd9d71ce3b9@oracle.com> Message-ID: <0b259e47-c6ec-54e8-e220-b5b5ea2ced8a@zeus.net.au> Thanks Alan, I've been thinking that it may be preferable to have hooks that allowed us to inject our own permission checks, rather than retaining existing permission checks. An implementation can override Guard::check without requiring a provider mechanism. The other advantage is the ability to customize Permission implementations, such as allowing address ranges in a SocketPermission implementation and not consulting DNS to resolve host names. Cheers, Peter. On 10/06/2021 11:55 pm, Alan Bateman wrote: > On 10/06/2021 07:40, Peter Firmstone wrote: >> >> Just a quick question, would it be possible that some JFR hooks might >> also be useable for an authorisation layer? >> >> > JFR events can't be used to intercept/veto operations, assuming that > is what you are asking. However, it might be that JFR events are > monitored as part of some overall security approach that takes into > account events recorded for health, performance, or troubleshooting > purposes. > > -Alan -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Sun Jun 13 23:56:20 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 09:56:20 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: <0b259e47-c6ec-54e8-e220-b5b5ea2ced8a@zeus.net.au> References: <07a4cddc-916e-a0cc-5b6a-5a42d847ea90@zeus.net.au> <3bcc71f4-fc19-1fa0-4ede-ecd9d71ce3b9@oracle.com> <0b259e47-c6ec-54e8-e220-b5b5ea2ced8a@zeus.net.au> Message-ID: <96fe1baa-cc12-f16d-05e8-6e6549fd2f00@zeus.net.au> Some thoughts on hooks: * Utilize the Service Provider API, so as not to expose jdk implementation code.? META-INF/services/java.security.Guard * Allow existing Permission classes to remain backward compatible, declare them as services, so that SecurityManager can be degraded as planned and these services are gradually removed. (Removes dependencies on Permission instance types). * Guard implementation is required to have a constructor with two String arguments, (String name, String actions). * Service must implement Guard interface. * Doesn't depend on Permission or any existing implementation classes, completely customizable by the service implementation. * Application developers can also implement hooks using this service. Break up guard service providers into current Permission types: "AWT" "FILE" "SERIALIZABLE" "MANAGEMENT" "REFLECT" "RUNTIME" "NET" "SOCKET" "URL" "FILE-LINK" "SECURITY" "SQL" "LOGGING" "PROPERTY" "MBEAN" "MBEAN-SERVER" "MBEAN-TRUST" "SUBJECT-DELEGATION" "TLS" "AUTH" "KERBEROS-DELEGATION" "KERBEROS-SERVICE" "PRIVATE-CREDENTIAL" "AUDIO" "JAXB" "WEB-SERVICE" I would like to suggest adding a new provider type: "PARSE-DATA" - To be called by any code about to parse data, eg deserialization, XML, JSON, SQL, etc.? Granted to users, so that it can only be performed after authentication. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. On 13/06/2021 8:34 pm, Peter Firmstone wrote: > Thanks Alan, > > I've been thinking that it may be preferable to have hooks that > allowed us to inject our own permission checks, rather than retaining > existing permission checks. > > An implementation can override Guard::check without requiring a > provider mechanism. > > The other advantage is the ability to customize Permission > implementations, such as allowing address ranges in a SocketPermission > implementation and not consulting DNS to resolve host names. > > Cheers, > > Peter. > > > On 10/06/2021 11:55 pm, Alan Bateman wrote: >> On 10/06/2021 07:40, Peter Firmstone wrote: >>> >>> Just a quick question, would it be possible that some JFR hooks >>> might also be useable for an authorisation layer? >>> >>> >> JFR events can't be used to intercept/veto operations, assuming that >> is what you are asking. However, it might be that JFR events are >> monitored as part of some overall security approach that takes into >> account events recorded for health, performance, or troubleshooting >> purposes. >> >> -Alan > From peter.firmstone at zeus.net.au Mon Jun 14 05:13:15 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 15:13:15 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: <96fe1baa-cc12-f16d-05e8-6e6549fd2f00@zeus.net.au> References: <07a4cddc-916e-a0cc-5b6a-5a42d847ea90@zeus.net.au> <3bcc71f4-fc19-1fa0-4ede-ecd9d71ce3b9@oracle.com> <0b259e47-c6ec-54e8-e220-b5b5ea2ced8a@zeus.net.au> <96fe1baa-cc12-f16d-05e8-6e6549fd2f00@zeus.net.au> Message-ID: Clarification, utilize java.security.Provider. So this might use a module declaration or META-INF/services/java.security.Provider, sorry got muddled with typical ServiceLoader usage below. The reason for choosing Provider is that it allows constructor parameters, it's also security related and can require code signing, not sure if that should be a requirement. Another reason for using security provider is to avoid deadlock during Provider initialization, it must be listed as a provider in the java.security file or if security.overridePropertiesFile=true and -Djava.security.properties=file://path/additional.security defines providers, which would be useful for testing. Dynamic loading a provider using Security.addProvider or insertProviderAt causes security checks, each Guard::check call would try to initiate "SECURITY" Provider loading causing deadlock.? To avoid deadlock at the very least the "SECURITY" and "PROPERTY" java.security.Guard services would need to be loaded by java.security at startup. grant codebase "jrt:/java.xml.crypto" { ??? permission java.util.PropertyPermission "java.specification.version", "read"; ??? permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; }; Need to be careful with loading and recursive permission checks, it's ok if a permission check fires off permission checks that cause loading of other providers, we just can't ask the provider that is being dynamically loaded to perform permission checks on itself, or any circular relationship between providers. Basically it's good to have separate providers for each permission type as it helps avoid deadlocks. grant codebase "jrt:/jdk.crypto.cryptoki" { ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; On 14/06/2021 9:56 am, Peter Firmstone wrote: > Some thoughts on hooks: > > ?* Utilize the Service Provider API, so as not to expose jdk > ?? implementation code.? META-INF/services/java.security.Guard > ?* Allow existing Permission classes to remain backward compatible, > ?? declare them as services, so that SecurityManager can be degraded as > ?? planned and these services are gradually removed. (Removes > ?? dependencies on Permission instance types). > ?* Guard implementation is required to have a constructor with two > ?? String arguments, (String name, String actions). > ?* Service must implement Guard interface. > ?* Doesn't depend on Permission or any existing implementation classes, > ?? completely customizable by the service implementation. > ?* Application developers can also implement hooks using this service. > > Break up guard service providers into current Permission types: > > "AWT" > "FILE" > "SERIALIZABLE" > "MANAGEMENT" > "REFLECT" > "RUNTIME" > "NET" > "SOCKET" > "URL" > "FILE-LINK" > "SECURITY" > "SQL" > "LOGGING" > "PROPERTY" > "MBEAN" > "MBEAN-SERVER" > "MBEAN-TRUST" > "SUBJECT-DELEGATION" > "TLS" > "AUTH" > "KERBEROS-DELEGATION" > "KERBEROS-SERVICE" > "PRIVATE-CREDENTIAL" > "AUDIO" > "JAXB" > "WEB-SERVICE" > > I would like to suggest adding a new provider type: > > "PARSE-DATA" - To be called by any code about to parse data, eg > deserialization, XML, JSON, SQL, etc.? Granted to users, so that it > can only be performed after authentication. > -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From david.holmes at oracle.com Tue Jun 15 03:05:31 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jun 2021 13:05:31 +1000 Subject: Windows-aarch64 build failure in Github actions Message-ID: <043da6a7-d82d-5adf-a663-dc65ac5df94d@oracle.com> Hi, I've cc'd the Microsoft folk directly as noone seems to be paying any attention to this. The Windows Aarch64 debug build in Github actions has been failing for quite some time now e.g. [1] LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' make[3]: *** [gensrc/GensrcAdlc.gmk:63: /cygdrive/d/a/jdk17/jdk17/jdk/build/windows-aarch64/hotspot/variant-server/tools/adlc/adlc.exe] Error 1 I suspect this is an issue with the cross-compilation setup as adlc.exe has to be native binary for the build machine, not the target. Someone who actually builds Windows-Aarch64 needs to check a valid configure setup with what is seen in GHA and try to discern what the problem may be. I tried to file an issue with GitHub [2] but now suspect this is a configure problem at our end that should be fixed. Otherwise we should remove Windows-aarch64 as a target platform in the submit.yaml workflow file for GHA. Thanks, David [1] https://github.com/dholmes-ora/jdk17/runs/2825339313?check_suite_focus=true [2] https://github.com/actions/virtual-environments/issues/3567 From richard.reingruber at sap.com Tue Jun 15 08:12:50 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 15 Jun 2021 08:12:50 +0000 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: Vote: yes Cheers, Richard. -----Original Message----- From: jdk-dev On Behalf Of Volker Simonis Sent: Dienstag, 8. Juni 2021 12:34 To: jdk-dev Subject: CFV: New JDK Committer: Xin Liu I hereby nominate Xin Liu (xliu) to JDK Committer. Xin is a member of the Corretto team at Amazon and has contributed 42 patches in the JDK project since 2018 [1]. He mostly works on the C2 JIT compiler and has recently authored the support for asynchronous logging. A list of selected patches can be found at the end of this mail. Votes are due by 12:00 CET June 22, 2021. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thank you and best regards, Volker [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#committer-vote Selected patches: 1. 8222670: pathological case of JIT recompilation and code cache bloat https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 2. 8229450: C2 compilation fails with assert(found_sfpt) failed https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 3. 8022574: remove HaltNode code after uncommon trap calls https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 5. 8151779: Some intrinsic flags could be replaced with one general flag https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 6. 8206075: On x86, assert on unbound assembler Labels used as branch target https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 7. 8254369: Node::disconnect_inputs may skip precedences https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f 8. 8261675: ObjectValue::set_visited(bool) sets _visited false https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a 10. 8229517: Support for optional asynchronous/buffered logging https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 11. 8257800: CompileCommand TypedMethodOptionMatcher::parse_method_pattern() may over consume https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 12. 8251464: make Node::dump(int depth) support indent https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 From vkempik at azul.com Tue Jun 15 08:15:45 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 15 Jun 2021 08:15:45 +0000 Subject: CFV: New JDK Committer: Xin Liu In-Reply-To: References: Message-ID: <1D9278F9-C632-4017-A8F9-F1631990E1B1@azul.com> Vote: Yes > 8 ???? 2021 ?., ? 13:34, Volker Simonis ???????(?): > > I hereby nominate Xin Liu (xliu) to JDK Committer. > > Xin is a member of the Corretto team at Amazon and has contributed 42 > patches in the JDK project since 2018 [1]. He mostly works on the C2 > JIT compiler and has recently authored the support for asynchronous > logging. A list of selected patches can be found at the end of this > mail. > > Votes are due by 12:00 CET June 22, 2021. > > Only current JDK Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thank you and best regards, > Volker > > [1] https://github.com/search?o=desc&p=1&q=author-name%3A%22Xin+Liu%22+repo%3Aopenjdk%2Fjdk+merge%3Afalse&s=committer-date&type=Commits > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote > > Selected patches: > 1. 8222670: pathological case of JIT recompilation and code cache bloat > https://github.com/openjdk/jdk/commit/63dbcdc87456de230741767c298e72f428c34f47 > 2. 8229450: C2 compilation fails with assert(found_sfpt) failed > https://github.com/openjdk/jdk/commit/0a92dc786d1e5f3162067154beec8f079437f4f7 > 3. 8022574: remove HaltNode code after uncommon trap calls > https://github.com/openjdk/jdk/commit/52e1bec7bc9a63890a301222829e89b3aeab0fbc > 4. 8247732: validate user-input intrinsic_ids in ControlIntrinsic > https://github.com/openjdk/jdk/commit/83be8a902cee867c0e9d400e762f61896eb6df80 > 5. 8151779: Some intrinsic flags could be replaced with one general flag > https://github.com/openjdk/jdk/commit/4076ca82d2965c50334126d2dec3fa2ee7d89152 > 6. 8206075: On x86, assert on unbound assembler Labels used as branch target > https://github.com/openjdk/jdk/commit/6cbef1de5d6130bb6ecb34d865759c109f414504 > 7. 8254369: Node::disconnect_inputs may skip precedences > https://github.com/openjdk/jdk/commit/bdda2058c24180cd979ed856a30c3932b9e7ea1f > 8. 8261675: ObjectValue::set_visited(bool) sets _visited false > https://github.com/openjdk/jdk/commit/2677f6f47d97f39435a12fdfeae738fc8432dfd4 > 9. 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse > https://github.com/openjdk/jdk/commit/612c38cdc92a3e169fe83846920407d50263044a > 10. 8229517: Support for optional asynchronous/buffered logging > https://github.com/openjdk/jdk/commit/41185d38f21e448370433f7e4f1633777cab6170 > 11. 8257800: CompileCommand > TypedMethodOptionMatcher::parse_method_pattern() may over consume > https://github.com/openjdk/jdk/commit/adf0e23aa2c4169de6d8b41be4306128ed9666f6 > 12. 8251464: make Node::dump(int depth) support indent > https://github.com/openjdk/jdk/commit/ea5a2b15a040394730404c3abb62a3628450c796 From jiefu at tencent.com Tue Jun 15 09:17:48 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Tue, 15 Jun 2021 09:17:48 +0000 Subject: Result: New JDK Committer: Hui Shi (hshi) Message-ID: <10BB795C-7675-409E-9D75-765D730159B6@tencent.com> Voting for Hui Shi (hshi) [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Jie [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005618.html From david.holmes at oracle.com Wed Jun 16 04:59:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Jun 2021 14:59:03 +1000 Subject: Windows-aarch64 build failure in Github actions In-Reply-To: <043da6a7-d82d-5adf-a663-dc65ac5df94d@oracle.com> References: <043da6a7-d82d-5adf-a663-dc65ac5df94d@oracle.com> Message-ID: I heard back from the Windows-aarch64 port folk and so filed: 8268860: Windows-Aarch64 build is failing in GitHub actions and a subtask: 8268861: Disable Windows-Aarch64 build in GitHub Actions which I have done a PR for. David On 15/06/2021 1:05 pm, David Holmes wrote: > Hi, > > I've cc'd the Microsoft folk directly as noone seems to be paying any > attention to this. > > The Windows Aarch64 debug build in Github actions has been failing for > quite some time now e.g. [1] > > LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' > make[3]: *** [gensrc/GensrcAdlc.gmk:63: > /cygdrive/d/a/jdk17/jdk17/jdk/build/windows-aarch64/hotspot/variant-server/tools/adlc/adlc.exe] > Error 1 > > I suspect this is an issue with the cross-compilation setup as adlc.exe > has to be native binary for the build machine, not the target. Someone > who actually builds Windows-Aarch64 needs to check a valid configure > setup with what is seen in GHA and try to discern what the problem may be. > > I tried to file an issue with GitHub [2] but now suspect this is a > configure problem at our end that should be fixed. Otherwise we should > remove Windows-aarch64 as a target platform in the submit.yaml workflow > file for GHA. > > Thanks, > David > > [1] > https://github.com/dholmes-ora/jdk17/runs/2825339313?check_suite_focus=true > > [2] https://github.com/actions/virtual-environments/issues/3567 > From vicente.romero at oracle.com Thu Jun 17 17:39:48 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 17 Jun 2021 13:39:48 -0400 Subject: Result: New JDK Committer: Guoxiong Li (gli) In-Reply-To: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> References: <719907d9-cc92-14f2-0266-38109c58b871@oracle.com> Message-ID: <9d31a5f0-1457-46ba-6988-edce86101e3c@oracle.com> Voting for Guoxiong Li (gli) [1] is now closed. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Vicente Vicente [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005641.html PS, in the CFV I wrote an incorrect JDK user name `gli` is the correct one From jakob at jcornell.net Fri Jun 18 19:31:13 2021 From: jakob at jcornell.net (Jakob Cornell) Date: Fri, 18 Jun 2021 14:31:13 -0500 Subject: Information about possible JDB enhancements In-Reply-To: References: Message-ID: <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net> Hi all, I'm hoping to become an OpenJDK contributor in order to make some enhancements to JDB, which is my go-to tool for Java debugging. As an example, JDB currently ignores empty commands, and I hope to make a change so that entering an empty command results in the previous command being rerun (as users coming from GDB will expect). I would also be interested in investigating implementation of conditional breakpoints, assuming JDI supports this (I'm not familiar with it). I get the sense that these changes may not be priorities for the OpenJDK development community (or perhaps may not even be desired), and so I'm writing to try to get a sense of whether I'd be able to find someone willing to sponsor changes like these. If the answer is no then I shouldn't bother to look into creating patches. Can anybody speak to the feasability of this? Also, is there a more targeted mailing list I should use? Thanks, Jakob From daniel.daugherty at oracle.com Fri Jun 18 19:57:21 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 18 Jun 2021 15:57:21 -0400 Subject: Information about possible JDB enhancements In-Reply-To: <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net> References: <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net> Message-ID: <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com> Forwarding to serviceability-dev at ... Dan On 6/18/21 3:31 PM, Jakob Cornell wrote: > Hi all, > > I'm hoping to become an OpenJDK contributor in order to make some > enhancements to JDB, which is my go-to tool for Java debugging. As an > example, JDB currently ignores empty commands, and I hope to make a > change so that entering an empty command results in the previous > command being rerun (as users coming from GDB will expect).? I would > also be interested in investigating implementation of conditional > breakpoints, assuming JDI supports this (I'm not familiar with it). > > I get the sense that these changes may not be priorities for the > OpenJDK development community (or perhaps may not even be desired), > and so I'm writing to try to get a sense of whether I'd be able to > find someone willing to sponsor changes like these.? If the answer is > no then I shouldn't bother to look into creating patches.? Can anybody > speak to the feasability of this?? Also, is there a more targeted > mailing list I should use? > > Thanks, > Jakob From sgehwolf at redhat.com Mon Jun 21 07:41:32 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 21 Jun 2021 09:41:32 +0200 Subject: Information about possible JDB enhancements In-Reply-To: <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net> References: <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net> Message-ID: <79599b6cc5d1122a012fabda876a212c1dd0d081.camel@redhat.com> On Fri, 2021-06-18 at 14:31 -0500, Jakob Cornell wrote: > Also, is there a more targeted mailing list I should use? Yes. serviceability-dev at openjdk.java.net[1]. HTH. Thanks, Severin [1] https://mail.openjdk.java.net/mailman/listinfo/serviceability-dev From wwijsman at live.nl Mon Jun 21 11:55:40 2021 From: wwijsman at live.nl (Wouter Wijsman) Date: Mon, 21 Jun 2021 11:55:40 +0000 Subject: Timed UUID comparison Message-ID: Dear JDK developers, A couple of weeks ago I found that the compareTo function in the UUID class in Java does not look at timestamps when comparing time based UUIDs. The result of this is that when using this function to sort time based UUIDS, the order seems somewhat random. This was quite surprising to me and caused a bug in one of my applications. I managed to find out where this comparison is done in the OpenJDK implementation and I made a pull request with a simple fix on Github, but since there is no official bug report for this behavior, it hasn't been reviewed yet. The pull request can be found here: https://github.com/openjdk/jdk/pull/3620 Are there any opinions on this behavior and is this pull request wanted? Otherwise I'll just close it. Kind regards, Wouter Wijsman From Alan.Bateman at oracle.com Mon Jun 21 12:30:12 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jun 2021 13:30:12 +0100 Subject: Timed UUID comparison In-Reply-To: References: Message-ID: <9f8211a0-0d88-2c24-1986-6876f729f7b3@oracle.com> On 21/06/2021 12:55, Wouter Wijsman wrote: > Dear JDK developers, > > A couple of weeks ago I found that the compareTo function in the UUID class in Java does not look at timestamps when comparing time based UUIDs. The result of this is that when using this function to sort time based UUIDS, the order seems somewhat random. This was quite surprising to me and caused a bug in one of my applications. > > I managed to find out where this comparison is done in the OpenJDK implementation and I made a pull request with a simple fix on Github, but since there is no official bug report for this behavior, it hasn't been reviewed yet. The pull request can be found here: https://github.com/openjdk/jdk/pull/3620 > > Are there any opinions on this behavior and is this pull request wanted? Otherwise I'll just close it. It's best to start a discussion on core-libs-dev about the issue and the use-case. I don't think changing the UUID spec in an incompatible way is really an option but there may be a case for exposing a Comparator that compares in timestamp order. -Alan From jesper.wilhelmsson at oracle.com Mon Jun 21 12:40:54 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 21 Jun 2021 12:40:54 +0000 Subject: Timed UUID comparison In-Reply-To: References: Message-ID: <93199054-FABD-4D71-9CA5-FC8C1E6A7A69@oracle.com> Hi Wouter, As a first step to fix an issue in the JDK, I recommend that you read this section in the OpenJDK Developers' Guide: https://openjdk.java.net/guide/#i-have-a-patch-what-do-i-do Best regards, /Jesper > 21 juni 2021 kl. 13:55 skrev Wouter Wijsman : > > Dear JDK developers, > > A couple of weeks ago I found that the compareTo function in the UUID class in Java does not look at timestamps when comparing time based UUIDs. The result of this is that when using this function to sort time based UUIDS, the order seems somewhat random. This was quite surprising to me and caused a bug in one of my applications. > > I managed to find out where this comparison is done in the OpenJDK implementation and I made a pull request with a simple fix on Github, but since there is no official bug report for this behavior, it hasn't been reviewed yet. The pull request can be found here: https://github.com/openjdk/jdk/pull/3620 > > Are there any opinions on this behavior and is this pull request wanted? Otherwise I'll just close it. > > Kind regards, > Wouter Wijsman From volker.simonis at gmail.com Tue Jun 22 18:05:35 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Jun 2021 20:05:35 +0200 Subject: Result: New JDK Committer: Xin Liu Message-ID: Voting for Xin Liu [1] is now closed. Yes: 19 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Congratulations and best regards, Volker [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/thread.html#5665 From simeon.danailov.andreev at gmail.com Wed Jun 23 10:39:59 2021 From: simeon.danailov.andreev at gmail.com (S A) Date: Wed, 23 Jun 2021 13:39:59 +0300 Subject: libjdwp crash while debugging application ran on OpenJDK 16 Message-ID: Hi all, my colleagues recently ran into a crash in libjdwp, when measuring performance with OpenJDK 17 (early access build). The same crash was observed with OpenJDK 16.0.1, but not with OpenJDK 15. We are hoping to get a fix for the crash, before the official OpenJDK 17 release. We've opened a RHEL bugzilla ticket for this ( https://bugzilla.redhat.com/show_bug.cgi?id=1972529), but we expect this won't be enough to resolve the crash before the release. What would the appropriate medium be to report the problem? I assume this mailing list is not the right place, but I don't know how to otherwise reach out to OpenJDK developers and maintainers (other than via RHEL support/bugzilla, which is often a slow process). Sorry for the noise on the mailing list. Best regards, Simeon *Extra infos and background:* We would like to move to OpenJDK 17, in order to use Shenandoah GC. Shenandoah GC shows promising results for our product, though only with the fix for https://bugs.openjdk.java.net/browse/JDK-8254315. We would not be able to switch (or even evaluate the switch properly) until the crash is resolved. Unfortunately we have no reproducer outside of our product, and our reproducer is quite complex. Trivial use cases of debugging OpenJDK 16 with Eclipse (we base our product on Eclipse) do not run into a crash. A fast debug build for OpenJDK 16 reports an assertion fail as follows: # Internal Error (/tmp/jep2604_fastdebug_jdk16/jdk16/src/hotspot/share/runtime/jniHandles.cpp:148), pid=81289, tid=56880 # assert(!is_jweak(handle)) failed: wrong method for detroying jweak # # JRE version: OpenJDK Runtime Environment (16.0) (fastdebug build 16-internal+0-adhoc.sandreev.jdk16) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 16-internal+0-adhoc.sandreev.jdk16, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x1043cb4] JNIHandles::destroy_global(_jobject*)+0x224 ... Stack: [0x00007ffe3c4f5000,0x00007ffe3c5f6000], sp=0x00007ffe3c5f4be0, free space=1022k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1043cb4] JNIHandles::destroy_global(_jobject*)+0x224 V [libjvm.so+0xfafd9f] jni_DeleteGlobalRef+0x10f C [libjdwp.so+0xf11a] deleteNode+0x7a C [libjdwp.so+0xf71f] commonRef_reset+0x6f C [libjdwp.so+0x10dec] debugInit_reset+0x6c C [libjdwp.so+0x270a2] acceptThread+0xa2 V [libjvm.so+0x127c054] JvmtiAgentThread::call_start_function()+0x1d4 V [libjvm.so+0x1a51e9a] JavaThread::thread_main_inner()+0x5ba V [libjvm.so+0x1a589e0] Thread::call_run()+0x100 V [libjvm.so+0x15fbd26] thread_native_entry(Thread*)+0x116 Going through the stack trace, looking for related changes, I've not been able to reproduce the crash with this commit reverted: https://github.com/openjdk/jdk/commit/79f1dfb8d3941377da77e73f7bbab93baef29b8e From stefan.karlsson at oracle.com Wed Jun 23 13:09:56 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 23 Jun 2021 15:09:56 +0200 Subject: libjdwp crash while debugging application ran on OpenJDK 16 In-Reply-To: References: Message-ID: <6d07afc1-ce8c-f0a5-7b8b-bf1b8357ed4b@oracle.com> Hi Simeon, On 2021-06-23 12:39, S A wrote: > Hi all, > > my colleagues recently ran into a crash in libjdwp, when measuring > performance with OpenJDK 17 (early access build). The same crash was > observed with OpenJDK 16.0.1, but not with OpenJDK 15. > > We are hoping to get a fix for the crash, before the official OpenJDK 17 > release. We've opened a RHEL bugzilla ticket for this ( > https://bugzilla.redhat.com/show_bug.cgi?id=1972529), but we expect this > won't be enough to resolve the crash before the release. > > What would the appropriate medium be to report the problem? I assume this > mailing list is not the right place, but I don't know how to otherwise > reach out to OpenJDK developers and maintainers (other than via RHEL > support/bugzilla, which is often a slow process). The hs_err crash files usually states where to report the bugs. Oracle-built binaries say: # If you would like to submit a bug report, please visit: #?? https://bugreport.java.com/bugreport/crash.jsp I think serviceability-dev would be the be the correct mailing list. I'll bcc away jdk-dev and will move this to serviceablity-dev. I wonder if this could be caused by calling commonRef_unpin on a ref that is not "pinned"? Specifically, look at the updated weakenNode: static jweak weakenNode(JNIEnv *env, RefNode *node) { ??? if (node->strongCount == 1) { ... ??????? return weakRef; ??? } else { ??????? node->strongCount--; ??????? return node->ref; ??? } } if strongCount is 0, this will underflow and then delete node will take the wrong path: if (node->strongCount != 0) { ? JNI_FUNC_PTR(env,DeleteGlobalRef)(env, node->ref); } else { ? JNI_FUNC_PTR(env,DeleteWeakGlobalRef)(env, node->ref); } The previous version of weakenNode looked like this: static jweak weakenNode(JNIEnv *env, RefNode *node) { ??? if (node->isStrong) { ... ??????? return weakRef; ??? } else { ??????? return node->ref; ??? } } so a unbalanced unpin call would previously not fail in the same way. StefanK > > Sorry for the noise on the mailing list. > > Best regards, > Simeon > > *Extra infos and background:* > > We would like to move to OpenJDK 17, in order to use Shenandoah GC. > Shenandoah GC shows promising results for our product, though only with the > fix for https://bugs.openjdk.java.net/browse/JDK-8254315. We would not be > able to switch (or even evaluate the switch properly) until the crash is > resolved. > > Unfortunately we have no reproducer outside of our product, and our > reproducer is quite complex. Trivial use cases of debugging OpenJDK 16 with > Eclipse (we base our product on Eclipse) do not run into a crash. > > A fast debug build for OpenJDK 16 reports an assertion fail as follows: > > # Internal Error > (/tmp/jep2604_fastdebug_jdk16/jdk16/src/hotspot/share/runtime/jniHandles.cpp:148), > pid=81289, tid=56880 > # assert(!is_jweak(handle)) failed: wrong method for detroying jweak > # > # JRE version: OpenJDK Runtime Environment (16.0) (fastdebug build > 16-internal+0-adhoc.sandreev.jdk16) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug > 16-internal+0-adhoc.sandreev.jdk16, mixed mode, tiered, compressed oops, g1 > gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x1043cb4] JNIHandles::destroy_global(_jobject*)+0x224 > ... > Stack: [0x00007ffe3c4f5000,0x00007ffe3c5f6000], sp=0x00007ffe3c5f4be0, > free space=1022k > Native frames: (J=compiled Java code, A=aot compiled Java code, > j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1043cb4] JNIHandles::destroy_global(_jobject*)+0x224 > V [libjvm.so+0xfafd9f] jni_DeleteGlobalRef+0x10f > C [libjdwp.so+0xf11a] deleteNode+0x7a > C [libjdwp.so+0xf71f] commonRef_reset+0x6f > C [libjdwp.so+0x10dec] debugInit_reset+0x6c > C [libjdwp.so+0x270a2] acceptThread+0xa2 > V [libjvm.so+0x127c054] JvmtiAgentThread::call_start_function()+0x1d4 > V [libjvm.so+0x1a51e9a] JavaThread::thread_main_inner()+0x5ba > V [libjvm.so+0x1a589e0] Thread::call_run()+0x100 > V [libjvm.so+0x15fbd26] thread_native_entry(Thread*)+0x116 > > Going through the stack trace, looking for related changes, I've not been > able to reproduce the crash with this commit reverted: > https://github.com/openjdk/jdk/commit/79f1dfb8d3941377da77e73f7bbab93baef29b8e From thomas.schatzl at oracle.com Thu Jun 24 13:32:50 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 24 Jun 2021 15:32:50 +0200 Subject: CFV: New JDK Reviewer: Leo Korinth Message-ID: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Hi all, I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. Only current JDK Project Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Votes are due by 16:00 UTC on 8th July 2021. Thomas [1] https://openjdk.java.net/census#lkorinth [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#reviewer-vote From thomas.stuefe at gmail.com Thu Jun 24 13:36:37 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Jun 2021 15:36:37 +0200 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes On Thu, Jun 24, 2021 at 3:33 PM Thomas Schatzl wrote: > Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the > Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual contributions > to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote > From goetz.lindenmaier at sap.com Thu Jun 24 13:37:19 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 24 Jun 2021 13:37:19 +0000 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes Best, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Thomas > Schatzl > Sent: Thursday, June 24, 2021 3:33 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Leo Korinth > > Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the > Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual contributions > to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author- > name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From thomas.schatzl at oracle.com Thu Jun 24 13:42:03 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 24 Jun 2021 15:42:03 +0200 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes On 24.06.21 15:32, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the > Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual contributions > to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From andy.herrick at oracle.com Thu Jun 24 13:43:44 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 24 Jun 2021 09:43:44 -0400 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <44df786d-3b24-88e9-e231-1a6774aca247@oracle.com> |Vote: yes /Andy | On 6/24/2021 9:32 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of > the Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual > contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From adinn at redhat.com Thu Jun 24 13:47:46 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 24 Jun 2021 14:47:46 +0100 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes On 24/06/2021 14:32, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the > Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual contributions > to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From Alan.Bateman at oracle.com Thu Jun 24 13:59:24 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Jun 2021 14:59:24 +0100 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes From harold.seigel at oracle.com Thu Jun 24 14:01:52 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 24 Jun 2021 10:01:52 -0400 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <519de13e-1570-52d8-df5b-da94be84d4f5@oracle.com> Vote: Yes Harold On 6/24/2021 9:32 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of > the Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual > contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From erik.gahlin at oracle.com Thu Jun 24 14:19:08 2021 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 24 Jun 2021 14:19:08 +0000 Subject: New JDK Reviewer: Leo Korinth Message-ID: <1A153F2C-0239-47EA-B371-60EB3FF54854@oracle.com> Vote: yes On 2021-06-24, 15:32, "jdk-dev on behalf of Thomas Schatzl" wrote: Hi all, I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. Only current JDK Project Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Votes are due by 16:00 UTC on 8th July 2021. Thomas [1] https://openjdk.java.net/census#lkorinth [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#reviewer-vote From sangheon.kim at oracle.com Thu Jun 24 14:21:29 2021 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Thu, 24 Jun 2021 07:21:29 -0700 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <3bd0b227-8439-dd18-7923-c535fff530bb@oracle.com> Vote: yes Thanks, Sangheon On 6/24/21 6:32 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of > the Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual > contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From lois.foltan at oracle.com Thu Jun 24 14:48:05 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 24 Jun 2021 10:48:05 -0400 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes Lois On 6/24/2021 9:32 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of > the Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual > contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From kim.barrett at oracle.com Thu Jun 24 15:30:42 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Jun 2021 15:30:42 +0000 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <014C3D5C-90CF-4949-931A-D13EDE6647BC@oracle.com> vote: yes > On Jun 24, 2021, at 9:32 AM, Thomas Schatzl wrote: > > Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. > > He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From daniel.daugherty at oracle.com Thu Jun 24 15:38:40 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 24 Jun 2021 11:38:40 -0400 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes Dan On 6/24/21 9:32 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of > the Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual > contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From daniel.fuchs at oracle.com Thu Jun 24 15:40:13 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 24 Jun 2021 16:40:13 +0100 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <4075110f-c5f3-318b-9ea6-e818e5eeda71@oracle.com> Vote: yes best regards, -- daniel On 24/06/2021 14:32, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. From erik.osterlund at oracle.com Thu Jun 24 21:27:57 2021 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 24 Jun 2021 21:27:57 +0000 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <661B6099-1D64-4E66-924F-B8730EFA1667@oracle.com> Vote: yes /Erik > On 24 Jun 2021, at 15:33, Thomas Schatzl wrote: > > ?Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. > > He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From christoph.langer at sap.com Thu Jun 24 21:57:20 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 24 Jun 2021 21:57:20 +0000 Subject: New JDK Reviewer: Leo Korinth In-Reply-To: <1A153F2C-0239-47EA-B371-60EB3FF54854@oracle.com> References: <1A153F2C-0239-47EA-B371-60EB3FF54854@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Erik Gahlin > Sent: Donnerstag, 24. Juni 2021 16:19 > To: Thomas Schatzl ; jdk- > dev at openjdk.java.net > Subject: Re: New JDK Reviewer: Leo Korinth > > Vote: yes > > On 2021-06-24, 15:32, "jdk-dev on behalf of Thomas Schatzl" retn at openjdk.java.net on behalf of thomas.schatzl at oracle.com> wrote: > > Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the > Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual contributions > to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author- > name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote > From lihuaming3 at huawei.com Fri Jun 25 03:31:14 2021 From: lihuaming3 at huawei.com (lihuaming (A)) Date: Fri, 25 Jun 2021 03:31:14 +0000 Subject: =?utf-8?B?562U5aSNOiBOZXcgSkRLIFJldmlld2VyOiBMZW8gS29yaW50aA==?= In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <0841a3b21f3547f992cad227ab0f80b0@huawei.com> Vote: Yes -Hamlin Li -----????----- ???: jdk-dev [mailto:jdk-dev-retn at openjdk.java.net] ?? Thomas Schatzl ????: 2021?6?24? 21:33 ???: jdk-dev at openjdk.java.net ??: CFV: New JDK Reviewer: Leo Korinth Hi all, I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. Only current JDK Project Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Votes are due by 16:00 UTC on 8th July 2021. Thomas [1] https://openjdk.java.net/census#lkorinth [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#reviewer-vote From calvin.cheung at oracle.com Fri Jun 25 16:31:08 2021 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Fri, 25 Jun 2021 09:31:08 -0700 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <858c03f5-5ac2-ae1a-b399-b3e789595f74@oracle.com> Vote: yes On 6/24/21 6:32 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of > the Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual > contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From jesper.wilhelmsson at oracle.com Sun Jun 27 21:30:45 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sun, 27 Jun 2021 21:30:45 +0000 Subject: New JDK Reviewer: Leo Korinth In-Reply-To: <1A153F2C-0239-47EA-B371-60EB3FF54854@oracle.com> References: <1A153F2C-0239-47EA-B371-60EB3FF54854@oracle.com> Message-ID: Vote: Yes /Jesper > 24 juni 2021 kl. 16:19 skrev Erik Gahlin : > > Vote: yes > > On 2021-06-24, 15:32, "jdk-dev on behalf of Thomas Schatzl" wrote: > > Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the > Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual contributions > to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote > > From jesper.wilhelmsson at oracle.com Sun Jun 27 21:33:40 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sun, 27 Jun 2021 21:33:40 +0000 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: Yes /Jesper > 24 juni 2021 kl. 15:32 skrev Thomas Schatzl : > > Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. > > He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From joel.p.borggren-franck at oracle.com Mon Jun 28 07:29:06 2021 From: joel.p.borggren-franck at oracle.com (Joel Borggren-Franck) Date: Mon, 28 Jun 2021 07:29:06 +0000 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <823268DE-939C-496A-AF7B-1F915897A2C4@oracle.com> Vote: yes cheers /Joel > On 24 Jun 2021, at 15:32, Thomas Schatzl wrote: > > Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. > > He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From yan at azul.com Mon Jun 28 08:23:42 2021 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 28 Jun 2021 11:23:42 +0300 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <8ac72560-52f2-4ea0-84b6-0765917e0164@azul.com> Vote: yes --yan On 24.06.2021 16:32, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the > Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual contributions > to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote > From shade at redhat.com Mon Jun 28 11:19:12 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 28 Jun 2021 13:19:12 +0200 Subject: -Xcomp test time regressions? Message-ID: <09f260cb-6c34-f1f6-a1b5-c12ed8c7e278@redhat.com> Hi, I was doing the usual work, and then noticed -Xcomp tests got considerably slower. I believe there are plenty of JBS bug reports already with various test timeouts. Running a sample test like: $ CONF=linux-x86_64-server-fastdebug make run-test TEST=gc/shenandoah/mxbeans/TestPauseNotifications.java TEST_VM_OPTS="-Xcomp" I initially thought it has something to do with JTReg upgrade, but it does not look like it: - 18, JTReg 6+1: 5m33s (!!!) - 11u, JTReg 5.1-b01: 2m27s - 11u, JTReg 6+1: 2m32s Comparing the test logs between "slow" 18 and fast "11u", I can see that javac tasks take a lot more (whole minutes more!) time in "slow" configs. Before I go and bisect this more thoroughly, is this an already known thing? -- Thanks, -Aleksey From david.holmes at oracle.com Mon Jun 28 13:18:36 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Jun 2021 23:18:36 +1000 Subject: -Xcomp test time regressions? In-Reply-To: <09f260cb-6c34-f1f6-a1b5-c12ed8c7e278@redhat.com> References: <09f260cb-6c34-f1f6-a1b5-c12ed8c7e278@redhat.com> Message-ID: <595777d6-1e65-71a3-0418-ed903693ea3c@oracle.com> Hi Aleksey, Seems like a question for the JIT folk on hotspot-compiler-dev. Though ... On 28/06/2021 9:19 pm, Aleksey Shipilev wrote: > Hi, > > I was doing the usual work, and then noticed -Xcomp tests got > considerably slower. I believe there are plenty of JBS bug reports > already with various test timeouts. > > Running a sample test like: > ? $ CONF=linux-x86_64-server-fastdebug make run-test > TEST=gc/shenandoah/mxbeans/TestPauseNotifications.java > TEST_VM_OPTS="-Xcomp" > > I initially thought it has something to do with JTReg upgrade, but it > does not look like it: > ? - 18, JTReg 6+1: 5m33s (!!!) > ? - 11u, JTReg 5.1-b01: 2m27s > ? - 11u, JTReg 6+1: 2m32s > > Comparing the test logs between "slow" 18 and fast "11u", I can see that > javac tasks take a lot more (whole minutes more!) time in "slow" configs. Did we use to handle the TEST_VM_OPTS differently, such that it didn't apply to the javac part? David > Before I go and bisect this more thoroughly, is this an already known > thing? > From shade at redhat.com Mon Jun 28 13:49:09 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 28 Jun 2021 15:49:09 +0200 Subject: -Xcomp test time regressions? In-Reply-To: <595777d6-1e65-71a3-0418-ed903693ea3c@oracle.com> References: <09f260cb-6c34-f1f6-a1b5-c12ed8c7e278@redhat.com> <595777d6-1e65-71a3-0418-ed903693ea3c@oracle.com> Message-ID: <8e4aa963-f8de-3d88-00c6-058bb7b92545@redhat.com> Hi David, On 6/28/21 3:18 PM, David Holmes wrote: > Did we use to handle the TEST_VM_OPTS differently, such that it didn't > apply to the javac part? Looking at test history, I think -Xcomp always applied to javac, but now -Xcomp is slower itself, and it shows. See below. >> Before I go and bisect this more thoroughly, is this an already known >> thing? Bisected. Yes, it is a known thing: https://bugs.openjdk.java.net/browse/JDK-8264903 So maybe we should attack it from a different angle: somehow ask jtreg to invoke javac without additional JVM options, so we don't spend significant time -Xcomp-ing javac itself. I tried to add "@build " to the exemplar test, but it is still compiled with -Xcomp. Either way, even if that worked, it would be awkward to add to every test out there. jtreg docs say that -vmoption is used when compiling and running classes. I cannot find the option that could provide different VM options to compiling and running classes. Adding one might make sense? -- Thanks, -Aleksey From shade at redhat.com Mon Jun 28 14:07:41 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 28 Jun 2021 16:07:41 +0200 Subject: -Xcomp test time regressions? In-Reply-To: <8e4aa963-f8de-3d88-00c6-058bb7b92545@redhat.com> References: <09f260cb-6c34-f1f6-a1b5-c12ed8c7e278@redhat.com> <595777d6-1e65-71a3-0418-ed903693ea3c@oracle.com> <8e4aa963-f8de-3d88-00c6-058bb7b92545@redhat.com> Message-ID: <00b9ff62-0d05-71ae-e983-688b92d4b97a@redhat.com> On 6/28/21 3:49 PM, Aleksey Shipilev wrote: > On 6/28/21 3:18 PM, David Holmes wrote: >> Did we use to handle the TEST_VM_OPTS differently, such that it didn't >> apply to the javac part? > > Looking at test history, I think -Xcomp always applied to javac, but now -Xcomp is slower itself, > and it shows. See below. > >>> Before I go and bisect this more thoroughly, is this an already known >>> thing? > > Bisected. > > Yes, it is a known thing: > https://bugs.openjdk.java.net/browse/JDK-8264903 > > So maybe we should attack it from a different angle: somehow ask jtreg to invoke javac without > additional JVM options, so we don't spend significant time -Xcomp-ing javac itself. I tried to add > "@build " to the exemplar test, but it is still compiled with -Xcomp. Either way, even if > that worked, it would be awkward to add to every test out there. > > jtreg docs say that -vmoption is used when compiling and running classes. I cannot find the option > that could provide different VM options to compiling and running classes. Adding one might make sense? Oh wait, there is -javaoption: and -javacoption:, hm. First option is accessible via JAVA_OPTIONS. So these two things behave differently: $ make run-test TEST=gc/shenandoah/mxbeans/TestPauseNotifications.java TEST_VM_OPTS="-Xcomp" real 5m37.320s user 18m17.810s sys 0m14.241s $ make run-test TEST=gc/shenandoah/mxbeans/TestPauseNotifications.java TEST_OPTS="JAVA_OPTIONS=-Xcomp" real 2m16.399s user 9m3.895s sys 0m10.085s I have checked that -Xcomp is indeed passed to the test in the latter case, and it compiles everything there. I guess it is time to revise my test scripts to always do the latter to save cycles. -- Thanks, -Aleksey From igor.ignatyev at oracle.com Mon Jun 28 14:13:47 2021 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Mon, 28 Jun 2021 14:13:47 +0000 Subject: -Xcomp test time regressions? In-Reply-To: <8e4aa963-f8de-3d88-00c6-058bb7b92545@redhat.com> References: <09f260cb-6c34-f1f6-a1b5-c12ed8c7e278@redhat.com> <595777d6-1e65-71a3-0418-ed903693ea3c@oracle.com>, <8e4aa963-f8de-3d88-00c6-058bb7b92545@redhat.com> Message-ID: <08E3904B-DBA0-41FA-B7FC-D07959580C80@oracle.com> Hi Aleksey, > On Jun 28, 2021, at 6:55 AM, Aleksey Shipilev wrote: > > ?Hi David, > >> On 6/28/21 3:18 PM, David Holmes wrote: >> Did we use to handle the TEST_VM_OPTS differently, such that it didn't >> apply to the javac part? > > Looking at test history, I think -Xcomp always applied to javac, but now -Xcomp is slower itself, and it shows. See below. > >>> Before I go and bisect this more thoroughly, is this an already known >>> thing? > > Bisected. > > Yes, it is a known thing: > https://bugs.openjdk.java.net/browse/JDK-8264903 > > So maybe we should attack it from a different angle: somehow ask jtreg to invoke javac without additional JVM options, so we don't spend significant time -Xcomp-ing javac itself. I tried to add "@build " to the exemplar test, but it is still compiled with -Xcomp. Either way, even if that worked, it would be awkward to add to every test out there. > > jtreg docs say that -vmoption is used when compiling and running classes. I cannot find the option that could provide different VM options to compiling and running classes. Adding one might make sense? > -javaoption is that option; and we should use it instead of -vmoption, IIRC we have discussed that before but there were blocking issues, e.g. some tests passing only vmoption to a child JVM, so we need to double check if it all got resolved and make a change. I?ll file a ticket for that. Cheers, ? Igor From magnus.ihse.bursie at oracle.com Mon Jun 28 15:51:49 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 28 Jun 2021 17:51:49 +0200 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes /Magnus On 2021-06-24 15:32, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of > the Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual > contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From mikael.vidstedt at oracle.com Tue Jun 29 03:25:31 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 29 Jun 2021 03:25:31 +0000 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <320DE4CD-2E84-46AE-9282-E5F0AE9674C8@oracle.com> Vote: yes Cheers, Mikael > On Jun 24, 2021, at 6:32 AM, Thomas Schatzl wrote: > > Hi all, > > I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. > > He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From erik.joelsson at oracle.com Tue Jun 29 12:49:28 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 29 Jun 2021 05:49:28 -0700 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <33e01d34-46de-c090-4660-8bcf79b95bfe@oracle.com> Vote: yes On 2021-06-24 06:32, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of > the Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual > contributions to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From richard.reingruber at sap.com Wed Jun 30 08:37:39 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 30 Jun 2021 08:37:39 +0000 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes Richard. -----Original Message----- From: jdk-dev On Behalf Of Thomas Schatzl Sent: Donnerstag, 24. Juni 2021 15:33 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Reviewer: Leo Korinth Hi all, I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. Only current JDK Project Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Votes are due by 16:00 UTC on 8th July 2021. Thomas [1] https://openjdk.java.net/census#lkorinth [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#reviewer-vote From per.liden at oracle.com Wed Jun 30 13:23:13 2021 From: per.liden at oracle.com (Per Liden) Date: Wed, 30 Jun 2021 15:23:13 +0200 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes /Per On 6/24/21 3:32 PM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. > > Leo is currently a JDK committer, and has been a long time member of the > Garbage Collection team at Oracle, notably working in the area of > Parallel GC, Reference Processing and (removing) CMS but also helping > with G1. > > He has made substantial contributions [2] to the development of the > areas mentioned above, and has in total made 50 individual contributions > to the JDK project. > > Only current JDK Project Reviewers [3] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [4]. > > Votes are due by 16:00 UTC on 8th July 2021. > > Thomas > > [1] https://openjdk.java.net/census#lkorinth > [2] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits > > [3] https://openjdk.java.net/census > [4] https://openjdk.java.net/projects/#reviewer-vote From martin.doerr at sap.com Wed Jun 30 14:38:33 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Jun 2021 14:38:33 +0000 Subject: AW: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: Vote: yes Best regards, Martin Von: jdk-dev im Auftrag von Thomas Schatzl Datum: Donnerstag, 24. Juni 2021 um 15:35 An: jdk-dev at openjdk.java.net Betreff: CFV: New JDK Reviewer: Leo Korinth Hi all, I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK Project Reviewer. Leo is currently a JDK committer, and has been a long time member of the Garbage Collection team at Oracle, notably working in the area of Parallel GC, Reference Processing and (removing) CMS but also helping with G1. He has made substantial contributions [2] to the development of the areas mentioned above, and has in total made 50 individual contributions to the JDK project. Only current JDK Project Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Votes are due by 16:00 UTC on 8th July 2021. Thomas [1] https://openjdk.java.net/census#lkorinth [2] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Leo+Korinth%22&type=commits [3] https://openjdk.java.net/census [4] https://openjdk.java.net/projects/#reviewer-vote From brent.christian at oracle.com Wed Jun 30 17:36:36 2021 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 30 Jun 2021 10:36:36 -0700 Subject: CFV: New JDK Reviewer: Leo Korinth In-Reply-To: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> References: <89a09292-af87-2e64-ca65-4f5df32a5baa@oracle.com> Message-ID: <4e1906fe-f720-a8bf-a95b-c85cc0a26840@oracle.com> Vote: Yes On 6/24/21 6:32 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Leo Korinth (lkorinth[1]) to the role of JDK > Project Reviewer. >