From david.buck at oracle.com Mon Jun 4 18:56:28 2018 From: david.buck at oracle.com (David Buck) Date: Tue, 5 Jun 2018 03:56:28 +0900 Subject: [8] RFA 8204053 : libsaproc.so not linked with -z,noexecstack Message-ID: Hi! Please approve the push of this 8-only fix. bug report: https://bugs.openjdk.java.net/browse/JDK-8204053 webrev: http://cr.openjdk.java.net/~dbuck/8204053.0/ code review: http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022261.html JPRT hotspot testset run and passed. Efficacy of fix manually confirmed. Cheers, -Buck From rob.mckenna at oracle.com Tue Jun 5 00:33:43 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 5 Jun 2018 01:33:43 +0100 Subject: [8] RFA 8204053 : libsaproc.so not linked with -z,noexecstack In-Reply-To: References: Message-ID: <20180605003343.GC4913@vimes> Approved -Rob On 05/06/18 03:56, David Buck wrote: > Hi! > > Please approve the push of this 8-only fix. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8204053 > > webrev: > http://cr.openjdk.java.net/~dbuck/8204053.0/ > > code review: > http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022261.html > > JPRT hotspot testset run and passed. Efficacy of fix manually confirmed. > > Cheers, > -Buck From mbalao at redhat.com Tue Jun 5 15:53:26 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 5 Jun 2018 12:53:26 -0300 Subject: [8u-dev] RFA for JDK-8204343: Release session if initialization of SunPKCS11 Signature fails Message-ID: Hi, Here there is a backport of JDK-8203182 [1] to JDK8: * http://cr.openjdk.java.net/~mbalao/webrevs/8203182/backports/8/8203182.webrev.01/ * http://cr.openjdk.java.net/~mbalao/webrevs/8203182/backports/8/8203182.webrev.01.zip Backport ticket: JDK-8204343 [2]. JDK commit: http://hg.openjdk.java.net/jdk/jdk/rev/00ebc17f3cc6 Review approval: http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017224.html I'd be grateful if someone can approve it. Kind regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8203182 [2] - https://bugs.openjdk.java.net/browse/JDK-8204343 From rob.mckenna at oracle.com Tue Jun 5 16:12:21 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 5 Jun 2018 17:12:21 +0100 Subject: [8u-dev] RFA for JDK-8204343: Release session if initialization of SunPKCS11 Signature fails In-Reply-To: References: Message-ID: <20180605161221.GD4583@vimes> You will need a separate code review for the 8 backport if the original patch does not apply cleanly after reshuffling. -Rob On 05/06/18 12:53, Martin Balao wrote: > Hi, > > Here there is a backport of JDK-8203182 [1] to JDK8: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8203182/backports/8/8203182.webrev.01/ > * > http://cr.openjdk.java.net/~mbalao/webrevs/8203182/backports/8/8203182.webrev.01.zip > > Backport ticket: JDK-8204343 [2]. > JDK commit: http://hg.openjdk.java.net/jdk/jdk/rev/00ebc17f3cc6 > Review approval: > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017224.html > > I'd be grateful if someone can approve it. > > Kind regards, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8203182 > [2] - https://bugs.openjdk.java.net/browse/JDK-8204343 From mbalao at redhat.com Tue Jun 5 16:19:43 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 5 Jun 2018 13:19:43 -0300 Subject: [8u-dev] RFA for JDK-8204343: Release session if initialization of SunPKCS11 Signature fails In-Reply-To: <20180605161221.GD4583@vimes> References: <20180605161221.GD4583@vimes> Message-ID: Hi Rob, JDK patch applies cleanly if path is fixed according to jdk8u directories layout. Kind regards, Martin.- On Tue, Jun 5, 2018 at 1:12 PM, Rob McKenna wrote: > You will need a separate code review for the 8 backport if the original > patch does not apply cleanly after reshuffling. > > -Rob > > On 05/06/18 12:53, Martin Balao wrote: > > Hi, > > > > Here there is a backport of JDK-8203182 [1] to JDK8: > > > > * > > http://cr.openjdk.java.net/~mbalao/webrevs/8203182/ > backports/8/8203182.webrev.01/ > > * > > http://cr.openjdk.java.net/~mbalao/webrevs/8203182/ > backports/8/8203182.webrev.01.zip > > > > Backport ticket: JDK-8204343 [2]. > > JDK commit: http://hg.openjdk.java.net/jdk/jdk/rev/00ebc17f3cc6 > > Review approval: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017224.html > > > > I'd be grateful if someone can approve it. > > > > Kind regards, > > Martin.- > > > > -- > > [1] - https://bugs.openjdk.java.net/browse/JDK-8203182 > > [2] - https://bugs.openjdk.java.net/browse/JDK-8204343 > From rob.mckenna at oracle.com Tue Jun 5 16:33:25 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 5 Jun 2018 17:33:25 +0100 Subject: [8u-dev] RFA for JDK-8204343: Release session if initialization of SunPKCS11 Signature fails In-Reply-To: References: <20180605161221.GD4583@vimes> Message-ID: <20180605163325.GE4583@vimes> Thanks for the confirmation Martin, Approved. -Rob On 05/06/18 13:19, Martin Balao wrote: > Hi Rob, > > JDK patch applies cleanly if path is fixed according to jdk8u directories > layout. > > Kind regards, > Martin.- > > On Tue, Jun 5, 2018 at 1:12 PM, Rob McKenna wrote: > > > You will need a separate code review for the 8 backport if the original > > patch does not apply cleanly after reshuffling. > > > > -Rob > > > > On 05/06/18 12:53, Martin Balao wrote: > > > Hi, > > > > > > Here there is a backport of JDK-8203182 [1] to JDK8: > > > > > > * > > > http://cr.openjdk.java.net/~mbalao/webrevs/8203182/ > > backports/8/8203182.webrev.01/ > > > * > > > http://cr.openjdk.java.net/~mbalao/webrevs/8203182/ > > backports/8/8203182.webrev.01.zip > > > > > > Backport ticket: JDK-8204343 [2]. > > > JDK commit: http://hg.openjdk.java.net/jdk/jdk/rev/00ebc17f3cc6 > > > Review approval: > > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017224.html > > > > > > I'd be grateful if someone can approve it. > > > > > > Kind regards, > > > Martin.- > > > > > > -- > > > [1] - https://bugs.openjdk.java.net/browse/JDK-8203182 > > > [2] - https://bugs.openjdk.java.net/browse/JDK-8204343 > > From kevin.walls at oracle.com Thu Jun 7 14:09:41 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 7 Jun 2018 15:09:41 +0100 Subject: [8u-dev] Request for approval for CR 8196880: VS2017 Addition of Global Delete Operator with Size Parameter Conflicts with Arena's Chunk Provided One Message-ID: <7f4f246b-63eb-15af-133f-e015f84c2877@oracle.com> Hi, I'd like to request approval to backport from 11 to 8u: 8196880: VS2017 Addition of Global Delete Operator with Size Parameter Conflicts with Arena's Chunk Provided One JBS: https://bugs.openjdk.java.net/browse/JDK-8196880 11 changeset:? http://hg.openjdk.java.net/jdk/jdk/rev/6b8fb182bb17 11 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030139.html This is a clean backport into jdk8u (after changing the path to be src/share/vm/adlc/arena.hpp). Builds and tests are OK after this change - it fixes an error triggered by later VS compilers, but doesn't change the behaviour on the current VS2010 compiler. Thanks! Kevin From rob.mckenna at oracle.com Thu Jun 7 15:27:56 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 7 Jun 2018 16:27:56 +0100 Subject: [8u-dev] Request for approval for CR 8196880: VS2017 Addition of Global Delete Operator with Size Parameter Conflicts with Arena's Chunk Provided One In-Reply-To: <7f4f246b-63eb-15af-133f-e015f84c2877@oracle.com> References: <7f4f246b-63eb-15af-133f-e015f84c2877@oracle.com> Message-ID: <20180607152756.GA4535@vimes> Approved -Rob On 07/06/18 15:09, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 11 to 8u: > > 8196880: VS2017 Addition of Global Delete Operator with Size Parameter > Conflicts with Arena's Chunk Provided One > JBS: https://bugs.openjdk.java.net/browse/JDK-8196880 > > 11 changeset:? http://hg.openjdk.java.net/jdk/jdk/rev/6b8fb182bb17 > > 11 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030139.html > > This is a clean backport into jdk8u (after changing the path to be > src/share/vm/adlc/arena.hpp). > > Builds and tests are OK after this change - it fixes an error triggered by > later VS compilers, but > doesn't change the behaviour on the current VS2010 compiler. > > Thanks! > Kevin > From kevin.walls at oracle.com Fri Jun 8 09:31:09 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 8 Jun 2018 10:31:09 +0100 Subject: [8u] Request for enhancement backport approval for CR 8196108: Add build support for VS 2015/2017 Message-ID: <533fc1b6-b847-7b9f-9883-aab9bd631c34@oracle.com> Hi, I'd like to get enhancement backport approval to backport to jdk8u: 8196108: Add build support for VS 2015/2017 https://bugs.openjdk.java.net/browse/JDK-8196108 This continues to widen the range of compilers acceptable to build jdk8.? This change lets us start a VS2017 build, will need further work on making the build complete. This backport change is now out for review on build-dev. No changes are suggested regarding what is officially working or supported at this time. Many thanks Kevin From deepak.kejriwal at oracle.com Fri Jun 8 09:42:43 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Fri, 8 Jun 2018 02:42:43 -0700 (PDT) Subject: [8u-dev] Request for Approval: Backport of 8176192: Incorrect usage of Iterator in Java 8 In com.sun.jndi.ldap.EventSupport.removeNamingListener In-Reply-To: <106a7706-d5ba-4c73-940b-0afa0dfcd7ae@default> References: <106a7706-d5ba-4c73-940b-0afa0dfcd7ae@default> Message-ID: Hi, Please approve the backport of 8176192 to 8u-dev. BugHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8176192": https://bugs.openjdk.java.net/browse/JDK-8203910 JDK Change set: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3d52a1fd3eea JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048242.html Changes applied cleanly to jdk8u-dev after path reshuffling. All the related testing is done and is a pass. Regards, Deepak From rob.mckenna at oracle.com Fri Jun 8 13:33:39 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 8 Jun 2018 14:33:39 +0100 Subject: [8u-dev] Request for Approval: Backport of 8176192: Incorrect usage of Iterator in Java 8 In com.sun.jndi.ldap.EventSupport.removeNamingListener In-Reply-To: References: <106a7706-d5ba-4c73-940b-0afa0dfcd7ae@default> Message-ID: <20180608133339.GB4674@vimes> Approved -Rob On 08/06/18 02:42, Deepak Kejriwal wrote: > Hi, > > > > Please approve the backport of 8176192 to 8u-dev. > > BugHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8176192": https://bugs.openjdk.java.net/browse/JDK-8203910 > > JDK Change set: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3d52a1fd3eea > > JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048242.html > > > > Changes applied cleanly to jdk8u-dev after path reshuffling. > > All the related testing is done and is a pass. > > > > Regards, > > Deepak From rob.mckenna at oracle.com Fri Jun 8 13:40:48 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 8 Jun 2018 14:40:48 +0100 Subject: [8u] Request for enhancement backport approval for CR 8196108: Add build support for VS 2015/2017 In-Reply-To: <533fc1b6-b847-7b9f-9883-aab9bd631c34@oracle.com> References: <533fc1b6-b847-7b9f-9883-aab9bd631c34@oracle.com> Message-ID: <20180608134048.GC4674@vimes> Approved subject to codereview / push approval. -Rob On 08/06/18 10:31, Kevin Walls wrote: > Hi, > > I'd like to get enhancement backport approval to backport to jdk8u: > > 8196108: Add build support for VS 2015/2017 > https://bugs.openjdk.java.net/browse/JDK-8196108 > > This continues to widen the range of compilers acceptable to build jdk8.? > This change lets us start a VS2017 build, will need further work on making > the build complete. > > This backport change is now out for review on build-dev. > > No changes are suggested regarding what is officially working or supported > at this time. > > Many thanks > Kevin > From kevin.walls at oracle.com Fri Jun 8 16:10:28 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 8 Jun 2018 17:10:28 +0100 Subject: [8u] Request for approval for CR 8196108: Add build support for VS 2015/2017 Message-ID: Hi, Following on from the enhancement request approval, I'd like to request approval to backport from 11 to 8u: 8196108: Add build support for VS 2015/2017 JBS: https://bugs.openjdk.java.net/browse/JDK-8196108 JDK 11 changeset:http://hg.openjdk.java.net/jdk/jdk/rev/bcce1fa183e7 Original review thread: http://mail.openjdk.java.net/pipermail/build-dev/2018-January/020719.html jdk8u webrev:http://cr.openjdk.java.net/~kevinw/8196108/webrev.00/ jdk8u review thread on build-dev: http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022314.html Tested locally and with JPRT on hotspot and jdk tests, using the existing default VS2010 compiler, so the standard build is unaffected. Many thanks Kevin From rob.mckenna at oracle.com Fri Jun 8 18:40:21 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 8 Jun 2018 19:40:21 +0100 Subject: [8u] Request for approval for CR 8196108: Add build support for VS 2015/2017 In-Reply-To: References: Message-ID: <20180608184021.GD4674@vimes> Approved -Rob On 08/06/18 17:10, Kevin Walls wrote: > Hi, > > Following on from the enhancement request approval, > I'd like to request approval to backport from 11 to 8u: > > 8196108: Add build support for VS 2015/2017 > JBS: https://bugs.openjdk.java.net/browse/JDK-8196108 > > JDK 11 changeset:http://hg.openjdk.java.net/jdk/jdk/rev/bcce1fa183e7 > > Original review thread: > http://mail.openjdk.java.net/pipermail/build-dev/2018-January/020719.html > > > jdk8u webrev:http://cr.openjdk.java.net/~kevinw/8196108/webrev.00/ > > jdk8u review thread on build-dev: http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022314.html > > > Tested locally and with JPRT on hotspot and jdk tests, using the existing default VS2010 compiler, so the standard build is unaffected. > > Many thanks > Kevin > From deepak.kejriwal at oracle.com Mon Jun 11 09:21:40 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Mon, 11 Jun 2018 02:21:40 -0700 (PDT) Subject: [8u-dev] Request for Approval: Backport of 8186171: HashMap: Entry.setValue may not work after Iterator.remove() called for previous entries Message-ID: <1c1fd1bb-33d5-4b67-b00d-a421a5290c91@default> Hi, Please approve the backport of 8176192 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8186171 Webrev for [8u-dev]: http://cr.openjdk.java.net/~rpatil/8186171/webrev.01/ JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053647.html Summary: The back port for test files is not clean back port as all tests files are extending JSR166TestCase.java which was added to JDK 9 as part of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8146467"JDK-8146467: Integrate JSR 166 jck tests into JDK repo. This is not present in JDK8 version. Therefore, I have extracted test are relevant to the fix done JDK-8186171 and created a new test file Bug8186171Test.java. All the related testing is done and is a pass. Regards, Deepak From david.buck at oracle.com Mon Jun 11 10:32:14 2018 From: david.buck at oracle.com (David Buck) Date: Mon, 11 Jun 2018 19:32:14 +0900 Subject: [8u-dev] Request for Approval: Backport of 8186171: HashMap: Entry.setValue may not work after Iterator.remove() called for previous entries In-Reply-To: <1c1fd1bb-33d5-4b67-b00d-a421a5290c91@default> References: <1c1fd1bb-33d5-4b67-b00d-a421a5290c91@default> Message-ID: <4d0d9e43-2a5c-0cef-fb46-15a426851e62@oracle.com> approved Cheers, -Buck On 2018/06/11 18:21, Deepak Kejriwal wrote: > Hi, > > > > Please approve the backport of 8176192 to 8u-dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186171 > > Webrev for [8u-dev]: http://cr.openjdk.java.net/~rpatil/8186171/webrev.01/ > > JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053647.html > > > > Summary: > > The back port for test files is not clean back port as all tests files are extending JSR166TestCase.java which was added to JDK 9 as part of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8146467"JDK-8146467: Integrate JSR 166 jck tests into JDK repo. This is not present in JDK8 version. > > Therefore, I have extracted test are relevant to the fix done JDK-8186171 and created a new test file Bug8186171Test.java. > > > > All the related testing is done and is a pass. > > > > Regards, > > Deepak > From rob.mckenna at oracle.com Mon Jun 11 15:39:01 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 11 Jun 2018 16:39:01 +0100 Subject: [8u-dev] RFA for JDK-8203182: Release session if initialization of SunPKCS11 Signature fails In-Reply-To: <20180605163325.GE4583@vimes> References: <20180605161221.GD4583@vimes> <20180605163325.GE4583@vimes> Message-ID: <20180611153901.GA2963@vimes> Resending with the correct bugid. (the main bug id should always be used on approval requests) -Rob On 05/06/18 17:33, Rob McKenna wrote: > Thanks for the confirmation Martin, > > Approved. > > -Rob > > On 05/06/18 13:19, Martin Balao wrote: > > Hi Rob, > > > > JDK patch applies cleanly if path is fixed according to jdk8u directories > > layout. > > > > Kind regards, > > Martin.- > > > > On Tue, Jun 5, 2018 at 1:12 PM, Rob McKenna wrote: > > > > > You will need a separate code review for the 8 backport if the original > > > patch does not apply cleanly after reshuffling. > > > > > > -Rob > > > > > > On 05/06/18 12:53, Martin Balao wrote: > > > > Hi, > > > > > > > > Here there is a backport of JDK-8203182 [1] to JDK8: > > > > > > > > * > > > > http://cr.openjdk.java.net/~mbalao/webrevs/8203182/ > > > backports/8/8203182.webrev.01/ > > > > * > > > > http://cr.openjdk.java.net/~mbalao/webrevs/8203182/ > > > backports/8/8203182.webrev.01.zip > > > > > > > > Backport ticket: JDK-8204343 [2]. > > > > JDK commit: http://hg.openjdk.java.net/jdk/jdk/rev/00ebc17f3cc6 > > > > Review approval: > > > > http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017224.html > > > > > > > > I'd be grateful if someone can approve it. > > > > > > > > Kind regards, > > > > Martin.- > > > > > > > > -- > > > > [1] - https://bugs.openjdk.java.net/browse/JDK-8203182 > > > > [2] - https://bugs.openjdk.java.net/browse/JDK-8204343 > > > From ivan.gerasimov at oracle.com Mon Jun 11 19:37:04 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 11 Jun 2018 12:37:04 -0700 Subject: [8u-dev] Request for Approval to Backport: 8140470 : javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java test failed with AccessControlException Message-ID: Hello! This is a test stabilization fix. I've seen a failure of the test with jdk8u, so I'd like to backport this fix. The patch applies cleanly. Control testing ran fine on all platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8140470 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/db0148cc63a6 Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013184.html Would you please approve the backport? -- With kind regards, Ivan Gerasimov From david.buck at oracle.com Mon Jun 11 23:22:27 2018 From: david.buck at oracle.com (David Buck) Date: Tue, 12 Jun 2018 08:22:27 +0900 Subject: [8u-dev] Request for Approval to Backport: 8140470 : javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java test failed with AccessControlException In-Reply-To: References: Message-ID: <0a4a87e3-7769-bbfa-828d-46535b85defb@oracle.com> approved Cheers, -Buck On 2018/06/12 4:37, Ivan Gerasimov wrote: > Hello! > > This is a test stabilization fix.? I've seen a failure of the test with > jdk8u, so I'd like to backport this fix. > > The patch applies cleanly.? Control testing ran fine on all platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140470 > > Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/db0148cc63a6 > > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013184.html > > > Would you please approve the backport? > From kevin.walls at oracle.com Tue Jun 12 19:13:28 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 12 Jun 2018 20:13:28 +0100 Subject: [8u-dev] Request for approval for CR 8150426: Wrong cast in metadata_at_put Message-ID: <62b30dbf-a823-00fe-8d90-5536c7cce7c8@oracle.com> Hi, I'd like to request approval to backport from 9 to 8u: 8150426: Wrong cast in metadata_at_put JBS: https://bugs.openjdk.java.net/browse/JDK-8150426 This fixes a build error if you vary the compiler from our defaults. 9 changeset: URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e06c15b0844e (diff pasted below) 9 review thread: http://openjdk.5641.n7.nabble.com/RFR-8150426-Wrong-cast-in-metadata-at-put-td258746.html This is a clean backport, or imports with minimal/trivial changes. Thanks! Kevin --- a/src/share/vm/oops/typeArrayOop.hpp Wed Feb 24 13:18:54 2016 -0500 +++ b/src/share/vm/oops/typeArrayOop.hpp Tue Feb 23 18:58:36 2016 -0500 @@ -129,7 +129,7 @@ Metadata* metadata_at(int which) const { return (Metadata*)*long_at_addr(which); } void metadata_at_put(int which, Metadata* contents) { - *long_at_addr(which) = (long)contents; + *long_at_addr(which) = (jlong)contents; } #else Metadata* metadata_at(int which) const { From alexey.ivanov at oracle.com Tue Jun 12 20:56:21 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 12 Jun 2018 21:56:21 +0100 Subject: [8u-dev] RFA for 8179675: Build with error on windows with new Cygwin grep In-Reply-To: References: <6d4d3cdc-5a3b-1d77-1739-7528ddac6c3f@oracle.com> Message-ID: <6c394cbe-8ecf-4e52-b8b5-1c25e8196f94@oracle.com> Hi, Could I get an approval for the following 8u-specific fix? Latest webrev: http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/ Review thread: http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022361.html Thank you in advance. Regards, Alexey On 12/06/2018 21:05, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2018-06-12 11:08, Alexey Ivanov wrote: >> Resending with clickable link to the webrev: >> http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/ >> >> -- >> Alexey >> >> On 12/06/2018 19:06, Alexey Ivanov wrote: >>> Hi, >>> >>> Could you please review the following fix for 8u-dev? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179675 >>> webrev: http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/ >>> >>> The problem is that newer grep v3.0 does not match the end-of-line >>> if the input uses Windows line endings. >>> >>> The fix removes CR, '\r', from the input before processing with grep. >>> >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey >> > From rob.mckenna at oracle.com Tue Jun 12 21:14:47 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 12 Jun 2018 22:14:47 +0100 Subject: [8u-dev] Request for approval for CR 8150426: Wrong cast in metadata_at_put In-Reply-To: <62b30dbf-a823-00fe-8d90-5536c7cce7c8@oracle.com> References: <62b30dbf-a823-00fe-8d90-5536c7cce7c8@oracle.com> Message-ID: <20180612211447.GB20362@vimes> Approved -Rob On 12/06/18 20:13, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 9 to 8u: > > 8150426: Wrong cast in metadata_at_put > JBS: https://bugs.openjdk.java.net/browse/JDK-8150426 > > This fixes a build error if you vary the compiler from our defaults. > > 9 changeset: > URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e06c15b0844e > (diff pasted below) > > 9 review thread: > http://openjdk.5641.n7.nabble.com/RFR-8150426-Wrong-cast-in-metadata-at-put-td258746.html > > This is a clean backport, or imports with minimal/trivial changes. > > Thanks! > Kevin > > > > --- a/src/share/vm/oops/typeArrayOop.hpp Wed Feb 24 13:18:54 2016 -0500 > > +++ b/src/share/vm/oops/typeArrayOop.hpp Tue Feb 23 18:58:36 2016 -0500 > > @@ -129,7 +129,7 @@ > > Metadata* metadata_at(int which) const { > > return (Metadata*)*long_at_addr(which); } > > void metadata_at_put(int which, Metadata* contents) { > > - *long_at_addr(which) = (long)contents; > > + *long_at_addr(which) = (jlong)contents; > > } > > #else > > Metadata* metadata_at(int which) const { > From rob.mckenna at oracle.com Tue Jun 12 21:41:22 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 12 Jun 2018 22:41:22 +0100 Subject: [8u-dev] RFA for 8179675: Build with error on windows with new Cygwin grep In-Reply-To: <6c394cbe-8ecf-4e52-b8b5-1c25e8196f94@oracle.com> References: <6d4d3cdc-5a3b-1d77-1739-7528ddac6c3f@oracle.com> <6c394cbe-8ecf-4e52-b8b5-1c25e8196f94@oracle.com> Message-ID: <20180612214122.GC20362@vimes> Approved -Rob On 12/06/18 21:56, Alexey Ivanov wrote: > Hi, > > Could I get an approval for the following 8u-specific fix? > > Latest webrev: > http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/ > > Review thread: > http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022361.html > > > Thank you in advance. > > Regards, > Alexey > > On 12/06/2018 21:05, Erik Joelsson wrote: > >Looks good. > > > >/Erik > > > > > >On 2018-06-12 11:08, Alexey Ivanov wrote: > >>Resending with clickable link to the webrev: > >>http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/ > >> > >>-- > >>Alexey > >> > >>On 12/06/2018 19:06, Alexey Ivanov wrote: > >>>Hi, > >>> > >>>Could you please review the following fix for 8u-dev? > >>> > >>>JBS: https://bugs.openjdk.java.net/browse/JDK-8179675 > >>>webrev: http://cr.openjdk.java.net/~aivanov/8179675/jdk8/webrev.0/ > >>> > >>>The problem is that newer grep v3.0 does not match the end-of-line if > >>>the input uses Windows line endings. > >>> > >>>The fix removes CR, '\r', from the input before processing with grep. > >>> > >>> > >>>Thank you in advance. > >>> > >>>Regards, > >>>Alexey > >> > > > From philip.race at oracle.com Wed Jun 13 01:21:40 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 12 Jun 2018 18:21:40 -0700 Subject: Request for Approval: Backport of 8203499: Uninitialised memory in WinAccessBridge.cpp:485 Message-ID: <5B2071A4.8080104@oracle.com> Request to backport this fix to 8u. Patch from 11 applied cleanly (after reshuffle) All builds fine on internal build servers for 8. bug : https://bugs.openjdk.java.net/browse/JDK-8203499 11 review thread : http://mail.openjdk.java.net/pipermail/swing-dev/2018-June/008649.html 11 webrev : http://cr.openjdk.java.net/~prr/8203499/ 11 changeset : http://hg.openjdk.java.net/jdk/jdk/rev/10b8e57899b3 8 webrev : http://cr.openjdk.java.net/~prr/8203499.8u/ -phil. From david.buck at oracle.com Wed Jun 13 01:31:34 2018 From: david.buck at oracle.com (David Buck) Date: Wed, 13 Jun 2018 10:31:34 +0900 Subject: Request for Approval: Backport of 8203499: Uninitialised memory in WinAccessBridge.cpp:485 In-Reply-To: <5B2071A4.8080104@oracle.com> References: <5B2071A4.8080104@oracle.com> Message-ID: <5A3871B3-39F4-445A-99CE-DC9D6A0522B9@oracle.com> approved Cheers, -Buck > On Jun 13, 2018, at 10:21, Philip Race wrote: > > > Request to backport this fix to 8u. Patch from 11 applied cleanly (after reshuffle) > All builds fine on internal build servers for 8. > > bug : https://bugs.openjdk.java.net/browse/JDK-8203499 > 11 review thread : http://mail.openjdk.java.net/pipermail/swing-dev/2018-June/008649.html > 11 webrev : http://cr.openjdk.java.net/~prr/8203499/ > 11 changeset : http://hg.openjdk.java.net/jdk/jdk/rev/10b8e57899b3 > 8 webrev : http://cr.openjdk.java.net/~prr/8203499.8u/ > > -phil. From neugens at redhat.com Wed Jun 13 12:39:43 2018 From: neugens at redhat.com (Mario Torre) Date: Wed, 13 Jun 2018 14:39:43 +0200 Subject: Request for Approval: Backport of JDK-8188030: AWT java apps fail to start when some minimal fonts are present In-Reply-To: <20171115173815.GE3687@vimes> References: <20171115173815.GE3687@vimes> Message-ID: Hello Rob, Sorry to resurrect this old thread. I would like to ask permission to push the following change to jdk8u-dev: http://cr.openjdk.java.net/~neugens/8188030/webrev-jdk8.01/ The discussion is here (it spans multiple months, I apologise in advance, but I'm linking the final decision): http://mail.openjdk.java.net/pipermail/2d-dev/2018-June/009297.html The original bug is here: https://bugs.openjdk.java.net/browse/JDK-8188030 There may be some additional work necessary for the closed JDK, but I have no way to test that, in that case there may be a follow up bug to address the missing part and I'll be happy to assist if necessary where possible. Cheers, Mario On Wed, Nov 15, 2017 at 6:38 PM, Rob McKenna wrote: > Hi Mario, > > Given that there are changes you'll need to get the new fix reviewed > first. > > Once that is done the request will be processed. > > If approved you can then push using the master bug id. > > -Rob > > On 15/11/17 18:17, Mario Torre wrote: >> Hi all, >> >> I would like to backport the fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8188030 >> >> To OpenJDK8 updates dev: >> >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev >> >> The fix is slightly different than the fix for 10 [1] since we want to >> preserve the status for the Oracle build that I'm told does not >> support the CFF fonts in 8: >> >> http://cr.openjdk.java.net/~neugens/8188030/webrev-jdk8.01/ >> >> I apologise for continually asking this, I promise I'll write this >> down this time, but I don't remember what's the next step after that, >> just push the fix after approval with the same bug id, right? >> >> Cheers, >> Mario >> >> [1] http://hg.openjdk.java.net/jdk10/client/rev/d5a1cde89944 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From rob.mckenna at oracle.com Wed Jun 13 13:09:03 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 13 Jun 2018 14:09:03 +0100 Subject: Request for Approval: Backport of JDK-8188030: AWT java apps fail to start when some minimal fonts are present In-Reply-To: References: <20171115173815.GE3687@vimes> Message-ID: <20180613130903.GA11145@vimes> No problem at all Mario. Looks like Phil is happy to proceed. Phil, I assume the issues that Mario has raised are on your radar and you're happy to proceed as per the codereview. Please add an appropriate noreg label to the master bug. Approved. -Rob On 13/06/18 14:39, Mario Torre wrote: > Hello Rob, > > Sorry to resurrect this old thread. > > I would like to ask permission to push the following change to jdk8u-dev: > > http://cr.openjdk.java.net/~neugens/8188030/webrev-jdk8.01/ > > The discussion is here (it spans multiple months, I apologise in > advance, but I'm linking the final decision): > > http://mail.openjdk.java.net/pipermail/2d-dev/2018-June/009297.html > > The original bug is here: > > https://bugs.openjdk.java.net/browse/JDK-8188030 > > There may be some additional work necessary for the closed JDK, but I > have no way to test that, in that case there may be a follow up bug to > address the missing part and I'll be happy to assist if necessary > where possible. > > Cheers, > Mario > > On Wed, Nov 15, 2017 at 6:38 PM, Rob McKenna wrote: > > Hi Mario, > > > > Given that there are changes you'll need to get the new fix reviewed > > first. > > > > Once that is done the request will be processed. > > > > If approved you can then push using the master bug id. > > > > -Rob > > > > On 15/11/17 18:17, Mario Torre wrote: > >> Hi all, > >> > >> I would like to backport the fix for: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8188030 > >> > >> To OpenJDK8 updates dev: > >> > >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev > >> > >> The fix is slightly different than the fix for 10 [1] since we want to > >> preserve the status for the Oracle build that I'm told does not > >> support the CFF fonts in 8: > >> > >> http://cr.openjdk.java.net/~neugens/8188030/webrev-jdk8.01/ > >> > >> I apologise for continually asking this, I promise I'll write this > >> down this time, but I don't remember what's the next step after that, > >> just push the fix after approval with the same bug id, right? > >> > >> Cheers, > >> Mario > >> > >> [1] http://hg.openjdk.java.net/jdk10/client/rev/d5a1cde89944 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Wed Jun 13 13:58:17 2018 From: neugens at redhat.com (Mario Torre) Date: Wed, 13 Jun 2018 15:58:17 +0200 Subject: Request for Approval: Backport of JDK-8188030: AWT java apps fail to start when some minimal fonts are present In-Reply-To: <20180613130903.GA11145@vimes> References: <20171115173815.GE3687@vimes> <20180613130903.GA11145@vimes> Message-ID: Hi Rob, Thanks, I just merged. I added a noreg-hard label, not sure if that's what you wanted, please let me know if I should change that. Thanks again! Cheers, Mario On Wed, Jun 13, 2018 at 3:09 PM, Rob McKenna wrote: > No problem at all Mario. > > Looks like Phil is happy to proceed. > > Phil, I assume the issues that Mario has raised are on your radar and > you're happy to proceed as per the codereview. > > Please add an appropriate noreg label to the master bug. > > Approved. > > -Rob > > On 13/06/18 14:39, Mario Torre wrote: >> Hello Rob, >> >> Sorry to resurrect this old thread. >> >> I would like to ask permission to push the following change to jdk8u-dev: >> >> http://cr.openjdk.java.net/~neugens/8188030/webrev-jdk8.01/ >> >> The discussion is here (it spans multiple months, I apologise in >> advance, but I'm linking the final decision): >> >> http://mail.openjdk.java.net/pipermail/2d-dev/2018-June/009297.html >> >> The original bug is here: >> >> https://bugs.openjdk.java.net/browse/JDK-8188030 >> >> There may be some additional work necessary for the closed JDK, but I >> have no way to test that, in that case there may be a follow up bug to >> address the missing part and I'll be happy to assist if necessary >> where possible. >> >> Cheers, >> Mario >> >> On Wed, Nov 15, 2017 at 6:38 PM, Rob McKenna wrote: >> > Hi Mario, >> > >> > Given that there are changes you'll need to get the new fix reviewed >> > first. >> > >> > Once that is done the request will be processed. >> > >> > If approved you can then push using the master bug id. >> > >> > -Rob >> > >> > On 15/11/17 18:17, Mario Torre wrote: >> >> Hi all, >> >> >> >> I would like to backport the fix for: >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8188030 >> >> >> >> To OpenJDK8 updates dev: >> >> >> >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev >> >> >> >> The fix is slightly different than the fix for 10 [1] since we want to >> >> preserve the status for the Oracle build that I'm told does not >> >> support the CFF fonts in 8: >> >> >> >> http://cr.openjdk.java.net/~neugens/8188030/webrev-jdk8.01/ >> >> >> >> I apologise for continually asking this, I promise I'll write this >> >> down this time, but I don't remember what's the next step after that, >> >> just push the fix after approval with the same bug id, right? >> >> >> >> Cheers, >> >> Mario >> >> >> >> [1] http://hg.openjdk.java.net/jdk10/client/rev/d5a1cde89944 >> >> >> >> -- >> Mario Torre >> Associate Manager, Software Engineering >> Red Hat GmbH >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From kevin.walls at oracle.com Wed Jun 13 14:00:09 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 13 Jun 2018 15:00:09 +0100 Subject: [8u-dev] Request for approval for CR 8196884: VS2017 Multiple Type Cast Conversion Compilation Errors Message-ID: <7533319d-a5e8-c78d-d675-5126493c6a99@oracle.com> Hi, I'd like to request approval to backport from 11 to 8u: 8196884: VS2017 Multiple Type Cast Conversion Compilation Errors JBS: https://bugs.openjdk.java.net/browse/JDK-8196884 11 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/844bf1deff1a 11 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030221.html After path unshuffling, the only import rejects are copyright years which I'm fixing manually. Thanks Kevin From deepak.kejriwal at oracle.com Mon Jun 4 09:42:02 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Mon, 4 Jun 2018 02:42:02 -0700 (PDT) Subject: [8u-dev] Request for Approval: Backport of 8176192: Incorrect usage of Iterator in Java 8 In com.sun.jndi.ldap.EventSupport.removeNamingListener Message-ID: <106a7706-d5ba-4c73-940b-0afa0dfcd7ae@default> Hi, Please approve the backport of 8176192 to 8u-dev. BugHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8176192": https://bugs.openjdk.java.net/browse/JDK-8203910 JDK Change set: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3d52a1fd3eea JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048242.html Changes applied cleanly to jdk8u-dev after path reshuffling. All the related testing is done and is a pass. Regards, Deepak From deepak.kejriwal at oracle.com Thu Jun 7 08:32:09 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Thu, 7 Jun 2018 01:32:09 -0700 (PDT) Subject: [8u-dev] Request for Approval: Backport of 8176192: Incorrect usage of Iterator in Java 8 In com.sun.jndi.ldap.EventSupport.removeNamingListener In-Reply-To: <106a7706-d5ba-4c73-940b-0afa0dfcd7ae@default> References: <106a7706-d5ba-4c73-940b-0afa0dfcd7ae@default> Message-ID: Hi All, Gentle reminder. Please provide the approval for backport of 8176192 to 8u-dev. Regards, Deepak From: Deepak Kejriwal Sent: Monday, June 4, 2018 3:12 PM To: jdk8u-dev at openjdk.java.net Subject: [8u-dev] Request for Approval: Backport of 8176192: Incorrect usage of Iterator in Java 8 In com.sun.jndi.ldap.EventSupport.removeNamingListener Hi, Please approve the backport of 8176192 to 8u-dev. BugHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8176192": https://bugs.openjdk.java.net/browse/JDK-8203910 JDK Change set: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3d52a1fd3eea JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048242.html Changes applied cleanly to jdk8u-dev after path reshuffling. All the related testing is done and is a pass. Regards, Deepak From rob.mckenna at oracle.com Wed Jun 13 14:36:08 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 13 Jun 2018 15:36:08 +0100 Subject: [8u-dev] Request for approval for CR 8196884: VS2017 Multiple Type Cast Conversion Compilation Errors In-Reply-To: <7533319d-a5e8-c78d-d675-5126493c6a99@oracle.com> References: <7533319d-a5e8-c78d-d675-5126493c6a99@oracle.com> Message-ID: <20180613143608.GG11145@vimes> Approved -Rob On 13/06/18 15:00, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 11 to 8u: > > 8196884: VS2017 Multiple Type Cast Conversion Compilation Errors > JBS: https://bugs.openjdk.java.net/browse/JDK-8196884 > > 11 changeset: > http://hg.openjdk.java.net/jdk/jdk/rev/844bf1deff1a > > 11 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030221.html > > After path unshuffling, the only import rejects are copyright years which I'm fixing manually. > > Thanks > Kevin > From kevin.walls at oracle.com Thu Jun 14 13:47:13 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 14 Jun 2018 14:47:13 +0100 Subject: [8u-dev] Request for approval for CR 8081202: Hotspot compile warning: "Invalid suffix on literal; C++11 requires a space between literal and identifier" Message-ID: <632cdce8-d84c-0043-f3df-6af3887c9261@oracle.com> Hi, I'd like to request approval to backport from 9 to 8u: 8081202: Hotspot compile warning: "Invalid suffix on literal; C++11 requires a space between literal and identifier" JBS: https://bugs.openjdk.java.net/browse/JDK-8081202 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/767f36deb0dc Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018677.html Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8081202/webrev.00/ This doesn't all backport cleanly, but the manual work is very very routine, and all about adding a space between a " and a macro.? It changes 76 files. Testing has gone OK, this doesn't change the regular jdk8 builds. Thanks! Kevin From kevin.walls at oracle.com Thu Jun 14 15:59:12 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 14 Jun 2018 16:59:12 +0100 Subject: [8u-dev] Request for approval for CR 8197868: VS2017 (C2065) 'timezone': Undeclared Identifier in share/runtime/os.cpp Message-ID: <1a4511a8-a111-64d9-e5b6-1c1e0831813b@oracle.com> Hi, I'd like to request approval to backport from 11 to 8u: 8197868: VS2017 (C2065) 'timezone': Undeclared Identifier in share/runtime/os.cpp JBS: https://bugs.openjdk.java.net/browse/JDK-8197868 11 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/a04a9bee2431 11 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030273.html This is a clean backport (hg import). This avoids a build error if you use a more recent compiler on Windows. Testing with the current standard compilers is going OK. Thanks Kevin From rob.mckenna at oracle.com Thu Jun 14 16:04:51 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 14 Jun 2018 17:04:51 +0100 Subject: [8u-dev] Request for approval for CR 8081202: Hotspot compile warning: "Invalid suffix on literal; C++11 requires a space between literal and identifier" In-Reply-To: <632cdce8-d84c-0043-f3df-6af3887c9261@oracle.com> References: <632cdce8-d84c-0043-f3df-6af3887c9261@oracle.com> Message-ID: <20180614160451.GB4129@vimes> Approved -Rob On 14/06/18 14:47, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 9 to 8u: > > 8081202: Hotspot compile warning: "Invalid suffix on literal; C++11 requires > a space between literal and identifier" > JBS: https://bugs.openjdk.java.net/browse/JDK-8081202 > > 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/767f36deb0dc > > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018677.html > > Proposed 8u change: > http://cr.openjdk.java.net/~kevinw/8081202/webrev.00/ > > This doesn't all backport cleanly, but the manual work is very very routine, > and all about adding a space between a " and a macro.? It changes 76 files. > > Testing has gone OK, this doesn't change the regular jdk8 builds. > > Thanks! > Kevin > From rob.mckenna at oracle.com Thu Jun 14 16:05:08 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 14 Jun 2018 17:05:08 +0100 Subject: [8u-dev] Request for approval for CR 8197868: VS2017 (C2065) 'timezone': Undeclared Identifier in share/runtime/os.cpp In-Reply-To: <1a4511a8-a111-64d9-e5b6-1c1e0831813b@oracle.com> References: <1a4511a8-a111-64d9-e5b6-1c1e0831813b@oracle.com> Message-ID: <20180614160508.GC4129@vimes> Approved -Rob On 14/06/18 16:59, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 11 to 8u: > > 8197868: VS2017 (C2065) 'timezone': Undeclared Identifier in > share/runtime/os.cpp > JBS: https://bugs.openjdk.java.net/browse/JDK-8197868 > > 11 changeset: > http://hg.openjdk.java.net/jdk/jdk/rev/a04a9bee2431 > > 11 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030273.html > > This is a clean backport (hg import). > > This avoids a build error if you use a more recent compiler on Windows. > Testing with the current standard compilers is going OK. > > Thanks > Kevin > From kevin.walls at oracle.com Fri Jun 15 09:16:13 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 15 Jun 2018 10:16:13 +0100 Subject: [8u-dev] Request for approval for CR 8150688: Fix os_windows siglabel Message-ID: Hi, I'd like to request approval to backport from 9 to 8u: 8150688: Fix os_windows siglabel JBS: https://bugs.openjdk.java.net/browse/JDK-8150688 9 changeset: URL:?? http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/80706cc25494 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018236.html Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8150688/webrev.00/ This is a pretty clean backport. but didn't import automatically: in 8u there is no "os::get_signal_number()" and some of the def_excpt... lines didn't apply automatically, but they are the same change. This removes some errors when varying the windows compiler in use, still builds and tests OK on current standard VS compiler. Thanks! Kevin From kevin.walls at oracle.com Fri Jun 15 10:47:27 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 15 Jun 2018 11:47:27 +0100 Subject: [8u-dev] Request for approval for CR 8197864: VS2017 (C4334) Result of 32-bit Shift Implicitly Converted to 64 bits Message-ID: <6ecac393-f32f-2482-6504-1ec4a13ac694@oracle.com> Hi, I'd like to request approval to backport from 11 to 8u: 8197864: VS2017 (C4334) Result of 32-bit Shift Implicitly Converted to 64 bits JBS: https://bugs.openjdk.java.net/browse/JDK-8197864 This removes an error and build failure when varying the Windows compiler from our default. 11 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/23348e42fb34 11 review thread: http://openjdk.5641.n7.nabble.com/11-RFR-S-JDK-8197864-VS2017-C4334-Result-of-32-bit-Shift-Implicitly-Converted-to-64-bits-td327483.html This would be a clean backport but for the copyright year. Thanks Kevin From kevin.walls at oracle.com Fri Jun 15 11:00:14 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 15 Jun 2018 12:00:14 +0100 Subject: [8u-dev] Request for approval for CR 8204872: [8u] VS2017: threadLocalAllocBuffer.inline.hpp(99): error C3680: cannot concatenate user-defined string literals with mismatched literal suffix identifiers Message-ID: <7f561224-4b5c-96e6-697d-7896d21c4b5f@oracle.com> Hi, I'd like to request approval to push to 8u: 8204872: [8u] VS2017: threadLocalAllocBuffer.inline.hpp(99): error C3680: cannot concatenate user-defined string literals with mismatched literal suffix identifiers JBS: https://bugs.openjdk.java.net/browse/JDK-8204872 This is a new change, but a change to whitespace, following? the same pattern as 8081202 which is recently backported to 8u, i.e. add a space between string literals and macros, to avoid compile errors. This wasn't covered by 8081202 as it's in code which was no longer the same in 9, due to: 8145092: Use Unified Logging for the GC logging (which we are not backporting). Text diff is below, I've run it in various recent tests, but do let me know if a webrev or other approval is required. Many thanks Kevin bash-4.2$ hg status M src/share/vm/memory/threadLocalAllocBuffer.inline.hpp bash-4.2$ hg diff src/share/vm/memory/threadLocalAllocBuffer.inline.hpp diff -r 6688d6c6a225 src/share/vm/memory/threadLocalAllocBuffer.inline.hpp --- a/src/share/vm/memory/threadLocalAllocBuffer.inline.hpp???? Tue Feb 20 07:10:42 2018 -0500 +++ b/src/share/vm/memory/threadLocalAllocBuffer.inline.hpp???? Fri Jun 15 03:48:33 2018 -0700 @@ -94,10 +94,10 @@ ?? if (PrintTLAB && Verbose) { ???? Thread* thrd = myThread(); -??? gclog_or_tty->print("TLAB: %s thread: "INTPTR_FORMAT" [id: %2d]" -??????????????????????? " obj: "SIZE_FORMAT -??????????????????????? " free: "SIZE_FORMAT -??????????????????????? " waste: "SIZE_FORMAT"\n", +??? gclog_or_tty->print("TLAB: %s thread: " INTPTR_FORMAT " [id: %2d]" +??????????????????????? " obj: " SIZE_FORMAT +??????????????????????? " free: " SIZE_FORMAT +??????????????????????? " waste: " SIZE_FORMAT "\n" ???????????????????????? "slow", p2i(thrd), thrd->osthread()->thread_id(), ???????????????????????? obj_size, free(), refill_waste_limit()); ?? } From rob.mckenna at oracle.com Fri Jun 15 12:57:07 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 15 Jun 2018 13:57:07 +0100 Subject: [8u-dev] Request for approval for CR 8150688: Fix os_windows siglabel In-Reply-To: References: Message-ID: <20180615125707.GA3481@vimes> The changes will need a codereview. -Rob On 15/06/18 10:16, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 9 to 8u: > > 8150688: Fix os_windows siglabel > JBS: https://bugs.openjdk.java.net/browse/JDK-8150688 > > 9 changeset: > URL:?? http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/80706cc25494 > > 9 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018236.html > > Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8150688/webrev.00/ > > This is a pretty clean backport. but didn't import automatically: in 8u > there is no "os::get_signal_number()" and some of the def_excpt... lines > didn't apply automatically, but they are the same change. > > This removes some errors when varying the windows compiler in use, still > builds and tests OK on current standard VS compiler. > > Thanks! > Kevin > From rob.mckenna at oracle.com Fri Jun 15 12:57:21 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 15 Jun 2018 13:57:21 +0100 Subject: [8u-dev] Request for approval for CR 8197864: VS2017 (C4334) Result of 32-bit Shift Implicitly Converted to 64 bits In-Reply-To: <6ecac393-f32f-2482-6504-1ec4a13ac694@oracle.com> References: <6ecac393-f32f-2482-6504-1ec4a13ac694@oracle.com> Message-ID: <20180615125721.GB3481@vimes> Approved -Rob On 15/06/18 11:47, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 11 to 8u: > > 8197864: VS2017 (C4334) Result of 32-bit Shift Implicitly Converted to 64 > bits > JBS: https://bugs.openjdk.java.net/browse/JDK-8197864 > > This removes an error and build failure when varying the Windows compiler > from our default. > > 11 changeset: > http://hg.openjdk.java.net/jdk/jdk/rev/23348e42fb34 > > 11 review thread: > http://openjdk.5641.n7.nabble.com/11-RFR-S-JDK-8197864-VS2017-C4334-Result-of-32-bit-Shift-Implicitly-Converted-to-64-bits-td327483.html > > This would be a clean backport but for the copyright year. > > Thanks > Kevin > From rob.mckenna at oracle.com Fri Jun 15 12:58:17 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 15 Jun 2018 13:58:17 +0100 Subject: [8u-dev] Request for approval for CR 8204872: [8u] VS2017: threadLocalAllocBuffer.inline.hpp(99): error C3680: cannot concatenate user-defined string literals with mismatched literal suffix identifiers In-Reply-To: <7f561224-4b5c-96e6-697d-7896d21c4b5f@oracle.com> References: <7f561224-4b5c-96e6-697d-7896d21c4b5f@oracle.com> Message-ID: <20180615125817.GC3481@vimes> This will require a codereview as its a new change. -Rob On 15/06/18 12:00, Kevin Walls wrote: > Hi, > > I'd like to request approval to push to 8u: > > 8204872: [8u] VS2017: threadLocalAllocBuffer.inline.hpp(99): error C3680: > cannot concatenate user-defined string literals with mismatched literal > suffix identifiers > JBS: https://bugs.openjdk.java.net/browse/JDK-8204872 > > This is a new change, but a change to whitespace, following? the same > pattern as 8081202 which is recently backported to 8u, i.e. add a space > between string literals and macros, to avoid compile errors. > This wasn't covered by 8081202 as it's in code which was no longer the same > in 9, due to: > 8145092: Use Unified Logging for the GC logging > (which we are not backporting). > > Text diff is below, I've run it in various recent tests, but do let me know > if a webrev or other approval is required. > > Many thanks > Kevin > > bash-4.2$ hg status > M src/share/vm/memory/threadLocalAllocBuffer.inline.hpp > bash-4.2$ hg diff src/share/vm/memory/threadLocalAllocBuffer.inline.hpp > diff -r 6688d6c6a225 src/share/vm/memory/threadLocalAllocBuffer.inline.hpp > --- a/src/share/vm/memory/threadLocalAllocBuffer.inline.hpp???? Tue Feb 20 > 07:10:42 2018 -0500 > +++ b/src/share/vm/memory/threadLocalAllocBuffer.inline.hpp???? Fri Jun 15 > 03:48:33 2018 -0700 > @@ -94,10 +94,10 @@ > > ?? if (PrintTLAB && Verbose) { > ???? Thread* thrd = myThread(); > -??? gclog_or_tty->print("TLAB: %s thread: "INTPTR_FORMAT" [id: %2d]" > -??????????????????????? " obj: "SIZE_FORMAT > -??????????????????????? " free: "SIZE_FORMAT > -??????????????????????? " waste: "SIZE_FORMAT"\n", > +??? gclog_or_tty->print("TLAB: %s thread: " INTPTR_FORMAT " [id: %2d]" > +??????????????????????? " obj: " SIZE_FORMAT > +??????????????????????? " free: " SIZE_FORMAT > +??????????????????????? " waste: " SIZE_FORMAT "\n" > ???????????????????????? "slow", p2i(thrd), thrd->osthread()->thread_id(), > ???????????????????????? obj_size, free(), refill_waste_limit()); > ?? } > From sgehwolf at redhat.com Fri Jun 15 13:55:22 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Jun 2018 15:55:22 +0200 Subject: RFA: 8205104: EXTRA_LDFLAGS not consistently being used Message-ID: Hi, Please approve this 8u-only change for the hotspot build where EXTRA_LDFLAGS aren't correctly passed down to all library builds. The build system changed in 10+ and isn't applicable there. Review-thread: http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022398.html Bug: https://bugs.openjdk.java.net/browse/JDK-8205104 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8205104/webrev.01/ Thanks, Severin From rob.mckenna at oracle.com Fri Jun 15 14:51:08 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 15 Jun 2018 15:51:08 +0100 Subject: RFA: 8205104: EXTRA_LDFLAGS not consistently being used In-Reply-To: References: Message-ID: <20180615145108.GD3481@vimes> Approved -Rob On 15/06/18 15:55, Severin Gehwolf wrote: > Hi, > > Please approve this 8u-only change for the hotspot build where > EXTRA_LDFLAGS aren't correctly passed down to all library builds. The > build system changed in 10+ and isn't applicable there. > > Review-thread: http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022398.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8205104 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8205104/webrev.01/ > > Thanks, > Severin From sean.coffey at oracle.com Fri Jun 15 17:14:18 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 15 Jun 2018 18:14:18 +0100 Subject: [8u-dev] Request for approval for CR 8204872: [8u] VS2017: threadLocalAllocBuffer.inline.hpp(99): error C3680: cannot concatenate user-defined string literals with mismatched literal suffix identifiers In-Reply-To: <20180615125817.GC3481@vimes> References: <7f561224-4b5c-96e6-697d-7896d21c4b5f@oracle.com> <20180615125817.GC3481@vimes> Message-ID: This looks fine to me Kevin. Approved. Regards, Sean. On 15/06/18 13:58, Rob McKenna wrote: > This will require a codereview as its a new change. > > -Rob > > On 15/06/18 12:00, Kevin Walls wrote: >> Hi, >> >> I'd like to request approval to push to 8u: >> >> 8204872: [8u] VS2017: threadLocalAllocBuffer.inline.hpp(99): error C3680: >> cannot concatenate user-defined string literals with mismatched literal >> suffix identifiers >> JBS: https://bugs.openjdk.java.net/browse/JDK-8204872 >> >> This is a new change, but a change to whitespace, following the same >> pattern as 8081202 which is recently backported to 8u, i.e. add a space >> between string literals and macros, to avoid compile errors. >> This wasn't covered by 8081202 as it's in code which was no longer the same >> in 9, due to: >> 8145092: Use Unified Logging for the GC logging >> (which we are not backporting). >> >> Text diff is below, I've run it in various recent tests, but do let me know >> if a webrev or other approval is required. >> >> Many thanks >> Kevin >> >> bash-4.2$ hg status >> M src/share/vm/memory/threadLocalAllocBuffer.inline.hpp >> bash-4.2$ hg diff src/share/vm/memory/threadLocalAllocBuffer.inline.hpp >> diff -r 6688d6c6a225 src/share/vm/memory/threadLocalAllocBuffer.inline.hpp >> --- a/src/share/vm/memory/threadLocalAllocBuffer.inline.hpp Tue Feb 20 >> 07:10:42 2018 -0500 >> +++ b/src/share/vm/memory/threadLocalAllocBuffer.inline.hpp Fri Jun 15 >> 03:48:33 2018 -0700 >> @@ -94,10 +94,10 @@ >> >> if (PrintTLAB && Verbose) { >> Thread* thrd = myThread(); >> - gclog_or_tty->print("TLAB: %s thread: "INTPTR_FORMAT" [id: %2d]" >> - " obj: "SIZE_FORMAT >> - " free: "SIZE_FORMAT >> - " waste: "SIZE_FORMAT"\n", >> + gclog_or_tty->print("TLAB: %s thread: " INTPTR_FORMAT " [id: %2d]" >> + " obj: " SIZE_FORMAT >> + " free: " SIZE_FORMAT >> + " waste: " SIZE_FORMAT "\n" >> "slow", p2i(thrd), thrd->osthread()->thread_id(), >> obj_size, free(), refill_waste_limit()); >> } >> From sgehwolf at redhat.com Mon Jun 18 14:36:32 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Jun 2018 16:36:32 +0200 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path Message-ID: Hi, Please approve these two backports to JDK 8u-dev which are already in JDK 9 and better. 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch 8148351: Only display resolved symlink for compiler, do not change path webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch Bug 8031668 is a dependency for 8148351 which actually fixes the wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is the same as for JDK 9, modulo some context changes. After the JDK 8 patch of 8031668, the JDK 9 patch of 8148351 imports as is. The issue at hand is that one cannot build the JDK 8 tree with certain compiler wrappers such as cscppc. It currently fails with: configure: Using default toolchain gcc (GNU Compiler Collection) checking for gcc... /usr/lib64/cscppc/gcc checking resolved symbolic links for CC... /usr/bin/cscppc checking if CC is disguised ccache... no, keeping CC configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler. configure: The result from running with --version was: "" configure: error: A gcc compiler is required. Try setting --with-tools-dir. configure exiting with result code 1 After both backports configure with a wrapped GCC succeeds. Please note that I'd need an Oracle sponsor for getting this pushed to jdk8u-dev since both changes require re-generation of generated- configure.sh Thanks, Severin From rob.mckenna at oracle.com Mon Jun 18 16:45:44 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 18 Jun 2018 17:45:44 +0100 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: References: Message-ID: <20180618164544.GB3250@vimes> Approved. Please work with the appropriate team to find a sponsor. -Rob On 18/06/18 16:36, Severin Gehwolf wrote: > Hi, > > Please approve these two backports to JDK 8u-dev which are already in > JDK 9 and better. > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch > > 8148351: Only display resolved symlink for compiler, do not change path > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch > > Bug 8031668 is a dependency for 8148351 which actually fixes the > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is > the same as for JDK 9, modulo some context changes. After the JDK 8 > patch of 8031668, the JDK 9 patch of 8148351 imports as is. > > The issue at hand is that one cannot build the JDK 8 tree with certain > compiler wrappers such as cscppc. It currently fails with: > > configure: Using default toolchain gcc (GNU Compiler Collection) > checking for gcc... /usr/lib64/cscppc/gcc > checking resolved symbolic links for CC... /usr/bin/cscppc > checking if CC is disguised ccache... no, keeping CC > configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler. > configure: The result from running with --version was: "" > configure: error: A gcc compiler is required. Try setting --with-tools-dir. > configure exiting with result code 1 > > After both backports configure with a wrapped GCC succeeds. > > Please note that I'd need an Oracle sponsor for getting this pushed to > jdk8u-dev since both changes require re-generation of generated- > configure.sh > > Thanks, > Severin From kevin.walls at oracle.com Mon Jun 18 19:34:36 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 18 Jun 2018 20:34:36 +0100 Subject: [8u-dev] Request for approval for CR 8160748: Inconsistent types for ideal_reg Message-ID: <4b16d606-a31c-8684-122a-108c7b41228d@oracle.com> Hi, I'd like to request approval to backport from 10 to 8u: 8160748: Inconsistent types for ideal_reg JBS: https://bugs.openjdk.java.net/browse/JDK-8160748 Backporting this fixes a compile time error when testing a later compiler on Windows (e.g. VS2017). //10 changeset: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/d0f9cd0ff128 10 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023705.html Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8160748/webrev.00/ Review of 8u change on hotspot-compiler-dev: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-June/029394.html Thanks! Kevin From kevin.walls at oracle.com Mon Jun 18 20:11:16 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 18 Jun 2018 21:11:16 +0100 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: <20180618164544.GB3250@vimes> References: <20180618164544.GB3250@vimes> Message-ID: <7519930b-8524-be33-f512-3ec222969dec@oracle.com> Hi -- I've been doing various 8u build changes recently -- would you like me to push this, with the regenerated autogen-generated file? On 18/06/2018 17:45, Rob McKenna wrote: > Approved. Please work with the appropriate team to find a sponsor. > > -Rob > > On 18/06/18 16:36, Severin Gehwolf wrote: >> Hi, >> >> Please approve these two backports to JDK 8u-dev which are already in >> JDK 9 and better. >> >> 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ >> hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch >> >> 8148351: Only display resolved symlink for compiler, do not change path >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ >> hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch >> >> Bug 8031668 is a dependency for 8148351 which actually fixes the >> wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is >> the same as for JDK 9, modulo some context changes. After the JDK 8 >> patch of 8031668, the JDK 9 patch of 8148351 imports as is. >> >> The issue at hand is that one cannot build the JDK 8 tree with certain >> compiler wrappers such as cscppc. It currently fails with: >> >> configure: Using default toolchain gcc (GNU Compiler Collection) >> checking for gcc... /usr/lib64/cscppc/gcc >> checking resolved symbolic links for CC... /usr/bin/cscppc >> checking if CC is disguised ccache... no, keeping CC >> configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler. >> configure: The result from running with --version was: "" >> configure: error: A gcc compiler is required. Try setting --with-tools-dir. >> configure exiting with result code 1 >> >> After both backports configure with a wrapped GCC succeeds. >> >> Please note that I'd need an Oracle sponsor for getting this pushed to >> jdk8u-dev since both changes require re-generation of generated- >> configure.sh >> >> Thanks, >> Severin From rob.mckenna at oracle.com Mon Jun 18 21:04:17 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 18 Jun 2018 22:04:17 +0100 Subject: [8u-dev] Request for approval for CR 8160748: Inconsistent types for ideal_reg In-Reply-To: <4b16d606-a31c-8684-122a-108c7b41228d@oracle.com> References: <4b16d606-a31c-8684-122a-108c7b41228d@oracle.com> Message-ID: <20180618210417.GC3250@vimes> Approved. Please add a suitable noreg label to the bug. -Rob On 18/06/18 20:34, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 10 to 8u: > > 8160748: Inconsistent types for ideal_reg > JBS: https://bugs.openjdk.java.net/browse/JDK-8160748 > > Backporting this fixes a compile time error when testing a later > compiler on Windows (e.g. VS2017). > //10 changeset: > http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/d0f9cd0ff128 > > 10 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-July/023705.html > > Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8160748/webrev.00/ > > Review of 8u change on hotspot-compiler-dev: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-June/029394.html > > Thanks! > Kevin > From kevin.walls at oracle.com Tue Jun 19 06:10:46 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 19 Jun 2018 07:10:46 +0100 Subject: [8u-dev] Request for approval for CR 8150688: Fix os_windows siglabel In-Reply-To: <20180615125707.GA3481@vimes> References: <20180615125707.GA3481@vimes> Message-ID: <4df467bc-b51f-3fc6-1297-08acfde1366f@oracle.com> Hi - Actually I had missed a comma change in the ia64 case. hotspot runtime dev review of 8u change: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-June/028681.html Thanks Kevin On 15/06/2018 13:57, Rob McKenna wrote: > The changes will need a codereview. > > -Rob > > On 15/06/18 10:16, Kevin Walls wrote: >> Hi, >> >> I'd like to request approval to backport from 9 to 8u: >> >> 8150688: Fix os_windows siglabel >> JBS: https://bugs.openjdk.java.net/browse/JDK-8150688 >> >> 9 changeset: >> URL:?? http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/80706cc25494 >> >> 9 review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018236.html >> >> Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8150688/webrev.00/ >> >> This is a pretty clean backport. but didn't import automatically: in 8u >> there is no "os::get_signal_number()" and some of the def_excpt... lines >> didn't apply automatically, but they are the same change. >> >> This removes some errors when varying the windows compiler in use, still >> builds and tests OK on current standard VS compiler. >> >> Thanks! >> Kevin >> From sgehwolf at redhat.com Tue Jun 19 06:23:17 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 19 Jun 2018 08:23:17 +0200 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: <7519930b-8524-be33-f512-3ec222969dec@oracle.com> References: <20180618164544.GB3250@vimes> <7519930b-8524-be33-f512-3ec222969dec@oracle.com> Message-ID: <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com> Hi Kevin, On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote: > Hi -- I've been doing various 8u build changes recently -- would you > like me to push this, with the regenerated autogen-generated file? It would be very much appreciated! Thanks, Severin > > > On 18/06/2018 17:45, Rob McKenna wrote: > > Approved. Please work with the appropriate team to find a sponsor. > > > > -Rob > > > > On 18/06/18 16:36, Severin Gehwolf wrote: > > > Hi, > > > > > > Please approve these two backports to JDK 8u-dev which are already in > > > JDK 9 and better. > > > > > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch > > > > > > 8148351: Only display resolved symlink for compiler, do not change path > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch > > > > > > Bug 8031668 is a dependency for 8148351 which actually fixes the > > > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is > > > the same as for JDK 9, modulo some context changes. After the JDK 8 > > > patch of 8031668, the JDK 9 patch of 8148351 imports as is. > > > > > > The issue at hand is that one cannot build the JDK 8 tree with certain > > > compiler wrappers such as cscppc. It currently fails with: > > > > > > configure: Using default toolchain gcc (GNU Compiler Collection) > > > checking for gcc... /usr/lib64/cscppc/gcc > > > checking resolved symbolic links for CC... /usr/bin/cscppc > > > checking if CC is disguised ccache... no, keeping CC > > > configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler. > > > configure: The result from running with --version was: "" > > > configure: error: A gcc compiler is required. Try setting --with-tools-dir. > > > configure exiting with result code 1 > > > > > > After both backports configure with a wrapped GCC succeeds. > > > > > > Please note that I'd need an Oracle sponsor for getting this pushed to > > > jdk8u-dev since both changes require re-generation of generated- > > > configure.sh > > > > > > Thanks, > > > Severin > > From kevin.walls at oracle.com Tue Jun 19 12:51:43 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 19 Jun 2018 13:51:43 +0100 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com> References: <20180618164544.GB3250@vimes> <7519930b-8524-be33-f512-3ec222969dec@oracle.com> <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com> Message-ID: <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com> Hi Severin - Ah, actually there's a conflict with the way we build, where we use ccache in the path, and it no longer likes it with this change: Our build system jprt fails, with the configure output: ... checking flags for boot jdk java command for small workloads... -XX:+UseSerialGC -Xms32M -Xmx512M configure: Using default toolchain gcc (GNU Compiler Collection) checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc checking resolved symbolic links for CC... /opt/jprt/products/P1/ccache2.4/bin/ccache configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic link to ccache. This is not supported. configure: Please use --enable-ccache instead of providing a wrapped compiler. configure exiting with result code 1 It's the second change, 8148351, which triggers this failure, as it removes lines at 549 onwards which previously tried to handle the ccache in the path case. Yes, in 9 onward we abort the build if ccache is found at the end of a link, we haven't done that in jdk 8 before... Would retaining the ccache handling code in toolchain.m4 still give you the behaviour you want from doing the backport? Thanks Kevin On 19/06/2018 07:23, Severin Gehwolf wrote: > Hi Kevin, > > On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote: >> Hi -- I've been doing various 8u build changes recently -- would you >> like me to push this, with the regenerated autogen-generated file? > It would be very much appreciated! > > Thanks, > Severin > >> >> On 18/06/2018 17:45, Rob McKenna wrote: >>> Approved. Please work with the appropriate team to find a sponsor. >>> >>> -Rob >>> >>> On 18/06/18 16:36, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Please approve these two backports to JDK 8u-dev which are already in >>>> JDK 9 and better. >>>> >>>> 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links >>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ >>>> hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch >>>> >>>> 8148351: Only display resolved symlink for compiler, do not change path >>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ >>>> hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch >>>> >>>> Bug 8031668 is a dependency for 8148351 which actually fixes the >>>> wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is >>>> the same as for JDK 9, modulo some context changes. After the JDK 8 >>>> patch of 8031668, the JDK 9 patch of 8148351 imports as is. >>>> >>>> The issue at hand is that one cannot build the JDK 8 tree with certain >>>> compiler wrappers such as cscppc. It currently fails with: >>>> >>>> configure: Using default toolchain gcc (GNU Compiler Collection) >>>> checking for gcc... /usr/lib64/cscppc/gcc >>>> checking resolved symbolic links for CC... /usr/bin/cscppc >>>> checking if CC is disguised ccache... no, keeping CC >>>> configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler. >>>> configure: The result from running with --version was: "" >>>> configure: error: A gcc compiler is required. Try setting --with-tools-dir. >>>> configure exiting with result code 1 >>>> >>>> After both backports configure with a wrapped GCC succeeds. >>>> >>>> Please note that I'd need an Oracle sponsor for getting this pushed to >>>> jdk8u-dev since both changes require re-generation of generated- >>>> configure.sh >>>> >>>> Thanks, >>>> Severin >> From sgehwolf at redhat.com Tue Jun 19 13:30:17 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 19 Jun 2018 15:30:17 +0200 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com> References: <20180618164544.GB3250@vimes> <7519930b-8524-be33-f512-3ec222969dec@oracle.com> <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com> <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com> Message-ID: Hi Kevin, Thanks for your help! Adding in build-dev for additional input. On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote: > Hi Severin - > > Ah, actually there's a conflict with the way we build, where we use > ccache in the path, and it no longer likes it with this change: > > Our build system jprt fails, with the configure output: > ... > checking flags for boot jdk java command for small workloads... > -XX:+UseSerialGC -Xms32M -Xmx512M > configure: Using default toolchain gcc (GNU Compiler Collection) > checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc > checking resolved symbolic links for CC... > /opt/jprt/products/P1/ccache2.4/bin/ccache > configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic > link to ccache. This is not supported. > configure: Please use --enable-ccache instead of providing a wrapped > compiler. > configure exiting with result code 1 Erik, Magnus, how do you do this for your JDK 9+ builds? Is there a way to use "--enable-ccache" for JDK 8 builds? > It's the second change, 8148351, which triggers this failure, as it > removes lines at 549 onwards which previously tried to handle the ccache > in the path case. Right. It's 8148351 which we'd be interested in. > Yes, in 9 onward we abort the build if ccache is found at the end of a > link, we haven't done that in jdk 8 before... Would retaining the ccache > handling code in toolchain.m4 still give you the behaviour you want from > doing the backport? Thanks, Severin > Thanks > Kevin > > > > > > On 19/06/2018 07:23, Severin Gehwolf wrote: > > Hi Kevin, > > > > On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote: > > > Hi -- I've been doing various 8u build changes recently -- would you > > > like me to push this, with the regenerated autogen-generated file? > > > > It would be very much appreciated! > > > > Thanks, > > Severin > > > > > > > > On 18/06/2018 17:45, Rob McKenna wrote: > > > > Approved. Please work with the appropriate team to find a sponsor. > > > > > > > > -Rob > > > > > > > > On 18/06/18 16:36, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Please approve these two backports to JDK 8u-dev which are already in > > > > > JDK 9 and better. > > > > > > > > > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch > > > > > > > > > > 8148351: Only display resolved symlink for compiler, do not change path > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch > > > > > > > > > > Bug 8031668 is a dependency for 8148351 which actually fixes the > > > > > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is > > > > > the same as for JDK 9, modulo some context changes. After the JDK 8 > > > > > patch of 8031668, the JDK 9 patch of 8148351 imports as is. > > > > > > > > > > The issue at hand is that one cannot build the JDK 8 tree with certain > > > > > compiler wrappers such as cscppc. It currently fails with: > > > > > > > > > > configure: Using default toolchain gcc (GNU Compiler Collection) > > > > > checking for gcc... /usr/lib64/cscppc/gcc > > > > > checking resolved symbolic links for CC... /usr/bin/cscppc > > > > > checking if CC is disguised ccache... no, keeping CC > > > > > configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler. > > > > > configure: The result from running with --version was: "" > > > > > configure: error: A gcc compiler is required. Try setting --with-tools-dir. > > > > > configure exiting with result code 1 > > > > > > > > > > After both backports configure with a wrapped GCC succeeds. > > > > > > > > > > Please note that I'd need an Oracle sponsor for getting this pushed to > > > > > jdk8u-dev since both changes require re-generation of generated- > > > > > configure.sh > > > > > > > > > > Thanks, > > > > > Severin > > From rob.mckenna at oracle.com Tue Jun 19 14:02:38 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 19 Jun 2018 15:02:38 +0100 Subject: [8u-dev] Request for approval for CR 8150688: Fix os_windows siglabel In-Reply-To: <4df467bc-b51f-3fc6-1297-08acfde1366f@oracle.com> References: <20180615125707.GA3481@vimes> <4df467bc-b51f-3fc6-1297-08acfde1366f@oracle.com> Message-ID: <20180619140238.GA3336@vimes> Approved -Rob On 19/06/18 07:10, Kevin Walls wrote: > Hi - > > Actually I had missed a comma change in the ia64 case. > > hotspot runtime dev review of 8u change: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-June/028681.html > > Thanks > Kevin > > > On 15/06/2018 13:57, Rob McKenna wrote: > >The changes will need a codereview. > > > > -Rob > > > >On 15/06/18 10:16, Kevin Walls wrote: > >>Hi, > >> > >>I'd like to request approval to backport from 9 to 8u: > >> > >>8150688: Fix os_windows siglabel > >>JBS: https://bugs.openjdk.java.net/browse/JDK-8150688 > >> > >>9 changeset: > >>URL:?? http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/80706cc25494 > >> > >>9 review thread: > >>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018236.html > >> > >>Proposed 8u change: http://cr.openjdk.java.net/~kevinw/8150688/webrev.00/ > >> > >>This is a pretty clean backport. but didn't import automatically: in 8u > >>there is no "os::get_signal_number()" and some of the def_excpt... lines > >>didn't apply automatically, but they are the same change. > >> > >>This removes some errors when varying the windows compiler in use, still > >>builds and tests OK on current standard VS compiler. > >> > >>Thanks! > >>Kevin > >> > From erik.joelsson at oracle.com Tue Jun 19 14:06:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Jun 2018 07:06:50 -0700 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: References: <20180618164544.GB3250@vimes> <7519930b-8524-be33-f512-3ec222969dec@oracle.com> <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com> <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com> Message-ID: Hello, On 2018-06-19 06:30, Severin Gehwolf wrote: > Hi Kevin, > > Thanks for your help! Adding in build-dev for additional input. > > On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote: >> Hi Severin - >> >> Ah, actually there's a conflict with the way we build, where we use >> ccache in the path, and it no longer likes it with this change: >> >> Our build system jprt fails, with the configure output: >> ... >> checking flags for boot jdk java command for small workloads... >> -XX:+UseSerialGC -Xms32M -Xmx512M >> configure: Using default toolchain gcc (GNU Compiler Collection) >> checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc >> checking resolved symbolic links for CC... >> /opt/jprt/products/P1/ccache2.4/bin/ccache >> configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic >> link to ccache. This is not supported. >> configure: Please use --enable-ccache instead of providing a wrapped >> compiler. >> configure exiting with result code 1 > Erik, Magnus, how do you do this for your JDK 9+ builds? Is there a way > to use "--enable-ccache" for JDK 8 builds? We don't. The problem here is that the build machines we have for 8 have ccache installed as a gcc wrapper. This was done back in 7 with the intention of transparently improving build performance (but in reality it didn't). Because of this situation, we implemented a workaround for 8 where we explicitly don't accept ccache as gcc wrapper and look for gcc elsewhere instead. Our build machines for 9 do not have cache installed at all (it's still in the devkit, but not as a wrapper, and since we saw no benefit for our use case we don't use ccache anyway). The change being backported here removes the workaround that allows the build to function with the ccache wrapper on the system. I don't think that's a good idea for 8. We need to retain that workaround so the patch needs to be modified before going into 8u. Reproducing this issue locally should be pretty simple. Create a dummy script named ccache somewhere. Put a symlink named gcc, pointing to that ccache script first in your path. Then run configure. /Erik >> It's the second change, 8148351, which triggers this failure, as it >> removes lines at 549 onwards which previously tried to handle the ccache >> in the path case. > Right. It's 8148351 which we'd be interested in. > >> Yes, in 9 onward we abort the build if ccache is found at the end of a >> link, we haven't done that in jdk 8 before... Would retaining the ccache >> handling code in toolchain.m4 still give you the behaviour you want from >> doing the backport? > Thanks, > Severin > >> Thanks >> Kevin >> >> >> >> >> >> On 19/06/2018 07:23, Severin Gehwolf wrote: >>> Hi Kevin, >>> >>> On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote: >>>> Hi -- I've been doing various 8u build changes recently -- would you >>>> like me to push this, with the regenerated autogen-generated file? >>> It would be very much appreciated! >>> >>> Thanks, >>> Severin >>> >>>> On 18/06/2018 17:45, Rob McKenna wrote: >>>>> Approved. Please work with the appropriate team to find a sponsor. >>>>> >>>>> -Rob >>>>> >>>>> On 18/06/18 16:36, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Please approve these two backports to JDK 8u-dev which are already in >>>>>> JDK 9 and better. >>>>>> >>>>>> 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links >>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ >>>>>> hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch >>>>>> >>>>>> 8148351: Only display resolved symlink for compiler, do not change path >>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ >>>>>> hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch >>>>>> >>>>>> Bug 8031668 is a dependency for 8148351 which actually fixes the >>>>>> wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is >>>>>> the same as for JDK 9, modulo some context changes. After the JDK 8 >>>>>> patch of 8031668, the JDK 9 patch of 8148351 imports as is. >>>>>> >>>>>> The issue at hand is that one cannot build the JDK 8 tree with certain >>>>>> compiler wrappers such as cscppc. It currently fails with: >>>>>> >>>>>> configure: Using default toolchain gcc (GNU Compiler Collection) >>>>>> checking for gcc... /usr/lib64/cscppc/gcc >>>>>> checking resolved symbolic links for CC... /usr/bin/cscppc >>>>>> checking if CC is disguised ccache... no, keeping CC >>>>>> configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler. >>>>>> configure: The result from running with --version was: "" >>>>>> configure: error: A gcc compiler is required. Try setting --with-tools-dir. >>>>>> configure exiting with result code 1 >>>>>> >>>>>> After both backports configure with a wrapped GCC succeeds. >>>>>> >>>>>> Please note that I'd need an Oracle sponsor for getting this pushed to >>>>>> jdk8u-dev since both changes require re-generation of generated- >>>>>> configure.sh >>>>>> >>>>>> Thanks, >>>>>> Severin >> From sgehwolf at redhat.com Tue Jun 19 14:17:08 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 19 Jun 2018 16:17:08 +0200 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: References: <20180618164544.GB3250@vimes> <7519930b-8524-be33-f512-3ec222969dec@oracle.com> <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com> <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com> Message-ID: Hi Erik, On Tue, 2018-06-19 at 07:06 -0700, Erik Joelsson wrote: > Hello, > > On 2018-06-19 06:30, Severin Gehwolf wrote: > > Hi Kevin, > > > > Thanks for your help! Adding in build-dev for additional input. > > > > On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote: > > > Hi Severin - > > > > > > Ah, actually there's a conflict with the way we build, where we use > > > ccache in the path, and it no longer likes it with this change: > > > > > > Our build system jprt fails, with the configure output: > > > ... > > > checking flags for boot jdk java command for small workloads... > > > -XX:+UseSerialGC -Xms32M -Xmx512M > > > configure: Using default toolchain gcc (GNU Compiler Collection) > > > checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc > > > checking resolved symbolic links for CC... > > > /opt/jprt/products/P1/ccache2.4/bin/ccache > > > configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic > > > link to ccache. This is not supported. > > > configure: Please use --enable-ccache instead of providing a wrapped > > > compiler. > > > configure exiting with result code 1 > > > > Erik, Magnus, how do you do this for your JDK 9+ builds? Is there a way > > to use "--enable-ccache" for JDK 8 builds? > > We don't. The problem here is that the build machines we have for 8 have > ccache installed as a gcc wrapper. This was done back in 7 with the > intention of transparently improving build performance (but in reality > it didn't). Because of this situation, we implemented a workaround for 8 > where we explicitly don't accept ccache as gcc wrapper and look for gcc > elsewhere instead. Our build machines for 9 do not have cache installed > at all (it's still in the devkit, but not as a wrapper, and since we saw > no benefit for our use case we don't use ccache anyway). > > The change being backported here removes the workaround that allows the > build to function with the ccache wrapper on the system. I don't think > that's a good idea for 8. We need to retain that workaround so the patch > needs to be modified before going into 8u. Sigh. Back to the drawing board ;-) > Reproducing this issue locally should be pretty simple. Create a dummy > script named ccache somewhere. Put a symlink named gcc, pointing to that > ccache script first in your path. Then run configure. Thanks, yes. I've got that reproduced. Cheers, Severin > /Erik > > > It's the second change, 8148351, which triggers this failure, as it > > > removes lines at 549 onwards which previously tried to handle the ccache > > > in the path case. > > > > Right. It's 8148351 which we'd be interested in. > > > > > Yes, in 9 onward we abort the build if ccache is found at the end of a > > > link, we haven't done that in jdk 8 before... Would retaining the ccache > > > handling code in toolchain.m4 still give you the behaviour you want from > > > doing the backport? > > > > Thanks, > > Severin > > > > > Thanks > > > Kevin > > > > > > > > > > > > > > > > > > On 19/06/2018 07:23, Severin Gehwolf wrote: > > > > Hi Kevin, > > > > > > > > On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote: > > > > > Hi -- I've been doing various 8u build changes recently -- would you > > > > > like me to push this, with the regenerated autogen-generated file? > > > > > > > > It would be very much appreciated! > > > > > > > > Thanks, > > > > Severin > > > > > > > > > On 18/06/2018 17:45, Rob McKenna wrote: > > > > > > Approved. Please work with the appropriate team to find a sponsor. > > > > > > > > > > > > -Rob > > > > > > > > > > > > On 18/06/18 16:36, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Please approve these two backports to JDK 8u-dev which are already in > > > > > > > JDK 9 and better. > > > > > > > > > > > > > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links > > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ > > > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch > > > > > > > > > > > > > > 8148351: Only display resolved symlink for compiler, do not change path > > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ > > > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch > > > > > > > > > > > > > > Bug 8031668 is a dependency for 8148351 which actually fixes the > > > > > > > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is > > > > > > > the same as for JDK 9, modulo some context changes. After the JDK 8 > > > > > > > patch of 8031668, the JDK 9 patch of 8148351 imports as is. > > > > > > > > > > > > > > The issue at hand is that one cannot build the JDK 8 tree with certain > > > > > > > compiler wrappers such as cscppc. It currently fails with: > > > > > > > > > > > > > > configure: Using default toolchain gcc (GNU Compiler Collection) > > > > > > > checking for gcc... /usr/lib64/cscppc/gcc > > > > > > > checking resolved symbolic links for CC... /usr/bin/cscppc > > > > > > > checking if CC is disguised ccache... no, keeping CC > > > > > > > configure: The C compiler (located as /usr/bin/cscppc) does not seem to be the required gcc compiler. > > > > > > > configure: The result from running with --version was: "" > > > > > > > configure: error: A gcc compiler is required. Try setting --with-tools-dir. > > > > > > > configure exiting with result code 1 > > > > > > > > > > > > > > After both backports configure with a wrapped GCC succeeds. > > > > > > > > > > > > > > Please note that I'd need an Oracle sponsor for getting this pushed to > > > > > > > jdk8u-dev since both changes require re-generation of generated- > > > > > > > configure.sh > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > From gnu.andrew at redhat.com Wed Jun 20 05:47:57 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Jun 2018 06:47:57 +0100 Subject: [8u] Request for Approval for JDK-8008321: compile.cpp verify_graph_edges uses bool as int Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8008321 Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8008321/webrev.01/ Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-June/014851.html Fix applies as is to OpenJDK 8. Debug build is failing here without this fix: /usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0/x86_64-pc-linux-gnu-g++ -DLINUX -D_GNU_SOURCE -DIA32 -DASSERT -I. -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/prims -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/precompiled -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/cpu/x86/vm -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/os_cpu/linux_x86/vm -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/os/linux/vm -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.71-b00\"" -DHOTSPOT_BUILD_TARGET="\"debug\"" -DHOTSPOT_BUILD_USER="\"andrew\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m32 -march=i586 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -D_NMT_NOINLINE_ -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -O2 -pipe -march=core2 -ggdb -mno-tls-direct-seg-refs -Werror=implicit-function-declaration -fstack-protector-strong -std=gnu++98 -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/compiledICHolder.o.d -fpch-deps -o compiledICHolder.o /home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/oops/compiledICHolder.cpp /home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/opto/compile.cpp: In member function 'void Compile::verify_graph_edges(bool)': /home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/opto/compile.cpp:3494:25: error: use of an operand of type 'bool' in 'operator++' is deprecated [-Werror=deprecated] if (dead_nodes++ == 0) Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Wed Jun 20 09:48:16 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 20 Jun 2018 11:48:16 +0200 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com> References: <20180618164544.GB3250@vimes> <7519930b-8524-be33-f512-3ec222969dec@oracle.com> <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com> <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com> Message-ID: <3ffc325823b9c6561eacd7f8ba91faad551acb47.camel@redhat.com> Hi Rob, Due to this conflict we've decided to change the JDK 8 patch for 8148351. It's been reviewed by Erik Joelsson from the build group and it does not seem to have the conflict the original patch had. Is it still OK to push it? Bug: https://bugs.openjdk.java.net/browse/JDK-8148351 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.02/ Review of the above: http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022447.html hg-export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch Thanks, Severin On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote: > Hi Severin - > > Ah, actually there's a conflict with the way we build, where we use > ccache in the path, and it no longer likes it with this change: > > Our build system jprt fails, with the configure output: > ... > checking flags for boot jdk java command for small workloads... > -XX:+UseSerialGC -Xms32M -Xmx512M > configure: Using default toolchain gcc (GNU Compiler Collection) > checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc > checking resolved symbolic links for CC... > /opt/jprt/products/P1/ccache2.4/bin/ccache > configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a > symbolic > link to ccache. This is not supported. > configure: Please use --enable-ccache instead of providing a wrapped > compiler. > configure exiting with result code 1 > > It's the second change, 8148351, which triggers this failure, as it > removes lines at 549 onwards which previously tried to handle the > ccache > in the path case. > > Yes, in 9 onward we abort the build if ccache is found at the end of > a > link, we haven't done that in jdk 8 before... Would retaining the > ccache > handling code in toolchain.m4 still give you the behaviour you want > from > doing the backport? > > Thanks > Kevin > > > > > > On 19/06/2018 07:23, Severin Gehwolf wrote: > > Hi Kevin, > > > > On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote: > > > Hi -- I've been doing various 8u build changes recently -- would > > > you > > > like me to push this, with the regenerated autogen-generated > > > file? > > > > It would be very much appreciated! > > > > Thanks, > > Severin > > > > > > > > On 18/06/2018 17:45, Rob McKenna wrote: > > > > Approved. Please work with the appropriate team to find a > > > > sponsor. > > > > > > > > -Rob > > > > > > > > On 18/06/18 16:36, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Please approve these two backports to JDK 8u-dev which are > > > > > already in > > > > > JDK 9 and better. > > > > > > > > > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves > > > > > symbolic links > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031 > > > > > 668/webrev.01/ > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8 > > > > > 031668/JDK-8031668.jdk8.export.patch > > > > > > > > > > 8148351: Only display resolved symlink for compiler, do not > > > > > change path > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148 > > > > > 351/webrev.01/ > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8 > > > > > 148351/JDK-8148351.jdk8.export.patch > > > > > > > > > > Bug 8031668 is a dependency for 8148351 which actually fixes > > > > > the > > > > > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of > > > > > 8031668 is > > > > > the same as for JDK 9, modulo some context changes. After the > > > > > JDK 8 > > > > > patch of 8031668, the JDK 9 patch of 8148351 imports as is. > > > > > > > > > > The issue at hand is that one cannot build the JDK 8 tree > > > > > with certain > > > > > compiler wrappers such as cscppc. It currently fails with: > > > > > > > > > > configure: Using default toolchain gcc (GNU Compiler > > > > > Collection) > > > > > checking for gcc... /usr/lib64/cscppc/gcc > > > > > checking resolved symbolic links for CC... /usr/bin/cscppc > > > > > checking if CC is disguised ccache... no, keeping CC > > > > > configure: The C compiler (located as /usr/bin/cscppc) does > > > > > not seem to be the required gcc compiler. > > > > > configure: The result from running with --version was: "" > > > > > configure: error: A gcc compiler is required. Try setting -- > > > > > with-tools-dir. > > > > > configure exiting with result code 1 > > > > > > > > > > After both backports configure with a wrapped GCC succeeds. > > > > > > > > > > Please note that I'd need an Oracle sponsor for getting this > > > > > pushed to > > > > > jdk8u-dev since both changes require re-generation of > > > > > generated- > > > > > configure.sh > > > > > > > > > > Thanks, > > > > > Severin > > From david.buck at oracle.com Wed Jun 20 10:24:47 2018 From: david.buck at oracle.com (David Buck) Date: Wed, 20 Jun 2018 19:24:47 +0900 Subject: [8u] Request for Approval for JDK-8008321: compile.cpp verify_graph_edges uses bool as int In-Reply-To: References: Message-ID: approved for backport to 8u-dev Cheers, -Buck On 2018/06/20 14:47, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8008321 > Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8008321/webrev.01/ > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-June/014851.html > > Fix applies as is to OpenJDK 8. > > Debug build is failing here without this fix: > > /usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0/x86_64-pc-linux-gnu-g++ -DLINUX > -D_GNU_SOURCE -DIA32 -DASSERT -I. > -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/prims > -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm > -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/precompiled > -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/cpu/x86/vm > -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/os_cpu/linux_x86/vm > -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/os/linux/vm > -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/os/posix/vm > -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.71-b00\"" > -DHOTSPOT_BUILD_TARGET="\"debug\"" -DHOTSPOT_BUILD_USER="\"andrew\"" > -DHOTSPOT_LIB_ARCH=\"i386\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" > -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_32 > -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_32 > -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fno-rtti > -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m32 > -march=i586 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer > -D_NMT_NOINLINE_ -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith > -Wsign-compare -Wundef -Wunused-function -Wunused-value -O2 -pipe > -march=core2 -ggdb -mno-tls-direct-seg-refs > -Werror=implicit-function-declaration -fstack-protector-strong > -std=gnu++98 -DDTRACE_ENABLED -c -MMD -MP -MF > ../generated/dependencies/compiledICHolder.o.d -fpch-deps -o > compiledICHolder.o > /home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/oops/compiledICHolder.cpp > > /home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/opto/compile.cpp: > In member function 'void Compile::verify_graph_edges(bool)': > /home/andrew/projects/openjdk/upstream/jdk8u-dev/hotspot/src/share/vm/opto/compile.cpp:3494:25: > error: use of an operand of type 'bool' in 'operator++' is deprecated > [-Werror=deprecated] > if (dead_nodes++ == 0) > > Thanks, > From rob.mckenna at oracle.com Wed Jun 20 13:50:02 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 20 Jun 2018 14:50:02 +0100 Subject: RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path In-Reply-To: <3ffc325823b9c6561eacd7f8ba91faad551acb47.camel@redhat.com> References: <20180618164544.GB3250@vimes> <7519930b-8524-be33-f512-3ec222969dec@oracle.com> <48684b1cfbdb6d6f266865cdb7130553a80e115c.camel@redhat.com> <72055bad-3908-d4f6-349f-8dd62965b731@oracle.com> <3ffc325823b9c6561eacd7f8ba91faad551acb47.camel@redhat.com> Message-ID: <20180620135002.GB5040@vimes> Yep - approved. Thanks for addressing the problem. -Rob On 20/06/18 11:48, Severin Gehwolf wrote: > Hi Rob, > > Due to this conflict we've decided to change the JDK 8 patch for > 8148351. It's been reviewed by Erik Joelsson from the build group and > it does not seem to have the conflict the original patch had. Is it > still OK to push it? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148351 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.02/ > Review of the above: > http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022447.html > hg-export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch > > Thanks, > Severin > > On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote: > > Hi Severin - > > > > Ah, actually there's a conflict with the way we build, where we use > > ccache in the path, and it no longer likes it with this change: > > > > Our build system jprt fails, with the configure output: > > ... > > checking flags for boot jdk java command for small workloads... > > -XX:+UseSerialGC -Xms32M -Xmx512M > > configure: Using default toolchain gcc (GNU Compiler Collection) > > checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc > > checking resolved symbolic links for CC... > > /opt/jprt/products/P1/ccache2.4/bin/ccache > > configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a > > symbolic > > link to ccache. This is not supported. > > configure: Please use --enable-ccache instead of providing a wrapped > > compiler. > > configure exiting with result code 1 > > > > It's the second change, 8148351, which triggers this failure, as it > > removes lines at 549 onwards which previously tried to handle the > > ccache > > in the path case. > > > > Yes, in 9 onward we abort the build if ccache is found at the end of > > a > > link, we haven't done that in jdk 8 before... Would retaining the > > ccache > > handling code in toolchain.m4 still give you the behaviour you want > > from > > doing the backport? > > > > Thanks > > Kevin > > > > > > > > > > > > On 19/06/2018 07:23, Severin Gehwolf wrote: > > > Hi Kevin, > > > > > > On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote: > > > > Hi -- I've been doing various 8u build changes recently -- would > > > > you > > > > like me to push this, with the regenerated autogen-generated > > > > file? > > > > > > It would be very much appreciated! > > > > > > Thanks, > > > Severin > > > > > > > > > > > On 18/06/2018 17:45, Rob McKenna wrote: > > > > > Approved. Please work with the appropriate team to find a > > > > > sponsor. > > > > > > > > > > -Rob > > > > > > > > > > On 18/06/18 16:36, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > Please approve these two backports to JDK 8u-dev which are > > > > > > already in > > > > > > JDK 9 and better. > > > > > > > > > > > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves > > > > > > symbolic links > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031 > > > > > > 668/webrev.01/ > > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8 > > > > > > 031668/JDK-8031668.jdk8.export.patch > > > > > > > > > > > > 8148351: Only display resolved symlink for compiler, do not > > > > > > change path > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148 > > > > > > 351/webrev.01/ > > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8 > > > > > > 148351/JDK-8148351.jdk8.export.patch > > > > > > > > > > > > Bug 8031668 is a dependency for 8148351 which actually fixes > > > > > > the > > > > > > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of > > > > > > 8031668 is > > > > > > the same as for JDK 9, modulo some context changes. After the > > > > > > JDK 8 > > > > > > patch of 8031668, the JDK 9 patch of 8148351 imports as is. > > > > > > > > > > > > The issue at hand is that one cannot build the JDK 8 tree > > > > > > with certain > > > > > > compiler wrappers such as cscppc. It currently fails with: > > > > > > > > > > > > configure: Using default toolchain gcc (GNU Compiler > > > > > > Collection) > > > > > > checking for gcc... /usr/lib64/cscppc/gcc > > > > > > checking resolved symbolic links for CC... /usr/bin/cscppc > > > > > > checking if CC is disguised ccache... no, keeping CC > > > > > > configure: The C compiler (located as /usr/bin/cscppc) does > > > > > > not seem to be the required gcc compiler. > > > > > > configure: The result from running with --version was: "" > > > > > > configure: error: A gcc compiler is required. Try setting -- > > > > > > with-tools-dir. > > > > > > configure exiting with result code 1 > > > > > > > > > > > > After both backports configure with a wrapped GCC succeeds. > > > > > > > > > > > > Please note that I'd need an Oracle sponsor for getting this > > > > > > pushed to > > > > > > jdk8u-dev since both changes require re-generation of > > > > > > generated- > > > > > > configure.sh > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > From gnu.andrew at redhat.com Wed Jun 20 16:55:02 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Jun 2018 17:55:02 +0100 Subject: [8u] Request for Approval for JDK-8008321: compile.cpp verify_graph_edges uses bool as int In-Reply-To: References: Message-ID: On 20 June 2018 at 11:24, David Buck wrote: > approved for backport to 8u-dev > > Cheers, > -Buck > Thanks. Pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c96534cd81fe -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Jun 21 03:56:43 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 21 Jun 2018 04:56:43 +0100 Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated Message-ID: [CCing hotspot list for review] Bug: https://bugs.openjdk.java.net/browse/JDK-8179887 Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8179887/webrev.01/ Review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031746.html Patch is basically the same as for OpenJDK 11, except we don't have to revert 8187667, which isn't present in OpenJDK 8. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From kevin.walls at oracle.com Thu Jun 21 11:31:54 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 21 Jun 2018 12:31:54 +0100 Subject: [8u-dev] Request for Review and Approval: 8198304: VS2017 (C4838, C4312) Various conversion issues with gtest tests Message-ID: <2026243f-9055-47c8-ee74-509c51bc91d8@oracle.com> Hi, I'd like to get review/approval for an 8u (partial) backport of: 8198304: VS2017 (C4838, C4312) Various conversion issues with gtest tests jbs: https://bugs.openjdk.java.net/browse/JDK-8198304 It's a simple backport, a cast to avoid a compile error with later compilers, and introduces a #define as the same thing is repeated. Only some of the changes are relevant for 8u, and in 11 they are "gtests" but in jdk8u they are in the regular source, #ifndef PRODUCT jdk 11 diff: http://hg.openjdk.java.net/jdk/jdk/rev/ba9da6aaae36 11 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030323.html 8u diff: bash-4.2$ hg status M src/share/vm/memory/guardedMemory.cpp bash-4.2$ hg diff diff -r c96534cd81fe src/share/vm/memory/guardedMemory.cpp --- a/src/share/vm/memory/guardedMemory.cpp???? Fri Jun 20 08:14:30 2014 +0200 +++ b/src/share/vm/memory/guardedMemory.cpp???? Thu Jun 21 03:51:32 2018 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2018, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -84,6 +84,8 @@ ?#ifndef PRODUCT +#define GEN_PURPOSE_TAG ((void *) ((uintptr_t)0xf000f000)) + ?static void guarded_memory_test_check(void* p, size_t sz, void* tag) { ?? assert(p != NULL, "NULL pointer given to check"); ?? u_char* c = (u_char*) p; @@ -100,12 +102,12 @@ ?? assert(total_sz > 1 && total_sz >= (sizeof(GuardHeader) + 1 + sizeof(Guard)), "Unexpected size"); ?? u_char* basep = (u_char*) os::malloc(total_sz, mtInternal); -? GuardedMemory guarded(basep, 1, (void*)0xf000f000); +? GuardedMemory guarded(basep, 1, GEN_PURPOSE_TAG); ?? assert(*basep == badResourceValue, "Expected guard in the form of badResourceValue"); ?? u_char* userp = guarded.get_user_ptr(); ?? assert(*userp == uninitBlockPad, "Expected uninitialized data in the form of uninitBlockPad"); -? guarded_memory_test_check(userp, 1, (void*)0xf000f000); +? guarded_memory_test_check(userp, 1, GEN_PURPOSE_TAG); ?? void* freep = guarded.release_for_freeing(); ?? assert((u_char*)freep == basep, "Expected the same pointer guard was "); bash-4.2$ Thanks Kevin From sean.coffey at oracle.com Fri Jun 22 08:50:42 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 22 Jun 2018 09:50:42 +0100 Subject: [8u-dev] Request for Review and Approval: 8198304: VS2017 (C4838, C4312) Various conversion issues with gtest tests In-Reply-To: <2026243f-9055-47c8-ee74-509c51bc91d8@oracle.com> References: <2026243f-9055-47c8-ee74-509c51bc91d8@oracle.com> Message-ID: <3e236df1-7d04-02f9-7a73-e37f436e16f5@oracle.com> Looks fine Kevin. Approved for jdk8u-dev. regards, Sean. On 21/06/2018 12:31, Kevin Walls wrote: > Hi, > > I'd like to get review/approval for an 8u (partial) backport of: > > 8198304: VS2017 (C4838, C4312) Various conversion issues with gtest tests > jbs: https://bugs.openjdk.java.net/browse/JDK-8198304 > > It's a simple backport, a cast to avoid a compile error with later > compilers, and introduces a #define as the same thing is repeated. > > Only some of the changes are relevant for 8u, and in 11 they are > "gtests" but in jdk8u they are in the regular source, #ifndef PRODUCT > > jdk 11 diff: > http://hg.openjdk.java.net/jdk/jdk/rev/ba9da6aaae36 > > 11 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030323.html > > > 8u diff: > > bash-4.2$ hg status > M src/share/vm/memory/guardedMemory.cpp > bash-4.2$ hg diff > diff -r c96534cd81fe src/share/vm/memory/guardedMemory.cpp > --- a/src/share/vm/memory/guardedMemory.cpp???? Fri Jun 20 08:14:30 > 2014 +0200 > +++ b/src/share/vm/memory/guardedMemory.cpp???? Thu Jun 21 03:51:32 > 2018 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2014, 2018, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -84,6 +84,8 @@ > > ?#ifndef PRODUCT > > +#define GEN_PURPOSE_TAG ((void *) ((uintptr_t)0xf000f000)) > + > ?static void guarded_memory_test_check(void* p, size_t sz, void* tag) { > ?? assert(p != NULL, "NULL pointer given to check"); > ?? u_char* c = (u_char*) p; > @@ -100,12 +102,12 @@ > ?? assert(total_sz > 1 && total_sz >= (sizeof(GuardHeader) + 1 + > sizeof(Guard)), "Unexpected size"); > ?? u_char* basep = (u_char*) os::malloc(total_sz, mtInternal); > > -? GuardedMemory guarded(basep, 1, (void*)0xf000f000); > +? GuardedMemory guarded(basep, 1, GEN_PURPOSE_TAG); > > ?? assert(*basep == badResourceValue, "Expected guard in the form of > badResourceValue"); > ?? u_char* userp = guarded.get_user_ptr(); > ?? assert(*userp == uninitBlockPad, "Expected uninitialized data in > the form of uninitBlockPad"); > -? guarded_memory_test_check(userp, 1, (void*)0xf000f000); > +? guarded_memory_test_check(userp, 1, GEN_PURPOSE_TAG); > > ?? void* freep = guarded.release_for_freeing(); > ?? assert((u_char*)freep == basep, "Expected the same pointer guard > was "); > bash-4.2$ > > > > Thanks > Kevin > From kevin.walls at oracle.com Fri Jun 22 08:53:10 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 22 Jun 2018 09:53:10 +0100 Subject: [8u-dev] Request for Review and Approval: 8198304: VS2017 (C4838, C4312) Various conversion issues with gtest tests In-Reply-To: <3e236df1-7d04-02f9-7a73-e37f436e16f5@oracle.com> References: <2026243f-9055-47c8-ee74-509c51bc91d8@oracle.com> <3e236df1-7d04-02f9-7a73-e37f436e16f5@oracle.com> Message-ID: Thanks! On 22/06/2018 09:50, Se?n Coffey wrote: > Looks fine Kevin. Approved for jdk8u-dev. > > regards, > Sean. > > > On 21/06/2018 12:31, Kevin Walls wrote: >> Hi, >> >> I'd like to get review/approval for an 8u (partial) backport of: >> >> 8198304: VS2017 (C4838, C4312) Various conversion issues with gtest >> tests >> jbs: https://bugs.openjdk.java.net/browse/JDK-8198304 >> >> It's a simple backport, a cast to avoid a compile error with later >> compilers, and introduces a #define as the same thing is repeated. >> >> Only some of the changes are relevant for 8u, and in 11 they are >> "gtests" but in jdk8u they are in the regular source, #ifndef PRODUCT >> >> jdk 11 diff: >> http://hg.openjdk.java.net/jdk/jdk/rev/ba9da6aaae36 >> >> 11 review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030323.html >> >> >> 8u diff: >> >> bash-4.2$ hg status >> M src/share/vm/memory/guardedMemory.cpp >> bash-4.2$ hg diff >> diff -r c96534cd81fe src/share/vm/memory/guardedMemory.cpp >> --- a/src/share/vm/memory/guardedMemory.cpp???? Fri Jun 20 08:14:30 >> 2014 +0200 >> +++ b/src/share/vm/memory/guardedMemory.cpp???? Thu Jun 21 03:51:32 >> 2018 -0700 >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2014, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2014, 2018, Oracle and/or its affiliates. All >> rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -84,6 +84,8 @@ >> >> ?#ifndef PRODUCT >> >> +#define GEN_PURPOSE_TAG ((void *) ((uintptr_t)0xf000f000)) >> + >> ?static void guarded_memory_test_check(void* p, size_t sz, void* tag) { >> ?? assert(p != NULL, "NULL pointer given to check"); >> ?? u_char* c = (u_char*) p; >> @@ -100,12 +102,12 @@ >> ?? assert(total_sz > 1 && total_sz >= (sizeof(GuardHeader) + 1 + >> sizeof(Guard)), "Unexpected size"); >> ?? u_char* basep = (u_char*) os::malloc(total_sz, mtInternal); >> >> -? GuardedMemory guarded(basep, 1, (void*)0xf000f000); >> +? GuardedMemory guarded(basep, 1, GEN_PURPOSE_TAG); >> >> ?? assert(*basep == badResourceValue, "Expected guard in the form of >> badResourceValue"); >> ?? u_char* userp = guarded.get_user_ptr(); >> ?? assert(*userp == uninitBlockPad, "Expected uninitialized data in >> the form of uninitBlockPad"); >> -? guarded_memory_test_check(userp, 1, (void*)0xf000f000); >> +? guarded_memory_test_check(userp, 1, GEN_PURPOSE_TAG); >> >> ?? void* freep = guarded.release_for_freeing(); >> ?? assert((u_char*)freep == basep, "Expected the same pointer guard >> was "); >> bash-4.2$ >> >> >> >> Thanks >> Kevin >> > From dmitry.markov at oracle.com Fri Jun 22 11:57:17 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 22 Jun 2018 12:57:17 +0100 Subject: [8u-dev] Request for approval 8200353: Shift or Capslock not working in Textfield after accented keystrokes Message-ID: Hello, Can I get an approval to port the fix for 8200353 to jdk8u-dev, please? The jdk11 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8200353 Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2018-June/014036.html JDK11 change: http://hg.openjdk.java.net/jdk/client/rev/1427a66f7714 Thanks, Dmitry From rob.mckenna at oracle.com Fri Jun 22 15:45:52 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 22 Jun 2018 16:45:52 +0100 Subject: [8u-dev] Request for approval 8200353: Shift or Capslock not working in Textfield after accented keystrokes In-Reply-To: References: Message-ID: <20180622154552.GA5126@vimes> Approved -Rob On 22/06/18 12:57, Dmitry Markov wrote: > Hello, > > Can I get an approval to port the fix for 8200353 to jdk8u-dev, please? The jdk11 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8200353 > Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2018-June/014036.html > JDK11 change: http://hg.openjdk.java.net/jdk/client/rev/1427a66f7714 > > Thanks, > Dmitry From VicWang at zhaoxin.com Mon Jun 25 09:01:06 2018 From: VicWang at zhaoxin.com (Vic Wang(BJ-RD)) Date: Mon, 25 Jun 2018 09:01:06 +0000 Subject: =?gb2312?B?aW5xdWlyeSB3aGV0aGVyIGpkazh1IGNhbiBjb21waWxlIHdpdGggaWNjo78=?= Message-ID: Hi, I get the openjdk-jdk8u-jdk8u source code, and I want to compile jvm with ICC compiler. How to configure jvm before using ICC compiling? If there are any tips for ICC compiling, please let me know. Thanks a lot. Best Regards! VicWang ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From kevin.walls at oracle.com Mon Jun 25 10:43:05 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 25 Jun 2018 11:43:05 +0100 Subject: [8u-dev] Request for approval for CR 8204872: [8u] VS2017: threadLocalAllocBuffer.inline.hpp(99): error C3680: cannot concatenate user-defined string literals with mismatched literal suffix identifiers In-Reply-To: References: <7f561224-4b5c-96e6-697d-7896d21c4b5f@oracle.com> <20180615125817.GC3481@vimes> Message-ID: <37dcde92-8ccd-e228-1ac6-a37f9c5d1b26@oracle.com> Hi Sean, Rob - Just fyi... As I haven't pushed this one yet: having fixed a few other compile problems, there are some more of this exact same literal spacing issue...? I'll try and collect them all ther under this bug, and go back for a code review of them all together. Thanks Kevin On 15/06/2018 18:14, Se?n Coffey wrote: > This looks fine to me Kevin. Approved. > > Regards, > Sean. > > On 15/06/18 13:58, Rob McKenna wrote: >> This will require a codereview as its a new change. >> >> ???? -Rob >> >> On 15/06/18 12:00, Kevin Walls wrote: >>> Hi, >>> >>> I'd like to request approval to push to 8u: >>> >>> 8204872: [8u] VS2017: threadLocalAllocBuffer.inline.hpp(99): error >>> C3680: >>> cannot concatenate user-defined string literals with mismatched literal >>> suffix identifiers >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8204872 >>> >>> This is a new change, but a change to whitespace, following the same >>> pattern as 8081202 which is recently backported to 8u, i.e. add a space >>> between string literals and macros, to avoid compile errors. >>> This wasn't covered by 8081202 as it's in code which was no longer >>> the same >>> in 9, due to: >>> 8145092: Use Unified Logging for the GC logging >>> (which we are not backporting). >>> >>> Text diff is below, I've run it in various recent tests, but do let >>> me know >>> if a webrev or other approval is required. >>> >>> Many thanks >>> Kevin >>> >>> bash-4.2$ hg status >>> M src/share/vm/memory/threadLocalAllocBuffer.inline.hpp >>> bash-4.2$ hg diff src/share/vm/memory/threadLocalAllocBuffer.inline.hpp >>> diff -r 6688d6c6a225 >>> src/share/vm/memory/threadLocalAllocBuffer.inline.hpp >>> --- a/src/share/vm/memory/threadLocalAllocBuffer.inline.hpp Tue Feb 20 >>> 07:10:42 2018 -0500 >>> +++ b/src/share/vm/memory/threadLocalAllocBuffer.inline.hpp Fri Jun 15 >>> 03:48:33 2018 -0700 >>> @@ -94,10 +94,10 @@ >>> >>> ??? if (PrintTLAB && Verbose) { >>> ????? Thread* thrd = myThread(); >>> -??? gclog_or_tty->print("TLAB: %s thread: "INTPTR_FORMAT" [id: %2d]" >>> -??????????????????????? " obj: "SIZE_FORMAT >>> -??????????????????????? " free: "SIZE_FORMAT >>> -??????????????????????? " waste: "SIZE_FORMAT"\n", >>> +??? gclog_or_tty->print("TLAB: %s thread: " INTPTR_FORMAT " [id: %2d]" >>> +??????????????????????? " obj: " SIZE_FORMAT >>> +??????????????????????? " free: " SIZE_FORMAT >>> +??????????????????????? " waste: " SIZE_FORMAT "\n" >>> ????????????????????????? "slow", p2i(thrd), >>> thrd->osthread()->thread_id(), >>> ????????????????????????? obj_size, free(), refill_waste_limit()); >>> ??? } >>> > From martijnverburg at gmail.com Mon Jun 25 11:14:13 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 25 Jun 2018 12:14:13 +0100 Subject: =?UTF-8?Q?Re=3A_inquiry_whether_jdk8u_can_compile_with_icc=EF=BC=9F?= In-Reply-To: References: Message-ID: Hi Vic, You may wish to ask this question on the build-dev mailing list. Cheers, Martijn On Mon, 25 Jun 2018 at 10:02, Vic Wang(BJ-RD) wrote: > Hi, > > I get the openjdk-jdk8u-jdk8u source code, and I want to compile > jvm with ICC compiler. > How to configure jvm before using ICC compiling? > If there are any tips for ICC compiling, please let me know. Thanks > a lot. > > Best Regards! > VicWang > > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is > for the sole use of its intended recipient. Any unauthorized review, use, > copying or forwarding of this email or the content of this email is > strictly prohibited. > From kevin.walls at oracle.com Mon Jun 25 14:07:50 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 25 Jun 2018 15:07:50 +0100 Subject: [8u-dev] Request for approval for CR 8069124: runtime/NMT/MallocSiteHashOverflow.java failing in nightlies Message-ID: Hi, I'd like to request approval to backport from 9 to 8u: 8069124: runtime/NMT/MallocSiteHashOverflow.java failing in nightlies JBS: https://bugs.openjdk.java.net/browse/JDK-8069124 9 changeset: URL:?? http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e0c6eb5fce97 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e0c6eb5fce97 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014113.html This is a "clean backport, or imports with minimal/trivial changes". Specifically, this is a clean import except for src/share/vm/services/mallocSiteTable.cpp where the change of "int index" to "unsigned int index" failed to happen automatically: on a neighbouring line, the jdk9 change also removes an assert,? which we don't have here in 8u.? The rejected 9 change and proposed 8u change are pasted in below (will webrev if not clear...?). The bug title is a test failure, but this is wanted in 8u as it cleans up the types and avoids a compile error on later Windows compilers, i.e.: ...hotspot\src\share\vm\utilities\nativeCallStack.cpp(78): warning C4311: 'type cast': pointer truncation from 'const address' to 'long' ...hotspot\src\share\vm\utilities\nativeCallStack.cpp(78): warning C4302: 'type cast': truncation from 'const address' to 'long' Many thanks! Kevin 9 change rejected for 8u: bash-4.2$ cat src/share/vm/services/mallocSiteTable.cpp.rej --- mallocSiteTable.cpp +++ mallocSiteTable.cpp @@ -135,8 +135,7 @@ ? */ ?MallocSite* MallocSiteTable::lookup_or_add(const NativeCallStack& key, size_t* bucket_idx, ?? size_t* pos_idx) { -? int index = hash_to_index(key.hash()); -? assert(index >= 0, err_msg("Negative index %d", index)); +? unsigned int index = hash_to_index(key.hash()); ?? *bucket_idx = (size_t)index; ?? *pos_idx = 0; 8u change: bash-4.2$ hg diff src/share/vm/services/mallocSiteTable.cpp diff -r 0fa4c2b668b9 src/share/vm/services/mallocSiteTable.cpp --- a/src/share/vm/services/mallocSiteTable.cpp Fri Jun 22 01:55:23 2018 -0700 +++ b/src/share/vm/services/mallocSiteTable.cpp Mon Jun 25 06:54:46 2018 -0700 @@ -136,7 +136,7 @@ ?MallocSite* MallocSiteTable::lookup_or_add(const NativeCallStack& key, size_t* bucket_idx, ?? size_t* pos_idx, MEMFLAGS flags) { ?? assert(flags != mtNone, "Should have a real memory type"); -? int index = hash_to_index(key.hash()); +? unsigned int index = hash_to_index(key.hash()); ?? assert(index >= 0, "Negative index"); ?? *bucket_idx = (size_t)index; ?? *pos_idx = 0; bash-4.2$ From sgehwolf at redhat.com Mon Jun 25 14:18:43 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 25 Jun 2018 16:18:43 +0200 Subject: RFA: 8061305: Javadoc crashes when method name ends with "Property" Message-ID: <73778bb6a2fe8522a955a528ed3862615c75c38f.camel@redhat.com> Hi, Please approve this backport to 8u. The fix is the same as in JDK 9+ after path unshuffeling. The only difference is in tests. The test structure changed significantly in JDK 9+, hence the difference. Bug: https://bugs.openjdk.java.net/browse/JDK-8061305 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8061305/webrev.02/ Review-thread for 8u changes: http://mail.openjdk.java.net/pipermail/javadoc-dev/2018-June/000555.html Thanks, Severin From rob.mckenna at oracle.com Mon Jun 25 14:52:49 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 25 Jun 2018 15:52:49 +0100 Subject: [8u-dev] Request for approval for CR 8069124: runtime/NMT/MallocSiteHashOverflow.java failing in nightlies In-Reply-To: References: Message-ID: <20180625145249.GC3040@vimes> Thanks for the clarification Kevin. Approved. -Rob On 25/06/18 15:07, Kevin Walls wrote: > Hi, > > I'd like to request approval to backport from 9 to 8u: > > 8069124: runtime/NMT/MallocSiteHashOverflow.java failing in nightlies > JBS: https://bugs.openjdk.java.net/browse/JDK-8069124 > > 9 changeset: > URL:?? http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e0c6eb5fce97 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e0c6eb5fce97 > > 9 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014113.html > > > This is a "clean backport, or imports with minimal/trivial changes". > Specifically, this is a clean import except for > src/share/vm/services/mallocSiteTable.cpp where the change of "int index" to > "unsigned int index" failed to happen automatically: on a neighbouring line, > the jdk9 change also removes an assert,? which we don't have here in 8u.? > The rejected 9 change and proposed 8u change are pasted in below (will > webrev if not clear...?). > > The bug title is a test failure, but this is wanted in 8u as it cleans up > the types and avoids a compile error on later Windows > compilers, i.e.: > ...hotspot\src\share\vm\utilities\nativeCallStack.cpp(78): warning C4311: > 'type cast': pointer truncation from 'const address' to 'long' > ...hotspot\src\share\vm\utilities\nativeCallStack.cpp(78): warning C4302: > 'type cast': truncation from 'const address' to 'long' > > > Many thanks! > Kevin > > > 9 change rejected for 8u: > > bash-4.2$ cat src/share/vm/services/mallocSiteTable.cpp.rej > --- mallocSiteTable.cpp > +++ mallocSiteTable.cpp > @@ -135,8 +135,7 @@ > ? */ > ?MallocSite* MallocSiteTable::lookup_or_add(const NativeCallStack& key, > size_t* bucket_idx, > ?? size_t* pos_idx) { > -? int index = hash_to_index(key.hash()); > -? assert(index >= 0, err_msg("Negative index %d", index)); > +? unsigned int index = hash_to_index(key.hash()); > ?? *bucket_idx = (size_t)index; > ?? *pos_idx = 0; > > > 8u change: > > bash-4.2$ hg diff src/share/vm/services/mallocSiteTable.cpp > diff -r 0fa4c2b668b9 src/share/vm/services/mallocSiteTable.cpp > --- a/src/share/vm/services/mallocSiteTable.cpp Fri Jun 22 01:55:23 2018 > -0700 > +++ b/src/share/vm/services/mallocSiteTable.cpp Mon Jun 25 06:54:46 2018 > -0700 > @@ -136,7 +136,7 @@ > ?MallocSite* MallocSiteTable::lookup_or_add(const NativeCallStack& key, > size_t* bucket_idx, > ?? size_t* pos_idx, MEMFLAGS flags) { > ?? assert(flags != mtNone, "Should have a real memory type"); > -? int index = hash_to_index(key.hash()); > +? unsigned int index = hash_to_index(key.hash()); > ?? assert(index >= 0, "Negative index"); > ?? *bucket_idx = (size_t)index; > ?? *pos_idx = 0; > bash-4.2$ > From rob.mckenna at oracle.com Tue Jun 26 03:01:37 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 26 Jun 2018 04:01:37 +0100 Subject: RFA: 8061305: Javadoc crashes when method name ends with "Property" In-Reply-To: <73778bb6a2fe8522a955a528ed3862615c75c38f.camel@redhat.com> References: <73778bb6a2fe8522a955a528ed3862615c75c38f.camel@redhat.com> Message-ID: <20180626030137.GA4987@vimes> Approved -Rob On 25/06/18 16:18, Severin Gehwolf wrote: > Hi, > > Please approve this backport to 8u. The fix is the same as in JDK 9+ > after path unshuffeling. The only difference is in tests. The test > structure changed significantly in JDK 9+, hence the difference. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061305 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8061305/webrev.02/ > Review-thread for 8u changes: > http://mail.openjdk.java.net/pipermail/javadoc-dev/2018-June/000555.html > > Thanks, > Severin From kevin.walls at oracle.com Tue Jun 26 08:15:33 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 26 Jun 2018 09:15:33 +0100 Subject: [8u-dev] Request for approval for CR 8205440: [8u] DWORD64 required for later Windows compilers Message-ID: <831e579c-0081-a219-b8ab-61d9de6379da@oracle.com> Hi, I'd like to request approval to push a small new change 8u: 8205440: [8u] DWORD64 required for later Windows compilers JBS: https://bugs.openjdk.java.net/browse/JDK-8205440 Proposed 8u change: src/os/windows/vm/os_windows.cpp @@ -2261,9 +2296,9 @@ ?? assert((pc[1] & ~0x7) == 0xF8, "cannot handle non-register operands"); ?? assert(ctx->Rax == min_jint, "unexpected idiv exception"); ?? // set correct result values and continue after idiv instruction -? ctx->Rip = (DWORD)pc + 2;??????? // idiv reg, reg? is 2 bytes -? ctx->Rax = (DWORD)min_jint;????? // result -? ctx->Rdx = (DWORD)0;???????????? // remainder +? ctx->Rip = (DWORD64)pc + 2;??????? // idiv reg, reg? is 2 bytes +? ctx->Rax = (DWORD64)min_jint;????? // result +? ctx->Rdx = (DWORD64)0;???????????? // remainder ?? // Continue the execution ?? #else ?? PCONTEXT ctx = exceptionInfo->ContextRecord; In JDK9, these DWORD changed to DWORD64 as a minor byproduct of: 8136421: JEP 243: Java-Level JVM Compiler Interface ...which we aren't implementing in jdk8 right now. Hotspot review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033294.html Thanks Kevin From david.buck at oracle.com Tue Jun 26 08:31:07 2018 From: david.buck at oracle.com (David Buck) Date: Tue, 26 Jun 2018 17:31:07 +0900 Subject: [8u-dev] Request for approval for CR 8205440: [8u] DWORD64 required for later Windows compilers In-Reply-To: <831e579c-0081-a219-b8ab-61d9de6379da@oracle.com> References: <831e579c-0081-a219-b8ab-61d9de6379da@oracle.com> Message-ID: approved for push to 8u-dev Cheers, -Buck On 2018/06/26 17:15, Kevin Walls wrote: > Hi, > > I'd like to request approval to push a small new change 8u: > > 8205440: [8u] DWORD64 required for later Windows compilers > JBS: https://bugs.openjdk.java.net/browse/JDK-8205440 > > > Proposed 8u change: > > src/os/windows/vm/os_windows.cpp > > @@ -2261,9 +2296,9 @@ > ?? assert((pc[1] & ~0x7) == 0xF8, "cannot handle non-register operands"); > ?? assert(ctx->Rax == min_jint, "unexpected idiv exception"); > ?? // set correct result values and continue after idiv instruction > -? ctx->Rip = (DWORD)pc + 2;??????? // idiv reg, reg? is 2 bytes > -? ctx->Rax = (DWORD)min_jint;????? // result > -? ctx->Rdx = (DWORD)0;???????????? // remainder > +? ctx->Rip = (DWORD64)pc + 2;??????? // idiv reg, reg? is 2 bytes > +? ctx->Rax = (DWORD64)min_jint;????? // result > +? ctx->Rdx = (DWORD64)0;???????????? // remainder > ?? // Continue the execution > ?? #else > ?? PCONTEXT ctx = exceptionInfo->ContextRecord; > > > In JDK9, these DWORD changed to DWORD64 as a minor byproduct of: > 8136421: JEP 243: Java-Level JVM Compiler Interface > ...which we aren't implementing in jdk8 right now. > > Hotspot review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033294.html > > Thanks > Kevin > From sgehwolf at redhat.com Tue Jun 26 13:30:42 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 26 Jun 2018 15:30:42 +0200 Subject: [8u-dev] RFA: 8185723: Zero: segfaults on Power PC 32-bit Message-ID: <528cf63e07e9995d06cdff0da564ff0bd46d7bb0.camel@redhat.com> Hi, Please approve this 8u backport of a Zero-only fix for PPC 32-bit. The patch fixes JVM crashes. It's been in JDK 10+ for almost a year now and we've been using this fix in Fedora ever since. The committed patch to JDK 10 (back then) applies as is to JDK 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8185723 webrev: http://cr.openjdk.java.net/~aph/8185723/ Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/027733.html Thanks, Severin From sgehwolf at redhat.com Tue Jun 26 14:11:39 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 26 Jun 2018 16:11:39 +0200 Subject: [8u-dev] RFA: 8186461: Zero's atomic_copy64() should use SPE instructions on linux-powerpcspe Message-ID: <1971c4a800da6daedf611ac545cb75f7eb306bdc.camel@redhat.com> Hi, Please approve this Zero-only patch for JDK 8u which fixes a build issue on PPC 32-bit systems which don't have FPUs. The patch from JDK 10 applies as is with minor context changes after JDK-8185723[1] has been applied: JDK 8: static void atomic_copy64(volatile void *src, volatile void *dst) vs: JDK 10: static void atomic_copy64(const volatile void *src, volatile void *dst) Bug: https://bugs.openjdk.java.net/browse/JDK-8186461 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8186461/webrev.01/ Original review-thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029265.html Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007579.html From sgehwolf at redhat.com Tue Jun 26 14:37:48 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 26 Jun 2018 16:37:48 +0200 Subject: [8u-dev] RFA: 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong Message-ID: <830fed428668d0c5b1bdbc1cb726b6ef9f7a7dbd.camel@redhat.com> Hi, Please approve this Zero-only JDK 8u backport which fixes random SEGVs on S390 (31 bit). We have been using this patch for months in Fedora and would like to get this upstream. The patch is in JDK 10u and in JDK 11. The JDK 11 patch applies with minor patch context changes post path-unshuffeling and after JDK-8185723[1] and JDK-8186461[2] have been applied. Bug: https://bugs.openjdk.java.net/browse/JDK-8201509 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201509/webrev.01/ Original review-thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031626.html Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007579.html [2] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007580.html From gnu.andrew at redhat.com Tue Jun 26 17:39:07 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 26 Jun 2018 18:39:07 +0100 Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: Message-ID: On 21 June 2018 at 04:56, Andrew Hughes wrote: > [CCing hotspot list for review] > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179887 > Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8179887/webrev.01/ > Review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031746.html > > Patch is basically the same as for OpenJDK 11, except we don't have to > revert 8187667, which isn't present in OpenJDK 8. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Ping? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rob.mckenna at oracle.com Tue Jun 26 17:57:23 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 26 Jun 2018 18:57:23 +0100 Subject: [8u-dev] RFA: 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong In-Reply-To: <830fed428668d0c5b1bdbc1cb726b6ef9f7a7dbd.camel@redhat.com> References: <830fed428668d0c5b1bdbc1cb726b6ef9f7a7dbd.camel@redhat.com> Message-ID: <20180626175723.GB3315@vimes> Approved -Rob On 26/06/18 16:37, Severin Gehwolf wrote: > Hi, > > Please approve this Zero-only JDK 8u backport which fixes random SEGVs > on S390 (31 bit). We have been using this patch for months in Fedora > and would like to get this upstream. The patch is in JDK 10u and in JDK > 11. The JDK 11 patch applies with minor patch context changes post > path-unshuffeling and after JDK-8185723[1] and JDK-8186461[2] have been > applied. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201509 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201509/webrev.01/ > Original review-thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031626.html > > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007579.html > [2] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007580.html From rob.mckenna at oracle.com Tue Jun 26 17:57:39 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 26 Jun 2018 18:57:39 +0100 Subject: [8u-dev] RFA: 8186461: Zero's atomic_copy64() should use SPE instructions on linux-powerpcspe In-Reply-To: <1971c4a800da6daedf611ac545cb75f7eb306bdc.camel@redhat.com> References: <1971c4a800da6daedf611ac545cb75f7eb306bdc.camel@redhat.com> Message-ID: <20180626175739.GC3315@vimes> Approved -Rob On 26/06/18 16:11, Severin Gehwolf wrote: > Hi, > > Please approve this Zero-only patch for JDK 8u which fixes a build > issue on PPC 32-bit systems which don't have FPUs. The patch from JDK > 10 applies as is with minor context changes after JDK-8185723[1] has > been applied: > > JDK 8: > static void atomic_copy64(volatile void *src, volatile void *dst) > > vs: > > JDK 10: > static void atomic_copy64(const volatile void *src, volatile void *dst) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186461 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8186461/webrev.01/ > Original review-thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029265.html > > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-June/007579.html From rob.mckenna at oracle.com Tue Jun 26 17:58:00 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 26 Jun 2018 18:58:00 +0100 Subject: [8u-dev] RFA: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <528cf63e07e9995d06cdff0da564ff0bd46d7bb0.camel@redhat.com> References: <528cf63e07e9995d06cdff0da564ff0bd46d7bb0.camel@redhat.com> Message-ID: <20180626175800.GD3315@vimes> Approved -Rob On 26/06/18 15:30, Severin Gehwolf wrote: > Hi, > > Please approve this 8u backport of a Zero-only fix for PPC 32-bit. The > patch fixes JVM crashes. It's been in JDK 10+ for almost a year now and > we've been using this fix in Fedora ever since. The committed patch to > JDK 10 (back then) applies as is to JDK 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185723 > webrev: http://cr.openjdk.java.net/~aph/8185723/ > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/027733.html > > Thanks, > Severin From kevin.walls at oracle.com Wed Jun 27 06:26:40 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 27 Jun 2018 07:26:40 +0100 Subject: [8u-dev] Request for approval: 8204872: [8u] VS2017: more instances of "error C3680: cannot concatenate user-defined string literals with mismatched literal suffix identifiers" Message-ID: <28985527-dc43-7091-1305-69e5a1c72ecb@oracle.com> Hi, I'd like to get approval for 8u for... 8204872: [8u] VS2017: more instances of "error C3680: cannot concatenate user-defined string literals with mismatched literal suffix identifiers" https://bugs.openjdk.java.net/browse/JDK-8204872 These are whitespace additions, in the pattern of https://bugs.openjdk.java.net/browse/JDK-8081202 ...? I think these are the last of the literal suffix spacing issues when using a later Windows VS compiler on 8u. 8u webrev: http://cr.openjdk.java.net/~kevinw/8204872/webrev.00/ hotspot-dev approval thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033310.html Thanks! Kevin From david.buck at oracle.com Wed Jun 27 06:43:08 2018 From: david.buck at oracle.com (David Buck) Date: Wed, 27 Jun 2018 15:43:08 +0900 Subject: [8u-dev] Request for approval: 8204872: [8u] VS2017: more instances of "error C3680: cannot concatenate user-defined string literals with mismatched literal suffix identifiers" In-Reply-To: <28985527-dc43-7091-1305-69e5a1c72ecb@oracle.com> References: <28985527-dc43-7091-1305-69e5a1c72ecb@oracle.com> Message-ID: <5fc78265-03a2-c0cc-6cf2-57f78460a019@oracle.com> approved Cheers, -Buck On 2018/06/27 15:26, Kevin Walls wrote: > Hi, > > I'd like to get approval for 8u for... > > 8204872: [8u] VS2017: more instances of "error C3680: cannot concatenate > user-defined string literals with mismatched literal suffix identifiers" > https://bugs.openjdk.java.net/browse/JDK-8204872 > > These are whitespace additions, in the pattern of > https://bugs.openjdk.java.net/browse/JDK-8081202 ...? I think these are > the last of the literal suffix spacing issues when using a later Windows > VS compiler on 8u. > > 8u webrev: http://cr.openjdk.java.net/~kevinw/8204872/webrev.00/ > > hotspot-dev approval thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033310.html > > Thanks! > Kevin > From gnu.andrew at redhat.com Wed Jun 27 14:47:53 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 Jun 2018 15:47:53 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf Message-ID: I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. Severin is already a committer for later versions of OpenJDK (9 and up) and has had a number of backports approved for OpenJDK 8, in addition to his own work [0], including three in the last twenty-four hours. Votes are due by 17h00 UTC on the 11th of July, 2018. Only current OpenJDK 8 Updates 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]. [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() [1] http://openjdk.java.net/census#jdk8u [2] http://openjdk.java.net/projects/#committer-vote -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jun 27 14:49:54 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 Jun 2018 15:49:54 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: On 27 June 2018 at 15:47, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. > > Severin is already a committer for later versions of OpenJDK (9 and up) and > has had a number of backports approved for OpenJDK 8, in addition to his own > work [0], including three in the last twenty-four hours. > > Votes are due by 17h00 UTC on the 11th of July, 2018. > > Only current OpenJDK 8 Updates 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]. > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() > [1] http://openjdk.java.net/census#jdk8u > [2] http://openjdk.java.net/projects/#committer-vote > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Vote: Yes. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From zgu at redhat.com Wed Jun 27 14:51:07 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 Jun 2018 10:51:07 -0400 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: <5a263a2a-0ca1-b0e9-35f5-25e7c62a15d5@redhat.com> Vote: yes -Zhengyu On 06/27/2018 10:47 AM, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. > > Severin is already a committer for later versions of OpenJDK (9 and up) and > has had a number of backports approved for OpenJDK 8, in addition to his own > work [0], including three in the last twenty-four hours. > > Votes are due by 17h00 UTC on the 11th of July, 2018. > > Only current OpenJDK 8 Updates 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]. > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() > [1] http://openjdk.java.net/census#jdk8u > [2] http://openjdk.java.net/projects/#committer-vote > From neugens at redhat.com Wed Jun 27 14:54:33 2018 From: neugens at redhat.com (Mario Torre) Date: Wed, 27 Jun 2018 16:54:33 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario On Wed, Jun 27, 2018 at 4:47 PM, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. > > Severin is already a committer for later versions of OpenJDK (9 and up) and > has had a number of backports approved for OpenJDK 8, in addition to his own > work [0], including three in the last twenty-four hours. > > Votes are due by 17h00 UTC on the 11th of July, 2018. > > Only current OpenJDK 8 Updates 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]. > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() > [1] http://openjdk.java.net/census#jdk8u > [2] http://openjdk.java.net/projects/#committer-vote > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From rkennke at redhat.com Wed Jun 27 14:59:38 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 Jun 2018 16:59:38 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes :-) > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. > > Severin is already a committer for later versions of OpenJDK (9 and up) and > has had a number of backports approved for OpenJDK 8, in addition to his own > work [0], including three in the last twenty-four hours. > > Votes are due by 17h00 UTC on the 11th of July, 2018. > > Only current OpenJDK 8 Updates 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]. > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() > [1] http://openjdk.java.net/census#jdk8u > [2] http://openjdk.java.net/projects/#committer-vote > From andy.herrick at oracle.com Wed Jun 27 15:05:21 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Jun 2018 11:05:21 -0400 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: <3287c56a-b0a8-fa98-3399-4b7bfdeb5e51@oracle.com> vote: yes /Andy On 6/27/2018 10:47 AM, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. > > Severin is already a committer for later versions of OpenJDK (9 and up) and > has had a number of backports approved for OpenJDK 8, in addition to his own > work [0], including three in the last twenty-four hours. > > Votes are due by 17h00 UTC on the 11th of July, 2018. > > Only current OpenJDK 8 Updates 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]. > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() > [1] http://openjdk.java.net/census#jdk8u > [2] http://openjdk.java.net/projects/#committer-vote From vladimir.kozlov at oracle.com Wed Jun 27 16:42:15 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Jun 2018 09:42:15 -0700 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: <62980e3d-88be-680c-dbdf-4af93ba6b44b@oracle.com> Vote: yes On 6/27/18 7:47 AM, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. > > Severin is already a committer for later versions of OpenJDK (9 and up) and > has had a number of backports approved for OpenJDK 8, in addition to his own > work [0], including three in the last twenty-four hours. > > Votes are due by 17h00 UTC on the 11th of July, 2018. > > Only current OpenJDK 8 Updates 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]. > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() > [1] http://openjdk.java.net/census#jdk8u > [2] http://openjdk.java.net/projects/#committer-vote > From serguei.spitsyn at oracle.com Wed Jun 27 20:10:43 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Jun 2018 13:10:43 -0700 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes From shade at redhat.com Wed Jun 27 20:41:36 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Jun 2018 22:41:36 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes On 06/27/2018 04:47 PM, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. From volker.simonis at gmail.com Thu Jun 28 06:24:27 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Jun 2018 08:24:27 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes On Wed, Jun 27, 2018 at 4:47 PM, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. > > Severin is already a committer for later versions of OpenJDK (9 and up) and > has had a number of backports approved for OpenJDK 8, in addition to his own > work [0], including three in the last twenty-four hours. > > Votes are due by 17h00 UTC on the 11th of July, 2018. > > Only current OpenJDK 8 Updates 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]. > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() > [1] http://openjdk.java.net/census#jdk8u > [2] http://openjdk.java.net/projects/#committer-vote > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jun 29 04:47:25 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 29 Jun 2018 05:47:25 +0100 Subject: [8u] Request for Approval for JDK-6260348: GTK+ L&F JTextComponent not respecting desktop caret blink rate Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-6260348 Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/6260348/webrev.01/ Original review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2015-April/004424.html Fix applies as is to OpenJDK 8 (bar one copyright header being older in 8) Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sean.coffey at oracle.com Fri Jun 29 07:18:50 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 29 Jun 2018 08:18:50 +0100 Subject: [8u] Request for Approval for JDK-6260348: GTK+ L&F JTextComponent not respecting desktop caret blink rate In-Reply-To: References: Message-ID: Approved. regards, Sean. On 29/06/2018 05:47, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-6260348 > Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/6260348/webrev.01/ > Original review thread: > http://mail.openjdk.java.net/pipermail/swing-dev/2015-April/004424.html > > Fix applies as is to OpenJDK 8 (bar one copyright header being older in 8) > > Thanks, From dalibor.topic at oracle.com Fri Jun 29 11:08:04 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 29 Jun 2018 13:08:04 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: <4fd93345-2e5d-8e45-5332-7f71c9d98b26@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From gnu.andrew at redhat.com Fri Jun 29 13:06:06 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 29 Jun 2018 14:06:06 +0100 Subject: [8u] Request for Approval for JDK-6260348: GTK+ L&F JTextComponent not respecting desktop caret blink rate In-Reply-To: References: Message-ID: On 29 June 2018 at 08:18, Se?n Coffey wrote: > Approved. > > regards, > Sean. > > > > On 29/06/2018 05:47, Andrew Hughes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6260348 >> Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/6260348/webrev.01/ >> Original review thread: >> http://mail.openjdk.java.net/pipermail/swing-dev/2015-April/004424.html >> >> Fix applies as is to OpenJDK 8 (bar one copyright header being older in 8) >> >> Thanks, > > Thanks. Pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/2bd1e6a63647 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From daniel.fuchs at oracle.com Fri Jun 29 15:38:03 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 Jun 2018 17:38:03 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: <240620c8-66f2-f032-5f7c-ded692351f4c@oracle.com> Vote: yes best regards, -- daniel On 27/06/2018 16:47, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. From aleksej.efimov at oracle.com Fri Jun 29 17:03:55 2018 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 29 Jun 2018 18:03:55 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Severin Gehwolf In-Reply-To: References: Message-ID: <49130eaa-ab52-22be-3e9e-dfe9418de6ea@oracle.com> Vote: yes On 06/27/2018 03:47 PM, Andrew Hughes wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to OpenJDK 8 Updates Committer. > > Severin is already a committer for later versions of OpenJDK (9 and up) and > has had a number of backports approved for OpenJDK 8, in addition to his own > work [0], including three in the last twenty-four hours. > > Votes are due by 17h00 UTC on the 11th of July, 2018. > > Only current OpenJDK 8 Updates 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]. > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf%40redhat.com%22))+and+not+merge() > [1] http://openjdk.java.net/census#jdk8u > [2] http://openjdk.java.net/projects/#committer-vote