From Sergey.Bylokhov at oracle.com Mon Oct 1 01:10:25 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 30 Sep 2018 18:10:25 -0700 Subject: [8u-dev] Request for approval: 8202264 and 8207150 Message-ID: Hello, These are the direct backports from jdk12 to jdk8u-dev. webrev for both: http://cr.openjdk.java.net/~serb/8207150/jdk8/webrev.00 8202264: Race condition in AudioClip.loop() Bug: https://bugs.openjdk.java.net/browse/JDK-8202264 jdk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/003aa3e59090 Reviewer: Phil Race 8207150: Clip.isRunning() may return true after Clip.stop() was called Bug: https://bugs.openjdk.java.net/browse/JDK-8207150 jdk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/dcf301c53d23 Reviewer: Phil Race -- Best regards, Sergey. From david.buck at oracle.com Mon Oct 1 03:14:25 2018 From: david.buck at oracle.com (David Buck) Date: Mon, 1 Oct 2018 12:14:25 +0900 Subject: [8u-dev] Request for approval: 8202264 and 8207150 In-Reply-To: References: Message-ID: approved Cheers, -Buck On 2018/10/01 10:10, Sergey Bylokhov wrote: > Hello, > > These are the direct backports from jdk12 to jdk8u-dev. > webrev for both: http://cr.openjdk.java.net/~serb/8207150/jdk8/webrev.00 > > > 8202264: Race condition in AudioClip.loop() > Bug: https://bugs.openjdk.java.net/browse/JDK-8202264 > jdk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/003aa3e59090 > Reviewer: Phil Race > > 8207150: Clip.isRunning() may return true after Clip.stop() was called > Bug: https://bugs.openjdk.java.net/browse/JDK-8207150 > jdk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/dcf301c53d23 > Reviewer: Phil Race > From Alan.Bateman at oracle.com Mon Oct 1 09:40:11 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Oct 2018 10:40:11 +0100 Subject: [8u-dev] Request for approval for JDK-8208638 : Instead of circle rendered in appl window, but ellipse is produced in JEditorPane In-Reply-To: References: Message-ID: On 28/09/2018 02:11, Krishna Addepalli wrote: > Hi, > > Could you please approve the backport of the jdk12 fix to 8u-dev? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208638 > webrev: http://cr.openjdk.java.net/~kaddepalli/8208638/8udev/webrev/ > > The patch is same except for the path difference between jdk12 and jdk8u. > JDk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/2105d8064ca2 > JDK12 review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2018-September/008907.html > I'm not involved in JDK updates but a back port from JDK 12 to 8u does beg the question as to whether the change will also be backported to 11u. I see there is discussion on jdk-updates-dev about the approvals for 11u but in the mean time then maybe backport issues should be created to at least track what will otherwise be regressions moving from 8u to 11u. -Alan From philip.race at oracle.com Mon Oct 1 16:29:13 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Oct 2018 09:29:13 -0700 Subject: [8u-dev] Request for approval for JDK-8208638 : Instead of circle rendered in appl window, but ellipse is produced in JEditorPane In-Reply-To: References: Message-ID: <5BB24B59.5040809@oracle.com> I'd go further .. it probably shouldn't go into 8u *without* a concurrent 11u backport. else (as others have pointed out) when you upgrade from 8u to 11u it regresses which is against a "big rule". -phil. On 10/1/18, 2:40 AM, Alan Bateman wrote: > On 28/09/2018 02:11, Krishna Addepalli wrote: >> Hi, >> Could you please approve the backport of the jdk12 fix to 8u-dev? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8208638 >> webrev: http://cr.openjdk.java.net/~kaddepalli/8208638/8udev/webrev/ >> The patch is same except for the path difference between jdk12 and >> jdk8u. >> JDk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/2105d8064ca2 >> JDK12 review thread: >> http://mail.openjdk.java.net/pipermail/swing-dev/2018-September/008907.html >> > I'm not involved in JDK updates but a back port from JDK 12 to 8u does > beg the question as to whether the change will also be backported to > 11u. I see there is discussion on jdk-updates-dev about the approvals > for 11u but in the mean time then maybe backport issues should be > created to at least track what will otherwise be regressions moving > from 8u to 11u. > > -Alan From krishna.addepalli at oracle.com Mon Oct 1 17:50:20 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Mon, 1 Oct 2018 23:20:20 +0530 Subject: [8u-dev] Request for approval for JDK-8208638 : Instead of circle rendered in appl window, but ellipse is produced in JEditorPane In-Reply-To: <5BB24B59.5040809@oracle.com> References: <5BB24B59.5040809@oracle.com> Message-ID: Hi Alan and Phil Thanks for your comments. I?m currently cloning the 11u repo. So, I need to send the mail to jdk11u-dev at openjdk.java.net for back port request? Krishna > On 01-Oct-2018, at 9:59 PM, Philip Race wrote: > > I'd go further .. it probably shouldn't go into 8u *without* a concurrent 11u backport. > else (as others have pointed out) when you upgrade from 8u to 11u it regresses > which is against a "big rule". > > -phil. > > On 10/1/18, 2:40 AM, Alan Bateman wrote: >> On 28/09/2018 02:11, Krishna Addepalli wrote: >>> Hi, >>> Could you please approve the backport of the jdk12 fix to 8u-dev? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208638 >>> webrev: http://cr.openjdk.java.net/~kaddepalli/8208638/8udev/webrev/ >>> The patch is same except for the path difference between jdk12 and jdk8u. >>> JDk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/2105d8064ca2 >>> JDK12 review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2018-September/008907.html >>> >> I'm not involved in JDK updates but a back port from JDK 12 to 8u does beg the question as to whether the change will also be backported to 11u. I see there is discussion on jdk-updates-dev about the approvals for 11u but in the mean time then maybe backport issues should be created to at least track what will otherwise be regressions moving from 8u to 11u. >> >> -Alan From philip.race at oracle.com Mon Oct 1 17:55:19 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 1 Oct 2018 10:55:19 -0700 Subject: [8u-dev] Request for approval for JDK-8208638 : Instead of circle rendered in appl window, but ellipse is produced in JEditorPane In-Reply-To: References: <5BB24B59.5040809@oracle.com> Message-ID: The 11 process documented here : http://openjdk.java.net/projects/jdk-updates/approval.html does not say anything about email .. so it is not clear .. it only talks about updating the bug report. So at least follow the process written there. -phil. On 10/01/2018 10:50 AM, Krishna Addepalli wrote: > Hi Alan and Phil > > Thanks for your comments. I?m currently cloning the 11u repo. So, I > need to send the mail to jdk11u-dev at openjdk.java.net > ?for back port request? > > Krishna > >> On 01-Oct-2018, at 9:59 PM, Philip Race > > wrote: >> >> I'd go further .. it probably shouldn't go into 8u *without* a >> concurrent 11u backport. >> else (as others have pointed out) when you upgrade from 8u to 11u it >> regresses >> which is against a "big rule". >> >> -phil. >> >> On 10/1/18, 2:40 AM, Alan Bateman wrote: >>> On 28/09/2018 02:11, Krishna Addepalli wrote: >>>> Hi, >>>> ?Could you please approve the backport of the jdk12 fix to 8u-dev? >>>> ?Bug: https://bugs.openjdk.java.net/browse/JDK-8208638 >>>> webrev: >>>> http://cr.openjdk.java.net/~kaddepalli/8208638/8udev/webrev/ >>>> >>>> ?The patch is same except for the path difference between jdk12 and >>>> jdk8u. >>>> JDk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/2105d8064ca2 >>>> JDK12 review thread: >>>> http://mail.openjdk.java.net/pipermail/swing-dev/2018-September/008907.html >>>> >>> I'm not involved in JDK updates but a back port from JDK 12 to 8u >>> does beg the question as to whether the change will also be >>> backported to 11u. I see there is discussion on jdk-updates-dev >>> about the approvals for 11u but in the mean time then maybe backport >>> issues should be created to at least track what will otherwise be >>> regressions moving from 8u to 11u. >>> >>> -Alan > From sean.coffey at oracle.com Tue Oct 2 08:29:57 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 2 Oct 2018 09:29:57 +0100 Subject: [8u-dev] Request for approval for JDK-8208638 : Instead of circle rendered in appl window, but ellipse is produced in JEditorPane In-Reply-To: <5BB24B59.5040809@oracle.com> References: <5BB24B59.5040809@oracle.com> Message-ID: <3e8f61ef-2c4f-cf43-d3e2-f52c655e680d@oracle.com> I've been monitoring the recent fixes coming into jdk8u-dev. If/when the criteria for allowing fixes into the LTS Update releases is altered, I'll work with the assignees to ensure that applicable 11.0.x fixes are also pushed. regards, Sean. On 01/10/2018 17:29, Philip Race wrote: > I'd go further .. it probably shouldn't go into 8u *without* a > concurrent 11u backport. > else (as others have pointed out) when you upgrade from 8u to 11u it > regresses > which is against a "big rule". > > -phil. > > On 10/1/18, 2:40 AM, Alan Bateman wrote: >> On 28/09/2018 02:11, Krishna Addepalli wrote: >>> Hi, >>> ? Could you please approve the backport of the jdk12 fix to 8u-dev? >>> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8208638 >>> webrev: http://cr.openjdk.java.net/~kaddepalli/8208638/8udev/webrev/ >>> ? The patch is same except for the path difference between jdk12 and >>> jdk8u. >>> JDk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/2105d8064ca2 >>> JDK12 review thread: >>> http://mail.openjdk.java.net/pipermail/swing-dev/2018-September/008907.html >>> >> I'm not involved in JDK updates but a back port from JDK 12 to 8u >> does beg the question as to whether the change will also be >> backported to 11u. I see there is discussion on jdk-updates-dev about >> the approvals for 11u but in the mean time then maybe backport issues >> should be created to at least track what will otherwise be >> regressions moving from 8u to 11u. >> >> -Alan From gromero at linux.vnet.ibm.com Tue Oct 2 13:42:07 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 2 Oct 2018 10:42:07 -0300 Subject: [8u] RFR for backport of JDK-8164920: ppc: enhancement of CRC32 intrinsic to jdk8u-dev (v3) In-Reply-To: <5d059529-6048-ea79-f661-aae05b754dcc@linux.vnet.ibm.com> References: <31e036a0-a7b7-70f2-422f-addd4049436f@linux.vnet.ibm.com> <5d059529-6048-ea79-f661-aae05b754dcc@linux.vnet.ibm.com> Message-ID: Hi, On 09/25/2018 03:29 PM, Gustavo Romero wrote: > Hi, > > Maybe I please get reviews for the following changes (v2)? > > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8131048/ > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8164920/ > > Change JDK-8131048 is a dependency to backport JDK-8164920 to 8u. > > Goetz reviewed the first version of this backport and pointed out necessary > changes and fixes that are present in this v2. Thank you, Goetz. > > There is no code change except to adapt the file paths, to add has_vpmsumb() > feature detection, and to adapt the signature before doing the runtime call > to CRC32 intrinsic by casting T_INTs as T_LONGs, because PPC64 > c_calling_convention() requires T_LONGs on 8u, otherwise a proper assert() > for that is hit. Additional testing of v2 has found that the connection of CRC32 update method for ByteBuffers to its intrinsic was missing in the Interpreter: diff -r a9bebb701e31 src/cpu/ppc/vm/templateInterpreter_ppc.cpp --- a/src/cpu/ppc/vm/templateInterpreter_ppc.cpp Mon Sep 24 17:18:38 2018 -0400 +++ b/src/cpu/ppc/vm/templateInterpreter_ppc.cpp Sun Sep 30 21:58:58 2018 -0400 @@ -1327,9 +1327,12 @@ case Interpreter::java_lang_math_exp : entry_point = ((InterpreterGenerator*) this)->generate_math_entry(kind); break; case Interpreter::java_lang_ref_reference_get : entry_point = ((InterpreterGenerator*)this)->generate_Reference_get_entry(); break; - case Interpreter::java_util_zip_CRC32_update : entry_point = ((InterpreterGenerator*)this)->generate_CRC32_update_entry(); break; - case Interpreter::java_util_zip_CRC32_updateBytes : entry_point = ((InterpreterGenerator*)this)->generate_CRC32_updateBytes_entry(kind); break; - case Interpreter::java_util_zip_CRC32_updateByteBuffer : break; + case Interpreter::java_util_zip_CRC32_update + : entry_point = ((InterpreterGenerator*)this)->generate_CRC32_update_entry(); break; + case Interpreter::java_util_zip_CRC32_updateBytes + : // fall thru + case Interpreter::java_util_zip_CRC32_updateByteBuffer + : entry_point = ((InterpreterGenerator*)this)->generate_CRC32_updateBytes_entry(kind); break; default : ShouldNotReachHere(); break; } Please find v3 which fixes that issue in: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ Thank you. Best regards, Gustavo From goetz.lindenmaier at sap.com Tue Oct 2 14:03:09 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Oct 2018 14:03:09 +0000 Subject: [8u] RFR for backport of JDK-8164920: ppc: enhancement of CRC32 intrinsic to jdk8u-dev (v3) In-Reply-To: References: <31e036a0-a7b7-70f2-422f-addd4049436f@linux.vnet.ibm.com> <5d059529-6048-ea79-f661-aae05b754dcc@linux.vnet.ibm.com> Message-ID: <5b1dbfc516844d519205dd1286a98a9a@sap.com> Hi Gustavo, Your change looks good. I ran build and tests on aix and linux ppc64 be which are fine. Best regards, Goetz. > -----Original Message----- > From: Gustavo Romero > Sent: Dienstag, 2. Oktober 2018 15:42 > To: hotspot-compiler-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net; Lindenmaier, Goetz > ; Doerr, Martin > Subject: Re: [8u] RFR for backport of JDK-8164920: ppc: enhancement of > CRC32 intrinsic to jdk8u-dev (v3) > > Hi, > > On 09/25/2018 03:29 PM, Gustavo Romero wrote: > > Hi, > > > > Maybe I please get reviews for the following changes (v2)? > > > > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8131048/ > > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8164920/ > > > > Change JDK-8131048 is a dependency to backport JDK-8164920 to 8u. > > > > Goetz reviewed the first version of this backport and pointed out > necessary > > changes and fixes that are present in this v2. Thank you, Goetz. > > > > There is no code change except to adapt the file paths, to add > has_vpmsumb() > > feature detection, and to adapt the signature before doing the runtime call > > to CRC32 intrinsic by casting T_INTs as T_LONGs, because PPC64 > > c_calling_convention() requires T_LONGs on 8u, otherwise a proper > assert() > > for that is hit. > > Additional testing of v2 has found that the connection of CRC32 update > method > for ByteBuffers to its intrinsic was missing in the Interpreter: > > > diff -r a9bebb701e31 src/cpu/ppc/vm/templateInterpreter_ppc.cpp > --- a/src/cpu/ppc/vm/templateInterpreter_ppc.cpp Mon Sep 24 17:18:38 > 2018 -0400 > +++ b/src/cpu/ppc/vm/templateInterpreter_ppc.cpp Sun Sep 30 21:58:58 > 2018 -0400 > @@ -1327,9 +1327,12 @@ > case Interpreter::java_lang_math_exp : entry_point = > ((InterpreterGenerator*) this)->generate_math_entry(kind); break; > case Interpreter::java_lang_ref_reference_get > : entry_point = ((InterpreterGenerator*)this)- > >generate_Reference_get_entry(); break; > - case Interpreter::java_util_zip_CRC32_update : entry_point = > ((InterpreterGenerator*)this)->generate_CRC32_update_entry(); break; > - case Interpreter::java_util_zip_CRC32_updateBytes : entry_point = > ((InterpreterGenerator*)this)->generate_CRC32_updateBytes_entry(kind); > break; > - case Interpreter::java_util_zip_CRC32_updateByteBuffer : break; > + case Interpreter::java_util_zip_CRC32_update > + : entry_point = ((InterpreterGenerator*)this)- > >generate_CRC32_update_entry(); break; > + case Interpreter::java_util_zip_CRC32_updateBytes > + : // fall thru > + case Interpreter::java_util_zip_CRC32_updateByteBuffer > + : entry_point = ((InterpreterGenerator*)this)- > >generate_CRC32_updateBytes_entry(kind); break; > default : ShouldNotReachHere(); > break; > } > > > Please find v3 which fixes that issue in: > > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ > > Thank you. > > > Best regards, > Gustavo From gromero at linux.vnet.ibm.com Wed Oct 3 00:50:04 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 2 Oct 2018 21:50:04 -0300 Subject: [8u-dev] Request for approval for 8131048 and 8164920 Message-ID: <5b5605d6-9284-fc5a-0640-ee3b0c5ef8f0@linux.vnet.ibm.com> Hi, Could the following backports be approved please? "8131048: ppc: implement CRC32 intrinsic" Bug : https://bugs.openjdk.java.net/browse/JDK-8131048 jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3b81bc9fe683 "8164920: ppc: enhancement of CRC32 intrinsic" Bug : https://bugs.openjdk.java.net/browse/JDK-8164920 jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ebbfdf26a4ee Both changes do not apply cleanly to jdk8u and a few adjustments were necessary regarding the file path structure changes from 8 to 9, CPU feature detection (has_vpmsumb), and the C calling convention on PPC64. 8131048 and 8164920 backports have been reviewed by Goetz on hotspot-compiler-dev: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html OpenJDK 8u backport webrev: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ The backports in question are important for the performance of some Apache Cassandra workloads on PPC64. For instance, YCSB improves throughput by 19%. The 8131048 backport touches shared code but in effect is PPC64-only. Thank you. Best regards, Gustavo PS: I understand that the request for approval for 8u is still done through email and not by setting a proper *-fix-request label in the JBS like it happens for 10, 11, and above, as described in [1]. [1] http://openjdk.java.net/projects/jdk-updates/approval.html From david.buck at oracle.com Wed Oct 3 02:17:48 2018 From: david.buck at oracle.com (David Buck) Date: Wed, 3 Oct 2018 11:17:48 +0900 Subject: [8u-dev] Request for approval for 8131048 and 8164920 In-Reply-To: <5b5605d6-9284-fc5a-0640-ee3b0c5ef8f0@linux.vnet.ibm.com> References: <5b5605d6-9284-fc5a-0640-ee3b0c5ef8f0@linux.vnet.ibm.com> Message-ID: <7b1da16e-c1c1-5b0b-3914-1625108d7fcc@oracle.com> Hi Gustavo! Would you please file an enhancement backport approval request? http://openjdk.java.net/projects/jdk8u/enhancement-template.html Cheers, -Buck On 2018/10/03 9:50, Gustavo Romero wrote: > Hi, > > Could the following backports be approved please? > > "8131048: ppc: implement CRC32 intrinsic" > Bug?????????? : https://bugs.openjdk.java.net/browse/JDK-8131048 > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3b81bc9fe683 > > "8164920: ppc: enhancement of CRC32 intrinsic" > Bug?????????? : https://bugs.openjdk.java.net/browse/JDK-8164920 > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ebbfdf26a4ee > > Both changes do not apply cleanly to jdk8u and a few adjustments were > necessary > regarding the file path structure changes from 8 to 9, CPU feature > detection > (has_vpmsumb), and the C calling convention on PPC64. > > 8131048 and 8164920 backports have been reviewed by Goetz on > hotspot-compiler-dev: > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html > > > OpenJDK 8u backport webrev: > > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ > > The backports in question are important for the performance of some Apache > Cassandra workloads on PPC64. For instance, YCSB improves throughput by > 19%. > > The 8131048 backport touches shared code but in effect is PPC64-only. > > Thank you. > > > Best regards, > Gustavo > > PS: I understand that the request for approval for 8u is still done through > email and not by setting a proper *-fix-request label in the JBS like it > happens > for 10, 11, and above, as described in [1]. > > [1] http://openjdk.java.net/projects/jdk-updates/approval.html > From prasadarao.koppula at oracle.com Wed Oct 3 08:50:52 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Wed, 3 Oct 2018 08:50:52 +0000 (UTC) Subject: RFA [8u] 8211430: LDAPS communication failure with jdk 1.8.0_181 Message-ID: Hi, Could you approve to push this straight backport of the following JDK 12 fix: bug report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208211430"https://bugs.openjdk.java.net/browse/JDK- 8211430 code review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055806.html Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ Thanks, Prasad.K From sean.coffey at oracle.com Wed Oct 3 08:54:47 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 3 Oct 2018 09:54:47 +0100 Subject: RFA [8u] 8211430: LDAPS communication failure with jdk 1.8.0_181 In-Reply-To: References: Message-ID: <92edaf38-098d-0d91-a85f-671a033028a8@oracle.com> Approved. regards, Sean. On 03/10/2018 09:50, Prasadrao Koppula wrote: > Hi, > > > > Could you approve to push this straight backport of the following JDK 12 fix: > > > > bug report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208211430"https://bugs.openjdk.java.net/browse/JDK- 8211430 > > code review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055806.html > > Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ > > > > Thanks, > Prasad.K > > From prasadarao.koppula at oracle.com Wed Oct 3 08:55:44 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Wed, 3 Oct 2018 08:55:44 +0000 (UTC) Subject: RFA [8u] 8211430: LDAPS communication failure with jdk 1.8.0_181 In-Reply-To: <92edaf38-098d-0d91-a85f-671a033028a8@oracle.com> References: <92edaf38-098d-0d91-a85f-671a033028a8@oracle.com> Message-ID: <816b056d-8488-4fb4-9d66-dc929cef36e1@default> Thanks Sean. Thanks, Prasad.K -----Original Message----- From: Se?n Coffey Sent: Wednesday, October 03, 2018 2:25 PM To: Prasadrao Koppula ; jdk8u-dev at openjdk.java.net Subject: Re: RFA [8u] 8211430: LDAPS communication failure with jdk 1.8.0_181 Approved. regards, Sean. On 03/10/2018 09:50, Prasadrao Koppula wrote: > Hi, > > > > Could you approve to push this straight backport of the following JDK 12 fix: > > > > bug report: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-%208211430"https://bugs.openjdk.java.net/browse/JDK- 8211430 > > code review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055806.html > > Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ > > > > Thanks, > Prasad.K > > From dmitry.markov at oracle.com Wed Oct 3 09:42:05 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 3 Oct 2018 10:42:05 +0100 Subject: [8u] RFR: 8210891: Remove unused extutil.h from JDK8u sources Message-ID: <3DFDC07A-23A4-4557-B519-8DB8D1930039@oracle.com> Hello, Could you review the following fix, please? bug: https://bugs.openjdk.java.net/browse/JDK-8210891 webrev: http://cr.openjdk.java.net/~dmarkov/8210891/webrev.00/ Removed extutil.h and updated TPRMs accordingly. Thanks in advance, Dmitry From sean.coffey at oracle.com Wed Oct 3 14:54:59 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 3 Oct 2018 15:54:59 +0100 Subject: Tagging proposal for JDK GA releases Message-ID: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> I'd like to propose an enhancement to the JDK build-tagging convention to help users more easily identify JDK GA releases via Mercurial tag names. The concept is quite simple and lets people identify snapshots of GA releases in Mercurial history without having to know the build number of the GA release. For example, to obtain JDK 10.0.2 GA sources today, one issues the `hg update -r jdk-10.0.2+13` command. With the proposed enhancement, `hg update -r jdk-10.0.2-ga` could have been used. It's proposed that the new ga tag would be in addition to the regular GA build number tag. It would be added to the relevant repository once the GA milestone has been reached. This new convention would be used for future JDK releases and is tracked via JDK-8180946[1]. If the changes are adopted, I can look at retroactively adding labels for all feature JDK GA releases since JDK 7 to the JDK feature-release main-line repository. To accommodate the new tag format, some simple jcheck edits would be required. Test checks would also be added. Comments? regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8180946 From hohensee at amazon.com Wed Oct 3 15:25:18 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 3 Oct 2018 15:25:18 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> We at Amazon would find this useful. Thanks, Paul ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" wrote: I'd like to propose an enhancement to the JDK build-tagging convention to help users more easily identify JDK GA releases via Mercurial tag names. The concept is quite simple and lets people identify snapshots of GA releases in Mercurial history without having to know the build number of the GA release. For example, to obtain JDK 10.0.2 GA sources today, one issues the `hg update -r jdk-10.0.2+13` command. With the proposed enhancement, `hg update -r jdk-10.0.2-ga` could have been used. It's proposed that the new ga tag would be in addition to the regular GA build number tag. It would be added to the relevant repository once the GA milestone has been reached. This new convention would be used for future JDK releases and is tracked via JDK-8180946[1]. If the changes are adopted, I can look at retroactively adding labels for all feature JDK GA releases since JDK 7 to the JDK feature-release main-line repository. To accommodate the new tag format, some simple jcheck edits would be required. Test checks would also be added. Comments? regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8180946 From martijnverburg at gmail.com Wed Oct 3 15:43:14 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 3 Oct 2018 16:43:14 +0100 Subject: Tagging proposal for JDK GA releases In-Reply-To: <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> Message-ID: Likewise at Adopt Cheers, Martijn On Wed, 3 Oct 2018 at 16:26, Hohensee, Paul wrote: > We at Amazon would find this useful. > > Thanks, > > Paul > > ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" < > jdk-updates-dev-bounces at openjdk.java.net on behalf of > sean.coffey at oracle.com> wrote: > > I'd like to propose an enhancement to the JDK build-tagging > convention to help users more easily identify JDK GA releases > via Mercurial tag names. > > The concept is quite simple and lets people identify snapshots > of GA releases in Mercurial history without having to know the > build number of the GA release. > > For example, to obtain JDK 10.0.2 GA sources today, one issues the > `hg update -r jdk-10.0.2+13` command. With the proposed > enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > It's proposed that the new ga tag would be in addition to the regular > GA build number tag. It would be added to the relevant repository > once the GA milestone has been reached. > > This new convention would be used for future JDK releases and is > tracked via JDK-8180946[1]. If the changes are adopted, I can > look at retroactively adding labels for all feature JDK GA releases > since JDK 7 to the JDK feature-release main-line repository. > > To accommodate the new tag format, some simple jcheck edits > would be required. Test checks would also be added. > > Comments? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > > > From gromero at linux.vnet.ibm.com Wed Oct 3 15:59:06 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 3 Oct 2018 12:59:06 -0300 Subject: [8u-dev] Request for approval for 8131048 and 8164920 In-Reply-To: <7b1da16e-c1c1-5b0b-3914-1625108d7fcc@oracle.com> References: <5b5605d6-9284-fc5a-0640-ee3b0c5ef8f0@linux.vnet.ibm.com> <7b1da16e-c1c1-5b0b-3914-1625108d7fcc@oracle.com> Message-ID: Hi David! On 10/02/2018 11:17 PM, David Buck wrote: > Hi Gustavo! > > Would you please file an enhancement backport approval request? > > http://openjdk.java.net/projects/jdk8u/enhancement-template.html Sure! Thanks. Cheers, Gustavo > Cheers, > -Buck > > On 2018/10/03 9:50, Gustavo Romero wrote: >> Hi, >> >> Could the following backports be approved please? >> >> "8131048: ppc: implement CRC32 intrinsic" >> Bug?????????? : https://bugs.openjdk.java.net/browse/JDK-8131048 >> jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3b81bc9fe683 >> >> "8164920: ppc: enhancement of CRC32 intrinsic" >> Bug?????????? : https://bugs.openjdk.java.net/browse/JDK-8164920 >> jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ebbfdf26a4ee >> >> Both changes do not apply cleanly to jdk8u and a few adjustments were necessary >> regarding the file path structure changes from 8 to 9, CPU feature detection >> (has_vpmsumb), and the C calling convention on PPC64. >> >> 8131048 and 8164920 backports have been reviewed by Goetz on hotspot-compiler-dev: >> >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html >> >> OpenJDK 8u backport webrev: >> >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ >> >> The backports in question are important for the performance of some Apache >> Cassandra workloads on PPC64. For instance, YCSB improves throughput by 19%. >> >> The 8131048 backport touches shared code but in effect is PPC64-only. >> >> Thank you. >> >> >> Best regards, >> Gustavo >> >> PS: I understand that the request for approval for 8u is still done through >> email and not by setting a proper *-fix-request label in the JBS like it happens >> for 10, 11, and above, as described in [1]. >> >> [1] http://openjdk.java.net/projects/jdk-updates/approval.html >> > From gromero at linux.vnet.ibm.com Wed Oct 3 16:00:43 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 3 Oct 2018 13:00:43 -0300 Subject: [8u-dev] Request for enhancement backport approval for CR JDK-8131048 and JDK-8164920 Message-ID: Hi, I'd like to request an enhancement backport approval for JDK-8131048 [1] and JDK-8164920 [2] which will add support for CRC32 intrinsics on PPC64. Adding support for the CRC32 intrinsics on PPC64 would be highly beneficial and important for the performance of several workloads relying on CRC32 methods and it's specially important for some Apache Cassandra workloads on PPC64. For instance, YCSB benchmark improves its throughput by 19 % when the CRC32 intrinsics are enabled. The risk involved is low and it affects only the PPC64 platform. JDK-8131048 and JDK-8164920 backports have been reviewed by Goetz Lindenmaier on hotspot-compiler-dev ML [3]. The changes were tested on PPC64 LE / Linux, PPC64 BE / Linux, and PPC64 BE / AIX. No regression was observed. The webrevs for OpenJDK 8u can be found in: "8131048: ppc: implement CRC32 intrinsic" http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ "8164920: ppc: enhancement of CRC32 intrinsic" http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ Thank you. Best regards, Gustavo [1] https://bugs.openjdk.java.net/browse/JDK-8131048 [2] https://bugs.openjdk.java.net/browse/JDK-8164920 [3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html From sean.coffey at oracle.com Wed Oct 3 16:29:05 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 3 Oct 2018 17:29:05 +0100 Subject: [8u] RFR: 8210891: Remove unused extutil.h from JDK8u sources In-Reply-To: <3DFDC07A-23A4-4557-B519-8DB8D1930039@oracle.com> References: <3DFDC07A-23A4-4557-B519-8DB8D1930039@oracle.com> Message-ID: Approved. Regards, Sean. On 03/10/18 10:42, Dmitry Markov wrote: > Hello, > > Could you review the following fix, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8210891 > webrev: http://cr.openjdk.java.net/~dmarkov/8210891/webrev.00/ > > Removed extutil.h and updated TPRMs accordingly. > > Thanks in advance, > Dmitry From philip.race at oracle.com Wed Oct 3 17:21:33 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 3 Oct 2018 10:21:33 -0700 Subject: [8u] RFR: 8210891: Remove unused extutil.h from JDK8u sources In-Reply-To: <3DFDC07A-23A4-4557-B519-8DB8D1930039@oracle.com> References: <3DFDC07A-23A4-4557-B519-8DB8D1930039@oracle.com> Message-ID: Approved. -phil. On 10/03/2018 02:42 AM, Dmitry Markov wrote: > Hello, > > Could you review the following fix, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8210891 > webrev: http://cr.openjdk.java.net/~dmarkov/8210891/webrev.00/ > > > Removed extutil.h and updated TPRMs accordingly. > > Thanks in advance, > Dmitry From krishna.addepalli at oracle.com Thu Oct 4 04:13:54 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 4 Oct 2018 09:43:54 +0530 Subject: [8u-dev] Request for approval for JDK-8208638 : Instead of circle rendered in appl window, but ellipse is produced in JEditorPane In-Reply-To: <3e8f61ef-2c4f-cf43-d3e2-f52c655e680d@oracle.com> References: <5BB24B59.5040809@oracle.com> <3e8f61ef-2c4f-cf43-d3e2-f52c655e680d@oracle.com> Message-ID: <1C5C37CF-C1D4-4B95-90F8-CC494DD44D71@oracle.com> Hi Sean, I have updated JDK-8208638 with jdk11u-fix-request label, and also provided the webrev (which is fortunately same as that of 12). Could you approve the back port request for 8u? Thanks, Krishna > On 02-Oct-2018, at 1:59 PM, Se?n Coffey wrote: > > I've been monitoring the recent fixes coming into jdk8u-dev. If/when the criteria for allowing fixes into the LTS Update releases is altered, I'll work with the assignees to ensure that applicable 11.0.x fixes are also pushed. > > regards, > Sean. > > > On 01/10/2018 17:29, Philip Race wrote: >> I'd go further .. it probably shouldn't go into 8u *without* a concurrent 11u backport. >> else (as others have pointed out) when you upgrade from 8u to 11u it regresses >> which is against a "big rule". >> >> -phil. >> >> On 10/1/18, 2:40 AM, Alan Bateman wrote: >>> On 28/09/2018 02:11, Krishna Addepalli wrote: >>>> Hi, >>>> Could you please approve the backport of the jdk12 fix to 8u-dev? >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208638 >>>> webrev: http://cr.openjdk.java.net/~kaddepalli/8208638/8udev/webrev/ >>>> The patch is same except for the path difference between jdk12 and jdk8u. >>>> JDk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/2105d8064ca2 >>>> JDK12 review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2018-September/008907.html >>>> >>> I'm not involved in JDK updates but a back port from JDK 12 to 8u does beg the question as to whether the change will also be backported to 11u. I see there is discussion on jdk-updates-dev about the approvals for 11u but in the mean time then maybe backport issues should be created to at least track what will otherwise be regressions moving from 8u to 11u. >>> >>> -Alan > From sean.coffey at oracle.com Thu Oct 4 07:59:26 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 4 Oct 2018 08:59:26 +0100 Subject: [8u-dev] Request for approval for JDK-8208638 : Instead of circle rendered in appl window, but ellipse is produced in JEditorPane In-Reply-To: <1C5C37CF-C1D4-4B95-90F8-CC494DD44D71@oracle.com> References: <5BB24B59.5040809@oracle.com> <3e8f61ef-2c4f-cf43-d3e2-f52c655e680d@oracle.com> <1C5C37CF-C1D4-4B95-90F8-CC494DD44D71@oracle.com> Message-ID: <8371b429-a46a-af1c-a2b3-6cd12c2ed7ea@oracle.com> Approved for jdk8u-dev. Apologies for the delay - I thought I had approved earlier. regards, Sean. On 04/10/2018 05:13, Krishna Addepalli wrote: > Hi Sean, > > I have updated JDK-8208638 with jdk11u-fix-request label, and also provided the webrev (which is fortunately same as that of 12). > Could you approve the back port request for 8u? > > Thanks, > Krishna > >> On 02-Oct-2018, at 1:59 PM, Se?n Coffey wrote: >> >> I've been monitoring the recent fixes coming into jdk8u-dev. If/when the criteria for allowing fixes into the LTS Update releases is altered, I'll work with the assignees to ensure that applicable 11.0.x fixes are also pushed. >> >> regards, >> Sean. >> >> >> On 01/10/2018 17:29, Philip Race wrote: >>> I'd go further .. it probably shouldn't go into 8u *without* a concurrent 11u backport. >>> else (as others have pointed out) when you upgrade from 8u to 11u it regresses >>> which is against a "big rule". >>> >>> -phil. >>> >>> On 10/1/18, 2:40 AM, Alan Bateman wrote: >>>> On 28/09/2018 02:11, Krishna Addepalli wrote: >>>>> Hi, >>>>> Could you please approve the backport of the jdk12 fix to 8u-dev? >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208638 >>>>> webrev: http://cr.openjdk.java.net/~kaddepalli/8208638/8udev/webrev/ >>>>> The patch is same except for the path difference between jdk12 and jdk8u. >>>>> JDk12 changeset: http://hg.openjdk.java.net/jdk/client/rev/2105d8064ca2 >>>>> JDK12 review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2018-September/008907.html >>>>> >>>> I'm not involved in JDK updates but a back port from JDK 12 to 8u does beg the question as to whether the change will also be backported to 11u. I see there is discussion on jdk-updates-dev about the approvals for 11u but in the mean time then maybe backport issues should be created to at least track what will otherwise be regressions moving from 8u to 11u. >>>> >>>> -Alan From volker.simonis at gmail.com Thu Oct 4 08:15:44 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Oct 2018 11:15:44 +0300 Subject: Tagging proposal for JDK GA releases In-Reply-To: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: Sounds good! Thanks for driving this forward, Volker Se?n Coffey schrieb am Mi. 3. Okt. 2018 um 17:55: > I'd like to propose an enhancement to the JDK build-tagging > convention to help users more easily identify JDK GA releases > via Mercurial tag names. > > The concept is quite simple and lets people identify snapshots > of GA releases in Mercurial history without having to know the > build number of the GA release. > > For example, to obtain JDK 10.0.2 GA sources today, one issues the > `hg update -r jdk-10.0.2+13` command. With the proposed > enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > It's proposed that the new ga tag would be in addition to the regular > GA build number tag. It would be added to the relevant repository > once the GA milestone has been reached. > > This new convention would be used for future JDK releases and is > tracked via JDK-8180946[1]. If the changes are adopted, I can > look at retroactively adding labels for all feature JDK GA releases > since JDK 7 to the JDK feature-release main-line repository. > > To accommodate the new tag format, some simple jcheck edits > would be required. Test checks would also be added. > > Comments? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > From goetz.lindenmaier at sap.com Thu Oct 4 08:19:38 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 08:19:38 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> Message-ID: Hi, I also think this would make things more clear. I want to propose another point I stumbled about lately. You all know that if I do hg clone -r jdk-10.0.2-ga I get all the changes, but not the change that tags the version. I often check for the hash of the change tagging the release and clone that. Then I have a repo whose last change is the ga tag. Unfortunately recently, the tag comes later and is not directly applied to the change it wants to tag, but a few changes later. E.g., tag 12+14 is applied on top of "8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError" while it tags "Merge 8897e41b327c": http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 * Added tag jdk-12+14 for changeset 8897e41b327c | * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError | * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative | * 8211150: G1 Full GC not purging code root memory and hence causing memory leak | * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false | * 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI | * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF | * 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= | * Merge 8897e41b327c jdk-12+14 The following would be more convenient: *Merge | \ | * Added tag jdk-12+14 for changeset 8897e41b327c | | * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError | | * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative | | * | 8211150: G1 Full GC not purging code root memory and hence causing memory leak | | * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false | | * | 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI | | * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF | | * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= | / * Merge 8897e41b327c jdk-12+14 Which easily can be achieved by doing hg update -r 8897e41b327c (the merge change) before doing hg tag -f. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Mittwoch, 3. Oktober 2018 17:25 > To: Se?n Coffey ; jdk-dev dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- > dev at openjdk.java.net > Subject: Re: Tagging proposal for JDK GA releases > > We at Amazon would find this useful. > > Thanks, > > Paul > > ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" updates-dev-bounces at openjdk.java.net on behalf of > sean.coffey at oracle.com> wrote: > > I'd like to propose an enhancement to the JDK build-tagging > convention to help users more easily identify JDK GA releases > via Mercurial tag names. > > The concept is quite simple and lets people identify snapshots > of GA releases in Mercurial history without having to know the > build number of the GA release. > > For example, to obtain JDK 10.0.2 GA sources today, one issues the > `hg update -r jdk-10.0.2+13` command. With the proposed > enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > It's proposed that the new ga tag would be in addition to the regular > GA build number tag. It would be added to the relevant repository > once the GA milestone has been reached. > > This new convention would be used for future JDK releases and is > tracked via JDK-8180946[1]. If the changes are adopted, I can > look at retroactively adding labels for all feature JDK GA releases > since JDK 7 to the JDK feature-release main-line repository. > > To accommodate the new tag format, some simple jcheck edits > would be required. Test checks would also be added. > > Comments? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > From jesper.wilhelmsson at oracle.com Thu Oct 4 08:47:37 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 4 Oct 2018 10:47:37 +0200 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> Message-ID: <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> The proposal looks good to me. > On 4 Oct 2018, at 10:19, Lindenmaier, Goetz wrote: > > Hi, > > I also think this would make things more clear. > > I want to propose another point I stumbled about lately. > Sorry, my mistake. We are not supposed to tag merge changesets. I have re-tagged jdk-12+14 to a non-merge change. I would like to take the opportunity to highlight that the hg history would be a lot easier to work with if everyone remembers to rebase their changes before pushing. Then we would have a lot fewer merges in there. /Jesper > You all know that if I do hg clone -r jdk-10.0.2-ga > I get all the changes, but not the change that tags the version. > I often check for the hash of the change tagging the release > and clone that. Then I have a repo whose last change is the ga tag. > > Unfortunately recently, the tag comes later and is not directly > applied to the change it wants to tag, but a few changes later. E.g., > tag 12+14 is applied on top of "8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError" > while it tags "Merge 8897e41b327c": > http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 > > * Added tag jdk-12+14 for changeset 8897e41b327c > | > * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError > | > * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative > | > * 8211150: G1 Full GC not purging code root memory and hence causing memory leak > | > * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false > | > * 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI > | > * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > | > * 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= > | > * Merge 8897e41b327c jdk-12+14 > > The following would be more convenient: > > *Merge > | \ > | * Added tag jdk-12+14 for changeset 8897e41b327c > | | > * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError > | | > * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative > | | > * | 8211150: G1 Full GC not purging code root memory and hence causing memory leak > | | > * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false > | | > * | 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI > | | > * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > | | > * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= > | / > * Merge 8897e41b327c jdk-12+14 > > Which easily can be achieved by doing hg update -r 8897e41b327c (the merge change) > before doing hg tag -f. > > Best regards, > Goetz. > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Hohensee, Paul >> Sent: Mittwoch, 3. Oktober 2018 17:25 >> To: Se?n Coffey ; jdk-dev > dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >> dev at openjdk.java.net >> Subject: Re: Tagging proposal for JDK GA releases >> >> We at Amazon would find this useful. >> >> Thanks, >> >> Paul >> >> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" > updates-dev-bounces at openjdk.java.net on behalf of >> sean.coffey at oracle.com> wrote: >> >> I'd like to propose an enhancement to the JDK build-tagging >> convention to help users more easily identify JDK GA releases >> via Mercurial tag names. >> >> The concept is quite simple and lets people identify snapshots >> of GA releases in Mercurial history without having to know the >> build number of the GA release. >> >> For example, to obtain JDK 10.0.2 GA sources today, one issues the >> `hg update -r jdk-10.0.2+13` command. With the proposed >> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >> It's proposed that the new ga tag would be in addition to the regular >> GA build number tag. It would be added to the relevant repository >> once the GA milestone has been reached. >> >> This new convention would be used for future JDK releases and is >> tracked via JDK-8180946[1]. If the changes are adopted, I can >> look at retroactively adding labels for all feature JDK GA releases >> since JDK 7 to the JDK feature-release main-line repository. >> >> To accommodate the new tag format, some simple jcheck edits >> would be required. Test checks would also be added. >> >> Comments? >> >> regards, >> Sean. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >> > From goetz.lindenmaier at sap.com Thu Oct 4 09:09:55 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 09:09:55 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> Message-ID: <0a18f1ae2a20475ea782db906c24e2ae@sap.com> Hi Jesper, I didn't mean that the tag is on a Merge changeset, I didn't know that rule. What I mean is, in other words than in my mail below: I would like that the parent of the tag change is the change to be tagged. I know this means that there will be a merge, but it seems worth while. Best regards, Goetz. > -----Original Message----- > From: jesper.wilhelmsson at oracle.com > Sent: Donnerstag, 4. Oktober 2018 10:48 > To: Lindenmaier, Goetz > Cc: Hohensee, Paul ; Se?n Coffey > ; jdk-dev ; jdk- > updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: Tagging proposal for JDK GA releases > > The proposal looks good to me. > > > On 4 Oct 2018, at 10:19, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > I also think this would make things more clear. > > > > I want to propose another point I stumbled about lately. > > > > Sorry, my mistake. We are not supposed to tag merge changesets. > I have re-tagged jdk-12+14 to a non-merge change. > > I would like to take the opportunity to highlight that the hg history would be > a lot easier to work with if everyone remembers to rebase their changes > before pushing. Then we would have a lot fewer merges in there. > /Jesper > > > You all know that if I do hg clone -r jdk-10.0.2-ga > > I get all the changes, but not the change that tags the version. > > I often check for the hash of the change tagging the release > > and clone that. Then I have a repo whose last change is the ga tag. > > > > Unfortunately recently, the tag comes later and is not directly > > applied to the change it wants to tag, but a few changes later. E.g., > > tag 12+14 is applied on top of "8202359: [GRAAL] > compiler/uncommontrap/TestDeoptOOM.java failed with > OutOfMemoryError" > > while it tags "Merge 8897e41b327c": > > http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 > > > > * Added tag jdk-12+14 for changeset 8897e41b327c > > | > > * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed > with OutOfMemoryError > > | > > * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths > when directory is relative > > | > > * 8211150: G1 Full GC not purging code root memory and hence causing > memory leak > > | > > * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with > expected value: false > > | > > * 8211392: > compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times > out in JDK12 CI > > | > > * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > > | > > * 8211375: Minimal VM build failures after JDK-8211251 (Default mask > register for avx512 instructions)= > > | > > * Merge 8897e41b327c jdk-12+14 > > > > The following would be more convenient: > > > > *Merge > > | \ > > | * Added tag jdk-12+14 for changeset 8897e41b327c > > | | > > * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java > failed with OutOfMemoryError > > | | > > * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths > when directory is relative > > | | > > * | 8211150: G1 Full GC not purging code root memory and hence causing > memory leak > > | | > > * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with > expected value: false > > | | > > * | 8211392: > compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times > out in JDK12 CI > > | | > > * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > > | | > > * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask > register for avx512 instructions)= > > | / > > * Merge 8897e41b327c jdk-12+14 > > > > Which easily can be achieved by doing hg update -r 8897e41b327c (the > merge change) > > before doing hg tag -f. > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: jdk-updates-dev > On > >> Behalf Of Hohensee, Paul > >> Sent: Mittwoch, 3. Oktober 2018 17:25 > >> To: Se?n Coffey ; jdk-dev >> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- > >> dev at openjdk.java.net > >> Subject: Re: Tagging proposal for JDK GA releases > >> > >> We at Amazon would find this useful. > >> > >> Thanks, > >> > >> Paul > >> > >> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >> updates-dev-bounces at openjdk.java.net on behalf of > >> sean.coffey at oracle.com> wrote: > >> > >> I'd like to propose an enhancement to the JDK build-tagging > >> convention to help users more easily identify JDK GA releases > >> via Mercurial tag names. > >> > >> The concept is quite simple and lets people identify snapshots > >> of GA releases in Mercurial history without having to know the > >> build number of the GA release. > >> > >> For example, to obtain JDK 10.0.2 GA sources today, one issues the > >> `hg update -r jdk-10.0.2+13` command. With the proposed > >> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > >> It's proposed that the new ga tag would be in addition to the regular > >> GA build number tag. It would be added to the relevant repository > >> once the GA milestone has been reached. > >> > >> This new convention would be used for future JDK releases and is > >> tracked via JDK-8180946[1]. If the changes are adopted, I can > >> look at retroactively adding labels for all feature JDK GA releases > >> since JDK 7 to the JDK feature-release main-line repository. > >> > >> To accommodate the new tag format, some simple jcheck edits > >> would be required. Test checks would also be added. > >> > >> Comments? > >> > >> regards, > >> Sean. > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > >> > > From jesper.wilhelmsson at oracle.com Thu Oct 4 09:37:30 2018 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 4 Oct 2018 11:37:30 +0200 Subject: Tagging proposal for JDK GA releases In-Reply-To: <0a18f1ae2a20475ea782db906c24e2ae@sap.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> <0a18f1ae2a20475ea782db906c24e2ae@sap.com> Message-ID: > 4 okt. 2018 kl. 11:09 skrev Lindenmaier, Goetz : > > Hi Jesper, > > I didn't mean that the tag is on a Merge changeset, > I didn't know that rule. It?s more a guideline than a rule I guess. But I?ve heard it can cause issues in some cases. > What I mean is, in other words than in my mail below: > I would like that the parent of the tag change is the > change to be tagged. > I know this means that there will be a merge, but > it seems worth while. Has it been done this way in the past? I?ve only been tagging promoted builds for a short while, I may be missing some step that was part of the process before. /Jesper > Best regards, > Goetz. > >> -----Original Message----- >> From: jesper.wilhelmsson at oracle.com >> Sent: Donnerstag, 4. Oktober 2018 10:48 >> To: Lindenmaier, Goetz >> Cc: Hohensee, Paul ; Se?n Coffey >> ; jdk-dev ; jdk- >> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >> Subject: Re: Tagging proposal for JDK GA releases >> >> The proposal looks good to me. >> >>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz >> wrote: >>> >>> Hi, >>> >>> I also think this would make things more clear. >>> >>> I want to propose another point I stumbled about lately. >>> >> >> Sorry, my mistake. We are not supposed to tag merge changesets. >> I have re-tagged jdk-12+14 to a non-merge change. >> >> I would like to take the opportunity to highlight that the hg history would be >> a lot easier to work with if everyone remembers to rebase their changes >> before pushing. Then we would have a lot fewer merges in there. >> /Jesper >> >>> You all know that if I do hg clone -r jdk-10.0.2-ga >>> I get all the changes, but not the change that tags the version. >>> I often check for the hash of the change tagging the release >>> and clone that. Then I have a repo whose last change is the ga tag. >>> >>> Unfortunately recently, the tag comes later and is not directly >>> applied to the change it wants to tag, but a few changes later. E.g., >>> tag 12+14 is applied on top of "8202359: [GRAAL] >> compiler/uncommontrap/TestDeoptOOM.java failed with >> OutOfMemoryError" >>> while it tags "Merge 8897e41b327c": >>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 >>> >>> * Added tag jdk-12+14 for changeset 8897e41b327c >>> | >>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed >> with OutOfMemoryError >>> | >>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths >> when directory is relative >>> | >>> * 8211150: G1 Full GC not purging code root memory and hence causing >> memory leak >>> | >>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >> expected value: false >>> | >>> * 8211392: >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times >> out in JDK12 CI >>> | >>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>> | >>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask >> register for avx512 instructions)= >>> | >>> * Merge 8897e41b327c jdk-12+14 >>> >>> The following would be more convenient: >>> >>> *Merge >>> | \ >>> | * Added tag jdk-12+14 for changeset 8897e41b327c >>> | | >>> * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java >> failed with OutOfMemoryError >>> | | >>> * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths >> when directory is relative >>> | | >>> * | 8211150: G1 Full GC not purging code root memory and hence causing >> memory leak >>> | | >>> * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >> expected value: false >>> | | >>> * | 8211392: >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times >> out in JDK12 CI >>> | | >>> * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>> | | >>> * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask >> register for avx512 instructions)= >>> | / >>> * Merge 8897e41b327c jdk-12+14 >>> >>> Which easily can be achieved by doing hg update -r 8897e41b327c (the >> merge change) >>> before doing hg tag -f. >>> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: jdk-updates-dev >> On >>>> Behalf Of Hohensee, Paul >>>> Sent: Mittwoch, 3. Oktober 2018 17:25 >>>> To: Se?n Coffey ; jdk-dev >>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >>>> dev at openjdk.java.net >>>> Subject: Re: Tagging proposal for JDK GA releases >>>> >>>> We at Amazon would find this useful. >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >>> updates-dev-bounces at openjdk.java.net on behalf of >>>> sean.coffey at oracle.com> wrote: >>>> >>>> I'd like to propose an enhancement to the JDK build-tagging >>>> convention to help users more easily identify JDK GA releases >>>> via Mercurial tag names. >>>> >>>> The concept is quite simple and lets people identify snapshots >>>> of GA releases in Mercurial history without having to know the >>>> build number of the GA release. >>>> >>>> For example, to obtain JDK 10.0.2 GA sources today, one issues the >>>> `hg update -r jdk-10.0.2+13` command. With the proposed >>>> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >>>> It's proposed that the new ga tag would be in addition to the regular >>>> GA build number tag. It would be added to the relevant repository >>>> once the GA milestone has been reached. >>>> >>>> This new convention would be used for future JDK releases and is >>>> tracked via JDK-8180946[1]. If the changes are adopted, I can >>>> look at retroactively adding labels for all feature JDK GA releases >>>> since JDK 7 to the JDK feature-release main-line repository. >>>> >>>> To accommodate the new tag format, some simple jcheck edits >>>> would be required. Test checks would also be added. >>>> >>>> Comments? >>>> >>>> regards, >>>> Sean. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >>>> >>> > From goetz.lindenmaier at sap.com Thu Oct 4 09:44:19 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 09:44:19 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> <0a18f1ae2a20475ea782db906c24e2ae@sap.com> Message-ID: <9199693ea8174d7d89674323b9d5c4f1@sap.com> Hi I think before, when no-one committed to jdk/jdk because there were the hs/comp/gc etc repositories it happened by process. I.e., no changes were merged into the repo before the build was tagged. I think all the jdk10 tags have the tagged change for parent. This is no more the case since jdk11. Best regards, Goetz. > -----Original Message----- > From: Jesper Wilhelmsson > Sent: Donnerstag, 4. Oktober 2018 11:38 > To: Lindenmaier, Goetz > Cc: Hohensee, Paul ; Se?n Coffey > ; jdk-dev ; jdk- > updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: Tagging proposal for JDK GA releases > > > > > 4 okt. 2018 kl. 11:09 skrev Lindenmaier, Goetz > : > > > > Hi Jesper, > > > > I didn't mean that the tag is on a Merge changeset, > > I didn't know that rule. > > It?s more a guideline than a rule I guess. But I?ve heard it can cause issues in > some cases. > > > What I mean is, in other words than in my mail below: > > I would like that the parent of the tag change is the > > change to be tagged. > > I know this means that there will be a merge, but > > it seems worth while. > > Has it been done this way in the past? I?ve only been tagging promoted > builds for a short while, I may be missing some step that was part of the > process before. > /Jesper > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: jesper.wilhelmsson at oracle.com > > >> Sent: Donnerstag, 4. Oktober 2018 10:48 > >> To: Lindenmaier, Goetz > >> Cc: Hohensee, Paul ; Se?n Coffey > >> ; jdk-dev ; jdk- > >> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > >> Subject: Re: Tagging proposal for JDK GA releases > >> > >> The proposal looks good to me. > >> > >>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz > > >> wrote: > >>> > >>> Hi, > >>> > >>> I also think this would make things more clear. > >>> > >>> I want to propose another point I stumbled about lately. > >>> > >> > >> Sorry, my mistake. We are not supposed to tag merge changesets. > >> I have re-tagged jdk-12+14 to a non-merge change. > >> > >> I would like to take the opportunity to highlight that the hg history would > be > >> a lot easier to work with if everyone remembers to rebase their changes > >> before pushing. Then we would have a lot fewer merges in there. > >> /Jesper > >> > >>> You all know that if I do hg clone -r jdk-10.0.2-ga > >>> I get all the changes, but not the change that tags the version. > >>> I often check for the hash of the change tagging the release > >>> and clone that. Then I have a repo whose last change is the ga tag. > >>> > >>> Unfortunately recently, the tag comes later and is not directly > >>> applied to the change it wants to tag, but a few changes later. E.g., > >>> tag 12+14 is applied on top of "8202359: [GRAAL] > >> compiler/uncommontrap/TestDeoptOOM.java failed with > >> OutOfMemoryError" > >>> while it tags "Merge 8897e41b327c": > >>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 > >>> > >>> * Added tag jdk-12+14 for changeset 8897e41b327c > >>> | > >>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java > failed > >> with OutOfMemoryError > >>> | > >>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths > >> when directory is relative > >>> | > >>> * 8211150: G1 Full GC not purging code root memory and hence causing > >> memory leak > >>> | > >>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with > >> expected value: false > >>> | > >>> * 8211392: > >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java > times > >> out in JDK12 CI > >>> | > >>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > >>> | > >>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask > >> register for avx512 instructions)= > >>> | > >>> * Merge 8897e41b327c jdk-12+14 > >>> > >>> The following would be more convenient: > >>> > >>> *Merge > >>> | \ > >>> | * Added tag jdk-12+14 for changeset 8897e41b327c > >>> | | > >>> * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java > >> failed with OutOfMemoryError > >>> | | > >>> * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute > paths > >> when directory is relative > >>> | | > >>> * | 8211150: G1 Full GC not purging code root memory and hence > causing > >> memory leak > >>> | | > >>> * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with > >> expected value: false > >>> | | > >>> * | 8211392: > >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java > times > >> out in JDK12 CI > >>> | | > >>> * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > >>> | | > >>> * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask > >> register for avx512 instructions)= > >>> | / > >>> * Merge 8897e41b327c jdk-12+14 > >>> > >>> Which easily can be achieved by doing hg update -r 8897e41b327c (the > >> merge change) > >>> before doing hg tag -f. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: jdk-updates-dev bounces at openjdk.java.net> > >> On > >>>> Behalf Of Hohensee, Paul > >>>> Sent: Mittwoch, 3. Oktober 2018 17:25 > >>>> To: Se?n Coffey ; jdk-dev >>>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- > >>>> dev at openjdk.java.net > >>>> Subject: Re: Tagging proposal for JDK GA releases > >>>> > >>>> We at Amazon would find this useful. > >>>> > >>>> Thanks, > >>>> > >>>> Paul > >>>> > >>>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >>>> updates-dev-bounces at openjdk.java.net on behalf of > >>>> sean.coffey at oracle.com> wrote: > >>>> > >>>> I'd like to propose an enhancement to the JDK build-tagging > >>>> convention to help users more easily identify JDK GA releases > >>>> via Mercurial tag names. > >>>> > >>>> The concept is quite simple and lets people identify snapshots > >>>> of GA releases in Mercurial history without having to know the > >>>> build number of the GA release. > >>>> > >>>> For example, to obtain JDK 10.0.2 GA sources today, one issues the > >>>> `hg update -r jdk-10.0.2+13` command. With the proposed > >>>> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > >>>> It's proposed that the new ga tag would be in addition to the regular > >>>> GA build number tag. It would be added to the relevant repository > >>>> once the GA milestone has been reached. > >>>> > >>>> This new convention would be used for future JDK releases and is > >>>> tracked via JDK-8180946[1]. If the changes are adopted, I can > >>>> look at retroactively adding labels for all feature JDK GA releases > >>>> since JDK 7 to the JDK feature-release main-line repository. > >>>> > >>>> To accommodate the new tag format, some simple jcheck edits > >>>> would be required. Test checks would also be added. > >>>> > >>>> Comments? > >>>> > >>>> regards, > >>>> Sean. > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > >>>> > >>> > > From jesper.wilhelmsson at oracle.com Thu Oct 4 09:58:37 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 4 Oct 2018 11:58:37 +0200 Subject: Tagging proposal for JDK GA releases In-Reply-To: <9199693ea8174d7d89674323b9d5c4f1@sap.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> <0a18f1ae2a20475ea782db906c24e2ae@sap.com> <9199693ea8174d7d89674323b9d5c4f1@sap.com> Message-ID: <6B8C902C-F2BD-454C-9FB4-8F98EEF52A43@oracle.com> Hi Goetz, I see, so it was more by accident than on purpose it was that way before. Let's not hijack this thread with this discussion, it should be discussed as a separate suggestion. Personally I'm not in favor for adding more merge changesets but that doesn't mean I won't do it if there is a good reason for it. Thanks, /Jesper > On 4 Oct 2018, at 11:44, Lindenmaier, Goetz wrote: > > Hi > > I think before, when no-one committed to jdk/jdk because there were the hs/comp/gc etc > repositories it happened by process. I.e., no changes were merged into the repo > before the build was tagged. > > I think all the jdk10 tags have the tagged change for parent. > This is no more the case since jdk11. > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Jesper Wilhelmsson >> Sent: Donnerstag, 4. Oktober 2018 11:38 >> To: Lindenmaier, Goetz >> Cc: Hohensee, Paul ; Se?n Coffey >> ; jdk-dev ; jdk- >> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >> Subject: Re: Tagging proposal for JDK GA releases >> >> >> >>> 4 okt. 2018 kl. 11:09 skrev Lindenmaier, Goetz >> : >>> >>> Hi Jesper, >>> >>> I didn't mean that the tag is on a Merge changeset, >>> I didn't know that rule. >> >> It?s more a guideline than a rule I guess. But I?ve heard it can cause issues in >> some cases. >> >>> What I mean is, in other words than in my mail below: >>> I would like that the parent of the tag change is the >>> change to be tagged. >>> I know this means that there will be a merge, but >>> it seems worth while. >> >> Has it been done this way in the past? I?ve only been tagging promoted >> builds for a short while, I may be missing some step that was part of the >> process before. >> /Jesper >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: jesper.wilhelmsson at oracle.com >> >>>> Sent: Donnerstag, 4. Oktober 2018 10:48 >>>> To: Lindenmaier, Goetz >>>> Cc: Hohensee, Paul ; Se?n Coffey >>>> ; jdk-dev ; jdk- >>>> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >>>> Subject: Re: Tagging proposal for JDK GA releases >>>> >>>> The proposal looks good to me. >>>> >>>>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz >> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I also think this would make things more clear. >>>>> >>>>> I want to propose another point I stumbled about lately. >>>>> >>>> >>>> Sorry, my mistake. We are not supposed to tag merge changesets. >>>> I have re-tagged jdk-12+14 to a non-merge change. >>>> >>>> I would like to take the opportunity to highlight that the hg history would >> be >>>> a lot easier to work with if everyone remembers to rebase their changes >>>> before pushing. Then we would have a lot fewer merges in there. >>>> /Jesper >>>> >>>>> You all know that if I do hg clone -r jdk-10.0.2-ga >>>>> I get all the changes, but not the change that tags the version. >>>>> I often check for the hash of the change tagging the release >>>>> and clone that. Then I have a repo whose last change is the ga tag. >>>>> >>>>> Unfortunately recently, the tag comes later and is not directly >>>>> applied to the change it wants to tag, but a few changes later. E.g., >>>>> tag 12+14 is applied on top of "8202359: [GRAAL] >>>> compiler/uncommontrap/TestDeoptOOM.java failed with >>>> OutOfMemoryError" >>>>> while it tags "Merge 8897e41b327c": >>>>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 >>>>> >>>>> * Added tag jdk-12+14 for changeset 8897e41b327c >>>>> | >>>>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java >> failed >>>> with OutOfMemoryError >>>>> | >>>>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths >>>> when directory is relative >>>>> | >>>>> * 8211150: G1 Full GC not purging code root memory and hence causing >>>> memory leak >>>>> | >>>>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >>>> expected value: false >>>>> | >>>>> * 8211392: >>>> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java >> times >>>> out in JDK12 CI >>>>> | >>>>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>>>> | >>>>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask >>>> register for avx512 instructions)= >>>>> | >>>>> * Merge 8897e41b327c jdk-12+14 >>>>> >>>>> The following would be more convenient: >>>>> >>>>> *Merge >>>>> | \ >>>>> | * Added tag jdk-12+14 for changeset 8897e41b327c >>>>> | | >>>>> * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java >>>> failed with OutOfMemoryError >>>>> | | >>>>> * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute >> paths >>>> when directory is relative >>>>> | | >>>>> * | 8211150: G1 Full GC not purging code root memory and hence >> causing >>>> memory leak >>>>> | | >>>>> * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >>>> expected value: false >>>>> | | >>>>> * | 8211392: >>>> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java >> times >>>> out in JDK12 CI >>>>> | | >>>>> * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>>>> | | >>>>> * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask >>>> register for avx512 instructions)= >>>>> | / >>>>> * Merge 8897e41b327c jdk-12+14 >>>>> >>>>> Which easily can be achieved by doing hg update -r 8897e41b327c (the >>>> merge change) >>>>> before doing hg tag -f. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: jdk-updates-dev > bounces at openjdk.java.net> >>>> On >>>>>> Behalf Of Hohensee, Paul >>>>>> Sent: Mittwoch, 3. Oktober 2018 17:25 >>>>>> To: Se?n Coffey ; jdk-dev >>>>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: Tagging proposal for JDK GA releases >>>>>> >>>>>> We at Amazon would find this useful. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Paul >>>>>> >>>>>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >>>>> updates-dev-bounces at openjdk.java.net on behalf of >>>>>> sean.coffey at oracle.com> wrote: >>>>>> >>>>>> I'd like to propose an enhancement to the JDK build-tagging >>>>>> convention to help users more easily identify JDK GA releases >>>>>> via Mercurial tag names. >>>>>> >>>>>> The concept is quite simple and lets people identify snapshots >>>>>> of GA releases in Mercurial history without having to know the >>>>>> build number of the GA release. >>>>>> >>>>>> For example, to obtain JDK 10.0.2 GA sources today, one issues the >>>>>> `hg update -r jdk-10.0.2+13` command. With the proposed >>>>>> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >>>>>> It's proposed that the new ga tag would be in addition to the regular >>>>>> GA build number tag. It would be added to the relevant repository >>>>>> once the GA milestone has been reached. >>>>>> >>>>>> This new convention would be used for future JDK releases and is >>>>>> tracked via JDK-8180946[1]. If the changes are adopted, I can >>>>>> look at retroactively adding labels for all feature JDK GA releases >>>>>> since JDK 7 to the JDK feature-release main-line repository. >>>>>> >>>>>> To accommodate the new tag format, some simple jcheck edits >>>>>> would be required. Test checks would also be added. >>>>>> >>>>>> Comments? >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >>>>>> >>>>> >>> > From poonam.bajaj at oracle.com Thu Oct 4 16:19:00 2018 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Thu, 4 Oct 2018 09:19:00 -0700 Subject: [8u-dev] RFA: JDK-8211150: G1 Full GC not purging code root memory and hence causing memory leak Message-ID: Hello, Please approve this simple change for 8u-dev that fixes a memory leak during G1 Full GC cycles: Bug: https://bugs.openjdk.java.net/browse/JDK-8211150 12 Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/b16820c2336d webrev: http://cr.openjdk.java.net/~poonam/8211150/webrev.01/ Review-thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023373.html Thanks, Poonam From sgehwolf at redhat.com Thu Oct 4 16:48:50 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 04 Oct 2018 18:48:50 +0200 Subject: RFA: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling Message-ID: <0324a031df88f42303864c451d7ac6f2acc5e460.camel@redhat.com> Hi, Please approve this 8u backport request related to ppc64le. When using a ppc64le build from 8u and pulling in natives from Maven etc. users might end up getting ppc64 (BE) binaries because of the way the JDK reports itself to the user. Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ Review thread of this 8u change: http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023417.html The 8u change has been reviewed by David Holmes, Goetz Lindenmaier, Erik Joelsson. Not all changes from JDK 9 apply for the backport. Testing: Linux ppc64le/be builds and verifying os.arch property reports correctly. No change for ppc64be builds. Thanks, Severin From rob.mckenna at oracle.com Thu Oct 4 18:31:38 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 4 Oct 2018 19:31:38 +0100 Subject: [8u-dev] RFA: JDK-8211150: G1 Full GC not purging code root memory and hence causing memory leak In-Reply-To: References: Message-ID: <20181004183138.GA4091@vimes> Approved -Rob On 04/10/18 09:19, Poonam Parhar wrote: > Hello, > > Please approve this simple change for 8u-dev that fixes a memory leak during > G1 Full GC cycles: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211150 > 12 Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/b16820c2336d > webrev: http://cr.openjdk.java.net/~poonam/8211150/webrev.01/ > Review-thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023373.html > > > Thanks, > Poonam > From rob.mckenna at oracle.com Thu Oct 4 18:32:53 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 4 Oct 2018 19:32:53 +0100 Subject: RFA: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <0324a031df88f42303864c451d7ac6f2acc5e460.camel@redhat.com> References: <0324a031df88f42303864c451d7ac6f2acc5e460.camel@redhat.com> Message-ID: <20181004183253.GB4091@vimes> Approved -Rob On 04/10/18 18:48, Severin Gehwolf wrote: > Hi, > > Please approve this 8u backport request related to ppc64le. When using > a ppc64le build from 8u and pulling in natives from Maven etc. users > might end up getting ppc64 (BE) binaries because of the way the JDK > reports itself to the user. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ > > Review thread of this 8u change: > http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023417.html > > The 8u change has been reviewed by David Holmes, Goetz Lindenmaier, > Erik Joelsson. Not all changes from JDK 9 apply for the backport. > > Testing: Linux ppc64le/be builds and verifying os.arch property reports > correctly. No change for ppc64be builds. > > Thanks, > Severin > From sean.coffey at oracle.com Thu Oct 4 18:39:34 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 4 Oct 2018 19:39:34 +0100 Subject: [jdk8u-dev] Request for review and approval 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux Message-ID: <0a70ffce-fa91-bbec-3264-339dce10ce3d@oracle.com> I'd like to backport this fix to jdk8u-dev. The same change as JDK 12 is made. I'll create a backport record for 11 Updates. I? didn't remove SecureRandom import statement since it's still used in the JDK 8u test. JDK 12 changeset : http://hg.openjdk.java.net/jdk/jdk/rev/5f868838bc5f review thread : http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018198.html JDK 8u patch : diff --git a/test/javax/xml/crypto/dsig/GenerationTests.java b/test/javax/xml/crypto/dsig/GenerationTests.java --- a/test/javax/xml/crypto/dsig/GenerationTests.java +++ b/test/javax/xml/crypto/dsig/GenerationTests.java @@ -23,11 +23,12 @@ ?/** ? * @test - * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 8038349 8074784 + * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 + * 8038349 8074784 8210736 ? * @summary Basic unit tests for generating XML Signatures with JSR 105 ? * @compile -XDignore.symbol.file KeySelectors.java SignatureValidator.java ? *???? X509KeySelector.java GenerationTests.java - * @run main/othervm GenerationTests + * @run main/othervm -Dsun.net.httpserver.nodelay=true GenerationTests ? * @author Sean Mullan ? */ regards, Sean. From fairoz.matte at oracle.com Fri Oct 5 03:36:52 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Fri, 5 Oct 2018 03:36:52 +0000 (UTC) Subject: [8u-dev] RFA: 8163083: SocketListeningConnector does not allow invocations with port 0 Message-ID: <44332b48-ca0b-4c30-937f-8c544cc73880@default> Hi, Please approve the backport of JDK-8163083 to 8u-dev JBS issue - https://bugs.openjdk.java.net/browse/JDK-8163083 Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025366.html Thanks, Fairoz From manajit.halder at oracle.com Fri Oct 5 04:25:32 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Fri, 5 Oct 2018 09:55:32 +0530 Subject: Review request for backport of JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut In-Reply-To: <80a0af9c-96ed-d2d7-5b53-274f80a5a5c6@oracle.com> References: <3D3FF3F1-5736-4FE0-A55B-785AA1D05F09@oracle.com> <7e790df4-1049-0dfa-bc89-108124ec4f09@oracle.com> <80a0af9c-96ed-d2d7-5b53-274f80a5a5c6@oracle.com> Message-ID: <17bd0c2f-9db0-fcc2-af71-b40d9c018798@oracle.com> Thank you Sean. Regards, Manajit On 25/09/18 7:32 PM, Se?n Coffey wrote: > Looks fine to me also. > > regards, > Sean. > > > On 25/09/2018 10:51, Manajit Halder wrote: >> Hi All, >> >> Please review jdk8u-dev backport of issueJDK-8206392 >> . >> >> Received +1, need one more review from JDK8u reviewers. >> >> Regards, >> >> Manajit >> >> >> >> On 19/09/18 9:03 PM, Manajit Halder wrote: >>> Thanks Dmitry. >>> >>> Hi Sergey, >>> >>> Can you please review the jdk8u-dev backport. >>> >>> Regards, >>> >>> Manajit >>> >>> >>> On 19/09/18 2:53 PM, Dmitry Markov wrote: >>>> Hi Manajit, >>>> >>>> It looks good to me, but I am NOT JDK 8u reviewer. >>>> >>>> Thanks, >>>> Dmitry >>>> >>>>> On 18 Sep 2018, at 13:20, Manajit Halder >>>>> > wrote: >>>>> >>>>> Hi Dmitry, >>>>> >>>>> Please review the back port of JDK-8206392 to JDK8u-dev. Back port >>>>> is clean apart from removal of @key headful from test case. >>>>> >>>>> All the tests performed on the original fix were run on the back >>>>> port. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8206392 >>>>> >>>>> JDK8u-dev >>>>> webrev: >>>>> http://cr.openjdk.java.net/~mhalder/8206392-jdk8u-dev-backport/webrev.00/ >>>>> >>>>> >>>>> >>>>> JDK-12 approval mail: >>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014307.html >>>>> >>>>> >>>>> JDK-12 webrev: >>>>> http://cr.openjdk.java.net/~mhalder/8206392/webrev.00/ >>>>> >>>>> >>>>> Regards, >>>>> Manajit >>>>> >>>>> >>>> >>> >> > From sean.coffey at oracle.com Fri Oct 5 07:41:54 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Oct 2018 08:41:54 +0100 Subject: [8u-dev] RFA: 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <44332b48-ca0b-4c30-937f-8c544cc73880@default> References: <44332b48-ca0b-4c30-937f-8c544cc73880@default> Message-ID: <9714d7ef-d19a-1798-3679-67e7f7c83969@oracle.com> Approved. regards, Sean. On 05/10/2018 04:36, Fairoz Matte wrote: > Hi, > > Please approve the backport of JDK-8163083 to 8u-dev > > JBS issue - https://bugs.openjdk.java.net/browse/JDK-8163083 > Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ > Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025366.html > > Thanks, > Fairoz From sgehwolf at redhat.com Fri Oct 5 07:58:35 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 05 Oct 2018 09:58:35 +0200 Subject: RFA: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <20181004183253.GB4091@vimes> References: <0324a031df88f42303864c451d7ac6f2acc5e460.camel@redhat.com> <20181004183253.GB4091@vimes> Message-ID: <31fc1357907f7445b014ecc451c16e43b94e28b7.camel@redhat.com> On Thu, 2018-10-04 at 19:32 +0100, Rob McKenna wrote: > Approved Thanks, Rob! Cheers, Severin > -Rob > > On 04/10/18 18:48, Severin Gehwolf wrote: > > Hi, > > > > Please approve this 8u backport request related to ppc64le. When using > > a ppc64le build from 8u and pulling in natives from Maven etc. users > > might end up getting ppc64 (BE) binaries because of the way the JDK > > reports itself to the user. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ > > > > Review thread of this 8u change: > > http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023417.html > > > > The 8u change has been reviewed by David Holmes, Goetz Lindenmaier, > > Erik Joelsson. Not all changes from JDK 9 apply for the backport. > > > > Testing: Linux ppc64le/be builds and verifying os.arch property reports > > correctly. No change for ppc64be builds. > > > > Thanks, > > Severin > > From Alan.Bateman at oracle.com Fri Oct 5 08:10:00 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Oct 2018 09:10:00 +0100 Subject: [jdk8u-dev] Request for review and approval 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux In-Reply-To: <0a70ffce-fa91-bbec-3264-339dce10ce3d@oracle.com> References: <0a70ffce-fa91-bbec-3264-339dce10ce3d@oracle.com> Message-ID: On 04/10/2018 19:39, Se?n Coffey wrote: > I'd like to backport this fix to jdk8u-dev. The same change as JDK 12 > is made. I'll create a backport record for 11 Updates. > > I? didn't remove SecureRandom import statement since it's still used > in the JDK 8u test. > > JDK 12 changeset : http://hg.openjdk.java.net/jdk/jdk/rev/5f868838bc5f > review thread : > http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018198.html > > JDK 8u patch : > > diff --git a/test/javax/xml/crypto/dsig/GenerationTests.java > b/test/javax/xml/crypto/dsig/GenerationTests.java > --- a/test/javax/xml/crypto/dsig/GenerationTests.java > +++ b/test/javax/xml/crypto/dsig/GenerationTests.java > @@ -23,11 +23,12 @@ > > ?/** > ? * @test > - * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 > 8038349 8074784 > + * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 > + * 8038349 8074784 8210736 > ? * @summary Basic unit tests for generating XML Signatures with JSR 105 > ? * @compile -XDignore.symbol.file KeySelectors.java > SignatureValidator.java > ? *???? X509KeySelector.java GenerationTests.java > - * @run main/othervm GenerationTests > + * @run main/othervm -Dsun.net.httpserver.nodelay=true GenerationTests > ? * @author Sean Mullan > ? */ > I reviewed this test fix for Max on security-dev. The fix for jdk8u-dev looks okay too. -Alan. From dalibor.topic at oracle.com Fri Oct 5 08:41:23 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 5 Oct 2018 10:41:23 +0200 Subject: [jdk8u-dev] Request for review and approval 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux In-Reply-To: <0a70ffce-fa91-bbec-3264-339dce10ce3d@oracle.com> References: <0a70ffce-fa91-bbec-3264-339dce10ce3d@oracle.com> Message-ID: <21f6d83e-6dec-b116-9a79-597c06ec4485@oracle.com> Thanks, Sean. Approved! cheers, dalibor topic On 04.10.2018 20:39, Se?n Coffey wrote: > I'd like to backport this fix to jdk8u-dev. The same change as JDK 12 is > made. I'll create a backport record for 11 Updates. > > I? didn't remove SecureRandom import statement since it's still used in > the JDK 8u test. > > JDK 12 changeset : http://hg.openjdk.java.net/jdk/jdk/rev/5f868838bc5f > review thread : > http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018198.html > > > JDK 8u patch : > > diff --git a/test/javax/xml/crypto/dsig/GenerationTests.java > b/test/javax/xml/crypto/dsig/GenerationTests.java > --- a/test/javax/xml/crypto/dsig/GenerationTests.java > +++ b/test/javax/xml/crypto/dsig/GenerationTests.java > @@ -23,11 +23,12 @@ > > ?/** > ? * @test > - * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 8038349 > 8074784 > + * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 > + * 8038349 8074784 8210736 > ? * @summary Basic unit tests for generating XML Signatures with JSR 105 > ? * @compile -XDignore.symbol.file KeySelectors.java > SignatureValidator.java > ? *???? X509KeySelector.java GenerationTests.java > - * @run main/othervm GenerationTests > + * @run main/othervm -Dsun.net.httpserver.nodelay=true GenerationTests > ? * @author Sean Mullan > ? */ > > regards, > Sean. > -- 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 sean.coffey at oracle.com Fri Oct 5 10:15:30 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Oct 2018 11:15:30 +0100 Subject: RFA: 8044235: src.zip should include all sources In-Reply-To: <6a602d4d92deb4e0185c5ed3c6287e02ff98840a.camel@redhat.com> References: <6a602d4d92deb4e0185c5ed3c6287e02ff98840a.camel@redhat.com> Message-ID: Severin, this is approved for jdk8u-dev. Regards, Sean. On 27/09/18 13:20, Severin Gehwolf wrote: > Hi Sean, > > On Thu, 2018-09-27 at 12:42 +0100, Se?n Coffey wrote: >> Severin, >> >> this is an enhancement and as such should be accompanied by an >> enhancement backport approval template : >> >> http://openjdk.java.net/projects/jdk8u/enhancement-template.html >> >> I've long been a fan of bringing this back to jdk8u-dev also. This one >> is currently in review. In the interim, please log an enhancement >> request so that we can track such requests. > Thanks, done: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007919.html > > Cheers, > Severin > >> regards, >> Sean. >> >> >> On 26/09/2018 17:43, Severin Gehwolf wrote: >>> Hi, >>> >>> Please approve this backport request for 8044235 so as to include all >>> sources in src.zip produced by the build. It will only include all >>> sources when OPENJDK is defined. So it should be OK for Oracle JDK >>> builds. >>> >>> I should mention that this increases the size of src.zip from about >>> 25MB to 50MB. With that being said, src.zip is supposed to help Java >>> developers stepping through their code. Randomly omitting sources for >>> some classes while including others does not make a lot of sense. >>> OpenJDK is *open source* after all. We are in 2018 (do those extra 25MB >>> really matter?). Downstream consumers can remove src.zip from their >>> bundle if they're concerned about size. In Fedora, we have been using >>> this patch for years. There, src.zip is in a separate package so not >>> everybody gets it by default. Problem solved :) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044235 >>> >>> Patch is the same as for JDK 9: >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5cab03c4e5f9 >>> >>> Original review thread is here: >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-May/000785.html >>> >>> Thanks, >>> Severin >>> >> From sgehwolf at redhat.com Fri Oct 5 11:34:30 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 05 Oct 2018 13:34:30 +0200 Subject: RFA: 8044235: src.zip should include all sources In-Reply-To: References: <6a602d4d92deb4e0185c5ed3c6287e02ff98840a.camel@redhat.com> Message-ID: <338d14158f3982030667b5c1589ef6db16b768af.camel@redhat.com> On Fri, 2018-10-05 at 11:15 +0100, Se?n Coffey wrote: > Severin, > > this is approved for jdk8u-dev. Thanks, Sean! Cheers, Severin > Regards, > Sean. > > On 27/09/18 13:20, Severin Gehwolf wrote: > > Hi Sean, > > > > On Thu, 2018-09-27 at 12:42 +0100, Se?n Coffey wrote: > > > Severin, > > > > > > this is an enhancement and as such should be accompanied by an > > > enhancement backport approval template : > > > > > > http://openjdk.java.net/projects/jdk8u/enhancement-template.html > > > > > > I've long been a fan of bringing this back to jdk8u-dev also. This one > > > is currently in review. In the interim, please log an enhancement > > > request so that we can track such requests. > > > > Thanks, done: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007919.html > > > > Cheers, > > Severin > > > > > regards, > > > Sean. > > > > > > > > > On 26/09/2018 17:43, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Please approve this backport request for 8044235 so as to include all > > > > sources in src.zip produced by the build. It will only include all > > > > sources when OPENJDK is defined. So it should be OK for Oracle JDK > > > > builds. > > > > > > > > I should mention that this increases the size of src.zip from about > > > > 25MB to 50MB. With that being said, src.zip is supposed to help Java > > > > developers stepping through their code. Randomly omitting sources for > > > > some classes while including others does not make a lot of sense. > > > > OpenJDK is *open source* after all. We are in 2018 (do those extra 25MB > > > > really matter?). Downstream consumers can remove src.zip from their > > > > bundle if they're concerned about size. In Fedora, we have been using > > > > this patch for years. There, src.zip is in a separate package so not > > > > everybody gets it by default. Problem solved :) > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044235 > > > > > > > > Patch is the same as for JDK 9: > > > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5cab03c4e5f9 > > > > > > > > Original review thread is here: > > > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-May/000785.html > > > > > > > > Thanks, > > > > Severin > > > > > > From fairoz.matte at oracle.com Fri Oct 5 12:44:11 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Fri, 5 Oct 2018 12:44:11 +0000 (UTC) Subject: [8u-dev] RFA: 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <9714d7ef-d19a-1798-3679-67e7f7c83969@oracle.com> References: <44332b48-ca0b-4c30-937f-8c544cc73880@default> <9714d7ef-d19a-1798-3679-67e7f7c83969@oracle.com> Message-ID: <4fac41d5-43c2-450b-af08-ed9fb73c9b89@default> Thanks Sean, Thanks, Fairoz > -----Original Message----- > From: Se?n Coffey > Sent: Friday, October 05, 2018 1:12 PM > To: Fairoz Matte ; jdk8u-dev at openjdk.java.net > Subject: Re: [8u-dev] RFA: 8163083: SocketListeningConnector does not allow > invocations with port 0 > > Approved. > > regards, > Sean. > > > On 05/10/2018 04:36, Fairoz Matte wrote: > > Hi, > > > > Please approve the backport of JDK-8163083 to 8u-dev > > > > JBS issue - https://bugs.openjdk.java.net/browse/JDK-8163083 > > Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability- > dev/2018-October/025366.html > > > > Thanks, > > Fairoz > From gromero at linux.vnet.ibm.com Fri Oct 5 13:06:54 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 5 Oct 2018 10:06:54 -0300 Subject: [8u-dev] Request for enhancement backport approval for CR JDK-8131048 and JDK-8164920 In-Reply-To: References: Message-ID: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> Hi, Any news on that request? Please let me know if any bit of information is missing so I can provide it. Thanks. Best regards, Gustavo On 10/03/2018 01:00 PM, Gustavo Romero wrote: > Hi, > > I'd like to request an enhancement backport approval for JDK-8131048 [1] and > JDK-8164920 [2]? which will add support for CRC32 intrinsics on PPC64. > > Adding support for the CRC32 intrinsics on PPC64 would be highly beneficial and > important for the performance of several workloads relying on CRC32 methods and > it's specially important for some Apache Cassandra workloads on PPC64. For > instance, YCSB benchmark improves its throughput by 19 % when the CRC32 > intrinsics are enabled. > > The risk involved is low and it affects only the PPC64 platform. > > JDK-8131048 and JDK-8164920 backports have been reviewed by Goetz Lindenmaier > on hotspot-compiler-dev ML [3]. The changes were tested on PPC64 LE / Linux, > PPC64 BE / Linux, and PPC64 BE / AIX. No regression was observed. > > The webrevs for OpenJDK 8u can be found in: > > "8131048: ppc: implement CRC32 intrinsic" > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ > > "8164920: ppc: enhancement of CRC32 intrinsic" > http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ > > Thank you. > > > Best regards, > Gustavo > > [1] https://bugs.openjdk.java.net/browse/JDK-8131048 > [2] https://bugs.openjdk.java.net/browse/JDK-8164920 > [3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html > From rob.mckenna at oracle.com Fri Oct 5 14:41:08 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 5 Oct 2018 15:41:08 +0100 Subject: [8u-dev] Request for approval: 8205330 & 8210695 Message-ID: <20181005144108.GB2793@vimes> Hi folks, Looking for approval for: 8205330: InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection https://bugs.openjdk.java.net/browse/JDK-8205330 http://hg.openjdk.java.net/jdk/jdk/rev/f912267934e0 8210695: Create test to cover JDK-8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection https://bugs.openjdk.java.net/browse/JDK-8210695 http://hg.openjdk.java.net/jdk/jdk/rev/caac55d48dc3 Patches apply cleanly with the (trivial) exception of an externally defined variable in the try-with-resources block of the test in 8210695. -Rob From philip.race at oracle.com Fri Oct 5 14:41:46 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 05 Oct 2018 07:41:46 -0700 Subject: [8u-dev] Request for approval for JDK-8208638 : Instead of circle rendered in appl window, but ellipse is produced in JEditorPane In-Reply-To: <8371b429-a46a-af1c-a2b3-6cd12c2ed7ea@oracle.com> References: <5BB24B59.5040809@oracle.com> <3e8f61ef-2c4f-cf43-d3e2-f52c655e680d@oracle.com> <1C5C37CF-C1D4-4B95-90F8-CC494DD44D71@oracle.com> <8371b429-a46a-af1c-a2b3-6cd12c2ed7ea@oracle.com> Message-ID: <5BB7782A.3080809@oracle.com> Why is the 11u backport request is not yet approved ? I personally would not have pushed the 8u backport until the 11u one was approved as I think there should be a strict ordering to this. -phil. On 10/4/18, 12:59 AM, Se?n Coffey wrote: > Approved for jdk8u-dev. Apologies for the delay - I thought I had > approved earlier. > > regards, > Sean. > > > On 04/10/2018 05:13, Krishna Addepalli wrote: >> Hi Sean, >> >> I have updated JDK-8208638 with jdk11u-fix-request label, and also >> provided the webrev (which is fortunately same as that of 12). >> Could you approve the back port request for 8u? >> >> Thanks, >> Krishna >> >>> On 02-Oct-2018, at 1:59 PM, Se?n Coffey wrote: >>> >>> I've been monitoring the recent fixes coming into jdk8u-dev. If/when >>> the criteria for allowing fixes into the LTS Update releases is >>> altered, I'll work with the assignees to ensure that applicable >>> 11.0.x fixes are also pushed. >>> >>> regards, >>> Sean. >>> >>> >>> On 01/10/2018 17:29, Philip Race wrote: >>>> I'd go further .. it probably shouldn't go into 8u *without* a >>>> concurrent 11u backport. >>>> else (as others have pointed out) when you upgrade from 8u to 11u >>>> it regresses >>>> which is against a "big rule". >>>> >>>> -phil. >>>> >>>> On 10/1/18, 2:40 AM, Alan Bateman wrote: >>>>> On 28/09/2018 02:11, Krishna Addepalli wrote: >>>>>> Hi, >>>>>> Could you please approve the backport of the jdk12 fix to 8u-dev? >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208638 >>>>>> webrev: http://cr.openjdk.java.net/~kaddepalli/8208638/8udev/webrev/ >>>>>> The patch is same except for the path difference between jdk12 >>>>>> and jdk8u. >>>>>> JDk12 changeset: >>>>>> http://hg.openjdk.java.net/jdk/client/rev/2105d8064ca2 >>>>>> JDK12 review thread: >>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2018-September/008907.html >>>>>> >>>>> I'm not involved in JDK updates but a back port from JDK 12 to 8u >>>>> does beg the question as to whether the change will also be >>>>> backported to 11u. I see there is discussion on jdk-updates-dev >>>>> about the approvals for 11u but in the mean time then maybe >>>>> backport issues should be created to at least track what will >>>>> otherwise be regressions moving from 8u to 11u. >>>>> >>>>> -Alan > From rob.mckenna at oracle.com Fri Oct 5 15:00:09 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 5 Oct 2018 16:00:09 +0100 Subject: [8u-dev] RFR & RFA: 8202261 - (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space Message-ID: <20181005150009.GC2793@vimes> Hi folks, Looking for review / approval for: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space https://bugs.openjdk.java.net/browse/JDK-8202261 This webrev differs very slightly from the 12 changeset: http://cr.openjdk.java.net/~robm/8202261/webrev.01/ The (minor) differences are: 1) edits to the mapfiles 2) No setDirectIO bracket alteration in windows/classes/sun/nio/ch/FileDispatcherImpl.java JPRT builds & passes regression testing. -Rob From sean.coffey at oracle.com Fri Oct 5 15:10:50 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Oct 2018 16:10:50 +0100 Subject: [8u-dev] Request for approval: 8205330 & 8210695 In-Reply-To: <20181005144108.GB2793@vimes> References: <20181005144108.GB2793@vimes> Message-ID: Approved. Regards, Sean. On 05/10/18 15:41, Rob McKenna wrote: > Hi folks, > > Looking for approval for: > > 8205330: InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection > https://bugs.openjdk.java.net/browse/JDK-8205330 > http://hg.openjdk.java.net/jdk/jdk/rev/f912267934e0 > > 8210695: Create test to cover JDK-8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection > https://bugs.openjdk.java.net/browse/JDK-8210695 > http://hg.openjdk.java.net/jdk/jdk/rev/caac55d48dc3 > > Patches apply cleanly with the (trivial) exception of an externally defined > variable in the try-with-resources block of the test in 8210695. > > -Rob > From sean.coffey at oracle.com Fri Oct 5 15:10:59 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Oct 2018 16:10:59 +0100 Subject: [8u-dev] RFR & RFA: 8202261 - (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: <20181005150009.GC2793@vimes> References: <20181005150009.GC2793@vimes> Message-ID: Approved. Regards, Sean. On 05/10/18 16:00, Rob McKenna wrote: > Hi folks, > > Looking for review / approval for: > > 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space > https://bugs.openjdk.java.net/browse/JDK-8202261 > > This webrev differs very slightly from the 12 changeset: > > http://cr.openjdk.java.net/~robm/8202261/webrev.01/ > > The (minor) differences are: > > 1) edits to the mapfiles > 2) No setDirectIO bracket alteration in windows/classes/sun/nio/ch/FileDispatcherImpl.java > > JPRT builds & passes regression testing. > > -Rob > From sean.coffey at oracle.com Fri Oct 5 16:21:48 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Oct 2018 17:21:48 +0100 Subject: [8u-dev] Request for enhancement backport approval for CR JDK-8131048 and JDK-8164920 In-Reply-To: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> References: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> Message-ID: Thanks for the request Gustavo. I hope to have an answer for you shortly. Regards, Sean. On 05/10/18 14:06, Gustavo Romero wrote: > Hi, > > Any news on that request? > > Please let me know if any bit of information is missing so I can > provide it. > > Thanks. > > > Best regards, > Gustavo > > On 10/03/2018 01:00 PM, Gustavo Romero wrote: >> Hi, >> >> I'd like to request an enhancement backport approval for JDK-8131048 >> [1] and >> JDK-8164920 [2] which will add support for CRC32 intrinsics on PPC64. >> >> Adding support for the CRC32 intrinsics on PPC64 would be highly >> beneficial and >> important for the performance of several workloads relying on CRC32 >> methods and >> it's specially important for some Apache Cassandra workloads on >> PPC64. For >> instance, YCSB benchmark improves its throughput by 19 % when the CRC32 >> intrinsics are enabled. >> >> The risk involved is low and it affects only the PPC64 platform. >> >> JDK-8131048 and JDK-8164920 backports have been reviewed by Goetz >> Lindenmaier >> on hotspot-compiler-dev ML [3]. The changes were tested on PPC64 LE / >> Linux, >> PPC64 BE / Linux, and PPC64 BE / AIX. No regression was observed. >> >> The webrevs for OpenJDK 8u can be found in: >> >> "8131048: ppc: implement CRC32 intrinsic" >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ >> >> "8164920: ppc: enhancement of CRC32 intrinsic" >> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ >> >> Thank you. >> >> >> Best regards, >> Gustavo >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8131048 >> [2] https://bugs.openjdk.java.net/browse/JDK-8164920 >> [3] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html >> > From manajit.halder at oracle.com Tue Oct 9 04:26:29 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Tue, 9 Oct 2018 09:56:29 +0530 Subject: [8u-dev] Request for approval for backport of CR JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut Message-ID: Hi, Please approve the back port of 8206392 to 8u0dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8206392 JDK12 Change set: http://hg.openjdk.java.net/jdk/jdk/rev/cfbfa216f3c0 Since there was a minor change in the test file with jtreg tag, this back port code review was done in a separate thread. JDK8 Review thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/007962.html JDK8 Webrev: http://cr.openjdk.java.net/~mhalder/8206392-jdk8u-dev-backport/webrev.00/ Regards, Manajit From aph at redhat.com Tue Oct 9 08:42:50 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 9 Oct 2018 09:42:50 +0100 Subject: [8u-communication] JDK 8u202 planning In-Reply-To: <9abfe128-eb5d-d14b-625e-81b97bc3eb1b@oracle.com> References: <9abfe128-eb5d-d14b-625e-81b97bc3eb1b@oracle.com> Message-ID: <6a46d5fa-7061-57a9-1f7d-14a880537a53@redhat.com> On 09/28/2018 03:58 PM, Se?n Coffey wrote: > As per previous communications [1], Oracle doesn't plan to contribute > further changes to JDK 8 Updates in this OpenJDK Project beyond > January 2019. > > 8u202 is proposed to be the last Oracle led release for this OpenJDK > Project. A proposed timeline is as follows : > > - July 2018 8u-dev forest begins collecting 8u202 fixes > - Mid October 2018 RampDown 2 > - Mid January 2019 GA > > With the January 2019 release approaching the stabilization phase, fixes > in the master jdk8u forest on or before October 23rd will automatically > get included in the January 8u202 release. If I hear no objections to the > proposed timeline, I'll publish them on the Project page next week. > > While the January release ramps down for stabilization, discussion on this > mailing list can move to how best to transition this Project to a new set > of maintainers. That sounds good. I presume that Oracle supports ends the instant 8u202 is GA, so I'd hope that we could have a clean transition to a new project lead at exactly that moment. We also need to talk about how to build and distribute OpenJDK 8 binaries for releases after 8u202 GA. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Tue Oct 9 09:25:37 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Oct 2018 11:25:37 +0200 Subject: RFA: 8211387: [Zero] atomic_copy64: Use ldrexd for atomic reads on ARMv7 Message-ID: <626018f99fdd7be2dd8b19b96fa36c1c15608cc2.camel@redhat.com> Hi, Please approve this Zero JVM only change for 8u. It makes Zero use ldrexd for atomic reads on ARMv7. Since we build 8u Zero on ARM 32 in Fedora this is useful to us to get upstream. Patch is the same as for JDK 12, post path-unshuffeling. Bug: https://bugs.openjdk.java.net/browse/JDK-8211387 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/6ee9500fe653 Testing: bootcyle-images Zero builds on ARMv7. Thanks, Severin From martijnverburg at gmail.com Tue Oct 9 09:29:57 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 9 Oct 2018 10:29:57 +0100 Subject: [8u-communication] JDK 8u202 planning In-Reply-To: <6a46d5fa-7061-57a9-1f7d-14a880537a53@redhat.com> References: <9abfe128-eb5d-d14b-625e-81b97bc3eb1b@oracle.com> <6a46d5fa-7061-57a9-1f7d-14a880537a53@redhat.com> Message-ID: Hi Andrew / All, We're happy to get the AdoptOpenJDK Build Farm into the right state to produce those binaries. We're already producing OpenJDK 8 builds across all platforms but appreciate that the OpenJDK community may have extra requirements that we need to flesh out. Happy to start that conversation even if the post-Oracle lead for 8 updates isn't confirmed yet. Cheers, Martijn On Tue, 9 Oct 2018 at 09:43, Andrew Haley wrote: > On 09/28/2018 03:58 PM, Se?n Coffey wrote: > > As per previous communications [1], Oracle doesn't plan to contribute > > further changes to JDK 8 Updates in this OpenJDK Project beyond > > January 2019. > > > > 8u202 is proposed to be the last Oracle led release for this OpenJDK > > Project. A proposed timeline is as follows : > > > > - July 2018 8u-dev forest begins collecting 8u202 > fixes > > - Mid October 2018 RampDown 2 > > - Mid January 2019 GA > > > > With the January 2019 release approaching the stabilization phase, fixes > > in the master jdk8u forest on or before October 23rd will automatically > > get included in the January 8u202 release. If I hear no objections to the > > proposed timeline, I'll publish them on the Project page next week. > > > > While the January release ramps down for stabilization, discussion on > this > > mailing list can move to how best to transition this Project to a new set > > of maintainers. > > That sounds good. I presume that Oracle supports ends the instant 8u202 > is GA, so I'd hope that we could have a clean transition to a new project > lead at exactly that moment. > > We also need to talk about how to build and distribute OpenJDK 8 binaries > for releases after 8u202 GA. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From fairoz.matte at oracle.com Wed Oct 10 04:28:17 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Wed, 10 Oct 2018 04:28:17 +0000 (UTC) Subject: [8u-dev] RFA: JDK-8068440 and JDK-8073159 Message-ID: <66354368-6f71-4143-8c53-84908153fbd3@default> Hi, Please approve the backport of JDK-8068440 and JDK-8073159 to 8u-dev JBS bug - https://bugs.openjdk.java.net/browse/JDK-8068440 and https://bugs.openjdk.java.net/browse/JDK-8073159 Webrev - http://cr.openjdk.java.net/~fmatte/8068440/webrev.01/ Review thread - http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030887.html Thanks, Fairoz From david.buck at oracle.com Wed Oct 10 06:27:29 2018 From: david.buck at oracle.com (David Buck) Date: Wed, 10 Oct 2018 15:27:29 +0900 Subject: [8u-dev] RFA: JDK-8068440 and JDK-8073159 In-Reply-To: <66354368-6f71-4143-8c53-84908153fbd3@default> References: <66354368-6f71-4143-8c53-84908153fbd3@default> Message-ID: <646520b0-54a7-e146-4dab-bac83e2e5f33@oracle.com> approved Cheers, -Buck On 2018/10/10 13:28, Fairoz Matte wrote: > Hi, > > Please approve the backport of JDK-8068440 and JDK-8073159 to 8u-dev > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8068440 and > https://bugs.openjdk.java.net/browse/JDK-8073159 > > Webrev - http://cr.openjdk.java.net/~fmatte/8068440/webrev.01/ > > Review thread - http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030887.html > > Thanks, > Fairoz > From sean.coffey at oracle.com Wed Oct 10 08:29:21 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 10 Oct 2018 09:29:21 +0100 Subject: [8u-dev] Request for enhancement backport approval for CR JDK-8131048 and JDK-8164920 In-Reply-To: References: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> Message-ID: <4983a66c-3ce9-90bc-4604-36768ca66f5b@oracle.com> Gustavo, this is approved for jdk8u-dev. Regards, Sean. On 05/10/18 17:21, Se?n Coffey wrote: > Thanks for the request Gustavo. I hope to have an answer for you shortly. > > Regards, > Sean. > > On 05/10/18 14:06, Gustavo Romero wrote: >> Hi, >> >> Any news on that request? >> >> Please let me know if any bit of information is missing so I can >> provide it. >> >> Thanks. >> >> >> Best regards, >> Gustavo >> >> On 10/03/2018 01:00 PM, Gustavo Romero wrote: >>> Hi, >>> >>> I'd like to request an enhancement backport approval for JDK-8131048 >>> [1] and >>> JDK-8164920 [2] which will add support for CRC32 intrinsics on PPC64. >>> >>> Adding support for the CRC32 intrinsics on PPC64 would be highly >>> beneficial and >>> important for the performance of several workloads relying on CRC32 >>> methods and >>> it's specially important for some Apache Cassandra workloads on >>> PPC64. For >>> instance, YCSB benchmark improves its throughput by 19 % when the CRC32 >>> intrinsics are enabled. >>> >>> The risk involved is low and it affects only the PPC64 platform. >>> >>> JDK-8131048 and JDK-8164920 backports have been reviewed by Goetz >>> Lindenmaier >>> on hotspot-compiler-dev ML [3]. The changes were tested on PPC64 LE >>> / Linux, >>> PPC64 BE / Linux, and PPC64 BE / AIX. No regression was observed. >>> >>> The webrevs for OpenJDK 8u can be found in: >>> >>> "8131048: ppc: implement CRC32 intrinsic" >>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ >>> >>> "8164920: ppc: enhancement of CRC32 intrinsic" >>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ >>> >>> Thank you. >>> >>> >>> Best regards, >>> Gustavo >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8131048 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8164920 >>> [3] >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html >>> >> > From gromero at linux.vnet.ibm.com Wed Oct 10 13:11:30 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 10 Oct 2018 10:11:30 -0300 Subject: [8u-dev] Request for enhancement backport approval for CR JDK-8131048 and JDK-8164920 In-Reply-To: <4983a66c-3ce9-90bc-4604-36768ca66f5b@oracle.com> References: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> <4983a66c-3ce9-90bc-4604-36768ca66f5b@oracle.com> Message-ID: <9bc1191f-1fde-a9c5-46ea-ea64de8da5af@linux.vnet.ibm.com> Hi Sean, On 10/10/2018 05:29 AM, Se?n Coffey wrote: > Gustavo, > > this is approved for jdk8u-dev. Thank you so much. Do I need to trigger again a RFA (I did it before this RFE approval by mistake [1]), or this approval is already the final one and so it's ready to be pushed? Best regards, Gustavo [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/007934.html > Regards, > Sean. > > On 05/10/18 17:21, Se?n Coffey wrote: >> Thanks for the request Gustavo. I hope to have an answer for you shortly. >> >> Regards, >> Sean. >> >> On 05/10/18 14:06, Gustavo Romero wrote: >>> Hi, >>> >>> Any news on that request? >>> >>> Please let me know if any bit of information is missing so I can provide it. >>> >>> Thanks. >>> >>> >>> Best regards, >>> Gustavo >>> >>> On 10/03/2018 01:00 PM, Gustavo Romero wrote: >>>> Hi, >>>> >>>> I'd like to request an enhancement backport approval for JDK-8131048 [1] and >>>> JDK-8164920 [2] which will add support for CRC32 intrinsics on PPC64. >>>> >>>> Adding support for the CRC32 intrinsics on PPC64 would be highly beneficial and >>>> important for the performance of several workloads relying on CRC32 methods and >>>> it's specially important for some Apache Cassandra workloads on PPC64. For >>>> instance, YCSB benchmark improves its throughput by 19 % when the CRC32 >>>> intrinsics are enabled. >>>> >>>> The risk involved is low and it affects only the PPC64 platform. >>>> >>>> JDK-8131048 and JDK-8164920 backports have been reviewed by Goetz Lindenmaier >>>> on hotspot-compiler-dev ML [3]. The changes were tested on PPC64 LE / Linux, >>>> PPC64 BE / Linux, and PPC64 BE / AIX. No regression was observed. >>>> >>>> The webrevs for OpenJDK 8u can be found in: >>>> >>>> "8131048: ppc: implement CRC32 intrinsic" >>>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ >>>> >>>> "8164920: ppc: enhancement of CRC32 intrinsic" >>>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ >>>> >>>> Thank you. >>>> >>>> >>>> Best regards, >>>> Gustavo >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8131048 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8164920 >>>> [3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html >>>> >>> >> > From sgehwolf at redhat.com Wed Oct 10 15:03:40 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Oct 2018 17:03:40 +0200 Subject: RFA: 8208091: SA: jhsdb jstack --mixed throws UnmappedAddressException on i686 Message-ID: <4293f23526767e89f7c8d86e5b66d64b48366e53.camel@redhat.com> Hi, Please approve this 8u packport of JDK-8208091. In JDK 12 the command to trigger the bug is "jhsdb jstack --mixed". In JDK 8u the command is "jstack -m". The bug is the same, though. The actual fix is the same as in JDK 12 post path-unshuffeling. The testing infrastructure is rather different in JDK 8. There are hardly any serviceability tests. In order to keep changes to a stable release minimal the JDK 8u patch only inludes the fix. The test isn't 100% guaranteed to trigger the problem anyway. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8208091 JDK 8 patch: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8208091/JDK-8208091.jdk8.export.patch JDK 12 change: http://hg.openjdk.java.net/jdk/jdk/rev/2e98c7737d8f Thanks, Severin Prior the fix: # ./jdk-8u-prior-jstack-fix/bin/jstack -m 2339 Attaching to process ID 2339, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.71-b00 Deadlock Detection: No deadlocks found. ----------------- 2340 ----------------- 0xf7755430 ???????? ----------------- 2341 ----------------- 0xf7755430 ???????? ----------------- 2342 ----------------- 0xf7755430 ???????? ----------------- 2343 ----------------- 0xf7755430 ???????? ----------------- 2344 ----------------- 0xf7755430 ???????? ----------------- 2345 ----------------- 0xf7755430 ???????? ----------------- 2346 ----------------- 0xf7755430 ???????? ----------------- 2347 ----------------- 0xf7755430 ???????? sun.jvm.hotspot.debugger.UnmappedAddressException: f0 at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCInteger(LinuxDebuggerLocal.java:498) at sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readAddress(LinuxDebuggerLocal.java:433) at sun.jvm.hotspot.debugger.linux.LinuxAddress.getAddressAt(LinuxAddress.java:74) at sun.jvm.hotspot.debugger.linux.x86.LinuxX86CFrame.sender(LinuxX86CFrame.java:69) at sun.jvm.hotspot.tools.PStack.run(PStack.java:161) at sun.jvm.hotspot.tools.PStack.run(PStack.java:58) at sun.jvm.hotspot.tools.PStack.run(PStack.java:53) at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) at sun.tools.jstack.JStack.main(JStack.java:106) ----------------- 2348 ----------------- 0xf7755430 ???????? ----------------- 2349 ----------------- 0xf7755430 ???????? ----------------- 2350 ----------------- 0xf7755430 ???????? ----------------- 2351 ----------------- 0xf7755430 ???????? ----------------- 2339 ----------------- 0xf7755430 ???????? Post fix: $ ./jdk-8u-post-jstack-fix/bin/jstack -m 2339 Attaching to process ID 2339, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.71-b00 Deadlock Detection: No deadlocks found. ----------------- 2340 ----------------- 0xf7755430 ???????? ----------------- 2341 ----------------- 0xf7755430 ???????? ----------------- 2342 ----------------- 0xf7755430 ???????? ----------------- 2343 ----------------- 0xf7755430 ???????? ----------------- 2344 ----------------- 0xf7755430 ???????? ----------------- 2345 ----------------- 0xf7755430 ???????? ----------------- 2346 ----------------- 0xf7755430 ???????? ----------------- 2347 ----------------- 0xf7755430 ???????? ----------------- 2348 ----------------- 0xf7755430 ???????? ----------------- 2349 ----------------- 0xf7755430 ???????? ----------------- 2350 ----------------- 0xf7755430 ???????? ----------------- 2351 ----------------- 0xf7755430 ???????? ----------------- 2339 ----------------- 0xf7755430 ???????? From sean.coffey at oracle.com Wed Oct 10 15:27:20 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 10 Oct 2018 16:27:20 +0100 Subject: [8u-dev] Request for approval for CR JDK-8131048 and JDK-8164920 In-Reply-To: <9bc1191f-1fde-a9c5-46ea-ea64de8da5af@linux.vnet.ibm.com> References: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> <4983a66c-3ce9-90bc-4604-36768ca66f5b@oracle.com> <9bc1191f-1fde-a9c5-46ea-ea64de8da5af@linux.vnet.ibm.com> Message-ID: <0891f249-d21c-8da4-7f9d-31dd9a2d9a3e@oracle.com> I think we have all the information needed from your previous emails. I've adjusted the subject line in this email to "request for approval" Approved for pushing to jdk8u-dev. Regards, Sean. On 10/10/18 14:11, Gustavo Romero wrote: > Hi Sean, > > On 10/10/2018 05:29 AM, Se?n Coffey wrote: >> Gustavo, >> >> this is approved for jdk8u-dev. > > Thank you so much. > > Do I need to trigger again a RFA (I did it before this RFE approval by > mistake > [1]), or this approval is already the final one and so it's ready to > be pushed? > > > Best regards, > Gustavo > > [1] > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/007934.html > >> Regards, >> Sean. >> >> On 05/10/18 17:21, Se?n Coffey wrote: >>> Thanks for the request Gustavo. I hope to have an answer for you >>> shortly. >>> >>> Regards, >>> Sean. >>> >>> On 05/10/18 14:06, Gustavo Romero wrote: >>>> Hi, >>>> >>>> Any news on that request? >>>> >>>> Please let me know if any bit of information is missing so I can >>>> provide it. >>>> >>>> Thanks. >>>> >>>> >>>> Best regards, >>>> Gustavo >>>> >>>> On 10/03/2018 01:00 PM, Gustavo Romero wrote: >>>>> Hi, >>>>> >>>>> I'd like to request an enhancement backport approval for >>>>> JDK-8131048 [1] and >>>>> JDK-8164920 [2] which will add support for CRC32 intrinsics on >>>>> PPC64. >>>>> >>>>> Adding support for the CRC32 intrinsics on PPC64 would be highly >>>>> beneficial and >>>>> important for the performance of several workloads relying on >>>>> CRC32 methods and >>>>> it's specially important for some Apache Cassandra workloads on >>>>> PPC64. For >>>>> instance, YCSB benchmark improves its throughput by 19 % when the >>>>> CRC32 >>>>> intrinsics are enabled. >>>>> >>>>> The risk involved is low and it affects only the PPC64 platform. >>>>> >>>>> JDK-8131048 and JDK-8164920 backports have been reviewed by Goetz >>>>> Lindenmaier >>>>> on hotspot-compiler-dev ML [3]. The changes were tested on PPC64 >>>>> LE / Linux, >>>>> PPC64 BE / Linux, and PPC64 BE / AIX. No regression was observed. >>>>> >>>>> The webrevs for OpenJDK 8u can be found in: >>>>> >>>>> "8131048: ppc: implement CRC32 intrinsic" >>>>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ >>>>> >>>>> "8164920: ppc: enhancement of CRC32 intrinsic" >>>>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> Best regards, >>>>> Gustavo >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8131048 >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8164920 >>>>> [3] >>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html >>>>> >>>> >>> >> > From sean.coffey at oracle.com Wed Oct 10 15:30:55 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 10 Oct 2018 16:30:55 +0100 Subject: [8u-dev] Request for approval for backport of CR JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut In-Reply-To: References: Message-ID: <9f068708-e831-24f2-7f7e-2af62ba92fc5@oracle.com> Approved for jdk8u-dev. I've created an 11-pool record to track this issue also. Regards, Sean. On 09/10/18 05:26, Manajit Halder wrote: > Hi, > > Please approve the back port of 8206392 to 8u0dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8206392 > > > JDK12 Change set: http://hg.openjdk.java.net/jdk/jdk/rev/cfbfa216f3c0 > > Since there was a minor change in the test file with jtreg tag, this > back port code review was done in a separate thread. > > JDK8 Review thread: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/007962.html > > JDK8 Webrev: > http://cr.openjdk.java.net/~mhalder/8206392-jdk8u-dev-backport/webrev.00/ > > > > Regards, > Manajit > From sean.coffey at oracle.com Wed Oct 10 15:32:51 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 10 Oct 2018 16:32:51 +0100 Subject: RFA: 8211387: [Zero] atomic_copy64: Use ldrexd for atomic reads on ARMv7 In-Reply-To: <626018f99fdd7be2dd8b19b96fa36c1c15608cc2.camel@redhat.com> References: <626018f99fdd7be2dd8b19b96fa36c1c15608cc2.camel@redhat.com> Message-ID: <27e74049-1bcb-3a0d-62a7-b5f5b2aec6de@oracle.com> Please add an appropriate noreg- label to the master bug record. http://openjdk.java.net/guide/changePlanning.html#noreg Approved for jdk8u-dev. Regards, Sean. On 09/10/18 10:25, Severin Gehwolf wrote: > Hi, > > Please approve this Zero JVM only change for 8u. It makes Zero use > ldrexd for atomic reads on ARMv7. Since we build 8u Zero on ARM 32 in > Fedora this is useful to us to get upstream. Patch is the same as for > JDK 12, post path-unshuffeling. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211387 > changeset: http://hg.openjdk.java.net/jdk/jdk/rev/6ee9500fe653 > > Testing: bootcyle-images Zero builds on ARMv7. > > Thanks, > Severin > From rob.mckenna at oracle.com Wed Oct 10 15:35:03 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 10 Oct 2018 16:35:03 +0100 Subject: RFA: 8211387: [Zero] atomic_copy64: Use ldrexd for atomic reads on ARMv7 In-Reply-To: <626018f99fdd7be2dd8b19b96fa36c1c15608cc2.camel@redhat.com> References: <626018f99fdd7be2dd8b19b96fa36c1c15608cc2.camel@redhat.com> Message-ID: <20181010153503.GA4322@vimes> Approved -Rob On 09/10/18 11:25, Severin Gehwolf wrote: > Hi, > > Please approve this Zero JVM only change for 8u. It makes Zero use > ldrexd for atomic reads on ARMv7. Since we build 8u Zero on ARM 32 in > Fedora this is useful to us to get upstream. Patch is the same as for > JDK 12, post path-unshuffeling. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211387 > changeset: http://hg.openjdk.java.net/jdk/jdk/rev/6ee9500fe653 > > Testing: bootcyle-images Zero builds on ARMv7. > > Thanks, > Severin > From rob.mckenna at oracle.com Wed Oct 10 15:38:22 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 10 Oct 2018 16:38:22 +0100 Subject: RFA: 8208091: SA: jhsdb jstack --mixed throws UnmappedAddressException on i686 In-Reply-To: <4293f23526767e89f7c8d86e5b66d64b48366e53.camel@redhat.com> References: <4293f23526767e89f7c8d86e5b66d64b48366e53.camel@redhat.com> Message-ID: <20181010153822.GB4322@vimes> Hi Severin, Not totally comfortable with the lack of a test, but I do see why. Approved. -Rob On 10/10/18 17:03, Severin Gehwolf wrote: > Hi, > > Please approve this 8u packport of JDK-8208091. In JDK 12 the command > to trigger the bug is "jhsdb jstack --mixed". In JDK 8u the command is > "jstack -m". The bug is the same, though. The actual fix is the same as > in JDK 12 post path-unshuffeling. > > The testing infrastructure is rather different in JDK 8. There are > hardly any serviceability tests. In order to keep changes to a stable > release minimal the JDK 8u patch only inludes the fix. The test isn't > 100% guaranteed to trigger the problem anyway. Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208091 > JDK 8 patch: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8208091/JDK-8208091.jdk8.export.patch > JDK 12 change: http://hg.openjdk.java.net/jdk/jdk/rev/2e98c7737d8f > > Thanks, > Severin > > Prior the fix: > > # ./jdk-8u-prior-jstack-fix/bin/jstack -m 2339 > Attaching to process ID 2339, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 25.71-b00 > Deadlock Detection: > > No deadlocks found. > > ----------------- 2340 ----------------- > 0xf7755430 ???????? > ----------------- 2341 ----------------- > 0xf7755430 ???????? > ----------------- 2342 ----------------- > 0xf7755430 ???????? > ----------------- 2343 ----------------- > 0xf7755430 ???????? > ----------------- 2344 ----------------- > 0xf7755430 ???????? > ----------------- 2345 ----------------- > 0xf7755430 ???????? > ----------------- 2346 ----------------- > 0xf7755430 ???????? > ----------------- 2347 ----------------- > 0xf7755430 ???????? > sun.jvm.hotspot.debugger.UnmappedAddressException: f0 > at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) > at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) > at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) > at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCInteger(LinuxDebuggerLocal.java:498) > at sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) > at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readAddress(LinuxDebuggerLocal.java:433) > at sun.jvm.hotspot.debugger.linux.LinuxAddress.getAddressAt(LinuxAddress.java:74) > at sun.jvm.hotspot.debugger.linux.x86.LinuxX86CFrame.sender(LinuxX86CFrame.java:69) > at sun.jvm.hotspot.tools.PStack.run(PStack.java:161) > at sun.jvm.hotspot.tools.PStack.run(PStack.java:58) > at sun.jvm.hotspot.tools.PStack.run(PStack.java:53) > at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) > at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) > at sun.tools.jstack.JStack.main(JStack.java:106) > ----------------- 2348 ----------------- > 0xf7755430 ???????? > ----------------- 2349 ----------------- > 0xf7755430 ???????? > ----------------- 2350 ----------------- > 0xf7755430 ???????? > ----------------- 2351 ----------------- > 0xf7755430 ???????? > ----------------- 2339 ----------------- > 0xf7755430 ???????? > > Post fix: > > $ ./jdk-8u-post-jstack-fix/bin/jstack -m 2339 > Attaching to process ID 2339, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 25.71-b00 > Deadlock Detection: > > No deadlocks found. > > ----------------- 2340 ----------------- > 0xf7755430 ???????? > ----------------- 2341 ----------------- > 0xf7755430 ???????? > ----------------- 2342 ----------------- > 0xf7755430 ???????? > ----------------- 2343 ----------------- > 0xf7755430 ???????? > ----------------- 2344 ----------------- > 0xf7755430 ???????? > ----------------- 2345 ----------------- > 0xf7755430 ???????? > ----------------- 2346 ----------------- > 0xf7755430 ???????? > ----------------- 2347 ----------------- > 0xf7755430 ???????? > ----------------- 2348 ----------------- > 0xf7755430 ???????? > ----------------- 2349 ----------------- > 0xf7755430 ???????? > ----------------- 2350 ----------------- > 0xf7755430 ???????? > ----------------- 2351 ----------------- > 0xf7755430 ???????? > ----------------- 2339 ----------------- > 0xf7755430 ???????? > From sgehwolf at redhat.com Wed Oct 10 15:47:46 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Oct 2018 17:47:46 +0200 Subject: RFA: 8211387: [Zero] atomic_copy64: Use ldrexd for atomic reads on ARMv7 In-Reply-To: <27e74049-1bcb-3a0d-62a7-b5f5b2aec6de@oracle.com> References: <626018f99fdd7be2dd8b19b96fa36c1c15608cc2.camel@redhat.com> <27e74049-1bcb-3a0d-62a7-b5f5b2aec6de@oracle.com> Message-ID: Hi Sean, On Wed, 2018-10-10 at 16:32 +0100, Se?n Coffey wrote: > Please add an appropriate noreg- label to the master bug record. > > http://openjdk.java.net/guide/changePlanning.html#noreg I've added noreg-hard. > Approved for jdk8u-dev. Thanks! Cheers, Severin > Regards, > Sean. > > On 09/10/18 10:25, Severin Gehwolf wrote: > > Hi, > > > > Please approve this Zero JVM only change for 8u. It makes Zero use > > ldrexd for atomic reads on ARMv7. Since we build 8u Zero on ARM 32 in > > Fedora this is useful to us to get upstream. Patch is the same as for > > JDK 12, post path-unshuffeling. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211387 > > changeset: http://hg.openjdk.java.net/jdk/jdk/rev/6ee9500fe653 > > > > Testing: bootcyle-images Zero builds on ARMv7. > > > > Thanks, > > Severin > > > > From sgehwolf at redhat.com Wed Oct 10 16:01:52 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Oct 2018 18:01:52 +0200 Subject: RFA: 8208091: SA: jhsdb jstack --mixed throws UnmappedAddressException on i686 In-Reply-To: <20181010153822.GB4322@vimes> References: <4293f23526767e89f7c8d86e5b66d64b48366e53.camel@redhat.com> <20181010153822.GB4322@vimes> Message-ID: <8b472feda57a58e588aee5613641187a891cc02c.camel@redhat.com> On Wed, 2018-10-10 at 16:38 +0100, Rob McKenna wrote: > Hi Severin, > > Not totally comfortable with the lack of a test, but I do see why. > Approved. Thanks, Rob! Cheers, Severin > -Rob > > On 10/10/18 17:03, Severin Gehwolf wrote: > > Hi, > > > > Please approve this 8u packport of JDK-8208091. In JDK 12 the command > > to trigger the bug is "jhsdb jstack --mixed". In JDK 8u the command is > > "jstack -m". The bug is the same, though. The actual fix is the same as > > in JDK 12 post path-unshuffeling. > > > > The testing infrastructure is rather different in JDK 8. There are > > hardly any serviceability tests. In order to keep changes to a stable > > release minimal the JDK 8u patch only inludes the fix. The test isn't > > 100% guaranteed to trigger the problem anyway. Thoughts? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208091 > > JDK 8 patch: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8208091/JDK-8208091.jdk8.export.patch > > JDK 12 change: http://hg.openjdk.java.net/jdk/jdk/rev/2e98c7737d8f > > > > Thanks, > > Severin > > > > Prior the fix: > > > > # ./jdk-8u-prior-jstack-fix/bin/jstack -m 2339 > > Attaching to process ID 2339, please wait... > > Debugger attached successfully. > > Server compiler detected. > > JVM version is 25.71-b00 > > Deadlock Detection: > > > > No deadlocks found. > > > > ----------------- 2340 ----------------- > > 0xf7755430 ???????? > > ----------------- 2341 ----------------- > > 0xf7755430 ???????? > > ----------------- 2342 ----------------- > > 0xf7755430 ???????? > > ----------------- 2343 ----------------- > > 0xf7755430 ???????? > > ----------------- 2344 ----------------- > > 0xf7755430 ???????? > > ----------------- 2345 ----------------- > > 0xf7755430 ???????? > > ----------------- 2346 ----------------- > > 0xf7755430 ???????? > > ----------------- 2347 ----------------- > > 0xf7755430 ???????? > > sun.jvm.hotspot.debugger.UnmappedAddressException: f0 > > at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) > > at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) > > at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) > > at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCInteger(LinuxDebuggerLocal.java:498) > > at sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) > > at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readAddress(LinuxDebuggerLocal.java:433) > > at sun.jvm.hotspot.debugger.linux.LinuxAddress.getAddressAt(LinuxAddress.java:74) > > at sun.jvm.hotspot.debugger.linux.x86.LinuxX86CFrame.sender(LinuxX86CFrame.java:69) > > at sun.jvm.hotspot.tools.PStack.run(PStack.java:161) > > at sun.jvm.hotspot.tools.PStack.run(PStack.java:58) > > at sun.jvm.hotspot.tools.PStack.run(PStack.java:53) > > at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) > > at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) > > at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) > > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > > at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > > at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) > > at sun.tools.jstack.JStack.main(JStack.java:106) > > ----------------- 2348 ----------------- > > 0xf7755430 ???????? > > ----------------- 2349 ----------------- > > 0xf7755430 ???????? > > ----------------- 2350 ----------------- > > 0xf7755430 ???????? > > ----------------- 2351 ----------------- > > 0xf7755430 ???????? > > ----------------- 2339 ----------------- > > 0xf7755430 ???????? > > > > Post fix: > > > > $ ./jdk-8u-post-jstack-fix/bin/jstack -m 2339 > > Attaching to process ID 2339, please wait... > > Debugger attached successfully. > > Server compiler detected. > > JVM version is 25.71-b00 > > Deadlock Detection: > > > > No deadlocks found. > > > > ----------------- 2340 ----------------- > > 0xf7755430 ???????? > > ----------------- 2341 ----------------- > > 0xf7755430 ???????? > > ----------------- 2342 ----------------- > > 0xf7755430 ???????? > > ----------------- 2343 ----------------- > > 0xf7755430 ???????? > > ----------------- 2344 ----------------- > > 0xf7755430 ???????? > > ----------------- 2345 ----------------- > > 0xf7755430 ???????? > > ----------------- 2346 ----------------- > > 0xf7755430 ???????? > > ----------------- 2347 ----------------- > > 0xf7755430 ???????? > > ----------------- 2348 ----------------- > > 0xf7755430 ???????? > > ----------------- 2349 ----------------- > > 0xf7755430 ???????? > > ----------------- 2350 ----------------- > > 0xf7755430 ???????? > > ----------------- 2351 ----------------- > > 0xf7755430 ???????? > > ----------------- 2339 ----------------- > > 0xf7755430 ???????? > > From gromero at linux.vnet.ibm.com Wed Oct 10 16:04:39 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 10 Oct 2018 13:04:39 -0300 Subject: [8u-dev] Request for approval for CR JDK-8131048 and JDK-8164920 In-Reply-To: <0891f249-d21c-8da4-7f9d-31dd9a2d9a3e@oracle.com> References: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> <4983a66c-3ce9-90bc-4604-36768ca66f5b@oracle.com> <9bc1191f-1fde-a9c5-46ea-ea64de8da5af@linux.vnet.ibm.com> <0891f249-d21c-8da4-7f9d-31dd9a2d9a3e@oracle.com> Message-ID: <02d37f6e-4563-a605-37f7-467038d56a1c@linux.vnet.ibm.com> On 10/10/2018 12:27 PM, Se?n Coffey wrote: > I think we have all the information needed from your previous emails. I've adjusted the subject line in this email to "request for approval" > > Approved for pushing to jdk8u-dev. Thanks Sean. @Andrew, I'm wondering if you so kindly could please sponsor that change now it's approved. Thanks and best regards, Gustavo > Regards, > Sean. > > On 10/10/18 14:11, Gustavo Romero wrote: >> Hi Sean, >> >> On 10/10/2018 05:29 AM, Se?n Coffey wrote: >>> Gustavo, >>> >>> this is approved for jdk8u-dev. >> >> Thank you so much. >> >> Do I need to trigger again a RFA (I did it before this RFE approval by mistake >> [1]), or this approval is already the final one and so it's ready to be pushed? >> >> >> Best regards, >> Gustavo >> >> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/007934.html >> >>> Regards, >>> Sean. >>> >>> On 05/10/18 17:21, Se?n Coffey wrote: >>>> Thanks for the request Gustavo. I hope to have an answer for you shortly. >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 05/10/18 14:06, Gustavo Romero wrote: >>>>> Hi, >>>>> >>>>> Any news on that request? >>>>> >>>>> Please let me know if any bit of information is missing so I can provide it. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> Best regards, >>>>> Gustavo >>>>> >>>>> On 10/03/2018 01:00 PM, Gustavo Romero wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to request an enhancement backport approval for JDK-8131048 [1] and >>>>>> JDK-8164920 [2]? which will add support for CRC32 intrinsics on PPC64. >>>>>> >>>>>> Adding support for the CRC32 intrinsics on PPC64 would be highly beneficial and >>>>>> important for the performance of several workloads relying on CRC32 methods and >>>>>> it's specially important for some Apache Cassandra workloads on PPC64. For >>>>>> instance, YCSB benchmark improves its throughput by 19 % when the CRC32 >>>>>> intrinsics are enabled. >>>>>> >>>>>> The risk involved is low and it affects only the PPC64 platform. >>>>>> >>>>>> JDK-8131048 and JDK-8164920 backports have been reviewed by Goetz Lindenmaier >>>>>> on hotspot-compiler-dev ML [3]. The changes were tested on PPC64 LE / Linux, >>>>>> PPC64 BE / Linux, and PPC64 BE / AIX. No regression was observed. >>>>>> >>>>>> The webrevs for OpenJDK 8u can be found in: >>>>>> >>>>>> "8131048: ppc: implement CRC32 intrinsic" >>>>>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8131048/ >>>>>> >>>>>> "8164920: ppc: enhancement of CRC32 intrinsic" >>>>>> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v3/8164920/ >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Gustavo >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8131048 >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8164920 >>>>>> [3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030819.html >>>>>> >>>>> >>>> >>> >> > From aph at redhat.com Wed Oct 10 16:47:53 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Oct 2018 17:47:53 +0100 Subject: [8u-communication] JDK 8u202 planning In-Reply-To: References: <9abfe128-eb5d-d14b-625e-81b97bc3eb1b@oracle.com> <6a46d5fa-7061-57a9-1f7d-14a880537a53@redhat.com> Message-ID: On 10/09/2018 10:29 AM, Martijn Verburg wrote: > We're happy to get the AdoptOpenJDK Build Farm into the right state to > produce those binaries. We're already producing OpenJDK 8 builds across > all platforms but appreciate that the OpenJDK community may have extra > requirements that we need to flesh out. Testing, mostly. Do you really have the resources to do TCK testing, including interactive tests, on all builds? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martijnverburg at gmail.com Wed Oct 10 16:50:35 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 10 Oct 2018 17:50:35 +0100 Subject: [8u-communication] JDK 8u202 planning In-Reply-To: References: <9abfe128-eb5d-d14b-625e-81b97bc3eb1b@oracle.com> <6a46d5fa-7061-57a9-1f7d-14a880537a53@redhat.com> Message-ID: Hi Andrew, I strongly believe we will yes. We're going to use our upcoming 8u181 and 8u202 releases as trial runs to hone the scaffolding around the interactive tests. Cheers, Martijn On Wed, 10 Oct 2018 at 17:47, Andrew Haley wrote: > On 10/09/2018 10:29 AM, Martijn Verburg wrote: > > We're happy to get the AdoptOpenJDK Build Farm into the right state to > > produce those binaries. We're already producing OpenJDK 8 builds across > > all platforms but appreciate that the OpenJDK community may have extra > > requirements that we need to flesh out. > > Testing, mostly. Do you really have the resources to do TCK testing, > including interactive tests, on all builds? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From aph at redhat.com Wed Oct 10 17:03:20 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Oct 2018 18:03:20 +0100 Subject: [8u-communication] JDK 8u202 planning In-Reply-To: References: <9abfe128-eb5d-d14b-625e-81b97bc3eb1b@oracle.com> <6a46d5fa-7061-57a9-1f7d-14a880537a53@redhat.com> Message-ID: <9aa75738-bb66-6dce-ee1a-ef009f937487@redhat.com> On 10/10/2018 05:50 PM, Martijn Verburg wrote: > I strongly believe we will yes. We're going to use our upcoming 8u181 and > 8u202 releases as trial runs to hone the scaffolding around the interactive > tests. OK, so that's a possibility, if we can sort out the issues around embargoes and the related security issues. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Oct 11 13:46:59 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Oct 2018 14:46:59 +0100 Subject: OEL version used to build JDK 8? Message-ID: <376add08-5d95-a9cd-70c8-768a3e3f7484@redhat.com> As I understand it, Oracle uses an older version of OEL to build the portable Linux binaries of JDK 8. What version is that? Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Thu Oct 11 14:05:48 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Oct 2018 16:05:48 +0200 Subject: OEL version used to build JDK 8? In-Reply-To: <376add08-5d95-a9cd-70c8-768a3e3f7484@redhat.com> References: <376add08-5d95-a9cd-70c8-768a3e3f7484@redhat.com> Message-ID: You can find the Oracle build platforms in the OpenJDK Wiki: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms On Thu, Oct 11, 2018 at 3:47 PM Andrew Haley wrote: > > As I understand it, Oracle uses an older version of OEL to build the > portable Linux binaries of JDK 8. What version is that? Thanks. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sean.coffey at oracle.com Thu Oct 11 17:54:10 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 11 Oct 2018 18:54:10 +0100 Subject: Tagging proposal for JDK GA releases In-Reply-To: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: Thanks for the feedback to date. Given the support expressed for this change, and the lack of objections, I'll propose the necessary jcheck changes to the Code Tools Project. Once approved, I'll ask the Leads of the relevant JDK Projects to begin using the new tag format each time a JDK release achieves the GA milestone. regards, Sean. On 03/10/2018 15:54, Se?n Coffey wrote: > I'd like to propose an enhancement to the JDK build-tagging > convention to help users more easily identify JDK GA releases > via Mercurial tag names. > > The concept is quite simple and lets people identify snapshots > of GA releases in Mercurial history without having to know the > build number of the GA release. > > For example, to obtain JDK 10.0.2 GA sources today, one issues the > `hg update -r jdk-10.0.2+13` command. With the proposed > enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > It's proposed that the new ga tag would be in addition to the regular > GA build number tag. It would be added to the relevant repository > once the GA milestone has been reached. > > This new convention would be used for future JDK releases and is > tracked via JDK-8180946[1]. If the changes are adopted, I can > look at retroactively adding labels for all feature JDK GA releases > since JDK 7 to the JDK feature-release main-line repository. > > To accommodate the new tag format, some simple jcheck edits > would be required. Test checks would also be added. > > Comments? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8180946 From pankaj.b.bansal at oracle.com Thu Oct 11 18:57:00 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Thu, 11 Oct 2018 18:57:00 +0000 (UTC) Subject: [jdk8u-dev] Request for enhancement approval for JDK-8207322 Message-ID: <43989498-8fa7-417d-a2ac-41fc4a547f7b@default> To JDK 8u maintainers & approvers, Could you please approve enhancement HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322 to jdk8u-dev. It adds conditional support for gtk3 and is a backport of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145547"JDK-8145547. As part of the enhancement backport, we will be backporting 16 more bugs fixes done for GTK3 related issues since jdk9. Due to this, the backport will be pushed under HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322. More information about the 16 bugs can be found at HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322. The backport has been reviewed on AWT, Swing mailing list. Although it is characterized as an enhancement, it is really necessary platform maintenance, without which SWT Interop will be broken for all upcoming SWT releases, and in due course JDK8 will not run on future Linux versions which no longer support GTK2. AWT review thread for 8u-backport: http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014422.html JDK9 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8145547 This Enhancement : https://bugs.openjdk.java.net/browse/JDK-8207322 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.03/"http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.03/ Regards, Pankaj Bansal From rob.mckenna at oracle.com Thu Oct 11 19:55:21 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 11 Oct 2018 20:55:21 +0100 Subject: [jdk8u-dev] Request for enhancement approval for JDK-8207322 In-Reply-To: <43989498-8fa7-417d-a2ac-41fc4a547f7b@default> References: <43989498-8fa7-417d-a2ac-41fc4a547f7b@default> Message-ID: <20181011195521.GE3729@vimes> Thanks for the request - we'll get back to you shortly. -Rob On 11/10/18 18:57, Pankaj Bansal wrote: > To JDK 8u maintainers & approvers, > > Could you please approve enhancement HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322 to jdk8u-dev. It adds conditional support for gtk3 and is a backport of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145547"JDK-8145547. > > As part of the enhancement backport, we will be backporting 16 more bugs fixes done for GTK3 related issues since jdk9. Due to this, the backport will be pushed under HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322. More information about the 16 bugs can be found at HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322. The backport has been reviewed on AWT, Swing mailing list. > > Although it is characterized as an enhancement, it is really necessary platform maintenance, without which SWT Interop will be broken for all upcoming SWT releases, and in due course JDK8 will not run on future Linux versions which no longer support GTK2. > > AWT review thread for 8u-backport: http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014422.html > > JDK9 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8145547 > This Enhancement : https://bugs.openjdk.java.net/browse/JDK-8207322 > Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.03/"http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.03/ > > > > Regards, > > Pankaj Bansal > > > > From hohensee at amazon.com Fri Oct 12 00:03:54 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Oct 2018 00:03:54 +0000 Subject: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Message-ID: <9D007BB7-F6FE-4A24-81BC-6629B68DEF70@amazon.com> Please review a backport to jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 The backport is slightly different from the JDK11 patch due to G1 refactoring, hence my request for new review. I?ll ask for jdk8u approval once the backport is reviewed. I backported two jtreg tests from JDK11, which pass. Also, all the hotspot gc jtreg tests pass as well as they do for jdk8u-dev. There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to be re-approved for jdk8u as well, and if so, what?s the process? Thanks, Paul From aph at redhat.com Fri Oct 12 08:12:07 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Oct 2018 09:12:07 +0100 Subject: OEL version used to build JDK 8? In-Reply-To: References: <376add08-5d95-a9cd-70c8-768a3e3f7484@redhat.com> Message-ID: <4ba8d770-af4b-118d-1a07-a093bce8adf3@redhat.com> On 10/11/2018 03:05 PM, Volker Simonis wrote: > You can find the Oracle build platforms in the OpenJDK Wiki: > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms Aha, yes: Linux x86_x64: Build platform is OEL 7.1 but using sysroot (headers and libs) from 6.4 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jcbeyler at google.com Fri Oct 12 02:35:52 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 11 Oct 2018 19:35:52 -0700 Subject: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <9D007BB7-F6FE-4A24-81BC-6629B68DEF70@amazon.com> References: <9D007BB7-F6FE-4A24-81BC-6629B68DEF70@amazon.com> Message-ID: Hi Paul, The biggest thing I saw in this RFR was that the flags for the test: http://cr.openjdk.java.net/~phh/8195115/webrev.05/test/gc/g1/mixedgc/TestOldGenCollectionUsage.java.html were changed it seems: - the @requires are different for the backport (you accept null for JDK8 for GC and also removed the @requires vm.opt.MaxGCPauseMillis == "null") - the @run flags are different (-Xms/Xmx are 14m for the backport; they were 12 originally; there is a comment below in the backport saying this requires normally 12m though you ask for 14 in the @run) What are the reasons for these differences? Apart from that, the backport seemed ok but I'm not that well versed in the GC changes :) Jc On Thu, Oct 11, 2018 at 5:04 PM Hohensee, Paul wrote: > Please review a backport to jdk8u. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > > > The backport is slightly different from the JDK11 patch due to G1 > refactoring, hence my request for new review. I?ll ask for jdk8u approval > once the backport is reviewed. > > > > I backported two jtreg tests from JDK11, which pass. Also, all the hotspot > gc jtreg tests pass as well as they do for jdk8u-dev. > > > > There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. > Does that have to be re-approved for jdk8u as well, and if so, what?s the > process? > > > > Thanks, > > > > Paul > > > > > -- Thanks, Jc From sean.coffey at oracle.com Fri Oct 12 09:39:45 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 12 Oct 2018 10:39:45 +0100 Subject: [jdk8u-dev] Request for enhancement approval for JDK-8207322 In-Reply-To: <20181011195521.GE3729@vimes> References: <43989498-8fa7-417d-a2ac-41fc4a547f7b@default> <20181011195521.GE3729@vimes> Message-ID: <4713ba54-37e7-4ef3-62fe-e344791cc32e@oracle.com> Approved for jdk8u-dev. Please log a push request. http://openjdk.java.net/projects/jdk8u/approval-template.html Regards, Sean. On 11/10/18 20:55, Rob McKenna wrote: > Thanks for the request - we'll get back to you shortly. > > -Rob > > On 11/10/18 18:57, Pankaj Bansal wrote: >> To JDK 8u maintainers & approvers, >> >> Could you please approve enhancement HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322 to jdk8u-dev. It adds conditional support for gtk3 and is a backport of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145547"JDK-8145547. >> >> As part of the enhancement backport, we will be backporting 16 more bugs fixes done for GTK3 related issues since jdk9. Due to this, the backport will be pushed under HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322. More information about the 16 bugs can be found at HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207322"JDK-8207322. The backport has been reviewed on AWT, Swing mailing list. >> >> Although it is characterized as an enhancement, it is really necessary platform maintenance, without which SWT Interop will be broken for all upcoming SWT releases, and in due course JDK8 will not run on future Linux versions which no longer support GTK2. >> >> AWT review thread for 8u-backport: http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014422.html >> >> JDK9 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8145547 >> This Enhancement : https://bugs.openjdk.java.net/browse/JDK-8207322 >> Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.03/"http://cr.openjdk.java.net/~pbansal/gtk3_backport/webrev.03/ >> >> >> >> Regards, >> >> Pankaj Bansal >> >> >> >> From pankaj.b.bansal at oracle.com Fri Oct 12 09:59:58 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Fri, 12 Oct 2018 09:59:58 +0000 (UTC) Subject: [jdk8u-dev] Request for approval for JDK-8207322 Message-ID: <97b43318-fa76-4095-857a-9afe14757f33@default> To JDK 8u maintainers & approvers, Could you please approve the fix for https://bugs.openjdk.java.net/browse/JDK-8207322 to jdk8u-dev. It adds conditional support for gtk3 and is a backport of https://bugs.openjdk.java.net/browse/JDK-8145547 As part of the enhancement backport, we will be backporting 16 more bugs fixes done for GTK3 related issues since jdk9. Due to this, the backport will be pushed under https://bugs.openjdk.java.net/browse/JDK-8207322. More information about the 16 bugs can be found at https://bugs.openjdk.java.net/browse/JDK-8207322. The backport fix has been reviewed on AWT, Swing mailing list. The enhancement request has also been approved on jdk8u-dev mailing list. AWT review thread for 8u-backport: http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014422.html Enhancement approval thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/008005.html JDK9 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8145547 This Enhancement : https://bugs.openjdk.java.net/browse/JDK-8207322 Webrev: "http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.03/ Reviewers: Phil Race (philip.race at oracle.com) , Semyon Sadetsky (semyon.sadetsky at oracle.com) Regards, Pankaj Bansal From sean.coffey at oracle.com Fri Oct 12 10:02:12 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 12 Oct 2018 11:02:12 +0100 Subject: [jdk8u-dev] Request for approval for JDK-8207322 In-Reply-To: <97b43318-fa76-4095-857a-9afe14757f33@default> References: <97b43318-fa76-4095-857a-9afe14757f33@default> Message-ID: <386aa374-027a-635e-c273-b087b8a7d9aa@oracle.com> Approved for pushing to jdk8u-dev Regards, Sean. On 12/10/18 10:59, Pankaj Bansal wrote: > To JDK 8u maintainers & approvers, > > > > Could you please approve the fix for https://bugs.openjdk.java.net/browse/JDK-8207322 to jdk8u-dev. It adds conditional support for gtk3 and is a backport of https://bugs.openjdk.java.net/browse/JDK-8145547 > > > > As part of the enhancement backport, we will be backporting 16 more bugs fixes done for GTK3 related issues since jdk9. Due to this, the backport will be pushed under https://bugs.openjdk.java.net/browse/JDK-8207322. More information about the 16 bugs can be found at https://bugs.openjdk.java.net/browse/JDK-8207322. > > > > The backport fix has been reviewed on AWT, Swing mailing list. The enhancement request has also been approved on jdk8u-dev mailing list. > > > > AWT review thread for 8u-backport: http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014422.html > > Enhancement approval thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/008005.html > > > > JDK9 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8145547 > > This Enhancement : https://bugs.openjdk.java.net/browse/JDK-8207322 > > Webrev: "http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.03/ > > Reviewers: Phil Race (philip.race at oracle.com) , Semyon Sadetsky (semyon.sadetsky at oracle.com) > > > > Regards, > > Pankaj Bansal From hohensee at amazon.com Fri Oct 12 14:13:48 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Oct 2018 14:13:48 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Message-ID: <7565CED8-5174-4CB2-8AC1-F2544BD3B316@amazon.com> Thanks for the review, new webrev at http://cr.openjdk.java.net/~phh/8195115/webrev.06/. The different requires were an artifact of me trying to get TestOldGenCollectionUsage.java to run. Good catch. Jiangli changed the heap size to 14m to get it to work with CDS, see https://bugs.openjdk.java.net/browse/JDK-8210193. Paul From: JC Beyler Date: Thursday, October 11, 2018 at 10:37 PM To: "Hohensee, Paul" Cc: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" , "jdk8u-dev at openjdk.java.net" Subject: Re: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Hi Paul, The biggest thing I saw in this RFR was that the flags for the test: http://cr.openjdk.java.net/~phh/8195115/webrev.05/test/gc/g1/mixedgc/TestOldGenCollectionUsage.java.html were changed it seems: - the @requires are different for the backport (you accept null for JDK8 for GC and also removed the @requires vm.opt.MaxGCPauseMillis == "null") - the @run flags are different (-Xms/Xmx are 14m for the backport; they were 12 originally; there is a comment below in the backport saying this requires normally 12m though you ask for 14 in the @run) What are the reasons for these differences? Apart from that, the backport seemed ok but I'm not that well versed in the GC changes :) Jc On Thu, Oct 11, 2018 at 5:04 PM Hohensee, Paul > wrote: Please review a backport to jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 The backport is slightly different from the JDK11 patch due to G1 refactoring, hence my request for new review. I?ll ask for jdk8u approval once the backport is reviewed. I backported two jtreg tests from JDK11, which pass. Also, all the hotspot gc jtreg tests pass as well as they do for jdk8u-dev. There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to be re-approved for jdk8u as well, and if so, what?s the process? Thanks, Paul -- Thanks, Jc From kishor.gollapalliwar at gmail.com Sat Oct 13 14:26:27 2018 From: kishor.gollapalliwar at gmail.com (Kishor Gollapalliwar) Date: Sat, 13 Oct 2018 19:56:27 +0530 Subject: Inconsistencies in TreeSet Interface Message-ID: Hello Everyone, Introduction : I?m an enthusiast java developer. I?m a newbie in this group, hence please ignore my nuisance and guide me towards right direction. ## Problems Statement Treeset#add method documentations : ?adds the specified element e to this set if the set contains no element e2 such that (e==null ? e2==null : e.equals(e2))? Inconsistencies: > If we try to add ?null? value, it will throws NullPointerException, hence > e and e2 can not be null. > And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to > collection. Request you to help me understand if behavior of Treeset#add method is as expected, and differ with set interface documentation. We may have to consider to update method documentations, if behavior is expected. For more details I have attached the sample java application. I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK 8u181. Thanks & Regards, *Kishor Golapelliwar,* The ability to convert ideas to things is the secret to outward success. From gnu.andrew at redhat.com Sat Oct 13 23:50:25 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sun, 14 Oct 2018 00:50:25 +0100 Subject: [jdk8u-dev] Request for approval for JDK-8207322 In-Reply-To: <97b43318-fa76-4095-857a-9afe14757f33@default> References: <97b43318-fa76-4095-857a-9afe14757f33@default> Message-ID: On Fri, 12 Oct 2018 at 11:00, Pankaj Bansal wrote: > > To JDK 8u maintainers & approvers, > > > > Could you please approve the fix for https://bugs.openjdk.java.net/browse/JDK-8207322 to jdk8u-dev. It adds conditional support for gtk3 and is a backport of https://bugs.openjdk.java.net/browse/JDK-8145547 > > > > As part of the enhancement backport, we will be backporting 16 more bugs fixes done for GTK3 related issues since jdk9. Due to this, the backport will be pushed under https://bugs.openjdk.java.net/browse/JDK-8207322. More information about the 16 bugs can be found at https://bugs.openjdk.java.net/browse/JDK-8207322. > > > > The backport fix has been reviewed on AWT, Swing mailing list. The enhancement request has also been approved on jdk8u-dev mailing list. > > > > AWT review thread for 8u-backport: http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014422.html > > Enhancement approval thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/008005.html > > > > JDK9 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8145547 > > This Enhancement : https://bugs.openjdk.java.net/browse/JDK-8207322 > > Webrev: "http://cr.openjdk.java.net/%7Epbansal/gtk3_backport/webrev.03/ > > Reviewers: Phil Race (philip.race at oracle.com) , Semyon Sadetsky (semyon.sadetsky at oracle.com) > > > > Regards, > > Pankaj Bansal For what it's worth, we backported this some time ago: https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3066 I'm a little perturbed by the idea of combining over a dozen other fixes into one changeset. Can we at least make sure that the commit text includes these bug IDs so the fact they've been backported is not lost? 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 gnu.andrew at redhat.com Sun Oct 14 00:26:16 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sun, 14 Oct 2018 01:26:16 +0100 Subject: [8u-dev] Request for approval for CR JDK-8131048 and JDK-8164920 In-Reply-To: <0891f249-d21c-8da4-7f9d-31dd9a2d9a3e@oracle.com> References: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> <4983a66c-3ce9-90bc-4604-36768ca66f5b@oracle.com> <9bc1191f-1fde-a9c5-46ea-ea64de8da5af@linux.vnet.ibm.com> <0891f249-d21c-8da4-7f9d-31dd9a2d9a3e@oracle.com> Message-ID: On Wed, 10 Oct 2018 at 16:28, Se?n Coffey wrote: > > I think we have all the information needed from your previous emails. > I've adjusted the subject line in this email to "request for approval" > > Approved for pushing to jdk8u-dev. > > Regards, > Sean. Pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/bcccbecdde63 http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/f892c3b6b651 -- 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 fairoz.matte at oracle.com Mon Oct 15 05:02:57 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Sun, 14 Oct 2018 22:02:57 -0700 (PDT) Subject: [8u-dev] RFA: 8193879: Java debugger hangs on method invocation Message-ID: <5b10a3ee-412a-49af-ae25-159b560f8cc0@default> Hi, Please approve the backport of JDK-8193879 to 8u-dev JBS issue - https://bugs.openjdk.java.net/browse/JDK-8193879 Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.01/ Review thread http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025471.html Thanks, Fairoz From david.buck at oracle.com Mon Oct 15 05:32:43 2018 From: david.buck at oracle.com (David Buck) Date: Mon, 15 Oct 2018 14:32:43 +0900 Subject: [8u-dev] RFA: 8193879: Java debugger hangs on method invocation In-Reply-To: <5b10a3ee-412a-49af-ae25-159b560f8cc0@default> References: <5b10a3ee-412a-49af-ae25-159b560f8cc0@default> Message-ID: approved Cheers, -Buck On 2018/10/15 14:02, Fairoz Matte wrote: > Hi, > > Please approve the backport of JDK-8193879 to 8u-dev > > JBS issue - https://bugs.openjdk.java.net/browse/JDK-8193879 > > Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.01/ > > Review thread http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025471.html > > Thanks, > Fairoz > From fairoz.matte at oracle.com Mon Oct 15 05:38:00 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Sun, 14 Oct 2018 22:38:00 -0700 (PDT) Subject: [8u-dev] RFA: 8193879: Java debugger hangs on method invocation In-Reply-To: References: <5b10a3ee-412a-49af-ae25-159b560f8cc0@default> Message-ID: <0cd8815f-cce3-4fe8-b312-ab7c401044a8@default> Thanks Buck... > -----Original Message----- > From: David Buck > Sent: Monday, October 15, 2018 11:03 AM > To: Fairoz Matte ; jdk8u-dev at openjdk.java.net > Subject: Re: [8u-dev] RFA: 8193879: Java debugger hangs on method > invocation > > approved > > Cheers, > -Buck > > On 2018/10/15 14:02, Fairoz Matte wrote: > > Hi, > > > > Please approve the backport of JDK-8193879 to 8u-dev > > > > JBS issue - https://bugs.openjdk.java.net/browse/JDK-8193879 > > > > Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.01/ > > > > Review thread http://mail.openjdk.java.net/pipermail/serviceability- > dev/2018-October/025471.html > > > > Thanks, > > Fairoz > > From gromero at linux.vnet.ibm.com Mon Oct 15 10:50:55 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 15 Oct 2018 07:50:55 -0300 Subject: [8u-dev] Request for approval for CR JDK-8131048 and JDK-8164920 In-Reply-To: References: <8b7aa0e8-c9f7-5553-af45-e4f6030d9b09@linux.vnet.ibm.com> <4983a66c-3ce9-90bc-4604-36768ca66f5b@oracle.com> <9bc1191f-1fde-a9c5-46ea-ea64de8da5af@linux.vnet.ibm.com> <0891f249-d21c-8da4-7f9d-31dd9a2d9a3e@oracle.com> Message-ID: <0b93124b-2dbd-913e-ee45-b68e2533e52d@linux.vnet.ibm.com> On 10/13/2018 09:26 PM, Andrew Hughes wrote: > On Wed, 10 Oct 2018 at 16:28, Se?n Coffey wrote: >> >> I think we have all the information needed from your previous emails. >> I've adjusted the subject line in this email to "request for approval" >> >> Approved for pushing to jdk8u-dev. >> >> Regards, >> Sean. > > Pushed: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/bcccbecdde63 > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/f892c3b6b651 Thanks a lot Andrew. Best regards, Gustavo From rwestrel at redhat.com Mon Oct 15 11:10:06 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 15 Oct 2018 13:10:06 +0200 Subject: [8u] RFR and RFA: 8172850: Anti-dependency on membar causes crash in register allocator due to invalid instruction scheduling Message-ID: I'd like to backport 8172850 to 8u because I'd also like to backport a change that depends on it: 8209639. The change doesn't apply cleanly. So here is an updated webrev: http://cr.openjdk.java.net/~roland/8172850-8u/webrev.00/ Initial change: https://bugs.openjdk.java.net/browse/JDK-8172850 http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/6bf44f4e2a1e Roland. From rwestrel at redhat.com Mon Oct 15 11:13:01 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 15 Oct 2018 13:13:01 +0200 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item Message-ID: I'd like to backport 8209639 to 8u because one of our customers is hitting it. The change doesn't apply cleanly so here is a webrev for 8u: http://cr.openjdk.java.net/~roland/8209639-8u/webrev.00/ Initial change: https://bugs.openjdk.java.net/browse/JDK-8209639 http://hg.openjdk.java.net/jdk/jdk/rev/76a51e26d0ac Roland. From sean.coffey at oracle.com Mon Oct 15 11:21:26 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 15 Oct 2018 12:21:26 +0100 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: References: Message-ID: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> Roland, do you plan to port this fix to JDK 11.0.x first ? Regards, Sean. On 15/10/18 12:13, Roland Westrelin wrote: > I'd like to backport 8209639 to 8u because one of our customers is > hitting it. The change doesn't apply cleanly so here is a webrev for 8u: > > http://cr.openjdk.java.net/~roland/8209639-8u/webrev.00/ > > Initial change: > > https://bugs.openjdk.java.net/browse/JDK-8209639 > http://hg.openjdk.java.net/jdk/jdk/rev/76a51e26d0ac > > Roland. From rwestrel at redhat.com Mon Oct 15 13:27:17 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 15 Oct 2018 15:27:17 +0200 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> Message-ID: Hi Sean, > do you plan to port this fix to JDK 11.0.x first ? I didn't plan to but I suppose it makes sense. I will go through the process for 11u. Can both requests proceed in parallel? Roland. From rob.mckenna at oracle.com Mon Oct 15 13:56:44 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 15 Oct 2018 14:56:44 +0100 Subject: Inconsistencies in TreeSet Interface In-Reply-To: References: Message-ID: <20181015135644.GA3535@vimes> Hi Kishor, core-libs-dev at openjdk.java.net may be a better venue for this topic. -Rob On 13/10/18 19:56, Kishor Gollapalliwar wrote: > Hello Everyone, > > Introduction : I?m an enthusiast java developer. I?m a newbie in this > group, hence please ignore my nuisance and guide me towards right direction. > > ## Problems Statement > > Treeset#add method documentations : ?adds the specified element e to this > set if the set contains no element e2 such that (e==null ? e2==null : > e.equals(e2))? > > Inconsistencies: > > > If we try to add ?null? value, it will throws NullPointerException, hence > > e and e2 can not be null. > > > > > And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to > > collection. > > > Request you to help me understand if behavior of Treeset#add method is as > expected, and differ with set interface documentation. We may have to > consider to update method documentations, if behavior is expected. > > For more details I have attached the sample java application. > > I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK 8u181. > > Thanks & Regards, > *Kishor Golapelliwar,* > The ability to convert ideas to things is the secret to outward success. From mbalao at redhat.com Mon Oct 15 15:15:11 2018 From: mbalao at redhat.com (Martin Balao) Date: Mon, 15 Oct 2018 17:15:11 +0200 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> Message-ID: Hi Sean, Any updates on this? Kind regards, Martin.- On Tue, Sep 25, 2018 at 6:56 PM, Se?n Coffey wrote: > Thanks for logging this request Martin. Looking into this and hope to > reply shortly. > > regards, > Sean. > > > > On 25/09/2018 10:07, Martin Balao wrote: > >> Hi, >> >> I'd like to request an enhancement backport approval for JDK-8029661 [1]. >> >> Supporting TLS v1.2 algorithms in SunPKCS11 crypto provider would be >> highly >> beneficial for operating in a FIPS-140 environment. This is highly >> critical >> for both security and compliance reasons to many OpenJDK users; including >> corporations, public sector and other organizations. TLS 1.2 is currently >> the most wide-spread TLS version. >> >> Changes done as part of this enhancement are constrained to SunPKCS11 >> crypto provider and do not affect SSL/TLS code. Risk involved is low >> mainly >> because of the following reasons: 1) this enhancement is an extension on >> top of currently supported mechanisms (no major refactorings were >> applied); >> and, 2) backport is straight forward because affected code has not >> suffered >> major changes since JDK 8 release. >> >> JDK-8029661 has been reviewed by Valerie Peng on security-dev list [2] and >> has been merged to JDK [3] base line. Regression testing on >> sun/security/pkcs11 category experienced no regressions because of this >> enhancement on both JDK base line and JDK 8. >> >> JDK 8 backport webrev: >> >> * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >> 8029661.webrev.10.jdk8u/ >> * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >> 8029661.webrev.10.jdk8u.zip >> >> Please note that this backport includes JDK-8210912 fix [4]. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 >> [2] - http://mail.openjdk.java.net/pipermail/security-dev/ >> 2018-September/018278.html >> [3] - http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed >> [4] - https://bugs.openjdk.java.net/browse/JDK-8210912 >> > > From sean.coffey at oracle.com Mon Oct 15 15:25:21 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 15 Oct 2018 16:25:21 +0100 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> Message-ID: <2c4d13cd-6d35-78eb-f6b5-8301ad2a5e9d@oracle.com> Hope to have an answer within next few days Martin! Regards, Sean. On 15/10/18 16:15, Martin Balao wrote: > Hi Sean, > > Any updates on this? > > Kind regards, > Martin.- > > On Tue, Sep 25, 2018 at 6:56 PM, Se?n Coffey > wrote: > > Thanks for logging this request Martin. Looking into this and hope > to reply shortly. > > regards, > Sean. > > > > On 25/09/2018 10:07, Martin Balao wrote: > > Hi, > > I'd like to request an enhancement backport approval for > JDK-8029661 [1]. > > Supporting TLS v1.2 algorithms in SunPKCS11 crypto provider > would be highly > beneficial for operating in a FIPS-140 environment. This is > highly critical > for both security and compliance reasons to many OpenJDK > users; including > corporations, public sector and other organizations. TLS 1.2 > is currently > the most wide-spread TLS version. > > Changes done as part of this enhancement are constrained to > SunPKCS11 > crypto provider and do not affect SSL/TLS code. Risk involved > is low mainly > because of the following reasons: 1) this enhancement is an > extension on > top of currently supported mechanisms (no major refactorings > were applied); > and, 2) backport is straight forward because affected code has > not suffered > major changes since JDK 8 release. > > JDK-8029661 has been reviewed by Valerie Peng on security-dev > list [2] and > has been merged to JDK [3] base line. Regression testing on > sun/security/pkcs11 category experienced no regressions > because of this > enhancement on both JDK base line and JDK 8. > > JDK 8 backport webrev: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ > > 8029661.webrev.10.jdk8u/ > * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ > > 8029661.webrev.10.jdk8u.zip > > Please note that this backport includes JDK-8210912 fix [4]. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 > > [2] - http://mail.openjdk.java.net/pipermail/security-dev/ > > 2018-September/018278.html > [3] - http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed > > [4] - https://bugs.openjdk.java.net/browse/JDK-8210912 > > > > From sean.coffey at oracle.com Mon Oct 15 16:09:51 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 15 Oct 2018 17:09:51 +0100 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> Message-ID: <2baed155-ce19-75c4-dfab-77e1fb66c17b@oracle.com> Given the new push approval criteria for the JDK Updates Project[1], it would be good to ensure all fixes get into that repository before porting to older JDK family versions. I see you've already make an 11u inclusion request. [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-October/000209.html Regards, Sean. On 15/10/18 14:27, Roland Westrelin wrote: > Hi Sean, > >> do you plan to port this fix to JDK 11.0.x first ? > I didn't plan to but I suppose it makes sense. I will go through the > process for 11u. Can both requests proceed in parallel? > > Roland. From hohensee at amazon.com Mon Oct 15 22:08:30 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 15 Oct 2018 22:08:30 +0000 Subject: [8u-dev] RFA: JDK-8064811: Use THREAD instead of CHECK_NULL in return statements Message-ID: Please approve a backport of JDK-8064811 to 8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8064811 Webrev: http://cr.openjdk.java.net/~phh/8064811/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016018.html The patch applies cleanly net of line numbers, copyright notice dates, and code that exists in JDK9 but not in JDK8. It builds and runs jdk8 hotspot jtreg tests on a linux x64 host, which is the only one to which I have access. If needed, would someone please run it through JPRT? Thanks, Paul From david.holmes at oracle.com Tue Oct 16 07:14:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Oct 2018 17:14:48 +1000 Subject: [8u-dev] RFA: JDK-8064811: Use THREAD instead of CHECK_NULL in return statements In-Reply-To: References: Message-ID: <1302dab8-6be3-46dc-c08e-f6121db9a2df@oracle.com> Hi Paul, I'm running this through JPRT but the backport looks okay to me. Thanks, David On 16/10/2018 8:08 AM, Hohensee, Paul wrote: > Please approve a backport of JDK-8064811 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8064811 > Webrev: http://cr.openjdk.java.net/~phh/8064811/webrev.00/ > Review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016018.html > > The patch applies cleanly net of line numbers, copyright notice dates, and code that exists in JDK9 but not in JDK8. > > It builds and runs jdk8 hotspot jtreg tests on a linux x64 host, which is the only one to which I have access. If needed, would someone please run it through JPRT? > > Thanks, > > Paul > > > From sean.coffey at oracle.com Tue Oct 16 08:27:41 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 16 Oct 2018 09:27:41 +0100 Subject: [8u-dev] RFA: JDK-8064811: Use THREAD instead of CHECK_NULL in return statements In-Reply-To: <1302dab8-6be3-46dc-c08e-f6121db9a2df@oracle.com> References: <1302dab8-6be3-46dc-c08e-f6121db9a2df@oracle.com> Message-ID: Thanks David. I was just about to create a JPRT job. This is approved provided David gives the 'ok' regards JPRT results. regards, Sean. On 16/10/2018 08:14, David Holmes wrote: > Hi Paul, > > I'm running this through JPRT but the backport looks okay to me. > > Thanks, > David > > On 16/10/2018 8:08 AM, Hohensee, Paul wrote: >> Please approve a backport of JDK-8064811 to 8u. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8064811 >> Webrev: http://cr.openjdk.java.net/~phh/8064811/webrev.00/ >> Review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016018.html >> >> The patch applies cleanly net of line numbers, copyright notice >> dates, and code that exists in JDK9 but not in JDK8. >> >> It builds and runs jdk8 hotspot jtreg tests on a linux x64 host, >> which is the only one to which I have access. If needed, would >> someone please run it through JPRT? >> >> Thanks, >> >> Paul >> >> >> From david.holmes at oracle.com Tue Oct 16 11:44:41 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Oct 2018 21:44:41 +1000 Subject: [8u-dev] RFA: JDK-8064811: Use THREAD instead of CHECK_NULL in return statements In-Reply-To: <1302dab8-6be3-46dc-c08e-f6121db9a2df@oracle.com> References: <1302dab8-6be3-46dc-c08e-f6121db9a2df@oracle.com> Message-ID: JPRT passed. David On 16/10/2018 5:14 PM, David Holmes wrote: > Hi Paul, > > I'm running this through JPRT but the backport looks okay to me. > > Thanks, > David > > On 16/10/2018 8:08 AM, Hohensee, Paul wrote: >> Please approve a backport of JDK-8064811 to 8u. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8064811 >> Webrev: http://cr.openjdk.java.net/~phh/8064811/webrev.00/ >> Review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016018.html >> >> >> The patch applies cleanly net of line numbers, copyright notice dates, >> and code that exists in JDK9 but not in JDK8. >> >> It builds and runs jdk8 hotspot jtreg tests on a linux x64 host, which >> is the only one to which I have access. If needed, would someone >> please run it through JPRT? >> >> Thanks, >> >> Paul >> >> >> From rwestrel at redhat.com Tue Oct 16 12:14:33 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 16 Oct 2018 14:14:33 +0200 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: <2baed155-ce19-75c4-dfab-77e1fb66c17b@oracle.com> References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> <2baed155-ce19-75c4-dfab-77e1fb66c17b@oracle.com> Message-ID: Change is now backported to 11u. Roland. From sean.coffey at oracle.com Tue Oct 16 12:35:15 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 16 Oct 2018 13:35:15 +0100 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> Message-ID: <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> Thanks for pushing to 11.0.2. This is approved for jdk8u-dev but it looks like it's still subject to 8u review first. regards, Sean. On 15/10/2018 12:21, Se?n Coffey wrote: > Roland, > > do you plan to port this fix to JDK 11.0.x first ? > > Regards, > Sean. > > On 15/10/18 12:13, Roland Westrelin wrote: >> I'd like to backport 8209639 to 8u because one of our customers is >> hitting it. The change doesn't apply cleanly so here is a webrev for 8u: >> >> http://cr.openjdk.java.net/~roland/8209639-8u/webrev.00/ >> >> Initial change: >> >> https://bugs.openjdk.java.net/browse/JDK-8209639 >> http://hg.openjdk.java.net/jdk/jdk/rev/76a51e26d0ac >> >> Roland. > From hohensee at amazon.com Tue Oct 16 14:41:11 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Oct 2018 14:41:11 +0000 Subject: [8u-dev] RFA: JDK-8064811: Use THREAD instead of CHECK_NULL in return statements In-Reply-To: References: <1302dab8-6be3-46dc-c08e-f6121db9a2df@oracle.com> Message-ID: <19B019BB-EC2D-4E4F-A7B5-17CFCC023264@amazon.com> Pushed. Thanks, David and Sean! Pal ?On 10/16/18, 7:46 AM, "David Holmes" wrote: JPRT passed. David On 16/10/2018 5:14 PM, David Holmes wrote: > Hi Paul, > > I'm running this through JPRT but the backport looks okay to me. > > Thanks, > David > > On 16/10/2018 8:08 AM, Hohensee, Paul wrote: >> Please approve a backport of JDK-8064811 to 8u. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8064811 >> Webrev: http://cr.openjdk.java.net/~phh/8064811/webrev.00/ >> Review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016018.html >> >> >> The patch applies cleanly net of line numbers, copyright notice dates, >> and code that exists in JDK9 but not in JDK8. >> >> It builds and runs jdk8 hotspot jtreg tests on a linux x64 host, which >> is the only one to which I have access. If needed, would someone >> please run it through JPRT? >> >> Thanks, >> >> Paul >> >> >> From aleksej.efimov at oracle.com Tue Oct 16 16:56:20 2018 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 16 Oct 2018 17:56:20 +0100 Subject: [8u] Request for approval for bulk integration of fixes from 8u192 to 8u Message-ID: <86eaf10f-b9a4-363d-4266-6678d39ba3d5@oracle.com> Hello, 8u192 has been released [1]. Requesting for approval to sync 8u192 changes to "jdk8u" forest. Webrev: http://cr.openjdk.java.net/~aefimov/syncs/openJDK.8u192-8u202/webrev Thank you, Aleksei [1] http://www.oracle.com/technetwork/java/javase/downloads/index.html From rob.mckenna at oracle.com Tue Oct 16 16:59:00 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 16 Oct 2018 17:59:00 +0100 Subject: [8u] Request for approval for bulk integration of fixes from 8u192 to 8u In-Reply-To: <86eaf10f-b9a4-363d-4266-6678d39ba3d5@oracle.com> References: <86eaf10f-b9a4-363d-4266-6678d39ba3d5@oracle.com> Message-ID: <20181016165900.GA7864@vimes> Approved. -Rob On 16/10/18 17:56, Aleks Efimov wrote: > Hello, > > 8u192 has been released [1]. Requesting for approval to sync 8u192 changes > to "jdk8u" forest. > > Webrev: > http://cr.openjdk.java.net/~aefimov/syncs/openJDK.8u192-8u202/webrev > > Thank you, > Aleksei > > [1] http://www.oracle.com/technetwork/java/javase/downloads/index.html From aleksej.efimov at oracle.com Tue Oct 16 17:05:36 2018 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 16 Oct 2018 18:05:36 +0100 Subject: [8u] Request for approval for bulk integration of fixes from 8u192 to 8u In-Reply-To: <20181016165900.GA7864@vimes> References: <86eaf10f-b9a4-363d-4266-6678d39ba3d5@oracle.com> <20181016165900.GA7864@vimes> Message-ID: Thank you, Rob! -Aleksei On 10/16/2018 05:59 PM, Rob McKenna wrote: > Approved. > > -Rob > > On 16/10/18 17:56, Aleks Efimov wrote: >> Hello, >> >> 8u192 has been released [1]. Requesting for approval to sync 8u192 changes >> to "jdk8u" forest. >> >> Webrev: >> http://cr.openjdk.java.net/~aefimov/syncs/openJDK.8u192-8u202/webrev >> >> Thank you, >> Aleksei >> >> [1] http://www.oracle.com/technetwork/java/javase/downloads/index.html From hohensee at amazon.com Tue Oct 16 22:23:12 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Oct 2018 22:23:12 +0000 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block Message-ID: Please approve a trivial backport of JDK-8211394 to 8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 Webrev: http://cr.openjdk.java.net/~phh/8211394/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html The patch applies cleanly net of line numbers, copyright notice dates, and code that exists in JDK9 but not in JDK8. The result is a one line change and a new comment. It builds and runs jdk8 hotspot jtreg test on a linux x64 host. If needed, would someone please run it through jprt? Thanks, Paul From david.holmes at oracle.com Tue Oct 16 23:05:35 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Oct 2018 09:05:35 +1000 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: References: Message-ID: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> On 17/10/2018 8:23 AM, Hohensee, Paul wrote: > Please approve a trivial backport of JDK-8211394 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 > > Webrev: http://cr.openjdk.java.net/~phh/8211394/webrev.00/ > > > Review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html > > The patch applies cleanly net of line numbers, copyright notice > dates,?and code that exists in JDK9 but not in JDK8. The result is a one > line change and a new comment. Looks fine. > It builds and runs jdk8 hotspot jtreg test on a linux x64 host. If > needed, would someone please run it through jprt? It doesn't really warrant it but I fired it off anyway. Thanks, David > Thanks, > > Paul > From yumin.qi at gmail.com Wed Oct 17 06:29:58 2018 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 16 Oct 2018 23:29:58 -0700 Subject: Question of backport AppCDS to openjdk8u Message-ID: Hi, Gurus I have a question about backporting AppCDS to jdk8u. Recently I have been working on backporting AppCDS from jdk10 to jdk8(for internal use), I also want this feature in openjdk8. Since OracleJDK8 has AppCDS as commercial feature, so need to know if it is okay to add this important feature to open jdk8u before it is on LTS. If it is OK I will file a bug and get it pushed into open repo. Thanks Yumin From volker.simonis at gmail.com Wed Oct 17 09:51:16 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Oct 2018 11:51:16 +0200 Subject: Question of backport AppCDS to openjdk8u In-Reply-To: References: Message-ID: On Wed, Oct 17, 2018 at 10:53 AM yumin qi wrote: > > Hi, Gurus > > I have a question about backporting AppCDS to jdk8u. Recently I have > been working on backporting AppCDS from jdk10 to jdk8(for internal use), I Did you succeed? There are a lot of differences between the Hotspot in OpenJDK 8 and 10 and there also have been some more improvements for AppCDS in OpenJDK 11 so if you donwport it you'll probably want to downport the version from OpenJDK 11. That said, I think it will be a huge change and I'm not sure the current (and future) OpenJDK 8u maintainers will want to support it. But that's something they'll have to decide :) I think it would be a good idea to share the patch/webrev of your internal backport to give an idea of the required changes. Regards, Volker > also want this feature in openjdk8. Since OracleJDK8 has AppCDS as > commercial feature, so need to know if it is okay to add this important > feature to open jdk8u before it is on LTS. If it is OK I will file a bug > and get it pushed into open repo. > > Thanks > Yumin From muthusamy.chinnathambi at oracle.com Wed Oct 17 11:26:28 2018 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Wed, 17 Oct 2018 04:26:28 -0700 (PDT) Subject: [8u] Request for enhancement backport approval for CR JDK-8027434: "-XX:OnOutOfMemoryError" uses fork instead of vfork Message-ID: Hi, May I get the approval of enhancement backport of 'JDK-8027434: "-XX:OnOutOfMemoryError" uses fork instead of vfork' to jdk8u-dev. Jdk12 bug: https://bugs.openjdk.java.net/browse/JDK-8027434 Short description of the change: When the system does not have enough memory available to fork, the option "-XX:OnOutOfMemoryError" may not work. Even a simple command "kill" does not get executed. This change is to use vfork instead of fork during "OnOutOfMemoryError". I have tested it with the jprt and jtreg tests. Regards, Muthusamy C From sean.coffey at oracle.com Wed Oct 17 11:44:17 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 17 Oct 2018 12:44:17 +0100 Subject: [8u] Request for enhancement backport approval for CR JDK-8027434: "-XX:OnOutOfMemoryError" uses fork instead of vfork In-Reply-To: References: Message-ID: <130ab045-f422-1dc3-d0ae-ae5a515487e4@oracle.com> Muthusamy, please look at fixing this in the 11 Updates release first. Also, can you check with hotspot engineers around the suitability of this fix in an update release ? Regards, Sean. On 17/10/18 12:26, Muthusamy Chinnathambi wrote: > Hi, > > May I get the approval of enhancement backport of 'JDK-8027434: "-XX:OnOutOfMemoryError" uses fork instead of vfork' to jdk8u-dev. > > Jdk12 bug: https://bugs.openjdk.java.net/browse/JDK-8027434 > > Short description of the change: > When the system does not have enough memory available to fork, the option "-XX:OnOutOfMemoryError" may not work. Even a simple command "kill" does not get executed. This change is to use vfork instead of fork during "OnOutOfMemoryError". > > I have tested it with the jprt and jtreg tests. > > Regards, > Muthusamy C From david.holmes at oracle.com Wed Oct 17 11:53:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Oct 2018 21:53:34 +1000 Subject: [8u] Request for enhancement backport approval for CR JDK-8027434: "-XX:OnOutOfMemoryError" uses fork instead of vfork In-Reply-To: <130ab045-f422-1dc3-d0ae-ae5a515487e4@oracle.com> References: <130ab045-f422-1dc3-d0ae-ae5a515487e4@oracle.com> Message-ID: Hi Sean, On 17/10/2018 9:44 PM, Se?n Coffey wrote: > Muthusamy, > > please look at fixing this in the 11 Updates release first. Also, can > you check with hotspot engineers around the suitability of this fix in > an update release ? This is a very simple fix that only impacts users of -XX:OnOutOfMemoryError. I have no concerns about it going into any update release. Thanks, David > Regards, > Sean. > > On 17/10/18 12:26, Muthusamy Chinnathambi wrote: >> Hi, >> >> May I get the approval of enhancement backport of 'JDK-8027434: >> "-XX:OnOutOfMemoryError" uses fork instead of vfork' to jdk8u-dev. >> >> Jdk12 bug: https://bugs.openjdk.java.net/browse/JDK-8027434 >> >> Short description of the change: >> When the system does not have enough memory available to fork, the >> option "-XX:OnOutOfMemoryError" may not work. Even a simple command >> "kill" does not get executed. This change is to use vfork instead of >> fork during "OnOutOfMemoryError". >> >> I have tested it with the jprt and jtreg tests. >> >> Regards, >> Muthusamy C > From yumin.qi at gmail.com Wed Oct 17 14:57:52 2018 From: yumin.qi at gmail.com (yumin qi) Date: Wed, 17 Oct 2018 07:57:52 -0700 Subject: Question of backport AppCDS to openjdk8u In-Reply-To: References: Message-ID: Hi, Volker On Wed, Oct 17, 2018 at 2:51 AM Volker Simonis wrote: > On Wed, Oct 17, 2018 at 10:53 AM yumin qi wrote: > > > > Hi, Gurus > > > > I have a question about backporting AppCDS to jdk8u. Recently I have > > been working on backporting AppCDS from jdk10 to jdk8(for internal use), > I > > Did you succeed? > > There are a lot of differences between the Hotspot in OpenJDK 8 and 10 > and there also have been some more improvements for AppCDS in OpenJDK > 11 so if you donwport it you'll probably want to downport the version > from OpenJDK 11. > > Yes, the changes are large. I port it from jdk10 not jdk11. So far, passed some tests on runtime/appcds (not all, some tests are not for jdk8). > That said, I think it will be a huge change and I'm not sure the > current (and future) OpenJDK 8u maintainers will want to support it. > But that's something they'll have to decide :) > > The maintenance after LTS for open part is Redhat? Yes, that is a problem since no one what to have a big change after LTS. > I think it would be a good idea to share the patch/webrev of your > internal backport to give an idea of the required changes. > If it did not get in, I will post the webrev then. Thanks Yumin > > Regards, > Volker > > > also want this feature in openjdk8. Since OracleJDK8 has AppCDS as > > commercial feature, so need to know if it is okay to add this important > > feature to open jdk8u before it is on LTS. If it is OK I will file a bug > > and get it pushed into open repo. > > > > Thanks > > Yumin > From hohensee at amazon.com Wed Oct 17 20:14:58 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Oct 2018 20:14:58 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <7565CED8-5174-4CB2-8AC1-F2544BD3B316@amazon.com> References: <7565CED8-5174-4CB2-8AC1-F2544BD3B316@amazon.com> Message-ID: <22380FF1-A213-464A-9F5B-8A7D6815909E@amazon.com> Ping. Reviews please, before the cutoff? Thanks, Paul From: hotspot-gc-dev on behalf of "Hohensee, Paul" Date: Friday, October 12, 2018 at 10:14 AM To: JC Beyler Cc: "serviceability-dev at openjdk.java.net" , "jdk8u-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" Subject: Re: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Thanks for the review, new webrev at http://cr.openjdk.java.net/~phh/8195115/webrev.06/. The different requires were an artifact of me trying to get TestOldGenCollectionUsage.java to run. Good catch. Jiangli changed the heap size to 14m to get it to work with CDS, see https://bugs.openjdk.java.net/browse/JDK-8210193. Paul From: JC Beyler Date: Thursday, October 11, 2018 at 10:37 PM To: "Hohensee, Paul" Cc: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" , "jdk8u-dev at openjdk.java.net" Subject: Re: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Hi Paul, The biggest thing I saw in this RFR was that the flags for the test: http://cr.openjdk.java.net/~phh/8195115/webrev.05/test/gc/g1/mixedgc/TestOldGenCollectionUsage.java.html were changed it seems: - the @requires are different for the backport (you accept null for JDK8 for GC and also removed the @requires vm.opt.MaxGCPauseMillis == "null") - the @run flags are different (-Xms/Xmx are 14m for the backport; they were 12 originally; there is a comment below in the backport saying this requires normally 12m though you ask for 14 in the @run) What are the reasons for these differences? Apart from that, the backport seemed ok but I'm not that well versed in the GC changes :) Jc On Thu, Oct 11, 2018 at 5:04 PM Hohensee, Paul > wrote: Please review a backport to jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 The backport is slightly different from the JDK11 patch due to G1 refactoring, hence my request for new review. I?ll ask for jdk8u approval once the backport is reviewed. I backported two jtreg tests from JDK11, which pass. Also, all the hotspot gc jtreg tests pass as well as they do for jdk8u-dev. There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to be re-approved for jdk8u as well, and if so, what?s the process? Thanks, Paul -- Thanks, Jc From rwestrel at redhat.com Thu Oct 18 08:06:29 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 18 Oct 2018 10:06:29 +0200 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: References: Message-ID: Anyone for a review of this one and companion 8172850? Roland. From fairoz.matte at oracle.com Thu Oct 18 12:48:26 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Thu, 18 Oct 2018 05:48:26 -0700 (PDT) Subject: [8u-dev] RFA: 8211909: JDWP Transport Listener: dt_socket thread crash Message-ID: <51a20e18-8179-44b8-807c-bb11a1082144@default> Hi, Please approve the backport of JDK-8211909 to 8u-dev JBS issue - https://bugs.openjdk.java.net/browse/JDK-8211909 Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025586.html Thanks, Fairoz From ivandasch at gmail.com Thu Oct 18 13:02:50 2018 From: ivandasch at gmail.com (Ivan Daschinsky) Date: Thu, 18 Oct 2018 16:02:50 +0300 Subject: Process freeze when calling UNSAFE.freeMemory of large chunks. Message-ID: Hi! I've faced recently with strange issue with UNSAFE.freeMemory. When in some thread(threads) we try to deallocate huge chunks of memory, all process freezes completely. I've wrote reproducer in C and Java with relatively same functionality. In few words, java reproducer will create N threads, each of therm allocated 2^M chunk of memory, sleeps T, than wait for barrier's broke. So all N threads will simultaneously deallocate N*2^M total bytes of memory. When we run java code on machine with 1.5 Tb of RAM with params N=40, M=33, T=30, we see strange freeze on memory deallocation, when I run strace -F -p, I see freeze when on munmap calls, main thread freezes and stop printing "Tick" messages. However, perf record doesn't handle these events and complains about too low --proc-map-timeout. Even encrease of this timeout doesn't help. -XX:+PerfDisableSharedMem also doesn't help. I will attach some excerpts from perf top during freeze PerfTop: 7898 irqs/sec kernel:97.2% exact: 0.0% [4000Hz cycles], (all, 64 CPUs) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 18.84% [kernel] [k] osq_lock 16.53% [kernel] [k] down_read_trylock 8.23% [kernel] [k] up_read 7.41% [kernel] [k] handle_mm_fault 4.02% libjvm.so [.] GenericTaskQueueSet, (MemoryType)5>::steal_best_of_2 3.90% [kernel] [k] page_add_new_anon_rmap 3.10% [kernel] [k] find_vma 2.80% libjvm.so [.] Copy::fill_to_memory_atomic 2.74% [kernel] [k] mem_cgroup_charge_common 2.39% [kernel] [k] clear_page_c_e 1.76% [kernel] [k] free_pcppages_bulk 1.53% [kernel] [k] page_fault 1.46% [kernel] [k] unmap_page_range 1.21% [kernel] [k] release_pages 1.18% [kernel] [k] __mem_cgroup_commit_charge 1.15% [kernel] [k] __do_page_fault 1.08% [kernel] [k] __mem_cgroup_uncharge_common 1.00% [kernel] [k] __list_del_entry 0.89% [kernel] [k] get_pageblock_flags_group 0.76% [kernel] [k] rwsem_spin_on_owner 0.61% libjvm.so [.] G1ParScanThreadState::trim_queue 0.58% [kernel] [k] mem_cgroup_page_lruvec Java code was run on OpenJDK 1.8.0_131-b12 on RHEL 7.4. and also on Oracle JDK 1.8.0_121-b13. However, C reproducer works like a charm without any freezes, it does I suppose simply the same as Java one. Could you please explain why this happens? Is it expected behaviour? Code of reproducers you can download from these gists. https://gist.github.com/ivandasch/491227e74b6536a6ba67090844192300 https://gist.github.com/ivandasch/4647528b8b0dc8324c370b86b9799ece https://gist.github.com/ivandasch/60a649e872089602461ac72fd17508b7 -- Sincerely yours, Ivan Daschinskiy From rob.mckenna at oracle.com Thu Oct 18 13:41:12 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 18 Oct 2018 14:41:12 +0100 Subject: [8u-dev] RFA: 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: <51a20e18-8179-44b8-807c-bb11a1082144@default> References: <51a20e18-8179-44b8-807c-bb11a1082144@default> Message-ID: <20181018134112.GB4277@vimes> Approved -Rob On 18/10/18 05:48, Fairoz Matte wrote: > Hi, > > Please approve the backport of JDK-8211909 to 8u-dev > > JBS issue - https://bugs.openjdk.java.net/browse/JDK-8211909 > > Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025586.html > > Thanks, > Fairoz From vladimir.kozlov at oracle.com Thu Oct 18 15:35:11 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Oct 2018 08:35:11 -0700 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> Message-ID: Roland, It seems you are missing last parameter 'ireg' in assert() call. Vladimir On 10/16/18 5:35 AM, Se?n Coffey wrote: > Thanks for pushing to 11.0.2. This is approved for jdk8u-dev but it looks like it's still subject to 8u review first. > > regards, > Sean. > > > On 15/10/2018 12:21, Se?n Coffey wrote: >> Roland, >> >> do you plan to port this fix to JDK 11.0.x first ? >> >> Regards, >> Sean. >> >> On 15/10/18 12:13, Roland Westrelin wrote: >>> I'd like to backport 8209639 to 8u because one of our customers is >>> hitting it. The change doesn't apply cleanly so here is a webrev for 8u: >>> >>> http://cr.openjdk.java.net/~roland/8209639-8u/webrev.00/ >>> >>> Initial change: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8209639 >>> http://hg.openjdk.java.net/jdk/jdk/rev/76a51e26d0ac >>> >>> Roland. >> > From rwestrel at redhat.com Thu Oct 18 15:48:35 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 18 Oct 2018 17:48:35 +0200 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> Message-ID: > It seems you are missing last parameter 'ireg' in assert() call. Thanks Vladimir. Updated webrev: http://cr.openjdk.java.net/~roland/8209639-8u/webrev.01/ Roland. From vladimir.kozlov at oracle.com Thu Oct 18 15:53:40 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Oct 2018 08:53:40 -0700 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> Message-ID: <20b5eae9-0a92-92df-2767-c8dd11739880@oracle.com> Good. Thanks, Vladimir On 10/18/18 8:48 AM, Roland Westrelin wrote: > >> It seems you are missing last parameter 'ireg' in assert() call. > > Thanks Vladimir. Updated webrev: > > http://cr.openjdk.java.net/~roland/8209639-8u/webrev.01/ > > Roland. > From hohensee at amazon.com Thu Oct 18 16:44:51 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Oct 2018 16:44:51 +0000 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> Message-ID: <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> Hi David, Did the jprt job go ok? If so, Rob or Sean, would you please approve the backport? Thanks, Paul ?On 10/16/18, 7:06 PM, "David Holmes" wrote: On 17/10/2018 8:23 AM, Hohensee, Paul wrote: > Please approve a trivial backport of JDK-8211394 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 > > Webrev: http://cr.openjdk.java.net/~phh/8211394/webrev.00/ > > > Review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html > > The patch applies cleanly net of line numbers, copyright notice > dates, and code that exists in JDK9 but not in JDK8. The result is a one > line change and a new comment. Looks fine. > It builds and runs jdk8 hotspot jtreg test on a linux x64 host. If > needed, would someone please run it through jprt? It doesn't really warrant it but I fired it off anyway. Thanks, David > Thanks, > > Paul > From david.holmes at oracle.com Fri Oct 19 00:29:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Oct 2018 10:29:21 +1000 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> Message-ID: On 19/10/2018 2:44 AM, Hohensee, Paul wrote: > Hi David, > > Did the jprt job go ok? If so, Rob or Sean, would you please approve the backport? Yes - sorry. Didn't expect it to hold this up as it's so trivial. David > Thanks, > > Paul > > ?On 10/16/18, 7:06 PM, "David Holmes" wrote: > > On 17/10/2018 8:23 AM, Hohensee, Paul wrote: > > Please approve a trivial backport of JDK-8211394 to 8u. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 > > > > Webrev: http://cr.openjdk.java.net/~phh/8211394/webrev.00/ > > > > > > Review thread: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html > > > > The patch applies cleanly net of line numbers, copyright notice > > dates, and code that exists in JDK9 but not in JDK8. The result is a one > > line change and a new comment. > > Looks fine. > > > It builds and runs jdk8 hotspot jtreg test on a linux x64 host. If > > needed, would someone please run it through jprt? > > It doesn't really warrant it but I fired it off anyway. > > Thanks, > David > > > Thanks, > > > > Paul > > > > From david.buck at oracle.com Fri Oct 19 00:40:23 2018 From: david.buck at oracle.com (David Buck) Date: Fri, 19 Oct 2018 09:40:23 +0900 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> Message-ID: <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> Hi Paul! Please add an appropriate noreg label [0] to the JBS bug report. Once that is done please consider this approved for push to 8u-dev. Cheers, -Buck [0] https://openjdk.java.net/guide/changePlanning.html#noreg On 2018/10/19 9:29, David Holmes wrote: > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: >> Hi David, >> >> Did the jprt job go ok? If so, Rob or Sean, would you please approve >> the backport? > > Yes - sorry. Didn't expect it to hold this up as it's so trivial. > > David > >> Thanks, >> >> Paul >> >> ?On 10/16/18, 7:06 PM, "David Holmes" wrote: >> >> ???? On 17/10/2018 8:23 AM, Hohensee, Paul wrote: >> ???? > Please approve a trivial backport of JDK-8211394 to 8u. >> ???? > >> ???? > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 >> ???? > >> ???? > Webrev: http://cr.openjdk.java.net/~phh/8211394/webrev.00/ >> ???? > >> ???? > >> ???? > Review thread: >> ???? > >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html >> >> ???? > >> ???? > The patch applies cleanly net of line numbers, copyright notice >> ???? > dates, and code that exists in JDK9 but not in JDK8. The result >> is a one >> ???? > line change and a new comment. >> ???? Looks fine. >> ???? > It builds and runs jdk8 hotspot jtreg test on a linux x64 host. If >> ???? > needed, would someone please run it through jprt? >> ???? It doesn't really warrant it but I fired it off anyway. >> ???? Thanks, >> ???? David >> ???? > Thanks, >> ???? > >> ???? > Paul >> ???? > >> From tobias.hartmann at oracle.com Fri Oct 19 07:18:39 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 19 Oct 2018 09:18:39 +0200 Subject: [8u] RFR and RFA: 8172850: Anti-dependency on membar causes crash in register allocator due to invalid instruction scheduling In-Reply-To: References: Message-ID: <62ddd3de-28fe-bb25-51b4-f603c0549e21@oracle.com> Hi Roland, this looks good to me (but I'm not a 8u reviewer). Best regards, Tobias On 15.10.18 13:10, Roland Westrelin wrote: > > I'd like to backport 8172850 to 8u because I'd also like to backport a > change that depends on it: 8209639. The change doesn't apply cleanly. So > here is an updated webrev: > > http://cr.openjdk.java.net/~roland/8172850-8u/webrev.00/ > > Initial change: > > https://bugs.openjdk.java.net/browse/JDK-8172850 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/6bf44f4e2a1e > > Roland. > From dalibor.topic at oracle.com Fri Oct 19 09:49:54 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 19 Oct 2018 11:49:54 +0200 Subject: Question of backport AppCDS to openjdk8u In-Reply-To: References: Message-ID: <863c0d9c-d9dc-9f50-2ff4-b0a2a6b84b73@oracle.com> On 17.10.2018 11:51, Volker Simonis wrote: > > That said, I think it will be a huge change and I'm not sure the > current (and future) OpenJDK 8u maintainers will want to support it. > But that's something they'll have to decide :) I agree. I think it's best to leave that decision to future (if any) OpenJDK 8u maintainers, i.e. to re-raise it sometime after January. cheers, dalibor topic -- 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 jvanek at redhat.com Fri Oct 19 10:34:36 2018 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 19 Oct 2018 12:34:36 +0200 Subject: Please allow backport of "Generated javadoc scattered all over the plac" to jdk8 Message-ID: <7953f97f-0b6d-e240-4d17-f4b04c9a16cd@redhat.com> https://bugs.openjdk.java.net/browse/JDK-8154313 http://cr.openjdk.java.net/~jvanek/8154313/ Hi! This was proposed long time ago into JDK8, however never reached it asjdk9 was in development. It was pushed into it, and with small changes over 10 ad 11 lives up to now. We are keeping this pacth locally in rpms for jdk8, and as fas as I can tell, the zipped javadoc is useful and used thing/ From my view, it is missed in jdk8. Can I kindly ask for considering it as enhancement update for jdk8u? Best regards from CZ J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From rob.mckenna at oracle.com Fri Oct 19 13:02:55 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 19 Oct 2018 14:02:55 +0100 Subject: [jdk8u-dev] Request for approval: 8200719 - Cannot connect to IPv6 host when exists any active network interface without IPv6 address Message-ID: <20181019130255.GA4921@vimes> Looking to backport this fix, patch applies cleanly: https://bugs.openjdk.java.net/browse/JDK-8200719 http://hg.openjdk.java.net/jdk/jdk/rev/bc1c7e41e285 http://mail.openjdk.java.net/pipermail/net-dev/2018-April/011335.html -Rob From sean.coffey at oracle.com Fri Oct 19 13:04:53 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 19 Oct 2018 14:04:53 +0100 Subject: [jdk8u-dev] Request for approval: 8200719 - Cannot connect to IPv6 host when exists any active network interface without IPv6 address In-Reply-To: <20181019130255.GA4921@vimes> References: <20181019130255.GA4921@vimes> Message-ID: <954afbec-8185-0f8f-2616-93d393d3d113@oracle.com> Approved. Regards, Sean. On 19/10/18 14:02, Rob McKenna wrote: > Looking to backport this fix, patch applies cleanly: > > https://bugs.openjdk.java.net/browse/JDK-8200719 > http://hg.openjdk.java.net/jdk/jdk/rev/bc1c7e41e285 > http://mail.openjdk.java.net/pipermail/net-dev/2018-April/011335.html > > -Rob > From thomas.schatzl at oracle.com Fri Oct 19 13:23:27 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 19 Oct 2018 15:23:27 +0200 Subject: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <9D007BB7-F6FE-4A24-81BC-6629B68DEF70@amazon.com> References: <9D007BB7-F6FE-4A24-81BC-6629B68DEF70@amazon.com> Message-ID: Hi Paul, On Fri, 2018-10-12 at 00:03 +0000, Hohensee, Paul wrote: > Please review a backport to jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > The backport is slightly different from the JDK11 patch due to G1 > refactoring, hence my request for new review. I?ll ask for jdk8u > approval once the backport is reviewed. > I backported two jtreg tests from JDK11, which pass. Also, all the > hotspot gc jtreg tests pass as well as they do for jdk8u-dev. I think the backport is good. Others need to decide whether this change is worth backporting. > There was a CSR involved, > https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to > be re-approved for jdk8u as well, and if so, what?s the process? CC'ed Joe Darcy as I am not sure either. Thanks, Thomas From hohensee at amazon.com Fri Oct 19 16:54:25 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Oct 2018 16:54:25 +0000 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> Message-ID: <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> Done and pushed. Thanks! ?On 10/18/18, 8:41 PM, "David Buck" wrote: Hi Paul! Please add an appropriate noreg label [0] to the JBS bug report. Once that is done please consider this approved for push to 8u-dev. Cheers, -Buck [0] https://openjdk.java.net/guide/changePlanning.html#noreg On 2018/10/19 9:29, David Holmes wrote: > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: >> Hi David, >> >> Did the jprt job go ok? If so, Rob or Sean, would you please approve >> the backport? > > Yes - sorry. Didn't expect it to hold this up as it's so trivial. > > David > >> Thanks, >> >> Paul >> >> On 10/16/18, 7:06 PM, "David Holmes" wrote: >> >> On 17/10/2018 8:23 AM, Hohensee, Paul wrote: >> > Please approve a trivial backport of JDK-8211394 to 8u. >> > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 >> > >> > Webrev: http://cr.openjdk.java.net/~phh/8211394/webrev.00/ >> > >> > >> > Review thread: >> > >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html >> >> > >> > The patch applies cleanly net of line numbers, copyright notice >> > dates, and code that exists in JDK9 but not in JDK8. The result >> is a one >> > line change and a new comment. >> Looks fine. >> > It builds and runs jdk8 hotspot jtreg test on a linux x64 host. If >> > needed, would someone please run it through jprt? >> It doesn't really warrant it but I fired it off anyway. >> Thanks, >> David >> > Thanks, >> > >> > Paul >> > >> From hohensee at amazon.com Fri Oct 19 17:10:49 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Oct 2018 17:10:49 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Message-ID: <4B638999-9360-49FC-B423-41922357EF1C@amazon.com> Thanks, Thomas. Cutting distribution down to jdk8u-dev now, and asking for backport approval. Here's the email discussion: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Backport argument: At Amazon, we discovered more than a year ago that the MemoryPoolMXBean Usage attribute isn't very useful for monitoring, and more importantly, alarming on, excessive heap use. That's because it's an instantaneous measurement, so it includes yet-to-collected garbage. We moved to using CollectionUsage (usage after the last GC that affected the memory pool) instead as a measure of the long-term heap occupancy. If it's trending up without the app changing, there may be a memory leak, or just more load that might require a -Xmx increase. Once moved, however, we found that G1 was effectively useless to us because it reported incorrect values for the G1 old gen: mixed collections weren't updating its CollectionUsage. We patched our internal jdk8 distro, and last June, openjdk11. This is a backport of the latter. We believe that anyone monitoring server apps running G1 in jdk8u needs this fix. Thanks, Paul ?On 10/19/18, 9:24 AM, "Thomas Schatzl" wrote: Hi Paul, On Fri, 2018-10-12 at 00:03 +0000, Hohensee, Paul wrote: > Please review a backport to jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > The backport is slightly different from the JDK11 patch due to G1 > refactoring, hence my request for new review. I?ll ask for jdk8u > approval once the backport is reviewed. > I backported two jtreg tests from JDK11, which pass. Also, all the > hotspot gc jtreg tests pass as well as they do for jdk8u-dev. I think the backport is good. Others need to decide whether this change is worth backporting. > There was a CSR involved, > https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to > be re-approved for jdk8u as well, and if so, what?s the process? CC'ed Joe Darcy as I am not sure either. Thanks, Thomas From navy.xliu at gmail.com Fri Oct 19 22:14:21 2018 From: navy.xliu at gmail.com (Liu Xin) Date: Fri, 19 Oct 2018 15:14:21 -0700 Subject: [8u] Request for approval for CR 8129560 - private exponent of TestKeyPairGenerator.java needs to comply with FIPS 186-4 Message-ID: Hi, jdk8u reviewers, Could you take a look at this tiny backport? I update the private exponent to 65537 so we can pass the regression test on more platforms. BUGS: https://bugs.openjdk.java.net/browse/JDK-8129560 Webrev: http://cr.openjdk.java.net/~phh/8129560/webrev.00/ I don?t have permission to check in. Paul will check in on behalf of me if reviewers approve it. Thanks, --lx From ivan.gerasimov at oracle.com Sat Oct 20 03:03:58 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Oct 2018 20:03:58 -0700 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> Message-ID: Hello! I'm curious how the jdk build passed successfully. I see the following error in JPRT now (failing on all platforms): /s/hotspot/src/share/vm/classfile/verificationType.cpp: In member function 'bool VerificationType::is_reference_assignable_from(const VerificationType&, ClassVerifier*, bool, Thread*) const':/s/hotspot/src/share/vm/classfile/verificationType.cpp:102: error: expected primary-expression before '*' token or, on Windows: \s\hotspot\src\share\vm\classfile\verificationType.cpp(102) : error C2275: 'Thread' : illegal use of this type as an expression C:\jprt\T\P1\020004.robm\s\hotspot\src\share\vm\runtime/thread.hpp(102) : see declaration of 'Thread' I created JDK-8212709 to backout the backport for now. With kind regards, Ivan On 10/19/18 9:54 AM, Hohensee, Paul wrote: > Done and pushed. Thanks! > > ?On 10/18/18, 8:41 PM, "David Buck" wrote: > > Hi Paul! > > Please add an appropriate noreg label [0] to the JBS bug report. > > Once that is done please consider this approved for push to 8u-dev. > > Cheers, > -Buck > > [0] https://openjdk.java.net/guide/changePlanning.html#noreg > > On 2018/10/19 9:29, David Holmes wrote: > > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: > >> Hi David, > >> > >> Did the jprt job go ok? If so, Rob or Sean, would you please approve > >> the backport? > > > > Yes - sorry. Didn't expect it to hold this up as it's so trivial. > > > > David > > > >> Thanks, > >> > >> Paul > >> > >> On 10/16/18, 7:06 PM, "David Holmes" wrote: > >> > >> On 17/10/2018 8:23 AM, Hohensee, Paul wrote: > >> > Please approve a trivial backport of JDK-8211394 to 8u. > >> > > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 > >> > > >> > Webrev: http://cr.openjdk.java.net/~phh/8211394/webrev.00/ > >> > > >> > > >> > Review thread: > >> > > >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html > >> > >> > > >> > The patch applies cleanly net of line numbers, copyright notice > >> > dates, and code that exists in JDK9 but not in JDK8. The result > >> is a one > >> > line change and a new comment. > >> Looks fine. > >> > It builds and runs jdk8 hotspot jtreg test on a linux x64 host. If > >> > needed, would someone please run it through jprt? > >> It doesn't really warrant it but I fired it off anyway. > >> Thanks, > >> David > >> > Thanks, > >> > > >> > Paul > >> > > >> > > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Sat Oct 20 03:26:30 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Oct 2018 20:26:30 -0700 Subject: [8u-dev] build failure - Backout backport of JDK-8211394 from jdk 8u-dev Message-ID: Hello! This is a request to backout the backport of the fix for JDK-8211394 as it causes build failure on all platforms. I've just double-checked, and trying to build fresh jdk8u-dev from the top hg revision failed. With the fix backed out, it build fine again. The webrev with the anti-delta: BUGURL: https://bugs.openjdk.java.net/browse/JDK-8212709 WEBREV: http://cr.openjdk.java.net/~igerasim/8212709/00/webrev/ Would you please approve to push it to restore build-ability? -- With kind regards, Ivan Gerasimov From david.buck at oracle.com Sat Oct 20 03:38:15 2018 From: david.buck at oracle.com (David Buck) Date: Sat, 20 Oct 2018 12:38:15 +0900 Subject: [8u-dev] build failure - Backout backport of JDK-8211394 from jdk 8u-dev In-Reply-To: References: Message-ID: <6372e393-600f-c65b-f70d-683fa755cc2a@oracle.com> approved We need to better understand how this happened. I think we should continue that conversation on the original approval thread. But for now, let's get 8u-dev building again. Thanks for the quick action. Cheers, -Buck On 2018/10/20 12:26, Ivan Gerasimov wrote: > Hello! > > This is a request to backout the backport of the fix for JDK-8211394 as > it causes build failure on all platforms. > > I've just double-checked, and trying to build fresh jdk8u-dev from the > top hg revision failed. > > With the fix backed out, it build fine again. > > The webrev with the anti-delta: > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8212709 > WEBREV: http://cr.openjdk.java.net/~igerasim/8212709/00/webrev/ > > Would you please approve to push it to restore build-ability? > From ivan.gerasimov at oracle.com Sat Oct 20 03:47:51 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Oct 2018 20:47:51 -0700 Subject: [8u-dev] build failure - Backout backport of JDK-8211394 from jdk 8u-dev In-Reply-To: <6372e393-600f-c65b-f70d-683fa755cc2a@oracle.com> References: <6372e393-600f-c65b-f70d-683fa755cc2a@oracle.com> Message-ID: Thanks David! Pushed. With kind regards, Ivan On 10/19/18 8:38 PM, David Buck wrote: > approved > > We need to better understand how this happened. I think we should > continue that conversation on the original approval thread. But for > now, let's get 8u-dev building again. Thanks for the quick action. > > Cheers, > -Buck > > On 2018/10/20 12:26, Ivan Gerasimov wrote: >> Hello! >> >> This is a request to backout the backport of the fix for JDK-8211394 >> as it causes build failure on all platforms. >> >> I've just double-checked, and trying to build fresh jdk8u-dev from >> the top hg revision failed. >> >> With the fix backed out, it build fine again. >> >> The webrev with the anti-delta: >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8212709 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8212709/00/webrev/ >> >> Would you please approve to push it to restore build-ability? >> > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Sat Oct 20 04:01:13 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Oct 2018 21:01:13 -0700 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> Message-ID: The build issue seems to be due that the actual source diff [1] contained this change: + from_field_is_protected, TRAPS); while the webrev [2] had this: + from_field_is_protected, THREAD); which, I assume, was building fine. [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/raw-rev/fbc668a76c00 [2] http://cr.openjdk.java.net/~phh/8211394/webrev.00/src/share/vm/classfile/verificationType.cpp.patch With kind regards, Ivan On 10/19/18 8:03 PM, Ivan Gerasimov wrote: > Hello! > > I'm curious how the jdk build passed successfully. > > I see the following error in JPRT now (failing on all platforms): > > /s/hotspot/src/share/vm/classfile/verificationType.cpp: In member > function 'bool VerificationType::is_reference_assignable_from(const > VerificationType&, ClassVerifier*, bool, Thread*) > const':/s/hotspot/src/share/vm/classfile/verificationType.cpp:102: > error: expected primary-expression before '*' token > > or, on Windows: > > \s\hotspot\src\share\vm\classfile\verificationType.cpp(102) : error > C2275: 'Thread' : illegal use of this type as an expression > C:\jprt\T\P1\020004.robm\s\hotspot\src\share\vm\runtime/thread.hpp(102) > : see declaration of 'Thread' > > I created JDK-8212709 to backout the backport for now. > > With kind regards, > > Ivan > > > On 10/19/18 9:54 AM, Hohensee, Paul wrote: >> Done and pushed. Thanks! >> >> ?On 10/18/18, 8:41 PM, "David Buck" wrote: >> >> Hi Paul! >> Please add an appropriate noreg label [0] to the JBS bug >> report. >> Once that is done please consider this approved for push to >> 8u-dev. >> Cheers, >> -Buck >> [0] https://openjdk.java.net/guide/changePlanning.html#noreg >> On 2018/10/19 9:29, David Holmes wrote: >> > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: >> >> Hi David, >> >> >> >> Did the jprt job go ok? If so, Rob or Sean, would you please >> approve >> >> the backport? >> > >> > Yes - sorry. Didn't expect it to hold this up as it's so trivial. >> > >> > David >> > >> >> Thanks, >> >> >> >> Paul >> >> >> >> On 10/16/18, 7:06 PM, "David Holmes" >> wrote: >> >> >> >> On 17/10/2018 8:23 AM, Hohensee, Paul wrote: >> >> > Please approve a trivial backport of JDK-8211394 to 8u. >> >> > >> >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 >> >> > >> >> > Webrev: >> http://cr.openjdk.java.net/~phh/8211394/webrev.00/ >> >> > >> >> > >> >> > Review thread: >> >> > >> >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html >> >> >> >> > >> >> > The patch applies cleanly net of line numbers, >> copyright notice >> >> > dates, and code that exists in JDK9 but not in JDK8. >> The result >> >> is a one >> >> > line change and a new comment. >> >> Looks fine. >> >> > It builds and runs jdk8 hotspot jtreg test on a linux >> x64 host. If >> >> > needed, would someone please run it through jprt? >> >> It doesn't really warrant it but I fired it off anyway. >> >> Thanks, >> >> David >> >> > Thanks, >> >> > >> >> > Paul >> >> > >> >> >> > -- With kind regards, Ivan Gerasimov From david.buck at oracle.com Sat Oct 20 09:11:36 2018 From: david.buck at oracle.com (david buck) Date: Sat, 20 Oct 2018 18:11:36 +0900 Subject: [8u] RFA 8155635: C2: Mixed unsafe oop accesses break alias analysis Message-ID: <0298e746-0fb5-d147-b09f-b3316eb21c62@oracle.com> Hi! Please approve the following backport from JDK 9 to JDK 8: bug report: https://bugs.openjdk.java.net/browse/JDK-8155635 webrev: http://cr.openjdk.java.net/~dbuck/jdk8155635_jdk8_ver01/ backport code review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/031004.html Cheers, -Buck From david.holmes at oracle.com Sun Oct 21 21:43:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Oct 2018 07:43:07 +1000 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> Message-ID: <4ad237e9-ccad-e85d-2a6c-4b907bc41658@oracle.com> On 20/10/2018 2:01 PM, Ivan Gerasimov wrote: > The build issue seems to be due that the actual source diff [1] > contained this change: > > +????????????????????????????????????????? from_field_is_protected, TRAPS); > > while the webrev [2] had this: > > +????????????????????????????????????????? from_field_is_protected, > THREAD); > > which, I assume, was building fine. Yes the patch from the webrev was put through JPRT and everything was fine. Thanks for doing the backout Ivan. David H. > [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/raw-rev/fbc668a76c00 > [2] > http://cr.openjdk.java.net/~phh/8211394/webrev.00/src/share/vm/classfile/verificationType.cpp.patch > > > With kind regards, > Ivan > > On 10/19/18 8:03 PM, Ivan Gerasimov wrote: >> Hello! >> >> I'm curious how the jdk build passed successfully. >> >> I see the following error in JPRT now (failing on all platforms): >> >> /s/hotspot/src/share/vm/classfile/verificationType.cpp: In member >> function 'bool VerificationType::is_reference_assignable_from(const >> VerificationType&, ClassVerifier*, bool, Thread*) >> const':/s/hotspot/src/share/vm/classfile/verificationType.cpp:102: >> error: expected primary-expression before '*' token >> >> or, on Windows: >> >> \s\hotspot\src\share\vm\classfile\verificationType.cpp(102) : error >> C2275: 'Thread' : illegal use of this type as an expression >> C:\jprt\T\P1\020004.robm\s\hotspot\src\share\vm\runtime/thread.hpp(102) : >> see declaration of 'Thread' >> >> I created JDK-8212709 to backout the backport for now. >> >> With kind regards, >> >> Ivan >> >> >> On 10/19/18 9:54 AM, Hohensee, Paul wrote: >>> Done and pushed. Thanks! >>> >>> ?On 10/18/18, 8:41 PM, "David Buck" wrote: >>> >>> ???? Hi Paul! >>> ????????? Please add an appropriate noreg label [0] to the JBS bug >>> report. >>> ????????? Once that is done please consider this approved for push to >>> 8u-dev. >>> ????????? Cheers, >>> ???? -Buck >>> ????????? [0] https://openjdk.java.net/guide/changePlanning.html#noreg >>> ????????? On 2018/10/19 9:29, David Holmes wrote: >>> ???? > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: >>> ???? >> Hi David, >>> ???? >> >>> ???? >> Did the jprt job go ok? If so, Rob or Sean, would you please >>> approve >>> ???? >> the backport? >>> ???? > >>> ???? > Yes - sorry. Didn't expect it to hold this up as it's so trivial. >>> ???? > >>> ???? > David >>> ???? > >>> ???? >> Thanks, >>> ???? >> >>> ???? >> Paul >>> ???? >> >>> ???? >> On 10/16/18, 7:06 PM, "David Holmes" >>> wrote: >>> ???? >> >>> ???? >>????? On 17/10/2018 8:23 AM, Hohensee, Paul wrote: >>> ???? >>????? > Please approve a trivial backport of JDK-8211394 to 8u. >>> ???? >>????? > >>> ???? >>????? > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 >>> ???? >>????? > >>> ???? >>????? > Webrev: >>> http://cr.openjdk.java.net/~phh/8211394/webrev.00/ >>> ???? >>????? > >>> ???? >>????? > >>> ???? >>????? > Review thread: >>> ???? >>????? > >>> ???? >> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html >>> >>> ???? >> >>> ???? >>????? > >>> ???? >>????? > The patch applies cleanly net of line numbers, >>> copyright notice >>> ???? >>????? > dates, and code that exists in JDK9 but not in JDK8. >>> The result >>> ???? >> is a one >>> ???? >>????? > line change and a new comment. >>> ???? >>????? Looks fine. >>> ???? >>????? > It builds and runs jdk8 hotspot jtreg test on a linux >>> x64 host. If >>> ???? >>????? > needed, would someone please run it through jprt? >>> ???? >>????? It doesn't really warrant it but I fired it off anyway. >>> ???? >>????? Thanks, >>> ???? >>????? David >>> ???? >>????? > Thanks, >>> ???? >>????? > >>> ???? >>????? > Paul >>> ???? >>????? > >>> ???? >> >>> >> > From sean.coffey at oracle.com Mon Oct 22 08:43:40 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 22 Oct 2018 09:43:40 +0100 Subject: [8u] Request for approval for CR 8129560 - private exponent of TestKeyPairGenerator.java needs to comply with FIPS 186-4 In-Reply-To: References: Message-ID: <1c10b3ca-5b2a-4bf4-2259-1f26f7918b6a@oracle.com> Approved. Regards, Sean. On 19/10/18 23:14, Liu Xin wrote: > > Hi, jdk8u reviewers, > > Could you take a look at this tiny backport? I update the private > exponent to 65537 so we can pass the regression test on more platforms. > > BUGS:https://bugs.openjdk.java.net/browse/JDK-8129560 > > Webrev:http://cr.openjdk.java.net/~phh/8129560/webrev.00/ > > > I don?t have permission to check in. Paul will check in on behalf of > me if reviewers approve it. > > > Thanks, > > --lx > From sean.coffey at oracle.com Mon Oct 22 09:21:09 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 22 Oct 2018 10:21:09 +0100 Subject: [8u] RFA 8155635: C2: Mixed unsafe oop accesses break alias analysis In-Reply-To: <0298e746-0fb5-d147-b09f-b3316eb21c62@oracle.com> References: <0298e746-0fb5-d147-b09f-b3316eb21c62@oracle.com> Message-ID: Approved. Regards, Sean. On 20/10/18 10:11, david buck wrote: > Hi! > > Please approve the following backport from JDK 9 to JDK 8: > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8155635 > > webrev: > http://cr.openjdk.java.net/~dbuck/jdk8155635_jdk8_ver01/ > > backport code review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/031004.html > > > Cheers, > -Buck From hohensee at amazon.com Mon Oct 22 14:55:32 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 22 Oct 2018 14:55:32 +0000 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: <4ad237e9-ccad-e85d-2a6c-4b907bc41658@oracle.com> References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> <4ad237e9-ccad-e85d-2a6c-4b907bc41658@oracle.com> Message-ID: <5EA2DE32-0E42-4651-8CD6-B316040FD477@amazon.com> Yes, my bad on this, and +1 on thanks for backing it out. I'll push the correct patch today if that's ok. Paul ?On 10/21/18, 2:43 PM, "David Holmes" wrote: On 20/10/2018 2:01 PM, Ivan Gerasimov wrote: > The build issue seems to be due that the actual source diff [1] > contained this change: > > + from_field_is_protected, TRAPS); > > while the webrev [2] had this: > > + from_field_is_protected, > THREAD); > > which, I assume, was building fine. Yes the patch from the webrev was put through JPRT and everything was fine. Thanks for doing the backout Ivan. David H. > [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/raw-rev/fbc668a76c00 > [2] > http://cr.openjdk.java.net/~phh/8211394/webrev.00/src/share/vm/classfile/verificationType.cpp.patch > > > With kind regards, > Ivan > > On 10/19/18 8:03 PM, Ivan Gerasimov wrote: >> Hello! >> >> I'm curious how the jdk build passed successfully. >> >> I see the following error in JPRT now (failing on all platforms): >> >> /s/hotspot/src/share/vm/classfile/verificationType.cpp: In member >> function 'bool VerificationType::is_reference_assignable_from(const >> VerificationType&, ClassVerifier*, bool, Thread*) >> const':/s/hotspot/src/share/vm/classfile/verificationType.cpp:102: >> error: expected primary-expression before '*' token >> >> or, on Windows: >> >> \s\hotspot\src\share\vm\classfile\verificationType.cpp(102) : error >> C2275: 'Thread' : illegal use of this type as an expression >> C:\jprt\T\P1\020004.robm\s\hotspot\src\share\vm\runtime/thread.hpp(102) : >> see declaration of 'Thread' >> >> I created JDK-8212709 to backout the backport for now. >> >> With kind regards, >> >> Ivan >> >> >> On 10/19/18 9:54 AM, Hohensee, Paul wrote: >>> Done and pushed. Thanks! >>> >>> On 10/18/18, 8:41 PM, "David Buck" wrote: >>> >>> Hi Paul! >>> Please add an appropriate noreg label [0] to the JBS bug >>> report. >>> Once that is done please consider this approved for push to >>> 8u-dev. >>> Cheers, >>> -Buck >>> [0] https://openjdk.java.net/guide/changePlanning.html#noreg >>> On 2018/10/19 9:29, David Holmes wrote: >>> > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: >>> >> Hi David, >>> >> >>> >> Did the jprt job go ok? If so, Rob or Sean, would you please >>> approve >>> >> the backport? >>> > >>> > Yes - sorry. Didn't expect it to hold this up as it's so trivial. >>> > >>> > David >>> > >>> >> Thanks, >>> >> >>> >> Paul >>> >> >>> >> On 10/16/18, 7:06 PM, "David Holmes" >>> wrote: >>> >> >>> >> On 17/10/2018 8:23 AM, Hohensee, Paul wrote: >>> >> > Please approve a trivial backport of JDK-8211394 to 8u. >>> >> > >>> >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 >>> >> > >>> >> > Webrev: >>> http://cr.openjdk.java.net/~phh/8211394/webrev.00/ >>> >> > >>> >> > >>> >> > Review thread: >>> >> > >>> >> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html >>> >>> >> >>> >> > >>> >> > The patch applies cleanly net of line numbers, >>> copyright notice >>> >> > dates, and code that exists in JDK9 but not in JDK8. >>> The result >>> >> is a one >>> >> > line change and a new comment. >>> >> Looks fine. >>> >> > It builds and runs jdk8 hotspot jtreg test on a linux >>> x64 host. If >>> >> > needed, would someone please run it through jprt? >>> >> It doesn't really warrant it but I fired it off anyway. >>> >> Thanks, >>> >> David >>> >> > Thanks, >>> >> > >>> >> > Paul >>> >> > >>> >> >>> >> > From sean.coffey at oracle.com Mon Oct 22 15:00:39 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 22 Oct 2018 16:00:39 +0100 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: <5EA2DE32-0E42-4651-8CD6-B316040FD477@amazon.com> References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> <4ad237e9-ccad-e85d-2a6c-4b907bc41658@oracle.com> <5EA2DE32-0E42-4651-8CD6-B316040FD477@amazon.com> Message-ID: <2e63218e-cd90-315b-cd21-93d8d44c74bf@oracle.com> Paul, please file a new bug to use for the 2nd push. Add details of old push, backout etc. Regards, Sean. On 22/10/18 15:55, Hohensee, Paul wrote: > Yes, my bad on this, and +1 on thanks for backing it out. I'll push the correct patch today if that's ok. > > Paul > > ?On 10/21/18, 2:43 PM, "David Holmes" wrote: > > On 20/10/2018 2:01 PM, Ivan Gerasimov wrote: > > The build issue seems to be due that the actual source diff [1] > > contained this change: > > > > + from_field_is_protected, TRAPS); > > > > while the webrev [2] had this: > > > > + from_field_is_protected, > > THREAD); > > > > which, I assume, was building fine. > > Yes the patch from the webrev was put through JPRT and everything was fine. > > Thanks for doing the backout Ivan. > > David H. > > > [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/raw-rev/fbc668a76c00 > > [2] > > http://cr.openjdk.java.net/~phh/8211394/webrev.00/src/share/vm/classfile/verificationType.cpp.patch > > > > > > With kind regards, > > Ivan > > > > On 10/19/18 8:03 PM, Ivan Gerasimov wrote: > >> Hello! > >> > >> I'm curious how the jdk build passed successfully. > >> > >> I see the following error in JPRT now (failing on all platforms): > >> > >> /s/hotspot/src/share/vm/classfile/verificationType.cpp: In member > >> function 'bool VerificationType::is_reference_assignable_from(const > >> VerificationType&, ClassVerifier*, bool, Thread*) > >> const':/s/hotspot/src/share/vm/classfile/verificationType.cpp:102: > >> error: expected primary-expression before '*' token > >> > >> or, on Windows: > >> > >> \s\hotspot\src\share\vm\classfile\verificationType.cpp(102) : error > >> C2275: 'Thread' : illegal use of this type as an expression > >> C:\jprt\T\P1\020004.robm\s\hotspot\src\share\vm\runtime/thread.hpp(102) : > >> see declaration of 'Thread' > >> > >> I created JDK-8212709 to backout the backport for now. > >> > >> With kind regards, > >> > >> Ivan > >> > >> > >> On 10/19/18 9:54 AM, Hohensee, Paul wrote: > >>> Done and pushed. Thanks! > >>> > >>> On 10/18/18, 8:41 PM, "David Buck" wrote: > >>> > >>> Hi Paul! > >>> Please add an appropriate noreg label [0] to the JBS bug > >>> report. > >>> Once that is done please consider this approved for push to > >>> 8u-dev. > >>> Cheers, > >>> -Buck > >>> [0] https://openjdk.java.net/guide/changePlanning.html#noreg > >>> On 2018/10/19 9:29, David Holmes wrote: > >>> > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: > >>> >> Hi David, > >>> >> > >>> >> Did the jprt job go ok? If so, Rob or Sean, would you please > >>> approve > >>> >> the backport? > >>> > > >>> > Yes - sorry. Didn't expect it to hold this up as it's so trivial. > >>> > > >>> > David > >>> > > >>> >> Thanks, > >>> >> > >>> >> Paul > >>> >> > >>> >> On 10/16/18, 7:06 PM, "David Holmes" > >>> wrote: > >>> >> > >>> >> On 17/10/2018 8:23 AM, Hohensee, Paul wrote: > >>> >> > Please approve a trivial backport of JDK-8211394 to 8u. > >>> >> > > >>> >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 > >>> >> > > >>> >> > Webrev: > >>> http://cr.openjdk.java.net/~phh/8211394/webrev.00/ > >>> >> > > >>> >> > > >>> >> > Review thread: > >>> >> > > >>> >> > >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html > >>> > >>> >> > >>> >> > > >>> >> > The patch applies cleanly net of line numbers, > >>> copyright notice > >>> >> > dates, and code that exists in JDK9 but not in JDK8. > >>> The result > >>> >> is a one > >>> >> > line change and a new comment. > >>> >> Looks fine. > >>> >> > It builds and runs jdk8 hotspot jtreg test on a linux > >>> x64 host. If > >>> >> > needed, would someone please run it through jprt? > >>> >> It doesn't really warrant it but I fired it off anyway. > >>> >> Thanks, > >>> >> David > >>> >> > Thanks, > >>> >> > > >>> >> > Paul > >>> >> > > >>> >> > >>> > >> > > > > From hohensee at amazon.com Mon Oct 22 15:44:07 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 22 Oct 2018 15:44:07 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <4B638999-9360-49FC-B423-41922357EF1C@amazon.com> References: <4B638999-9360-49FC-B423-41922357EF1C@amazon.com> Message-ID: Trying again with correct request template. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.06/ Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Thanks, Paul ?On 10/19/18, 10:11 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Thanks, Thomas. Cutting distribution down to jdk8u-dev now, and asking for backport approval. Here's the email discussion: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Backport argument: At Amazon, we discovered more than a year ago that the MemoryPoolMXBean Usage attribute isn't very useful for monitoring, and more importantly, alarming on, excessive heap use. That's because it's an instantaneous measurement, so it includes yet-to-collected garbage. We moved to using CollectionUsage (usage after the last GC that affected the memory pool) instead as a measure of the long-term heap occupancy. If it's trending up without the app changing, there may be a memory leak, or just more load that might require a -Xmx increase. Once moved, however, we found that G1 was effectively useless to us because it reported incorrect values for the G1 old gen: mixed collections weren't updating its CollectionUsage. We patched our internal jdk8 distro, and last June, openjdk11. This is a backport of the latter. We believe that anyone monitoring server apps running G1 in jdk8u needs this fix. Thanks, Paul On 10/19/18, 9:24 AM, "Thomas Schatzl" wrote: Hi Paul, On Fri, 2018-10-12 at 00:03 +0000, Hohensee, Paul wrote: > Please review a backport to jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > The backport is slightly different from the JDK11 patch due to G1 > refactoring, hence my request for new review. I?ll ask for jdk8u > approval once the backport is reviewed. > I backported two jtreg tests from JDK11, which pass. Also, all the > hotspot gc jtreg tests pass as well as they do for jdk8u-dev. I think the backport is good. Others need to decide whether this change is worth backporting. > There was a CSR involved, > https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to > be re-approved for jdk8u as well, and if so, what?s the process? CC'ed Joe Darcy as I am not sure either. Thanks, Thomas From hohensee at amazon.com Mon Oct 22 19:14:22 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 22 Oct 2018 19:14:22 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: References: <4B638999-9360-49FC-B423-41922357EF1C@amazon.com> Message-ID: <536354B0-3B58-4F96-BDE3-505AF26B73A9@amazon.com> Typo, webrev s/b webrev.05. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html ?On 10/22/18, 8:45 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Trying again with correct request template. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.06/ Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Thanks, Paul On 10/19/18, 10:11 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Thanks, Thomas. Cutting distribution down to jdk8u-dev now, and asking for backport approval. Here's the email discussion: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Backport argument: At Amazon, we discovered more than a year ago that the MemoryPoolMXBean Usage attribute isn't very useful for monitoring, and more importantly, alarming on, excessive heap use. That's because it's an instantaneous measurement, so it includes yet-to-collected garbage. We moved to using CollectionUsage (usage after the last GC that affected the memory pool) instead as a measure of the long-term heap occupancy. If it's trending up without the app changing, there may be a memory leak, or just more load that might require a -Xmx increase. Once moved, however, we found that G1 was effectively useless to us because it reported incorrect values for the G1 old gen: mixed collections weren't updating its CollectionUsage. We patched our internal jdk8 distro, and last June, openjdk11. This is a backport of the latter. We believe that anyone monitoring server apps running G1 in jdk8u needs this fix. Thanks, Paul On 10/19/18, 9:24 AM, "Thomas Schatzl" wrote: Hi Paul, On Fri, 2018-10-12 at 00:03 +0000, Hohensee, Paul wrote: > Please review a backport to jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > The backport is slightly different from the JDK11 patch due to G1 > refactoring, hence my request for new review. I?ll ask for jdk8u > approval once the backport is reviewed. > I backported two jtreg tests from JDK11, which pass. Also, all the > hotspot gc jtreg tests pass as well as they do for jdk8u-dev. I think the backport is good. Others need to decide whether this change is worth backporting. > There was a CSR involved, > https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to > be re-approved for jdk8u as well, and if so, what?s the process? CC'ed Joe Darcy as I am not sure either. Thanks, Thomas From valerie.peng at oracle.com Mon Oct 22 22:17:40 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 22 Oct 2018 15:17:40 -0700 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> Message-ID: Martin, Sean asked me to help review this backport. Are the changes for 8u identical to those for JDK 12 (minus the path differences)? Is there any 8u specific modifications? Thanks, Valerie On 10/15/2018 8:15 AM, Martin Balao wrote: > Hi Sean, > > Any updates on this? > > Kind regards, > Martin.- > > On Tue, Sep 25, 2018 at 6:56 PM, Se?n Coffey wrote: > >> Thanks for logging this request Martin. Looking into this and hope to >> reply shortly. >> >> regards, >> Sean. >> >> >> >> On 25/09/2018 10:07, Martin Balao wrote: >> >>> Hi, >>> >>> I'd like to request an enhancement backport approval for JDK-8029661 [1]. >>> >>> Supporting TLS v1.2 algorithms in SunPKCS11 crypto provider would be >>> highly >>> beneficial for operating in a FIPS-140 environment. This is highly >>> critical >>> for both security and compliance reasons to many OpenJDK users; including >>> corporations, public sector and other organizations. TLS 1.2 is currently >>> the most wide-spread TLS version. >>> >>> Changes done as part of this enhancement are constrained to SunPKCS11 >>> crypto provider and do not affect SSL/TLS code. Risk involved is low >>> mainly >>> because of the following reasons: 1) this enhancement is an extension on >>> top of currently supported mechanisms (no major refactorings were >>> applied); >>> and, 2) backport is straight forward because affected code has not >>> suffered >>> major changes since JDK 8 release. >>> >>> JDK-8029661 has been reviewed by Valerie Peng on security-dev list [2] and >>> has been merged to JDK [3] base line. Regression testing on >>> sun/security/pkcs11 category experienced no regressions because of this >>> enhancement on both JDK base line and JDK 8. >>> >>> JDK 8 backport webrev: >>> >>> * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >>> 8029661.webrev.10.jdk8u/ >>> * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >>> 8029661.webrev.10.jdk8u.zip >>> >>> Please note that this backport includes JDK-8210912 fix [4]. >>> >>> Thanks, >>> Martin.- >>> >>> -- >>> [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 >>> [2] - http://mail.openjdk.java.net/pipermail/security-dev/ >>> 2018-September/018278.html >>> [3] - http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed >>> [4] - https://bugs.openjdk.java.net/browse/JDK-8210912 >>> >> From ivan.gerasimov at oracle.com Tue Oct 23 04:21:43 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 22 Oct 2018 21:21:43 -0700 Subject: [8u-dev] Request for review and approval to backport : 8194864, 8186098 test-stabilization Message-ID: Hello! I'd like to backport two mentioned test bug fixes. The changes required some minor manual editions, thus the request for review. Bug: https://bugs.openjdk.java.net/browse/JDK-8194864 Jdk12 change: http://hg.openjdk.java.net/jdk/jdk/rev/7537c762d42d Bug: https://bugs.openjdk.java.net/browse/JDK-8186098 Jdk12 change: http://hg.openjdk.java.net/jdk/jdk/rev/257d7610663f Cannot find the reviews, as the site http://mail.openjdk.java.net/ appears to be down at this moment. Here is the combined webrev of both fixes: http://cr.openjdk.java.net/~igerasim/8186098/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From sean.coffey at oracle.com Tue Oct 23 07:07:47 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 23 Oct 2018 08:07:47 +0100 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <2c4d13cd-6d35-78eb-f6b5-8301ad2a5e9d@oracle.com> References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> <2c4d13cd-6d35-78eb-f6b5-8301ad2a5e9d@oracle.com> Message-ID: Martin, this enhancement backport is approved for jdk8u-dev. Please follow up with an 8u review request if necessary. regards, Sean. On 15/10/2018 16:25, Se?n Coffey wrote: > > Hope to have an answer within next few days Martin! > > Regards, > Sean. > On 15/10/18 16:15, Martin Balao wrote: >> Hi Sean, >> >> Any updates on this? >> >> Kind regards, >> Martin.- >> >> On Tue, Sep 25, 2018 at 6:56 PM, Se?n Coffey > > wrote: >> >> Thanks for logging this request Martin. Looking into this and >> hope to reply shortly. >> >> regards, >> Sean. >> >> >> >> On 25/09/2018 10:07, Martin Balao wrote: >> >> Hi, >> >> I'd like to request an enhancement backport approval for >> JDK-8029661 [1]. >> >> Supporting TLS v1.2 algorithms in SunPKCS11 crypto provider >> would be highly >> beneficial for operating in a FIPS-140 environment. This is >> highly critical >> for both security and compliance reasons to many OpenJDK >> users; including >> corporations, public sector and other organizations. TLS 1.2 >> is currently >> the most wide-spread TLS version. >> >> Changes done as part of this enhancement are constrained to >> SunPKCS11 >> crypto provider and do not affect SSL/TLS code. Risk involved >> is low mainly >> because of the following reasons: 1) this enhancement is an >> extension on >> top of currently supported mechanisms (no major refactorings >> were applied); >> and, 2) backport is straight forward because affected code >> has not suffered >> major changes since JDK 8 release. >> >> JDK-8029661 has been reviewed by Valerie Peng on security-dev >> list [2] and >> has been merged to JDK [3] base line. Regression testing on >> sun/security/pkcs11 category experienced no regressions >> because of this >> enhancement on both JDK base line and JDK 8. >> >> JDK 8 backport webrev: >> >> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >> >> 8029661.webrev.10.jdk8u/ >> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >> >> 8029661.webrev.10.jdk8u.zip >> >> Please note that this backport includes JDK-8210912 fix [4]. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 >> >> [2] - http://mail.openjdk.java.net/pipermail/security-dev/ >> >> 2018-September/018278.html >> [3] - http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed >> >> [4] - https://bugs.openjdk.java.net/browse/JDK-8210912 >> >> >> >> > From sean.coffey at oracle.com Tue Oct 23 07:29:06 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 23 Oct 2018 08:29:06 +0100 Subject: [8u-dev] Request for review and approval to backport : 8194864, 8186098 test-stabilization In-Reply-To: References: Message-ID: Approved. regards, Sean. cached RFR email threads : http://webcache.googleusercontent.com/search?q=cache:yaFjc_umi24J:mail.openjdk.java.net/pipermail/security-dev/2018-January/016717.html+&cd=3&hl=en&ct=clnk&gl=uk http://webcache.googleusercontent.com/search?q=cache:HUDtGZJ00EgJ:mail.openjdk.java.net/pipermail/security-dev/2018-January/016750.html+&cd=2&hl=en&ct=clnk&gl=uk On 23/10/2018 05:21, Ivan Gerasimov wrote: > Hello! > > I'd like to backport two mentioned test bug fixes. > The changes required some minor manual editions, thus the request for > review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8194864 > Jdk12 change: http://hg.openjdk.java.net/jdk/jdk/rev/7537c762d42d > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186098 > Jdk12 change: http://hg.openjdk.java.net/jdk/jdk/rev/257d7610663f > > Cannot find the reviews, as the site http://mail.openjdk.java.net/ > appears to be down at this moment. > > Here is the combined webrev of both fixes: > http://cr.openjdk.java.net/~igerasim/8186098/00/webrev/ > > Thanks in advance! > From rwestrel at redhat.com Tue Oct 23 07:38:06 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 23 Oct 2018 09:38:06 +0200 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: <20b5eae9-0a92-92df-2767-c8dd11739880@oracle.com> References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> <20b5eae9-0a92-92df-2767-c8dd11739880@oracle.com> Message-ID: Thank you for the review, Vladimir. Can you take a look at the backport of 8172850 as well? Roland. From mbalao at redhat.com Tue Oct 23 12:18:29 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 23 Oct 2018 09:18:29 -0300 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> Message-ID: Hi Valerie, This backport was trivial, only a few changes required: * Paths * JDK-8210912 fix included [1] * Minor adjustments when checking TLS version in P11TlsKeyMaterialGenerator, P11TlsMasterSecretGenerator and P11TlsRsaPremasterSecretGenerator Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8210912 On Mon, Oct 22, 2018 at 7:17 PM, Valerie Peng wrote: > Martin, > > Sean asked me to help review this backport. Are the changes for 8u > identical to those for JDK 12 (minus the path differences)? Is there any 8u > specific modifications? > > Thanks, > > Valerie > > > > On 10/15/2018 8:15 AM, Martin Balao wrote: > >> Hi Sean, >> >> Any updates on this? >> >> Kind regards, >> Martin.- >> >> On Tue, Sep 25, 2018 at 6:56 PM, Se?n Coffey >> wrote: >> >> Thanks for logging this request Martin. Looking into this and hope to >>> reply shortly. >>> >>> regards, >>> Sean. >>> >>> >>> >>> On 25/09/2018 10:07, Martin Balao wrote: >>> >>> Hi, >>>> >>>> I'd like to request an enhancement backport approval for JDK-8029661 >>>> [1]. >>>> >>>> Supporting TLS v1.2 algorithms in SunPKCS11 crypto provider would be >>>> highly >>>> beneficial for operating in a FIPS-140 environment. This is highly >>>> critical >>>> for both security and compliance reasons to many OpenJDK users; >>>> including >>>> corporations, public sector and other organizations. TLS 1.2 is >>>> currently >>>> the most wide-spread TLS version. >>>> >>>> Changes done as part of this enhancement are constrained to SunPKCS11 >>>> crypto provider and do not affect SSL/TLS code. Risk involved is low >>>> mainly >>>> because of the following reasons: 1) this enhancement is an extension on >>>> top of currently supported mechanisms (no major refactorings were >>>> applied); >>>> and, 2) backport is straight forward because affected code has not >>>> suffered >>>> major changes since JDK 8 release. >>>> >>>> JDK-8029661 has been reviewed by Valerie Peng on security-dev list [2] >>>> and >>>> has been merged to JDK [3] base line. Regression testing on >>>> sun/security/pkcs11 category experienced no regressions because of this >>>> enhancement on both JDK base line and JDK 8. >>>> >>>> JDK 8 backport webrev: >>>> >>>> * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >>>> 8029661.webrev.10.jdk8u/ >>>> * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >>>> 8029661.webrev.10.jdk8u.zip >>>> >>>> Please note that this backport includes JDK-8210912 fix [4]. >>>> >>>> Thanks, >>>> Martin.- >>>> >>>> -- >>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 >>>> [2] - http://mail.openjdk.java.net/pipermail/security-dev/ >>>> 2018-September/018278.html >>>> [3] - http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed >>>> [4] - https://bugs.openjdk.java.net/browse/JDK-8210912 >>>> >>>> >>> > From vladimir.kozlov at oracle.com Tue Oct 23 17:11:40 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Oct 2018 10:11:40 -0700 Subject: [8u] RFR and RFA: 8172850: Anti-dependency on membar causes crash in register allocator due to invalid instruction scheduling In-Reply-To: References: Message-ID: <99bfb699-6763-3bf6-6cb2-27506ca1892a@oracle.com> Looks good. Thanks, Vladimir On 10/15/18 4:10 AM, Roland Westrelin wrote: > > I'd like to backport 8172850 to 8u because I'd also like to backport a > change that depends on it: 8209639. The change doesn't apply cleanly. So > here is an updated webrev: > > http://cr.openjdk.java.net/~roland/8172850-8u/webrev.00/ > > Initial change: > > https://bugs.openjdk.java.net/browse/JDK-8172850 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/6bf44f4e2a1e > > Roland. > From sean.coffey at oracle.com Tue Oct 23 17:17:28 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 23 Oct 2018 18:17:28 +0100 Subject: [8u] RFR and RFA: 8172850: Anti-dependency on membar causes crash in register allocator due to invalid instruction scheduling In-Reply-To: <99bfb699-6763-3bf6-6cb2-27506ca1892a@oracle.com> References: <99bfb699-6763-3bf6-6cb2-27506ca1892a@oracle.com> Message-ID: <50de3977-2dd3-de99-5a8d-af0d3f5f47c8@oracle.com> Approved for jdk8u-dev. regards, Sean. On 23/10/2018 18:11, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/15/18 4:10 AM, Roland Westrelin wrote: >> >> I'd like to backport 8172850 to 8u because I'd also like to backport a >> change that depends on it: 8209639. The change doesn't apply cleanly. So >> here is an updated webrev: >> >> http://cr.openjdk.java.net/~roland/8172850-8u/webrev.00/ >> >> Initial change: >> >> https://bugs.openjdk.java.net/browse/JDK-8172850 >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/6bf44f4e2a1e >> >> Roland. >> From rwestrel at redhat.com Wed Oct 24 08:21:26 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 24 Oct 2018 10:21:26 +0200 Subject: [8u] RFR and RFA: 8172850: Anti-dependency on membar causes crash in register allocator due to invalid instruction scheduling In-Reply-To: <50de3977-2dd3-de99-5a8d-af0d3f5f47c8@oracle.com> References: <99bfb699-6763-3bf6-6cb2-27506ca1892a@oracle.com> <50de3977-2dd3-de99-5a8d-af0d3f5f47c8@oracle.com> Message-ID: Thanks for the reviews, Vladimir & Tobias and thanks for the approval Sean. Roland. From rwestrel at redhat.com Wed Oct 24 08:22:15 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 24 Oct 2018 10:22:15 +0200 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: <20b5eae9-0a92-92df-2767-c8dd11739880@oracle.com> References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> <20b5eae9-0a92-92df-2767-c8dd11739880@oracle.com> Message-ID: Could I get approval now that the change is reviewed? Roland. From sean.coffey at oracle.com Wed Oct 24 08:39:25 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 24 Oct 2018 09:39:25 +0100 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> <20b5eae9-0a92-92df-2767-c8dd11739880@oracle.com> Message-ID: <2013cc23-469e-b934-2dfd-afdcabf2afb8@oracle.com> Approved. regards, Sean. On 24/10/2018 09:22, Roland Westrelin wrote: > Could I get approval now that the change is reviewed? > > Roland. From rwestrel at redhat.com Wed Oct 24 08:41:40 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 24 Oct 2018 10:41:40 +0200 Subject: [8u] RFR + RFA: 8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item In-Reply-To: <2013cc23-469e-b934-2dfd-afdcabf2afb8@oracle.com> References: <40cf9beb-2686-3652-7978-b7b013f761f9@oracle.com> <846844a7-5c7a-ed4c-8f45-c3b34b929d43@oracle.com> <20b5eae9-0a92-92df-2767-c8dd11739880@oracle.com> <2013cc23-469e-b934-2dfd-afdcabf2afb8@oracle.com> Message-ID: > Approved. Thank you. Roland. From hohensee at amazon.com Wed Oct 24 14:39:13 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 24 Oct 2018 14:39:13 +0000 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: <2e63218e-cd90-315b-cd21-93d8d44c74bf@oracle.com> References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> <4ad237e9-ccad-e85d-2a6c-4b907bc41658@oracle.com> <5EA2DE32-0E42-4651-8CD6-B316040FD477@amazon.com> <2e63218e-cd90-315b-cd21-93d8d44c74bf@oracle.com> Message-ID: I filed https://bugs.openjdk.java.net/browse/JDK-8212821. New approval request: JBS bug: https://bugs.openjdk.java.net/browse/JDK-8212821 Webrev: http://cr.openjdk.java.net/~phh/8212821/webrev.00/ JDK-8211394 thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html JDK-821709 thread (backout): http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/008063.html Thanks, Paul ?On 10/22/18, 8:01 AM, "Se?n Coffey" wrote: Paul, please file a new bug to use for the 2nd push. Add details of old push, backout etc. Regards, Sean. On 22/10/18 15:55, Hohensee, Paul wrote: > Yes, my bad on this, and +1 on thanks for backing it out. I'll push the correct patch today if that's ok. > > Paul > > On 10/21/18, 2:43 PM, "David Holmes" wrote: > > On 20/10/2018 2:01 PM, Ivan Gerasimov wrote: > > The build issue seems to be due that the actual source diff [1] > > contained this change: > > > > + from_field_is_protected, TRAPS); > > > > while the webrev [2] had this: > > > > + from_field_is_protected, > > THREAD); > > > > which, I assume, was building fine. > > Yes the patch from the webrev was put through JPRT and everything was fine. > > Thanks for doing the backout Ivan. > > David H. > > > [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/raw-rev/fbc668a76c00 > > [2] > > http://cr.openjdk.java.net/~phh/8211394/webrev.00/src/share/vm/classfile/verificationType.cpp.patch > > > > > > With kind regards, > > Ivan > > > > On 10/19/18 8:03 PM, Ivan Gerasimov wrote: > >> Hello! > >> > >> I'm curious how the jdk build passed successfully. > >> > >> I see the following error in JPRT now (failing on all platforms): > >> > >> /s/hotspot/src/share/vm/classfile/verificationType.cpp: In member > >> function 'bool VerificationType::is_reference_assignable_from(const > >> VerificationType&, ClassVerifier*, bool, Thread*) > >> const':/s/hotspot/src/share/vm/classfile/verificationType.cpp:102: > >> error: expected primary-expression before '*' token > >> > >> or, on Windows: > >> > >> \s\hotspot\src\share\vm\classfile\verificationType.cpp(102) : error > >> C2275: 'Thread' : illegal use of this type as an expression > >> C:\jprt\T\P1\020004.robm\s\hotspot\src\share\vm\runtime/thread.hpp(102) : > >> see declaration of 'Thread' > >> > >> I created JDK-8212709 to backout the backport for now. > >> > >> With kind regards, > >> > >> Ivan > >> > >> > >> On 10/19/18 9:54 AM, Hohensee, Paul wrote: > >>> Done and pushed. Thanks! > >>> > >>> On 10/18/18, 8:41 PM, "David Buck" wrote: > >>> > >>> Hi Paul! > >>> Please add an appropriate noreg label [0] to the JBS bug > >>> report. > >>> Once that is done please consider this approved for push to > >>> 8u-dev. > >>> Cheers, > >>> -Buck > >>> [0] https://openjdk.java.net/guide/changePlanning.html#noreg > >>> On 2018/10/19 9:29, David Holmes wrote: > >>> > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: > >>> >> Hi David, > >>> >> > >>> >> Did the jprt job go ok? If so, Rob or Sean, would you please > >>> approve > >>> >> the backport? > >>> > > >>> > Yes - sorry. Didn't expect it to hold this up as it's so trivial. > >>> > > >>> > David > >>> > > >>> >> Thanks, > >>> >> > >>> >> Paul > >>> >> > >>> >> On 10/16/18, 7:06 PM, "David Holmes" > >>> wrote: > >>> >> > >>> >> On 17/10/2018 8:23 AM, Hohensee, Paul wrote: > >>> >> > Please approve a trivial backport of JDK-8211394 to 8u. > >>> >> > > >>> >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 > >>> >> > > >>> >> > Webrev: > >>> http://cr.openjdk.java.net/~phh/8211394/webrev.00/ > >>> >> > > >>> >> > > >>> >> > Review thread: > >>> >> > > >>> >> > >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html > >>> > >>> >> > >>> >> > > >>> >> > The patch applies cleanly net of line numbers, > >>> copyright notice > >>> >> > dates, and code that exists in JDK9 but not in JDK8. > >>> The result > >>> >> is a one > >>> >> > line change and a new comment. > >>> >> Looks fine. > >>> >> > It builds and runs jdk8 hotspot jtreg test on a linux > >>> x64 host. If > >>> >> > needed, would someone please run it through jprt? > >>> >> It doesn't really warrant it but I fired it off anyway. > >>> >> Thanks, > >>> >> David > >>> >> > Thanks, > >>> >> > > >>> >> > Paul > >>> >> > > >>> >> > >>> > >> > > > > From hohensee at amazon.com Wed Oct 24 14:40:09 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 24 Oct 2018 14:40:09 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <536354B0-3B58-4F96-BDE3-505AF26B73A9@amazon.com> References: <4B638999-9360-49FC-B423-41922357EF1C@amazon.com> <536354B0-3B58-4F96-BDE3-505AF26B73A9@amazon.com> Message-ID: <7181D9F6-DA4D-4867-BE77-4F803FBEBD83@amazon.com> Ping. Is there anything I've left out from the request? Thanks, Paul ?On 10/22/18, 12:21 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Typo, webrev s/b webrev.05. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html On 10/22/18, 8:45 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Trying again with correct request template. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.06/ Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Thanks, Paul On 10/19/18, 10:11 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Thanks, Thomas. Cutting distribution down to jdk8u-dev now, and asking for backport approval. Here's the email discussion: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Backport argument: At Amazon, we discovered more than a year ago that the MemoryPoolMXBean Usage attribute isn't very useful for monitoring, and more importantly, alarming on, excessive heap use. That's because it's an instantaneous measurement, so it includes yet-to-collected garbage. We moved to using CollectionUsage (usage after the last GC that affected the memory pool) instead as a measure of the long-term heap occupancy. If it's trending up without the app changing, there may be a memory leak, or just more load that might require a -Xmx increase. Once moved, however, we found that G1 was effectively useless to us because it reported incorrect values for the G1 old gen: mixed collections weren't updating its CollectionUsage. We patched our internal jdk8 distro, and last June, openjdk11. This is a backport of the latter. We believe that anyone monitoring server apps running G1 in jdk8u needs this fix. Thanks, Paul On 10/19/18, 9:24 AM, "Thomas Schatzl" wrote: Hi Paul, On Fri, 2018-10-12 at 00:03 +0000, Hohensee, Paul wrote: > Please review a backport to jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > The backport is slightly different from the JDK11 patch due to G1 > refactoring, hence my request for new review. I?ll ask for jdk8u > approval once the backport is reviewed. > I backported two jtreg tests from JDK11, which pass. Also, all the > hotspot gc jtreg tests pass as well as they do for jdk8u-dev. I think the backport is good. Others need to decide whether this change is worth backporting. > There was a CSR involved, > https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to > be re-approved for jdk8u as well, and if so, what?s the process? CC'ed Joe Darcy as I am not sure either. Thanks, Thomas From sean.coffey at oracle.com Wed Oct 24 15:02:58 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 24 Oct 2018 16:02:58 +0100 Subject: [8u-dev] RFA (XS): JDK-8211394: CHECK_ must be used in the rhs of an assignment statement within a block In-Reply-To: References: <87d2ab6a-1671-b21b-0f68-34771433c301@oracle.com> <8A4663B9-D769-44AD-ADBC-6B241156440D@amazon.com> <76f08ccc-1c63-052c-5ec0-c32be14221fa@oracle.com> <26E30AD8-3B1A-4197-B3F8-CBCAF051D335@amazon.com> <4ad237e9-ccad-e85d-2a6c-4b907bc41658@oracle.com> <5EA2DE32-0E42-4651-8CD6-B316040FD477@amazon.com> <2e63218e-cd90-315b-cd21-93d8d44c74bf@oracle.com> Message-ID: <842f80a8-0f3d-1869-8f40-10dd0b9cf0ee@oracle.com> Thanks Paul. I've just appended "round 2" to bug summary just to help with future changeset queries. Approved for jdk8u-dev. Regards, Sean. On 24/10/18 15:39, Hohensee, Paul wrote: > I filed https://bugs.openjdk.java.net/browse/JDK-8212821. > > New approval request: > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8212821 > Webrev: http://cr.openjdk.java.net/~phh/8212821/webrev.00/ > JDK-8211394 thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html > JDK-821709 thread (backout): http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/008063.html > > Thanks, > > Paul > > ?On 10/22/18, 8:01 AM, "Se?n Coffey" wrote: > > Paul, > > please file a new bug to use for the 2nd push. Add details of old push, > backout etc. > > Regards, > Sean. > > On 22/10/18 15:55, Hohensee, Paul wrote: > > Yes, my bad on this, and +1 on thanks for backing it out. I'll push the correct patch today if that's ok. > > > > Paul > > > > On 10/21/18, 2:43 PM, "David Holmes" wrote: > > > > On 20/10/2018 2:01 PM, Ivan Gerasimov wrote: > > > The build issue seems to be due that the actual source diff [1] > > > contained this change: > > > > > > + from_field_is_protected, TRAPS); > > > > > > while the webrev [2] had this: > > > > > > + from_field_is_protected, > > > THREAD); > > > > > > which, I assume, was building fine. > > > > Yes the patch from the webrev was put through JPRT and everything was fine. > > > > Thanks for doing the backout Ivan. > > > > David H. > > > > > [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/raw-rev/fbc668a76c00 > > > [2] > > > http://cr.openjdk.java.net/~phh/8211394/webrev.00/src/share/vm/classfile/verificationType.cpp.patch > > > > > > > > > With kind regards, > > > Ivan > > > > > > On 10/19/18 8:03 PM, Ivan Gerasimov wrote: > > >> Hello! > > >> > > >> I'm curious how the jdk build passed successfully. > > >> > > >> I see the following error in JPRT now (failing on all platforms): > > >> > > >> /s/hotspot/src/share/vm/classfile/verificationType.cpp: In member > > >> function 'bool VerificationType::is_reference_assignable_from(const > > >> VerificationType&, ClassVerifier*, bool, Thread*) > > >> const':/s/hotspot/src/share/vm/classfile/verificationType.cpp:102: > > >> error: expected primary-expression before '*' token > > >> > > >> or, on Windows: > > >> > > >> \s\hotspot\src\share\vm\classfile\verificationType.cpp(102) : error > > >> C2275: 'Thread' : illegal use of this type as an expression > > >> C:\jprt\T\P1\020004.robm\s\hotspot\src\share\vm\runtime/thread.hpp(102) : > > >> see declaration of 'Thread' > > >> > > >> I created JDK-8212709 to backout the backport for now. > > >> > > >> With kind regards, > > >> > > >> Ivan > > >> > > >> > > >> On 10/19/18 9:54 AM, Hohensee, Paul wrote: > > >>> Done and pushed. Thanks! > > >>> > > >>> On 10/18/18, 8:41 PM, "David Buck" wrote: > > >>> > > >>> Hi Paul! > > >>> Please add an appropriate noreg label [0] to the JBS bug > > >>> report. > > >>> Once that is done please consider this approved for push to > > >>> 8u-dev. > > >>> Cheers, > > >>> -Buck > > >>> [0] https://openjdk.java.net/guide/changePlanning.html#noreg > > >>> On 2018/10/19 9:29, David Holmes wrote: > > >>> > On 19/10/2018 2:44 AM, Hohensee, Paul wrote: > > >>> >> Hi David, > > >>> >> > > >>> >> Did the jprt job go ok? If so, Rob or Sean, would you please > > >>> approve > > >>> >> the backport? > > >>> > > > >>> > Yes - sorry. Didn't expect it to hold this up as it's so trivial. > > >>> > > > >>> > David > > >>> > > > >>> >> Thanks, > > >>> >> > > >>> >> Paul > > >>> >> > > >>> >> On 10/16/18, 7:06 PM, "David Holmes" > > >>> wrote: > > >>> >> > > >>> >> On 17/10/2018 8:23 AM, Hohensee, Paul wrote: > > >>> >> > Please approve a trivial backport of JDK-8211394 to 8u. > > >>> >> > > > >>> >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8211394 > > >>> >> > > > >>> >> > Webrev: > > >>> http://cr.openjdk.java.net/~phh/8211394/webrev.00/ > > >>> >> > > > >>> >> > > > >>> >> > Review thread: > > >>> >> > > > >>> >> > > >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-October/030376.html > > >>> > > >>> >> > > >>> >> > > > >>> >> > The patch applies cleanly net of line numbers, > > >>> copyright notice > > >>> >> > dates, and code that exists in JDK9 but not in JDK8. > > >>> The result > > >>> >> is a one > > >>> >> > line change and a new comment. > > >>> >> Looks fine. > > >>> >> > It builds and runs jdk8 hotspot jtreg test on a linux > > >>> x64 host. If > > >>> >> > needed, would someone please run it through jprt? > > >>> >> It doesn't really warrant it but I fired it off anyway. > > >>> >> Thanks, > > >>> >> David > > >>> >> > Thanks, > > >>> >> > > > >>> >> > Paul > > >>> >> > > > >>> >> > > >>> > > >> > > > > > > > > > > From sean.coffey at oracle.com Wed Oct 24 15:17:05 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 24 Oct 2018 16:17:05 +0100 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <7181D9F6-DA4D-4867-BE77-4F803FBEBD83@amazon.com> References: <4B638999-9360-49FC-B423-41922357EF1C@amazon.com> <536354B0-3B58-4F96-BDE3-505AF26B73A9@amazon.com> <7181D9F6-DA4D-4867-BE77-4F803FBEBD83@amazon.com> Message-ID: <9df445f6-2dad-8c6c-6852-29fe1ddd2fad@oracle.com> I wasn't aware of a pending approval request given that the mail doesn't follow approval guidelines [1] This fix has implications on behaviour in an update release. We should get Joe Darcy's approval before backporting. Joe - what are your recommendations ? regards, Sean. [1] http://openjdk.java.net/projects/jdk8u/approval-template.html Regards, Sean. On 24/10/18 15:40, Hohensee, Paul wrote: > Ping. Is there anything I've left out from the request? > > Thanks, > > Paul > > ?On 10/22/18, 12:21 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > Typo, webrev s/b webrev.05. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html > Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html > > On 10/22/18, 8:45 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > Trying again with correct request template. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.06/ > Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html > Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html > > Thanks, > > Paul > > On 10/19/18, 10:11 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > Thanks, Thomas. Cutting distribution down to jdk8u-dev now, and asking for backport approval. > > Here's the email discussion: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html > > Backport argument: > > At Amazon, we discovered more than a year ago that the MemoryPoolMXBean Usage attribute isn't very useful for monitoring, and more importantly, alarming on, excessive heap use. That's because it's an instantaneous measurement, so it includes yet-to-collected garbage. We moved to using CollectionUsage (usage after the last GC that affected the memory pool) instead as a measure of the long-term heap occupancy. If it's trending up without the app changing, there may be a memory leak, or just more load that might require a -Xmx increase. > > Once moved, however, we found that G1 was effectively useless to us because it reported incorrect values for the G1 old gen: mixed collections weren't updating its CollectionUsage. We patched our internal jdk8 distro, and last June, openjdk11. This is a backport of the latter. We believe that anyone monitoring server apps running G1 in jdk8u needs this fix. > > Thanks, > > Paul > > On 10/19/18, 9:24 AM, "Thomas Schatzl" wrote: > > Hi Paul, > > On Fri, 2018-10-12 at 00:03 +0000, Hohensee, Paul wrote: > > Please review a backport to jdk8u. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > > > The backport is slightly different from the JDK11 patch due to G1 > > refactoring, hence my request for new review. I?ll ask for jdk8u > > approval once the backport is reviewed. > > > I backported two jtreg tests from JDK11, which pass. Also, all the > > hotspot gc jtreg tests pass as well as they do for jdk8u-dev. > > I think the backport is good. Others need to decide whether this change > is worth backporting. > > > There was a CSR involved, > > https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to > > be re-approved for jdk8u as well, and if so, what?s the process? > > CC'ed Joe Darcy as I am not sure either. > > Thanks, > Thomas > > > > > > > > > > From david.holmes at oracle.com Thu Oct 25 05:06:50 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Oct 2018 15:06:50 +1000 Subject: RFR(S): [TESTBUG]runtime/ErrorHandling fails when using jtreg 4.1 b13 In-Reply-To: References: Message-ID: Hi Vaibhav, cc'ing jdk8u-dev to get some input from the maintainers. I was very confused until I realized this RFR was for 8u! :) Even so, after reading the bug report I'm still quite confused. This has been "broken" since the test was added in January 2016, but only causes a failure if jtreg 4.1b13 is used - is that correct? What is the default version of jtreg being used for 8u today? I'd be happy to review this but given I have no idea how the 8u testing is being handled in general I can't say whether this is the right fix ?? Thanks, David On 25/10/2018 2:18 PM, Vaibhav Choudhary wrote: > Hi, > > Please review this tiny fix. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8151295 > Fix: http://cr.openjdk.java.net/~rpatil/8151295/webrev.00/ > > Desc: In stead of @build jdk.test.lib.* we need to use @build com.oracle.java.testlibrary.* > These two tests are failing in nightly. > > Thanks, > Vaibhav > > From igor.ignatyev at oracle.com Thu Oct 25 05:11:58 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 24 Oct 2018 22:11:58 -0700 Subject: RFR(S): [TESTBUG]runtime/ErrorHandling fails when using jtreg 4.1 b13 In-Reply-To: References: Message-ID: IIRC, prior jtreg 4.1b13 it was fine to have nonexistent classes in @build actions, so the fix is good regardless of used version of jtreg, but are necessary for jtreg 4.1b13+. -- Igor > On Oct 24, 2018, at 10:06 PM, David Holmes wrote: > > Hi Vaibhav, > > cc'ing jdk8u-dev to get some input from the maintainers. > > I was very confused until I realized this RFR was for 8u! :) > > Even so, after reading the bug report I'm still quite confused. This has been "broken" since the test was added in January 2016, but only causes a failure if jtreg 4.1b13 is used - is that correct? What is the default version of jtreg being used for 8u today? > > I'd be happy to review this but given I have no idea how the 8u testing is being handled in general I can't say whether this is the right fix ?? > > Thanks, > David > > On 25/10/2018 2:18 PM, Vaibhav Choudhary wrote: >> Hi, >> Please review this tiny fix. >> Bug : https://bugs.openjdk.java.net/browse/JDK-8151295 >> Fix: http://cr.openjdk.java.net/~rpatil/8151295/webrev.00/ >> Desc: In stead of @build jdk.test.lib.* we need to use @build com.oracle.java.testlibrary.* >> These two tests are failing in nightly. >> Thanks, >> Vaibhav From david.holmes at oracle.com Thu Oct 25 05:14:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Oct 2018 15:14:53 +1000 Subject: RFR(S): [TESTBUG]runtime/ErrorHandling fails when using jtreg 4.1 b13 In-Reply-To: References: Message-ID: Hi Igor, On 25/10/2018 3:11 PM, Igor Ignatyev wrote: > IIRC, prior jtreg 4.1b13 it was fine to have nonexistent classes in @build actions, so the fix is good regardless of used version of jtreg, but are necessary for jtreg 4.1b13+. Okay, just wanted to be sure that 8u testing still expects use of hotspot testlibrary implementation in hotspot tests. Though if the @build is actually a no-op is it even necessary to fix it rather than just delete it? Sorry I've lost track of where we stand with needing to explicitly build the test library in older versions. Thanks, David > -- Igor >> On Oct 24, 2018, at 10:06 PM, David Holmes wrote: >> >> Hi Vaibhav, >> >> cc'ing jdk8u-dev to get some input from the maintainers. >> >> I was very confused until I realized this RFR was for 8u! :) >> >> Even so, after reading the bug report I'm still quite confused. This has been "broken" since the test was added in January 2016, but only causes a failure if jtreg 4.1b13 is used - is that correct? What is the default version of jtreg being used for 8u today? >> >> I'd be happy to review this but given I have no idea how the 8u testing is being handled in general I can't say whether this is the right fix ?? >> >> Thanks, >> David >> >> On 25/10/2018 2:18 PM, Vaibhav Choudhary wrote: >>> Hi, >>> Please review this tiny fix. >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8151295 >>> Fix: http://cr.openjdk.java.net/~rpatil/8151295/webrev.00/ >>> Desc: In stead of @build jdk.test.lib.* we need to use @build com.oracle.java.testlibrary.* >>> These two tests are failing in nightly. >>> Thanks, >>> Vaibhav > From kevin.walls at oracle.com Thu Oct 25 09:53:23 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 25 Oct 2018 10:53:23 +0100 Subject: [8u-dev] Request for approval for CR 8211933: [8u] hotspot adlc needs to link statically with libstdc++ for gcc7.3 Message-ID: <7cd3b4a0-66f2-daee-c8de-023116385db1@oracle.com> Hi, I'd like to request approval to push to 8u: 8211933: [8u] hotspot adlc needs to link statically with libstdc++ for gcc7.3 JBS: https://bugs.openjdk.java.net/browse/JDK-8211933 8u webrev: http://cr.openjdk.java.net/~kevinw/8211933/webrev.00/ build-dev review thread: http://mail.openjdk.java.net/pipermail/build-dev/2018-October/023658.html Essentially this adds -static-libstdc++ for linking adlc during an 8u build. This is needed e.g. when we build with gcc7.x using our devkit bundle and we won't necessarily find a correct version of that library on the system.? adlc is only used at build time, so this doesn't affect how e.g. libjvm is linked. (I am trying to add noreg-build and 9-na labels, but can't get in to jbs right now.) Thanks Kevin From david.buck at oracle.com Thu Oct 25 09:57:45 2018 From: david.buck at oracle.com (David Buck) Date: Thu, 25 Oct 2018 18:57:45 +0900 Subject: [8u-dev] Request for approval for CR 8211933: [8u] hotspot adlc needs to link statically with libstdc++ for gcc7.3 In-Reply-To: <7cd3b4a0-66f2-daee-c8de-023116385db1@oracle.com> References: <7cd3b4a0-66f2-daee-c8de-023116385db1@oracle.com> Message-ID: approved Cheers, -Buck 2018/10/25 18:53?Kevin Walls ????: > Hi, > > I'd like to request approval to push to 8u: > > 8211933: [8u] hotspot adlc needs to link statically with libstdc++ for gcc7.3 > JBS: https://bugs.openjdk.java.net/browse/JDK-8211933 > > 8u webrev: > http://cr.openjdk.java.net/~kevinw/8211933/webrev.00/ > > build-dev review thread: > http://mail.openjdk.java.net/pipermail/build-dev/2018-October/023658.html > > Essentially this adds -static-libstdc++ for linking adlc during an 8u build. This is needed e.g. when we build with gcc7.x using our devkit bundle and we won't necessarily find a correct version of that library on the system. adlc is only used at build time, so this doesn't affect how e.g. libjvm is linked. > > (I am trying to add noreg-build and 9-na labels, but can't get in to jbs right now.) > > Thanks > Kevin > From hohensee at amazon.com Thu Oct 25 14:32:28 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 25 Oct 2018 14:32:28 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <9df445f6-2dad-8c6c-6852-29fe1ddd2fad@oracle.com> References: <4B638999-9360-49FC-B423-41922357EF1C@amazon.com> <536354B0-3B58-4F96-BDE3-505AF26B73A9@amazon.com> <7181D9F6-DA4D-4867-BE77-4F803FBEBD83@amazon.com> <9df445f6-2dad-8c6c-6852-29fe1ddd2fad@oracle.com> Message-ID: <2B11EB05-C970-41B8-84F7-F822EF959479@amazon.com> Sorry about the formatting, I thought it did follow the guidelines, but I see now that I missed two things, the subject line and the list of backport approvers. I'll repost. Thanks, Paul ?On 10/24/18, 8:17 AM, "Se?n Coffey" wrote: I wasn't aware of a pending approval request given that the mail doesn't follow approval guidelines [1] This fix has implications on behaviour in an update release. We should get Joe Darcy's approval before backporting. Joe - what are your recommendations ? regards, Sean. [1] http://openjdk.java.net/projects/jdk8u/approval-template.html Regards, Sean. On 24/10/18 15:40, Hohensee, Paul wrote: > Ping. Is there anything I've left out from the request? > > Thanks, > > Paul > > On 10/22/18, 12:21 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > Typo, webrev s/b webrev.05. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html > Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html > > On 10/22/18, 8:45 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > Trying again with correct request template. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.06/ > Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html > Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html > > Thanks, > > Paul > > On 10/19/18, 10:11 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > Thanks, Thomas. Cutting distribution down to jdk8u-dev now, and asking for backport approval. > > Here's the email discussion: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html > > Backport argument: > > At Amazon, we discovered more than a year ago that the MemoryPoolMXBean Usage attribute isn't very useful for monitoring, and more importantly, alarming on, excessive heap use. That's because it's an instantaneous measurement, so it includes yet-to-collected garbage. We moved to using CollectionUsage (usage after the last GC that affected the memory pool) instead as a measure of the long-term heap occupancy. If it's trending up without the app changing, there may be a memory leak, or just more load that might require a -Xmx increase. > > Once moved, however, we found that G1 was effectively useless to us because it reported incorrect values for the G1 old gen: mixed collections weren't updating its CollectionUsage. We patched our internal jdk8 distro, and last June, openjdk11. This is a backport of the latter. We believe that anyone monitoring server apps running G1 in jdk8u needs this fix. > > Thanks, > > Paul > > On 10/19/18, 9:24 AM, "Thomas Schatzl" wrote: > > Hi Paul, > > On Fri, 2018-10-12 at 00:03 +0000, Hohensee, Paul wrote: > > Please review a backport to jdk8u. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > > > The backport is slightly different from the JDK11 patch due to G1 > > refactoring, hence my request for new review. I?ll ask for jdk8u > > approval once the backport is reviewed. > > > I backported two jtreg tests from JDK11, which pass. Also, all the > > hotspot gc jtreg tests pass as well as they do for jdk8u-dev. > > I think the backport is good. Others need to decide whether this change > is worth backporting. > > > There was a CSR involved, > > https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to > > be re-approved for jdk8u as well, and if so, what?s the process? > > CC'ed Joe Darcy as I am not sure either. > > Thanks, > Thomas > > > > > > > > > > From hohensee at amazon.com Thu Oct 25 14:43:07 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 25 Oct 2018 14:43:07 +0000 Subject: [8u-dev] Request for approval of CR 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Message-ID: <613F1C8E-896E-4CF4-82E6-F4B3384834D6@amazon.com> Please approve a G1 serviceability bug backport. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 CSR: https://bugs.openjdk.java.net/browse/JDK-8196719 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html Backport reviewers: tschatzl, jcbeyler I don?t know what the process is for approving a CSR associated with a backport, hence cc?ing Joe. The CSR documents the behavior change due to this fix, but as it notes, there is no spec change. Thanks, Paul From igor.ignatyev at oracle.com Thu Oct 25 18:24:30 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Oct 2018 11:24:30 -0700 Subject: RFR(S): [TESTBUG]runtime/ErrorHandling fails when using jtreg 4.1 b13 In-Reply-To: References: Message-ID: <68B1DBB7-3BE1-458C-8143-52BF8D2A2D32@oracle.com> Hi David, > On Oct 24, 2018, at 10:14 PM, David Holmes wrote: > > Hi Igor, > > On 25/10/2018 3:11 PM, Igor Ignatyev wrote: >> IIRC, prior jtreg 4.1b13 it was fine to have nonexistent classes in @build actions, so the fix is good regardless of used version of jtreg, but are necessary for jtreg 4.1b13+. > > Okay, just wanted to be sure that 8u testing still expects use of hotspot testlibrary implementation in hotspot tests. > > Though if the @build is actually a no-op is it even necessary to fix it rather than just delete it? Sorry I've lost track of where we stand with needing to explicitly build the test library in older versions. Unfortunately, I can't recall what the guidelines were for jdk8, but I agree it'd be safer to just remove @build actions here if these tests worked fine w/ jtreg4.1b12 (where these @builds were simply ignored) Cheers, -- Igor > > Thanks, > David > >> -- Igor >>> On Oct 24, 2018, at 10:06 PM, David Holmes wrote: >>> >>> Hi Vaibhav, >>> >>> cc'ing jdk8u-dev to get some input from the maintainers. >>> >>> I was very confused until I realized this RFR was for 8u! :) >>> >>> Even so, after reading the bug report I'm still quite confused. This has been "broken" since the test was added in January 2016, but only causes a failure if jtreg 4.1b13 is used - is that correct? What is the default version of jtreg being used for 8u today? >>> >>> I'd be happy to review this but given I have no idea how the 8u testing is being handled in general I can't say whether this is the right fix ?? >>> >>> Thanks, >>> David >>> >>> On 25/10/2018 2:18 PM, Vaibhav Choudhary wrote: >>>> Hi, >>>> Please review this tiny fix. >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8151295 >>>> Fix: http://cr.openjdk.java.net/~rpatil/8151295/webrev.00/ >>>> Desc: In stead of @build jdk.test.lib.* we need to use @build com.oracle.java.testlibrary.* >>>> These two tests are failing in nightly. >>>> Thanks, >>>> Vaibhav From jvanek at redhat.com Fri Oct 26 10:17:10 2018 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 26 Oct 2018 12:17:10 +0200 Subject: [8u-dev] Request for approval for CR JDK-8154313 - Generated javadoc scattered all over the place In-Reply-To: <7953f97f-0b6d-e240-4d17-f4b04c9a16cd@redhat.com> References: <7953f97f-0b6d-e240-4d17-f4b04c9a16cd@redhat.com> Message-ID: https://bugs.openjdk.java.net/browse/JDK-8154313 http://cr.openjdk.java.net/~jvanek/8154313/ Original review: start: http://mail.openjdk.java.net/pipermail/build-dev/2016-February/016653.html middle: http://mail.openjdk.java.net/pipermail/build-dev/2016-March/016737.html end: http://mail.openjdk.java.net/pipermail/build-dev/2016-April/016920.html This was proposed long time ago into JDK8, however never reached it asjdk9 was in development. It was pushed into it, and with small changes over 10 ad 11 lives up to now. We are keeping this pacth locally in rpms for jdk8, and as fas as I can tell, the zipped javadoc is useful and used thing/ From my view, it is missed in jdk8. Can I kindly ask for considering it as enhancement update for jdk8u? Best regards from CZ J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From sean.coffey at oracle.com Fri Oct 26 12:35:17 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 26 Oct 2018 13:35:17 +0100 Subject: [8u-communication] JDK 8u202 RDP2 Message-ID: Thanks to all for the JDK 8u202 contributions to date. We'll enter RDP2 on morning of 29th October (GMT). All changes in the jdk8u-dev forest will then be synced to the jdk8u master forest. Once we pass the RDP2 milestone, jdk8u-dev will collect fixes for the next OpenJDK 8u release which will be led by others. I propose that an `openjdk8u` fix version be attributed to such fixes in JBS. A similar value was used for the OpenJDK 7u Project when maintainer duties were handed over to Red Hat. Only critical fixes will be accepted into 8u202 post RDP2. The process for such requests is described on the Project page[1]. regards, Sean. [1] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html From hohensee at amazon.com Fri Oct 26 17:39:20 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 26 Oct 2018 17:39:20 +0000 Subject: [8u-dev] Request for approval of CR 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <613F1C8E-896E-4CF4-82E6-F4B3384834D6@amazon.com> References: <613F1C8E-896E-4CF4-82E6-F4B3384834D6@amazon.com> Message-ID: <23931D5F-B228-4E06-8DD6-C787A1E8AA93@amazon.com> Ping. :) ?On 10/25/18, 8:01 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Please approve a G1 serviceability bug backport. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 CSR: https://bugs.openjdk.java.net/browse/JDK-8196719 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html Backport reviewers: tschatzl, jcbeyler I don?t know what the process is for approving a CSR associated with a backport, hence cc?ing Joe. The CSR documents the behavior change due to this fix, but as it notes, there is no spec change. Thanks, Paul From vaibhav.x.choudhary at oracle.com Mon Oct 29 08:34:01 2018 From: vaibhav.x.choudhary at oracle.com (Vaibhav Choudhary) Date: Mon, 29 Oct 2018 14:04:01 +0530 Subject: RFR(S): [TESTBUG]runtime/ErrorHandling fails when using jtreg 4.1 b13 In-Reply-To: <68B1DBB7-3BE1-458C-8143-52BF8D2A2D32@oracle.com> References: <68B1DBB7-3BE1-458C-8143-52BF8D2A2D32@oracle.com> Message-ID: <40BF692C-F6E2-42B6-BEFD-D0EEE80E3EFB@oracle.com> Thank you Igor and David for the review. This make sense to remove @build. Here goes the next webrev :- http://cr.openjdk.java.net/~rpatil/8151295/webrev.01/ This test is failing from quite a long time but its getting ignored as known failure. Thanks, Vaibhav Choudhary vaibhav.x.choudhary at oracle.com https://blogs.oracle.com/vaibhav > On 25-Oct-2018, at 11:54 PM, Igor Ignatyev wrote: > > Hi David, > >> On Oct 24, 2018, at 10:14 PM, David Holmes wrote: >> >> Hi Igor, >> >> On 25/10/2018 3:11 PM, Igor Ignatyev wrote: >>> IIRC, prior jtreg 4.1b13 it was fine to have nonexistent classes in @build actions, so the fix is good regardless of used version of jtreg, but are necessary for jtreg 4.1b13+. >> >> Okay, just wanted to be sure that 8u testing still expects use of hotspot testlibrary implementation in hotspot tests. >> >> Though if the @build is actually a no-op is it even necessary to fix it rather than just delete it? Sorry I've lost track of where we stand with needing to explicitly build the test library in older versions. > Unfortunately, I can't recall what the guidelines were for jdk8, but I agree it'd be safer to just remove @build actions here if these tests worked fine w/ jtreg4.1b12 (where these @builds were simply ignored) > > Cheers, > -- Igor >> >> Thanks, >> David >> >>> -- Igor >>>> On Oct 24, 2018, at 10:06 PM, David Holmes wrote: >>>> >>>> Hi Vaibhav, >>>> >>>> cc'ing jdk8u-dev to get some input from the maintainers. >>>> >>>> I was very confused until I realized this RFR was for 8u! :) >>>> >>>> Even so, after reading the bug report I'm still quite confused. This has been "broken" since the test was added in January 2016, but only causes a failure if jtreg 4.1b13 is used - is that correct? What is the default version of jtreg being used for 8u today? >>>> >>>> I'd be happy to review this but given I have no idea how the 8u testing is being handled in general I can't say whether this is the right fix ?? >>>> >>>> Thanks, >>>> David >>>> >>>> On 25/10/2018 2:18 PM, Vaibhav Choudhary wrote: >>>>> Hi, >>>>> Please review this tiny fix. >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8151295 >>>>> Fix: http://cr.openjdk.java.net/~rpatil/8151295/webrev.00/ >>>>> Desc: In stead of @build jdk.test.lib.* we need to use @build com.oracle.java.testlibrary.* >>>>> These two tests are failing in nightly. >>>>> Thanks, >>>>> Vaibhav > From valerie.peng at oracle.com Mon Oct 29 23:53:44 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 29 Oct 2018 16:53:44 -0700 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> Message-ID: <82660e66-9260-135e-e590-2172e4077514@oracle.com> Hi Martin, The 8u changes look fine. Just double checking, what are the platforms and regression tests which you use for validating the 8u backport? Thanks, Valerie On 10/23/2018 5:18 AM, Martin Balao wrote: > Hi Valerie, > > This backport was trivial, only a few changes required: > > ?* Paths > ?*?JDK-8210912 fix included [1] > ?* Minor adjustments when checking TLS version > in?P11TlsKeyMaterialGenerator,?P11TlsMasterSecretGenerator > and?P11TlsRsaPremasterSecretGenerator > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8210912 > > On Mon, Oct 22, 2018 at 7:17 PM, Valerie Peng > wrote: > > Martin, > > Sean asked me to help review this backport. Are the changes for 8u > identical to those for JDK 12 (minus the path differences)? Is > there any 8u specific modifications? > > Thanks, > > Valerie > > > > On 10/15/2018 8:15 AM, Martin Balao wrote: > > Hi Sean, > > Any updates on this? > > Kind regards, > Martin.- > > On Tue, Sep 25, 2018 at 6:56 PM, Se?n Coffey > > wrote: > > Thanks for logging this request Martin. Looking into this > and hope to > reply shortly. > > regards, > Sean. > > > > On 25/09/2018 10:07, Martin Balao wrote: > > Hi, > > I'd like to request an enhancement backport approval > for JDK-8029661 [1]. > > Supporting TLS v1.2 algorithms in SunPKCS11 crypto > provider would be > highly > beneficial for operating in a FIPS-140 environment. > This is highly > critical > for both security and compliance reasons to many > OpenJDK users; including > corporations, public sector and other organizations. > TLS 1.2 is currently > the most wide-spread TLS version. > > Changes done as part of this enhancement are > constrained to SunPKCS11 > crypto provider and do not affect SSL/TLS code. Risk > involved is low > mainly > because of the following reasons: 1) this enhancement > is an extension on > top of currently supported mechanisms (no major > refactorings were > applied); > and, 2) backport is straight forward because affected > code has not > suffered > major changes since JDK 8 release. > > JDK-8029661 has been reviewed by Valerie Peng on > security-dev list [2] and > has been merged to JDK [3] base line. Regression > testing on > sun/security/pkcs11 category experienced no > regressions because of this > enhancement on both JDK base line and JDK 8. > > JDK 8 backport webrev: > > ? ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ > > 8029661.webrev.10.jdk8u/ > ? ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ > > 8029661.webrev.10.jdk8u.zip > > Please note that this backport includes JDK-8210912 > fix [4]. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 > > [2] - > http://mail.openjdk.java.net/pipermail/security-dev/ > > 2018-September/018278.html > [3] - > http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed > > [4] - https://bugs.openjdk.java.net/browse/JDK-8210912 > > > > > From david.holmes at oracle.com Tue Oct 30 01:26:22 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Oct 2018 11:26:22 +1000 Subject: RFR(S): [TESTBUG]runtime/ErrorHandling fails when using jtreg 4.1 b13 In-Reply-To: <40BF692C-F6E2-42B6-BEFD-D0EEE80E3EFB@oracle.com> References: <68B1DBB7-3BE1-458C-8143-52BF8D2A2D32@oracle.com> <40BF692C-F6E2-42B6-BEFD-D0EEE80E3EFB@oracle.com> Message-ID: On 29/10/2018 6:34 PM, Vaibhav Choudhary wrote: > Thank you Igor and David for the review. This make sense to remove @build. Here goes the next webrev :- > > http://cr.openjdk.java.net/~rpatil/8151295/webrev.01/ The removal seem okay - as long as the required test library classes end up getting built. Neither myself nor Igor are clear on the correct approach in 8u. > This test is failing from quite a long time but its getting ignored as known failure. You mean it's been failing for a long time due to a switch to jtreg 4.1 b13? Thanks, David > Thanks, > Vaibhav Choudhary > vaibhav.x.choudhary at oracle.com > https://blogs.oracle.com/vaibhav > > > >> On 25-Oct-2018, at 11:54 PM, Igor Ignatyev wrote: >> >> Hi David, >> >>> On Oct 24, 2018, at 10:14 PM, David Holmes wrote: >>> >>> Hi Igor, >>> >>> On 25/10/2018 3:11 PM, Igor Ignatyev wrote: >>>> IIRC, prior jtreg 4.1b13 it was fine to have nonexistent classes in @build actions, so the fix is good regardless of used version of jtreg, but are necessary for jtreg 4.1b13+. >>> >>> Okay, just wanted to be sure that 8u testing still expects use of hotspot testlibrary implementation in hotspot tests. >>> >>> Though if the @build is actually a no-op is it even necessary to fix it rather than just delete it? Sorry I've lost track of where we stand with needing to explicitly build the test library in older versions. >> Unfortunately, I can't recall what the guidelines were for jdk8, but I agree it'd be safer to just remove @build actions here if these tests worked fine w/ jtreg4.1b12 (where these @builds were simply ignored) >> >> Cheers, >> -- Igor >>> >>> Thanks, >>> David >>> >>>> -- Igor >>>>> On Oct 24, 2018, at 10:06 PM, David Holmes wrote: >>>>> >>>>> Hi Vaibhav, >>>>> >>>>> cc'ing jdk8u-dev to get some input from the maintainers. >>>>> >>>>> I was very confused until I realized this RFR was for 8u! :) >>>>> >>>>> Even so, after reading the bug report I'm still quite confused. This has been "broken" since the test was added in January 2016, but only causes a failure if jtreg 4.1b13 is used - is that correct? What is the default version of jtreg being used for 8u today? >>>>> >>>>> I'd be happy to review this but given I have no idea how the 8u testing is being handled in general I can't say whether this is the right fix ?? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 25/10/2018 2:18 PM, Vaibhav Choudhary wrote: >>>>>> Hi, >>>>>> Please review this tiny fix. >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8151295 >>>>>> Fix: http://cr.openjdk.java.net/~rpatil/8151295/webrev.00/ >>>>>> Desc: In stead of @build jdk.test.lib.* we need to use @build com.oracle.java.testlibrary.* >>>>>> These two tests are failing in nightly. >>>>>> Thanks, >>>>>> Vaibhav >> > From vaibhav.x.choudhary at oracle.com Tue Oct 30 01:37:47 2018 From: vaibhav.x.choudhary at oracle.com (Vaibhav Choudhary) Date: Tue, 30 Oct 2018 07:07:47 +0530 Subject: RFR(S): [TESTBUG]runtime/ErrorHandling fails when using jtreg 4.1 b13 In-Reply-To: References: <68B1DBB7-3BE1-458C-8143-52BF8D2A2D32@oracle.com> <40BF692C-F6E2-42B6-BEFD-D0EEE80E3EFB@oracle.com> Message-ID: > On 30-Oct-2018, at 6:56 AM, David Holmes wrote: > > On 29/10/2018 6:34 PM, Vaibhav Choudhary wrote: >> Thank you Igor and David for the review. This make sense to remove @build. Here goes the next webrev :- >> http://cr.openjdk.java.net/~rpatil/8151295/webrev.01/ > > The removal seem okay - as long as the required test library classes end up getting built. Neither myself nor Igor are clear on the correct approach in 8u. > Thank you. Yes, it do so. >> This test is failing from quite a long time but its getting ignored as known failure. > > You mean it's been failing for a long time due to a switch to jtreg 4.1 b13? No, test is failing even with previous versions of jtreg. I have changed the description of the bug. > > Thanks, > David Thanks, Vaibhav > >> Thanks, >> Vaibhav Choudhary >> vaibhav.x.choudhary at oracle.com >> https://blogs.oracle.com/vaibhav >>> On 25-Oct-2018, at 11:54 PM, Igor Ignatyev wrote: >>> >>> Hi David, >>> >>>> On Oct 24, 2018, at 10:14 PM, David Holmes wrote: >>>> >>>> Hi Igor, >>>> >>>> On 25/10/2018 3:11 PM, Igor Ignatyev wrote: >>>>> IIRC, prior jtreg 4.1b13 it was fine to have nonexistent classes in @build actions, so the fix is good regardless of used version of jtreg, but are necessary for jtreg 4.1b13+. >>>> >>>> Okay, just wanted to be sure that 8u testing still expects use of hotspot testlibrary implementation in hotspot tests. >>>> >>>> Though if the @build is actually a no-op is it even necessary to fix it rather than just delete it? Sorry I've lost track of where we stand with needing to explicitly build the test library in older versions. >>> Unfortunately, I can't recall what the guidelines were for jdk8, but I agree it'd be safer to just remove @build actions here if these tests worked fine w/ jtreg4.1b12 (where these @builds were simply ignored) >>> >>> Cheers, >>> -- Igor >>>> >>>> Thanks, >>>> David >>>> >>>>> -- Igor >>>>>> On Oct 24, 2018, at 10:06 PM, David Holmes wrote: >>>>>> >>>>>> Hi Vaibhav, >>>>>> >>>>>> cc'ing jdk8u-dev to get some input from the maintainers. >>>>>> >>>>>> I was very confused until I realized this RFR was for 8u! :) >>>>>> >>>>>> Even so, after reading the bug report I'm still quite confused. This has been "broken" since the test was added in January 2016, but only causes a failure if jtreg 4.1b13 is used - is that correct? What is the default version of jtreg being used for 8u today? >>>>>> >>>>>> I'd be happy to review this but given I have no idea how the 8u testing is being handled in general I can't say whether this is the right fix ?? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 25/10/2018 2:18 PM, Vaibhav Choudhary wrote: >>>>>>> Hi, >>>>>>> Please review this tiny fix. >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8151295 >>>>>>> Fix: http://cr.openjdk.java.net/~rpatil/8151295/webrev.00/ >>>>>>> Desc: In stead of @build jdk.test.lib.* we need to use @build com.oracle.java.testlibrary.* >>>>>>> These two tests are failing in nightly. >>>>>>> Thanks, >>>>>>> Vaibhav >>> From fairoz.matte at oracle.com Tue Oct 30 12:59:32 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Tue, 30 Oct 2018 05:59:32 -0700 (PDT) Subject: [8u-dev] Request for Approval: 8212914: Test javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails Message-ID: Hi, Kindly approve the small test bug fix for jdk8u-dev, issue "JDK-8212914: Test javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails" JBS issue - https://bugs.openjdk.java.net/browse/JDK-8212914 Webrev - http://cr.openjdk.java.net/~fmatte/8212914/webrev.03/ Review thread - http://mail.openjdk.java.net/pipermail/2d-dev/2018-October/009581.html Thanks, Fairoz From sean.coffey at oracle.com Tue Oct 30 14:21:41 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 30 Oct 2018 14:21:41 +0000 Subject: [8u-dev] Request for approval : 8209862: CipherCore performance improvement Message-ID: JDK-8207775 introduced some performance regression. I'd like to push this fix which should help minimize the performance hit. I've had feedback from performance team to indicate good results. The JDK 12 patch applies cleanly (after path modification). This patch was also pushed to 11.0.2. bug record : https://bugs.openjdk.java.net/browse/JDK-8209862 review thread : http://mail.openjdk.java.net/pipermail/security-dev/2018-October/018374.html patch : http://hg.openjdk.java.net/jdk/jdk/rev/84fe81feae26 regards, Sean. From rob.mckenna at oracle.com Tue Oct 30 14:31:19 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 30 Oct 2018 14:31:19 +0000 Subject: [8u-dev] Request for approval : 8209862: CipherCore performance improvement In-Reply-To: References: Message-ID: <20181030143119.GB3771@vimes> Approved -Rob On 30/10/18 14:21, Se?n Coffey wrote: > JDK-8207775 introduced some performance regression. I'd like to push this > fix which should help minimize the performance hit. I've had feedback from > performance team to indicate good results. > > The JDK 12 patch applies cleanly (after path modification). This patch was > also pushed to 11.0.2. > > bug record : https://bugs.openjdk.java.net/browse/JDK-8209862 > review thread : > http://mail.openjdk.java.net/pipermail/security-dev/2018-October/018374.html > patch : http://hg.openjdk.java.net/jdk/jdk/rev/84fe81feae26 > > regards, > Sean. > From hohensee at amazon.com Tue Oct 30 16:04:38 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 30 Oct 2018 16:04:38 +0000 Subject: [8u-dev] Request for approval of CR 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: References: <613F1C8E-896E-4CF4-82E6-F4B3384834D6@amazon.com> <23931D5F-B228-4E06-8DD6-C787A1E8AA93@amazon.com> Message-ID: <60BAEEDF-C9B1-4D8C-9C57-571EDF457A52@amazon.com> Thanks for your review, Jc. :) Paul From: JC Beyler Date: Tuesday, October 30, 2018 at 8:48 AM To: "Hohensee, Paul" Cc: "jdk8u-dev at openjdk.java.net" , "joe.darcy at oracle.com" Subject: Re: [8u-dev] Request for approval of CR 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Hi all, If it helps, I reviewed the change and compared it with the JDK11 change and it looks good to me but I'm nor a reviewer, nor someone who understands the gates when considering a backport :) Jc On Fri, Oct 26, 2018 at 10:39 AM Hohensee, Paul > wrote: Ping. :) On 10/25/18, 8:01 AM, "jdk8u-dev on behalf of Hohensee, Paul" on behalf of hohensee at amazon.com> wrote: Please approve a G1 serviceability bug backport. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 CSR: https://bugs.openjdk.java.net/browse/JDK-8196719 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-June/022305.html Backport review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-October/023507.html Backport reviewers: tschatzl, jcbeyler I don?t know what the process is for approving a CSR associated with a backport, hence cc?ing Joe. The CSR documents the behavior change due to this fix, but as it notes, there is no spec change. Thanks, Paul -- Thanks, Jc From mbalao at redhat.com Tue Oct 30 18:02:36 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 30 Oct 2018 15:02:36 -0300 Subject: [8u-dev] Request for review and approval: JDK-8213154: Update copyright headers of files in src tree that are missing Classpath exception Message-ID: Hi, Can I have a review for the JDK-8 backport of JDK-8213154 ? * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00.jdk8u/ * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00.jdk8u.zip Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8213154 From gnu.andrew at redhat.com Tue Oct 30 19:45:20 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 30 Oct 2018 19:45:20 +0000 Subject: [8u] Request for Approval for JDK-8197429: Increased stack guard causes segfaults on x86-32 Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8197429 Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8197429/webrev.01/ Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030076.html 8u review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007647.html Reviewed for 8u by Andrew Haley 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 mbalao at redhat.com Tue Oct 30 20:41:33 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 30 Oct 2018 17:41:33 -0300 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <82660e66-9260-135e-e590-2172e4077514@oracle.com> References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> <82660e66-9260-135e-e590-2172e4077514@oracle.com> Message-ID: Hi Valerie, I've fixed a copyright issue in a few headers: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.11.jdk8u/ * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.11.jdk8u.zip This has been tested on Linux x86_64 platform against sun/security/pkcs11 test suite. I've not noticed any regression. Thanks, Martin.- On Mon, Oct 29, 2018 at 8:53 PM, Valerie Peng wrote: > Hi Martin, > > The 8u changes look fine. > > Just double checking, what are the platforms and regression tests which > you use for validating the 8u backport? > Thanks, > Valerie > > > On 10/23/2018 5:18 AM, Martin Balao wrote: > > Hi Valerie, > > This backport was trivial, only a few changes required: > > * Paths > * JDK-8210912 fix included [1] > * Minor adjustments when checking TLS version > in P11TlsKeyMaterialGenerator, P11TlsMasterSecretGenerator and > P11TlsRsaPremasterSecretGenerator > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8210912 > > On Mon, Oct 22, 2018 at 7:17 PM, Valerie Peng > wrote: > >> Martin, >> >> Sean asked me to help review this backport. Are the changes for 8u >> identical to those for JDK 12 (minus the path differences)? Is there any 8u >> specific modifications? >> >> Thanks, >> >> Valerie >> >> >> >> On 10/15/2018 8:15 AM, Martin Balao wrote: >> >>> Hi Sean, >>> >>> Any updates on this? >>> >>> Kind regards, >>> Martin.- >>> >>> On Tue, Sep 25, 2018 at 6:56 PM, Se?n Coffey >>> wrote: >>> >>> Thanks for logging this request Martin. Looking into this and hope to >>>> reply shortly. >>>> >>>> regards, >>>> Sean. >>>> >>>> >>>> >>>> On 25/09/2018 10:07, Martin Balao wrote: >>>> >>>> Hi, >>>>> >>>>> I'd like to request an enhancement backport approval for JDK-8029661 >>>>> [1]. >>>>> >>>>> Supporting TLS v1.2 algorithms in SunPKCS11 crypto provider would be >>>>> highly >>>>> beneficial for operating in a FIPS-140 environment. This is highly >>>>> critical >>>>> for both security and compliance reasons to many OpenJDK users; >>>>> including >>>>> corporations, public sector and other organizations. TLS 1.2 is >>>>> currently >>>>> the most wide-spread TLS version. >>>>> >>>>> Changes done as part of this enhancement are constrained to SunPKCS11 >>>>> crypto provider and do not affect SSL/TLS code. Risk involved is low >>>>> mainly >>>>> because of the following reasons: 1) this enhancement is an extension >>>>> on >>>>> top of currently supported mechanisms (no major refactorings were >>>>> applied); >>>>> and, 2) backport is straight forward because affected code has not >>>>> suffered >>>>> major changes since JDK 8 release. >>>>> >>>>> JDK-8029661 has been reviewed by Valerie Peng on security-dev list [2] >>>>> and >>>>> has been merged to JDK [3] base line. Regression testing on >>>>> sun/security/pkcs11 category experienced no regressions because of this >>>>> enhancement on both JDK base line and JDK 8. >>>>> >>>>> JDK 8 backport webrev: >>>>> >>>>> * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >>>>> 8029661.webrev.10.jdk8u/ >>>>> * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ >>>>> 8029661.webrev.10.jdk8u.zip >>>>> >>>>> Please note that this backport includes JDK-8210912 fix [4]. >>>>> >>>>> Thanks, >>>>> Martin.- >>>>> >>>>> -- >>>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8029661 >>>>> [2] - http://mail.openjdk.java.net/pipermail/security-dev/ >>>>> 2018-September/018278.html >>>>> [3] - http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed >>>>> [4] - https://bugs.openjdk.java.net/browse/JDK-8210912 >>>>> >>>>> >>>> >> > > From volker.simonis at gmail.com Wed Oct 31 15:30:29 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 31 Oct 2018 16:30:29 +0100 Subject: [8u-dev] RFA: 8213151: [AIX] Some class library files are missing the Classpath exception Message-ID: Hi, can I please get an approval for down-porting "8213151: [AIX] Some class library files are missing the Classpath exception" from 12 to 8u-dev? JBS: https://bugs.openjdk.java.net/browse/JDK-8213151 jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/896e80158d35 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056321.html webrev: http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ This patch fixes a licensing issue which is important to be fixed in update release as well. The change applies cleanly to the 8u-dev/jdk repo modulo the usual directory shuffling and comes with no risk because it only changes the comment section which contains the license information. Thank you and best regards, Volker From Sergey.Bylokhov at oracle.com Wed Oct 31 15:42:18 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Oct 2018 08:42:18 -0700 Subject: [8u-dev] RFA: 8213151: [AIX] Some class library files are missing the Classpath exception In-Reply-To: References: Message-ID: <2969be79-311a-20a0-1f24-89fecd262005@oracle.com> Looks fine. On 31/10/2018 08:30, Volker Simonis wrote: > Hi, > > can I please get an approval for down-porting "8213151: [AIX] Some > class library files are missing the Classpath exception" from 12 to > 8u-dev? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213151 > jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/896e80158d35 > review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056321.html > webrev: http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ > > This patch fixes a licensing issue which is important to be fixed in > update release as well. The change applies cleanly to the 8u-dev/jdk > repo modulo the usual directory shuffling and comes with no risk > because it only changes the comment section which contains the license > information. > > Thank you and best regards, > Volker > -- Best regards, Sergey. From gnu.andrew at redhat.com Wed Oct 31 16:22:58 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 31 Oct 2018 16:22:58 +0000 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> Message-ID: On Tue, 23 Oct 2018 at 13:19, Martin Balao wrote: > > Hi Valerie, > > This backport was trivial, only a few changes required: > > * Paths > * JDK-8210912 fix included [1] > * Minor adjustments when checking TLS version > in P11TlsKeyMaterialGenerator, P11TlsMasterSecretGenerator > and P11TlsRsaPremasterSecretGenerator > > Thanks, > Martin.- > Having 8029661 be that fix alone on 12, but 8029661+8210912 on 8u is confusing. I can understand the desire to pair them, given we know 8029661 breaks the build without the other change, but at the very least, it should be mentioned in the commit message, so it shows up in searches. It doesn't appear to be at present. 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 volker.simonis at gmail.com Wed Oct 31 16:28:53 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 31 Oct 2018 17:28:53 +0100 Subject: [8u-dev] RFA: 8213151: [AIX] Some class library files are missing the Classpath exception In-Reply-To: <2969be79-311a-20a0-1f24-89fecd262005@oracle.com> References: <2969be79-311a-20a0-1f24-89fecd262005@oracle.com> Message-ID: Thanks, Sergey! On Wed, Oct 31, 2018 at 4:41 PM Sergey Bylokhov wrote: > > Looks fine. > > On 31/10/2018 08:30, Volker Simonis wrote: > > Hi, > > > > can I please get an approval for down-porting "8213151: [AIX] Some > > class library files are missing the Classpath exception" from 12 to > > 8u-dev? > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213151 > > jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/896e80158d35 > > review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056321.html > > webrev: http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ > > > > This patch fixes a licensing issue which is important to be fixed in > > update release as well. The change applies cleanly to the 8u-dev/jdk > > repo modulo the usual directory shuffling and comes with no risk > > because it only changes the comment section which contains the license > > information. > > > > Thank you and best regards, > > Volker > > > > > -- > Best regards, Sergey. From mbalao at redhat.com Wed Oct 31 20:13:12 2018 From: mbalao at redhat.com (Martin Balao) Date: Wed, 31 Oct 2018 17:13:12 -0300 Subject: [8u] Request for enhancement backport approval for CR JDK-8029661 - Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <235a8819-2870-dfc9-09ce-9d8be7d68ce6@oracle.com> Message-ID: On Wed, Oct 31, 2018 at 1:22 PM, Andrew Hughes wrote: > > Having 8029661 be that fix alone on 12, but 8029661+8210912 on > 8u is confusing. I can understand the desire to pair them, given > we know 8029661 breaks the build without the other change, but > at the very least, it should be mentioned in the commit message, > so it shows up in searches. It doesn't appear to be at present. That's right, thanks for pointing this out. Webrev.12: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.12.jdk8u/ * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.12.jdk8u.zip @Valerie: are you okay to go now? Kind regards, Martin.-