From david.buck at oracle.com Wed Jun 1 07:50:42 2016 From: david.buck at oracle.com (David Buck) Date: Wed, 1 Jun 2016 16:50:42 +0900 Subject: [8u-dev] Request for approval : 8153192: (se) Selector.select(long) uses wrong timeout after EINTR (lnx) In-Reply-To: <017e55b9-f9a6-6042-031d-a0fdd1a3a755@oracle.com> References: <017e55b9-f9a6-6042-031d-a0fdd1a3a755@oracle.com> Message-ID: <49D09CD3-7C76-4004-9ED8-583CEDB45337@oracle.com> approved for backport to 8u-dev Cheers, -Buck > On May 31, 2016, at 22:37, Se?n Coffey wrote: > > I'd like to backport this nio fix from jdk9 to jdk8u. Applies cleanly after modular path unshuffling. > > https://bugs.openjdk.java.net/browse/JDK-8153192 > jdk 9 changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5dd02e390cf8 > review thread : http://mail.openjdk.java.net/pipermail/nio-dev/2016-May/003674.html > > -- > Regards, > Sean. > From sundararajan.athijegannathan at oracle.com Wed Jun 1 10:04:22 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 15:34:22 +0530 Subject: [8u] approval request for JDK-8141541: Simplify Nashorn's Context class loader handling Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8141541 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-November/005530.html jdk8u webrev: http://cr.openjdk.java.net/~sundar/8141541/8u/webrev.00/ Backported "as is" without any changes except for modular source layout difference. Thanks, -Sundar From david.buck at oracle.com Wed Jun 1 10:29:53 2016 From: david.buck at oracle.com (David Buck) Date: Wed, 1 Jun 2016 19:29:53 +0900 Subject: [8u] approval request for JDK-8141541: Simplify Nashorn's Context class loader handling In-Reply-To: References: Message-ID: approved for backport to 8u-dev Cheers, -Buck > On Jun 1, 2016, at 19:04, Sundararajan Athijegannathan wrote: > > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8141541 > > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-November/005530.html > > jdk8u webrev: http://cr.openjdk.java.net/~sundar/8141541/8u/webrev.00/ > > Backported "as is" without any changes except for modular source layout > difference. > > Thanks, > > -Sundar > From alexandr.scherbatiy at oracle.com Wed Jun 1 11:03:40 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 1 Jun 2016 14:03:40 +0300 Subject: [8u-dev] Request for approval: 8157838 Personalized Windows Font Size is not taken into account in Java8u102 Message-ID: <30322662-75c4-c2f7-bb28-db22b53ac82e@oracle.com> Hello, Could you approve the fix for JDK 8u-dev: JDK-8157838 Personalized Windows Font Size is not taken into account in Java8u102 The bug: https://bugs.openjdk.java.net/browse/JDK-8157838 The webrev: http://cr.openjdk.java.net/~alexsch/8157838/webrev.00 The review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011408.html Theer is no a link to JDK 9 changeset because the proposed fix reverts fix JDK-8076545 in JDK 8u-dev only. Thanks, Alexandr. From sundararajan.athijegannathan at oracle.com Wed Jun 1 12:13:21 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 1 Jun 2016 17:43:21 +0530 Subject: [8u] approval request for 8158338: Nashorn's ScriptLoader split delegation has to be adjusted Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8158338 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006259.html jdk8u webrev: http://cr.openjdk.java.net/~sundar/8158338/8u/webrev.00/ Backport patch wouldn't apply "as is" because of jdk9/Module specific changes in jdk9 are not applicable to jdk8u. CC'ing this approval to nashorn team for backport webrev review. Thanks, -Sundar From marcus at lagergren.net Wed Jun 1 13:02:16 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Wed, 1 Jun 2016 15:02:16 +0200 Subject: [8u] approval request for 8158338: Nashorn's ScriptLoader split delegation has to be adjusted In-Reply-To: References: Message-ID: <6C9A3E24-3C81-40DD-A7E6-B2014DEE4B13@lagergren.net> +1 > On 01 Jun 2016, at 14:13, Sundararajan Athijegannathan wrote: > > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158338 > > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006259.html > > jdk8u webrev: http://cr.openjdk.java.net/~sundar/8158338/8u/webrev.00/ > > Backport patch wouldn't apply "as is" because of jdk9/Module specific > changes in jdk9 are not applicable to jdk8u. > > CC'ing this approval to nashorn team for backport webrev review. > > Thanks, > > -Sundar > > From sean.coffey at oracle.com Wed Jun 1 13:04:59 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 1 Jun 2016 14:04:59 +0100 Subject: [8u] approval request for 8158338: Nashorn's ScriptLoader split delegation has to be adjusted In-Reply-To: <6C9A3E24-3C81-40DD-A7E6-B2014DEE4B13@lagergren.net> References: <6C9A3E24-3C81-40DD-A7E6-B2014DEE4B13@lagergren.net> Message-ID: <574EDD7B.4070308@oracle.com> Approved for jdk8u-dev. Regards, Sean. On 01/06/16 14:02, Marcus Lagergren wrote: > +1 > >> On 01 Jun 2016, at 14:13, Sundararajan Athijegannathan wrote: >> >> Please approve. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158338 >> >> jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006259.html >> >> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8158338/8u/webrev.00/ >> >> Backport patch wouldn't apply "as is" because of jdk9/Module specific >> changes in jdk9 are not applicable to jdk8u. >> >> CC'ing this approval to nashorn team for backport webrev review. >> >> Thanks, >> >> -Sundar >> >> From sean.coffey at oracle.com Wed Jun 1 21:45:06 2016 From: sean.coffey at oracle.com (Sean Coffey) Date: Wed, 1 Jun 2016 22:45:06 +0100 Subject: [8u-dev] Request for approval: 8157838 Personalized Windows Font Size is not taken into account in Java8u102 In-Reply-To: <30322662-75c4-c2f7-bb28-db22b53ac82e@oracle.com> References: <30322662-75c4-c2f7-bb28-db22b53ac82e@oracle.com> Message-ID: <574F5762.8050107@oracle.com> Approved. regards, Sean. On 01/06/2016 12:03, Alexandr Scherbatiy wrote: > > Hello, > > Could you approve the fix for JDK 8u-dev: > > JDK-8157838 Personalized Windows Font Size is not taken into account > in Java8u102 > > The bug: https://bugs.openjdk.java.net/browse/JDK-8157838 > The webrev: http://cr.openjdk.java.net/~alexsch/8157838/webrev.00 > The review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011408.html > > Theer is no a link to JDK 9 changeset because the proposed fix reverts > fix JDK-8076545 in JDK 8u-dev only. > > Thanks, > Alexandr. > > From ramanand.patil at oracle.com Thu Jun 2 09:24:27 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 2 Jun 2016 02:24:27 -0700 (PDT) Subject: [8u-dev] Request for Approval: Backport of 8151876: (tz) Support tzdata2016d Message-ID: <28e2e5e8-f99b-462f-aaf3-8cc65bd4803c@default> Hi, Please approve the backport of 8151876 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23d88201b666 JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2016-May/001953.html Changes apply cleanly to jdk8u-dev after path reshuffling with very minor edits and the below exceptions: 1. test/java/util/TimeZone/Bug8149452.java 2. test/java/util/TimeZone/CheckDisplayNames.java Both of these test cases are not present in JDK8. All other test cases related to TimeZone are passed. Also, for reference I have uploaded the JDK8 webrev at- http://cr.openjdk.java.net/~rpatil/8157217/webrev.00/ Regards, Ramanand. From rob.mckenna at oracle.com Thu Jun 2 12:51:35 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 2 Jun 2016 13:51:35 +0100 Subject: [8u-dev] Request for Approval: Backport of 8151876: (tz) Support tzdata2016d In-Reply-To: <28e2e5e8-f99b-462f-aaf3-8cc65bd4803c@default> References: <28e2e5e8-f99b-462f-aaf3-8cc65bd4803c@default> Message-ID: <20160602125135.GB3321@vimes> Approved -Rob On 02/06/16 02:24, Ramanand Patil wrote: > Hi, > > > Please approve the backport of 8151876 to 8u-dev. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 > > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23d88201b666 > > JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2016-May/001953.html > > > > Changes apply cleanly to jdk8u-dev after path reshuffling with very minor edits and the below exceptions: > > 1. test/java/util/TimeZone/Bug8149452.java > > 2. test/java/util/TimeZone/CheckDisplayNames.java > > Both of these test cases are not present in JDK8. > > > > All other test cases related to TimeZone are passed. > > > > Also, for reference I have uploaded the JDK8 webrev at- http://cr.openjdk.java.net/~rpatil/8157217/webrev.00/ > > > > > > Regards, > > Ramanand. > > From alexey.ivanov at oracle.com Thu Jun 2 12:59:45 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 2 Jun 2016 15:59:45 +0300 Subject: [8u-dev] Request for approval for 8078382: Wrong glyph is displayed for a derived font Message-ID: Hello, Could you please approve the following backport of the fix to 8u-dev? The patch from JDK 9 applies cleanly after paths unshuffling. JBS: https://bugs.openjdk.java.net/browse/JDK-8078382 JDK 9 webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ Code review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-July/005562.html http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006747.html http://mail.openjdk.java.net/pipermail/2d-dev/2016-May/006935.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b803887ddddc Thanks, Alexey From rob.mckenna at oracle.com Thu Jun 2 14:03:21 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 2 Jun 2016 15:03:21 +0100 Subject: [8u-dev] Request for approval for 8078382: Wrong glyph is displayed for a derived font In-Reply-To: References: Message-ID: <20160602140321.GC3321@vimes> Approved -Rob On 02/06/16 03:59, Alexey Ivanov wrote: > Hello, > > Could you please approve the following backport of the fix to 8u-dev? > The patch from JDK 9 applies cleanly after paths unshuffling. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8078382 > > JDK 9 webrev: http://cr.openjdk.java.net/~bae/8078382/9/webrev.00/ > > Code review: > http://mail.openjdk.java.net/pipermail/2d-dev/2015-July/005562.html > http://mail.openjdk.java.net/pipermail/2d-dev/2016-April/006747.html > http://mail.openjdk.java.net/pipermail/2d-dev/2016-May/006935.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b803887ddddc > > > Thanks, > Alexey From artem.kosarev at oracle.com Thu Jun 2 19:28:08 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Thu, 2 Jun 2016 22:28:08 +0300 Subject: [8u-dev] Request for approval: 8154009 Some methods of java.security.Security require more permissions, than necessary Message-ID: <3b8e29f4-767c-d046-02b7-49254640f8a9@oracle.com> Hello, Could you approve the fix for JDK 8u-dev: JDK-8154009 Some methods of java.security.Security require more permissions, than necessary The bug: https://bugs.openjdk.java.net/browse/JDK-8154009 The webrev: http://cr.openjdk.java.net/~akosarev/8154009/webrev.01 The review thread: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014029.html This bug fix in not applicable for JDK 9, due to this there is no JDK 9 changeset. Thanks, Alexandr. From sundararajan.athijegannathan at oracle.com Fri Jun 3 06:39:53 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 3 Jun 2016 12:09:53 +0530 Subject: [8u] approval request for 8158467: AccessControlException is thrown on public Java class access if "script app loader" is set to null Message-ID: <2300ae60-d834-5fb0-fe88-4da830cc1cfa@oracle.com> Please approve. bug: https://bugs.openjdk.java.net/browse/JDK-8158467 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006274.html jdk8u webrev: http://cr.openjdk.java.net/~sundar/8158467/8u/webrev.00/ Backported "as is" except for modular source layout difference. -Sundar From cheleswer.sahu at oracle.com Fri Jun 3 06:51:58 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 2 Jun 2016 23:51:58 -0700 (PDT) Subject: [8u] RFA: 8154144 : Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely" Message-ID: Hi, May I please have approval to backport this fix from JDK9 to JDK8u. This fix applies cleanly. I have built and tested using JPRT. As I don't have committer status for JDK8u, "Kevin Walls" will push this for me in JDK8u. JBS Link: https://bugs.openjdk.java.net/browse/JDK-8154144 JDK9 change-set: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/73608cd4f89a Review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-May/019577.html Regards, Cheleswer From david.buck at oracle.com Fri Jun 3 06:56:36 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 3 Jun 2016 15:56:36 +0900 Subject: [8u] approval request for 8158467: AccessControlException is thrown on public Java class access if "script app loader" is set to null In-Reply-To: <2300ae60-d834-5fb0-fe88-4da830cc1cfa@oracle.com> References: <2300ae60-d834-5fb0-fe88-4da830cc1cfa@oracle.com> Message-ID: <24E3A7B4-A1AE-4E39-B21B-4D0AA9C7DDCA@oracle.com> approved for backport to 8u-dev Cheers, -Buck 2016/06/03 15:39?Sundararajan Athijegannathan ??????: > Please approve. > > bug: https://bugs.openjdk.java.net/browse/JDK-8158467 > > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006274.html > > jdk8u webrev: http://cr.openjdk.java.net/~sundar/8158467/8u/webrev.00/ > > Backported "as is" except for modular source layout difference. > > -Sundar > From david.buck at oracle.com Fri Jun 3 07:01:12 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 3 Jun 2016 16:01:12 +0900 Subject: [8u] RFA: 8154144 : Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely" In-Reply-To: References: Message-ID: <5D5591D0-CB64-4F58-BD93-CCB26061D15E@oracle.com> approved for backport to 8u-dev Cheers, -Buck 2016/06/03 15:51?Cheleswer Sahu ??????: > Hi, > > > > May I please have approval to backport this fix from JDK9 to JDK8u. This fix applies cleanly. I have built and tested using JPRT. As I don't have committer status for JDK8u, "Kevin Walls" will push this for me in JDK8u. > > > > JBS Link: https://bugs.openjdk.java.net/browse/JDK-8154144 > > JDK9 change-set: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/73608cd4f89a > > Review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-May/019577.html > > > > > > Regards, > > Cheleswer From artem.kosarev at oracle.com Fri Jun 3 13:00:18 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Fri, 3 Jun 2016 16:00:18 +0300 Subject: [8u-dev] Request for approval for 8044193: Need to add tests for AES cipher and 8049021: Add smartcardio tests with APDU buffer Message-ID: <7202fea8-1814-95e0-c307-cb9776ea186d@oracle.com> Hello, Please approve direct backports of regression tests to 8u-dev. Tests were originally reviewed by Valerie Peng. "Need to add tests for AES cipher" https://bugs.openjdk.java.net/browse/JDK-8044193 Review thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-January/011596.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1ab727276fd0 and "Add smartcardio tests with APDU buffer" https://bugs.openjdk.java.net/browse/JDK-8049021 Review thread: http://mail.openjdk.java.net/pipermail/security-dev/2014-December/011551.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f67043c027d4 Thank you, Artem Kosarev. From rob.mckenna at oracle.com Fri Jun 3 13:33:36 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 3 Jun 2016 14:33:36 +0100 Subject: [8u-dev] Request for approval for 8044193: Need to add tests for AES cipher and 8049021: Add smartcardio tests with APDU buffer In-Reply-To: <7202fea8-1814-95e0-c307-cb9776ea186d@oracle.com> References: <7202fea8-1814-95e0-c307-cb9776ea186d@oracle.com> Message-ID: <20160603133336.GA2632@vimes> Approved -Rob On 03/06/16 04:00, Artem Kosarev wrote: > Hello, > > Please approve direct backports of regression tests to 8u-dev. > > Tests were originally reviewed by Valerie Peng. > > "Need to add tests for AES cipher" > https://bugs.openjdk.java.net/browse/JDK-8044193 > Review thread: > http://mail.openjdk.java.net/pipermail/security-dev/2015-January/011596.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1ab727276fd0 > > > and > > "Add smartcardio tests with APDU buffer" > https://bugs.openjdk.java.net/browse/JDK-8049021 > Review thread: > http://mail.openjdk.java.net/pipermail/security-dev/2014-December/011551.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f67043c027d4 > > Thank you, > Artem Kosarev. > From rob.mckenna at oracle.com Fri Jun 3 13:34:43 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 3 Jun 2016 14:34:43 +0100 Subject: [8u-dev] Request for approval: 8154009 Some methods of java.security.Security require more permissions, than necessary In-Reply-To: <3b8e29f4-767c-d046-02b7-49254640f8a9@oracle.com> References: <3b8e29f4-767c-d046-02b7-49254640f8a9@oracle.com> Message-ID: <20160603133443.GB2632@vimes> Approved -Rob On 02/06/16 10:28, Artem Kosarev wrote: > Hello, > > Could you approve the fix for JDK 8u-dev: > > JDK-8154009 Some methods of java.security.Security require more permissions, > than necessary > > The bug: https://bugs.openjdk.java.net/browse/JDK-8154009 > The webrev: http://cr.openjdk.java.net/~akosarev/8154009/webrev.01 > The review thread: > http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014029.html > > This bug fix in not applicable for JDK 9, due to this there is no JDK 9 > changeset. > > Thanks, > Alexandr. > From srinivas.dama at oracle.com Mon Jun 6 15:41:39 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Mon, 6 Jun 2016 08:41:39 -0700 (PDT) Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <574C3F4D.1010704@oracle.com> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> <574C3F4D.1010704@oracle.com> Message-ID: <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> Hi, There are some 8u specific changes, Please do a backport review. Here are the links. Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 Jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006022.html Jdk9 webrev : http://cr.openjdk.java.net/~sdama/8138906/webrev.00/ Jdk8u webrev: http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.01/ Regards, Srinivas -----Original Message----- From: Se?n Coffey Sent: Monday, May 30, 2016 6:56 PM To: Srinivas Dama Subject: Re: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails Approved for jdk8u-dev. If the code differs from the JDK 9 fix, please obtain a code review before pushing. Regards, Sean. On 26/05/16 17:30, Srinivas Dama wrote: > Hi, > > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 > Jdk9 review thread : > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/00599 > 1.html Jdk8u-webrev : > http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ > > Regards, > Srinivas From hannes.wallnoefer at oracle.com Mon Jun 6 16:21:16 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 6 Jun 2016 18:21:16 +0200 Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> <574C3F4D.1010704@oracle.com> <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> Message-ID: <5755A2FC.6040304@oracle.com> Hi Srini, backport looks good. Hannes Am 2016-06-06 um 17:41 schrieb Srinivas Dama: > Hi, > > > There are some 8u specific changes, Please do a backport review. > > Here are the links. > Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 > Jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006022.html > Jdk9 webrev : > http://cr.openjdk.java.net/~sdama/8138906/webrev.00/ > > Jdk8u webrev: > http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.01/ > > Regards, > Srinivas > > -----Original Message----- > From: Se?n Coffey > Sent: Monday, May 30, 2016 6:56 PM > To: Srinivas Dama > Subject: Re: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails > > Approved for jdk8u-dev. If the code differs from the JDK 9 fix, please obtain a code review before pushing. > > Regards, > Sean. > > On 26/05/16 17:30, Srinivas Dama wrote: >> Hi, >> >> Please approve. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 >> Jdk9 review thread : >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/00599 >> 1.html Jdk8u-webrev : >> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ >> >> Regards, >> Srinivas From ivan.gerasimov at oracle.com Mon Jun 6 17:22:49 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 6 Jun 2016 20:22:49 +0300 Subject: [8u-dev] Request for Review & Approval to backport: 8073542: File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c In-Reply-To: References: <8d0c138a-4326-fb30-5628-55a3947a6789@oracle.com> Message-ID: Could someone please help review this simple backport? Thanks in advance, Ivan On 29.05.2016 21:08, Ivan Gerasimov wrote: > As this has to be re-reviewed, sending the request to net-dev list as > well. > > > On 27.05.2016 16:46, Ivan Gerasimov wrote: >> Hello! >> >> >> I'd like to backport the fix to jdk8u-dev. >> >> The fix had to be slightly adjusted due to the different way the >> error messages are retrieved in jdk8. >> >> Here's the webrev with modified fix: >> http://cr.openjdk.java.net/~igerasim/8073542/00/webrev/ >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073542 >> Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb6e5a409fef >> Jdk9 review: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035223.html >> >> > > With kind regards, > Ivan > > From Roger.Riggs at Oracle.com Mon Jun 6 17:45:00 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 6 Jun 2016 13:45:00 -0400 Subject: [8u-dev] Request for Review & Approval to backport: 8073542: File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c In-Reply-To: References: <8d0c138a-4326-fb30-5628-55a3947a6789@oracle.com> Message-ID: <886f9c72-64cf-98a4-1cf5-9c9d9371b86d@Oracle.com> Looks fine. Roger On 6/6/2016 1:22 PM, Ivan Gerasimov wrote: > Could someone please help review this simple backport? > > > Thanks in advance, > > Ivan > > > On 29.05.2016 21:08, Ivan Gerasimov wrote: >> As this has to be re-reviewed, sending the request to net-dev list as >> well. >> >> >> On 27.05.2016 16:46, Ivan Gerasimov wrote: >>> Hello! >>> >>> >>> I'd like to backport the fix to jdk8u-dev. >>> >>> The fix had to be slightly adjusted due to the different way the >>> error messages are retrieved in jdk8. >>> >>> Here's the webrev with modified fix: >>> http://cr.openjdk.java.net/~igerasim/8073542/00/webrev/ >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073542 >>> Jdk9 changeset: >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb6e5a409fef >>> Jdk9 review: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035223.html >>> >>> >> >> With kind regards, >> Ivan >> >> > From ivan.gerasimov at oracle.com Mon Jun 6 21:50:39 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 7 Jun 2016 00:50:39 +0300 Subject: [8u-dev] Request for Review & Approval to backport: 8073542: File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c In-Reply-To: <886f9c72-64cf-98a4-1cf5-9c9d9371b86d@Oracle.com> References: <8d0c138a-4326-fb30-5628-55a3947a6789@oracle.com> <886f9c72-64cf-98a4-1cf5-9c9d9371b86d@Oracle.com> Message-ID: Thanks! Pushed. With kind regards, Ivan On 06.06.2016 20:45, Roger Riggs wrote: > Looks fine. > > Roger > > > On 6/6/2016 1:22 PM, Ivan Gerasimov wrote: >> Could someone please help review this simple backport? >> >> >> Thanks in advance, >> >> Ivan >> >> >> On 29.05.2016 21:08, Ivan Gerasimov wrote: >>> As this has to be re-reviewed, sending the request to net-dev list >>> as well. >>> >>> >>> On 27.05.2016 16:46, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> >>>> I'd like to backport the fix to jdk8u-dev. >>>> >>>> The fix had to be slightly adjusted due to the different way the >>>> error messages are retrieved in jdk8. >>>> >>>> Here's the webrev with modified fix: >>>> http://cr.openjdk.java.net/~igerasim/8073542/00/webrev/ >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073542 >>>> Jdk9 changeset: >>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb6e5a409fef >>>> Jdk9 review: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035223.html >>>> >>>> >>> >>> With kind regards, >>> Ivan >>> >>> >> > > From mallikarjuna.avaluri at oracle.com Tue Jun 7 05:56:07 2016 From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri) Date: Tue, 7 Jun 2016 11:26:07 +0530 Subject: Request for approval: backport of JDK-8075297 : Tests for RFEs 4515853 and 4745056 Message-ID: Hello, Please approve a direct backport of tests from jdk 9. Patch applied cleanly and tested with JPRT. JDK-8075297 - Tests for RFEs 4515853 and 4745056 https://bugs.openjdk.java.net/browse/JDK-8075297 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-July/012586.html The JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5f7e9ef899f9 Thanks, Mallikarjuna Avaluri From david.buck at oracle.com Tue Jun 7 06:08:17 2016 From: david.buck at oracle.com (David Buck) Date: Tue, 7 Jun 2016 15:08:17 +0900 Subject: Request for approval: backport of JDK-8075297 : Tests for RFEs 4515853 and 4745056 In-Reply-To: References: Message-ID: <0E742C3E-F402-451A-AA69-79D3948781AE@oracle.com> approved for backport to 8u-dev Cheers, -Buck > On Jun 7, 2016, at 14:56, Mallikarjuna Avaluri wrote: > > Hello, > > Please approve a direct backport of tests from jdk 9. > Patch applied cleanly and tested with JPRT. > > JDK-8075297 - Tests for RFEs 4515853 and 4745056 > https://bugs.openjdk.java.net/browse/JDK-8075297 > > > JDK 9 review thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-July/012586.html > The JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5f7e9ef899f9 > > > > Thanks, > Mallikarjuna Avaluri > From michael.haupt at oracle.com Tue Jun 7 07:06:51 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Tue, 7 Jun 2016 09:06:51 +0200 Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <5755A2FC.6040304@oracle.com> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> <574C3F4D.1010704@oracle.com> <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> <5755A2FC.6040304@oracle.com> Message-ID: <97BA0A13-3FC7-4283-9D41-CE68AFC5B77E@oracle.com> Hi all, I'll sponsor the push. Best, Michael > Am 06.06.2016 um 18:21 schrieb Hannes Wallnoefer : > > Hi Srini, > > backport looks good. > > Hannes > > > Am 2016-06-06 um 17:41 schrieb Srinivas Dama: >> Hi, >> >> >> There are some 8u specific changes, Please do a backport review. >> >> Here are the links. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 >> Jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006022.html >> Jdk9 webrev : >> http://cr.openjdk.java.net/~sdama/8138906/webrev.00/ >> >> Jdk8u webrev: >> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.01/ >> >> Regards, >> Srinivas >> >> -----Original Message----- >> From: Se?n Coffey >> Sent: Monday, May 30, 2016 6:56 PM >> To: Srinivas Dama >> Subject: Re: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails >> >> Approved for jdk8u-dev. If the code differs from the JDK 9 fix, please obtain a code review before pushing. >> >> Regards, >> Sean. >> >> On 26/05/16 17:30, Srinivas Dama wrote: >>> Hi, >>> >>> Please approve. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 >>> Jdk9 review thread : >>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/00599 >>> 1.html Jdk8u-webrev : >>> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ >>> >>> Regards, >>> Srinivas > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 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-Nederland, 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 rob.mckenna at oracle.com Tue Jun 7 12:15:34 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 7 Jun 2016 13:15:34 +0100 Subject: approval request for JDK-8138906:Test test/script/trusted/JDK-8087292.js intermittently fails In-Reply-To: <5755A2FC.6040304@oracle.com> References: <2370da2a-7ade-4915-bdf8-a89977f4147e@default> <574C3F4D.1010704@oracle.com> <0916b5b4-6f76-4528-819c-05b4b53f68c0@default> <5755A2FC.6040304@oracle.com> Message-ID: <5756BAE6.7020305@oracle.com> Approved -Rob On 06/06/16 17:21, Hannes Wallnoefer wrote: > Hi Srini, > > backport looks good. > > Hannes > > > Am 2016-06-06 um 17:41 schrieb Srinivas Dama: >> Hi, >> >> >> There are some 8u specific changes, Please do a backport review. >> >> Here are the links. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 >> Jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-March/006022.html >> Jdk9 webrev : >> http://cr.openjdk.java.net/~sdama/8138906/webrev.00/ >> >> Jdk8u webrev: >> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.01/ >> >> Regards, >> Srinivas >> >> -----Original Message----- >> From: Se?n Coffey >> Sent: Monday, May 30, 2016 6:56 PM >> To: Srinivas Dama >> Subject: Re: approval request for JDK-8138906:Test >> test/script/trusted/JDK-8087292.js intermittently fails >> >> Approved for jdk8u-dev. If the code differs from the JDK 9 fix, please >> obtain a code review before pushing. >> >> Regards, >> Sean. >> >> On 26/05/16 17:30, Srinivas Dama wrote: >>> Hi, >>> >>> Please approve. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138906 >>> Jdk9 review thread : >>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-February/00599 >>> 1.html Jdk8u-webrev : >>> http://cr.openjdk.java.net/~sdama/8138906/8u/webrev.00/ >>> >>> Regards, >>> Srinivas > From artem.kosarev at oracle.com Tue Jun 7 18:30:59 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Tue, 7 Jun 2016 21:30:59 +0300 Subject: [8u-dev] Request for Approval for Backport 8075299: Additional tests for krb5 settings Message-ID: Hello, Please approve almost direct backport of regression tests to 8u-dev. Tests were originally reviewed by Max Weijun Wang. "Additional tests for krb5 settings" https://bugs.openjdk.java.net/browse/JDK-8075299 Review thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-September/012788.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a65de09f671f The only change from original fix is adding one test into Problem list due to Product issue: JDK-8158827 http://cr.openjdk.java.net/~akosarev/8075299/webrev.00 Tested with JPRT. Thanks in advance and best regards, Artem Kosarev. From alexandr.scherbatiy at oracle.com Wed Jun 8 12:36:15 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 08 Jun 2016 15:36:15 +0300 Subject: [8u-dev] Request for approval: 8158178 java.awt.SplashScreen.getSize() returns incorrect size for high dpi splash screens Message-ID: <5758113F.8010205@oracle.com> Hello, Could you approve the fix to JDK 8u-dev: JDK-8158178 java.awt.SplashScreen.getSize() returns incorrect size for high dpi splash screens The bug: https://bugs.openjdk.java.net/browse/JDK-8158178 The webrev: http://cr.openjdk.java.net/~alexsch/robin.stevens/8158178/jdk8/webrev.00 The review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011394.html This fix has been integrated into JDK 9 as part of the fix: JDK-8145174 HiDPI splash screen support on Linux http://hg.openjdk.java.net/jdk9/client/jdk/rev/e3fd20ff65cd The whole JDK-8145174 fix is not supposed to be backported to the JDK 8u-dev because JDK 8u-dev does not include HiDPI graphics support for Linux. The solution is to backport only the part which affects HiDPI splash screen support on Mac OS X. Thanks, Alexandr. From rob.mckenna at oracle.com Wed Jun 8 13:49:12 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 8 Jun 2016 14:49:12 +0100 Subject: [8u-dev] Request for Approval for Backport 8075299: Additional tests for krb5 settings In-Reply-To: References: Message-ID: <20160608134912.GA3677@vimes> Approved -Rob On 07/06/16 09:30, Artem Kosarev wrote: > Hello, > > Please approve almost direct backport of regression tests to 8u-dev. > > Tests were originally reviewed by Max Weijun Wang. > > "Additional tests for krb5 settings" > https://bugs.openjdk.java.net/browse/JDK-8075299 > Review thread: > http://mail.openjdk.java.net/pipermail/security-dev/2015-September/012788.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a65de09f671f > > > The only change from original fix is adding one test into Problem list due > to Product issue: JDK-8158827 > > > http://cr.openjdk.java.net/~akosarev/8075299/webrev.00 > > > > Tested with JPRT. > > > Thanks in advance and best regards, > Artem Kosarev. From rob.mckenna at oracle.com Wed Jun 8 13:50:32 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 8 Jun 2016 14:50:32 +0100 Subject: [8u-dev] Request for approval: 8158178 java.awt.SplashScreen.getSize() returns incorrect size for high dpi splash screens In-Reply-To: <5758113F.8010205@oracle.com> References: <5758113F.8010205@oracle.com> Message-ID: <20160608135032.GB3677@vimes> Approved -Rob On 08/06/16 03:36, Alexander Scherbatiy wrote: > > Hello, > > Could you approve the fix to JDK 8u-dev: > JDK-8158178 java.awt.SplashScreen.getSize() returns incorrect size for > high dpi splash screens > > The bug: https://bugs.openjdk.java.net/browse/JDK-8158178 > The webrev: > http://cr.openjdk.java.net/~alexsch/robin.stevens/8158178/jdk8/webrev.00 > The review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011394.html > > This fix has been integrated into JDK 9 as part of the fix: > JDK-8145174 HiDPI splash screen support on Linux > http://hg.openjdk.java.net/jdk9/client/jdk/rev/e3fd20ff65cd > > The whole JDK-8145174 fix is not supposed to be backported to the JDK 8u-dev > because JDK 8u-dev does not include HiDPI graphics support for Linux. > The solution is to backport only the part which affects HiDPI splash screen > support on Mac OS X. > > Thanks, > Alexandr. > From mikhail.cherkasov at oracle.com Thu Jun 9 11:16:07 2016 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 09 Jun 2016 14:16:07 +0300 Subject: [8u] Request for approval for 8158734: JEditorPane.createEditorKitForContentType throws NPE after 6882559 Message-ID: <57594FF7.2010904@oracle.com> Hi all, Could you please approve a direct backport from jdk9 to jdk8: Bug:https://bugs.openjdk.java.net/browse/JDK-8158734 jdk9 review: http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006050.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/f8acbd06989a 8u webrev:http://cr.openjdk.java.net/~mcherkas/8158734/8/webrev/ Thanks, Mikhail. From shilpi.rastogi at oracle.com Thu Jun 9 12:01:33 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Thu, 9 Jun 2016 17:31:33 +0530 Subject: [8u-dev] Request for approval:8147585: Annotations with lambda expressions has parameter result in wrong behavior. Message-ID: <57595A9D.1020203@oracle.com> Hi All, Please approve fix for issue: https://bugs.openjdk.java.net/browse/JDK-8147585 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041624.html Only path has been changed. ( no code change) JDK 9 changeset link: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3f4cce596ada Thanks, Shilpi From sean.coffey at oracle.com Thu Jun 9 12:04:40 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 9 Jun 2016 13:04:40 +0100 Subject: [8u] Request for approval for 8158734: JEditorPane.createEditorKitForContentType throws NPE after 6882559 In-Reply-To: <57594FF7.2010904@oracle.com> References: <57594FF7.2010904@oracle.com> Message-ID: <7c5764d1-7b7a-b6e9-3964-512ebee51bcc@oracle.com> Approved for jdk8u-dev. Regards, Sean. On 09/06/2016 12:16, mikhail cherkasov wrote: > Hi all, > > Could you please approve a direct backport from jdk9 to jdk8: > Bug:https://bugs.openjdk.java.net/browse/JDK-8158734 > jdk9 review: > http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006050.html > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/f8acbd06989a > 8u webrev:http://cr.openjdk.java.net/~mcherkas/8158734/8/webrev/ > > Thanks, > Mikhail. > > > From mikhail.cherkasov at oracle.com Thu Jun 9 12:06:16 2016 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 09 Jun 2016 15:06:16 +0300 Subject: [8u] Request for approval for 8158734: JEditorPane.createEditorKitForContentType throws NPE after 6882559 In-Reply-To: <7c5764d1-7b7a-b6e9-3964-512ebee51bcc@oracle.com> References: <57594FF7.2010904@oracle.com> <7c5764d1-7b7a-b6e9-3964-512ebee51bcc@oracle.com> Message-ID: <57595BB8.2020006@oracle.com> Sean, thank you! On 6/9/2016 3:04 PM, Se?n Coffey wrote: > Approved for jdk8u-dev. > > Regards, > Sean. > > On 09/06/2016 12:16, mikhail cherkasov wrote: >> Hi all, >> >> Could you please approve a direct backport from jdk9 to jdk8: >> Bug:https://bugs.openjdk.java.net/browse/JDK-8158734 >> jdk9 review: >> http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006050.html >> jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/f8acbd06989a >> 8u webrev:http://cr.openjdk.java.net/~mcherkas/8158734/8/webrev/ >> >> Thanks, >> Mikhail. >> >> >> > From sean.coffey at oracle.com Thu Jun 9 12:31:08 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 9 Jun 2016 13:31:08 +0100 Subject: [8u-dev] Request for approval:8147585: Annotations with lambda expressions has parameter result in wrong behavior. In-Reply-To: <57595A9D.1020203@oracle.com> References: <57595A9D.1020203@oracle.com> Message-ID: Approved for jdk8u-dev. Note that the testcase seems to pass on an unpatched JDK for me. I not sure if a CCC is required given that you're interpreting JLS but I'll leave that to you and your team to decide. Regards, Sean. On 09/06/2016 13:01, shilpi.rastogi at oracle.com wrote: > Hi All, > > Please approve fix for > issue: https://bugs.openjdk.java.net/browse/JDK-8147585 > JDK 9 review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041624.html > > Only path has been changed. ( no code change) > JDK 9 changeset link: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3f4cce596ada > > > Thanks, > Shilpi > > > From shafi.s.ahmad at oracle.com Fri Jun 10 06:29:34 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Thu, 9 Jun 2016 23:29:34 -0700 (PDT) Subject: [8u] RFA for JDK-8147451: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) Message-ID: Hi, Please approve this safe change to 8u-dev. Jdk8-bug: https://bugs.openjdk.java.net/browse/JDK-8147451 review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/019793.html webrev link: http://cr.openjdk.java.net/~shshahma/8147451/webrev.02/ Regards, Shafi From david.buck at oracle.com Fri Jun 10 07:58:42 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 10 Jun 2016 16:58:42 +0900 Subject: [8u] RFA for JDK-8147451: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) In-Reply-To: References: Message-ID: <3105B676-E7E8-4223-8808-305787935426@oracle.com> approved for push to jdk8u-dev Thanks for fixing this! Cheers, -Buck > On Jun 10, 2016, at 15:29, Shafi Ahmad wrote: > > Hi, > > Please approve this safe change to 8u-dev. > > Jdk8-bug: https://bugs.openjdk.java.net/browse/JDK-8147451 > review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/019793.html > webrev link: http://cr.openjdk.java.net/~shshahma/8147451/webrev.02/ > > Regards, > Shafi From shafi.s.ahmad at oracle.com Mon Jun 13 05:11:56 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Sun, 12 Jun 2016 22:11:56 -0700 (PDT) Subject: [8u] RFA for JDK-8044575: [TEST_BUG]testlibrary_tests/whitebox/vm_flags/UintxTest.java failed: assert(!res || TypeEntriesAtCall::arguments_profiling_enabled()) failed: no profiling of arguments Message-ID: Hi, Please approve this clean backport [https://bugs.openjdk.java.net/browse/JDK-8157046] to 8u-dev. Jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8044575 Review link: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-June/014709.html Jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/0960c95f2343 Regards, Shafi From shilpi.rastogi at oracle.com Mon Jun 13 05:39:34 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Mon, 13 Jun 2016 11:09:34 +0530 Subject: [8u-dev] Request for approval:8147585: Annotations with lambda expressions has parameter result in wrong behavior. In-Reply-To: References: <57595A9D.1020203@oracle.com> Message-ID: <575E4716.2090307@oracle.com> Thanks Sean!! I checked with our team, CCC is not required. The fix backported to jdk8udev. Regards, Shilpi On 6/9/2016 6:01 PM, Se?n Coffey wrote: > Approved for jdk8u-dev. Note that the testcase seems to pass on an > unpatched JDK for me. > > I not sure if a CCC is required given that you're interpreting JLS but > I'll leave that to you and your team to decide. > > Regards, > Sean. > > On 09/06/2016 13:01, shilpi.rastogi at oracle.com wrote: >> Hi All, >> >> Please approve fix for >> issue: https://bugs.openjdk.java.net/browse/JDK-8147585 >> JDK 9 review thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041624.html >> >> Only path has been changed. ( no code change) >> JDK 9 changeset link: >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3f4cce596ada >> >> >> Thanks, >> Shilpi >> >> >> > From david.buck at oracle.com Mon Jun 13 06:37:32 2016 From: david.buck at oracle.com (David Buck) Date: Mon, 13 Jun 2016 15:37:32 +0900 Subject: [8u] RFA for JDK-8044575: [TEST_BUG]testlibrary_tests/whitebox/vm_flags/UintxTest.java failed: assert(!res || TypeEntriesAtCall::arguments_profiling_enabled()) failed: no profiling of arguments In-Reply-To: References: Message-ID: <59A0195F-B004-4203-806A-C99B6F2D300C@oracle.com> approved for backport to 8u-dev Cheers, -Buck > On Jun 13, 2016, at 14:11, Shafi Ahmad wrote: > > Hi, > > Please approve this clean backport [https://bugs.openjdk.java.net/browse/JDK-8157046] to 8u-dev. > > Jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8044575 > Review link: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-June/014709.html > Jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/0960c95f2343 > > Regards, > Shafi From tobias.hartmann at oracle.com Mon Jun 13 09:26:40 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 13 Jun 2016 11:26:40 +0200 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape Message-ID: <575E7C50.7060900@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8159244 http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. Thanks, Tobias [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm From vladimir.kozlov at oracle.com Mon Jun 13 17:09:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Jun 2016 10:09:50 -0700 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <575E7C50.7060900@oracle.com> References: <575E7C50.7060900@oracle.com> Message-ID: Nice work, Tobias. Use next tag: @requires vm.gc == "Parallel" | vm.gc == "null" It will run the test when UseParallelGC is specified or no GC is specified by test environment. Otherwise you may get problem if CMS or other (not G1) is specified. We should generate similar barriers code we generate at the end of constructors. See Parse::do_exits() what is applicable for String constructor in your case. Thanks, Vladimir On 6/13/16 2:26 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8159244 > http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ > http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ > > C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). > Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. > > The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). > > TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png > [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png > [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png > [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log > [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log > [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log > [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm > [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm > From tobias.hartmann at oracle.com Tue Jun 14 10:08:12 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 14 Jun 2016 12:08:12 +0200 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: References: <575E7C50.7060900@oracle.com> Message-ID: <575FD78C.8080802@oracle.com> Hi Vladimir, thanks for the review! On 13.06.2016 19:09, Vladimir Kozlov wrote: > Nice work, Tobias. > > Use next tag: > > @requires vm.gc == "Parallel" | vm.gc == "null" > > It will run the test when UseParallelGC is specified or no GC is specified by test environment. Otherwise you may get problem if CMS or other (not G1) is specified. Right, I added the precondition to the test. > We should generate similar barriers code we generate at the end of constructors. See Parse::do_exits() what is applicable for String constructor in your case. In Parse::do_exits() we emit a MemBarRelease if the constructor writes to a final field to ensure that the effect of the initialization is committed to memory before any code publishes a reference to the newly constructed object. I agree that we should do the same after constructing/initializing a new String object because the String.value field is final. >From my understanding, a MemBarRelease is basically a combination of a LoadStoreBarrier and a StoreStoreBarrier. See sparc.ad: __ membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); So I wondered why a StoreStoreBarrier is not sufficient in this case. For the record, I found this nice description of a case where a StoreStore is not sufficient: http://www.hboehm.info/c++mm/no_write_fences.html New webrevs: http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.01 http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01 Thanks, Tobias > Thanks, > Vladimir > > On 6/13/16 2:26 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8159244 >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ >> >> C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). >> Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. >> >> The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). >> >> TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png >> [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png >> [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png >> [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log >> [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log >> [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log >> [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm >> [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm >> From aph at redhat.com Tue Jun 14 10:41:17 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Jun 2016 11:41:17 +0100 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <575FD78C.8080802@oracle.com> References: <575E7C50.7060900@oracle.com> <575FD78C.8080802@oracle.com> Message-ID: <575FDF4D.7080807@redhat.com> On 14/06/16 11:08, Tobias Hartmann wrote: > So I wondered why a StoreStoreBarrier is not sufficient in this case. It probably is, but I'm not certain that we can rely on it, and it's not much of an efficiency gain for the risk. We already know that there are no write-only objects in HotSpot because of locking. Andrew. From vladimir.kozlov at oracle.com Tue Jun 14 16:16:01 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jun 2016 09:16:01 -0700 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <575FD78C.8080802@oracle.com> References: <575E7C50.7060900@oracle.com> <575FD78C.8080802@oracle.com> Message-ID: Looks good to me. Thanks, Vladimir On 6/14/16 3:08 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 13.06.2016 19:09, Vladimir Kozlov wrote: >> Nice work, Tobias. >> >> Use next tag: >> >> @requires vm.gc == "Parallel" | vm.gc == "null" >> >> It will run the test when UseParallelGC is specified or no GC is specified by test environment. Otherwise you may get problem if CMS or other (not G1) is specified. > > Right, I added the precondition to the test. > >> We should generate similar barriers code we generate at the end of constructors. See Parse::do_exits() what is applicable for String constructor in your case. > > In Parse::do_exits() we emit a MemBarRelease if the constructor writes to a final field to ensure that the effect of the initialization is committed to memory before any code publishes a reference to the newly constructed object. I agree that we should do the same after constructing/initializing a new String object because the String.value field is final. > > From my understanding, a MemBarRelease is basically a combination of a LoadStoreBarrier and a StoreStoreBarrier. See sparc.ad: > > __ membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); > > So I wondered why a StoreStoreBarrier is not sufficient in this case. For the record, I found this nice description of a case where a StoreStore is not sufficient: http://www.hboehm.info/c++mm/no_write_fences.html > > New webrevs: > http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.01 > http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01 > > Thanks, > Tobias > >> Thanks, >> Vladimir >> >> On 6/13/16 2:26 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159244 >>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ >>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ >>> >>> C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). >>> Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. >>> >>> The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). >>> >>> TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png >>> [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png >>> [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png >>> [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log >>> [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log >>> [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log >>> [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm >>> [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm >>> From tobias.hartmann at oracle.com Tue Jun 14 16:22:20 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 14 Jun 2016 18:22:20 +0200 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: References: <575E7C50.7060900@oracle.com> <575FD78C.8080802@oracle.com> Message-ID: <57602F3C.20601@oracle.com> Thanks, Vladimir! Best regards, Tobias On 14.06.2016 18:16, Vladimir Kozlov wrote: > Looks good to me. > > Thanks, > Vladimir > > On 6/14/16 3:08 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 13.06.2016 19:09, Vladimir Kozlov wrote: >>> Nice work, Tobias. >>> >>> Use next tag: >>> >>> @requires vm.gc == "Parallel" | vm.gc == "null" >>> >>> It will run the test when UseParallelGC is specified or no GC is specified by test environment. Otherwise you may get problem if CMS or other (not G1) is specified. >> >> Right, I added the precondition to the test. >> >>> We should generate similar barriers code we generate at the end of constructors. See Parse::do_exits() what is applicable for String constructor in your case. >> >> In Parse::do_exits() we emit a MemBarRelease if the constructor writes to a final field to ensure that the effect of the initialization is committed to memory before any code publishes a reference to the newly constructed object. I agree that we should do the same after constructing/initializing a new String object because the String.value field is final. >> >> From my understanding, a MemBarRelease is basically a combination of a LoadStoreBarrier and a StoreStoreBarrier. See sparc.ad: >> >> __ membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); >> >> So I wondered why a StoreStoreBarrier is not sufficient in this case. For the record, I found this nice description of a case where a StoreStore is not sufficient: http://www.hboehm.info/c++mm/no_write_fences.html >> >> New webrevs: >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.01 >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01 >> >> Thanks, >> Tobias >> >>> Thanks, >>> Vladimir >>> >>> On 6/13/16 2:26 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8159244 >>>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ >>>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ >>>> >>>> C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). >>>> Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. >>>> >>>> The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). >>>> >>>> TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png >>>> [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png >>>> [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png >>>> [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log >>>> [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log >>>> [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log >>>> [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm >>>> [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm >>>> From artem.kosarev at oracle.com Wed Jun 15 11:56:42 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Wed, 15 Jun 2016 14:56:42 +0300 Subject: [8u-dev] Request for approval for 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics and 8049312: AES/CICO test failed with on several modes Message-ID: <4fb1178e-c745-892a-0f21-7a32f0600dc5@oracle.com> Hello, Please approve almost direct backports of bug fix + regression fix (caused by first bug fix) to 8u-dev. Bug fixes were originally reviewed by Xuelei Fan and Anthony Scarpino. "b113 causing a lot of memory allocation and regression for wls_webapp_atomics" https://bugs.openjdk.java.net/browse/JDK-8027575 Review thread: http://mail.openjdk.java.net/pipermail/security-dev/2014-June/010704.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c2e818a8d678 The only changes from original fix is that Copyright year change in one file *src/share/classes/com/sun/crypto/provider/CipherCore.java* couldn't be applied by mercurial automatically. Needed to do it manually. *WebRev: ** ***http://cr.openjdk.java.net/~akosarev/8027575/webrev.00 Plus: "AES/CICO test failed with on several modes" https://bugs.openjdk.java.net/browse/JDK-8049312 Review thread: http://mail.openjdk.java.net/pipermail/security-dev/2014-December/011519.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/09bcd51adf34 The only changes from original fix are the following: 1) I had to remove *java.base* from the pathes of files inside original patch from JDK 9. After that mercurial could apply the patch. 2) We don't require to remove test from *ProblemList.txt* file. Test hasn't been added to the ProblemList in JDK 8 yet. *WebRev: ** *http://cr.openjdk.java.net/~akosarev/8049312/webrev.00 Fixes were checked with JPRT. Thank you, Artem Kosarev. From artem.kosarev at oracle.com Wed Jun 15 11:57:35 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Wed, 15 Jun 2016 14:57:35 +0300 Subject: [8u-dev] Request for approval for 8048601: Tests for JCE crypto ciphers (part 1) Message-ID: <8e6e9285-b099-eec1-9562-2fd21b7b5558@oracle.com> Hello, Please approve direct backport of regression tests to 8u-dev. Tests were originally reviewed by Valerie Peng. "Tests for JCE crypto ciphers (part 1)" https://bugs.openjdk.java.net/browse/JDK-8048601 Review thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012727.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b2d0cf231c7 Tests were checked with JPRT. Thanks in advance. Best regards, Artem Kosarev. From rob.mckenna at oracle.com Wed Jun 15 15:41:41 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 15 Jun 2016 16:41:41 +0100 Subject: [8u-dev] Request for approval for 8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics and 8049312: AES/CICO test failed with on several modes In-Reply-To: <4fb1178e-c745-892a-0f21-7a32f0600dc5@oracle.com> References: <4fb1178e-c745-892a-0f21-7a32f0600dc5@oracle.com> Message-ID: <20160615154141.GA31291@vimes> Approved. Please add appropriate noreg labels to each bug. -Rob On 15/06/16 02:56, Artem Kosarev wrote: > Hello, > > Please approve almost direct backports of bug fix + regression fix (caused > by first bug fix) to 8u-dev. > > Bug fixes were originally reviewed by Xuelei Fan and Anthony Scarpino. > > "b113 causing a lot of memory allocation and regression for > wls_webapp_atomics" > https://bugs.openjdk.java.net/browse/JDK-8027575 > Review thread: > http://mail.openjdk.java.net/pipermail/security-dev/2014-June/010704.html > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c2e818a8d678 > > The only changes from original fix is that Copyright year change in one file > *src/share/classes/com/sun/crypto/provider/CipherCore.java* couldn't be > applied by mercurial automatically. Needed to do it manually. > *WebRev: ** > ***http://cr.openjdk.java.net/~akosarev/8027575/webrev.00 > > Plus: > > "AES/CICO test failed with on several modes" > https://bugs.openjdk.java.net/browse/JDK-8049312 > Review thread: > http://mail.openjdk.java.net/pipermail/security-dev/2014-December/011519.html > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/09bcd51adf34 > > The only changes from original fix are the following: > 1) I had to remove *java.base* from the pathes of files inside original > patch from JDK 9. After that mercurial could apply the patch. > 2) We don't require to remove test from *ProblemList.txt* file. Test hasn't > been added to the ProblemList in JDK 8 yet. > *WebRev: ** > *http://cr.openjdk.java.net/~akosarev/8049312/webrev.00 > > Fixes were checked with JPRT. > > Thank you, > Artem Kosarev. From rob.mckenna at oracle.com Wed Jun 15 15:42:12 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 15 Jun 2016 16:42:12 +0100 Subject: [8u-dev] Request for approval for 8048601: Tests for JCE crypto ciphers (part 1) In-Reply-To: <8e6e9285-b099-eec1-9562-2fd21b7b5558@oracle.com> References: <8e6e9285-b099-eec1-9562-2fd21b7b5558@oracle.com> Message-ID: <20160615154212.GB31291@vimes> Approved -Rob On 15/06/16 02:57, Artem Kosarev wrote: > Hello, > > Please approve direct backport of regression tests to 8u-dev. > > Tests were originally reviewed by Valerie Peng. > > "Tests for JCE crypto ciphers (part 1)" > https://bugs.openjdk.java.net/browse/JDK-8048601 > > Review thread: > http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012727.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b2d0cf231c7 > Tests were checked with JPRT. > > Thanks in advance. > > Best regards, > Artem Kosarev. > From tobias.hartmann at oracle.com Fri Jun 17 09:47:42 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Jun 2016 11:47:42 +0200 Subject: [8u] Request for approval: Backport of 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <575E7C50.7060900@oracle.com> References: <575E7C50.7060900@oracle.com> Message-ID: <5763C73E.9030207@oracle.com> Hi, please approve the following backport to 8u. 8159244: Partially initialized string object created by C2's string concat optimization may escape https://bugs.openjdk.java.net/browse/JDK-8159244 The JDK 9 and 8u versions were reviewed: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023333.html The JDK 9 fix was pushed to hs-comp and nightly testing showed no problems: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 Thanks, Tobias On 13.06.2016 11:26, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8159244 > http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ > http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ > > C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). > Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. > > The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). > > TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png > [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png > [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png > [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log > [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log > [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log > [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm > [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm > From tobias.hartmann at oracle.com Fri Jun 17 09:52:07 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Jun 2016 11:52:07 +0200 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <575FDF4D.7080807@redhat.com> References: <575E7C50.7060900@oracle.com> <575FD78C.8080802@oracle.com> <575FDF4D.7080807@redhat.com> Message-ID: <5763C847.2060004@oracle.com> Hi Andrew, sorry, I missed your message because you omitted hotspot-compiler-dev. Thanks for the clarification, I agree that it's not worth the risk. Best regards, Tobias On 14.06.2016 12:41, Andrew Haley wrote: > On 14/06/16 11:08, Tobias Hartmann wrote: >> So I wondered why a StoreStoreBarrier is not sufficient in this case. > > It probably is, but I'm not certain that we can rely on it, and > it's not much of an efficiency gain for the risk. We already know > that there are no write-only objects in HotSpot because of locking. > > Andrew. > From rob.mckenna at oracle.com Fri Jun 17 13:30:58 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 17 Jun 2016 14:30:58 +0100 Subject: [8u] Request for approval: Backport of 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <5763C73E.9030207@oracle.com> References: <575E7C50.7060900@oracle.com> <5763C73E.9030207@oracle.com> Message-ID: <20160617133058.GA3171@vimes> Approved -Rob On 17/06/16 11:47, Tobias Hartmann wrote: > Hi, > > please approve the following backport to 8u. > > 8159244: Partially initialized string object created by C2's string concat optimization may escape > https://bugs.openjdk.java.net/browse/JDK-8159244 > > The JDK 9 and 8u versions were reviewed: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023333.html > > The JDK 9 fix was pushed to hs-comp and nightly testing showed no problems: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 > > Thanks, > Tobias > > On 13.06.2016 11:26, Tobias Hartmann wrote: > > Hi, > > > > please review the following patch: > > > > https://bugs.openjdk.java.net/browse/JDK-8159244 > > http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ > > http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ > > > > C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). > > Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. > > > > The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). > > > > TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. > > > > Thanks, > > Tobias > > > > [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png > > [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png > > [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png > > [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log > > [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log > > [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log > > [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm > > [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm > > From tobias.hartmann at oracle.com Fri Jun 17 14:19:14 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Jun 2016 16:19:14 +0200 Subject: [8u] Request for approval: Backport of 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <20160617133058.GA3171@vimes> References: <575E7C50.7060900@oracle.com> <5763C73E.9030207@oracle.com> <20160617133058.GA3171@vimes> Message-ID: <576406E2.5040005@oracle.com> Thanks, Rob! Best regards, Tobias On 17.06.2016 15:30, Rob McKenna wrote: > Approved > > -Rob > > On 17/06/16 11:47, Tobias Hartmann wrote: >> Hi, >> >> please approve the following backport to 8u. >> >> 8159244: Partially initialized string object created by C2's string concat optimization may escape >> https://bugs.openjdk.java.net/browse/JDK-8159244 >> >> The JDK 9 and 8u versions were reviewed: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023333.html >> >> The JDK 9 fix was pushed to hs-comp and nightly testing showed no problems: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 >> >> Thanks, >> Tobias >> >> On 13.06.2016 11:26, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159244 >>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ >>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ >>> >>> C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). >>> Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. >>> >>> The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). >>> >>> TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png >>> [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png >>> [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png >>> [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log >>> [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log >>> [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log >>> [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm >>> [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm >>> From ivan.gerasimov at oracle.com Fri Jun 17 15:15:08 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 17 Jun 2016 18:15:08 +0300 Subject: [8u-dev] Request for approval to backport: 8158633: BASE64 encoded cert not correctly parsed with UTF-16 Message-ID: <75607b76-b3a8-26ee-7bf2-a06232cdd616@oracle.com> Hello! Would you please approve backporting this fix to jdk8u-dev? The unshuffled fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8158633 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d34833290472 Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014192.html With kind regards, Ivan From rob.mckenna at oracle.com Fri Jun 17 16:20:55 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 17 Jun 2016 17:20:55 +0100 Subject: [8u-dev] Request for approval to backport: 8158633: BASE64 encoded cert not correctly parsed with UTF-16 In-Reply-To: <75607b76-b3a8-26ee-7bf2-a06232cdd616@oracle.com> References: <75607b76-b3a8-26ee-7bf2-a06232cdd616@oracle.com> Message-ID: <20160617162055.GB3171@vimes> Approved -Rob On 17/06/16 06:15, Ivan Gerasimov wrote: > Hello! > > Would you please approve backporting this fix to jdk8u-dev? > > The unshuffled fix applies cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158633 > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d34833290472 > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014192.html > > With kind regards, > Ivan > From Sergey.Bylokhov at oracle.com Fri Jun 17 18:14:20 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 17 Jun 2016 21:14:20 +0300 Subject: [8u-dev] Request for approval: 8158072, 8158495 Message-ID: Hello, These is a direct back port from jdk 9 to jdk 8u-dev. 8158072: Need a test for JDK-7172749 Bug: https://bugs.openjdk.java.net/browse/JDK-8158072 Webrev can be found at: http://cr.openjdk.java.net/~serb/8158072/webrev.01 jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/20365a3a5763 Review: http://mail.openjdk.java.net/pipermail/2d-dev/2016-May/006921.html Reviewers: Alexey Ushakov, Phil Race 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData Bug: https://bugs.openjdk.java.net/browse/JDK-8158495 Webrev can be found at: http://cr.openjdk.java.net/~avu/JDK-8158495/webrev.01/ jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/e270820669ad Review: http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/006982.html Reviewers: Sergey Bylokhov, Phil Race -- Best regards, Sergey. From rob.mckenna at oracle.com Fri Jun 17 20:20:12 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 17 Jun 2016 21:20:12 +0100 Subject: [8u-dev] Request for approval: 8158072, 8158495 In-Reply-To: References: Message-ID: <20160617202012.GC3171@vimes> Approved -Rob On 17/06/16 09:14, Sergey Bylokhov wrote: > Hello, > These is a direct back port from jdk 9 to jdk 8u-dev. > > 8158072: Need a test for JDK-7172749 > Bug: https://bugs.openjdk.java.net/browse/JDK-8158072 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8158072/webrev.01 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/20365a3a5763 > Review: http://mail.openjdk.java.net/pipermail/2d-dev/2016-May/006921.html > Reviewers: Alexey Ushakov, Phil Race > > 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to > sun.java2d.opengl.OGLSurfaceData > Bug: https://bugs.openjdk.java.net/browse/JDK-8158495 > Webrev can be found at: > http://cr.openjdk.java.net/~avu/JDK-8158495/webrev.01/ > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/e270820669ad > Review: http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/006982.html > Reviewers: Sergey Bylokhov, Phil Race > > > -- > Best regards, Sergey. From shafi.s.ahmad at oracle.com Mon Jun 20 09:05:28 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 20 Jun 2016 02:05:28 -0700 (PDT) Subject: [8u] RFA for JDK-8147026: Convert an assert in ClassLoaderData to a guarantee Message-ID: Hi, Please approve this clean backport [https://bugs.openjdk.java.net/browse/JDK-8147026] to 8u-dev. Jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8147026 Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018010.html Jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8341dddb5188 Regards, Shafi From shafi.s.ahmad at oracle.com Mon Jun 20 10:00:40 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 20 Jun 2016 03:00:40 -0700 (PDT) Subject: [8u] RFA for JDK-8147026: Convert an assert in ClassLoaderData to a guarantee In-Reply-To: References: Message-ID: Hi All, Sorry I missed to list down all the review links. Review links are: 1. http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019199.html 2. http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018010.html Regards, Shafi > -----Original Message----- > From: Shafi Ahmad > Sent: Monday, June 20, 2016 2:35 PM > To: jdk8u-dev at openjdk.java.net > Subject: [8u] RFA for JDK-8147026: Convert an assert in ClassLoaderData to a > guarantee > > Hi, > > Please approve this clean backport > [https://bugs.openjdk.java.net/browse/JDK-8147026] to 8u-dev. > > Jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8147026 > Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime- > dev/2016-February/018010.html > Jdk9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8341dddb5188 > > Regards, > Shafi From david.buck at oracle.com Mon Jun 20 10:12:00 2016 From: david.buck at oracle.com (David Buck) Date: Mon, 20 Jun 2016 19:12:00 +0900 Subject: [8u] RFA for JDK-8147026: Convert an assert in ClassLoaderData to a guarantee In-Reply-To: References: Message-ID: <9EFC01D2-635A-4253-A8BB-F4BB29553FB8@oracle.com> approved for backport to 8u-dev Cheers, -Buck > On Jun 20, 2016, at 18:05, Shafi Ahmad wrote: > > Hi, > > Please approve this clean backport [https://bugs.openjdk.java.net/browse/JDK-8147026] to 8u-dev. > > Jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8147026 > Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018010.html > Jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8341dddb5188 > > Regards, > Shafi From shafi.s.ahmad at oracle.com Mon Jun 20 10:07:27 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 20 Jun 2016 03:07:27 -0700 (PDT) Subject: [8u] RFA for JDK-8147026: Convert an assert in ClassLoaderData to a guarantee In-Reply-To: <9EFC01D2-635A-4253-A8BB-F4BB29553FB8@oracle.com> References: <9EFC01D2-635A-4253-A8BB-F4BB29553FB8@oracle.com> Message-ID: Thanks David. Regards, Shafi > -----Original Message----- > From: David Buck > Sent: Monday, June 20, 2016 3:42 PM > To: Shafi Ahmad > Cc: jdk8u-dev at openjdk.java.net > Subject: Re: [8u] RFA for JDK-8147026: Convert an assert in ClassLoaderData > to a guarantee > > approved for backport to 8u-dev > > Cheers, > -Buck > > > On Jun 20, 2016, at 18:05, Shafi Ahmad > wrote: > > > > Hi, > > > > Please approve this clean backport > [https://bugs.openjdk.java.net/browse/JDK-8147026] to 8u-dev. > > > > Jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8147026 > > Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime- > dev/2016-February/018010.html > > Jdk9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8341dddb5188 > > > > Regards, > > Shafi > From shafi.s.ahmad at oracle.com Tue Jun 21 06:13:38 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 20 Jun 2016 23:13:38 -0700 (PDT) Subject: [8u] RFA for JDK-8158373: SIGSEGV: Metadata::mark_on_stack Message-ID: <6427b556-706f-4b10-9bc8-b03c9f2cecea@default> Hi, Please approve the code change for bug ''JDK-8158373: SIGSEGV: Metadata::mark_on_stack" to jdk8u-dev Jdk8 Bug: https://bugs.openjdk.java.net/browse/JDK-8158373 Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/020104.html Webrev link: http://cr.openjdk.java.net/~shshahma/8158373/webrev.00/ Regards, Shafi From david.buck at oracle.com Tue Jun 21 11:19:10 2016 From: david.buck at oracle.com (david buck) Date: Tue, 21 Jun 2016 20:19:10 +0900 Subject: [8u] RFA for JDK-8158373: SIGSEGV: Metadata::mark_on_stack In-Reply-To: <6427b556-706f-4b10-9bc8-b03c9f2cecea@default> References: <6427b556-706f-4b10-9bc8-b03c9f2cecea@default> Message-ID: <95eaf839-ea81-deee-016c-a2774b48f8ae@oracle.com> approved for push to 8u-dev Cheers, -Buck On 2016/06/21 15:13, Shafi Ahmad wrote: > Hi, > > Please approve the code change for bug ''JDK-8158373: SIGSEGV: Metadata::mark_on_stack" to jdk8u-dev > > Jdk8 Bug: https://bugs.openjdk.java.net/browse/JDK-8158373 > Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/020104.html > Webrev link: http://cr.openjdk.java.net/~shshahma/8158373/webrev.00/ > > Regards, > Shafi > From mark.sheppard at oracle.com Tue Jun 21 14:36:49 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 21 Jun 2016 15:36:49 +0100 Subject: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields Message-ID: <049f9220-4e6c-a2a6-39f5-8bfad8e5357e@oracle.com> Hi, please oblige and review the backport changes to jdk8 for the issue: https://bugs.openjdk.java.net/browse/JDK-8146975 webrev: http://cr.openjdk.java.net/~msheppar/8146975/jdk8/webrev/ http://cr.openjdk.java.net/~msheppar/8146975/jdk8/test/webrev/ main differences from 9 are to do with -addmods in tests and some slight differences in the security policy used. jdk9 changes: http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/ http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev.01/ jdk9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041703.html regards Mark From sean.coffey at oracle.com Tue Jun 21 14:50:19 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 21 Jun 2016 15:50:19 +0100 Subject: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields In-Reply-To: <049f9220-4e6c-a2a6-39f5-8bfad8e5357e@oracle.com> References: <049f9220-4e6c-a2a6-39f5-8bfad8e5357e@oracle.com> Message-ID: <977a6421-78ea-dc20-911b-3421b25647f2@oracle.com> Looks good to me Mark. Regards, Sean. On 21/06/2016 15:36, Mark Sheppard wrote: > > Hi, > please oblige and review the backport changes to jdk8 for the > issue: > https://bugs.openjdk.java.net/browse/JDK-8146975 > > webrev: > http://cr.openjdk.java.net/~msheppar/8146975/jdk8/webrev/ > http://cr.openjdk.java.net/~msheppar/8146975/jdk8/test/webrev/ > > main differences from 9 are to do with -addmods in tests > and some slight differences in the security policy used. > > jdk9 changes: > http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/ > http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev.01/ > > jdk9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041703.html > > > regards > Mark From volker.simonis at gmail.com Wed Jun 22 09:35:29 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jun 2016 11:35:29 +0200 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" Message-ID: Hi, could you please approve the backport of the following ppc64-only fixe to jdk8u-dev: 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c The original change has a JTreg test which uses the new jdk.internal.misc.Unsafe class and some of its features like Unsafe.unalignedAccess() which are not available in jdk8 so I propose to exclude the test from the downport. Without the test the change only touches a ppc64 specific file and applies cleanly to jdk8u-dev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u As this backport is now truly "ppc64-only", can I push it directly to jdk8u-dev/hotspot or do I still need a sponsor? Thank you and best regards, Volker From rob.mckenna at oracle.com Wed Jun 22 14:07:54 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 22 Jun 2016 15:07:54 +0100 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: References: Message-ID: <20160622140754.GD3299@vimes> Approved assuming the HS folks are ok with the test situation. I'm not sure I get the sponsor question. If you are an approved committer to jdk8u-dev (which you appear to be) you can push, otherwise you would need a sponsor. -Rob On 22/06/16 11:35, Volker Simonis wrote: > Hi, > > could you please approve the backport of the following ppc64-only fixe > to jdk8u-dev: > > 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of > illegal instructions > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c > > The original change has a JTreg test which uses the new > jdk.internal.misc.Unsafe class and some of its features like > Unsafe.unalignedAccess() which are not available in jdk8 so I propose > to exclude the test from the downport. > > Without the test the change only touches a ppc64 specific file and > applies cleanly to jdk8u-dev: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u > > As this backport is now truly "ppc64-only", can I push it directly to > jdk8u-dev/hotspot or do I still need a sponsor? > > Thank you and best regards, > Volker From hannes.wallnoefer at oracle.com Wed Jun 22 14:23:56 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 22 Jun 2016 16:23:56 +0200 Subject: [8u-dev] Request for Approval: 8150219: ReferenceError in 1.8.0_72 Message-ID: <576A9F7C.9020005@oracle.com> Please approve backport of 8150219 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8150219 Webrev: http://cr.openjdk.java.net/~hannesw/8150219/webrev.01/ Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006313.html Changes apply cleanly to jdk8u-dev after path reshuffling. Thanks, Hannes From volker.simonis at gmail.com Wed Jun 22 14:34:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jun 2016 16:34:23 +0200 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: <20160622140754.GD3299@vimes> References: <20160622140754.GD3299@vimes> Message-ID: On Wed, Jun 22, 2016 at 4:07 PM, Rob McKenna wrote: > Approved assuming the HS folks are ok with the test situation. > Thanks Rob! Yes, let's wait for another HS review. > I'm not sure I get the sponsor question. If you are an approved committer to jdk8u-dev (which you appear to be) you can push, otherwise you would need a sponsor. As all hotspot changes have to go trough JPRT external committers are not allowed to directly push to HS repos - expect for changes which only touch platforms which aren't built and tested by Oracle anyway (e.g. ppc64 and aarch64). My initial change contained a shared test so I needed a sponsor whereas the downport only touches a ppc64 file. Regards, Volker > > -Rob > > On 22/06/16 11:35, Volker Simonis wrote: >> Hi, >> >> could you please approve the backport of the following ppc64-only fixe >> to jdk8u-dev: >> >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of >> illegal instructions >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c >> >> The original change has a JTreg test which uses the new >> jdk.internal.misc.Unsafe class and some of its features like >> Unsafe.unalignedAccess() which are not available in jdk8 so I propose >> to exclude the test from the downport. >> >> Without the test the change only touches a ppc64 specific file and >> applies cleanly to jdk8u-dev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u >> >> As this backport is now truly "ppc64-only", can I push it directly to >> jdk8u-dev/hotspot or do I still need a sponsor? >> >> Thank you and best regards, >> Volker From alexander.vorobyev at oracle.com Wed Jun 22 15:29:58 2016 From: alexander.vorobyev at oracle.com (Alexander Vorobyev) Date: Wed, 22 Jun 2016 18:29:58 +0300 Subject: [8u-dev] Request for approval: backport of JDK-8058865: TempDirTest.java still times out with -Xcomp In-Reply-To: <542E8041.1010101@oracle.com> References: <542E8041.1010101@oracle.com> Message-ID: <9b21a330-36b6-4899-86c3-4a1ec02c9eb8@oracle.com> Hi All, I'd like approval for a JDK 8 backport of JDK-8058865 (https://bugs.openjdk.java.net/browse/JDK-8159982 - it is a separated issue, because JDK-8058865 is a JEP task and can't be backported directly) The JDK 9 changeset applies clearly. Only change is using java.beans.ConstructorProperties class instead of javax.management.ConstructorParameters (because it does not exist in JDK 8) So here is webrev: http://cr.openjdk.java.net/~avorobye/8159982/ The changeset (except using of java.beans.ConstructorProperties in Simple.java mentioned above) is absolutely the same as in original JDK 9 fix. JDK 9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec08bf9b7cb2 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018484.html Thanks, Alexander From alexander.vorobyev at oracle.com Wed Jun 22 15:32:36 2016 From: alexander.vorobyev at oracle.com (Alexander Vorobyev) Date: Wed, 22 Jun 2016 18:32:36 +0300 Subject: [8u-dev] Request for approval: backport of JDK-8058865: TempDirTest.java still times out with -Xcomp In-Reply-To: <9b21a330-36b6-4899-86c3-4a1ec02c9eb8@oracle.com> References: <542E8041.1010101@oracle.com> <9b21a330-36b6-4899-86c3-4a1ec02c9eb8@oracle.com> Message-ID: <3f069815-a0df-cc74-8061-85b82064a787@oracle.com> Sorry, this review has incorrect title by mistake. Please don't review it. On 22.06.2016 18:29, Alexander Vorobyev wrote: > Hi All, > > I'd like approval for a JDK 8 backport of JDK-8058865 > (https://bugs.openjdk.java.net/browse/JDK-8159982 - it is a separated > issue, because JDK-8058865 is a JEP task and can't be backported > directly) > > The JDK 9 changeset applies clearly. Only change is using > java.beans.ConstructorProperties class instead of > javax.management.ConstructorParameters (because it does not exist in > JDK 8) > > So here is webrev: > http://cr.openjdk.java.net/~avorobye/8159982/ > > The changeset (except using of java.beans.ConstructorProperties in > Simple.java mentioned above) is absolutely the same as in original JDK > 9 fix. > > JDK 9 Changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec08bf9b7cb2 > JDK 9 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018484.html > > > Thanks, > Alexander > > > From alexander.vorobyev at oracle.com Wed Jun 22 15:33:58 2016 From: alexander.vorobyev at oracle.com (Alexander Vorobyev) Date: Wed, 22 Jun 2016 18:33:58 +0300 Subject: [8u-dev] Request for approval: backport of JDK-8058865: JMX Test Refactoring In-Reply-To: <542E8041.1010101@oracle.com> References: <542E8041.1010101@oracle.com> Message-ID: <1041309d-cd5e-b4cc-d038-362e3f8db802@oracle.com> Hi All, I'd like approval for a JDK 8 backport of JDK-8058865 (https://bugs.openjdk.java.net/browse/JDK-8159982 - it is a separated issue, because JDK-8058865 is a JEP task and can't be backported directly) The JDK 9 changeset applies clearly. Only change is using java.beans.ConstructorProperties class instead of javax.management.ConstructorParameters (because it does not exist in JDK 8) So here is webrev: http://cr.openjdk.java.net/~avorobye/8159982/ The changeset (except using of java.beans.ConstructorProperties in Simple.java mentioned above) is absolutely the same as in original JDK 9 fix. JDK 9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec08bf9b7cb2 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018484.html Thanks, Alexander From rob.mckenna at oracle.com Wed Jun 22 15:42:19 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 22 Jun 2016 16:42:19 +0100 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: References: <20160622140754.GD3299@vimes> Message-ID: <20160622154219.GH3299@vimes> On 22/06/16 04:34, Volker Simonis wrote: > On Wed, Jun 22, 2016 at 4:07 PM, Rob McKenna wrote: > > Approved assuming the HS folks are ok with the test situation. > > > > Thanks Rob! > Yes, let's wait for another HS review. > > > I'm not sure I get the sponsor question. If you are an approved committer to jdk8u-dev (which you appear to be) you can push, otherwise you would need a sponsor. > > As all hotspot changes have to go trough JPRT external committers are JDK9 only :) -Rob > not allowed to directly push to HS repos - expect for changes which > only touch platforms which aren't built and tested by Oracle anyway > (e.g. ppc64 and aarch64). My initial change contained a shared test so > I needed a sponsor whereas the downport only touches a ppc64 file. > > Regards, > Volker > > > > > -Rob > > > > On 22/06/16 11:35, Volker Simonis wrote: > >> Hi, > >> > >> could you please approve the backport of the following ppc64-only fixe > >> to jdk8u-dev: > >> > >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of > >> illegal instructions > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 > >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ > >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html > >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c > >> > >> The original change has a JTreg test which uses the new > >> jdk.internal.misc.Unsafe class and some of its features like > >> Unsafe.unalignedAccess() which are not available in jdk8 so I propose > >> to exclude the test from the downport. > >> > >> Without the test the change only touches a ppc64 specific file and > >> applies cleanly to jdk8u-dev: > >> > >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u > >> > >> As this backport is now truly "ppc64-only", can I push it directly to > >> jdk8u-dev/hotspot or do I still need a sponsor? > >> > >> Thank you and best regards, > >> Volker From rob.mckenna at oracle.com Wed Jun 22 15:43:58 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 22 Jun 2016 16:43:58 +0100 Subject: [8u-dev] Request for Approval: 8150219: ReferenceError in 1.8.0_72 In-Reply-To: <576A9F7C.9020005@oracle.com> References: <576A9F7C.9020005@oracle.com> Message-ID: <20160622154358.GI3299@vimes> Approved -Rob On 22/06/16 04:23, Hannes Wallnoefer wrote: > Please approve backport of 8150219 to 8u-dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150219 > Webrev: http://cr.openjdk.java.net/~hannesw/8150219/webrev.01/ > Review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006313.html > > Changes apply cleanly to jdk8u-dev after path reshuffling. > > Thanks, > Hannes From mark.sheppard at oracle.com Wed Jun 22 15:54:30 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 22 Jun 2016 16:54:30 +0100 Subject: [8u-dev] Request for Approval: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields In-Reply-To: <977a6421-78ea-dc20-911b-3421b25647f2@oracle.com> References: <049f9220-4e6c-a2a6-39f5-8bfad8e5357e@oracle.com> <977a6421-78ea-dc20-911b-3421b25647f2@oracle.com> Message-ID: <7b9181b4-429e-5ea6-7a37-6f303af8d8b1@oracle.com> Hi, please oblige and approve the backport to jdk8-dev the fix for https://bugs.openjdk.java.net/browse/JDK-8146975 webrev: http://cr.openjdk.java.net/~msheppar/8146975/jdk8/webrev/ http://cr.openjdk.java.net/~msheppar/8146975/jdk8/test/webrev/ as reviewed below. regards Mark On 21/06/2016 15:50, Se?n Coffey wrote: > Looks good to me Mark. > > Regards, > Sean. > > On 21/06/2016 15:36, Mark Sheppard wrote: >> >> Hi, >> please oblige and review the backport changes to jdk8 for the >> issue: >> https://bugs.openjdk.java.net/browse/JDK-8146975 >> >> webrev: >> http://cr.openjdk.java.net/~msheppar/8146975/jdk8/webrev/ >> http://cr.openjdk.java.net/~msheppar/8146975/jdk8/test/webrev/ >> >> main differences from 9 are to do with -addmods in tests >> and some slight differences in the security policy used. >> >> jdk9 changes: >> http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/ >> http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev.01/ >> >> jdk9 review: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041703.html >> >> >> regards >> Mark > From volker.simonis at gmail.com Wed Jun 22 16:21:36 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jun 2016 18:21:36 +0200 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: <20160622154219.GH3299@vimes> References: <20160622140754.GD3299@vimes> <20160622154219.GH3299@vimes> Message-ID: On Wed, Jun 22, 2016 at 5:42 PM, Rob McKenna wrote: > On 22/06/16 04:34, Volker Simonis wrote: >> On Wed, Jun 22, 2016 at 4:07 PM, Rob McKenna wrote: >> > Approved assuming the HS folks are ok with the test situation. >> > >> >> Thanks Rob! >> Yes, let's wait for another HS review. >> >> > I'm not sure I get the sponsor question. If you are an approved committer to jdk8u-dev (which you appear to be) you can push, otherwise you would need a sponsor. >> >> As all hotspot changes have to go trough JPRT external committers are > > JDK9 only :) > Thanks! Good to know :) > -Rob > >> not allowed to directly push to HS repos - expect for changes which >> only touch platforms which aren't built and tested by Oracle anyway >> (e.g. ppc64 and aarch64). My initial change contained a shared test so >> I needed a sponsor whereas the downport only touches a ppc64 file. >> >> Regards, >> Volker >> >> > >> > -Rob >> > >> > On 22/06/16 11:35, Volker Simonis wrote: >> >> Hi, >> >> >> >> could you please approve the backport of the following ppc64-only fixe >> >> to jdk8u-dev: >> >> >> >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of >> >> illegal instructions >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 >> >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >> >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html >> >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c >> >> >> >> The original change has a JTreg test which uses the new >> >> jdk.internal.misc.Unsafe class and some of its features like >> >> Unsafe.unalignedAccess() which are not available in jdk8 so I propose >> >> to exclude the test from the downport. >> >> >> >> Without the test the change only touches a ppc64 specific file and >> >> applies cleanly to jdk8u-dev: >> >> >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u >> >> >> >> As this backport is now truly "ppc64-only", can I push it directly to >> >> jdk8u-dev/hotspot or do I still need a sponsor? >> >> >> >> Thank you and best regards, >> >> Volker From rob.mckenna at oracle.com Wed Jun 22 16:40:46 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 22 Jun 2016 17:40:46 +0100 Subject: [8u-dev] Request for approval: backport of JDK-8058865: JMX Test Refactoring In-Reply-To: <1041309d-cd5e-b4cc-d038-362e3f8db802@oracle.com> References: <542E8041.1010101@oracle.com> <1041309d-cd5e-b4cc-d038-362e3f8db802@oracle.com> Message-ID: <20160622164046.GJ3299@vimes> Approved -Rob On 22/06/16 06:33, Alexander Vorobyev wrote: > Hi All, > > I'd like approval for a JDK 8 backport of JDK-8058865 > (https://bugs.openjdk.java.net/browse/JDK-8159982 - it is a separated issue, > because JDK-8058865 is a JEP task and can't be backported directly) > > The JDK 9 changeset applies clearly. Only change is using > java.beans.ConstructorProperties class instead of > javax.management.ConstructorParameters (because it does not exist in JDK 8) > > So here is webrev: > http://cr.openjdk.java.net/~avorobye/8159982/ > > The changeset (except using of java.beans.ConstructorProperties in > Simple.java mentioned above) is absolutely the same as in original JDK 9 > fix. > > JDK 9 Changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec08bf9b7cb2 > JDK 9 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018484.html > > Thanks, > Alexander > > > From rob.mckenna at oracle.com Wed Jun 22 16:41:36 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 22 Jun 2016 17:41:36 +0100 Subject: [8u-dev] Request for Approval: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields In-Reply-To: <7b9181b4-429e-5ea6-7a37-6f303af8d8b1@oracle.com> References: <049f9220-4e6c-a2a6-39f5-8bfad8e5357e@oracle.com> <977a6421-78ea-dc20-911b-3421b25647f2@oracle.com> <7b9181b4-429e-5ea6-7a37-6f303af8d8b1@oracle.com> Message-ID: <20160622164136.GK3299@vimes> Approved -Rob On 22/06/16 04:54, Mark Sheppard wrote: > > Hi, > please oblige and approve the backport to jdk8-dev the fix for > https://bugs.openjdk.java.net/browse/JDK-8146975 > > webrev: > http://cr.openjdk.java.net/~msheppar/8146975/jdk8/webrev/ > http://cr.openjdk.java.net/~msheppar/8146975/jdk8/test/webrev/ > > as reviewed below. > > regards > Mark > > On 21/06/2016 15:50, Se?n Coffey wrote: > >Looks good to me Mark. > > > >Regards, > >Sean. > > > >On 21/06/2016 15:36, Mark Sheppard wrote: > >> > >>Hi, > >> please oblige and review the backport changes to jdk8 for the > >>issue: > >>https://bugs.openjdk.java.net/browse/JDK-8146975 > >> > >>webrev: > >>http://cr.openjdk.java.net/~msheppar/8146975/jdk8/webrev/ > >>http://cr.openjdk.java.net/~msheppar/8146975/jdk8/test/webrev/ > >> > >>main differences from 9 are to do with -addmods in tests > >>and some slight differences in the security policy used. > >> > >>jdk9 changes: > >>http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/ > >>http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev.01/ > >> > >>jdk9 review: > >>http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041703.html > >> > >> > >>regards > >>Mark > > > From vladimir.kozlov at oracle.com Wed Jun 22 19:08:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2016 12:08:50 -0700 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: References: Message-ID: Changes looks good. I agree with exclusion of test. Since it is only ppc64 changes you can push it yourself. Note, we do run Hotspot changes through JPRT to push into 8u-dev. Thanks, Vladimir On 6/22/16 2:35 AM, Volker Simonis wrote: > Hi, > > could you please approve the backport of the following ppc64-only fixe > to jdk8u-dev: > > 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of > illegal instructions > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c > > The original change has a JTreg test which uses the new > jdk.internal.misc.Unsafe class and some of its features like > Unsafe.unalignedAccess() which are not available in jdk8 so I propose > to exclude the test from the downport. > > Without the test the change only touches a ppc64 specific file and > applies cleanly to jdk8u-dev: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u > > As this backport is now truly "ppc64-only", can I push it directly to > jdk8u-dev/hotspot or do I still need a sponsor? > > Thank you and best regards, > Volker > From tobias.hartmann at oracle.com Thu Jun 23 07:13:54 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Jun 2016 09:13:54 +0200 Subject: [8u] RFR(S): 8160122: Backport of JDK-8159244 uses wrong version of the JDK 9 fix In-Reply-To: <576B8B58.7000500@oracle.com> References: <576B8B58.7000500@oracle.com> Message-ID: <576B8C32.6040408@oracle.com> [CC'ing jdk8u-dev] On 23.06.2016 09:10, Tobias Hartmann wrote: > Hi, > > while backporting 8159244 [1] to JDK 8u, I accidentally used an old version of the webrev: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3e2abbf1320d > This is the correct webrev: > http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01/ > > Please review the following change that fixes this: > https://bugs.openjdk.java.net/browse/JDK-8160122 > http://cr.openjdk.java.net/~thartmann/8160122/webrev.00/ > > Sorry for the mess, I should have merged the JDK 9 changeset. > > Thanks and best regards, > Tobias > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 From volker.simonis at gmail.com Thu Jun 23 08:41:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Jun 2016 10:41:23 +0200 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: References: Message-ID: Thanks Vladimir! Regards, Volker On Wed, Jun 22, 2016 at 9:08 PM, Vladimir Kozlov wrote: > Changes looks good. I agree with exclusion of test. > > Since it is only ppc64 changes you can push it yourself. > > Note, we do run Hotspot changes through JPRT to push into 8u-dev. > > Thanks, > Vladimir > > > On 6/22/16 2:35 AM, Volker Simonis wrote: >> >> Hi, >> >> could you please approve the backport of the following ppc64-only fixe >> to jdk8u-dev: >> >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of >> illegal instructions >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >> Review: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c >> >> The original change has a JTreg test which uses the new >> jdk.internal.misc.Unsafe class and some of its features like >> Unsafe.unalignedAccess() which are not available in jdk8 so I propose >> to exclude the test from the downport. >> >> Without the test the change only touches a ppc64 specific file and >> applies cleanly to jdk8u-dev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u >> >> As this backport is now truly "ppc64-only", can I push it directly to >> jdk8u-dev/hotspot or do I still need a sponsor? >> >> Thank you and best regards, >> Volker >> > From artem.kosarev at oracle.com Thu Jun 23 12:48:36 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Thu, 23 Jun 2016 15:48:36 +0300 Subject: [8u-dev] Request for approval for 8157603: TestCipher.java doesn't check one of the decrypted message as expected Message-ID: Hello, Please approve direct backport of regression tests correction to 8u-dev. Tests were originally reviewed by Valerie Peng. "TestCipher.java doesn't check one of the decrypted message as expected" https://bugs.openjdk.java.net/browse/JDK-8157603 Review thread: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014042.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bf910aef39d4 Changes applied cleanly and were successfully tested with JPRT. Thanks in advance. Artem Kosarev. From rob.mckenna at oracle.com Thu Jun 23 13:55:20 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 23 Jun 2016 14:55:20 +0100 Subject: [8u-dev] Request for approval for 8157603: TestCipher.java doesn't check one of the decrypted message as expected In-Reply-To: References: Message-ID: <20160623135520.GA2636@vimes> Approved -Rob On 23/06/16 03:48, Artem Kosarev wrote: > Hello, > > Please approve direct backport of regression tests correction to 8u-dev. > > Tests were originally reviewed by Valerie Peng. > > "TestCipher.java doesn't check one of the decrypted message as expected" > https://bugs.openjdk.java.net/browse/JDK-8157603 > > Review thread: > http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014042.html > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bf910aef39d4 > Changes applied cleanly and were successfully tested with JPRT. > > Thanks in advance. > Artem Kosarev. > From anton.litvinov at oracle.com Thu Jun 23 14:13:16 2016 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 23 Jun 2016 17:13:16 +0300 Subject: [8u-dev] Request for approval for CR 8057791: Selection in JList is drawn with wrong colors in Nimbus L&F Message-ID: Hello, I would like to request for approval to push a straight backport of the fix from JDK 9 to JDK 8. The patch from JDK 9 applies well to JDK 8 after correction of a file path. Bug: https://bugs.openjdk.java.net/browse/JDK-8057791 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/51244f65475e JDK 9 review thread: Approval 1 - http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006152.html Approval 2 - http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006154.html Reviewers: alexp, serb Thank you, Anton From rob.mckenna at oracle.com Thu Jun 23 15:51:16 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 23 Jun 2016 16:51:16 +0100 Subject: [8u-dev] Request for approval for CR 8057791: Selection in JList is drawn with wrong colors in Nimbus L&F In-Reply-To: References: Message-ID: <20160623155116.GC2636@vimes> Approved -Rob On 23/06/16 05:13, Anton Litvinov wrote: > Hello, > > I would like to request for approval to push a straight backport of the fix > from JDK 9 to JDK 8. The patch from JDK 9 applies well to JDK 8 after > correction of a file path. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8057791 > JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/51244f65475e > JDK 9 review thread: > Approval 1 - > http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006152.html > Approval 2 - > http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006154.html > Reviewers: alexp, serb > > Thank you, > Anton From vladimir.kozlov at oracle.com Thu Jun 23 17:32:32 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 10:32:32 -0700 Subject: [8u] RFR(S): 8160122: Backport of JDK-8159244 uses wrong version of the JDK 9 fix In-Reply-To: <576B8C32.6040408@oracle.com> References: <576B8B58.7000500@oracle.com> <576B8C32.6040408@oracle.com> Message-ID: <38d5c0af-cf9e-5c7a-db92-25c023e47aa1@oracle.com> Changes are good. Reviewed. Thanks, Vladimir On 6/23/16 12:13 AM, Tobias Hartmann wrote: > [CC'ing jdk8u-dev] > > On 23.06.2016 09:10, Tobias Hartmann wrote: >> Hi, >> >> while backporting 8159244 [1] to JDK 8u, I accidentally used an old version of the webrev: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3e2abbf1320d >> This is the correct webrev: >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01/ >> >> Please review the following change that fixes this: >> https://bugs.openjdk.java.net/browse/JDK-8160122 >> http://cr.openjdk.java.net/~thartmann/8160122/webrev.00/ >> >> Sorry for the mess, I should have merged the JDK 9 changeset. >> >> Thanks and best regards, >> Tobias >> >> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 From svetlana.nikandrova at oracle.com Thu Jun 23 18:20:32 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Thu, 23 Jun 2016 21:20:32 +0300 Subject: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered Message-ID: <576C2870.7020601@oracle.com> Hello, could you please review and approve this supportability fix for JDK-8147969 . In jdk 9 this issue has been already addressed as part of the update for JDK-8072452 . JBS: 8147969: Print size of DH keysize when errors are encountered https://bugs.openjdk.java.net/browse/JDK-8147969 Webrev: http://cr.openjdk.java.net/~snikandrova/8147969/webrev.00/ Thank you, Svetlana From tobias.hartmann at oracle.com Fri Jun 24 06:34:25 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Jun 2016 08:34:25 +0200 Subject: [8u] RFR(S): 8160122: Backport of JDK-8159244 uses wrong version of the JDK 9 fix In-Reply-To: <38d5c0af-cf9e-5c7a-db92-25c023e47aa1@oracle.com> References: <576B8B58.7000500@oracle.com> <576B8C32.6040408@oracle.com> <38d5c0af-cf9e-5c7a-db92-25c023e47aa1@oracle.com> Message-ID: <576CD471.6030502@oracle.com> Thanks, Vladimir! Best regards, Tobias On 23.06.2016 19:32, Vladimir Kozlov wrote: > Changes are good. Reviewed. > > Thanks, > Vladimir > > On 6/23/16 12:13 AM, Tobias Hartmann wrote: >> [CC'ing jdk8u-dev] >> >> On 23.06.2016 09:10, Tobias Hartmann wrote: >>> Hi, >>> >>> while backporting 8159244 [1] to JDK 8u, I accidentally used an old version of the webrev: >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3e2abbf1320d >>> This is the correct webrev: >>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01/ >>> >>> Please review the following change that fixes this: >>> https://bugs.openjdk.java.net/browse/JDK-8160122 >>> http://cr.openjdk.java.net/~thartmann/8160122/webrev.00/ >>> >>> Sorry for the mess, I should have merged the JDK 9 changeset. >>> >>> Thanks and best regards, >>> Tobias >>> >>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 From sean.coffey at oracle.com Fri Jun 24 06:59:52 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 24 Jun 2016 07:59:52 +0100 Subject: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered In-Reply-To: <576C2870.7020601@oracle.com> References: <576C2870.7020601@oracle.com> Message-ID: <04d170d0-d0db-ad3c-a861-d362c8ffabbc@oracle.com> src/share/classes/sun/security/ssl/ServerHandshaker.java : ! "Unsupported customized DH key size: " + ! customizedDHKeySize + ". " + ! "The key size must be multiple of 64, " + ! "and can only range from 1024 to 2048 (inclusive)"); You can remove the "multiple of 64" text. That condition was only introduced into JDK 9 from what I read. Looks good otherwise. Don't forget to get new signed jar files generated when integrating. Regards, Sean. On 23/06/2016 19:20, Svetlana Nikandrova wrote: > Hello, > > could you please review and approve this supportability fix for > JDK-8147969 . > In jdk 9 this issue has been already addressed as part of the update > for JDK-8072452 . > > JBS: > 8147969: Print size of DH keysize when errors are encountered > https://bugs.openjdk.java.net/browse/JDK-8147969 > Webrev: > http://cr.openjdk.java.net/~snikandrova/8147969/webrev.00/ > > > Thank you, > Svetlana From svetlana.nikandrova at oracle.com Fri Jun 24 11:48:30 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 24 Jun 2016 14:48:30 +0300 Subject: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered In-Reply-To: <04d170d0-d0db-ad3c-a861-d362c8ffabbc@oracle.com> References: <576C2870.7020601@oracle.com> <04d170d0-d0db-ad3c-a861-d362c8ffabbc@oracle.com> Message-ID: <576D1E0E.9090501@oracle.com> Sean, thank you for spotting this "multiple of 64". Please see updated weberv: http://cr.openjdk.java.net/~snikandrova/8147969/webrev.01/ Thank you for your reminder. Surely, I have signed sunjce_provider.jar and sunpkcs11.jar in my pocket (I believe changes in ServerHandshaker.java should not affect them, so I don't need a new version because of that). Thank you, Svetlana On 24.06.2016 9:59, Se?n Coffey wrote: > > src/share/classes/sun/security/ssl/ServerHandshaker.java : > > ! "Unsupported customized DH key size: " + > ! customizedDHKeySize + ". " + > ! "The key size must be multiple of 64, " + > ! "and can only range from 1024 to 2048 > (inclusive)"); > > You can remove the "multiple of 64" text. That condition was only > introduced into JDK 9 from what I read. > > Looks good otherwise. Don't forget to get new signed jar files > generated when integrating. > > Regards, > Sean. > On 23/06/2016 19:20, Svetlana Nikandrova wrote: >> Hello, >> >> could you please review and approve this supportability fix for >> JDK-8147969 . >> In jdk 9 this issue has been already addressed as part of the update >> for JDK-8072452 . >> >> JBS: >> 8147969: Print size of DH keysize when errors are encountered >> https://bugs.openjdk.java.net/browse/JDK-8147969 >> Webrev: >> http://cr.openjdk.java.net/~snikandrova/8147969/webrev.00/ >> >> >> Thank you, >> Svetlana > From sean.coffey at oracle.com Fri Jun 24 12:06:55 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 24 Jun 2016 13:06:55 +0100 Subject: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered In-Reply-To: <576D1E0E.9090501@oracle.com> References: <576C2870.7020601@oracle.com> <04d170d0-d0db-ad3c-a861-d362c8ffabbc@oracle.com> <576D1E0E.9090501@oracle.com> Message-ID: <576D225F.3020800@oracle.com> Looks good. Approved for jdk8u-dev. Please add a suitable noreg- label to the bug report. Regards, Sean. On 24/06/16 12:48, Svetlana Nikandrova wrote: > Sean, > > thank you for spotting this "multiple of 64". Please see updated weberv: > > http://cr.openjdk.java.net/~snikandrova/8147969/webrev.01/ > > > Thank you for your reminder. Surely, I have signed sunjce_provider.jar > and sunpkcs11.jar in my pocket (I believe changes in > ServerHandshaker.java should not affect them, so I don't need a new > version because of that). > > Thank you, > Svetlana > > On 24.06.2016 9:59, Se?n Coffey wrote: >> >> src/share/classes/sun/security/ssl/ServerHandshaker.java : >> >> ! "Unsupported customized DH key size: " + >> ! customizedDHKeySize + ". " + >> ! "The key size must be multiple of 64, " + >> ! "and can only range from 1024 to 2048 >> (inclusive)"); >> >> You can remove the "multiple of 64" text. That condition was only >> introduced into JDK 9 from what I read. >> >> Looks good otherwise. Don't forget to get new signed jar files >> generated when integrating. >> >> Regards, >> Sean. >> On 23/06/2016 19:20, Svetlana Nikandrova wrote: >>> Hello, >>> >>> could you please review and approve this supportability fix for >>> JDK-8147969 . >>> In jdk 9 this issue has been already addressed as part of the update >>> for JDK-8072452 . >>> >>> JBS: >>> 8147969: Print size of DH keysize when errors are encountered >>> https://bugs.openjdk.java.net/browse/JDK-8147969 >>> Webrev: >>> http://cr.openjdk.java.net/~snikandrova/8147969/webrev.00/ >>> >>> >>> Thank you, >>> Svetlana >> > From hannes.wallnoefer at oracle.com Fri Jun 24 13:25:46 2016 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 24 Jun 2016 15:25:46 +0200 Subject: [8u-dev] Request for Approval: 8137240: Negative lookahead in RegEx breaks backreference Message-ID: <576D34DA.6010408@oracle.com> Please approve backport of 8137240 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8137240 Webrev: http://cr.openjdk.java.net/~hannesw/8137240/webrev/ Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006358.html Changes apply cleanly to jdk8u-dev after path reshuffling. Thanks, Hannes From rob.mckenna at oracle.com Fri Jun 24 15:53:28 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 24 Jun 2016 16:53:28 +0100 Subject: [8u-dev] Request for Approval: 8137240: Negative lookahead in RegEx breaks backreference In-Reply-To: <576D34DA.6010408@oracle.com> References: <576D34DA.6010408@oracle.com> Message-ID: <20160624155328.GA4332@vimes> Approved -Rob On 24/06/16 03:25, Hannes Wallnoefer wrote: > Please approve backport of 8137240 to 8u-dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137240 > Webrev: http://cr.openjdk.java.net/~hannesw/8137240/webrev/ > Review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-June/006358.html > > Changes apply cleanly to jdk8u-dev after path reshuffling. > > Thanks, > Hannes From shafi.s.ahmad at oracle.com Mon Jun 27 08:22:14 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 27 Jun 2016 01:22:14 -0700 (PDT) Subject: [8u] RFA for JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 Message-ID: <248a1463-c319-4ec0-8bb9-cb5e28fb334a@default> Hi, Please approve the code change for bug " JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 " to jdk8u-dev Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8156836 Webrev link: http://cr.openjdk.java.net/~shshahma/8156836/webrev.00/ Review link: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023479.html Regards, Shafi From david.buck at oracle.com Mon Jun 27 08:35:22 2016 From: david.buck at oracle.com (david buck) Date: Mon, 27 Jun 2016 17:35:22 +0900 Subject: [8u] RFA for JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 In-Reply-To: <248a1463-c319-4ec0-8bb9-cb5e28fb334a@default> References: <248a1463-c319-4ec0-8bb9-cb5e28fb334a@default> Message-ID: <5029e508-93d8-ebb7-24a4-517b1ff2381b@oracle.com> approved for push to 8u-dev note: Only one code reviewer approved, but I agree that this is not unreasonable for such a trivial testcase change. Cheers, -Buck On 2016/06/27 17:22, Shafi Ahmad wrote: > Hi, > > Please approve the code change for bug " JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 " to jdk8u-dev > > Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8156836 > Webrev link: http://cr.openjdk.java.net/~shshahma/8156836/webrev.00/ > Review link: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023479.html > > Regards, > Shafi > From dmitry.markov at oracle.com Tue Jun 28 10:34:59 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Tue, 28 Jun 2016 13:34:59 +0300 Subject: [8u-dev] Request for approval 8154816: Caps Lock doesn't work as expected when using Pinyin Simplified input method Message-ID: <577252D3.4060402@oracle.com> Hello, Could you approve the back-port of the fix for 8154816 to jdk8u-dev, please? The jdk9 patch applies cleanly. The bug: https://bugs.openjdk.java.net/browse/JDK-8154816 The webrev: http://cr.openjdk.java.net/~dmarkov/8154816/jdk8u/webrev.00/ The review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011505.html The jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/ee48956a8b54 Thanks, Dmitry From rob.mckenna at oracle.com Tue Jun 28 11:34:59 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 28 Jun 2016 12:34:59 +0100 Subject: [8u-dev] Request for approval 8154816: Caps Lock doesn't work as expected when using Pinyin Simplified input method In-Reply-To: <577252D3.4060402@oracle.com> References: <577252D3.4060402@oracle.com> Message-ID: <20160628113459.GA2951@tecra> Approved -Rob On 28/06/16 01:34, dmitry markov wrote: > Hello, > > Could you approve the back-port of the fix for 8154816 to jdk8u-dev, please? > The jdk9 patch applies cleanly. > > The bug: > https://bugs.openjdk.java.net/browse/JDK-8154816 > The webrev: > http://cr.openjdk.java.net/~dmarkov/8154816/jdk8u/webrev.00/ > The review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011505.html > The jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/ee48956a8b54 > > Thanks, > Dmitry From dmitry.markov at oracle.com Wed Jun 29 09:16:59 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Wed, 29 Jun 2016 12:16:59 +0300 Subject: [8u-dev] Request for approval 8144703: ClassCastException: sun.font.CompositeFont cannot be cast to PhysicalFont Message-ID: <5773920B.5020008@oracle.com> Hello, Could you approve the back-port of the fix for 8144703 to jdk8u-dev, please? The jdk9 patch applies cleanly. The bug: https://bugs.openjdk.java.net/browse/JDK-8144703 The webrev: http://cr.openjdk.java.net/~dmarkov/8144703/jdk8u/webrev.00 The review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007018.html The jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/745d16c6c67d Thanks, Dmitry From rob.mckenna at oracle.com Wed Jun 29 13:09:42 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 29 Jun 2016 14:09:42 +0100 Subject: [8u-dev] Request for approval 8144703: ClassCastException: sun.font.CompositeFont cannot be cast to PhysicalFont In-Reply-To: <5773920B.5020008@oracle.com> References: <5773920B.5020008@oracle.com> Message-ID: <20160629130942.GA3749@vimes> Approved -Rob On 29/06/16 12:16, dmitry markov wrote: > Hello, > > Could you approve the back-port of the fix for 8144703 to jdk8u-dev, please? > The jdk9 patch applies cleanly. > > The bug: > https://bugs.openjdk.java.net/browse/JDK-8144703 > The webrev: > http://cr.openjdk.java.net/~dmarkov/8144703/jdk8u/webrev.00 > The review thread: > http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007018.html > The jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/745d16c6c67d > > Thanks, > Dmitry From vladimir.kempik at oracle.com Thu Jun 30 12:26:20 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 30 Jun 2016 15:26:20 +0300 Subject: [8u-dev] Request for approval: 8158871: Long response times with G1 and StringDeduplication Message-ID: Hello, Please approve this backport of the fix to jdk8u-dev. The patch needed some small changes to work on jdk8 The bug: https://bugs.openjdk.java.net/browse/JDK-8158871 Webrev: http://cr.openjdk.java.net/~vkempik/8158871/webrev.01/ The review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018508.html The jdk9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ba08710f3b6c Thanks, Vladimir From rob.mckenna at oracle.com Thu Jun 30 14:15:44 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 30 Jun 2016 15:15:44 +0100 Subject: [8u-dev] Request for approval: 8158871: Long response times with G1 and StringDeduplication In-Reply-To: References: Message-ID: <20160630141544.GA3842@vimes> Approved -Rob On 30/06/16 03:26, Vladimir Kempik wrote: > Hello, > > Please approve this backport of the fix to jdk8u-dev. > > The patch needed some small changes to work on jdk8 > > The bug: > https://bugs.openjdk.java.net/browse/JDK-8158871 > > Webrev: > http://cr.openjdk.java.net/~vkempik/8158871/webrev.01/ > > The review thread: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018508.html > > The jdk9 changeset: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ba08710f3b6c > > > Thanks, > Vladimir > From stevensro at gmail.com Thu Jun 30 21:27:25 2016 From: stevensro at gmail.com (Robin Stevens) Date: Thu, 30 Jun 2016 23:27:25 +0200 Subject: [8u-dev] Request for Approval: 8158325: Memory leak in com.apple.laf.ScreenMenu: removed JMenuItems are still referenced Message-ID: Please approve backport of 8158325 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8158325 Webrev: http://cr.openjdk.java.net/~alexsch/robin.stevens/8158325/webrev.01 Review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2016-June/006166.html Changes apply cleanly to jdk8u-dev after path reshuffling. Note that I needed to add: jdk/src/java.desktop/macosx/classes/com/apple/laf : jdk/src/macosx/classes/com/apple/laf to common/bin/unshuffle_list.txt before the unshuffle script could shuffle the changes. Thanks, Robin