From anton.litvinov at oracle.com Mon Apr 3 09:36:13 2017 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Mon, 3 Apr 2017 12:36:13 +0300 Subject: [8u-dev] Request for approval for CR 8167102: [macosx] PrintRequestAttributeSet breaks page size set using PageFormat 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 to JDK 8 after correction of file paths. Bug: https://bugs.openjdk.java.net/browse/JDK-8167102 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/e0f119ab7b1c JDK 9 review thread: Approval 1 - http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008262.html Approval 2 - http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008272.html Reviewers: psadhukhan, prr Thank you, Anton From david.buck at oracle.com Mon Apr 3 10:26:22 2017 From: david.buck at oracle.com (David Buck) Date: Mon, 3 Apr 2017 19:26:22 +0900 Subject: [8u-dev] Request for approval for CR 8167102: [macosx] PrintRequestAttributeSet breaks page size set using PageFormat In-Reply-To: References: Message-ID: <9290997f-b736-31e9-79b4-e4de0acfea88@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/04/03 18:36, 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 to JDK 8 after > correction of file paths. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167102 > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/e0f119ab7b1c > JDK 9 review thread: > Approval 1 - > http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008262.html > Approval 2 - > http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008272.html > Reviewers: psadhukhan, prr > > Thank you, > Anton From sean.coffey at oracle.com Mon Apr 3 13:17:01 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 3 Apr 2017 14:17:01 +0100 Subject: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems In-Reply-To: <20170331175009.GC3631@vimes> References: <20170331175009.GC3631@vimes> Message-ID: <83f7cc3c-3bda-dbd9-4d55-00768a3c02dc@oracle.com> Looks good to me. Regards, Sean. On 31/03/17 18:50, Rob McKenna wrote: > Hi Kevin, > > These changes will need codereview. > > -Rob > > On 31/03/17 03:32, Kevin Walls wrote: >> Hi, >> >> This is an approval request to backport into 8u: >> >> 8165482: java in ldoms, with cpu-arch=generic has problems >> 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dfff5edc66df >> >> With a few routine changes this backports OK: >> >> src/cpu/sparc/vm/vm_version_sparc.cpp: has a different initial number of %s >> in a call to jio_snprintf(), so it's not automatic, but the backport adds >> one %s. >> >> src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: in 8u we have an >> #ifndef PRODUCT which isn't in 9, not part of the change, but means the diff >> won't apply automatically. >> >> 9 uses log(), logging in 8u uses tty->print_cr, and needs err_msg() to form >> a message rather than having printf-style formatting built-in. 8u also uses >> #ifndef PRODUCT also, and in some places if (PrintMiscellaneous && Verbose) >> >> Webrev in 8u of these changes: >> http://cr.openjdk.java.net/~kevinw/8165482.8u/webrev.00/ >> >> Thanks >> Kevin >> >> >> >> From kevin.walls at oracle.com Mon Apr 3 13:48:54 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 3 Apr 2017 14:48:54 +0100 Subject: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems In-Reply-To: <83f7cc3c-3bda-dbd9-4d55-00768a3c02dc@oracle.com> References: <20170331175009.GC3631@vimes> <83f7cc3c-3bda-dbd9-4d55-00768a3c02dc@oracle.com> Message-ID: <68ec0b96-f081-673b-d649-e9b53dd3c825@oracle.com> Thanks Rob, Sean - and Poonam who also looked over these changes. Thanks Kevin On 03/04/2017 14:17, Se?n Coffey wrote: > Looks good to me. > > Regards, > Sean. > > On 31/03/17 18:50, Rob McKenna wrote: >> Hi Kevin, >> >> These changes will need codereview. >> >> -Rob >> >> On 31/03/17 03:32, Kevin Walls wrote: >>> Hi, >>> >>> This is an approval request to backport into 8u: >>> >>> 8165482: java in ldoms, with cpu-arch=generic has problems >>> 9 changeset: >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dfff5edc66df >>> >>> With a few routine changes this backports OK: >>> >>> src/cpu/sparc/vm/vm_version_sparc.cpp: has a different initial >>> number of %s >>> in a call to jio_snprintf(), so it's not automatic, but the backport >>> adds >>> one %s. >>> >>> src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: in 8u we >>> have an >>> #ifndef PRODUCT which isn't in 9, not part of the change, but means >>> the diff >>> won't apply automatically. >>> >>> 9 uses log(), logging in 8u uses tty->print_cr, and needs err_msg() >>> to form >>> a message rather than having printf-style formatting built-in. 8u >>> also uses >>> #ifndef PRODUCT also, and in some places if (PrintMiscellaneous && >>> Verbose) >>> >>> Webrev in 8u of these changes: >>> http://cr.openjdk.java.net/~kevinw/8165482.8u/webrev.00/ >>> >>> Thanks >>> Kevin >>> >>> >>> >>> > From kevin.walls at oracle.com Tue Apr 4 10:24:12 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 4 Apr 2017 11:24:12 +0100 Subject: [8u-dev] Request for approval for CR: 8164002: Add a new CPU family (S_family) for SPARC S7 and above processors Message-ID: Hi, This is a request to backport this CR into 8u-dev: 8164002: Add a new CPU family (S_family) for SPARC S7 and above processors JBS: https://bugs.openjdk.java.net/browse/JDK-8164002 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/bc41ec244c94 The hotspot change for 8 is pasted in below. This is almost a straight import: in vm_version_sparc.hpp the enum Feature_Flag does not have all the same elements as in jdk9, so that part of the change (adding S_family and renumbering) needs to be manually applied. Thanks Kevin diff -r ef91cb539697 src/cpu/sparc/vm/vm_version_sparc.cpp --- a/src/cpu/sparc/vm/vm_version_sparc.cpp Fri Mar 31 07:46:19 2017 -0700 +++ b/src/cpu/sparc/vm/vm_version_sparc.cpp Tue Apr 04 02:19:40 2017 -0700 @@ -449,9 +449,10 @@ unsigned int VM_Version::calc_parallel_worker_threads() { unsigned int result; - if (is_M_series()) { - // for now, use same gc thread calculation for M-series as for niagara-plus - // in future, we may want to tweak parameters for nof_parallel_worker_thread + if (is_M_series() || is_S_series()) { + // for now, use same gc thread calculation for M-series and S-series as for + // niagara-plus. In future, we may want to tweak parameters for + // nof_parallel_worker_thread result = nof_parallel_worker_threads(5, 16, 8); } else if (is_niagara_plus()) { result = nof_parallel_worker_threads(5, 16, 8); @@ -475,6 +476,9 @@ } else if (strstr(impl, "SPARC-M") != NULL) { // M-series SPARC is based on T-series. features |= (M_family_m | T_family_m); + } else if (strstr(impl, "SPARC-S") != NULL) { + // S-series SPARC is based on T-series. + features |= (S_family_m | T_family_m); } else if (strstr(impl, "SPARC-T") != NULL) { features |= T_family_m; if (strstr(impl, "SPARC-T1") != NULL) { diff -r ef91cb539697 src/cpu/sparc/vm/vm_version_sparc.hpp --- a/src/cpu/sparc/vm/vm_version_sparc.hpp Fri Mar 31 07:46:19 2017 -0700 +++ b/src/cpu/sparc/vm/vm_version_sparc.hpp Tue Apr 04 02:19:40 2017 -0700 @@ -47,13 +47,14 @@ cbcond_instructions = 13, sparc64_family = 14, M_family = 15, - T_family = 16, - T1_model = 17, - sparc5_instructions = 18, - aes_instructions = 19, - sha1_instruction = 20, - sha256_instruction = 21, - sha512_instruction = 22 + S_family = 16, + T_family = 17, + T1_model = 18, + sparc5_instructions = 19, + aes_instructions = 20, + sha1_instruction = 21, + sha256_instruction = 22, + sha512_instruction = 23 }; enum Feature_Flag_Set { @@ -76,6 +77,7 @@ cbcond_instructions_m = 1 << cbcond_instructions, sparc64_family_m = 1 << sparc64_family, M_family_m = 1 << M_family, + S_family_m = 1 << S_family, T_family_m = 1 << T_family, T1_model_m = 1 << T1_model, sparc5_instructions_m = 1 << sparc5_instructions, @@ -105,6 +107,7 @@ // Returns true if the platform is in the niagara line (T series) static bool is_M_family(int features) { return (features & M_family_m) != 0; } + static bool is_S_family(int features) { return (features & S_family_m) != 0; } static bool is_T_family(int features) { return (features & T_family_m) != 0; } static bool is_niagara() { return is_T_family(_features); } #ifdef ASSERT @@ -152,6 +155,7 @@ static bool is_niagara_plus() { return is_T_family(_features) && !is_T1_model(_features); } static bool is_M_series() { return is_M_family(_features); } + static bool is_S_series() { return is_S_family(_features); } static bool is_T4() { return is_T_family(_features) && has_cbcond(); } static bool is_T7() { return is_T_family(_features) && has_sparc5_instr(); } From sean.coffey at oracle.com Tue Apr 4 10:36:07 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 4 Apr 2017 11:36:07 +0100 Subject: [8u-dev] Request for approval for CR: 8164002: Add a new CPU family (S_family) for SPARC S7 and above processors In-Reply-To: References: Message-ID: <02ffc413-9ee4-ad12-f464-25cb1e1fa1b5@oracle.com> Looks good Kevin. I've reviewed the edits but it's no harm to get a hotspot engineer to verify also. Approved for jdk8u-dev. regards, Sean. On 04/04/2017 11:24, Kevin Walls wrote: > Hi, > > This is a request to backport this CR into 8u-dev: > > 8164002: Add a new CPU family (S_family) for SPARC S7 and above > processors > JBS: https://bugs.openjdk.java.net/browse/JDK-8164002 > 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/bc41ec244c94 > > The hotspot change for 8 is pasted in below. > > This is almost a straight import: in vm_version_sparc.hpp the enum > Feature_Flag does not have all the same elements as in jdk9, so that > part of the change (adding S_family and renumbering) needs to be > manually applied. > > Thanks > Kevin > > > diff -r ef91cb539697 src/cpu/sparc/vm/vm_version_sparc.cpp > --- a/src/cpu/sparc/vm/vm_version_sparc.cpp Fri Mar 31 07:46:19 > 2017 -0700 > +++ b/src/cpu/sparc/vm/vm_version_sparc.cpp Tue Apr 04 02:19:40 > 2017 -0700 > @@ -449,9 +449,10 @@ > > unsigned int VM_Version::calc_parallel_worker_threads() { > unsigned int result; > - if (is_M_series()) { > - // for now, use same gc thread calculation for M-series as for > niagara-plus > - // in future, we may want to tweak parameters for > nof_parallel_worker_thread > + if (is_M_series() || is_S_series()) { > + // for now, use same gc thread calculation for M-series and > S-series as for > + // niagara-plus. In future, we may want to tweak parameters for > + // nof_parallel_worker_thread > result = nof_parallel_worker_threads(5, 16, 8); > } else if (is_niagara_plus()) { > result = nof_parallel_worker_threads(5, 16, 8); > @@ -475,6 +476,9 @@ > } else if (strstr(impl, "SPARC-M") != NULL) { > // M-series SPARC is based on T-series. > features |= (M_family_m | T_family_m); > + } else if (strstr(impl, "SPARC-S") != NULL) { > + // S-series SPARC is based on T-series. > + features |= (S_family_m | T_family_m); > } else if (strstr(impl, "SPARC-T") != NULL) { > features |= T_family_m; > if (strstr(impl, "SPARC-T1") != NULL) { > diff -r ef91cb539697 src/cpu/sparc/vm/vm_version_sparc.hpp > --- a/src/cpu/sparc/vm/vm_version_sparc.hpp Fri Mar 31 07:46:19 > 2017 -0700 > +++ b/src/cpu/sparc/vm/vm_version_sparc.hpp Tue Apr 04 02:19:40 > 2017 -0700 > @@ -47,13 +47,14 @@ > cbcond_instructions = 13, > sparc64_family = 14, > M_family = 15, > - T_family = 16, > - T1_model = 17, > - sparc5_instructions = 18, > - aes_instructions = 19, > - sha1_instruction = 20, > - sha256_instruction = 21, > - sha512_instruction = 22 > + S_family = 16, > + T_family = 17, > + T1_model = 18, > + sparc5_instructions = 19, > + aes_instructions = 20, > + sha1_instruction = 21, > + sha256_instruction = 22, > + sha512_instruction = 23 > }; > > enum Feature_Flag_Set { > @@ -76,6 +77,7 @@ > cbcond_instructions_m = 1 << cbcond_instructions, > sparc64_family_m = 1 << sparc64_family, > M_family_m = 1 << M_family, > + S_family_m = 1 << S_family, > T_family_m = 1 << T_family, > T1_model_m = 1 << T1_model, > sparc5_instructions_m = 1 << sparc5_instructions, > @@ -105,6 +107,7 @@ > > // Returns true if the platform is in the niagara line (T series) > static bool is_M_family(int features) { return (features & > M_family_m) != 0; } > + static bool is_S_family(int features) { return (features & > S_family_m) != 0; } > static bool is_T_family(int features) { return (features & > T_family_m) != 0; } > static bool is_niagara() { return is_T_family(_features); } > #ifdef ASSERT > @@ -152,6 +155,7 @@ > static bool is_niagara_plus() { return > is_T_family(_features) && !is_T1_model(_features); } > > static bool is_M_series() { return > is_M_family(_features); } > + static bool is_S_series() { return > is_S_family(_features); } > static bool is_T4() { return > is_T_family(_features) && has_cbcond(); } > static bool is_T7() { return > is_T_family(_features) && has_sparc5_instr(); } > > From kevin.walls at oracle.com Tue Apr 4 11:28:40 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 4 Apr 2017 12:28:40 +0100 Subject: [8u-dev] Request for approval for CR: 8164002: Add a new CPU family (S_family) for SPARC S7 and above processors In-Reply-To: <02ffc413-9ee4-ad12-f464-25cb1e1fa1b5@oracle.com> References: <02ffc413-9ee4-ad12-f464-25cb1e1fa1b5@oracle.com> Message-ID: Great, thanks. Thanks also David Buck who looked over it was well, Cheers Kevin On 04/04/2017 11:36, Se?n Coffey wrote: > Looks good Kevin. I've reviewed the edits but it's no harm to get a > hotspot engineer to verify also. > > Approved for jdk8u-dev. > > regards, > Sean. > > On 04/04/2017 11:24, Kevin Walls wrote: >> Hi, >> >> This is a request to backport this CR into 8u-dev: >> >> 8164002: Add a new CPU family (S_family) for SPARC S7 and above >> processors >> JBS: https://bugs.openjdk.java.net/browse/JDK-8164002 >> 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/bc41ec244c94 >> >> The hotspot change for 8 is pasted in below. >> >> This is almost a straight import: in vm_version_sparc.hpp the enum >> Feature_Flag does not have all the same elements as in jdk9, so that >> part of the change (adding S_family and renumbering) needs to be >> manually applied. >> >> Thanks >> Kevin >> >> >> diff -r ef91cb539697 src/cpu/sparc/vm/vm_version_sparc.cpp >> --- a/src/cpu/sparc/vm/vm_version_sparc.cpp Fri Mar 31 07:46:19 >> 2017 -0700 >> +++ b/src/cpu/sparc/vm/vm_version_sparc.cpp Tue Apr 04 02:19:40 >> 2017 -0700 >> @@ -449,9 +449,10 @@ >> >> unsigned int VM_Version::calc_parallel_worker_threads() { >> unsigned int result; >> - if (is_M_series()) { >> - // for now, use same gc thread calculation for M-series as for >> niagara-plus >> - // in future, we may want to tweak parameters for >> nof_parallel_worker_thread >> + if (is_M_series() || is_S_series()) { >> + // for now, use same gc thread calculation for M-series and >> S-series as for >> + // niagara-plus. In future, we may want to tweak parameters for >> + // nof_parallel_worker_thread >> result = nof_parallel_worker_threads(5, 16, 8); >> } else if (is_niagara_plus()) { >> result = nof_parallel_worker_threads(5, 16, 8); >> @@ -475,6 +476,9 @@ >> } else if (strstr(impl, "SPARC-M") != NULL) { >> // M-series SPARC is based on T-series. >> features |= (M_family_m | T_family_m); >> + } else if (strstr(impl, "SPARC-S") != NULL) { >> + // S-series SPARC is based on T-series. >> + features |= (S_family_m | T_family_m); >> } else if (strstr(impl, "SPARC-T") != NULL) { >> features |= T_family_m; >> if (strstr(impl, "SPARC-T1") != NULL) { >> diff -r ef91cb539697 src/cpu/sparc/vm/vm_version_sparc.hpp >> --- a/src/cpu/sparc/vm/vm_version_sparc.hpp Fri Mar 31 07:46:19 >> 2017 -0700 >> +++ b/src/cpu/sparc/vm/vm_version_sparc.hpp Tue Apr 04 02:19:40 >> 2017 -0700 >> @@ -47,13 +47,14 @@ >> cbcond_instructions = 13, >> sparc64_family = 14, >> M_family = 15, >> - T_family = 16, >> - T1_model = 17, >> - sparc5_instructions = 18, >> - aes_instructions = 19, >> - sha1_instruction = 20, >> - sha256_instruction = 21, >> - sha512_instruction = 22 >> + S_family = 16, >> + T_family = 17, >> + T1_model = 18, >> + sparc5_instructions = 19, >> + aes_instructions = 20, >> + sha1_instruction = 21, >> + sha256_instruction = 22, >> + sha512_instruction = 23 >> }; >> >> enum Feature_Flag_Set { >> @@ -76,6 +77,7 @@ >> cbcond_instructions_m = 1 << cbcond_instructions, >> sparc64_family_m = 1 << sparc64_family, >> M_family_m = 1 << M_family, >> + S_family_m = 1 << S_family, >> T_family_m = 1 << T_family, >> T1_model_m = 1 << T1_model, >> sparc5_instructions_m = 1 << sparc5_instructions, >> @@ -105,6 +107,7 @@ >> >> // Returns true if the platform is in the niagara line (T series) >> static bool is_M_family(int features) { return (features & >> M_family_m) != 0; } >> + static bool is_S_family(int features) { return (features & >> S_family_m) != 0; } >> static bool is_T_family(int features) { return (features & >> T_family_m) != 0; } >> static bool is_niagara() { return is_T_family(_features); } >> #ifdef ASSERT >> @@ -152,6 +155,7 @@ >> static bool is_niagara_plus() { return >> is_T_family(_features) && !is_T1_model(_features); } >> >> static bool is_M_series() { return >> is_M_family(_features); } >> + static bool is_S_series() { return >> is_S_family(_features); } >> static bool is_T4() { return >> is_T_family(_features) && has_cbcond(); } >> static bool is_T7() { return >> is_T_family(_features) && has_sparc5_instr(); } >> >> > From david.buck at oracle.com Thu Apr 6 07:37:12 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 6 Apr 2017 16:37:12 +0900 Subject: [8u] RFA 8153267: nmethod's exception cache not multi-thread safe Message-ID: <64ddc7c2-81d4-74de-b928-0133919eef53@oracle.com> Hi! Please approve the following backport of JDK-8153267 from 9 to 8u: 8153267 bug report: https://bugs.openjdk.java.net/browse/JDK-8153267 8u backport webrev: http://cr.openjdk.java.net/~dbuck/8153267.0_jdk8u/ code review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-April/025944.html Cheers, -Buck From sean.coffey at oracle.com Thu Apr 6 07:51:56 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 6 Apr 2017 08:51:56 +0100 Subject: [8u] RFA 8153267: nmethod's exception cache not multi-thread safe In-Reply-To: <64ddc7c2-81d4-74de-b928-0133919eef53@oracle.com> References: <64ddc7c2-81d4-74de-b928-0133919eef53@oracle.com> Message-ID: Approved. regards, Sean. On 06/04/2017 08:37, David Buck wrote: > Hi! > > Please approve the following backport of JDK-8153267 from 9 to 8u: > > 8153267 bug report: https://bugs.openjdk.java.net/browse/JDK-8153267 > 8u backport webrev: http://cr.openjdk.java.net/~dbuck/8153267.0_jdk8u/ > code review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-April/025944.html > > Cheers, > -Buck > From HORII at jp.ibm.com Thu Apr 6 16:06:56 2017 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Fri, 7 Apr 2017 01:06:56 +0900 Subject: [8u] Request for enhancement backport approval for 8144019 Message-ID: Dear all, Could you please approve the backport of the following ppc64 change to jdk8u-dev? 8144019: PPC64 C1: Introduce Client Compiler Bug: https://bugs.openjdk.java.net/browse/JDK-8144019 Webrev: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4a24de859a87 Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020229.html URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/4a24de859a87 Though the original patch includes many changes in shared, we will be able to reduce them to less than 100 lines of changes in shared. Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo From rob.mckenna at oracle.com Thu Apr 6 16:31:05 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 6 Apr 2017 17:31:05 +0100 Subject: [8u] Request for enhancement backport approval for 8144019 In-Reply-To: References: Message-ID: <20170406163105.GB3166@vimes> Approved on the understanding that Volker is happy with it. Volker, would you mind commenting? -Rob On 07/04/17 01:06, Hiroshi H Horii wrote: > Dear all, > > Could you please approve the backport of the following ppc64 change to > jdk8u-dev? > > 8144019: PPC64 C1: Introduce Client Compiler > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144019 > Webrev: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4a24de859a87 > Review: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020229.html > URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/4a24de859a87 > > Though the original patch includes many changes in shared, we will be able > to reduce them to less than 100 lines of changes in shared. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > From naoto.sato at oracle.com Thu Apr 6 18:06:55 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 6 Apr 2017 11:06:55 -0700 Subject: [8u-dev] Request for approval for Japanese supplemental era related fixes - 8054214, 8173423, 8177678 In-Reply-To: References: <0c1a470e-452d-aa9c-23c6-389757548661@oracle.com> <845d3beb-554b-3de3-de54-94a13afd6a6b@oracle.com> Message-ID: Hello, Can I get the backport approval for the following? CCC has been filed and approved, and the new test case has been reviewed [1]. Naoto [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047079.html On 3/29/17 9:18 AM, Naoto Sato wrote: > Thanks, Sean. > > On 3/29/17 3:32 AM, Se?n Coffey wrote: >> Naoto, >> >> A CCC was logged for 8054214 in JDK 9. I'd be even more cautious in JDK >> 8u porting. Please log a CCC for JDK 8u port request. > > Will file a CCC for the backport. > >> >> If you're dropping the jdk9 testcase for 8u porting, can you please >> consider updating an existing one to test this new functionality ? It >> should be possible and it'll help verify the backport for quality team. > > It's not a new functionality per se, but in JDK9 the property is > provided with the command line option, while in JDK8 it was a static > calendar.properties file. Filed the following issue to create a JDK8 > specific test case. > > https://bugs.openjdk.java.net/browse/JDK-8177776 > > Naoto > >> >> Regards, >> Sean. >> >> On 28/03/17 22:59, Naoto Sato wrote: >>> Hello, >>> >>> Please approve the backport of the fixes for the supplemental Japanese >>> era related bugs. The issue-links/changesets/discussions for JDK9 are >>> as follows: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8054214 >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/21b45d72c6c0 >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045310.html >>> >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8173423 >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e0ab92b7360f >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/046150.html >>> >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8177678 >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e685e3197f62 >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046956.html >>> >>> >>> >>> The proposed webrev is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8054214.8173423.8177678/webrev.00/ >>> >>> The changes apply cleanly, except the copyright year and test cases >>> that are specific to JDK9, which are removed in this request. >>> >>> Naoto >>> >> From gustavo.scalet at eldorado.org.br Fri Apr 7 14:14:59 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 7 Apr 2017 14:14:59 +0000 Subject: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics Message-ID: Hi, We implemented the MulAdd intrinsic on PPC on JDK 9 and now we're backporting it to 8 but I'm facing an exception which I assume it's a bug elsewhere: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/sharedRuntime_ppc.cpp:737 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/gut/jdk8u-dev/hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp:737), pid=7631, tid=0x00003fff3454f1a0 # guarantee(i > 0 && sig_bt[i-1] == T_LONG) failed: argument of type (bt) should have been promoted to type (T_LONG,bt) for bt in {T_BOOLEAN, T_CHAR, T_BYTE, T_SHORT, T_INT} # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-debug-gut_2017_04_05_11_00-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode linux-ppc64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/hs_err_pid7631.log # # Compiler replay data is saved as: # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/replay_pid7631.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 70365327192480 Dumping core ... Aborted Please take a look at the diff[1] for the new muladd and a test case[2] in java, which has an argument to repeat the main loop. Setting it with a high value such as 1234 is enough to jit the code and run the intrinsic. I also noticed that this check in hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp does not exist in JDK9 due to a changeset[3] that was not backported. But that didn't stop X64 MulAdd intrinsics to work as it is. As I implemented one with the same interface, I don't understand why it's happening now... Thanks in advance [1] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file-add-muladd-ppc-diff [2] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file-testmuladd-java [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d7f63963925f#l3.7 From ramanand.patil at oracle.com Mon Apr 10 07:39:31 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 10 Apr 2017 00:39:31 -0700 (PDT) Subject: [8u-dev] Request for Approval: Backport of 8177449: (tz) Support tzdata2017b Message-ID: <62ca41ab-c7fa-4aa1-8090-d8fc905e830f@default> Hi, Please approve the backport of 8177449 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8177449 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d584006ddd5d JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2017-March/002280.html Changes apply cleanly to jdk8u-dev after path reshuffling. Regards, Ramanand. From sean.coffey at oracle.com Mon Apr 10 07:53:54 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 10 Apr 2017 08:53:54 +0100 Subject: [8u-dev] Request for Approval: Backport of 8177449: (tz) Support tzdata2017b In-Reply-To: <62ca41ab-c7fa-4aa1-8090-d8fc905e830f@default> References: <62ca41ab-c7fa-4aa1-8090-d8fc905e830f@default> Message-ID: <9d165c40-99d9-4271-7ce4-92213070f734@oracle.com> Approved. Regards, Sean. On 10/04/2017 08:39, Ramanand Patil wrote: > Hi, > Please approve the backport of 8177449 to 8u-dev. > Bug: https://bugs.openjdk.java.net/browse/JDK-8177449 > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d584006ddd5d > JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2017-March/002280.html > > Changes apply cleanly to jdk8u-dev after path reshuffling. > > Regards, > Ramanand. > From sean.coffey at oracle.com Mon Apr 10 07:57:31 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 10 Apr 2017 08:57:31 +0100 Subject: [8u-dev] Request for approval for Japanese supplemental era related fixes - 8054214, 8173423, 8177678 In-Reply-To: References: <0c1a470e-452d-aa9c-23c6-389757548661@oracle.com> <845d3beb-554b-3de3-de54-94a13afd6a6b@oracle.com> Message-ID: Thanks for following up Naoto. Approved. Regards, Sean. On 06/04/2017 19:06, Naoto Sato wrote: > Hello, > > Can I get the backport approval for the following? CCC has been filed > and approved, and the new test case has been reviewed [1]. > > Naoto > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047079.html > > On 3/29/17 9:18 AM, Naoto Sato wrote: >> Thanks, Sean. >> >> On 3/29/17 3:32 AM, Se?n Coffey wrote: >>> Naoto, >>> >>> A CCC was logged for 8054214 in JDK 9. I'd be even more cautious in JDK >>> 8u porting. Please log a CCC for JDK 8u port request. >> >> Will file a CCC for the backport. >> >>> >>> If you're dropping the jdk9 testcase for 8u porting, can you please >>> consider updating an existing one to test this new functionality ? It >>> should be possible and it'll help verify the backport for quality team. >> >> It's not a new functionality per se, but in JDK9 the property is >> provided with the command line option, while in JDK8 it was a static >> calendar.properties file. Filed the following issue to create a JDK8 >> specific test case. >> >> https://bugs.openjdk.java.net/browse/JDK-8177776 >> >> Naoto >> >>> >>> Regards, >>> Sean. >>> >>> On 28/03/17 22:59, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please approve the backport of the fixes for the supplemental Japanese >>>> era related bugs. The issue-links/changesets/discussions for JDK9 are >>>> as follows: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8054214 >>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/21b45d72c6c0 >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045310.html >>>> >>>> >>>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8173423 >>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e0ab92b7360f >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/046150.html >>>> >>>> >>>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8177678 >>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e685e3197f62 >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046956.html >>>> >>>> >>>> >>>> >>>> The proposed webrev is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8054214.8173423.8177678/webrev.00/ >>>> >>>> The changes apply cleanly, except the copyright year and test cases >>>> that are specific to JDK9, which are removed in this request. >>>> >>>> Naoto >>>> >>> From martin.doerr at sap.com Mon Apr 10 09:46:04 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 10 Apr 2017 09:46:04 +0000 Subject: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics In-Reply-To: References: Message-ID: <03ec681e790f4484a1830de8d475e0ae@sap.com> Hi Gustavo, before change "8086069: Adapt runtime calls to recent intrinsics to pass ints as long", it was required to convert int to long arguments for stub calls as well. This could be done in library_call by: Node* call = NULL; if (CCallingConventionRequiresIntsAsLongs) { Node* xlen_I2L = ConvI2L(xlen); Node* ylen_I2L = ConvI2L(ylen); Node* zlen_I2L = ConvI2L(zlen); call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen_I2L XTOP, y_start, ylen_I2L XTOP, z_start, zlen_I2L XTOP); } else { call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen, y_start, ylen, z_start, zlen); } In the current jdk9 code, stub calls are no longer performed according to the C calling convention (which requires int to long conversion on PPC64). The current stub code is designed to ignore the high 32 bits. Hence, the requirement for conversion only exists for real C calls, but no longer for stubs. Best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: Freitag, 7. April 2017 16:15 To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics Hi, We implemented the MulAdd intrinsic on PPC on JDK 9 and now we're backporting it to 8 but I'm facing an exception which I assume it's a bug elsewhere: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/sharedRuntime_ppc.cpp:737 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/gut/jdk8u-dev/hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp:737), pid=7631, tid=0x00003fff3454f1a0 # guarantee(i > 0 && sig_bt[i-1] == T_LONG) failed: argument of type (bt) should have been promoted to type (T_LONG,bt) for bt in {T_BOOLEAN, T_CHAR, T_BYTE, T_SHORT, T_INT} # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-debug-gut_2017_04_05_11_00-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode linux-ppc64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/hs_err_pid7631.log # # Compiler replay data is saved as: # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/replay_pid7631.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 70365327192480 Dumping core ... Aborted Please take a look at the diff[1] for the new muladd and a test case[2] in java, which has an argument to repeat the main loop. Setting it with a high value such as 1234 is enough to jit the code and run the intrinsic. I also noticed that this check in hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp does not exist in JDK9 due to a changeset[3] that was not backported. But that didn't stop X64 MulAdd intrinsics to work as it is. As I implemented one with the same interface, I don't understand why it's happening now... Thanks in advance [1] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file-add-muladd-ppc-diff [2] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file-testmuladd-java [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d7f63963925f#l3.7 From gustavo.scalet at eldorado.org.br Mon Apr 10 11:53:01 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 10 Apr 2017 11:53:01 +0000 Subject: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics In-Reply-To: <03ec681e790f4484a1830de8d475e0ae@sap.com> References: <03ec681e790f4484a1830de8d475e0ae@sap.com> Message-ID: <3e0cc41ee0f146759d60034d6ca33555@serv030.corp.eldorado.org.br> Hello Martin, Thanks for explaining that! I'll perform these conversions on JDK8 and see how it goes. > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: segunda-feira, 10 de abril de 2017 06:46 > To: Gustavo Serra Scalet ; jdk8u- > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RE: [PPC][Hotspot] Aparently unrelated > SharedRuntime::c_calling_convention call fails when implementing new > intrinsics > > Hi Gustavo, > > before change "8086069: Adapt runtime calls to recent intrinsics to pass > ints as long", it was required to convert int to long arguments for stub > calls as well. > > This could be done in library_call by: > Node* call = NULL; > if (CCallingConventionRequiresIntsAsLongs) { > Node* xlen_I2L = ConvI2L(xlen); > Node* ylen_I2L = ConvI2L(ylen); > Node* zlen_I2L = ConvI2L(zlen); > call = make_runtime_call(RC_LEAF|RC_NO_FP, > OptoRuntime::multiplyToLen_Type(), > stubAddr, stubName, TypePtr::BOTTOM, > x_start, xlen_I2L XTOP, y_start, ylen_I2L > XTOP, z_start, zlen_I2L XTOP); > } > else { > call = make_runtime_call(RC_LEAF|RC_NO_FP, > OptoRuntime::multiplyToLen_Type(), > stubAddr, stubName, TypePtr::BOTTOM, > x_start, xlen, y_start, ylen, z_start, > zlen); > } > > In the current jdk9 code, stub calls are no longer performed according > to the C calling convention (which requires int to long conversion on > PPC64). The current stub code is designed to ignore the high 32 bits. > Hence, the requirement for conversion only exists for real C calls, but > no longer for stubs. > > Best regards, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Freitag, 7. April 2017 16:15 > To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: [PPC][Hotspot] Aparently unrelated > SharedRuntime::c_calling_convention call fails when implementing new > intrinsics > > Hi, > > We implemented the MulAdd intrinsic on PPC on JDK 9 and now we're > backporting it to 8 but I'm facing an exception which I assume it's a > bug elsewhere: > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: > SuppressErrorAt=/sharedRuntime_ppc.cpp:737 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/gut/jdk8u- > dev/hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp:737), pid=7631, > tid=0x00003fff3454f1a0 > # guarantee(i > 0 && sig_bt[i-1] == T_LONG) failed: argument of type > (bt) should have been promoted to type (T_LONG,bt) for bt in {T_BOOLEAN, > T_CHAR, T_BYTE, T_SHORT, T_INT} > # > # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal- > debug-gut_2017_04_05_11_00-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode linux- > ppc64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/hs_err_pid7631.log > # > # Compiler replay data is saved as: > # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/replay_pid7631.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > Current thread is 70365327192480 > Dumping core ... > Aborted > > Please take a look at the diff[1] for the new muladd and a test case[2] > in java, which has an argument to repeat the main loop. Setting it with > a high value such as 1234 is enough to jit the code and run the > intrinsic. > > I also noticed that this check in > hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp does not exist in JDK9 due > to a changeset[3] that was not backported. But that didn't stop X64 > MulAdd intrinsics to work as it is. As I implemented one with the same > interface, I don't understand why it's happening now... > > Thanks in advance > > [1] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file- > add-muladd-ppc-diff > [2] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file- > testmuladd-java > [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d7f63963925f#l3.7 From gustavo.scalet at eldorado.org.br Mon Apr 10 13:58:39 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 10 Apr 2017 13:58:39 +0000 Subject: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics In-Reply-To: <3e0cc41ee0f146759d60034d6ca33555@serv030.corp.eldorado.org.br> References: <03ec681e790f4484a1830de8d475e0ae@sap.com> <3e0cc41ee0f146759d60034d6ca33555@serv030.corp.eldorado.org.br> Message-ID: <880ad44e043e4fd7a6ccc2166e6b0d71@serv030.corp.eldorado.org.br> Wait, there is still something missing I didn't understand: Why would then this kind of stub work on X64? As I understood, I'd need to perform this change on hotspot/src/share/vm/opto/library_call.cpp , which is an arch-independent file. Wouldn't that be a drawback for other archs? Thanks > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: segunda-feira, 10 de abril de 2017 08:53 > To: Doerr, Martin ; jdk8u-dev at openjdk.java.net; > ppc-aix-port-dev at openjdk.java.net > Subject: RE: [PPC][Hotspot] Aparently unrelated > SharedRuntime::c_calling_convention call fails when implementing new > intrinsics > > Hello Martin, > > Thanks for explaining that! I'll perform these conversions on JDK8 and > see how it goes. > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: segunda-feira, 10 de abril de 2017 06:46 > > To: Gustavo Serra Scalet ; jdk8u- > > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > Subject: RE: [PPC][Hotspot] Aparently unrelated > > SharedRuntime::c_calling_convention call fails when implementing new > > intrinsics > > > > Hi Gustavo, > > > > before change "8086069: Adapt runtime calls to recent intrinsics to > > pass ints as long", it was required to convert int to long arguments > > for stub calls as well. > > > > This could be done in library_call by: > > Node* call = NULL; > > if (CCallingConventionRequiresIntsAsLongs) { > > Node* xlen_I2L = ConvI2L(xlen); > > Node* ylen_I2L = ConvI2L(ylen); > > Node* zlen_I2L = ConvI2L(zlen); > > call = make_runtime_call(RC_LEAF|RC_NO_FP, > > OptoRuntime::multiplyToLen_Type(), > > stubAddr, stubName, TypePtr::BOTTOM, > > x_start, xlen_I2L XTOP, y_start, > > ylen_I2L XTOP, z_start, zlen_I2L XTOP); > > } > > else { > > call = make_runtime_call(RC_LEAF|RC_NO_FP, > > OptoRuntime::multiplyToLen_Type(), > > stubAddr, stubName, TypePtr::BOTTOM, > > x_start, xlen, y_start, ylen, z_start, > > zlen); > > } > > > > In the current jdk9 code, stub calls are no longer performed according > > to the C calling convention (which requires int to long conversion on > > PPC64). The current stub code is designed to ignore the high 32 bits. > > Hence, the requirement for conversion only exists for real C calls, > > but no longer for stubs. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Freitag, 7. April 2017 16:15 > > To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > Subject: [PPC][Hotspot] Aparently unrelated > > SharedRuntime::c_calling_convention call fails when implementing new > > intrinsics > > > > Hi, > > > > We implemented the MulAdd intrinsic on PPC on JDK 9 and now we're > > backporting it to 8 but I'm facing an exception which I assume it's a > > bug elsewhere: > > # To suppress the following error report, specify this argument # > > after -XX: or in .hotspotrc: > > SuppressErrorAt=/sharedRuntime_ppc.cpp:737 > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error (/home/gut/jdk8u- > > dev/hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp:737), pid=7631, > > tid=0x00003fff3454f1a0 > > # guarantee(i > 0 && sig_bt[i-1] == T_LONG) failed: argument of type > > (bt) should have been promoted to type (T_LONG,bt) for bt in > > {T_BOOLEAN, T_CHAR, T_BYTE, T_SHORT, T_INT} # # JRE version: OpenJDK > > Runtime Environment (8.0) (build 1.8.0-internal- > > debug-gut_2017_04_05_11_00-b00) > > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode linux- > > ppc64 compressed oops) > > # Failed to write core dump. Core dumps have been disabled. To enable > > core dumping, try "ulimit -c unlimited" before starting Java again # # > > An error report file with more information is saved as: > > # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/hs_err_pid7631.log > > # > > # Compiler replay data is saved as: > > # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/replay_pid7631.log > > # > > # If you would like to submit a bug report, please visit: > > # http://bugreport.java.com/bugreport/crash.jsp > > # > > Current thread is 70365327192480 > > Dumping core ... > > Aborted > > > > Please take a look at the diff[1] for the new muladd and a test > > case[2] in java, which has an argument to repeat the main loop. > > Setting it with a high value such as 1234 is enough to jit the code > > and run the intrinsic. > > > > I also noticed that this check in > > hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp does not exist in JDK9 > > due to a changeset[3] that was not backported. But that didn't stop > > X64 MulAdd intrinsics to work as it is. As I implemented one with the > > same interface, I don't understand why it's happening now... > > > > Thanks in advance > > > > [1] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file- > > add-muladd-ppc-diff > > [2] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file- > > testmuladd-java > > [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d7f63963925f#l3.7 From martin.doerr at sap.com Mon Apr 10 14:22:08 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 10 Apr 2017 14:22:08 +0000 Subject: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics In-Reply-To: <880ad44e043e4fd7a6ccc2166e6b0d71@serv030.corp.eldorado.org.br> References: <03ec681e790f4484a1830de8d475e0ae@sap.com> <3e0cc41ee0f146759d60034d6ca33555@serv030.corp.eldorado.org.br> <880ad44e043e4fd7a6ccc2166e6b0d71@serv030.corp.eldorado.org.br> Message-ID: <20c35e7b97144fea881e9e4ecf3a77a3@sap.com> Hi Gustavo, CCallingConventionRequiresIntsAsLongs is only true on PPC64 in jdk8u. I think runtime.cpp would also need a change in OptoRuntime::multiplyToLen_Type(): if (CCallingConventionRequiresIntsAsLongs) { fields[argp++] = TypePtr::NOTNULL; // x fields[argp++] = TypeLong::LONG; // xlen fields[argp++] = TypeLong::HALF; // placeholder fields[argp++] = TypePtr::NOTNULL; // y fields[argp++] = TypeLong::LONG; // ylen fields[argp++] = TypeLong::HALF; // placeholder fields[argp++] = TypePtr::NOTNULL; // z fields[argp++] = TypeLong::LONG; // zlen fields[argp++] = TypeLong::HALF; // placeholder } else { fields[argp++] = TypePtr::NOTNULL; // x fields[argp++] = TypeInt::INT; // xlen fields[argp++] = TypePtr::NOTNULL; // y fields[argp++] = TypeInt::INT; // ylen fields[argp++] = TypePtr::NOTNULL; // z fields[argp++] = TypeInt::INT; // zlen } I'm not saying that I like this code, but that's how we had used it in 8. Int to long conversion is needed as long as the stub call convention is not relaxed (as in jdk-8086069). Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Montag, 10. April 2017 15:59 To: Doerr, Martin ; jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics Wait, there is still something missing I didn't understand: Why would then this kind of stub work on X64? As I understood, I'd need to perform this change on hotspot/src/share/vm/opto/library_call.cpp , which is an arch-independent file. Wouldn't that be a drawback for other archs? Thanks > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: segunda-feira, 10 de abril de 2017 08:53 > To: Doerr, Martin ; jdk8u-dev at openjdk.java.net; > ppc-aix-port-dev at openjdk.java.net > Subject: RE: [PPC][Hotspot] Aparently unrelated > SharedRuntime::c_calling_convention call fails when implementing new > intrinsics > > Hello Martin, > > Thanks for explaining that! I'll perform these conversions on JDK8 and > see how it goes. > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: segunda-feira, 10 de abril de 2017 06:46 > > To: Gustavo Serra Scalet ; jdk8u- > > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > Subject: RE: [PPC][Hotspot] Aparently unrelated > > SharedRuntime::c_calling_convention call fails when implementing new > > intrinsics > > > > Hi Gustavo, > > > > before change "8086069: Adapt runtime calls to recent intrinsics to > > pass ints as long", it was required to convert int to long arguments > > for stub calls as well. > > > > This could be done in library_call by: > > Node* call = NULL; > > if (CCallingConventionRequiresIntsAsLongs) { > > Node* xlen_I2L = ConvI2L(xlen); > > Node* ylen_I2L = ConvI2L(ylen); > > Node* zlen_I2L = ConvI2L(zlen); > > call = make_runtime_call(RC_LEAF|RC_NO_FP, > > OptoRuntime::multiplyToLen_Type(), > > stubAddr, stubName, TypePtr::BOTTOM, > > x_start, xlen_I2L XTOP, y_start, > > ylen_I2L XTOP, z_start, zlen_I2L XTOP); > > } > > else { > > call = make_runtime_call(RC_LEAF|RC_NO_FP, > > OptoRuntime::multiplyToLen_Type(), > > stubAddr, stubName, TypePtr::BOTTOM, > > x_start, xlen, y_start, ylen, z_start, > > zlen); > > } > > > > In the current jdk9 code, stub calls are no longer performed according > > to the C calling convention (which requires int to long conversion on > > PPC64). The current stub code is designed to ignore the high 32 bits. > > Hence, the requirement for conversion only exists for real C calls, > > but no longer for stubs. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Freitag, 7. April 2017 16:15 > > To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > Subject: [PPC][Hotspot] Aparently unrelated > > SharedRuntime::c_calling_convention call fails when implementing new > > intrinsics > > > > Hi, > > > > We implemented the MulAdd intrinsic on PPC on JDK 9 and now we're > > backporting it to 8 but I'm facing an exception which I assume it's a > > bug elsewhere: > > # To suppress the following error report, specify this argument # > > after -XX: or in .hotspotrc: > > SuppressErrorAt=/sharedRuntime_ppc.cpp:737 > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error (/home/gut/jdk8u- > > dev/hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp:737), pid=7631, > > tid=0x00003fff3454f1a0 > > # guarantee(i > 0 && sig_bt[i-1] == T_LONG) failed: argument of type > > (bt) should have been promoted to type (T_LONG,bt) for bt in > > {T_BOOLEAN, T_CHAR, T_BYTE, T_SHORT, T_INT} # # JRE version: OpenJDK > > Runtime Environment (8.0) (build 1.8.0-internal- > > debug-gut_2017_04_05_11_00-b00) > > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode linux- > > ppc64 compressed oops) > > # Failed to write core dump. Core dumps have been disabled. To enable > > core dumping, try "ulimit -c unlimited" before starting Java again # # > > An error report file with more information is saved as: > > # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/hs_err_pid7631.log > > # > > # Compiler replay data is saved as: > > # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/replay_pid7631.log > > # > > # If you would like to submit a bug report, please visit: > > # http://bugreport.java.com/bugreport/crash.jsp > > # > > Current thread is 70365327192480 > > Dumping core ... > > Aborted > > > > Please take a look at the diff[1] for the new muladd and a test > > case[2] in java, which has an argument to repeat the main loop. > > Setting it with a high value such as 1234 is enough to jit the code > > and run the intrinsic. > > > > I also noticed that this check in > > hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp does not exist in JDK9 > > due to a changeset[3] that was not backported. But that didn't stop > > X64 MulAdd intrinsics to work as it is. As I implemented one with the > > same interface, I don't understand why it's happening now... > > > > Thanks in advance > > > > [1] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file- > > add-muladd-ppc-diff > > [2] https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file- > > testmuladd-java > > [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d7f63963925f#l3.7 From vladimir.kempik at oracle.com Mon Apr 10 17:31:04 2017 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Mon, 10 Apr 2017 20:31:04 +0300 Subject: [8u-dev] RFA: 8173373: C1: NPE is thrown instead of LinkageError when accessing inaccessible field on NULL receiver Message-ID: <0cc1b91b-240e-34d2-f940-07f7961a77a3@oracle.com> Hello, Please, approve this backport of JDK-8173373 to JDK8u-dev. The fix applies almost cleanly, but still needed review. Tested with jprt. Regards, Vladimir JBS: https://bugs.openjdk.java.net/browse/JDK-8173373 JDK8 webrev: http://cr.openjdk.java.net/~vkempik/8173373/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-April/025982.html From gustavo.scalet at eldorado.org.br Mon Apr 10 19:47:18 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 10 Apr 2017 19:47:18 +0000 Subject: [PPC][Hotspot] Aparently unrelated SharedRuntime::c_calling_convention call fails when implementing new intrinsics In-Reply-To: <20c35e7b97144fea881e9e4ecf3a77a3@sap.com> References: <03ec681e790f4484a1830de8d475e0ae@sap.com> <3e0cc41ee0f146759d60034d6ca33555@serv030.corp.eldorado.org.br> <880ad44e043e4fd7a6ccc2166e6b0d71@serv030.corp.eldorado.org.br> <20c35e7b97144fea881e9e4ecf3a77a3@sap.com> Message-ID: <6699343c2d054db98cef28af9272a60d@serv030.corp.eldorado.org.br> Hello Martin, Just a short feedback: you got it all right! I could build the backport after changing what you pointed out and it's now working. Thanks a lot once again. > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: segunda-feira, 10 de abril de 2017 11:22 > To: Gustavo Serra Scalet ; jdk8u- > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RE: [PPC][Hotspot] Aparently unrelated > SharedRuntime::c_calling_convention call fails when implementing new > intrinsics > > Hi Gustavo, > > CCallingConventionRequiresIntsAsLongs is only true on PPC64 in jdk8u. > > I think runtime.cpp would also need a change in > OptoRuntime::multiplyToLen_Type(): > if (CCallingConventionRequiresIntsAsLongs) { > fields[argp++] = TypePtr::NOTNULL; // x > fields[argp++] = TypeLong::LONG; // xlen > fields[argp++] = TypeLong::HALF; // placeholder > fields[argp++] = TypePtr::NOTNULL; // y > fields[argp++] = TypeLong::LONG; // ylen > fields[argp++] = TypeLong::HALF; // placeholder > fields[argp++] = TypePtr::NOTNULL; // z > fields[argp++] = TypeLong::LONG; // zlen > fields[argp++] = TypeLong::HALF; // placeholder > } else { > fields[argp++] = TypePtr::NOTNULL; // x > fields[argp++] = TypeInt::INT; // xlen > fields[argp++] = TypePtr::NOTNULL; // y > fields[argp++] = TypeInt::INT; // ylen > fields[argp++] = TypePtr::NOTNULL; // z > fields[argp++] = TypeInt::INT; // zlen > } > > I'm not saying that I like this code, but that's how we had used it in > 8. > > Int to long conversion is needed as long as the stub call convention is > not relaxed (as in jdk-8086069). > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 10. April 2017 15:59 > To: Doerr, Martin ; jdk8u-dev at openjdk.java.net; > ppc-aix-port-dev at openjdk.java.net > Subject: RE: [PPC][Hotspot] Aparently unrelated > SharedRuntime::c_calling_convention call fails when implementing new > intrinsics > > Wait, there is still something missing I didn't understand: Why would > then this kind of stub work on X64? > > As I understood, I'd need to perform this change on > hotspot/src/share/vm/opto/library_call.cpp , which is an arch- > independent file. Wouldn't that be a drawback for other archs? > > Thanks > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: segunda-feira, 10 de abril de 2017 08:53 > > To: Doerr, Martin ; jdk8u-dev at openjdk.java.net; > > ppc-aix-port-dev at openjdk.java.net > > Subject: RE: [PPC][Hotspot] Aparently unrelated > > SharedRuntime::c_calling_convention call fails when implementing new > > intrinsics > > > > Hello Martin, > > > > Thanks for explaining that! I'll perform these conversions on JDK8 and > > see how it goes. > > > > > -----Original Message----- > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > Sent: segunda-feira, 10 de abril de 2017 06:46 > > > To: Gustavo Serra Scalet ; jdk8u- > > > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > > Subject: RE: [PPC][Hotspot] Aparently unrelated > > > SharedRuntime::c_calling_convention call fails when implementing new > > > intrinsics > > > > > > Hi Gustavo, > > > > > > before change "8086069: Adapt runtime calls to recent intrinsics to > > > pass ints as long", it was required to convert int to long arguments > > > for stub calls as well. > > > > > > This could be done in library_call by: > > > Node* call = NULL; > > > if (CCallingConventionRequiresIntsAsLongs) { > > > Node* xlen_I2L = ConvI2L(xlen); > > > Node* ylen_I2L = ConvI2L(ylen); > > > Node* zlen_I2L = ConvI2L(zlen); > > > call = make_runtime_call(RC_LEAF|RC_NO_FP, > > > OptoRuntime::multiplyToLen_Type(), > > > stubAddr, stubName, TypePtr::BOTTOM, > > > x_start, xlen_I2L XTOP, y_start, > > > ylen_I2L XTOP, z_start, zlen_I2L XTOP); > > > } > > > else { > > > call = make_runtime_call(RC_LEAF|RC_NO_FP, > > > OptoRuntime::multiplyToLen_Type(), > > > stubAddr, stubName, TypePtr::BOTTOM, > > > x_start, xlen, y_start, ylen, > > > z_start, zlen); > > > } > > > > > > In the current jdk9 code, stub calls are no longer performed > > > according to the C calling convention (which requires int to long > > > conversion on PPC64). The current stub code is designed to ignore > the high 32 bits. > > > Hence, the requirement for conversion only exists for real C calls, > > > but no longer for stubs. > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Freitag, 7. April 2017 16:15 > > > To: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > > Subject: [PPC][Hotspot] Aparently unrelated > > > SharedRuntime::c_calling_convention call fails when implementing new > > > intrinsics > > > > > > Hi, > > > > > > We implemented the MulAdd intrinsic on PPC on JDK 9 and now we're > > > backporting it to 8 but I'm facing an exception which I assume it's > > > a bug elsewhere: > > > # To suppress the following error report, specify this argument # > > > after -XX: or in .hotspotrc: > > > SuppressErrorAt=/sharedRuntime_ppc.cpp:737 > > > # > > > # A fatal error has been detected by the Java Runtime Environment: > > > # > > > # Internal Error (/home/gut/jdk8u- > > > dev/hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp:737), pid=7631, > > > tid=0x00003fff3454f1a0 > > > # guarantee(i > 0 && sig_bt[i-1] == T_LONG) failed: argument of > > > type > > > (bt) should have been promoted to type (T_LONG,bt) for bt in > > > {T_BOOLEAN, T_CHAR, T_BYTE, T_SHORT, T_INT} # # JRE version: OpenJDK > > > Runtime Environment (8.0) (build 1.8.0-internal- > > > debug-gut_2017_04_05_11_00-b00) > > > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode > > > linux- > > > ppc64 compressed oops) > > > # Failed to write core dump. Core dumps have been disabled. To > > > enable core dumping, try "ulimit -c unlimited" before starting Java > > > again # # An error report file with more information is saved as: > > > # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/hs_err_pid7631.log > > > # > > > # Compiler replay data is saved as: > > > # /home/gut/hs/hotspot/src/cpu/ppc/vm/tst/replay_pid7631.log > > > # > > > # If you would like to submit a bug report, please visit: > > > # http://bugreport.java.com/bugreport/crash.jsp > > > # > > > Current thread is 70365327192480 > > > Dumping core ... > > > Aborted > > > > > > Please take a look at the diff[1] for the new muladd and a test > > > case[2] in java, which has an argument to repeat the main loop. > > > Setting it with a high value such as 1234 is enough to jit the code > > > and run the intrinsic. > > > > > > I also noticed that this check in > > > hotspot/src/cpu/ppc/vm/sharedRuntime_ppc.cpp does not exist in JDK9 > > > due to a changeset[3] that was not backported. But that didn't stop > > > X64 MulAdd intrinsics to work as it is. As I implemented one with > > > the same interface, I don't understand why it's happening now... > > > > > > Thanks in advance > > > > > > [1] > > > https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file- > > > add-muladd-ppc-diff > > > [2] > > > https://gist.github.com/gut/3d5f7984ef3114113b224853867bc906#file- > > > testmuladd-java > > > [3] > > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d7f63963925f#l3.7 From david.buck at oracle.com Tue Apr 11 03:32:26 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 11 Apr 2017 12:32:26 +0900 Subject: [8u-dev] RFA: 8173373: C1: NPE is thrown instead of LinkageError when accessing inaccessible field on NULL receiver In-Reply-To: <0cc1b91b-240e-34d2-f940-07f7961a77a3@oracle.com> References: <0cc1b91b-240e-34d2-f940-07f7961a77a3@oracle.com> Message-ID: approved for push to 8u-dev Cheers, -Buck On 2017/04/11 2:31, Vladimir Kempik wrote: > Hello, > > Please, approve this backport of JDK-8173373 to JDK8u-dev. > > The fix applies almost cleanly, but still needed review. > > Tested with jprt. > > Regards, > Vladimir > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8173373 > > JDK8 webrev: > http://cr.openjdk.java.net/~vkempik/8173373/webrev.00/ > > Review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-April/025982.html > > > > From sean.coffey at oracle.com Tue Apr 11 20:08:20 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 11 Apr 2017 21:08:20 +0100 Subject: [8u communication] JDK 8 Updates porting process In-Reply-To: <58D689B8.6040103@oracle.com> References: <598cb189-554a-46c3-de55-a196a62c3ded@oracle.com> <58D689B8.6040103@oracle.com> Message-ID: The x-pool style version has a logical relationship with hgupdater and makes bug management easier. A 9-pool fixVersion will get converted to the correct fixVersion once hgupdater detects a push to a JDK 9 based forest. For that reason, l'd prefer to keep '9-pool'. I don't expect many of these exceptions and the OpenJDK maintainers can monitor the pending ports. I haven't heard any objections to the proposed change. I'll make an edit to the JDK 8 Updates ground rules page to reflect this change. regards, Sean. On 25/03/2017 15:16, Philip Race wrote: > Could we use 9-bp instead of 9-pool ? > 9-bp strikes a bit more urgency without identifying a release. > > X-pool has traditionally been the Sargasso Sea of releases > > -phil. > > On 3/25/17, 3:20 AM, Se?n Coffey wrote: >> With JDK 9 now entering the RDP2 phase, the bar for getting fixes >> into that release is high. A current requirement for JDK 8u fixes is >> ensuring that the changes are integrated into later JDK release >> families first [Rule 1, [1]]. If jdk8u ports are being blocked >> because of this, please let the JDK 8 Update Project maintainers know. >> >> While we wait for the JDK 9 Updates Project to form, I'd like to >> propose that we allow ports from JDK 10 into JDK 8 Updates where >> needed. We can open a '9-pool' record to track the JDK 9 port. I'll >> make the proposed change to the JDK 8 Updates rules next Friday if no >> objections are heard. >> >> [1] http://openjdk.java.net/projects/jdk8u/groundrules.html >> From mikhail.cherkasov at oracle.com Tue Apr 11 20:19:24 2017 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Tue, 11 Apr 2017 23:19:24 +0300 Subject: [8u-dev] Request for Approval: Backport of 8177450: javax.swing.text.html.parser.Parser parseScript ignores a character after commend end Message-ID: Hi all, Could you please approve a backport of 8177450 to jdk8? jdk8 fix is absolutely identical(after patch unshuffling) jbs: https://bugs.openjdk.java.net/browse/JDK-8177450 jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/79e099ab284b review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2017-March/007264.html Thanks, Mikhail. From rob.mckenna at oracle.com Tue Apr 11 22:42:13 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 11 Apr 2017 23:42:13 +0100 Subject: [8u-dev] Request for Approval: Backport of 8177450: javax.swing.text.html.parser.Parser parseScript ignores a character after commend end In-Reply-To: References: Message-ID: <20170411224213.GD2991@vimes> Approved -Rob On 11/04/17 11:19, Mikhail Cherkasov wrote: > Hi all, > > Could you please approve a backport of 8177450 to jdk8? > > jdk8 fix is absolutely identical(after patch unshuffling) > > jbs: https://bugs.openjdk.java.net/browse/JDK-8177450 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/79e099ab284b > review thread: > http://mail.openjdk.java.net/pipermail/swing-dev/2017-March/007264.html > > Thanks, > Mikhail. From prasadarao.koppula at oracle.com Thu Apr 13 10:46:37 2017 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Thu, 13 Apr 2017 03:46:37 -0700 (PDT) Subject: [8u-dev] Request for Approval: Backport of JDK-8157035: Use stronger algorithms and keys for JSSE testing Message-ID: Hi, Please approve the backport of 8157035 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8157035 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6273069a5ad Since there were few minor changes in test files this backport code review was done in a separate thread. JDK8 Review Thread: http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015778.html JDK8 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ecoffeys/webrev.8157035.jdk8u/"http://cr.openjdk.java.net/~coffeys/webrev.8157035.jdk8u/ Thanks, Prasad.K From sean.coffey at oracle.com Thu Apr 13 10:58:45 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 13 Apr 2017 11:58:45 +0100 Subject: [8u-dev] Request for Approval: Backport of JDK-8157035: Use stronger algorithms and keys for JSSE testing In-Reply-To: References: Message-ID: <1ea201b7-fbd2-50c9-ac4f-461583569015@oracle.com> Approved. I can push this for you. regards, Sean. On 13/04/2017 11:46, Prasadrao Koppula wrote: > Hi, > > > > Please approve the backport of 8157035 to 8u-dev. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157035 > > > > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6273069a5ad > > > > Since there were few minor changes in test files this backport code review was done in a separate thread. > > > > JDK8 Review Thread: http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015778.html > > > > JDK8 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ecoffeys/webrev.8157035.jdk8u/"http://cr.openjdk.java.net/~coffeys/webrev.8157035.jdk8u/ > > > > Thanks, > > Prasad.K > > From prasadarao.koppula at oracle.com Thu Apr 13 10:44:54 2017 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Thu, 13 Apr 2017 03:44:54 -0700 (PDT) Subject: [8u-dev] Request for Approval: Backport of JDK-8157035: Use stronger algorithms and keys for JSSE testing Message-ID: Hi, Please approve the backport of 8157035 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8157035 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c6273069a5ad Since there were few minor changes in test files this backport code review was done in a separate thread. JDK8 Review Thread: http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015778.html JDK8 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ecoffeys/webrev.8157035.jdk8u/"http://cr.openjdk.java.net/~coffeys/webrev.8157035.jdk8u/ Thanks, Prasad.K From stuart.monteith at linaro.org Thu Apr 13 13:44:17 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 13 Apr 2017 14:44:17 +0100 Subject: Cross compiling Openjdk 8 for ARM, can't locate compiler In-Reply-To: <8760irn876.fsf@bruno-dell> References: <8760irn876.fsf@bruno-dell> Message-ID: Hello Bruno, I've not tried cross-compiling Java, so I don't have anything that will help you. Your best chance for help is on the aarch32-port-dev mailing list. BR, Stuart On 29 March 2017 at 21:23, Bruno Kremel wrote: > Hi All, > > As I was not able to compile OpenJDK 9 (there is disscussion in other > mailing list). I tried to compile OpenJDK 8 precisely changeset 152-b02. > > I configure this way: > > ./configure --with-jvm-interpreter=cpp \ > --with-jvm-variants=zero --enable-openjdk-only \ > --with-freetype-include=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/freetype2\ > --with-freetype-lib=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib\ > --with-freetype=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/\ > --with-debug-level=release --openjdk-target=arm-buildroot-linux-gnueabi \ > --with-sys-root=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot\ > --with-tools-dir=~/linux/buildroot-openjdk8/output/host \ > --disable-freetype-bundling --enable-unlimited-crypto --disable-headful\ > OBJCOPY=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-objcopy > STRIP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-strip > CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ > CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ > CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ > CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ > LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ > BUILD_CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ > BUILD_CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ > BUILD_CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ > BUILD_LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc > > The configure script seems to have some bug that it can't locate the > compiler properly: > > ... > checking for cl... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc > configure: Resolving BUILD_CC (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) faile > d, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc directly. > checking for cl... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ > configure: Resolving BUILD_CXX (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++) fail > ed, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ directly. > checking for ld... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc > configure: Resolving BUILD_LD (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) faile > d, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc directly. > checking for /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... no > checking for /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... no > configure: error: Could not find a C compiler. You might be able to fix this by running 'sudo apt-get install build-ess > ential'. > configure exiting with result code 1 > ... > > Those files that it claims "no" do exist and they are indeed a GCC crosscompiler. > The same parameters work for OpenJDK 9 (it does find the compiler). > > How can I resolve this issue? > > Thanks > Bruno Kremel > From mikhail.cherkasov at oracle.com Fri Apr 14 13:54:43 2017 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Fri, 14 Apr 2017 16:54:43 +0300 Subject: [8u-dev] Request for Approval: Backport of 8076249: NPE in AccessBridge while editing JList model Message-ID: <1af299e5-fb68-b328-4414-6115fe3fd356@oracle.com> Hi all, Could you please approve a backport of 8076249 to jdk8? jdk8 fix is absolutely identical(after patch unshuffling) jbs: https://bugs.openjdk.java.net/browse/JDK-8076249 jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/61ea362c37f3 review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2017-April/007294.html Thanks, Mikhail. From sean.coffey at oracle.com Fri Apr 14 14:06:10 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 14 Apr 2017 15:06:10 +0100 Subject: [8u-dev] Request for Approval: Backport of 8076249: NPE in AccessBridge while editing JList model In-Reply-To: <1af299e5-fb68-b328-4414-6115fe3fd356@oracle.com> References: <1af299e5-fb68-b328-4414-6115fe3fd356@oracle.com> Message-ID: Approved. With a test included, I think you can remove the noreg-hard label. Regards, Sean. On 14/04/17 14:54, Mikhail Cherkasov wrote: > Hi all, > > Could you please approve a backport of 8076249 to jdk8? > > jdk8 fix is absolutely identical(after patch unshuffling) > > jbs: https://bugs.openjdk.java.net/browse/JDK-8076249 > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/61ea362c37f3 > review thread: > http://mail.openjdk.java.net/pipermail/swing-dev/2017-April/007294.html > > Thanks, > Mikhail. From mikhail.cherkasov at oracle.com Fri Apr 14 14:12:30 2017 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Fri, 14 Apr 2017 17:12:30 +0300 Subject: [8u-dev] Request for Approval: Backport of 8076249: NPE in AccessBridge while editing JList model In-Reply-To: References: <1af299e5-fb68-b328-4414-6115fe3fd356@oracle.com> Message-ID: Thank you. On 4/14/2017 5:06 PM, Se?n Coffey wrote: > Approved. With a test included, I think you can remove the noreg-hard > label. The label is removed. > > Regards, > Sean. > > On 14/04/17 14:54, Mikhail Cherkasov wrote: >> Hi all, >> >> Could you please approve a backport of 8076249 to jdk8? >> >> jdk8 fix is absolutely identical(after patch unshuffling) >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8076249 >> jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/61ea362c37f3 >> review thread: >> http://mail.openjdk.java.net/pipermail/swing-dev/2017-April/007294.html >> >> Thanks, >> Mikhail. > From rob.mckenna at oracle.com Fri Apr 14 15:13:57 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 14 Apr 2017 16:13:57 +0100 Subject: [8u] Request for enhancement backport approval for 8144019 In-Reply-To: <20170406163105.GB3166@vimes> References: <20170406163105.GB3166@vimes> Message-ID: <20170414151357.GA4247@vimes> As I understand it the "webrev" here does not constitute the fix as it will be pushed to 8. Please publish the actual webrev as it applies to 8 and follow the enhancement request approval template at: http://openjdk.java.net/projects/jdk8u/enhancement-template.html Given that this change actually does affect shared code we will need a particular focus on the 2nd bullet point in that template. To be explicit: this change is not approved for 8u-dev yet. -Rob On 06/04/17 05:31, Rob McKenna wrote: > Approved on the understanding that Volker is happy with it. Volker, > would you mind commenting? > > -Rob > > On 07/04/17 01:06, Hiroshi H Horii wrote: > > Dear all, > > > > Could you please approve the backport of the following ppc64 change to > > jdk8u-dev? > > > > 8144019: PPC64 C1: Introduce Client Compiler > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144019 > > Webrev: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4a24de859a87 > > Review: > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020229.html > > URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/4a24de859a87 > > > > Though the original patch includes many changes in shared, we will be able > > to reduce them to less than 100 lines of changes in shared. > > > > Regards, > > Hiroshi > > ----------------------- > > Hiroshi Horii, Ph.D. > > IBM Research - Tokyo > > From HORII at jp.ibm.com Fri Apr 14 16:35:48 2017 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Sat, 15 Apr 2017 01:35:48 +0900 Subject: [8u] Request for enhancement backport approval for 8144019 In-Reply-To: <20170414151357.GA4247@vimes> References: <20170406163105.GB3166@vimes> <20170414151357.GA4247@vimes> Message-ID: Dear Rob, I'm sorry that my request doesn't follow the guideline to backport enhancements. > Please publish the actual webrev as it applies to 8 I would like to add links to webrev that Michi created. http://cr.openjdk.java.net/~horii/jdk8u_support_tiered_ppc64le/hotspot/webrev02/ http://cr.openjdk.java.net/~horii/jdk8u_support_tiered_ppc64le/jdk/webrev02/ > and follow the enhancement request approval template at: > http://openjdk.java.net/projects/jdk8u/enhancement-template.html [a rationale for why the enhancement should be backported] C1 and Tiered Compilation provide faster startup for JVMs. In recent popular workloads, such as Hadoop and Spark (via Yarn), multiple JVMs concurrently run with their short life cycles. C1 and Tiered Compilation significantly shorten execution time of these workloads. For example, the above changes provide 15% improvement of execution time of Spark (2.1.0) q16 on POWER8 3.325MHz with 1.0 scale factor. [tests] We have ran SPECjbb2015, Spark TPC-DS queries, and jitreg tests. We confirmed SPECjbb2015 and Spark worked well. Michi will report the details of jitreg tests. [risks] Most of changes in shared codes have effects on only ppc64 and ppc64le. src/share/vm/c1/c1_Compilation.hpp: 1 line changed: 0 ins; 0 del; 1 mod; 340 unchg src/share/vm/c1/c1_GraphBuilder.cpp: 10 lines changed: 9 ins; 0 del; 1 mod; 4460 unchg src/share/vm/c1/c1_IR.cpp: 2 lines changed: 1 ins; 0 del; 1 mod; 1404 unchg src/share/vm/c1/c1_IR.hpp: 7 lines changed: 6 ins; 0 del; 1 mod; 357 unchg src/share/vm/c1/c1_LIR.hpp: 2 lines changed: 0 ins; 0 del; 2 mod; 2506 unchg src/share/vm/c1/c1_LIRGenerator.cpp: 10 lines changed: 8 ins; 0 del; 2 mod; 3673 unchg src/share/vm/c1/c1_LIRGenerator.hpp: 6 lines changed: 5 ins; 0 del; 1 mod; 644 unchg src/share/vm/c1/c1_RangeCheckElimination.hpp: 7 lines changed: 6 ins; 0 del; 1 mod; 243 unchg src/share/vm/c1/c1_Runtime1.cpp: 8 lines changed: 0 ins; 7 del; 1 mod; 1483 unchg src/share/vm/runtime/deoptimization.cpp: 10 lines changed: 2 ins; 0 del; 8 mod; 2074 unchg src/share/vm/runtime/deoptimization.hpp: 5 lines changed: 1 ins; 0 del; 4 mod; 385 unchg src/share/vm/runtime/globals.hpp: 3 lines changed: 3 ins; 0 del; 0 mod; 4027 unchg Changes in src/cpu/ppc will add C1 for ppc64 and ppc64le. We believe that impacts on Interpreter and C2 are limited on ppc64 and ppc64le. Please tell me if I'm still missing information to request an approval of this backport. Regards, Hiroshi Rob McKenna wrote on 2017/04/15 00:13:57: > From: Rob McKenna > To: Hiroshi H Horii/Japan/IBM at IBMJP, volker.simonis at gmail.com > Cc: Tim Ellison , Michihiro Horie/Japan/ > IBM at IBMJP, jdk8u-dev at openjdk.java.net, "Doerr, Martin" > Date: 2017/04/15 00:15 > Subject: Re: [8u] Request for enhancement backport approval for 8144019 > > As I understand it the "webrev" here does not constitute the fix as it > will be pushed to 8. > > Please publish the actual webrev as it applies to 8 and follow the > enhancement request approval template at: > > http://openjdk.java.net/projects/jdk8u/enhancement-template.html > > Given that this change actually does affect shared code we will need a > particular focus on the 2nd bullet point in that template. > > To be explicit: this change is not approved for 8u-dev yet. > > -Rob > > On 06/04/17 05:31, Rob McKenna wrote: > > Approved on the understanding that Volker is happy with it. Volker, > > would you mind commenting? > > > > -Rob > > > > On 07/04/17 01:06, Hiroshi H Horii wrote: > > > Dear all, > > > > > > Could you please approve the backport of the following ppc64 change to > > > jdk8u-dev? > > > > > > 8144019: PPC64 C1: Introduce Client Compiler > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144019 > > > Webrev: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4a24de859a87 > > > Review: > > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/ > 2015-December/020229.html > > > URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/4a24de859a87 > > > > > > Though the original patch includes many changes in shared, we > will be able > > > to reduce them to less than 100 lines of changes in shared. > > > > > > Regards, > > > Hiroshi > > > ----------------------- > > > Hiroshi Horii, Ph.D. > > > IBM Research - Tokyo > > > > From shafi.s.ahmad at oracle.com Mon Apr 17 05:06:11 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Sun, 16 Apr 2017 22:06:11 -0700 (PDT) Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <20170330141709.GB3771@vimes> References: <20170330141709.GB3771@vimes> Message-ID: <8b90e51d-1914-471e-aa34-0675146b3ebc@default> Hi, This changes required to improve the ability to diagnose issues in large projects. The information is available it is just that it is not being emitted in the exception message. This should fall under improvements to serviceability. So may I get the approval of enhancement backport of 'JDK-8171194 to jdk8u-dev. The enhancement backport request id is https://bugs.openjdk.java.net/browse/JDK-8176800 Regards, Shafi > -----Original Message----- > From: Rob McKenna > Sent: Thursday, March 30, 2017 7:47 PM > To: Shafi Ahmad > Cc: jdk8u-dev at openjdk.java.net > Subject: Re: [8u] Request for enhancement backport approval for CR JDK- > 8171194: Exception "Duplicate field name&signature in class file" should > report the name and signature of the field > > Hi Shafi, > > This request has been rejected by the PM as: > > "There isn't any justification as to why this shouldn't simply be done on the > next major release but should also be backported to already released > versions" > > It may help to update the justification in this thread focusing on the > servicability aspects and the impact on older releases. > > -Rob > > On 29/03/17 11:46, Shafi Ahmad wrote: > > Hi, > > > > May I get the approval of enhancement backport of 'JDK-8171194: > Exception "Duplicate field name&signature in class file" should report the > name and signature of the field' to jdk8u-dev. > > > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 > > > > "java.lang.ClassFormatError: Duplicate field name&signature in class file > CampaignClient" > > > > From the above Exception message, it is difficult of knowing what is > triggering the problem. > > If the class in question is quite big so removing code by trial and error is > very time consuming. > > > > With field name + signature, pinpointing the actual problematic code will be > easy and time saving. > > > > I have tested it with the jprt and jtreg tests. > > > > Please note the original bug was raised against jdk8u. > > > > Regards, > > Shafi > > From david.holmes at oracle.com Tue Apr 18 02:19:55 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Apr 2017 12:19:55 +1000 Subject: Cross compiling Openjdk 8 for ARM, can't locate compiler In-Reply-To: References: <8760irn876.fsf@bruno-dell> Message-ID: On 13/04/2017 11:44 PM, Stuart Monteith wrote: > Hello Bruno, > I've not tried cross-compiling Java, so I don't have anything that > will help you. Your best chance for help is on the aarch32-port-dev > mailing list. Folks there may be able to help but really this is an issue with building Zero for ARM on JDK 8. Note than unlike JDK 9 there is no OpenJDK ARM port in JDK 8. Cheers, David > BR, > Stuart > > > On 29 March 2017 at 21:23, Bruno Kremel wrote: >> Hi All, >> >> As I was not able to compile OpenJDK 9 (there is disscussion in other >> mailing list). I tried to compile OpenJDK 8 precisely changeset 152-b02. >> >> I configure this way: >> >> ./configure --with-jvm-interpreter=cpp \ >> --with-jvm-variants=zero --enable-openjdk-only \ >> --with-freetype-include=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/freetype2\ >> --with-freetype-lib=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib\ >> --with-freetype=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/\ >> --with-debug-level=release --openjdk-target=arm-buildroot-linux-gnueabi \ >> --with-sys-root=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot\ >> --with-tools-dir=~/linux/buildroot-openjdk8/output/host \ >> --disable-freetype-bundling --enable-unlimited-crypto --disable-headful\ >> OBJCOPY=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-objcopy >> STRIP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-strip >> CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ >> CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ >> CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ >> CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >> LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >> BUILD_CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ >> BUILD_CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ >> BUILD_CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >> BUILD_LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >> >> The configure script seems to have some bug that it can't locate the >> compiler properly: >> >> ... >> checking for cl... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >> configure: Resolving BUILD_CC (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) faile >> d, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc directly. >> checking for cl... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ >> configure: Resolving BUILD_CXX (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++) fail >> ed, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ directly. >> checking for ld... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >> configure: Resolving BUILD_LD (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) faile >> d, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc directly. >> checking for /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... no >> checking for /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... no >> configure: error: Could not find a C compiler. You might be able to fix this by running 'sudo apt-get install build-ess >> ential'. >> configure exiting with result code 1 >> ... >> >> Those files that it claims "no" do exist and they are indeed a GCC crosscompiler. >> The same parameters work for OpenJDK 9 (it does find the compiler). >> >> How can I resolve this issue? >> >> Thanks >> Bruno Kremel >> From david.holmes at oracle.com Tue Apr 18 02:24:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Apr 2017 12:24:24 +1000 Subject: Cross compiling Openjdk 8 for ARM, can't locate compiler In-Reply-To: References: <8760irn876.fsf@bruno-dell> Message-ID: On 18/04/2017 12:19 PM, David Holmes wrote: > On 13/04/2017 11:44 PM, Stuart Monteith wrote: >> Hello Bruno, >> I've not tried cross-compiling Java, so I don't have anything that >> will help you. Your best chance for help is on the aarch32-port-dev >> mailing list. > > Folks there may be able to help but really this is an issue with > building Zero for ARM on JDK 8. Note than unlike JDK 9 there is no > OpenJDK ARM port in JDK 8. And Zero doesn't use cross-compiling. David > Cheers, > David > >> BR, >> Stuart >> >> >> On 29 March 2017 at 21:23, Bruno Kremel wrote: >>> Hi All, >>> >>> As I was not able to compile OpenJDK 9 (there is disscussion in other >>> mailing list). I tried to compile OpenJDK 8 precisely changeset 152-b02. >>> >>> I configure this way: >>> >>> ./configure --with-jvm-interpreter=cpp \ >>> --with-jvm-variants=zero --enable-openjdk-only \ >>> --with-freetype-include=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/freetype2\ >>> >>> --with-freetype-lib=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib\ >>> >>> --with-freetype=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/\ >>> >>> --with-debug-level=release >>> --openjdk-target=arm-buildroot-linux-gnueabi \ >>> --with-sys-root=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot\ >>> >>> --with-tools-dir=~/linux/buildroot-openjdk8/output/host \ >>> --disable-freetype-bundling --enable-unlimited-crypto --disable-headful\ >>> OBJCOPY=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-objcopy >>> >>> STRIP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-strip >>> >>> CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ >>> CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ >>> >>> CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ >>> >>> CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >>> LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >>> BUILD_CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ >>> >>> BUILD_CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ >>> >>> BUILD_CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >>> >>> BUILD_LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>> >>> >>> The configure script seems to have some bug that it can't locate the >>> compiler properly: >>> >>> ... >>> checking for cl... >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>> >>> configure: Resolving BUILD_CC (as >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) >>> faile >>> d, using >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>> directly. >>> checking for cl... >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ >>> >>> configure: Resolving BUILD_CXX (as >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++) >>> fail >>> ed, using >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ >>> directly. >>> checking for ld... >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>> >>> configure: Resolving BUILD_LD (as >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) >>> faile >>> d, using >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>> directly. >>> checking for >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... >>> no >>> checking for >>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... >>> no >>> configure: error: Could not find a C compiler. You might be able to >>> fix this by running 'sudo apt-get install build-ess >>> ential'. >>> configure exiting with result code 1 >>> ... >>> >>> Those files that it claims "no" do exist and they are indeed a GCC >>> crosscompiler. >>> The same parameters work for OpenJDK 9 (it does find the compiler). >>> >>> How can I resolve this issue? >>> >>> Thanks >>> Bruno Kremel >>> From david.holmes at oracle.com Tue Apr 18 04:25:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Apr 2017 14:25:04 +1000 Subject: Cross compiling Openjdk 8 for ARM, can't locate compiler In-Reply-To: References: <8760irn876.fsf@bruno-dell> Message-ID: Ignore this part. :) David On 18/04/2017 12:24 PM, David Holmes wrote: > On 18/04/2017 12:19 PM, David Holmes wrote: >> On 13/04/2017 11:44 PM, Stuart Monteith wrote: >>> Hello Bruno, >>> I've not tried cross-compiling Java, so I don't have anything that >>> will help you. Your best chance for help is on the aarch32-port-dev >>> mailing list. >> >> Folks there may be able to help but really this is an issue with >> building Zero for ARM on JDK 8. Note than unlike JDK 9 there is no >> OpenJDK ARM port in JDK 8. > > And Zero doesn't use cross-compiling. > > David > >> Cheers, >> David >> >>> BR, >>> Stuart >>> >>> >>> On 29 March 2017 at 21:23, Bruno Kremel wrote: >>>> Hi All, >>>> >>>> As I was not able to compile OpenJDK 9 (there is disscussion in other >>>> mailing list). I tried to compile OpenJDK 8 precisely changeset >>>> 152-b02. >>>> >>>> I configure this way: >>>> >>>> ./configure --with-jvm-interpreter=cpp \ >>>> --with-jvm-variants=zero --enable-openjdk-only \ >>>> --with-freetype-include=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/freetype2\ >>>> >>>> >>>> --with-freetype-lib=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib\ >>>> >>>> >>>> --with-freetype=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/\ >>>> >>>> >>>> --with-debug-level=release >>>> --openjdk-target=arm-buildroot-linux-gnueabi \ >>>> --with-sys-root=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot\ >>>> >>>> >>>> --with-tools-dir=~/linux/buildroot-openjdk8/output/host \ >>>> --disable-freetype-bundling --enable-unlimited-crypto >>>> --disable-headful\ >>>> OBJCOPY=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-objcopy >>>> >>>> >>>> STRIP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-strip >>>> >>>> >>>> CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ >>>> CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ >>>> >>>> >>>> CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ >>>> >>>> >>>> CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >>>> >>>> LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >>>> >>>> BUILD_CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ >>>> >>>> >>>> BUILD_CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ >>>> >>>> >>>> BUILD_CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ >>>> >>>> >>>> BUILD_LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>>> >>>> >>>> >>>> The configure script seems to have some bug that it can't locate the >>>> compiler properly: >>>> >>>> ... >>>> checking for cl... >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>>> >>>> >>>> configure: Resolving BUILD_CC (as >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) >>>> >>>> faile >>>> d, using >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>>> >>>> directly. >>>> checking for cl... >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ >>>> >>>> >>>> configure: Resolving BUILD_CXX (as >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++) >>>> >>>> fail >>>> ed, using >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ >>>> >>>> directly. >>>> checking for ld... >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>>> >>>> >>>> configure: Resolving BUILD_LD (as >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) >>>> >>>> faile >>>> d, using >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc >>>> >>>> directly. >>>> checking for >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... >>>> >>>> no >>>> checking for >>>> /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... >>>> >>>> no >>>> configure: error: Could not find a C compiler. You might be able to >>>> fix this by running 'sudo apt-get install build-ess >>>> ential'. >>>> configure exiting with result code 1 >>>> ... >>>> >>>> Those files that it claims "no" do exist and they are indeed a GCC >>>> crosscompiler. >>>> The same parameters work for OpenJDK 9 (it does find the compiler). >>>> >>>> How can I resolve this issue? >>>> >>>> Thanks >>>> Bruno Kremel >>>> From abhi.saha at oracle.com Tue Apr 18 20:25:40 2017 From: abhi.saha at oracle.com (Abhijit Saha) Date: Tue, 18 Apr 2017 13:25:40 -0700 Subject: [8u] Request for approval for bulk changes from Apr 2017 CPU 8u131 fixes into 8u Message-ID: <6398cd44-2238-47da-c44b-e4bf904eea26@oracle.com> 8u131 has been released earlier today [1]. Requesting approval to sync up the 8u131 changes into the jdk8u forest. webrev : http://cr.openjdk.java.net/~asaha/openJDK.8u131-8u152.sync/webrev Thanks Abhijit [1] http://www.oracle.com/technetwork/java/javase/downloads/index.html -- Java Platform Group Oracle Corporation. (408)276-7564 From dalibor.topic at oracle.com Tue Apr 18 21:27:27 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 18 Apr 2017 23:27:27 +0200 Subject: [8u] Request for approval for bulk changes from Apr 2017 CPU 8u131 fixes into 8u In-Reply-To: <6398cd44-2238-47da-c44b-e4bf904eea26@oracle.com> References: <6398cd44-2238-47da-c44b-e4bf904eea26@oracle.com> Message-ID: Thanks, Abhijit - approved! cheers, dalibor topic On 18.04.2017 22:25, Abhijit Saha wrote: > 8u131 has been released earlier today [1]. Requesting approval to sync > up the 8u131 changes into the jdk8u forest. > > webrev : http://cr.openjdk.java.net/~asaha/openJDK.8u131-8u152.sync/webrev > > > Thanks > Abhijit > > > [1] http://www.oracle.com/technetwork/java/javase/downloads/index.html > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From rob.mckenna at oracle.com Wed Apr 19 12:48:30 2017 From: rob.mckenna at oracle.com (Robert Mckenna (rob.mckenna@oracle.com)) Date: Wed, 19 Apr 2017 13:48:30 +0100 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <8b90e51d-1914-471e-aa34-0675146b3ebc@default> References: <20170330141709.GB3771@vimes> <8b90e51d-1914-471e-aa34-0675146b3ebc@default> Message-ID: <20170419124830.GB2755@vimes> Thanks Shafi, this has been approved. -Rob On 16/04/17 10:06, Shafi Ahmad wrote: > Hi, > > This changes required to improve the ability to diagnose issues in large projects. > The information is available it is just that it is not being emitted in the exception message. > This should fall under improvements to serviceability. > > So may I get the approval of enhancement backport of 'JDK-8171194 to jdk8u-dev. > > The enhancement backport request id is https://bugs.openjdk.java.net/browse/JDK-8176800 > > Regards, > Shafi > > > -----Original Message----- > > From: Rob McKenna > > Sent: Thursday, March 30, 2017 7:47 PM > > To: Shafi Ahmad > > Cc: jdk8u-dev at openjdk.java.net > > Subject: Re: [8u] Request for enhancement backport approval for CR JDK- > > 8171194: Exception "Duplicate field name&signature in class file" should > > report the name and signature of the field > > > > Hi Shafi, > > > > This request has been rejected by the PM as: > > > > "There isn't any justification as to why this shouldn't simply be done on the > > next major release but should also be backported to already released > > versions" > > > > It may help to update the justification in this thread focusing on the > > servicability aspects and the impact on older releases. > > > > -Rob > > > > On 29/03/17 11:46, Shafi Ahmad wrote: > > > Hi, > > > > > > May I get the approval of enhancement backport of 'JDK-8171194: > > Exception "Duplicate field name&signature in class file" should report the > > name and signature of the field' to jdk8u-dev. > > > > > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 > > > > > > "java.lang.ClassFormatError: Duplicate field name&signature in class file > > CampaignClient" > > > > > > From the above Exception message, it is difficult of knowing what is > > triggering the problem. > > > If the class in question is quite big so removing code by trial and error is > > very time consuming. > > > > > > With field name + signature, pinpointing the actual problematic code will be > > easy and time saving. > > > > > > I have tested it with the jprt and jtreg tests. > > > > > > Please note the original bug was raised against jdk8u. > > > > > > Regards, > > > Shafi > > > From bruno.rosa at eldorado.org.br Wed Apr 19 16:42:30 2017 From: bruno.rosa at eldorado.org.br (Bruno Alexandre Rosa) Date: Wed, 19 Apr 2017 16:42:30 +0000 Subject: FW: Backport performance enhancement to jdk8 Message-ID: <4c9892e2601e40acb972162097a0f8a7@serv030.corp.eldorado.org.br> Forwarding the discussion here. Regards, Bruno Rosa > From: Bruno Alexandre Rosa > Sent: quarta-feira, 12 de abril de 2017 16:23 > To: 'ppc-aix-port-dev at openjdk.java.net' > Subject: Backport performance enhancement to jdk8 > Hi, everyone, > > Recently our team implemented the missing mulAdd and squareToLen intrinsics on ppc64. Our initial approach does not use vector instructions, but we are also looking into that. > Running SPECjvm2008's crypto.rsa benchmark on jdk9 we got around 4% performance gain. Backporting it to jdk8 we noticed a more remarkable ~56% gain. > > We think that this gain justifies a backport. However, we are also aware that patches are backported mainly when they address bugfixes. Would this be acceptable for the community? > > Regards, > Bruno Rosa From david.holmes at oracle.com Thu Apr 20 01:04:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Apr 2017 11:04:53 +1000 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <20170419124830.GB2755@vimes> References: <20170330141709.GB3771@vimes> <8b90e51d-1914-471e-aa34-0675146b3ebc@default> <20170419124830.GB2755@vimes> Message-ID: <816452ad-cb03-17c4-2fb7-6aedc43080f4@oracle.com> On 19/04/2017 10:48 PM, Robert Mckenna (rob.mckenna at oracle.com) wrote: > Thanks Shafi, this has been approved. To be clear this is the enhancement approval, push approval still has to be requested - right? Thanks, David > -Rob > > On 16/04/17 10:06, Shafi Ahmad wrote: >> Hi, >> >> This changes required to improve the ability to diagnose issues in large projects. >> The information is available it is just that it is not being emitted in the exception message. >> This should fall under improvements to serviceability. >> >> So may I get the approval of enhancement backport of 'JDK-8171194 to jdk8u-dev. >> >> The enhancement backport request id is https://bugs.openjdk.java.net/browse/JDK-8176800 >> >> Regards, >> Shafi >> >>> -----Original Message----- >>> From: Rob McKenna >>> Sent: Thursday, March 30, 2017 7:47 PM >>> To: Shafi Ahmad >>> Cc: jdk8u-dev at openjdk.java.net >>> Subject: Re: [8u] Request for enhancement backport approval for CR JDK- >>> 8171194: Exception "Duplicate field name&signature in class file" should >>> report the name and signature of the field >>> >>> Hi Shafi, >>> >>> This request has been rejected by the PM as: >>> >>> "There isn't any justification as to why this shouldn't simply be done on the >>> next major release but should also be backported to already released >>> versions" >>> >>> It may help to update the justification in this thread focusing on the >>> servicability aspects and the impact on older releases. >>> >>> -Rob >>> >>> On 29/03/17 11:46, Shafi Ahmad wrote: >>>> Hi, >>>> >>>> May I get the approval of enhancement backport of 'JDK-8171194: >>> Exception "Duplicate field name&signature in class file" should report the >>> name and signature of the field' to jdk8u-dev. >>>> >>>> Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 >>>> >>>> "java.lang.ClassFormatError: Duplicate field name&signature in class file >>> CampaignClient" >>>> >>>> From the above Exception message, it is difficult of knowing what is >>> triggering the problem. >>>> If the class in question is quite big so removing code by trial and error is >>> very time consuming. >>>> >>>> With field name + signature, pinpointing the actual problematic code will be >>> easy and time saving. >>>> >>>> I have tested it with the jprt and jtreg tests. >>>> >>>> Please note the original bug was raised against jdk8u. >>>> >>>> Regards, >>>> Shafi >>>> From shafi.s.ahmad at oracle.com Thu Apr 20 03:55:48 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 19 Apr 2017 20:55:48 -0700 (PDT) Subject: [8u] RFA JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field Message-ID: <370e492a-66a1-42c8-acd0-a737d70b1e1a@default> Hi, May I get the approval of backport of 'JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field' to jdk8u. Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 Jdk10 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-February/025922.html Jdk8 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026136.html Enhancement request approval thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-April/006582.html Regards, Shafi From david.buck at oracle.com Thu Apr 20 07:04:20 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 20 Apr 2017 16:04:20 +0900 Subject: [8u] RFA JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <370e492a-66a1-42c8-acd0-a737d70b1e1a@default> References: <370e492a-66a1-42c8-acd0-a737d70b1e1a@default> Message-ID: <0cb77223-58a6-d831-8181-2afe358e1fdc@oracle.com> Hi! approved for push to 8u-dev The push should be based on the webrev from the 8u-dev code review: http://cr.openjdk.java.net/~shshahma/8176150/webrev.00/ Cheers, -Buck On 2017/04/20 12:55, Shafi Ahmad wrote: > Hi, > > May I get the approval of backport of 'JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field' to jdk8u. > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 > Jdk10 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-February/025922.html > Jdk8 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026136.html > Enhancement request approval thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-April/006582.html > > Regards, > Shafi > From rob.mckenna at oracle.com Thu Apr 20 12:47:47 2017 From: rob.mckenna at oracle.com (Robert Mckenna (rob.mckenna@oracle.com)) Date: Thu, 20 Apr 2017 13:47:47 +0100 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <816452ad-cb03-17c4-2fb7-6aedc43080f4@oracle.com> References: <20170330141709.GB3771@vimes> <8b90e51d-1914-471e-aa34-0675146b3ebc@default> <20170419124830.GB2755@vimes> <816452ad-cb03-17c4-2fb7-6aedc43080f4@oracle.com> Message-ID: <20170420124747.GA3866@vimes> Yes, as per the enhancement approval process. I should state that explicitly from now on. Thanks, -Rob On 20/04/17 11:04, David Holmes wrote: > On 19/04/2017 10:48 PM, Robert Mckenna (rob.mckenna at oracle.com) wrote: > >Thanks Shafi, this has been approved. > > To be clear this is the enhancement approval, push approval still has to be > requested - right? > > Thanks, > David > > > -Rob > > > >On 16/04/17 10:06, Shafi Ahmad wrote: > >>Hi, > >> > >>This changes required to improve the ability to diagnose issues in large projects. > >>The information is available it is just that it is not being emitted in the exception message. > >>This should fall under improvements to serviceability. > >> > >>So may I get the approval of enhancement backport of 'JDK-8171194 to jdk8u-dev. > >> > >>The enhancement backport request id is https://bugs.openjdk.java.net/browse/JDK-8176800 > >> > >>Regards, > >>Shafi > >> > >>>-----Original Message----- > >>>From: Rob McKenna > >>>Sent: Thursday, March 30, 2017 7:47 PM > >>>To: Shafi Ahmad > >>>Cc: jdk8u-dev at openjdk.java.net > >>>Subject: Re: [8u] Request for enhancement backport approval for CR JDK- > >>>8171194: Exception "Duplicate field name&signature in class file" should > >>>report the name and signature of the field > >>> > >>>Hi Shafi, > >>> > >>>This request has been rejected by the PM as: > >>> > >>>"There isn't any justification as to why this shouldn't simply be done on the > >>>next major release but should also be backported to already released > >>>versions" > >>> > >>>It may help to update the justification in this thread focusing on the > >>>servicability aspects and the impact on older releases. > >>> > >>> -Rob > >>> > >>>On 29/03/17 11:46, Shafi Ahmad wrote: > >>>>Hi, > >>>> > >>>>May I get the approval of enhancement backport of 'JDK-8171194: > >>>Exception "Duplicate field name&signature in class file" should report the > >>>name and signature of the field' to jdk8u-dev. > >>>> > >>>>Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 > >>>> > >>>>"java.lang.ClassFormatError: Duplicate field name&signature in class file > >>>CampaignClient" > >>>> > >>>>From the above Exception message, it is difficult of knowing what is > >>>triggering the problem. > >>>>If the class in question is quite big so removing code by trial and error is > >>>very time consuming. > >>>> > >>>>With field name + signature, pinpointing the actual problematic code will be > >>>easy and time saving. > >>>> > >>>>I have tested it with the jprt and jtreg tests. > >>>> > >>>>Please note the original bug was raised against jdk8u. > >>>> > >>>>Regards, > >>>>Shafi > >>>> From akashche at redhat.com Tue Apr 25 14:16:42 2017 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 25 Apr 2017 15:16:42 +0100 Subject: [8u-dev] Request for Approval: Backport of 8035653: InetAddress.getLocalHost crash Message-ID: Hi, Could you please approve a backport of 8035653 to jdk8u-dev? webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8035653/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8035653 jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8e5e92e0530e original review thread: http://mail.openjdk.java.net/pipermail/net-dev/2014-February/008276.html backport review thread: http://mail.openjdk.java.net/pipermail/net-dev/2017-April/010729.html Patch from jdk9/dev does not apply cleanly, change to DualStackPlainDatagramSocketImpl.java was already added to jdk8 as part of 8072466 [1][2]. This patch brings changes to DualStackPlainDatagramSocketImpl.c and also includes B8035653.java test. [1] https://bugs.openjdk.java.net/browse/JDK-8072466 [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3623f1b29b58#l7.1 -- -Alex From rob.mckenna at oracle.com Tue Apr 25 14:48:51 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 25 Apr 2017 15:48:51 +0100 Subject: [8u-dev] Request for Approval: Backport of 8035653: InetAddress.getLocalHost crash In-Reply-To: References: Message-ID: <20170425144851.GA2745@vimes> Approved -Rob On 25/04/17 03:16, Alex Kashchenko wrote: > Hi, > > Could you please approve a backport of 8035653 to jdk8u-dev? > > webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8035653/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8035653 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8e5e92e0530e > original review thread: > http://mail.openjdk.java.net/pipermail/net-dev/2014-February/008276.html > backport review thread: > http://mail.openjdk.java.net/pipermail/net-dev/2017-April/010729.html > > Patch from jdk9/dev does not apply cleanly, change to > DualStackPlainDatagramSocketImpl.java was already added to jdk8 as part of > 8072466 [1][2]. > > This patch brings changes to DualStackPlainDatagramSocketImpl.c and also > includes B8035653.java test. > > [1] https://bugs.openjdk.java.net/browse/JDK-8072466 > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3623f1b29b58#l7.1 > > -- > -Alex From akashche at redhat.com Tue Apr 25 15:34:23 2017 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 25 Apr 2017 16:34:23 +0100 Subject: [8u-dev] Request for Approval: Backport of 8035653: InetAddress.getLocalHost crash In-Reply-To: <20170425144851.GA2745@vimes> References: <20170425144851.GA2745@vimes> Message-ID: <70fd516a-3127-769b-0ef1-1f14af33f7d0@redhat.com> Hi, On 04/25/2017 03:48 PM, Rob McKenna wrote: > Approved The sponsor is required to prepare the changeset (I am not an Author in jdk8u) and push it. It is not clear whether "Contributed-by:" is added to backports, if it is - may I ask the sponsor to include mvala at redhat.com there. Thanks! > > -Rob > > On 25/04/17 03:16, Alex Kashchenko wrote: >> Hi, >> >> Could you please approve a backport of 8035653 to jdk8u-dev? >> >> webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8035653/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8035653 >> jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8e5e92e0530e >> original review thread: >> http://mail.openjdk.java.net/pipermail/net-dev/2014-February/008276.html >> backport review thread: >> http://mail.openjdk.java.net/pipermail/net-dev/2017-April/010729.html >> >> Patch from jdk9/dev does not apply cleanly, change to >> DualStackPlainDatagramSocketImpl.java was already added to jdk8 as part of >> 8072466 [1][2]. >> >> This patch brings changes to DualStackPlainDatagramSocketImpl.c and also >> includes B8035653.java test. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8072466 >> [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3623f1b29b58#l7.1 >> >> -- >> -Alex -- -Alex From christoph.langer at sap.com Wed Apr 26 06:42:11 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Apr 2017 06:42:11 +0000 Subject: [8u-dev] Request for Approval: Backport of 8035653: InetAddress.getLocalHost crash In-Reply-To: <70fd516a-3127-769b-0ef1-1f14af33f7d0@redhat.com> References: <20170425144851.GA2745@vimes> <70fd516a-3127-769b-0ef1-1f14af33f7d0@redhat.com> Message-ID: <88a9b942a3744672807a84445660a207@sap.com> Hi Alex, I'll push this for you. As it is a backport and does not contain additional changes, I'll keep the original author. Best regards Christoph > -----Original Message----- > From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf > Of Alex Kashchenko > Sent: Dienstag, 25. April 2017 17:34 > To: jdk8u-dev at openjdk.java.net > Subject: Re: [8u-dev] Request for Approval: Backport of 8035653: > InetAddress.getLocalHost crash > > Hi, > > On 04/25/2017 03:48 PM, Rob McKenna wrote: > > Approved > > The sponsor is required to prepare the changeset (I am not an Author in > jdk8u) and push it. It is not clear whether "Contributed-by:" is added > to backports, if it is - may I ask the sponsor to include > mvala at redhat.com there. Thanks! > > > > > -Rob > > > > On 25/04/17 03:16, Alex Kashchenko wrote: > >> Hi, > >> > >> Could you please approve a backport of 8035653 to jdk8u-dev? > >> > >> webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8035653/webrev.00/ > >> bug: https://bugs.openjdk.java.net/browse/JDK-8035653 > >> jdk9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8e5e92e0530e > >> original review thread: > >> http://mail.openjdk.java.net/pipermail/net-dev/2014- > February/008276.html > >> backport review thread: > >> http://mail.openjdk.java.net/pipermail/net-dev/2017-April/010729.html > >> > >> Patch from jdk9/dev does not apply cleanly, change to > >> DualStackPlainDatagramSocketImpl.java was already added to jdk8 as part > of > >> 8072466 [1][2]. > >> > >> This patch brings changes to DualStackPlainDatagramSocketImpl.c and also > >> includes B8035653.java test. > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8072466 > >> [2] http://hg.openjdk.java.net/jdk8u/jdk8u- > dev/jdk/rev/3623f1b29b58#l7.1 > >> > >> -- > >> -Alex > > > -- > -Alex From shafi.s.ahmad at oracle.com Wed Apr 26 10:29:15 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 26 Apr 2017 03:29:15 -0700 (PDT) Subject: [8u] RFA for JDK-8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking Message-ID: <2535a9e7-0e00-4460-8dda-7f1a9c41ba8c@default> Hi, May I get the approval of backport of JDK-8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking' to jdk8u. Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8168914 Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-February/025880.html Jdk8 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-April/026696.html Wbrev link: http://cr.openjdk.java.net/~shshahma/8168914/webrev.01/ Regards, Shafi From david.buck at oracle.com Wed Apr 26 10:38:45 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 26 Apr 2017 19:38:45 +0900 Subject: [8u] RFA for JDK-8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking In-Reply-To: <2535a9e7-0e00-4460-8dda-7f1a9c41ba8c@default> References: <2535a9e7-0e00-4460-8dda-7f1a9c41ba8c@default> Message-ID: <91C80424-6137-4621-ADF6-FACB51501189@oracle.com> approved for push to 8u-dev Cheers, -Buck > On Apr 26, 2017, at 19:29, Shafi Ahmad wrote: > > Hi, > > May I get the approval of backport of JDK-8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking' to jdk8u. > > Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8168914 > Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-February/025880.html > Jdk8 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-April/026696.html > Wbrev link: http://cr.openjdk.java.net/~shshahma/8168914/webrev.01/ > > Regards, > Shafi From shafi.s.ahmad at oracle.com Wed Apr 26 12:19:07 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 26 Apr 2017 05:19:07 -0700 (PDT) Subject: [8u] RFA for JDK-8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking In-Reply-To: <91C80424-6137-4621-ADF6-FACB51501189@oracle.com> References: <2535a9e7-0e00-4460-8dda-7f1a9c41ba8c@default> <91C80424-6137-4621-ADF6-FACB51501189@oracle.com> Message-ID: <13361eb9-68b8-403b-947a-472f33c1bcd8@default> Thank you Buck. Regards, Shafi > -----Original Message----- > From: David Buck > Sent: Wednesday, April 26, 2017 4:09 PM > To: Shafi Ahmad > Cc: jdk8u-dev at openjdk.java.net > Subject: Re: [8u] RFA for JDK-8168914: Crash in > ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking > > approved for push to 8u-dev > > Cheers, > -Buck > > > On Apr 26, 2017, at 19:29, Shafi Ahmad > wrote: > > > > Hi, > > > > May I get the approval of backport of JDK-8168914: Crash in > ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking' to > jdk8u. > > > > Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8168914 > > Jdk9 review thread: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-February/02588 > > 0.html > > Jdk8 review thread: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-April/026696.h > > tml Wbrev link: > > http://cr.openjdk.java.net/~shshahma/8168914/webrev.01/ > > > > Regards, > > Shafi > From brent.christian at oracle.com Wed Apr 26 16:39:26 2017 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 26 Apr 2017 09:39:26 -0700 Subject: [8u] Request for enhancement backport approval for CR 8176329 - jdeps to detect MR jar file and output a warning Message-ID: Hi, I would like to add the following small enhancement to 8u: "jdeps to detect MR jar file and output a warning" https://bugs.openjdk.java.net/browse/JDK-8176329 Rationale: If the 8u version of jdeps encounters a Multi-Release jar, the user should be warned that the JDK 9 version of jdeps should be used instead. The only change is to the jdeps tool itself (no change to the runtime). The change is low risk and very localized to check an input JAR file for the "Multi-Release" attribute. Thanks, -Brent From brent.christian at oracle.com Wed Apr 26 21:27:45 2017 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 26 Apr 2017 14:27:45 -0700 Subject: [8u] RFR 8176329 - jdeps to detect MR jar file and output a warning Message-ID: <4b19406a-ac3d-5426-f0c1-b8abc9230703@oracle.com> Hi, Please review the following change to 8u. If the 8u version of jdeps encounters a Multi-Release jar, the user should be warned that the JDK 9 version of jdeps should be used instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8176329 Webrev: http://cr.openjdk.java.net/~bchristi/8176329/webrev.04/ Thanks, -Brent From dalibor.topic at oracle.com Wed Apr 26 21:34:09 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 26 Apr 2017 23:34:09 +0200 Subject: [8u] Request for enhancement backport approval for CR 8176329 - jdeps to detect MR jar file and output a warning In-Reply-To: References: Message-ID: Thanks, Brent. This enhancement request is approved. Please proceed with the backport and send a push approval request to this mailing list when the backport ready for review and/or approval. cheers, dalibor topic On 26.04.2017 18:39, Brent Christian wrote: > Hi, > > I would like to add the following small enhancement to 8u: > > "jdeps to detect MR jar file and output a warning" > > https://bugs.openjdk.java.net/browse/JDK-8176329 > > Rationale: > If the 8u version of jdeps encounters a Multi-Release jar, the user > should be warned that the JDK 9 version of jdeps should be used instead. > > The only change is to the jdeps tool itself (no change to the runtime). > The change is low risk and very localized to check an input JAR file for > the "Multi-Release" attribute. > > > Thanks, > -Brent -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From mandy.chung at oracle.com Wed Apr 26 21:56:48 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 26 Apr 2017 14:56:48 -0700 Subject: [8u] RFR 8176329 - jdeps to detect MR jar file and output a warning In-Reply-To: <4b19406a-ac3d-5426-f0c1-b8abc9230703@oracle.com> References: <4b19406a-ac3d-5426-f0c1-b8abc9230703@oracle.com> Message-ID: <1D5BABC3-C796-41A0-9162-07A8FC2AE2FE@oracle.com> > On Apr 26, 2017, at 2:27 PM, Brent Christian wrote: > > Hi, > > Please review the following change to 8u. > > If the 8u version of jdeps encounters a Multi-Release jar, the user should be warned that the JDK 9 version of jdeps should be used instead. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8176329 > > Webrev: > http://cr.openjdk.java.net/~bchristi/8176329/webrev.04/ 303 if ("true".equalsIgnoreCase(atts.getValue("Multi-Release"))) { 304 return true; 305 } This can be simplified to return "true".equalsIgnoreCase(atts.getValue("Multi-Release?)); MRJarWarning.java test 66 defaultAttributes.putValue("Created-By", "1.8.0-internal (Oracle Corporation)"); I suggest to drop ?(Oracle?)? 82 // jdeps still recognizes a mult-release jar. typo: s/mult/multi Otherwise looks good. Mandy From mikhail.cherkasov at oracle.com Thu Apr 27 18:13:05 2017 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Thu, 27 Apr 2017 21:13:05 +0300 Subject: [8u-dev] Request for Approval: Backport of 8160893: [macosx] JMenuItems in JPopupMenu are not accessible Message-ID: Hi all, Could you please approve a backport of 8160893 to jdk8? jbs: https://bugs.openjdk.java.net/browse/JDK-8160893 backport review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2017-April/007328.html webrev: http://cr.openjdk.java.net/~mcherkas/8160893/webrev/ jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/e5be7a186fcc hread for jdk9: http://mail.openjdk.java.net/pipermail/swing-dev/2016-September/006701.html Thanks, Mikhail. From brent.christian at oracle.com Thu Apr 27 20:10:56 2017 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 27 Apr 2017 13:10:56 -0700 Subject: [8u] RFR 8176329 - jdeps to detect MR jar file and output a warning In-Reply-To: <1D5BABC3-C796-41A0-9162-07A8FC2AE2FE@oracle.com> References: <4b19406a-ac3d-5426-f0c1-b8abc9230703@oracle.com> <1D5BABC3-C796-41A0-9162-07A8FC2AE2FE@oracle.com> Message-ID: <41387545-fd01-0d3e-6634-3dc441ef08c4@oracle.com> Thanks, Mandy. I've incorporated your suggestions. -Brent On 4/26/17 2:56 PM, Mandy Chung wrote: > >> On Apr 26, 2017, at 2:27 PM, Brent Christian wrote: >> >> Hi, >> >> Please review the following change to 8u. >> >> If the 8u version of jdeps encounters a Multi-Release jar, the user should be warned that the JDK 9 version of jdeps should be used instead. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8176329 >> >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8176329/webrev.04/ > > 303 if ("true".equalsIgnoreCase(atts.getValue("Multi-Release"))) { > 304 return true; > 305 } > > This can be simplified to > return "true".equalsIgnoreCase(atts.getValue("Multi-Release?)); > > MRJarWarning.java test > 66 defaultAttributes.putValue("Created-By", "1.8.0-internal (Oracle Corporation)"); > > I suggest to drop ?(Oracle?)? > > 82 // jdeps still recognizes a mult-release jar. > > typo: s/mult/multi > > Otherwise looks good. > > Mandy > From brent.christian at oracle.com Thu Apr 27 20:28:47 2017 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 27 Apr 2017 13:28:47 -0700 Subject: [8u] Request for approval for CR 8176329 - jdeps to detect MR jar file and output a warning Message-ID: Hi, I am requesting approval to push my changes for 8176329 - "jdeps to detect MR jar file and output a warning". Bug: https://bugs.openjdk.java.net/browse/JDK-8176329 Webrev: http://cr.openjdk.java.net/~bchristi/8176329/webrev.05/ Review thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-April/006602.html Along with the new MR jar warning message, the change also updates messages for the "-jdkinternals" option, as suggested by Mandy in the bug report. Thanks, -Brent From christoph.langer at sap.com Thu Apr 27 21:31:12 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 27 Apr 2017 21:31:12 +0000 Subject: [8u-dev] Request for Approval: Backport of 8035653: InetAddress.getLocalHost crash In-Reply-To: <88a9b942a3744672807a84445660a207@sap.com> References: <20170425144851.GA2745@vimes> <70fd516a-3127-769b-0ef1-1f14af33f7d0@redhat.com> <88a9b942a3744672807a84445660a207@sap.com> Message-ID: <77283f76686a45d297fb66db2c823778@sap.com> Hi Alex, I pushed it: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/f08a4bccd723 Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 26. April 2017 08:42 > To: 'Alex Kashchenko' > Cc: jdk8u-dev at openjdk.java.net > Subject: RE: [8u-dev] Request for Approval: Backport of 8035653: > InetAddress.getLocalHost crash > > Hi Alex, > > I'll push this for you. > > As it is a backport and does not contain additional changes, I'll keep the > original author. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk8u-dev [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf > > Of Alex Kashchenko > > Sent: Dienstag, 25. April 2017 17:34 > > To: jdk8u-dev at openjdk.java.net > > Subject: Re: [8u-dev] Request for Approval: Backport of 8035653: > > InetAddress.getLocalHost crash > > > > Hi, > > > > On 04/25/2017 03:48 PM, Rob McKenna wrote: > > > Approved > > > > The sponsor is required to prepare the changeset (I am not an Author in > > jdk8u) and push it. It is not clear whether "Contributed-by:" is added > > to backports, if it is - may I ask the sponsor to include > > mvala at redhat.com there. Thanks! > > > > > > > > -Rob > > > > > > On 25/04/17 03:16, Alex Kashchenko wrote: > > >> Hi, > > >> > > >> Could you please approve a backport of 8035653 to jdk8u-dev? > > >> > > >> webrev: > http://cr.openjdk.java.net/~akasko/jdk8u/8035653/webrev.00/ > > >> bug: https://bugs.openjdk.java.net/browse/JDK-8035653 > > >> jdk9 changeset: > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8e5e92e0530e > > >> original review thread: > > >> http://mail.openjdk.java.net/pipermail/net-dev/2014- > > February/008276.html > > >> backport review thread: > > >> http://mail.openjdk.java.net/pipermail/net-dev/2017- > April/010729.html > > >> > > >> Patch from jdk9/dev does not apply cleanly, change to > > >> DualStackPlainDatagramSocketImpl.java was already added to jdk8 as > part > > of > > >> 8072466 [1][2]. > > >> > > >> This patch brings changes to DualStackPlainDatagramSocketImpl.c and > also > > >> includes B8035653.java test. > > >> > > >> [1] https://bugs.openjdk.java.net/browse/JDK-8072466 > > >> [2] http://hg.openjdk.java.net/jdk8u/jdk8u- > > dev/jdk/rev/3623f1b29b58#l7.1 > > >> > > >> -- > > >> -Alex > > > > > > -- > > -Alex From rob.mckenna at oracle.com Thu Apr 27 23:09:52 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 28 Apr 2017 00:09:52 +0100 Subject: [8u] Request for approval for CR 8176329 - jdeps to detect MR jar file and output a warning In-Reply-To: References: Message-ID: <20170427230952.GB3273@tecra> Approved -Rob On 27/04/17 01:28, Brent Christian wrote: > Hi, > > I am requesting approval to push my changes for 8176329 - "jdeps to detect > MR jar file and output a warning". > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8176329 > > Webrev: > http://cr.openjdk.java.net/~bchristi/8176329/webrev.05/ > > Review thread: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-April/006602.html > > Along with the new MR jar warning message, the change also updates messages > for the "-jdkinternals" option, as suggested by Mandy in the bug report. > > Thanks, > -Brent From rob.mckenna at oracle.com Thu Apr 27 23:12:03 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 28 Apr 2017 00:12:03 +0100 Subject: [8u-dev] Request for Approval: Backport of 8160893: [macosx] JMenuItems in JPopupMenu are not accessible In-Reply-To: References: Message-ID: <20170427231203.GC3273@tecra> Approved -Rob On 27/04/17 09:13, Mikhail Cherkasov wrote: > Hi all, > > Could you please approve a backport of 8160893 to jdk8? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8160893 > backport review thread: > http://mail.openjdk.java.net/pipermail/swing-dev/2017-April/007328.html > webrev: http://cr.openjdk.java.net/~mcherkas/8160893/webrev/ > > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/e5be7a186fcc > hread for jdk9: > http://mail.openjdk.java.net/pipermail/swing-dev/2016-September/006701.html > > > > Thanks, > Mikhail. From david.holmes at oracle.com Fri Apr 28 06:13:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Apr 2017 16:13:08 +1000 Subject: [8u] Request for Approval: 8179084: HotSpot VM fails to start when AggressiveHeap is set Message-ID: <56621484-6457-fbd1-a88a-331d186e2b30@oracle.com> Please approve. This fixes a regression introduced in 8u131. Bug: https://bugs.openjdk.java.net/browse/JDK-8179084 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f1cca489e9c6 The functional part of the patch applied cleanly, just at different line numbers. The test had to be adjusted for the 8u environment and so was re-reviewed here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-April/026727.html Thanks, David From rob.mckenna at oracle.com Fri Apr 28 19:11:20 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 28 Apr 2017 20:11:20 +0100 Subject: [8u] Request for Approval: 8179084: HotSpot VM fails to start when AggressiveHeap is set In-Reply-To: <56621484-6457-fbd1-a88a-331d186e2b30@oracle.com> References: <56621484-6457-fbd1-a88a-331d186e2b30@oracle.com> Message-ID: <20170428191120.GA12115@vimes> Approved -Rob On 28/04/17 04:13, David Holmes wrote: > Please approve. This fixes a regression introduced in 8u131. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179084 > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/f1cca489e9c6 > > The functional part of the patch applied cleanly, just at different line > numbers. > > The test had to be adjusted for the 8u environment and so was re-reviewed > here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-April/026727.html > > Thanks, > David > > > > >