From mikhail.cherkasov at oracle.com Thu Dec 1 12:25:36 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Thu, 1 Dec 2016 15:25:36 +0300 Subject: [8u] request for approval: 8076554: [macosx] Custom Swing text components need to allow standard accessibility Message-ID: Hi, it's a direct backport from jdk9 to jdk8: webrev:http://cr.openjdk.java.net/~mcherkas/8076554/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8076554 jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d5322b45852d jdk9 review: http://mail.openjdk.java.net/pipermail/swing-dev/2016-April/005762.html Thanks, Mikhail. From david.buck at oracle.com Thu Dec 1 12:35:30 2016 From: david.buck at oracle.com (David Buck) Date: Thu, 1 Dec 2016 21:35:30 +0900 Subject: [8u] request for approval: 8076554: [macosx] Custom Swing text components need to allow standard accessibility In-Reply-To: References: Message-ID: <58401912.20507@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2016/12/01 21:25, Mikhail Cherkasov wrote: > Hi, > > it's a direct backport from jdk9 to jdk8: > > webrev:http://cr.openjdk.java.net/~mcherkas/8076554/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8076554 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d5322b45852d > jdk9 review: > http://mail.openjdk.java.net/pipermail/swing-dev/2016-April/005762.html > > Thanks, > Mikhail. From szegedia at gmail.com Thu Dec 1 13:37:57 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 1 Dec 2016 14:37:57 +0100 Subject: [8u-dev] Request for Approval: 8170594: >>>=0 generates invalid bytecode for BaseNode LHS Message-ID: <80E3BC92-CC66-4B0D-B517-53DC4918CA9B@gmail.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8170594 jdk9 webrev: http://cr.openjdk.java.net/~attila/8170594/webrev.jdk9 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006686.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From rob.mckenna at oracle.com Thu Dec 1 17:00:54 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 1 Dec 2016 17:00:54 +0000 Subject: [8u-dev] Request for Approval: 8170594: >>>=0 generates invalid bytecode for BaseNode LHS In-Reply-To: <80E3BC92-CC66-4B0D-B517-53DC4918CA9B@gmail.com> References: <80E3BC92-CC66-4B0D-B517-53DC4918CA9B@gmail.com> Message-ID: <20161201170054.GA2790@vimes> Approved -Rob On 01/12/16 02:37, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170594 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8170594/webrev.jdk9 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006686.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. From mikhail.cherkasov at oracle.com Thu Dec 1 17:06:17 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Thu, 1 Dec 2016 20:06:17 +0300 Subject: [8u] request for approval: 8145207 [macosx] JList, VO can't access non-visible list items Message-ID: Hi, it's a direct backport from jdk9 to jdk8: webrev: http://cr.openjdk.java.net/~mcherkas/8145207/webrev/ jbs: https://bugs.openjdk.java.net/browse/JDK-8145207 jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/233b59b7ea2f jdk9 review: http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006312.html Thanks, Mikhail. From rob.mckenna at oracle.com Thu Dec 1 18:33:32 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 1 Dec 2016 18:33:32 +0000 Subject: [8u] request for approval: 8145207 [macosx] JList, VO can't access non-visible list items In-Reply-To: References: Message-ID: <20161201183332.GB2790@vimes> Approved -Rob On 01/12/16 08:06, Mikhail Cherkasov wrote: > Hi, > > it's a direct backport from jdk9 to jdk8: > > webrev: http://cr.openjdk.java.net/~mcherkas/8145207/webrev/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8145207 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/233b59b7ea2f > jdk9 review: > http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006312.html > > Thanks, > Mikhail. From sundararajan.athijegannathan at oracle.com Fri Dec 2 08:09:38 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 2 Dec 2016 13:39:38 +0530 Subject: [8u] approval request for 8170565: JSObject call() is passed undefined for the argument 'thiz' Message-ID: <4b674c89-56f7-699c-c8e7-3a8ecaf43d63@oracle.com> Please approve 8u backport of fix for https://bugs.openjdk.java.net/browse/JDK-8170565 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006670.html jdk8u backport webrev: http://cr.openjdk.java.net/~sundar/8170565/8u/webrev.00/ Backported 'as is' except for the modular source layout difference. Thanks, -Sundar From david.buck at oracle.com Fri Dec 2 10:21:25 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 2 Dec 2016 19:21:25 +0900 Subject: [8u] 8164508: unexpected profiling mismatch in c1 generated code Message-ID: <58414B25.2060105@oracle.com> Hi! Please approve this backport of JDK-8158639 from JDK 9 to 8u-dev. Bug Report: [ 8164508: unexpected profiling mismatch in c1 generated code ] https://bugs.openjdk.java.net/browse/JDK-8164508 8u Code Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-December/025057.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f940af863003 8u-dev Webrev: http://cr.openjdk.java.net/~dbuck/jdk8164508_8u_01/ Testing: Manual verification and JPRT (hotspot testset) Cheers, -Buck From david.buck at oracle.com Fri Dec 2 10:28:08 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 2 Dec 2016 19:28:08 +0900 Subject: [8u] approval request for 8170565: JSObject call() is passed undefined for the argument 'thiz' In-Reply-To: <4b674c89-56f7-699c-c8e7-3a8ecaf43d63@oracle.com> References: <4b674c89-56f7-699c-c8e7-3a8ecaf43d63@oracle.com> Message-ID: <58414CB8.2060007@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2016/12/02 17:09, Sundararajan Athijegannathan wrote: > Please approve 8u backport of fix for > https://bugs.openjdk.java.net/browse/JDK-8170565 > > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006670.html > > jdk8u backport webrev: > http://cr.openjdk.java.net/~sundar/8170565/8u/webrev.00/ > > Backported 'as is' except for the modular source layout difference. > > Thanks, > > -Sundar > From sean.coffey at oracle.com Fri Dec 2 10:33:21 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 2 Dec 2016 10:33:21 +0000 Subject: [8u] 8164508: unexpected profiling mismatch in c1 generated code In-Reply-To: <58414B25.2060105@oracle.com> References: <58414B25.2060105@oracle.com> Message-ID: <58414DF1.5000006@oracle.com> Approved for jdk8u-dev. Regards, Sean. On 02/12/16 10:21, David Buck wrote: > Hi! > > Please approve this backport of JDK-8158639 from JDK 9 to 8u-dev. > > Bug Report: > [ 8164508: unexpected profiling mismatch in c1 generated code ] > https://bugs.openjdk.java.net/browse/JDK-8164508 > > 8u Code Review: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-December/025057.html > > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f940af863003 > > 8u-dev Webrev: > http://cr.openjdk.java.net/~dbuck/jdk8164508_8u_01/ > > Testing: > Manual verification and JPRT (hotspot testset) > > Cheers, > -Buck > > > > From sean.coffey at oracle.com Fri Dec 2 16:10:13 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 2 Dec 2016 16:10:13 +0000 Subject: Result: New JDK 8u Reviewer: Vladimir Ivanov Message-ID: <58419CE5.5030302@oracle.com> Voting for Vladimir Ivanov (vlivanov) [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-November/006138.html Regards, Sean. From bruno.rosa at eldorado.org.br Fri Dec 2 17:42:30 2016 From: bruno.rosa at eldorado.org.br (Bruno Alexandre Rosa) Date: Fri, 2 Dec 2016 17:42:30 +0000 Subject: [8u] Request for enhancement backport approval for "8168318 : PPC64: Use cmpldi instead of li/cmpld" Message-ID: Hi, Thanks to Rob for pointing to the adequate process documentation. On behalf of Igor, I'm submitting an enhancement request that conforms to the process: This changeset adds a new matching rule to the instruction selection phase (adlc) of the ppc vm. It consists of the exchange of the pair li/cmpld with cmpldi. Jtreg hotspot tests didn't regress. Got an 1% performance improvement when benchmarking neo4j. Since the patch is rather small and affects only the ppc vm, the risks are minimal. Please, let us if we are breaking any jdk8u ground rules. Regards, Bruno Rosa Bug: https://bugs.openjdk.java.net/browse/JDK-8168318 Webrev: https://igorsnunes.github.io/openjdk/webrev/8168318/ Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024809.html URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/622d3fe587f2 From mikhail.cherkasov at oracle.com Mon Dec 5 09:17:29 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Mon, 5 Dec 2016 12:17:29 +0300 Subject: [8u] request for approval: 8132209: DiagnosticCommandImpl.getNotificationInfo() may expose internal representation Message-ID: <1065ade2-8cd2-1cce-03d9-68f9fd76b0c1@oracle.com> Everybody, It's a direct backport of one-line fix from jdk9 to jdk8: webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8132209/webrev.01/ jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2a671e5803a1 Thanks, -Dmitry. From dmitry.samersoff at oracle.com Mon Dec 5 09:47:08 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 5 Dec 2016 12:47:08 +0300 Subject: [8u] request for approval: 8132209: DiagnosticCommandImpl.getNotificationInfo() may expose internal representation Message-ID: <45e38179-4649-f352-558a-568ee74f6f0d@oracle.com> Everybody, It's a direct backport of one-line fix from jdk9 to jdk8: webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8132209/webrev.01/ jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2a671e5803a1 Thanks, -Dmitry. From rob.mckenna at oracle.com Mon Dec 5 13:34:08 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 5 Dec 2016 13:34:08 +0000 Subject: [8u] request for approval: 8132209: DiagnosticCommandImpl.getNotificationInfo() may expose internal representation In-Reply-To: <45e38179-4649-f352-558a-568ee74f6f0d@oracle.com> References: <45e38179-4649-f352-558a-568ee74f6f0d@oracle.com> Message-ID: <20161205133408.GA2364@vimes> Approved -Rob On 05/12/16 12:47, Dmitry Samersoff wrote: > Everybody, > > It's a direct backport of one-line fix from jdk9 to jdk8: > > webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8132209/webrev.01/ > > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2a671e5803a1 > > Thanks, > -Dmitry. From poonam.bajaj at oracle.com Mon Dec 5 21:55:50 2016 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Mon, 5 Dec 2016 13:55:50 -0800 Subject: CFV: New jdk8u Committer: Shafi Ahmad Message-ID: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> I hereby nominate Shafi Ahmad (shshahma) to JDK 8u Committer. Shafi is currently a JDK 8u Author, and a member of the JVM Sustaining group at Oracle. He has made many non-trivial contributions to JDK 8u [3]. Votes are due by the end of Dec 19, 2016. Only current JDK 8u Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. regards, Poonam [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3]http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=1000&rev=(keyword(%22shafi.s.ahmad at oracle.com%22)+or+author(shshahma))+and+not+desc(%22Merge%22) From david.buck at oracle.com Mon Dec 5 22:51:35 2016 From: david.buck at oracle.com (David Buck) Date: Tue, 6 Dec 2016 07:51:35 +0900 Subject: CFV: New jdk8u Committer: Shafi Ahmad In-Reply-To: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> References: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> Message-ID: <5845EF77.5000107@oracle.com> vote: YES! Cheers, -Buck On 2016/12/06 6:55, Poonam Bajaj Parhar wrote: > I hereby nominate Shafi Ahmad (shshahma) to JDK 8u Committer. > > Shafi is currently a JDK 8u Author, and a member of the JVM Sustaining > group at Oracle. He has made many non-trivial contributions to JDK 8u > [3]. > > Votes are due by the end of Dec 19, 2016. > > Only current JDK 8u Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Poonam > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=1000&rev=(keyword(%22shafi.s.ahmad at oracle.com%22)+or+author(shshahma))+and+not+desc(%22Merge%22) > From sean.coffey at oracle.com Mon Dec 5 23:56:09 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 5 Dec 2016 23:56:09 +0000 Subject: CFV: New jdk8u Committer: Shafi Ahmad In-Reply-To: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> References: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> Message-ID: <49cb2d83-a440-9564-2beb-4998b5f2d503@oracle.com> Vote: yes regards, Sean. On 05/12/2016 21:55, Poonam Bajaj Parhar wrote: > I hereby nominate Shafi Ahmad (shshahma) to JDK 8u Committer. > > Shafi is currently a JDK 8u Author, and a member of the JVM Sustaining > group at Oracle. He has made many non-trivial contributions to JDK 8u > [3]. > > Votes are due by the end of Dec 19, 2016. > > Only current JDK 8u Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Poonam > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=1000&rev=(keyword(%22shafi.s.ahmad at oracle.com%22)+or+author(shshahma))+and+not+desc(%22Merge%22) > From david.holmes at oracle.com Tue Dec 6 00:46:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Dec 2016 10:46:17 +1000 Subject: CFV: New jdk8u Committer: Shafi Ahmad In-Reply-To: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> References: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> Message-ID: <1e4f0b07-b9e6-6ee6-cdd3-59a78dd3b1e6@oracle.com> Hi Poonam, On 6/12/2016 7:55 AM, Poonam Bajaj Parhar wrote: > I hereby nominate Shafi Ahmad (shshahma) to JDK 8u Committer. > > Shafi is currently a JDK 8u Author, and a member of the JVM Sustaining > group at Oracle. He has made many non-trivial contributions to JDK 8u [3]. Some of these seem to be backports of other people's contributions. Can you isolate Shafi's specific contributions, or where the backport needed a non-trivial adjustment, please. Thanks, David ------ > Votes are due by the end of Dec 19, 2016. > > Only current JDK 8u Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Poonam > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=1000&rev=(keyword(%22shafi.s.ahmad at oracle.com%22)+or+author(shshahma))+and+not+desc(%22Merge%22) > From dmitry.samersoff at oracle.com Tue Dec 6 11:58:05 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 6 Dec 2016 14:58:05 +0300 Subject: [8u] RFR(S): Uninitialized memory in set_uintx_flag of attachListener.cpp Message-ID: Everybody, http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01/ Please, review the fix. The code should return error if op->arg(1) is NULL. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Tue Dec 6 13:05:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Dec 2016 23:05:24 +1000 Subject: [8u] RFR(S): Uninitialized memory in set_uintx_flag of attachListener.cpp In-Reply-To: References: Message-ID: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> On 6/12/2016 9:58 PM, Dmitry Samersoff wrote: > Everybody, > > http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01/ > > Please, review the fix. > > The code should return error if op->arg(1) is NULL. Looks ok. Only minor nit: 274 const char* arg1; 275 276 arg1 = op->arg(1); can be: 274 const char* arg1 = op->arg(1); Oh and copyright year needs updating. Thanks, David > -Dmitry > From dmitry.samersoff at oracle.com Tue Dec 6 13:22:48 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 6 Dec 2016 16:22:48 +0300 Subject: [8u] RFR(S): Uninitialized memory in set_uintx_flag of attachListener.cpp In-Reply-To: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> References: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> Message-ID: <3888e0f3-7cd0-e2ae-2a9e-a3fc7d47f9ef@oracle.com> David, Thank you! -Dmitry On 2016-12-06 16:05, David Holmes wrote: > On 6/12/2016 9:58 PM, Dmitry Samersoff wrote: >> Everybody, >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01/ >> >> Please, review the fix. >> >> The code should return error if op->arg(1) is NULL. > > Looks ok. Only minor nit: > > 274 const char* arg1; > 275 > 276 arg1 = op->arg(1); > > can be: > > 274 const char* arg1 = op->arg(1); > > Oh and copyright year needs updating. > > Thanks, > David > >> -Dmitry >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From poonam.bajaj at oracle.com Tue Dec 6 14:08:15 2016 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Tue, 6 Dec 2016 06:08:15 -0800 Subject: CFV: New jdk8u Committer: Shafi Ahmad In-Reply-To: <1e4f0b07-b9e6-6ee6-cdd3-59a78dd3b1e6@oracle.com> References: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> <1e4f0b07-b9e6-6ee6-cdd3-59a78dd3b1e6@oracle.com> Message-ID: Hello David, Here are the contributions that were made by Shafi: 8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) 8166872: GPL header in /hotspot/src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp 8157548: JVM crashes sometimes while starting 8162419: closed/com/oracle/jfr/runtime/TestVMInfoEvent.sh failing after JDK-8155968 8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) 8156836: SIGSEGV: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 8158373: SIGSEGV: Metadata::mark_on_stack 8147026: Convert an assert in ClassLoaderData to a guarantee 8147451: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) 8150002: Check for the validity of oop before printing it in verify_remembered_set 8144957: Remove PICL warning message 8140249: JVM Crashing During startUp If Flight Recording is enabled and the following was a backport from 9 that required significant work to backport the changes to 8u: 6515172: Runtime.availableProcessors() ignores Linux taskset command Thanks, Poonam On 12/5/2016 4:46 PM, David Holmes wrote: > Hi Poonam, > > On 6/12/2016 7:55 AM, Poonam Bajaj Parhar wrote: >> I hereby nominate Shafi Ahmad (shshahma) to JDK 8u Committer. >> >> Shafi is currently a JDK 8u Author, and a member of the JVM Sustaining >> group at Oracle. He has made many non-trivial contributions to JDK 8u >> [3]. > > Some of these seem to be backports of other people's contributions. > Can you isolate Shafi's specific contributions, or where the backport > needed a non-trivial adjustment, please. > > Thanks, > David > ------ > >> Votes are due by the end of Dec 19, 2016. >> >> Only current JDK 8u Committers [1] are eligible to vote on this >> nomination. >> Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> regards, >> Poonam >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3]http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=1000&rev=(keyword(%22shafi.s.ahmad at oracle.com%22)+or+author(shshahma))+and+not+desc(%22Merge%22) >> >> From serguei.spitsyn at oracle.com Tue Dec 6 23:10:41 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 6 Dec 2016 15:10:41 -0800 Subject: CFV: New jdk8u Committer: Shafi Ahmad In-Reply-To: References: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> <1e4f0b07-b9e6-6ee6-cdd3-59a78dd3b1e6@oracle.com> Message-ID: Vote: yes! From serguei.spitsyn at oracle.com Tue Dec 6 23:16:08 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 6 Dec 2016 15:16:08 -0800 Subject: [8u] RFR(S): Uninitialized memory in set_uintx_flag of attachListener.cpp In-Reply-To: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> References: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> Message-ID: <356562b9-e18d-6752-171f-945650a2941f@oracle.com> Ok++ Thanks, Serguei On 12/6/16 05:05, David Holmes wrote: > On 6/12/2016 9:58 PM, Dmitry Samersoff wrote: >> Everybody, >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01/ >> >> Please, review the fix. >> >> The code should return error if op->arg(1) is NULL. > > Looks ok. Only minor nit: > > 274 const char* arg1; > 275 > 276 arg1 = op->arg(1); > > can be: > > 274 const char* arg1 = op->arg(1); > > Oh and copyright year needs updating. > > Thanks, > David > >> -Dmitry >> From rob.mckenna at oracle.com Wed Dec 7 14:56:16 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 7 Dec 2016 14:56:16 +0000 Subject: CFV: New jdk8u Committer: Shafi Ahmad In-Reply-To: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> References: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> Message-ID: <20161207145616.GB2455@vimes> Vote: yes -Rob On 05/12/16 01:55, Poonam Bajaj Parhar wrote: > I hereby nominate Shafi Ahmad (shshahma) to JDK 8u Committer. > > Shafi is currently a JDK 8u Author, and a member of the JVM Sustaining group > at Oracle. He has made many non-trivial contributions to JDK 8u [3]. > > Votes are due by the end of Dec 19, 2016. > > Only current JDK 8u Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > regards, > Poonam > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3]http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=1000&rev=(keyword(%22shafi.s.ahmad at oracle.com%22)+or+author(shshahma))+and+not+desc(%22Merge%22) > From dmitry.samersoff at oracle.com Wed Dec 7 15:55:39 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 7 Dec 2016 18:55:39 +0300 Subject: [8u] request for approval: JDK-8170536 Uninitialized memory in set_uintx_flag of attachListener.cpp Message-ID: <75457d92-c31f-0f5b-9596-70c6c516c444@oracle.com> Everybody, Please approve 8u-only changes. Webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01 Review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-December/020772.html Thanks, -Dmitry. From naoto.sato at oracle.com Wed Dec 7 19:06:57 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 7 Dec 2016 11:06:57 -0800 Subject: [jdk8u-dev] Request for approval: 8170465, 8170466: JNI exception pending in jni_util.c:190 Message-ID: Hello, Please approve backport of these JDK9 fixes. The changeset applies cleanly after un-shuffling. https://bugs.openjdk.java.net/browse/JDK-8170465 https://bugs.openjdk.java.net/browse/JDK-8170466 JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26c1193265d6 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045255.html Naoto From rob.mckenna at oracle.com Wed Dec 7 19:11:11 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 7 Dec 2016 19:11:11 +0000 Subject: [8u] request for approval: JDK-8170536 Uninitialized memory in set_uintx_flag of attachListener.cpp In-Reply-To: <75457d92-c31f-0f5b-9596-70c6c516c444@oracle.com> References: <75457d92-c31f-0f5b-9596-70c6c516c444@oracle.com> Message-ID: <20161207191111.GA5819@vimes> Please add a suitable noreg label. Approved. -Rob On 07/12/16 06:55, Dmitry Samersoff wrote: > Everybody, > > Please approve 8u-only changes. > > Webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01 > > Review thread: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-December/020772.html > > Thanks, > -Dmitry. From rob.mckenna at oracle.com Wed Dec 7 20:01:11 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 7 Dec 2016 20:01:11 +0000 Subject: [jdk8u-dev] Request for approval: 8170465, 8170466: JNI exception pending in jni_util.c:190 In-Reply-To: References: Message-ID: <20161207200111.GB5819@vimes> Approved -Rob On 07/12/16 11:06, Naoto Sato wrote: > Hello, > > Please approve backport of these JDK9 fixes. The changeset applies cleanly > after un-shuffling. > > https://bugs.openjdk.java.net/browse/JDK-8170465 > https://bugs.openjdk.java.net/browse/JDK-8170466 > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26c1193265d6 > JDK 9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045255.html > > Naoto From gromero at linux.vnet.ibm.com Wed Dec 7 20:03:48 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 7 Dec 2016 18:03:48 -0200 Subject: [8u] Request for approval for 8170873 - PPC64: Poor StrictMath performance due to non-optimized compilation Message-ID: <58486B24.9060005@linux.vnet.ibm.com> Hi, Could you please approve the backport to jdk8u-dev of the following fix: 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html URL 1/2 : http://hg.openjdk.java.net/jdk9/dev/rev/3c7b02f5fa7c URL 2/2 : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b6bad6302dc8 The original change affects s390x and aarch64 as well but since both architectures are not present on 8u I propose a new webrev which just excludes them turning it a ppc-only fix on 8u: Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/ Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170873/jdk/ I also need a sponsor for pushing that change if the approval is granted. Thank you. Best regards, Gustavo From david.holmes at oracle.com Thu Dec 8 02:52:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Dec 2016 12:52:42 +1000 Subject: CFV: New jdk8u Committer: Shafi Ahmad In-Reply-To: References: <03686a98-16ac-5f2f-f135-900bf4a77b5d@oracle.com> <1e4f0b07-b9e6-6ee6-cdd3-59a78dd3b1e6@oracle.com> Message-ID: <762baa17-2104-f933-4423-917529c3eadf@oracle.com> Vote: veto Not withstanding the fact that Shafi has been doing a lot of work in backporting and fixing issue in 8u - which is very much appreciated - I feel this nomination is a little premature. The updated list below reduces from 20 to 12, and I am struggling to see 8 "significant contributions". I would accept these, plus the active-processor backport: - 8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) - 8162419: closed/com/oracle/jfr/runtime/TestVMInfoEvent.sh failing after JDK-8155968 - 8158373: SIGSEGV: Metadata::mark_on_stack [Very borderline] - 8147451: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) But that only comes to 5. These are all not "significant contributions" in my opinion: - 8166872: GPL header in /hotspot/src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp - 8157548: JVM crashes sometimes while starting - 8156836: SIGSEGV: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 - 8147026: Convert an assert in ClassLoaderData to a guarantee - 8150002: Check for the validity of oop before printing it in verify_remembered_set - 8144957: Remove PICL warning message - 8140249: JVM Crashing During startUp If Flight Recording is enabled Sorry. David On 7/12/2016 12:08 AM, Poonam Bajaj Parhar wrote: > Hello David, > > Here are the contributions that were made by Shafi: > > 8161144: Fix for JDK-8147451 failed: Crash in > Method::checked_resolve_jmethod_id(_jmethodID*) > > > 8166872: GPL header in > /hotspot/src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp > > > 8157548: JVM crashes sometimes while starting > > > 8162419: closed/com/oracle/jfr/runtime/TestVMInfoEvent.sh failing > after JDK-8155968 > > > 8161144: Fix for JDK-8147451 failed: Crash in > Method::checked_resolve_jmethod_id(_jmethodID*) > > > 8156836: SIGSEGV: Test test/compiler/jsr292/VMAnonymousClasses.java > fails with JTREG 4.2 b02 > > > 8158373: SIGSEGV: Metadata::mark_on_stack > > > 8147026: Convert an assert in ClassLoaderData to a guarantee > > > 8147451: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) > > > 8150002: Check for the validity of oop before printing it in > verify_remembered_set > > > 8144957: Remove PICL warning message > > > 8140249: JVM Crashing During startUp If Flight Recording is enabled > > > > and the following was a backport from 9 that required significant work > to backport the changes to 8u: > > 6515172: Runtime.availableProcessors() ignores Linux taskset command > > > > > Thanks, > Poonam > > > On 12/5/2016 4:46 PM, David Holmes wrote: >> Hi Poonam, >> >> On 6/12/2016 7:55 AM, Poonam Bajaj Parhar wrote: >>> I hereby nominate Shafi Ahmad (shshahma) to JDK 8u Committer. >>> >>> Shafi is currently a JDK 8u Author, and a member of the JVM Sustaining >>> group at Oracle. He has made many non-trivial contributions to JDK >>> 8u [3]. >> >> Some of these seem to be backports of other people's contributions. >> Can you isolate Shafi's specific contributions, or where the backport >> needed a non-trivial adjustment, please. >> >> Thanks, >> David >> ------ >> >>> Votes are due by the end of Dec 19, 2016. >>> >>> Only current JDK 8u Committers [1] are eligible to vote on this >>> nomination. >>> Votes must be cast in the open by replying to this mailing list. >>> >>> For Lazy Consensus voting instructions, see [2]. >>> >>> regards, >>> Poonam >>> >>> [1] http://openjdk.java.net/census >>> [2] http://openjdk.java.net/projects/#committer-vote >>> [3]http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=1000&rev=(keyword(%22shafi.s.ahmad at oracle.com%22)+or+author(shshahma))+and+not+desc(%22Merge%22) >>> >>> > From sean.coffey at oracle.com Thu Dec 8 07:39:36 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 8 Dec 2016 07:39:36 +0000 Subject: [8u$N] Request for enhancement backport approval for CR 8164908 ReflectionFactory support for IIOP and custom serialization In-Reply-To: <12289aa7-48fe-ec46-1632-2152a9d66fef@oracle.com> References: <72619c23-919e-fc8d-39c5-edee1ef955c6@Oracle.com> <12289aa7-48fe-ec46-1632-2152a9d66fef@oracle.com> Message-ID: <6ea9d4db-ff1a-b5b7-a4ae-5a119e07a81c@oracle.com> Roger, This enhancement request is approved. Please proceed with the backport and send a push approval request to this mailing list when you're ready to push this enhancement to jdk8u-dev. regards, Sean. On 29/11/2016 09:43, Se?n Coffey wrote: > Thanks for the request Roger. This one is currently under review. > > regards, > Sean. > > > On 28/11/2016 16:44, Roger Riggs wrote: >> Please approve the backport of enhancements to >> sun.reflect.ReflectionFactory[1] to facilitate >> the transition of custom serialization libraries to the strong >> encapsulation in JDK 9. >> >> The methods added to ReflectionFactory are used as replacements for the >> use of setAccessible to access private methods specific to >> serialization. >> >> The risk is minimal for JDK 8. >> The new methods have been implemented in JDK 9 and are used by the >> JDK 9 IIOP implementation. >> Tests for the new APIs are included in JDK 9 and are included in >> the backport. >> To minimize risk to JDK 8, the IIOP implementation is not modified. >> >> Thanks, Roger >> >> [1] 8164908 ReflectionFactory support for IIOP and custom serialization >> > From sean.coffey at oracle.com Thu Dec 8 07:54:31 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 8 Dec 2016 07:54:31 +0000 Subject: [8u] Request for approval for 8170873 - PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <58486B24.9060005@linux.vnet.ibm.com> References: <58486B24.9060005@linux.vnet.ibm.com> Message-ID: <92c612f1-0d97-a883-7654-3960954f7b42@oracle.com> Gustavo, Have your jdk8u-dev edits been reviewed anywhere ? Any differences from the jdk 9 fix mean it requires a review. Please resubmit your backport approval request once that's available. regards, Sean. On 07/12/2016 20:03, Gustavo Romero wrote: > Hi, > > Could you please approve the backport to jdk8u-dev of the following fix: > > 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized > compilation > > Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 > Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ > Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ > Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html > URL 1/2 : http://hg.openjdk.java.net/jdk9/dev/rev/3c7b02f5fa7c > URL 2/2 : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b6bad6302dc8 > > The original change affects s390x and aarch64 as well but since both > architectures are not present on 8u I propose a new webrev which just excludes > them turning it a ppc-only fix on 8u: > > Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/ > Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170873/jdk/ > > I also need a sponsor for pushing that change if the approval is granted. > > Thank you. > > > Best regards, > Gustavo > From gromero at linux.vnet.ibm.com Thu Dec 8 12:01:04 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 8 Dec 2016 10:01:04 -0200 Subject: [8u] Request for approval for 8170873 - PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <92c612f1-0d97-a883-7654-3960954f7b42@oracle.com> References: <58486B24.9060005@linux.vnet.ibm.com> <92c612f1-0d97-a883-7654-3960954f7b42@oracle.com> Message-ID: <58494B80.8050904@linux.vnet.ibm.com> Hi Sean, On 08-12-2016 05:54, Se?n Coffey wrote: > Have your jdk8u-dev edits been reviewed anywhere ? Any differences from the jdk 9 fix mean it requires a review. Please resubmit your backport approval request once that's available. No, it's not reviewed. Actually I thought that the review process for 8u would start by this approval request automatically. Sure, I'll start a separate review process and resubmit the backport approval request once the review is done. Thank you. Regards, Gustavo From dmitry.markov at oracle.com Thu Dec 8 12:47:50 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Thu, 08 Dec 2016 15:47:50 +0300 Subject: [8u-dev] Request for approval 8035568: [macosx] Cursor management unification Message-ID: <58495676.5010701@oracle.com> Hello, Can I get an approval to port the fix for 8035568 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8035568 Webrev: http://cr.openjdk.java.net/~dmarkov/8035568/jdk8u/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2014-July/008183.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/8ecb21b07971 Thanks, Dmitry From maxim.soloviev at oracle.com Thu Dec 8 12:55:12 2016 From: maxim.soloviev at oracle.com (Maxim Soloviev) Date: Thu, 8 Dec 2016 15:55:12 +0300 Subject: [8u-dev] Request for approval 8150490: Update OS detection code to recognize Windows Server 2016 Message-ID: <0356d580-e54a-0acf-3118-cd0544d60f68@oracle.com> Hello, Could you please approve the backport to jdk8u-dev of the fix: 8150490: Update OS detection code to recognize Windows Server 2016 Webrev: http://cr.openjdk.java.net/~msolovie/8150490/webrev.00/ http://cr.openjdk.java.net/~msolovie/8150490/webrev.jdk.00/ Original fix in JDK9: https://bugs.openjdk.java.net/browse/JDK-8150490 Review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018158.html JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/6416cd3a77b3 http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/76821da52279 Thanks, Maxim From rob.mckenna at oracle.com Thu Dec 8 16:10:28 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 8 Dec 2016 16:10:28 +0000 Subject: [8u-dev] Request for approval 8035568: [macosx] Cursor management unification In-Reply-To: <58495676.5010701@oracle.com> References: <58495676.5010701@oracle.com> Message-ID: <20161208161028.GB2398@vimes> Approved -Rob On 08/12/16 03:47, dmitry markov wrote: > Hello, > > Can I get an approval to port the fix for 8035568 to jdk8u-dev, please? The > jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8035568 > Webrev: http://cr.openjdk.java.net/~dmarkov/8035568/jdk8u/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2014-July/008183.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/8ecb21b07971 > > Thanks, > Dmitry From rob.mckenna at oracle.com Thu Dec 8 16:12:54 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 8 Dec 2016 16:12:54 +0000 Subject: [8u-dev] Request for approval 8150490: Update OS detection code to recognize Windows Server 2016 In-Reply-To: <0356d580-e54a-0acf-3118-cd0544d60f68@oracle.com> References: <0356d580-e54a-0acf-3118-cd0544d60f68@oracle.com> Message-ID: <20161208161254.GC2398@vimes> Approved. Please add an appropriate noreg label to the bug. -Rob On 08/12/16 03:55, Maxim Soloviev wrote: > Hello, > > Could you please approve the backport to jdk8u-dev of the fix: > 8150490: Update OS detection code to recognize Windows Server 2016 > > Webrev: > http://cr.openjdk.java.net/~msolovie/8150490/webrev.00/ > http://cr.openjdk.java.net/~msolovie/8150490/webrev.jdk.00/ > > Original fix in JDK9: > https://bugs.openjdk.java.net/browse/JDK-8150490 > > Review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018158.html > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/6416cd3a77b3 > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/76821da52279 > > Thanks, > Maxim From Roger.Riggs at Oracle.com Thu Dec 8 16:25:58 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Dec 2016 11:25:58 -0500 Subject: [8u$N] Request for phase approval for CR 8164908 ReflectionFactory support for IIOP and custom serialization In-Reply-To: <6ea9d4db-ff1a-b5b7-a4ae-5a119e07a81c@oracle.com> References: <72619c23-919e-fc8d-39c5-edee1ef955c6@Oracle.com> <12289aa7-48fe-ec46-1632-2152a9d66fef@oracle.com> <6ea9d4db-ff1a-b5b7-a4ae-5a119e07a81c@oracle.com> Message-ID: Please approve the backport of enhancements to sun.reflect.ReflectionFactory[1] to facilitate the transition of custom serialization libraries to the strong encapsulation in JDK 9. Issue: https://bugs.openjdk.java.net/browse/JDK-8164908 Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reflect-factory-8164908/ Review thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-November/006171.html Reviewed by: chegar and (offline) psandoz The methods added to ReflectionFactory are used as replacements for the use of setAccessible to access private methods specific to serialization. The risk is minimal for JDK 8. The new methods have been implemented in JDK 9 and are used by the JDK 9 IIOP implementation. Tests for the new APIs are included in JDK 9 and are included in the backport. To minimize risk to JDK 8, the IIOP implementation is not modified. Thanks, Roger From rob.mckenna at oracle.com Thu Dec 8 18:08:09 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 8 Dec 2016 18:08:09 +0000 Subject: [8u$N] Request for phase approval for CR 8164908 ReflectionFactory support for IIOP and custom serialization In-Reply-To: References: <72619c23-919e-fc8d-39c5-edee1ef955c6@Oracle.com> <12289aa7-48fe-ec46-1632-2152a9d66fef@oracle.com> <6ea9d4db-ff1a-b5b7-a4ae-5a119e07a81c@oracle.com> Message-ID: <20161208180809.GE2398@vimes> Approved -Rob On 08/12/16 11:25, Roger Riggs wrote: > Please approve the backport of enhancements to > sun.reflect.ReflectionFactory[1] to facilitate > the transition of custom serialization libraries to the strong encapsulation > in JDK 9. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8164908 > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-reflect-factory-8164908/ > > Review thread: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-November/006171.html > Reviewed by: chegar and (offline) psandoz > > The methods added to ReflectionFactory are used as replacements for the > use of setAccessible to access private methods specific to serialization. > > The risk is minimal for JDK 8. > The new methods have been implemented in JDK 9 and are used by the JDK 9 > IIOP implementation. > Tests for the new APIs are included in JDK 9 and are included in the > backport. > To minimize risk to JDK 8, the IIOP implementation is not modified. > > Thanks, Roger From dmitry.markov at oracle.com Fri Dec 9 08:40:26 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Fri, 09 Dec 2016 11:40:26 +0300 Subject: [8u-dev] Request for approval 8169589: [macosx] Activating a JDialog puts to back another dialog Message-ID: <584A6DFA.2080706@oracle.com> Hello, Can I get an approval to port the fix for 8169589 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8169589 Webrev: http://cr.openjdk.java.net/~dmarkov/8169589/jdk8u/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-November/012375.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/c1e333ed1273 Thanks, Dmitry From david.buck at oracle.com Fri Dec 9 08:57:27 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 9 Dec 2016 17:57:27 +0900 Subject: [8u-dev] Request for approval 8169589: [macosx] Activating a JDialog puts to back another dialog In-Reply-To: <584A6DFA.2080706@oracle.com> References: <584A6DFA.2080706@oracle.com> Message-ID: <584A71F7.6010507@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2016/12/09 17:40, dmitry markov wrote: > Hello, > > Can I get an approval to port the fix for 8169589 to jdk8u-dev, > please? The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8169589 > Webrev: http://cr.openjdk.java.net/~dmarkov/8169589/jdk8u/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-November/012375.html > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/c1e333ed1273 > > Thanks, > Dmitry From maxim.soloviev at oracle.com Fri Dec 9 16:54:19 2016 From: maxim.soloviev at oracle.com (Maxim Soloviev) Date: Fri, 9 Dec 2016 19:54:19 +0300 Subject: [8u-dev] Request for approval 8150490: Update OS detection code to recognize Windows Server 2016 In-Reply-To: <20161208161254.GC2398@vimes> References: <0356d580-e54a-0acf-3118-cd0544d60f68@oracle.com> <20161208161254.GC2398@vimes> Message-ID: <09b1f5e2-3ff6-74ee-c89a-7888411a9d6c@oracle.com> Hello, should I wait for any approve from hotspot-runtime-dev or I can ask somebody to push the changes? Thanks, Maxim On 12/08/2016 07:12 PM, Rob McKenna wrote: > Approved. Please add an appropriate noreg label to the bug. > > -Rob > > On 08/12/16 03:55, Maxim Soloviev wrote: >> Hello, >> >> Could you please approve the backport to jdk8u-dev of the fix: >> 8150490: Update OS detection code to recognize Windows Server 2016 >> >> Webrev: >> http://cr.openjdk.java.net/~msolovie/8150490/webrev.00/ >> http://cr.openjdk.java.net/~msolovie/8150490/webrev.jdk.00/ >> >> Original fix in JDK9: >> https://bugs.openjdk.java.net/browse/JDK-8150490 >> >> Review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018158.html >> >> JDK9 changeset: >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/6416cd3a77b3 >> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/76821da52279 >> >> Thanks, >> Maxim From rob.mckenna at oracle.com Fri Dec 9 18:13:30 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 9 Dec 2016 18:13:30 +0000 Subject: [8u-dev] Request for approval 8150490: Update OS detection code to recognize Windows Server 2016 In-Reply-To: <09b1f5e2-3ff6-74ee-c89a-7888411a9d6c@oracle.com> References: <0356d580-e54a-0acf-3118-cd0544d60f68@oracle.com> <20161208161254.GC2398@vimes> <09b1f5e2-3ff6-74ee-c89a-7888411a9d6c@oracle.com> Message-ID: <20161209181330.GA2340@vimes> The change appears to be identical and it has been reviewed in 9, correct? Do you have a separate 8 review thread that I'm missing? What approval are you waiting on from hotspot-runtime-dev? -Rob On 09/12/16 07:54, Maxim Soloviev wrote: > Hello, > > should I wait for any approve from hotspot-runtime-dev or I can ask somebody > to push the changes? > > Thanks, > Maxim > > On 12/08/2016 07:12 PM, Rob McKenna wrote: > >Approved. Please add an appropriate noreg label to the bug. > > > > -Rob > > > >On 08/12/16 03:55, Maxim Soloviev wrote: > >>Hello, > >> > >>Could you please approve the backport to jdk8u-dev of the fix: > >>8150490: Update OS detection code to recognize Windows Server 2016 > >> > >>Webrev: > >>http://cr.openjdk.java.net/~msolovie/8150490/webrev.00/ > >>http://cr.openjdk.java.net/~msolovie/8150490/webrev.jdk.00/ > >> > >>Original fix in JDK9: > >>https://bugs.openjdk.java.net/browse/JDK-8150490 > >> > >>Review thread: > >>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018158.html > >> > >>JDK9 changeset: > >>http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/6416cd3a77b3 > >>http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/76821da52279 > >> > >>Thanks, > >>Maxim > From daniel.daugherty at oracle.com Fri Dec 9 18:27:38 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 9 Dec 2016 11:27:38 -0700 Subject: [8u-dev] Request for approval 8150490: Update OS detection code to recognize Windows Server 2016 In-Reply-To: <20161209181330.GA2340@vimes> References: <0356d580-e54a-0acf-3118-cd0544d60f68@oracle.com> <20161208161254.GC2398@vimes> <09b1f5e2-3ff6-74ee-c89a-7888411a9d6c@oracle.com> <20161209181330.GA2340@vimes> Message-ID: <4bbe680f-8d21-ef92-766c-f074a2ed692a@oracle.com> I have only seen a "request for approval" for this fix (this thread) I have not seen a "request for code review" for this fix for JDK8u. The original approval request is also missing the usual verbiage about how the JDK9 and JDK8u versions of the fix compare (as Rob pointed out). I guess I'm not sure what Maxim is expecting from hotspot-runtime-dev at ... Dan On 12/9/16 11:13 AM, Rob McKenna wrote: > The change appears to be identical and it has been reviewed in 9, > correct? Do you have a separate 8 review thread that I'm missing? What > approval are you waiting on from hotspot-runtime-dev? > > -Rob > > On 09/12/16 07:54, Maxim Soloviev wrote: >> Hello, >> >> should I wait for any approve from hotspot-runtime-dev or I can ask somebody >> to push the changes? >> >> Thanks, >> Maxim >> >> On 12/08/2016 07:12 PM, Rob McKenna wrote: >>> Approved. Please add an appropriate noreg label to the bug. >>> >>> -Rob >>> >>> On 08/12/16 03:55, Maxim Soloviev wrote: >>>> Hello, >>>> >>>> Could you please approve the backport to jdk8u-dev of the fix: >>>> 8150490: Update OS detection code to recognize Windows Server 2016 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~msolovie/8150490/webrev.00/ >>>> http://cr.openjdk.java.net/~msolovie/8150490/webrev.jdk.00/ >>>> >>>> Original fix in JDK9: >>>> https://bugs.openjdk.java.net/browse/JDK-8150490 >>>> >>>> Review thread: >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018158.html >>>> >>>> JDK9 changeset: >>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/6416cd3a77b3 >>>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/76821da52279 >>>> >>>> Thanks, >>>> Maxim From ramanand.patil at oracle.com Fri Dec 9 19:51:17 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Fri, 9 Dec 2016 11:51:17 -0800 (PST) Subject: [8u-dev] Request for Approval: Backport of 8170316: (tz) Support tzdata2016j Message-ID: <2f039b95-9b65-4d56-a822-ba15a9c9ee67@default> Hi, Please approve the backport of 8170316 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8170316 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f418bde7bcf1 JDK9 review thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2016-November/002193.html Changes apply cleanly to jdk8u-dev after path reshuffling. Regards, Ramanand. From gromero at linux.vnet.ibm.com Fri Dec 9 21:27:53 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 9 Dec 2016 19:27:53 -0200 Subject: RFR(s) 8170873: PPC64: Poor StrictMath performance due to non-optimized compilation Message-ID: <584B21D9.20105@linux.vnet.ibm.com> Hi, Could the following webrev be reviewed please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/v2/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170873/v2/jdk/ bug : https://bugs.openjdk.java.net/browse/JDK-8170873 It's a backport of 8170153: 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html URL 1/2 : http://hg.openjdk.java.net/jdk9/jdk9/rev/3c7b02f5fa7c URL 2/2 : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b6bad6302dc8 The original change affects s390x and aarch64 as well but since both architectures are not present on 8u both were excluded from this new webrev turning it, in effect, a ppc-only fix on 8u. I understand that that change is particularly important to PPC64 since [1] is not planned to be backported. I've tested the same way I did on 9 (jtreg) and no regression was observed [2]. I did not run against the JCK tests as performend by Martin [3] since I'm still in the process of solving an issue related to the OCTLA. Thank you. Regards, Gustavo [1] https://bugs.openjdk.java.net/browse/JDK-8134780 [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025283.html [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025317.html From rob.mckenna at oracle.com Fri Dec 9 22:14:25 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 9 Dec 2016 22:14:25 +0000 Subject: [8u-dev] Request for Approval: Backport of 8170316: (tz) Support tzdata2016j In-Reply-To: <2f039b95-9b65-4d56-a822-ba15a9c9ee67@default> References: <2f039b95-9b65-4d56-a822-ba15a9c9ee67@default> Message-ID: <20161209221425.GB2340@vimes> Approved -Rob On 09/12/16 11:51, Ramanand Patil wrote: > Hi, > Please approve the backport of 8170316 to 8u-dev. > Bug: https://bugs.openjdk.java.net/browse/JDK-8170316 > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f418bde7bcf1 > JDK9 review thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2016-November/002193.html > > Changes apply cleanly to jdk8u-dev after path reshuffling. > > > Regards, > Ramanand. From dmitry.markov at oracle.com Sun Dec 11 11:48:07 2016 From: dmitry.markov at oracle.com (dmitry markov) Date: Sun, 11 Dec 2016 14:48:07 +0300 Subject: [8u-dev] Request for approval 8165428: Security Warning dialog should be always on the top when multiple applets with APPLICATION_MODAL dialog launched in a browser Message-ID: <584D3CF7.6010507@oracle.com> Hello, Can I get an approval to port the fix for 8165428 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8165428 Webrev: http://cr.openjdk.java.net/~dmarkov/8165428/jdk8u/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-November/012410.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/6bd103f92803 Thanks, Dmitry From david.buck at oracle.com Sun Dec 11 13:27:04 2016 From: david.buck at oracle.com (David Buck) Date: Sun, 11 Dec 2016 22:27:04 +0900 Subject: [8u-dev] Request for approval 8165428: Security Warning dialog should be always on the top when multiple applets with APPLICATION_MODAL dialog launched in a browser In-Reply-To: <584D3CF7.6010507@oracle.com> References: <584D3CF7.6010507@oracle.com> Message-ID: <584D5428.60003@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2016/12/11 20:48, dmitry markov wrote: > Hello, > > Can I get an approval to port the fix for 8165428 to jdk8u-dev, > please? The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8165428 > Webrev: http://cr.openjdk.java.net/~dmarkov/8165428/jdk8u/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-November/012410.html > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/6bd103f92803 > > Thanks, > Dmitry From gromero at linux.vnet.ibm.com Mon Dec 12 13:43:08 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 12 Dec 2016 11:43:08 -0200 Subject: RFR(s) 8170873: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <584B21D9.20105@linux.vnet.ibm.com> References: <584B21D9.20105@linux.vnet.ibm.com> Message-ID: <584EA96C.8000801@linux.vnet.ibm.com> Hi, I included aarch64 as Andrew requested [1] and so I need a aarch64 reviewer too. I forgot about the existence of the aarch64-port repo [2], but for s360x I understand it remains the same since s360x port is staging yet. Let me know if it's incorrect. Also, not sure if a separate webrev is necessary for [2]. Please review the new webrev: webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/v3/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170873/v3/jdk/ Thank you. Regards, Gustavo [1] http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2016-December/003983.html [2] http://hg.openjdk.java.net/aarch64-port/jdk8u/ On 09-12-2016 19:27, Gustavo Romero wrote: > Hi, > > Could the following webrev be reviewed please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/v2/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170873/v2/jdk/ > bug : https://bugs.openjdk.java.net/browse/JDK-8170873 > > It's a backport of 8170153: > > 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized > compilation > > Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 > Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ > Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ > Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html > URL 1/2 : http://hg.openjdk.java.net/jdk9/jdk9/rev/3c7b02f5fa7c > URL 2/2 : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b6bad6302dc8 > > The original change affects s390x and aarch64 as well but since both > architectures are not present on 8u both were excluded from this new webrev > turning it, in effect, a ppc-only fix on 8u. > > I understand that that change is particularly important to PPC64 since [1] is > not planned to be backported. > > I've tested the same way I did on 9 (jtreg) and no regression was observed [2]. > > I did not run against the JCK tests as performend by Martin [3] > since I'm still in the process of solving an issue related to the OCTLA. > > Thank you. > > > Regards, > Gustavo > > [1] https://bugs.openjdk.java.net/browse/JDK-8134780 > [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025283.html > [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025317.html > From rob.mckenna at oracle.com Mon Dec 12 17:45:38 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 12 Dec 2016 17:45:38 +0000 Subject: [8u-dev] Request for approval 8150490: Update OS detection code to recognize Windows Server 2016 In-Reply-To: <4bbe680f-8d21-ef92-766c-f074a2ed692a@oracle.com> References: <0356d580-e54a-0acf-3118-cd0544d60f68@oracle.com> <20161208161254.GC2398@vimes> <09b1f5e2-3ff6-74ee-c89a-7888411a9d6c@oracle.com> <20161209181330.GA2340@vimes> <4bbe680f-8d21-ef92-766c-f074a2ed692a@oracle.com> Message-ID: <20161212174538.GA2887@tecra> Ok, so it looks like the fix is in fact identical and no further review from hotspot-runtime-dev is required. Approved. -Rob On 09/12/16 11:27, Daniel D. Daugherty wrote: > I have only seen a "request for approval" for this fix (this thread) > I have not seen a "request for code review" for this fix for JDK8u. > > The original approval request is also missing the usual verbiage about > how the JDK9 and JDK8u versions of the fix compare (as Rob pointed out). > > I guess I'm not sure what Maxim is expecting from hotspot-runtime-dev at ... > > Dan > > > On 12/9/16 11:13 AM, Rob McKenna wrote: > >The change appears to be identical and it has been reviewed in 9, > >correct? Do you have a separate 8 review thread that I'm missing? What > >approval are you waiting on from hotspot-runtime-dev? > > > > -Rob > > > >On 09/12/16 07:54, Maxim Soloviev wrote: > >>Hello, > >> > >>should I wait for any approve from hotspot-runtime-dev or I can ask somebody > >>to push the changes? > >> > >>Thanks, > >>Maxim > >> > >>On 12/08/2016 07:12 PM, Rob McKenna wrote: > >>>Approved. Please add an appropriate noreg label to the bug. > >>> > >>> -Rob > >>> > >>>On 08/12/16 03:55, Maxim Soloviev wrote: > >>>>Hello, > >>>> > >>>>Could you please approve the backport to jdk8u-dev of the fix: > >>>>8150490: Update OS detection code to recognize Windows Server 2016 > >>>> > >>>>Webrev: > >>>>http://cr.openjdk.java.net/~msolovie/8150490/webrev.00/ > >>>>http://cr.openjdk.java.net/~msolovie/8150490/webrev.jdk.00/ > >>>> > >>>>Original fix in JDK9: > >>>>https://bugs.openjdk.java.net/browse/JDK-8150490 > >>>> > >>>>Review thread: > >>>>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018158.html > >>>> > >>>>JDK9 changeset: > >>>>http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/6416cd3a77b3 > >>>>http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/76821da52279 > >>>> > >>>>Thanks, > >>>>Maxim > From volker.simonis at gmail.com Mon Dec 12 18:19:09 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 12 Dec 2016 19:19:09 +0100 Subject: [8u] request for approval: "8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries" Message-ID: Hi, could you please approve the backport of the following GC fix to jdk8u-dev: 8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries This fix is critical for linux/ppc64 where it impacts Hadoop/Terasort [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8170409 Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8170409.v3/ Review: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November/019313.html, http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-December/019332.html URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/fe86ccf9132f The original patch cleanly applies with only two minor, non-functional changes: - we have to revert the file renaming from "share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp" and "share/vm/memory/cardTableModRefBS.hpp" in jdk8 to "share/vm/gc/cms/parCardTableModRefBS.cpp" and "share/vm/gc/shared/cardTableModRefBSForCTRS.hpp" in jdk9. - in jkd9, jdk8's Universe::heap() was moved to GenCollectedHeap::heap(). While the call to this function is not part of the patch, it has to be renamed in the context of the change such that the patch cleanly applies. The updated webrev can be found here: http://cr.openjdk.java.net/~simonis/webrevs/2016/8170409.8u/ Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025483.html From rob.mckenna at oracle.com Mon Dec 12 21:58:53 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 12 Dec 2016 21:58:53 +0000 Subject: [8u] request for approval: "8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries" In-Reply-To: References: Message-ID: <20161212215853.GC2887@tecra> Approved. Please add a suitable noreg label to the bug. -Rob On 12/12/16 07:19, Volker Simonis wrote: > Hi, > > could you please approve the backport of the following GC fix to jdk8u-dev: > > 8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries > > This fix is critical for linux/ppc64 where it impacts Hadoop/Terasort [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170409 > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8170409.v3/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November/019313.html, > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-December/019332.html > URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/fe86ccf9132f > > The original patch cleanly applies with only two minor, non-functional changes: > > - we have to revert the file renaming from > "share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp" and > "share/vm/memory/cardTableModRefBS.hpp" in jdk8 to > "share/vm/gc/cms/parCardTableModRefBS.cpp" and > "share/vm/gc/shared/cardTableModRefBSForCTRS.hpp" in jdk9. > > - in jkd9, jdk8's Universe::heap() was moved to > GenCollectedHeap::heap(). While the call to this function is not part > of the patch, it has to be renamed in the context of the change such > that the patch cleanly applies. > > The updated webrev can be found here: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8170409.8u/ > > Thank you and best regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025483.html From volker.simonis at gmail.com Tue Dec 13 08:32:28 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 13 Dec 2016 09:32:28 +0100 Subject: [8u] request for approval: "8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries" In-Reply-To: <20161212215853.GC2887@tecra> References: <20161212215853.GC2887@tecra> Message-ID: Thanks Rob! I've added 'noreg-hard' to the bug with a corresponding comment. Regards, Volker On Mon, Dec 12, 2016 at 10:58 PM, Rob McKenna wrote: > Approved. Please add a suitable noreg label to the bug. > > -Rob > > On 12/12/16 07:19, Volker Simonis wrote: >> Hi, >> >> could you please approve the backport of the following GC fix to jdk8u-dev: >> >> 8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries >> >> This fix is critical for linux/ppc64 where it impacts Hadoop/Terasort [1]. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170409 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8170409.v3/ >> Review: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November/019313.html, >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-December/019332.html >> URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/fe86ccf9132f >> >> The original patch cleanly applies with only two minor, non-functional changes: >> >> - we have to revert the file renaming from >> "share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp" and >> "share/vm/memory/cardTableModRefBS.hpp" in jdk8 to >> "share/vm/gc/cms/parCardTableModRefBS.cpp" and >> "share/vm/gc/shared/cardTableModRefBSForCTRS.hpp" in jdk9. >> >> - in jkd9, jdk8's Universe::heap() was moved to >> GenCollectedHeap::heap(). While the call to this function is not part >> of the patch, it has to be renamed in the context of the change such >> that the patch cleanly applies. >> >> The updated webrev can be found here: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8170409.8u/ >> >> Thank you and best regards, >> Volker >> >> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025483.html From HORII at jp.ibm.com Tue Dec 13 09:19:07 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Tue, 13 Dec 2016 18:19:07 +0900 Subject: [8u] Request for enhancement backport approval for JDK-8166684: implement intrinsic code with vector instructions for Unsafe.copyMemory() Message-ID: Dear all, Could you please approve the backport of the following ppc64 change to jdk8u-dev? 8166684: implement intrinsic code with vector instructions for Unsafe.copyMemory() Bug: https://bugs.openjdk.java.net/browse/JDK-8166684 Webrev: http://cr.openjdk.java.net/~horii/8166684/webrev.02/ Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024567.html URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0f2a78897867 This change improves performance of unsafe.copyMemory for ppc64le. Recent open sources frequently use copyMemory. This is a significant ppc64-only performance improvement which will not affect any of the Oracle platforms in any way. This change needs a part of the following change (src/cpu/ppc/vm/stubGenerator_ppc.cpp). 8144019: PPC64 C1: Introduce Client Compiler URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a24de859a87 Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo From mikhail.cherkasov at oracle.com Tue Dec 13 09:57:11 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Tue, 13 Dec 2016 12:57:11 +0300 Subject: [8u] request for approval: 8075516: Deleting a file from either the open or save java.awt.FileDialog hangs Message-ID: Hi all, Could you please approve a direct backport from jdk9 to 8: jbs: https://bugs.openjdk.java.net/browse/JDK-8075516 jdk9 review: http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011356.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fcbe313c8cec jdk8 webrev: http://cr.openjdk.java.net/~mcherkas/8075516/webrev.00/ Thanks, Mikhail. From mikhail.cherkasov at oracle.com Tue Dec 13 10:36:33 2016 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Tue, 13 Dec 2016 13:36:33 +0300 Subject: [8u] request for approval: 8152981: Double icons with JMenuItem setHorizontalTextPosition on Win 10 Message-ID: Hi all, Could you please approve a direct backport from jdk9 to 8: jbs: https://bugs.openjdk.java.net/browse/JDK-8152981 jdk9 review: http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005913.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5fb24aaf6945 jdk8 webrev: http://cr.openjdk.java.net/~mcherkas/8152981/webrev.00/ Thanks, Mikhail. From rwestrel at redhat.com Tue Dec 13 12:47:14 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 13:47:14 +0100 Subject: RFR(s) 8170873: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <584EA96C.8000801@linux.vnet.ibm.com> References: <584B21D9.20105@linux.vnet.ibm.com> <584EA96C.8000801@linux.vnet.ibm.com> Message-ID: Hi Gustavo, > I included aarch64 as Andrew requested [1] and so I need a aarch64 reviewer too. > > I forgot about the existence of the aarch64-port repo [2], but for s360x I > understand it remains the same since s360x port is staging yet. Let me know if > it's incorrect. Also, not sure if a separate webrev is necessary for [2]. > > Please review the new webrev: > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/v3/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170873/v3/jdk/ Thanks for including aarch64. As far as the aarch64 port is concerned, this looks good to me. I verified that the change is correct. I will push it to the aarch64 8u repo. Roland. From gromero at linux.vnet.ibm.com Tue Dec 13 14:43:35 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 13 Dec 2016 12:43:35 -0200 Subject: RFR(s) 8170873: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <584B21D9.20105@linux.vnet.ibm.com> <584EA96C.8000801@linux.vnet.ibm.com> Message-ID: <58500917.8010908@linux.vnet.ibm.com> Hi Roland, On 13-12-2016 10:47, Roland Westrelin wrote: > > Hi Gustavo, > >> I included aarch64 as Andrew requested [1] and so I need a aarch64 reviewer too. >> >> I forgot about the existence of the aarch64-port repo [2], but for s360x I >> understand it remains the same since s360x port is staging yet. Let me know if >> it's incorrect. Also, not sure if a separate webrev is necessary for [2]. >> >> Please review the new webrev: >> >> webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/v3/ >> webrev 2/2: http://cr.openjdk.java.net/~gromero/8170873/v3/jdk/ > > Thanks for including aarch64. As far as the aarch64 port is concerned, > this looks good to me. I verified that the change is correct. I will > push it to the aarch64 8u repo. Thanks for reviewing the change. I'll wait a review for PPC64. However I'm a little bit confused since the webrev I provide will, when applied to 8u, add aarch64 as well which is not currently in the 8u forest (maybe who pushes it could trim it off or use the previous webrev)... ... and maybe Andrew's reply (since he just added the aarch64-port-dev ML) was just for aarch64-port folks and I got it wrong... (it seems the case...) Please advise. Thanks. Regards, Gustavo From rob.mckenna at oracle.com Tue Dec 13 15:14:41 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 13 Dec 2016 15:14:41 +0000 Subject: [8u] request for approval: 8075516: Deleting a file from either the open or save java.awt.FileDialog hangs In-Reply-To: References: Message-ID: <20161213151441.GB2425@vimes> Approved -Rob On 13/12/16 12:57, Mikhail Cherkasov wrote: > Hi all, > > Could you please approve a direct backport from jdk9 to 8: > > jbs: https://bugs.openjdk.java.net/browse/JDK-8075516 > jdk9 review: > http://mail.openjdk.java.net/pipermail/awt-dev/2016-May/011356.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fcbe313c8cec > jdk8 webrev: http://cr.openjdk.java.net/~mcherkas/8075516/webrev.00/ > > Thanks, > Mikhail. From rob.mckenna at oracle.com Tue Dec 13 15:15:04 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 13 Dec 2016 15:15:04 +0000 Subject: [8u] request for approval: 8152981: Double icons with JMenuItem setHorizontalTextPosition on Win 10 In-Reply-To: References: Message-ID: <20161213151504.GC2425@vimes> Approved -Rob On 13/12/16 01:36, Mikhail Cherkasov wrote: > Hi all, > > Could you please approve a direct backport from jdk9 to 8: > > jbs: https://bugs.openjdk.java.net/browse/JDK-8152981 > jdk9 review: > http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005913.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5fb24aaf6945 > jdk8 webrev: http://cr.openjdk.java.net/~mcherkas/8152981/webrev.00/ > > Thanks, > Mikhail. From rob.mckenna at oracle.com Tue Dec 13 15:31:02 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 13 Dec 2016 15:31:02 +0000 Subject: [8u] Request for enhancement backport approval for "8168318 : PPC64: Use cmpldi instead of li/cmpld" In-Reply-To: References: Message-ID: <20161213153102.GD2425@vimes> Hi Bruno, Unless I'm mistaken, neither of you are OCA signatories: http://www.oracle.com/technetwork/community/oca-486395.html We cannot accept this enhancement request until: 1) The requestor is a signatory 2) The webrev is hosted on cr.openjdk.java.net or shared over email as a patch -Rob On 02/12/16 05:42, Bruno Alexandre Rosa wrote: > Hi, > > Thanks to Rob for pointing to the adequate process documentation. > > On behalf of Igor, I'm submitting an enhancement request that conforms to the process: > > This changeset adds a new matching rule to the instruction selection phase (adlc) of the ppc vm. > It consists of the exchange of the pair li/cmpld with cmpldi. > Jtreg hotspot tests didn't regress. > Got an 1% performance improvement when benchmarking neo4j. > Since the patch is rather small and affects only the ppc vm, the risks are minimal. > > Please, let us if we are breaking any jdk8u ground rules. > > Regards, > Bruno Rosa > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168318 > Webrev: https://igorsnunes.github.io/openjdk/webrev/8168318/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024809.html > URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/622d3fe587f2 From rob.mckenna at oracle.com Tue Dec 13 15:51:20 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 13 Dec 2016 15:51:20 +0000 Subject: [8u] Request for enhancement backport approval for JDK-8166684: implement intrinsic code with vector instructions for Unsafe.copyMemory() In-Reply-To: References: Message-ID: <20161213155120.GE2425@vimes> Thanks Hiroshi, your request is under review. -Rob On 13/12/16 06:19, Hiroshi H Horii wrote: > Dear all, > > Could you please approve the backport of the following ppc64 change to > jdk8u-dev? > > 8166684: implement intrinsic code with vector instructions for > Unsafe.copyMemory() > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166684 > Webrev: http://cr.openjdk.java.net/~horii/8166684/webrev.02/ > Review: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024567.html > URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0f2a78897867 > > This change improves performance of unsafe.copyMemory for ppc64le. Recent > open sources frequently use copyMemory. > This is a significant ppc64-only performance improvement which will not > affect any of the Oracle platforms in any way. > > This change needs a part of the following change > (src/cpu/ppc/vm/stubGenerator_ppc.cpp). > > 8144019: PPC64 C1: Introduce Client Compiler > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4a24de859a87 > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > From dalibor.topic at oracle.com Tue Dec 13 16:37:19 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 13 Dec 2016 17:37:19 +0100 Subject: [8u communication] Changes to JDK 8u122 plans Message-ID: Oracle no longer plans to create a separate JDK 8u122 PSU release. As such, the proposed schedule for JDK 8u122 in this Project is no longer accurate. Given the very small amount of changes that were destined specifically for 8u122 (and not for 8u121 as well), the process to propose critical fixes for inclusion in JDK 8u CPU releases [0] should be used instead, where applicable. This holds for future changes to be integrated into jdk8u-dev forest, as well as for already integrated changes that were destined for JDK 8u122. If you have questions or concerns, please share them on the jdk8u-dev mailing list. cheers, dalibor topic [0] http://openjdk.java.net/projects/jdk8u/criticalcpufixes.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 rwestrel at redhat.com Tue Dec 13 16:54:04 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 17:54:04 +0100 Subject: RFR(s) 8170873: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <58500917.8010908@linux.vnet.ibm.com> References: <584B21D9.20105@linux.vnet.ibm.com> <584EA96C.8000801@linux.vnet.ibm.com> <58500917.8010908@linux.vnet.ibm.com> Message-ID: > I'll wait a review for PPC64. However I'm a little bit confused since the > webrev I provide will, when applied to 8u, add aarch64 as well which is not > currently in the 8u forest (maybe who pushes it could trim it off or use the > previous webrev)... > > ... and maybe Andrew's reply (since he just added the aarch64-port-dev ML) was > just for aarch64-port folks and I got it wrong... (it seems the case...) I suppose it doesn't make much sense to include aarch64 in the non aarch64 8u. Thanks anyway! FYI, the commit message for the backport shouldn't use the backport's bug id but the one from jdk 9 (8170153 in this case). Roland. From gromero at linux.vnet.ibm.com Tue Dec 13 16:59:36 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 13 Dec 2016 14:59:36 -0200 Subject: RFR(s) 8170873: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <584B21D9.20105@linux.vnet.ibm.com> <584EA96C.8000801@linux.vnet.ibm.com> <58500917.8010908@linux.vnet.ibm.com> Message-ID: <585028F8.4060901@linux.vnet.ibm.com> On 13-12-2016 14:54, Roland Westrelin wrote: > >> I'll wait a review for PPC64. However I'm a little bit confused since the >> webrev I provide will, when applied to 8u, add aarch64 as well which is not >> currently in the 8u forest (maybe who pushes it could trim it off or use the >> previous webrev)... >> >> ... and maybe Andrew's reply (since he just added the aarch64-port-dev ML) was >> just for aarch64-port folks and I got it wrong... (it seems the case...) > > I suppose it doesn't make much sense to include aarch64 in the non > aarch64 8u. Thanks anyway! Fair enough. > FYI, the commit message for the backport shouldn't use the backport's > bug id but the one from jdk 9 (8170153 in this case). Thanks for pointing that out. Regards, Gustavo From gromero at linux.vnet.ibm.com Tue Dec 13 17:57:39 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 13 Dec 2016 15:57:39 -0200 Subject: [8u] RFR(s) 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <584B21D9.20105@linux.vnet.ibm.com> References: <584B21D9.20105@linux.vnet.ibm.com> Message-ID: <58503693.8050904@linux.vnet.ibm.com> Hi, Re-sending with the correct subject and adding the ppc-aix-port ML. Could the following webrev be reviewed please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/v2/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170873/v2/jdk/ bug : https://bugs.openjdk.java.net/browse/JDK-8170873 It's a backport of 8170153: 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html URL 1/2 : http://hg.openjdk.java.net/jdk9/jdk9/rev/3c7b02f5fa7c URL 2/2 : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b6bad6302dc8 The original change affects s390x and aarch64 as well but since both architectures are not present on 8u both were excluded from this new webrev turning it, in effect, a ppc-only fix on 8u. I understand that that change is particularly important to PPC64 since [1] is not planned to be backported. I've tested the same way I did on 9 (jtreg) and no regression was observed [2]. I did not run against the JCK tests as performend by Martin [3] since I'm still in the process of solving an issue related to the OCTLA. Thank you. Regards, Gustavo [1] https://bugs.openjdk.java.net/browse/JDK-8134780 [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025283.html [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025317.html From david.holmes at oracle.com Thu Dec 15 04:23:53 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2016 14:23:53 +1000 Subject: [8u communication] Changes to JDK 8u122 plans In-Reply-To: References: Message-ID: <368fb6dc-7927-d894-38dd-1ac51094f68f@oracle.com> Hi Dalibor, On 14/12/2016 2:37 AM, dalibor topic wrote: > Oracle no longer plans to create a separate JDK 8u122 PSU release. As > such, the proposed schedule for JDK 8u122 in this Project is no longer > accurate. > > Given the very small amount of changes that were destined specifically > for 8u122 (and not for 8u121 as well), the process to propose critical > fixes for inclusion in JDK 8u CPU releases [0] should be used instead, > where applicable. Do we label the original JBS issue, or the 8u backport issue? Thanks, David ----- > This holds for future changes to be integrated into jdk8u-dev forest, as > well as for already integrated changes that were destined for JDK 8u122. > > If you have questions or concerns, please share them on the jdk8u-dev > mailing list. > > cheers, > dalibor topic > > [0] http://openjdk.java.net/projects/jdk8u/criticalcpufixes.html From volker.simonis at gmail.com Thu Dec 15 12:00:17 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 15 Dec 2016 13:00:17 +0100 Subject: [8u] RFR(s) 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <58503693.8050904@linux.vnet.ibm.com> References: <584B21D9.20105@linux.vnet.ibm.com> <58503693.8050904@linux.vnet.ibm.com> Message-ID: Hi Gustavo, your changes look good, but you still use the new, backport bug id 8170873. Please update them to use the initial bug id 8170873. There's also no need to create a bug for a backport manually. Once you push a change with the original bug ID to the 8u-dev repositroy, a new downport issue will be automatically created for you. Once you've updated the webrevs and they are approved for 8u I can sponsor the change for you. Regards, Volker On Tue, Dec 13, 2016 at 6:57 PM, Gustavo Romero wrote: > Hi, > > Re-sending with the correct subject and adding the ppc-aix-port ML. > > Could the following webrev be reviewed please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/v2/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170873/v2/jdk/ > bug : https://bugs.openjdk.java.net/browse/JDK-8170873 > > It's a backport of 8170153: > > 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized > compilation > > Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 > Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ > Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ > Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html > URL 1/2 : http://hg.openjdk.java.net/jdk9/jdk9/rev/3c7b02f5fa7c > URL 2/2 : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b6bad6302dc8 > > The original change affects s390x and aarch64 as well but since both > architectures are not present on 8u both were excluded from this new webrev > turning it, in effect, a ppc-only fix on 8u. > > I understand that that change is particularly important to PPC64 since [1] is > not planned to be backported. > > I've tested the same way I did on 9 (jtreg) and no regression was observed [2]. > > I did not run against the JCK tests as performend by Martin [3] > since I'm still in the process of solving an issue related to the OCTLA. > > Thank you. > > > Regards, > Gustavo > > [1] https://bugs.openjdk.java.net/browse/JDK-8134780 > [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025283.html > [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025317.html > From gromero at linux.vnet.ibm.com Thu Dec 15 13:14:26 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 15 Dec 2016 11:14:26 -0200 Subject: [8u] RFR(s) 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <584B21D9.20105@linux.vnet.ibm.com> <58503693.8050904@linux.vnet.ibm.com> Message-ID: <58529732.3040704@linux.vnet.ibm.com> Hi Volker, On 15-12-2016 10:00, Volker Simonis wrote: > Hi Gustavo, > > your changes look good, but you still use the new, backport bug id > 8170873. Please update them to use the initial bug id 8170873. I've update to the same place: webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2 webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk > There's also no need to create a bug for a backport manually. Once you > push a change with the original bug ID to the 8u-dev repositroy, a new > downport issue will be automatically created for you. ah, ok. I'm sorry. It makes sense now. What is correct action to take regarding that manually opened bug now? > Once you've updated the webrevs and they are approved for 8u I can > sponsor the change for you. Thanks for reviewing and sponsoring it. I'll request the approval. Regards, Gustavo > > Regards, > Volker > > > > On Tue, Dec 13, 2016 at 6:57 PM, Gustavo Romero > wrote: >> Hi, >> >> Re-sending with the correct subject and adding the ppc-aix-port ML. >> >> Could the following webrev be reviewed please? >> >> webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/v2/ >> webrev 2/2: http://cr.openjdk.java.net/~gromero/8170873/v2/jdk/ >> bug : https://bugs.openjdk.java.net/browse/JDK-8170873 >> >> It's a backport of 8170153: >> >> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized >> compilation >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 >> Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ >> Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ >> Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html >> URL 1/2 : http://hg.openjdk.java.net/jdk9/jdk9/rev/3c7b02f5fa7c >> URL 2/2 : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b6bad6302dc8 >> >> The original change affects s390x and aarch64 as well but since both >> architectures are not present on 8u both were excluded from this new webrev >> turning it, in effect, a ppc-only fix on 8u. >> >> I understand that that change is particularly important to PPC64 since [1] is >> not planned to be backported. >> >> I've tested the same way I did on 9 (jtreg) and no regression was observed [2]. >> >> I did not run against the JCK tests as performend by Martin [3] >> since I'm still in the process of solving an issue related to the OCTLA. >> >> Thank you. >> >> >> Regards, >> Gustavo >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8134780 >> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025283.html >> [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025317.html >> > From aleksej.efimov at oracle.com Thu Dec 15 14:06:10 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 15 Dec 2016 17:06:10 +0300 Subject: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use" Message-ID: <82e0af2a-b250-a48f-75a3-34890755d6d3@oracle.com> Hi, Can I, please, have an approval to backport JDK-8146086 to 8u-dev. The source fix was slightly modified to remove stream/lamdba usages, therefore the fix is a subject to review. Webrev with 8u-dev changes: http://cr.openjdk.java.net/~aefimov/8146086/8/00/ The fix was tested with JPRT on all platforms - no failures observed. Best Regards, Aleksej JBS: https://bugs.openjdk.java.net/browse/JDK-8146086 JDK9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037984.html JDK9 changesets: http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/daffd583eb35 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/099e432fe59c From christoph.langer at sap.com Thu Dec 15 14:11:38 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 15 Dec 2016 14:11:38 +0000 Subject: 8u-dev: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type Message-ID: <7c791e24543d4c63ae8629ce8b6e0567@DEWDFE13DE03.global.corp.sap> Hi, please review(@Joe) & approve the downport of this regression fix. As it is a JAXP issue and includes a testcase, the change needs to be split into a jaxp part and a jdk part. The jaxp part applies cleanly after unshuffling, the JDK part had to be modified to fit into the jdk8 layout. Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 JAXP: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jaxp.8udev/ JDK: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/ Thanks & best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Mittwoch, 14. Dezember 2016 21:52 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net; Aleks Efimov ; jeff Dinkins Subject: Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) Register 10 contains wrong type I guess I should also request a downport to jdk8 immediately, as it is a regression, right? Yes, that would be great. Please create a patch for JDK 8 or work with Aleksej (Aleksej backported your previous patch), and ask for approval through the jdk8-dev alias. Best, Joe From huizhe.wang at oracle.com Thu Dec 15 18:08:03 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 15 Dec 2016 10:08:03 -0800 Subject: 8u-dev: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type In-Reply-To: <7c791e24543d4c63ae8629ce8b6e0567@DEWDFE13DE03.global.corp.sap> References: <7c791e24543d4c63ae8629ce8b6e0567@DEWDFE13DE03.global.corp.sap> Message-ID: <5852DC03.1060503@oracle.com> Hi Christoph, The patches look good to me. Thanks, Joe On 12/15/16, 6:11 AM, Langer, Christoph wrote: > > Hi, > > please review(@Joe) & approve the downport of this regression fix. As > it is a JAXP issue and includes a testcase, the change needs to be > split into a jaxp part and a jdk part. > > The jaxp part applies cleanly after unshuffling, the JDK part had to > be modified to fit into the jdk8 layout. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 > > JAXP: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jaxp.8udev/ > > > JDK: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/ > > > Thanks & best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Mittwoch, 14. Dezember 2016 21:52 > *To:* Langer, Christoph > *Cc:* core-libs-dev at openjdk.java.net; Aleks Efimov > ; jeff Dinkins > *Subject:* Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: > GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) > Register 10 contains wrong type > > > I guess I should also request a downport to jdk8 immediately, as > it is a regression, right? > > > Yes, that would be great. Please create a patch for JDK 8 or work with > Aleksej (Aleksej backported your previous patch), and ask for approval > through the jdk8-dev alias. > > Best, > Joe > From gromero at linux.vnet.ibm.com Thu Dec 15 21:12:23 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 15 Dec 2016 19:12:23 -0200 Subject: [8u] Request for approval for 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <58494B80.8050904@linux.vnet.ibm.com> References: <58486B24.9060005@linux.vnet.ibm.com> <92c612f1-0d97-a883-7654-3960954f7b42@oracle.com> <58494B80.8050904@linux.vnet.ibm.com> Message-ID: <58530737.5090305@linux.vnet.ibm.com> Hi, Re-submitting it for approval as it's now reviewed on 8u: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-December/006248.html Could you please approve the backport to jdk8u-dev of the following fix: 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html URL 1/2 : http://hg.openjdk.java.net/jdk9/dev/rev/3c7b02f5fa7c URL 2/2 : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b6bad6302dc8 The original change affects s390x and aarch64 as well but since both architectures are not present on 8u, it's a ppc-only fix on 8u: webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2 webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk Thank you. Regards, Gustavo From rob.mckenna at oracle.com Thu Dec 15 21:41:12 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 15 Dec 2016 21:41:12 +0000 Subject: [8u] Request for approval for 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <58530737.5090305@linux.vnet.ibm.com> References: <58486B24.9060005@linux.vnet.ibm.com> <92c612f1-0d97-a883-7654-3960954f7b42@oracle.com> <58494B80.8050904@linux.vnet.ibm.com> <58530737.5090305@linux.vnet.ibm.com> Message-ID: <20161215214112.GD2475@vimes> Please add the appropriate noreg label to the bug. (noreg-build?) Approved. -Rob On 15/12/16 07:12, Gustavo Romero wrote: > Hi, > > Re-submitting it for approval as it's now reviewed on 8u: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-December/006248.html > > Could you please approve the backport to jdk8u-dev of the following fix: > > 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized > compilation > > Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 > Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ > Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ > Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html > URL 1/2 : http://hg.openjdk.java.net/jdk9/dev/rev/3c7b02f5fa7c > URL 2/2 : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b6bad6302dc8 > > The original change affects s390x and aarch64 as well but since both > architectures are not present on 8u, it's a ppc-only fix on 8u: > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2 > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk > > Thank you. > > > Regards, > Gustavo > From christoph.langer at sap.com Fri Dec 16 07:35:35 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 16 Dec 2016 07:35:35 +0000 Subject: [8u-dev] Request for approval: 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type Message-ID: <8d587a3e043742b7abcb58a43bdfb4ee@DEWDFE13DE03.global.corp.sap> Hi, please approve this downport. Changes have been reviewed by Joe. Thanks Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Donnerstag, 15. Dezember 2016 19:08 To: Langer, Christoph Cc: jdk8u-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Aleks Efimov ; jeff Dinkins Subject: Re: 8u-dev: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) Register 10 contains wrong type Hi Christoph, The patches look good to me. Thanks, Joe On 12/15/16, 6:11 AM, Langer, Christoph wrote: Hi, please review(@Joe) & approve the downport of this regression fix. As it is a JAXP issue and includes a testcase, the change needs to be split into a jaxp part and a jdk part. The jaxp part applies cleanly after unshuffling, the JDK part had to be modified to fit into the jdk8 layout. Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 JAXP: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jaxp.8udev/ JDK: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/ Thanks & best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Mittwoch, 14. Dezember 2016 21:52 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net; Aleks Efimov ; jeff Dinkins Subject: Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) Register 10 contains wrong type I guess I should also request a downport to jdk8 immediately, as it is a regression, right? Yes, that would be great. Please create a patch for JDK 8 or work with Aleksej (Aleksej backported your previous patch), and ask for approval through the jdk8-dev alias. Best, Joe From david.buck at oracle.com Fri Dec 16 07:49:40 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 16 Dec 2016 16:49:40 +0900 Subject: [8u-dev] Request for approval: 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type In-Reply-To: <8d587a3e043742b7abcb58a43bdfb4ee@DEWDFE13DE03.global.corp.sap> References: <8d587a3e043742b7abcb58a43bdfb4ee@DEWDFE13DE03.global.corp.sap> Message-ID: <58539C94.4010408@oracle.com> approved for push to jdk8u-dev Cheers, -Buck On 2016/12/16 16:35, Langer, Christoph wrote: > Hi, > > please approve this downport. Changes have been reviewed by Joe. > > Thanks > Christoph > > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Sent: Donnerstag, 15. Dezember 2016 19:08 > To: Langer, Christoph > Cc: jdk8u-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Aleks Efimov ; jeff Dinkins > Subject: Re: 8u-dev: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) Register 10 contains wrong type > > Hi Christoph, > > The patches look good to me. > > Thanks, > Joe > > On 12/15/16, 6:11 AM, Langer, Christoph wrote: > Hi, > > please review(@Joe) & approve the downport of this regression fix. As it is a JAXP issue and includes a testcase, the change needs to be split into a jaxp part and a jdk part. > > The jaxp part applies cleanly after unshuffling, the JDK part had to be modified to fit into the jdk8 layout. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 > JAXP: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jaxp.8udev/ > JDK: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/ > > Thanks & best regards > Christoph > > > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 21:52 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; Aleks Efimov ; jeff Dinkins > Subject: Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) Register 10 contains wrong type > > > > I guess I should also request a downport to jdk8 immediately, as it is a regression, right? > > Yes, that would be great. Please create a patch for JDK 8 or work with Aleksej (Aleksej backported your previous patch), and ask for approval through the jdk8-dev alias. > > Best, > Joe > > From gromero at linux.vnet.ibm.com Fri Dec 16 14:14:05 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 16 Dec 2016 12:14:05 -0200 Subject: [8u] Request for approval for 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <20161215214112.GD2475@vimes> References: <58486B24.9060005@linux.vnet.ibm.com> <92c612f1-0d97-a883-7654-3960954f7b42@oracle.com> <58494B80.8050904@linux.vnet.ibm.com> <58530737.5090305@linux.vnet.ibm.com> <20161215214112.GD2475@vimes> Message-ID: <5853F6AD.7000206@linux.vnet.ibm.com> Hi Rob, Thanks. I added the no regression test label since it only affects build infrastructure as you requested. Gustavo On 15-12-2016 19:41, Rob McKenna wrote: > Please add the appropriate noreg label to the bug. (noreg-build?) > > Approved. > > -Rob > > On 15/12/16 07:12, Gustavo Romero wrote: >> Hi, >> >> Re-submitting it for approval as it's now reviewed on 8u: >> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-December/006248.html >> >> Could you please approve the backport to jdk8u-dev of the following fix: >> >> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized >> compilation >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 >> Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ >> Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ >> Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html >> URL 1/2 : http://hg.openjdk.java.net/jdk9/dev/rev/3c7b02f5fa7c >> URL 2/2 : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b6bad6302dc8 >> >> The original change affects s390x and aarch64 as well but since both >> architectures are not present on 8u, it's a ppc-only fix on 8u: >> >> webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2 >> webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk >> >> Thank you. >> >> >> Regards, >> Gustavo >> > From rob.mckenna at oracle.com Fri Dec 16 20:27:58 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 16 Dec 2016 20:27:58 +0000 Subject: [8u-dev] Request for approval - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections Message-ID: <20161216202758.GG2452@vimes> Hi folks, Looking for approval for this clean backport to 8: bug: https://bugs.openjdk.java.net/browse/JDK-8169465 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/164b346d89b2 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045541.html -Rob From sean.coffey at oracle.com Sat Dec 17 17:43:21 2016 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Sat, 17 Dec 2016 17:43:21 +0000 Subject: [8u-dev] Request for approval - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections In-Reply-To: <20161216202758.GG2452@vimes> References: <20161216202758.GG2452@vimes> Message-ID: <006E2254-7A9A-47BE-9B59-B883EF4C25EE@oracle.com> Approved. Regards, Sean. On 16 December 2016 20:27:58 GMT+00:00, Rob McKenna wrote: >Hi folks, > >Looking for approval for this clean backport to 8: > >bug: https://bugs.openjdk.java.net/browse/JDK-8169465 >changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/164b346d89b2 >review: >http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045541.html > > -Rob From christoph.langer at sap.com Mon Dec 19 10:08:38 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 19 Dec 2016 10:08:38 +0000 Subject: [8u-dev] Request for approval: 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type In-Reply-To: <58539C94.4010408@oracle.com> References: <8d587a3e043742b7abcb58a43bdfb4ee@DEWDFE13DE03.global.corp.sap> <58539C94.4010408@oracle.com> Message-ID: Thanks, the fix is pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jaxp/rev/e73eb9ed69f6 http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/71215ac21d10 @Joe: I don't know into which patch 8u*** this fix will go by default now. I leave it to you if you want to accelerate this into an earlier fix, as it is a regression... Best regards Christoph > -----Original Message----- > From: David Buck [mailto:david.buck at oracle.com] > Sent: Freitag, 16. Dezember 2016 08:50 > To: Langer, Christoph ; jdk8u- > dev at openjdk.java.net > Subject: Re: [8u-dev] Request for approval: 8169112: java.lang.VerifyError: > (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) > Register 10 contains wrong type > > approved for push to jdk8u-dev > > Cheers, > -Buck > > On 2016/12/16 16:35, Langer, Christoph wrote: > > Hi, > > > > please approve this downport. Changes have been reviewed by Joe. > > > > Thanks > > Christoph > > > > From: Joe Wang [mailto:huizhe.wang at oracle.com] > > Sent: Donnerstag, 15. Dezember 2016 19:08 > > To: Langer, Christoph > > Cc: jdk8u-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Aleks > Efimov ; jeff Dinkins > > Subject: Re: 8u-dev: RFR (JAXP): 8169112: java.lang.VerifyError: (class: > GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) Register > 10 contains wrong type > > > > Hi Christoph, > > > > The patches look good to me. > > > > Thanks, > > Joe > > > > On 12/15/16, 6:11 AM, Langer, Christoph wrote: > > Hi, > > > > please review(@Joe) & approve the downport of this regression fix. As it is a > JAXP issue and includes a testcase, the change needs to be split into a jaxp part > and a jdk part. > > > > The jaxp part applies cleanly after unshuffling, the JDK part had to be > modified to fit into the jdk8 layout. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 > > JAXP: > http://cr.openjdk.java.net/~clanger/webrevs/8169112_jaxp.8udev/ enjdk.java.net/%7Eclanger/webrevs/8169112_jaxp.8udev/> > > JDK: > http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/ njdk.java.net/%7Eclanger/webrevs/8169112_jdk.8udev/> > > > > Thanks & best regards > > Christoph > > > > > > From: Joe Wang [mailto:huizhe.wang at oracle.com] > > Sent: Mittwoch, 14. Dezember 2016 21:52 > > To: Langer, Christoph > > > Cc: core-libs-dev at openjdk.java.net; > Aleks Efimov > ; jeff > Dinkins > > Subject: Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, > method: template-bash signature: (LGregorSamsa8;)V) Register 10 contains > wrong type > > > > > > > > I guess I should also request a downport to jdk8 immediately, as it is a > regression, right? > > > > Yes, that would be great. Please create a patch for JDK 8 or work with Aleksej > (Aleksej backported your previous patch), and ask for approval through the > jdk8-dev alias. > > > > Best, > > Joe > > > > From aleksej.efimov at oracle.com Mon Dec 19 15:53:17 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 19 Dec 2016 18:53:17 +0300 Subject: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use" In-Reply-To: <82e0af2a-b250-a48f-75a3-34890755d6d3@oracle.com> References: <82e0af2a-b250-a48f-75a3-34890755d6d3@oracle.com> Message-ID: <7e4164c5-084d-fdee-acc2-2289aef677eb@oracle.com> Hi, Can I, please, ask JDK8 reviewer to look through the backported changes? Thanks, Aleksej On 15/12/16 17:06, Aleks Efimov wrote: > Hi, > Can I, please, have an approval to backport JDK-8146086 to 8u-dev. > The source fix was slightly modified to remove stream/lamdba usages, > therefore the fix is a subject to review. > Webrev with 8u-dev changes: > http://cr.openjdk.java.net/~aefimov/8146086/8/00/ > > The fix was tested with JPRT on all platforms - no failures observed. > > Best Regards, > Aleksej > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8146086 > > JDK9 review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037984.html > > > JDK9 changesets: > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/daffd583eb35 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/099e432fe59c > From zoltan.majo at oracle.com Mon Dec 19 16:01:19 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 19 Dec 2016 17:01:19 +0100 Subject: [8u] Request for approval and review: 8157181, 8160551, and 8171155 Message-ID: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com> Hi, please approve (and review in case of 8157181) the following backports to 8u: https://bugs.openjdk.java.net/browse/JDK-8157181 https://bugs.openjdk.java.net/browse/JDK-8160551 https://bugs.openjdk.java.net/browse/JDK-8171155 8160551 and 8171155 cleanly apply to 8u. As suggested by John Rose in a comment for 8159215, only a part of the 8157181 fix for 9 is backported to 8u. As a result, the backport of 8157181 does not apply cleanly to 8u (thus the review request). Here is the webrev for that change: http://cr.openjdk.java.net/~zmajo/8157181_8u/webrev.00/ I tested the three changes combined with JPRT, all tests pass. Thank you! Best regards, Zoltan From volker.simonis at gmail.com Mon Dec 19 16:56:45 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 19 Dec 2016 17:56:45 +0100 Subject: [8u] Request for approval for 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5853F6AD.7000206@linux.vnet.ibm.com> References: <58486B24.9060005@linux.vnet.ibm.com> <92c612f1-0d97-a883-7654-3960954f7b42@oracle.com> <58494B80.8050904@linux.vnet.ibm.com> <58530737.5090305@linux.vnet.ibm.com> <20161215214112.GD2475@vimes> <5853F6AD.7000206@linux.vnet.ibm.com> Message-ID: Thanks Rob, Gustavo, I've just pushed the changes to jdk8u-dev. Regards, Volker On Fri, Dec 16, 2016 at 3:14 PM, Gustavo Romero wrote: > Hi Rob, > > Thanks. I added the no regression test label since it only affects build > infrastructure as you requested. > > Gustavo > > On 15-12-2016 19:41, Rob McKenna wrote: >> Please add the appropriate noreg label to the bug. (noreg-build?) >> >> Approved. >> >> -Rob >> >> On 15/12/16 07:12, Gustavo Romero wrote: >>> Hi, >>> >>> Re-submitting it for approval as it's now reviewed on 8u: >>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-December/006248.html >>> >>> Could you please approve the backport to jdk8u-dev of the following fix: >>> >>> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized >>> compilation >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8170153 >>> Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ >>> Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ >>> Review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html >>> URL 1/2 : http://hg.openjdk.java.net/jdk9/dev/rev/3c7b02f5fa7c >>> URL 2/2 : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b6bad6302dc8 >>> >>> The original change affects s390x and aarch64 as well but since both >>> architectures are not present on 8u, it's a ppc-only fix on 8u: >>> >>> webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2 >>> webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk >>> >>> Thank you. >>> >>> >>> Regards, >>> Gustavo >>> >> > From david.holmes at oracle.com Mon Dec 19 21:11:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Dec 2016 07:11:38 +1000 Subject: [8u] Request for enhancement backport approval for CR 8170888: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments Message-ID: <39b485f8-b705-562c-d07e-11772d3d2f21@oracle.com> Please consider approving this enhancement for 8u: https://bugs.openjdk.java.net/browse/JDK-8170888 This enhancement adds experimental support for observing the memory limits imposed by Linux cgroups, and in particular a container environment like Docker. As this is an opt-in, experimental, VM option, there is zero risk associated with this enhancement. Thanks, David From david.holmes at oracle.com Mon Dec 19 21:14:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Dec 2016 07:14:18 +1000 Subject: [8u] Request for approval for CR 8147910 and CR 8161993 In-Reply-To: References: Message-ID: <3ad17363-1221-f1dd-501a-61e00d6bbd88@oracle.com> Please approve these two related backports for 8u. They complement the existing backport of: JDK-6515172: Runtime.availableProcessors() ignores Linux taskset command which reports actual number of active processors when running in a cpuset constrained environment (like Docker). That by itself won't cause G1 to adjust the number of GC worker threads, and the other GC's may be adversely impacted if the number of processors were to change during execution of the VM. To address that we also need to back port the following: - JDK-8147910 Cache initial active_processor_count Bug: https://bugs.openjdk.java.net/browse/JDK-8147910 JDK9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/42bdfbb535a2 This changes applies cleanly other than a unified logging line which was deleted. - JDK-8161993 G1 crashes if active_processor_count changes during startup Bug: https://bugs.openjdk.java.net/browse/JDK-8161993 JDK9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8986e5b85e73 This change could not apply directly due to file and directory renaming in JDK 9. For good measure I had it re-reviewed: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-December/019361.html Thank you, David From rob.mckenna at oracle.com Mon Dec 19 21:40:48 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 19 Dec 2016 21:40:48 +0000 Subject: [8u] Request for enhancement backport approval for CR 8170888: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments In-Reply-To: <39b485f8-b705-562c-d07e-11772d3d2f21@oracle.com> References: <39b485f8-b705-562c-d07e-11772d3d2f21@oracle.com> Message-ID: <20161219214048.GB2598@vimes> Thanks for the request. Its under review. -Rob On 20/12/16 07:11, David Holmes wrote: > Please consider approving this enhancement for 8u: > > https://bugs.openjdk.java.net/browse/JDK-8170888 > > This enhancement adds experimental support for observing the memory limits > imposed by Linux cgroups, and in particular a container environment like > Docker. > > As this is an opt-in, experimental, VM option, there is zero risk associated > with this enhancement. > > Thanks, > David From rob.mckenna at oracle.com Mon Dec 19 21:41:03 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 19 Dec 2016 21:41:03 +0000 Subject: [8u] Request for approval for CR 8147910 and CR 8161993 In-Reply-To: <3ad17363-1221-f1dd-501a-61e00d6bbd88@oracle.com> References: <3ad17363-1221-f1dd-501a-61e00d6bbd88@oracle.com> Message-ID: <20161219214103.GC2598@vimes> Approved -Rob On 20/12/16 07:14, David Holmes wrote: > > Please approve these two related backports for 8u. They complement the > existing backport of: > > JDK-6515172: Runtime.availableProcessors() ignores Linux taskset command > > which reports actual number of active processors when running in a cpuset > constrained environment (like Docker). That by itself won't cause G1 to > adjust the number of GC worker threads, and the other GC's may be adversely > impacted if the number of processors were to change during execution of the > VM. To address that we also need to back port the following: > > - JDK-8147910 Cache initial active_processor_count > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147910 > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/42bdfbb535a2 > > This changes applies cleanly other than a unified logging line which was > deleted. > > - JDK-8161993 G1 crashes if active_processor_count changes during startup > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161993 > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8986e5b85e73 > > This change could not apply directly due to file and directory renaming in > JDK 9. For good measure I had it re-reviewed: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-December/019361.html > > Thank you, > David From vladimir.kozlov at oracle.com Mon Dec 19 21:53:31 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Dec 2016 13:53:31 -0800 Subject: [8u] Request for approval and review: 8157181, 8160551, and 8171155 In-Reply-To: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com> References: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com> Message-ID: <77391954-5386-ce4b-39f3-10769d038945@oracle.com> Looks good to me. Thanks, Vladimir On 12/19/16 8:01 AM, Zolt?n Maj? wrote: > Hi, > > > please approve (and review in case of 8157181) the following backports > to 8u: > > https://bugs.openjdk.java.net/browse/JDK-8157181 > https://bugs.openjdk.java.net/browse/JDK-8160551 > https://bugs.openjdk.java.net/browse/JDK-8171155 > > 8160551 and 8171155 cleanly apply to 8u. > > As suggested by John Rose in a comment for 8159215, only a part of the > 8157181 fix for 9 is backported to 8u. As a result, the backport of > 8157181 does not apply cleanly to 8u (thus the review request). Here is > the webrev for that change: > > http://cr.openjdk.java.net/~zmajo/8157181_8u/webrev.00/ > > I tested the three changes combined with JPRT, all tests pass. > > Thank you! > > Best regards, > > > Zoltan > From rob.mckenna at oracle.com Mon Dec 19 22:51:56 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 19 Dec 2016 22:51:56 +0000 Subject: [8u] Request for approval and review: 8157181, 8160551, and 8171155 In-Reply-To: <77391954-5386-ce4b-39f3-10769d038945@oracle.com> References: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com> <77391954-5386-ce4b-39f3-10769d038945@oracle.com> Message-ID: <20161219225156.GA4231@vimes> Approved -Rob On 19/12/16 01:53, Vladimir Kozlov wrote: > Looks good to me. > > Thanks, > Vladimir > > On 12/19/16 8:01 AM, Zolt?n Maj? wrote: > >Hi, > > > > > >please approve (and review in case of 8157181) the following backports > >to 8u: > > > >https://bugs.openjdk.java.net/browse/JDK-8157181 > >https://bugs.openjdk.java.net/browse/JDK-8160551 > >https://bugs.openjdk.java.net/browse/JDK-8171155 > > > >8160551 and 8171155 cleanly apply to 8u. > > > >As suggested by John Rose in a comment for 8159215, only a part of the > >8157181 fix for 9 is backported to 8u. As a result, the backport of > >8157181 does not apply cleanly to 8u (thus the review request). Here is > >the webrev for that change: > > > >http://cr.openjdk.java.net/~zmajo/8157181_8u/webrev.00/ > > > >I tested the three changes combined with JPRT, all tests pass. > > > >Thank you! > > > >Best regards, > > > > > >Zoltan > > From david.holmes at oracle.com Tue Dec 20 00:10:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Dec 2016 10:10:34 +1000 Subject: [8u] Request for approval 8170307: Stack size option -Xss is ignored Message-ID: <5c49f4ab-3a57-d9c2-838f-2d0b7aa5ae66@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8170307 (not public) This change removes an ancient workaround that limited the usable stack of the primordial process thread to 2MB. This only affects applications that use the JNI invocation API to load the VM in the primordial process thread. The stack size will now be controlled by the -Xss stack option and the OS limit (specified through rlimit). In the corner case where no Java stack size is specified and rlimit is unlimited, then we impose a 8MB limit as done on Solaris. JDK 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3abc9ec542ab 8u webrev: http://cr.openjdk.java.net/~dholmes/8170307/webrev.8u/ As the patch did not apply directly due to the amount of change in the file in JDK 9 I had it re-reviewed here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-December/022151.html Thanks, David From zoltan.majo at oracle.com Tue Dec 20 08:55:28 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 20 Dec 2016 09:55:28 +0100 Subject: [8u] Request for approval and review: 8157181, 8160551, and 8171155 In-Reply-To: <20161219225156.GA4231@vimes> References: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com> <77391954-5386-ce4b-39f3-10769d038945@oracle.com> <20161219225156.GA4231@vimes> Message-ID: <9ef72691-121d-91a0-f0e9-b41f6e8b616b@oracle.com> Thank you, Vladimir, for the review! Thank you, Rob, for approving! Best regards, Zoltan On 12/19/2016 11:51 PM, Rob McKenna wrote: > Approved > > -Rob > > On 19/12/16 01:53, Vladimir Kozlov wrote: >> Looks good to me. >> >> Thanks, >> Vladimir >> >> On 12/19/16 8:01 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please approve (and review in case of 8157181) the following backports >>> to 8u: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157181 >>> https://bugs.openjdk.java.net/browse/JDK-8160551 >>> https://bugs.openjdk.java.net/browse/JDK-8171155 >>> >>> 8160551 and 8171155 cleanly apply to 8u. >>> >>> As suggested by John Rose in a comment for 8159215, only a part of the >>> 8157181 fix for 9 is backported to 8u. As a result, the backport of >>> 8157181 does not apply cleanly to 8u (thus the review request). Here is >>> the webrev for that change: >>> >>> http://cr.openjdk.java.net/~zmajo/8157181_8u/webrev.00/ >>> >>> I tested the three changes combined with JPRT, all tests pass. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> From sean.coffey at oracle.com Tue Dec 20 09:40:03 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 20 Dec 2016 09:40:03 +0000 Subject: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use" In-Reply-To: <7e4164c5-084d-fdee-acc2-2289aef677eb@oracle.com> References: <82e0af2a-b250-a48f-75a3-34890755d6d3@oracle.com> <7e4164c5-084d-fdee-acc2-2289aef677eb@oracle.com> Message-ID: Looks fine Aleksej. Approved for jdk8u-dev. regards, Sean. On 19/12/2016 15:53, Aleks Efimov wrote: > Hi, > > Can I, please, ask JDK8 reviewer to look through the backported changes? > > Thanks, > Aleksej > > On 15/12/16 17:06, Aleks Efimov wrote: >> Hi, >> Can I, please, have an approval to backport JDK-8146086 to 8u-dev. >> The source fix was slightly modified to remove stream/lamdba usages, >> therefore the fix is a subject to review. >> Webrev with 8u-dev changes: >> http://cr.openjdk.java.net/~aefimov/8146086/8/00/ >> >> The fix was tested with JPRT on all platforms - no failures observed. >> >> Best Regards, >> Aleksej >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8146086 >> >> JDK9 review thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037984.html >> >> >> JDK9 changesets: >> http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/daffd583eb35 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/099e432fe59c >> > From rob.mckenna at oracle.com Tue Dec 20 14:58:41 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 20 Dec 2016 14:58:41 +0000 Subject: [8u] Request for approval 8170307: Stack size option -Xss is ignored In-Reply-To: <5c49f4ab-3a57-d9c2-838f-2d0b7aa5ae66@oracle.com> References: <5c49f4ab-3a57-d9c2-838f-2d0b7aa5ae66@oracle.com> Message-ID: <20161220145841.GA2371@vimes> Approved -Rob On 20/12/16 10:10, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8170307 (not public) > > This change removes an ancient workaround that limited the usable stack of > the primordial process thread to 2MB. This only affects applications that > use the JNI invocation API to load the VM in the primordial process thread. > The stack size will now be controlled by the -Xss stack option and the OS > limit (specified through rlimit). In the corner case where no Java stack > size is specified and rlimit is unlimited, then we impose a 8MB limit as > done on Solaris. > > JDK 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/3abc9ec542ab > > 8u webrev: http://cr.openjdk.java.net/~dholmes/8170307/webrev.8u/ > > As the patch did not apply directly due to the amount of change in the file > in JDK 9 I had it re-reviewed here: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-December/022151.html > > Thanks, > David From peter at asgalon.net Tue Dec 20 15:45:07 2016 From: peter at asgalon.net (Peter Koellner) Date: Tue, 20 Dec 2016 16:45:07 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment Message-ID: Hi! I have been trying for a week now to build openjdk8 for windows, until now with disappointing results. I wasted half a week starting out with windows 10 and the jdk8 repository, and now have a windows7 home 64bit with 32bit cygwin 2.6 and the last stable version cloned from jdk8u following http://openjdk.java.net/projects/jdk8u/. Unfortunately, I still do not reach a useable runtime environment though the bootcycle-image builds without errors. Make test runs for about 4 hours on my vm and results in quite a large number of failed tests, the runtime throws exceptions because it cannot initialize the fontmanager when opening a JFrame. Before going into the details too much, this is a stable release that is supposed to build cleany and work properly, right? So the real problem is the build environment and maybe the configuration. Could someone please point me to valid instructions how to set up a valid build environment to produce a 32bit runtime for Windows? The reason for all this exercise is that we have a third-party-applet for some smartcard application which we need to persuade to use a configured network share location as "user.home" system property. So the idea is to change jdk/src/windows/native/java/lang/java_props_md.c to look for a registry key string value before setting a default value instead of using this KnownFolder id thingy. So: Since the result after configuring the thing still comes out broken, the autoconf scripts are missing vital environment configuration details. So, I would like to have the following information: - What exact windows version do I need to build the 32bit stable release build? Do I need a 32bit Windows for that? Which one? XP? Windows 7? Windows 8? Windows Server 2008? R2? - cygwin 32 bit is now at version 2.6. Does this work or do I need some ancient version? - What exact version of the freetype library do I have to install? I followed the installation instructions from the .configure script. - I am using Visual Studio C++ Express 2010 as below: Microsoft Visual Studio 2010 Version 10.0.30319.1 RTMRel Microsoft .NET Framework Version 4.0.30319 RTMRel Installed Version: VC Express Microsoft Visual C++ 2010 01013-532-2002287-70533 Microsoft Visual C++ 2010 The VM is set up as follows (from VS express info): Sistema operativo Microsoft Windows 7 Home Premium Versi?n 6.1.7601 Service Pack 1 Compilaci?n 7601 Descripci?n adicional del sistema operativo No disponible Fabricante del sistema operativo Microsoft Corporation Nombre del sistema WIN7VM Fabricante del sistema innotek GmbH Modelo del sistema VirtualBox Tipo de sistema PC basado en x64 Procesador Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, 2660 Mhz, 2 procesadores principales, 2 procesadores l?gicos Versi?n y fecha de BIOS innotek GmbH VirtualBox, 01.12.2006 Versi?n de SMBIOS 2.5 Directorio de Windows C:\Windows Directorio del sistema C:\Windows\system32 Dispositivo de arranque \Device\HarddiskVolume1 Configuraci?n regional Deutschland Capa de abstracci?n de hardware Versi?n = "6.1.7601.17514" Nombre de usuario WIN7VM\Peter Zona horaria Hora est?ndar Europa Occidental Memoria f?sica instalada (RAM) No disponible Memoria f?sica total 4,00 GB Memoria f?sica disponible 991 MB Memoria virtual total 8,00 GB Memoria virtual disponible 5,29 GB Espacio de archivo de paginaci?n 4,00 GB Archivo de paginaci?n C:\pagefile.sys cl says Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86 Well, I have a spanish windows now, that is part of the problem, since thanks to microsoft the home edition can't switch locale to english, which is a reason for several tests to fail because they test for en_US formatted output strings, and maybe there are other problems. Before I go and buy some obscure ancient windows version, I want to be pretty sure that it is the right one for this task. I have now installed JDK 1.7.0_80 as boot jdk. configure options are now: ./configure --with-boot-jdk=/cygdrive/c/Program\ Files\ \(x86\)/Java/jdk1.7.0_80\ --with-target-bits=32 \ --enable-unlimited-crypto \ --enable-debug \ --with-conf-name=windows-x86-normal-server-fastdebug \ --with-cacerts-file=/cygdrive/c/openjdk/cacerts \ --disable-debug-symbols \ --disable-zip-debug-info \ --with-milestone=conectalex \ --with-build-number=666 \ --disable-ccache \ --with-jtreg=c:/openjdk/jtreg previously, with same result: ./configure --with-boot-jdk=/cygdrive/c/Program\ Files\ \(x86\)/Java/jdk1.7.0_80\ --with-target-bits=32 \ --enable-unlimited-crypto \ --with-cacerts-file=/cygdrive/c/openjdk/cacerts \ --disable-debug-symbols \ --disable-zip-debug-info \ --with-milestone=conectalex \ --with-build-number=666 \ --disable-ccache \ --with-jtreg=c:/openjdk/jtreg Anything I am missing here? I am not sure if it is only a problem of the freetype library, sine there are test failures from the cryptography library: Test results: passed: 3.744; failed: 26 Report written to C:\openjdk\jdk8u\build\windows-x86-normal-server-release\testoutput\jdk_core\JTreport\html\report.html Results written to C:\openjdk\jdk8u\build\windows-x86-normal-server-release\testoutput\jdk_core\JTwork Error: Some tests failed or other problems occurred. Summary: jdk_core FAILED: Coincidencia FAILED: com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithDefaultProvider.java FAILED: com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java FAILED: com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java FAILED: com/sun/crypto/provider/Cipher/Blowfish/TestCipherBlowfish.java FAILED: com/sun/crypto/provider/Cipher/PBE/PBESameBuffer/PBESameBuffer.java FAILED: com/sun/crypto/provider/Cipher/PBE/TestCipherKeyWrapperPBEKey.java FAILED: com/sun/crypto/provider/Cipher/PBE/TestCipherPBE.java FAILED: com/sun/crypto/provider/Cipher/PBE/TestCipherPBECons.java FAILED: java/net/ipv6tests/TcpTest.java FAILED: java/net/ipv6tests/UdpTest.java FAILED: java/rmi/activation/checkusage/CheckUsage.java FAILED: java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java FAILED: java/security/KeyStore/PKCS12/KeytoolReaderP12Test.java FAILED: java/util/logging/LocalizedLevelName.java FAILED: java/util/logging/SimpleFormatterFormat.java FAILED: javax/security/auth/login/LoginContext/DynamicConfigurationTest.java FAILED: jdk/lambda/LambdaTranslationTest1.java FAILED: jdk/lambda/LambdaTranslationTest2.java FAILED: sun/misc/Version/Version.java FAILED: sun/security/pkcs11/rsa/TestCACerts.java FAILED: sun/security/rsa/TestCACerts.java FAILED: sun/security/tools/keytool/file-in-help.sh FAILED: sun/security/tools/keytool/newhelp.sh FAILED: sun/security/tools/keytool/printssl.sh FAILED: sun/util/logging/SourceClassName.java TEST STATS: name=jdk_core run=3770 pass=3744 fail=26 (this was from the last run yesterday, I am running a new test now with JAVA_VM_ARGS="-Duser.language=en -Duser.country=us" to get rid of i18n problems, but it will take a couple of hours and I already see crypto tests failing)) So what I urgently need is precise instructions how to set up a build environment for a windows 32bit build for openjkd8u latest stable release. -- peter kollner From akashche at redhat.com Tue Dec 20 18:55:06 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 20 Dec 2016 18:55:06 +0000 Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: References: Message-ID: <58597E8A.2040309@redhat.com> Hi Peter, On 12/20/2016 03:45 PM, Peter Koellner wrote: > > [...] > > - What exact windows version do I need to build the 32bit stable release > build? Do I need a 32bit Windows for that? Which one? XP? Windows 7? > Windows 8? Windows Server 2008? R2? According to wiki [1] Windows 2008 R2 64-bit works for building 32-bit jdk8. I think any recent (Win7+) version should work. > - cygwin 32 bit is now at version 2.6. Does this work or do I need some > ancient version? I don't think there are strict requirements about Cygwin version. I can suggest using a version that was current at the time of jdk8 release (early 2014). > - What exact version of the freetype library do I have to install? I > followed the installation instructions from the .configure script. I think any 2.3+ version of a FreeType should work. > - I am using Visual Studio C++ Express 2010 as below: VS2010 Express should be enough to build 32-bit binaries. You'll need VS2010 Pro or WinSDK 7.1 for 64-bit ones. > > [...] > > Well, I have a spanish windows now, I can suggest using only english windows locale for jdk builds. > > [...] > [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms#SupportedBuildPlatforms-JDK8buildplatformssupportedbyOracle -- -Alex From peter at asgalon.net Wed Dec 21 01:42:24 2016 From: peter at asgalon.net (Peter Koellner) Date: Wed, 21 Dec 2016 02:42:24 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: <58597E8A.2040309@redhat.com> References: <58597E8A.2040309@redhat.com> Message-ID: Hi! On Tue, 20 Dec 2016, Alex Kashchenko wrote: >> - What exact windows version do I need to build the 32bit stable release >> build? Do I need a 32bit Windows for that? Which one? XP? Windows 7? >> Windows 8? Windows Server 2008? R2? > > According to wiki [1] Windows 2008 R2 64-bit works for building 32-bit jdk8. > I think any recent (Win7+) version should work. I thought that too, since when the build process works, the resulting image should depend on the compiler and the built libraries, but not on the build runtime. >> - cygwin 32 bit is now at version 2.6. Does this work or do I need some >> ancient version? > > I don't think there are strict requirements about Cygwin version. I can > suggest using a version that was current at the time of jdk8 release (early > 2014). > >> - What exact version of the freetype library do I have to install? I >> followed the installation instructions from the .configure script. > > I think any 2.3+ version of a FreeType should work. It is 2.3.5 > >> - I am using Visual Studio C++ Express 2010 as below: > > VS2010 Express should be enough to build 32-bit binaries. You'll need VS2010 > Pro or WinSDK 7.1 for 64-bit ones. > >> >> [...] >> >> Well, I have a spanish windows now, > > I can suggest using only english windows locale for jdk builds. I have located a download link for windows 2008 SP1 and will try that next. > [1] > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms#SupportedBuildPlatforms-JDK8buildplatformssupportedbyOracle What puzzles me a bit now is this: Peter at WIN7VM /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin $ for i in *.dll; do echo " $i"; ldd $i; done > ldds What do the question marks mean: awt.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74710000) dt_shmem.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x747a0000) dt_socket.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) WS2_32.dll => /cygdrive/c/Windows/syswow64/WS2_32.dll (0x76370000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) NSI.dll => /cygdrive/c/Windows/syswow64/NSI.dll (0x77630000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x746e0000) fontmanager.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x747f0000) freetype.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) hprof.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) WSOCK32.dll => /cygdrive/c/Windows/system32/WSOCK32.dll (0x74d00000) WS2_32.dll => /cygdrive/c/Windows/syswow64/WS2_32.dll (0x76370000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) NSI.dll => /cygdrive/c/Windows/syswow64/NSI.dll (0x77630000) WINMM.dll => /cygdrive/c/Windows/system32/WINMM.dll (0x72a20000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x74780000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) instrument.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) j2pcsc.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) WinSCard.dll => /cygdrive/c/Windows/system32/WinSCard.dll (0x74830000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x74770000) j2pkcs11.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x747a0000) jaas_nt.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x746e0000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) java.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74840000) java_crw_demo.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x747a0000) JavaAccessBridge.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x74780000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) JavaAccessBridge-32.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x746c0000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) jawt.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74850000) ??? => ??? (0x746f0000) JAWTAccessBridge.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74860000) ??? => ??? (0x74840000) ??? => ??? (0x746e0000) JAWTAccessBridge-32.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74860000) ??? => ??? (0x74850000) ??? => ??? (0x746f0000) jdwp.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x74780000) jli.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) COMCTL32.dll => /cygdrive/c/Windows/WinSxS/x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af/COMCTL32.dll (0x747b0000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) jpeg.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74840000) ??? => ??? (0x74810000) jsdt.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x747a0000) jsound.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) WINMM.dll => /cygdrive/c/Windows/system32/WINMM.dll (0x72a20000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x746e0000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) jsoundds.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) DSOUND.dll => /cygdrive/c/Windows/system32/DSOUND.dll (0x747e0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) ole32.dll => /cygdrive/c/Windows/syswow64/ole32.dll (0x77100000) WINMM.dll => /cygdrive/c/Windows/system32/WINMM.dll (0x72a20000) POWRPROF.dll => /cygdrive/c/Windows/system32/POWRPROF.dll (0x747b0000) SETUPAPI.dll => /cygdrive/c/Windows/syswow64/SETUPAPI.dll (0x75c00000) CFGMGR32.dll => /cygdrive/c/Windows/syswow64/CFGMGR32.dll (0x753f0000) OLEAUT32.dll => /cygdrive/c/Windows/syswow64/OLEAUT32.dll (0x75b00000) DEVOBJ.dll => /cygdrive/c/Windows/syswow64/DEVOBJ.dll (0x76200000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x746f0000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) lcms.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74830000) ??? => ??? (0x746d0000) management.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74860000) mlib_image.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x74720000) msvcr100.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) net.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74850000) ??? => ??? (0x76370000) ??? => ??? (0x763b0000) ??? => ??? (0x75300000) ??? => ??? (0x74ff0000) ??? => ??? (0x74fe0000) ??? => ??? (0x75f90000) ??? => ??? (0x77630000) nio.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74860000) ??? => ??? (0x76370000) ??? => ??? (0x763b0000) ??? => ??? (0x75300000) ??? => ??? (0x74ff0000) ??? => ??? (0x74fe0000) ??? => ??? (0x75f90000) ??? => ??? (0x77630000) ??? => ??? (0x74830000) npt.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x747a0000) splashscreen.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x74770000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) sunec.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x74780000) sunmscapi.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) CRYPT32.dll => /cygdrive/c/Windows/syswow64/CRYPT32.dll (0x75640000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) MSASN1.dll => /cygdrive/c/Windows/syswow64/MSASN1.dll (0x75760000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x747a0000) unpack.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74850000) verify.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74860000) w2k_lsa_auth.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) Secur32.dll => /cygdrive/c/Windows/system32/Secur32.dll (0x69ff0000) WSOCK32.dll => /cygdrive/c/Windows/system32/WSOCK32.dll (0x74d00000) WS2_32.dll => /cygdrive/c/Windows/syswow64/WS2_32.dll (0x76370000) NSI.dll => /cygdrive/c/Windows/syswow64/NSI.dll (0x77630000) MSVCR100.dll => /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin/MSVCR100.dll (0x746e0000) WindowsAccessBridge.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) WindowsAccessBridge-32.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x75200000) GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x75420000) LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x75520000) USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x75fb0000) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x763b0000) ADVAPI32.dll => /cygdrive/c/Windows/syswow64/ADVAPI32.dll (0x759d0000) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x75f90000) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x75300000) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74ff0000) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74fe0000) IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x75050000) MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x760e0000) zip.dll ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75530000) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75ba0000) ??? => ??? (0x74850000) -- peter kollner From peter at asgalon.net Wed Dec 21 03:13:24 2016 From: peter at asgalon.net (Peter Koellner) Date: Wed, 21 Dec 2016 04:13:24 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: References: <58597E8A.2040309@redhat.com> Message-ID: On Wed, 21 Dec 2016, Peter Koellner wrote: > What puzzles me a bit now is this: > > Peter at WIN7VM > /cygdrive/c/openjdk/jdk8u/build/windows-x86-normal-server-fastdebug/bootcycle-build/images/j2re-image/bin > $ for i in *.dll; do echo " $i"; ldd $i; done > ldds > > What do the question marks mean: > > > awt.dll > ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77660000) > kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll > (0x75530000) > KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll > (0x75ba0000) > ??? => ??? (0x74710000) cygcheck puts it a bit clearer, it looks like something went wrong with manually copying/renaming the freetype.dll file. This should probably be automated. Second problem was that freetype.dll depends on zlib1.dll, which apparently was not copied. fontmanager depends on freetype6.dll instead of freetype.dll, not sure what that means with System.getLibrary("freetype"). Copying freetype.dll to freetype6.dll in the bin directory seems to solve the classnotfound-exceptions for the FontManager. My test application displays the JFrame opens the file chooser now. it is after 4 o'clock in the morning, tomorrow I will try to sort the dll mess out and look after the failed tests in make test. regards Peter -- peter kollner From akashche at redhat.com Wed Dec 21 09:21:02 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 21 Dec 2016 09:21:02 +0000 Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: References: <58597E8A.2040309@redhat.com> Message-ID: <585A497E.3050900@redhat.com> Hi Peter, On 12/21/2016 03:13 AM, Peter Koellner wrote: > > [...] > > cygcheck puts it a bit clearer, it looks like something went wrong with > manually copying/renaming the freetype.dll file. This should probably be > automated. > Second problem was that freetype.dll depends on zlib1.dll, which > apparently was not copied. fontmanager depends on freetype6.dll instead > of freetype.dll, not sure what that means with GZIP support in FreeType is not needed for OpenJDK, you can build it without FT_CONFIG_OPTION_USE_ZLIB option. You also may want to look how FreeType is handled in jdk9 - https://bugs.openjdk.java.net/browse/JDK-8057538 > > [...] > -- -Alex From volker.simonis at gmail.com Wed Dec 21 11:44:46 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 21 Dec 2016 12:44:46 +0100 Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: <585A497E.3050900@redhat.com> References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> Message-ID: Hi Peter, I can not see which version of freetype you have installed. Maybe you use one which was compiled for the cygwin environment? That would obviously not work in OpenJDK which is compiled with the MSVC tool chain. I know that getting a good version of freetype has always been a problem on Windows. That's why I added the configuration option "--with-freetype-src" to jdk9. You just pass in the directory of the freetype sources (e.g. --with-freetype-src=/cygdrive/c/Software/freetype-2-5-3) and it will automatically build both, the 32- and the 64-bit versions of freetype during the configuration step. I'd suggest you clone a jdk9 repo, download the freetype sources and run the configuration step as described above. Afterwards you can use the newly created freetype lib for your jdk8u build (i.e. --with-freetype-lib=/cygdrive/c/Software/freetype-2-5-3/lib32) Best regards, Volker PS: I don't think you should worry too much about the failing 26 jtreg tests. First of all you can have a look at http://download.java.net/openjdk/testresults/8/testresults.html to see which tests are known to fail and second some of the tests are not very stable on Windows. On Wed, Dec 21, 2016 at 10:21 AM, Alex Kashchenko wrote: > Hi Peter, > > On 12/21/2016 03:13 AM, Peter Koellner wrote: >> >> >> [...] >> >> cygcheck puts it a bit clearer, it looks like something went wrong with >> manually copying/renaming the freetype.dll file. This should probably be >> automated. >> Second problem was that freetype.dll depends on zlib1.dll, which >> apparently was not copied. fontmanager depends on freetype6.dll instead >> of freetype.dll, not sure what that means with > > > GZIP support in FreeType is not needed for OpenJDK, you can build it without > FT_CONFIG_OPTION_USE_ZLIB option. > > You also may want to look how FreeType is handled in jdk9 - > https://bugs.openjdk.java.net/browse/JDK-8057538 > >> >> [...] >> > > -- > -Alex From peter at asgalon.net Wed Dec 21 13:37:42 2016 From: peter at asgalon.net (Peter Koellner) Date: Wed, 21 Dec 2016 14:37:42 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: <585A497E.3050900@redhat.com> References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> Message-ID: Hi! Thanks, I'll take that into account with the next environment. I have downloaded a windows 2008 R2 and will install that today into a fresh VM to get rid of the i18n problems and fix the freetype setup. cheers Peter On Wed, 21 Dec 2016, Alex Kashchenko wrote: > Hi Peter, > > On 12/21/2016 03:13 AM, Peter Koellner wrote: >> >> [...] >> >> cygcheck puts it a bit clearer, it looks like something went wrong with >> manually copying/renaming the freetype.dll file. This should probably be >> automated. >> Second problem was that freetype.dll depends on zlib1.dll, which >> apparently was not copied. fontmanager depends on freetype6.dll instead >> of freetype.dll, not sure what that means with > > GZIP support in FreeType is not needed for OpenJDK, you can build it without > FT_CONFIG_OPTION_USE_ZLIB option. > > You also may want to look how FreeType is handled in jdk9 - > https://bugs.openjdk.java.net/browse/JDK-8057538 > >> >> [...] >> > > -- peter kollner From peter at asgalon.net Wed Dec 21 13:41:33 2016 From: peter at asgalon.net (Peter Koellner) Date: Wed, 21 Dec 2016 14:41:33 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> Message-ID: Hello Volker, thanks. This is very helpful information, especially about the tests. I still am a bit worried about the crypto package since we require smartcard cryptography support to work in our applications. regards Peter On Wed, 21 Dec 2016, Volker Simonis wrote: > Hi Peter, > > I can not see which version of freetype you have installed. Maybe you > use one which was compiled for the cygwin environment? That would > obviously not work in OpenJDK which is compiled with the MSVC tool > chain. > > I know that getting a good version of freetype has always been a > problem on Windows. That's why I added the configuration option > "--with-freetype-src" to jdk9. You just pass in the directory of the > freetype sources (e.g. > --with-freetype-src=/cygdrive/c/Software/freetype-2-5-3) and it will > automatically build both, the 32- and the 64-bit versions of freetype > during the configuration step. > > I'd suggest you clone a jdk9 repo, download the freetype sources and > run the configuration step as described above. Afterwards you can use > the newly created freetype lib for your jdk8u build (i.e. > --with-freetype-lib=/cygdrive/c/Software/freetype-2-5-3/lib32) > > Best regards, > Volker > > PS: I don't think you should worry too much about the failing 26 jtreg > tests. First of all you can have a look at > http://download.java.net/openjdk/testresults/8/testresults.html to see > which tests are known to fail and second some of the tests are not > very stable on Windows. > > > On Wed, Dec 21, 2016 at 10:21 AM, Alex Kashchenko wrote: >> Hi Peter, >> >> On 12/21/2016 03:13 AM, Peter Koellner wrote: >>> >>> >>> [...] >>> >>> cygcheck puts it a bit clearer, it looks like something went wrong with >>> manually copying/renaming the freetype.dll file. This should probably be >>> automated. >>> Second problem was that freetype.dll depends on zlib1.dll, which >>> apparently was not copied. fontmanager depends on freetype6.dll instead >>> of freetype.dll, not sure what that means with >> >> >> GZIP support in FreeType is not needed for OpenJDK, you can build it without >> FT_CONFIG_OPTION_USE_ZLIB option. >> >> You also may want to look how FreeType is handled in jdk9 - >> https://bugs.openjdk.java.net/browse/JDK-8057538 >> >>> >>> [...] >>> >> >> -- >> -Alex > -- peter kollner From peter at asgalon.net Wed Dec 21 14:23:31 2016 From: peter at asgalon.net (Peter Koellner) Date: Wed, 21 Dec 2016 15:23:31 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> Message-ID: On Wed, 21 Dec 2016, Volker Simonis wrote: > I know that getting a good version of freetype has always been a > problem on Windows. That's why I added the configuration option > "--with-freetype-src" to jdk9. You just pass in the directory of the > freetype sources (e.g. > --with-freetype-src=/cygdrive/c/Software/freetype-2-5-3) and it will > automatically build both, the 32- and the 64-bit versions of freetype > during the configuration step. > > I'd suggest you clone a jdk9 repo, download the freetype sources and > run the configuration step as described above. Afterwards you can use > the newly created freetype lib for your jdk8u build (i.e. > --with-freetype-lib=/cygdrive/c/Software/freetype-2-5-3/lib32) Perhaps it would be better to backport the additional configuration to the jdk8u repository? It would make it much easier to start, it would have saved me several days and its always better to improve autoconf scripts instead of working around deficencies. -- peter kollner From peter at asgalon.net Wed Dec 21 16:38:26 2016 From: peter at asgalon.net (Peter Koellner) Date: Wed, 21 Dec 2016 17:38:26 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> Message-ID: Hi! I have copied the common/autoconf/lib-freetype.m4 over to the jdk8u project and did a m4include(lib-freetype.m4) at the end of the LIB_SETUP_INIT function. Also added the MSBUILD check to toolchain.m4. Unfortunately, there seem to be missing something: freetype.log: Microsoft (R) Build Engine Version 4.0.30319.1 [Microsoft .NET Framework, Version 4.0.30319.1] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 12/21/2016 5:08:24 PM. Project "C:\openjdk\support\freetype-2.5.3\builds\windows\vc2010\freetype.vcxproj" on node 1 (default targets). C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\win32\Microsoft.Cpp.win32.Targets(511,5): error MSB8008: Specified platform toolset ({0}) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [C:\openjdk\support\freetype-2.5.3\builds\windows\vc2010\freetype.vcxproj] Done Building Project "C:\openjdk\support\freetype-2.5.3\builds\windows\vc2010\freetype.vcxproj" (default targets) -- FAILED. Build FAILED. "C:\openjdk\support\freetype-2.5.3\builds\windows\vc2010\freetype.vcxproj" (default target) (1) -> (PlatformPrepareForBuild target) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\win32\Microsoft.Cpp.win32.Targets(511,5): error MSB8008: Specified platform toolset ({0}) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected. [C:\openjdk\support\freetype-2.5.3\builds\windows\vc2010\freetype.vcxproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:02.85 the autoconf seem to have had a major cleanup, so a simple diff/patch is not really possible there. So I updated the boot jdk to jdk1.8.0_111 and configured jdk9, where compiling freetype seem to have worked now, and added the --with-freetype-lib=freetype2.5.3/lib32 and -.with-freetype-include=freetype-2.5.3/include folders. I'll leave a patch for the freetype configuration as a task for after I have a proven working result, make bootcycle-images is running now. regards Peter -- peter kollner From david.holmes at oracle.com Wed Dec 21 23:36:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Dec 2016 09:36:31 +1000 Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> Message-ID: <0b47e519-a032-4cc2-1f1d-fbf9a6919d00@oracle.com> On 21/12/2016 11:41 PM, Peter Koellner wrote: > > Hello Volker, > > thanks. This is very helpful information, especially about the tests. > I still am a bit worried about the crypto package since we require > smartcard cryptography support to work in our applications. Please be aware that the cryptography support in the OpenJDK is different to that in the Oracle JDK. http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html For more info you'd need to ask on security-dev. David > regards > Peter > > > On Wed, 21 Dec 2016, Volker Simonis wrote: > >> Hi Peter, >> >> I can not see which version of freetype you have installed. Maybe you >> use one which was compiled for the cygwin environment? That would >> obviously not work in OpenJDK which is compiled with the MSVC tool >> chain. >> >> I know that getting a good version of freetype has always been a >> problem on Windows. That's why I added the configuration option >> "--with-freetype-src" to jdk9. You just pass in the directory of the >> freetype sources (e.g. >> --with-freetype-src=/cygdrive/c/Software/freetype-2-5-3) and it will >> automatically build both, the 32- and the 64-bit versions of freetype >> during the configuration step. >> >> I'd suggest you clone a jdk9 repo, download the freetype sources and >> run the configuration step as described above. Afterwards you can use >> the newly created freetype lib for your jdk8u build (i.e. >> --with-freetype-lib=/cygdrive/c/Software/freetype-2-5-3/lib32) >> >> Best regards, >> Volker >> >> PS: I don't think you should worry too much about the failing 26 jtreg >> tests. First of all you can have a look at >> http://download.java.net/openjdk/testresults/8/testresults.html to see >> which tests are known to fail and second some of the tests are not >> very stable on Windows. >> >> >> On Wed, Dec 21, 2016 at 10:21 AM, Alex Kashchenko >> wrote: >>> Hi Peter, >>> >>> On 12/21/2016 03:13 AM, Peter Koellner wrote: >>>> >>>> >>>> [...] >>>> >>>> cygcheck puts it a bit clearer, it looks like something went wrong with >>>> manually copying/renaming the freetype.dll file. This should >>>> probably be >>>> automated. >>>> Second problem was that freetype.dll depends on zlib1.dll, which >>>> apparently was not copied. fontmanager depends on freetype6.dll instead >>>> of freetype.dll, not sure what that means with >>> >>> >>> GZIP support in FreeType is not needed for OpenJDK, you can build it >>> without >>> FT_CONFIG_OPTION_USE_ZLIB option. >>> >>> You also may want to look how FreeType is handled in jdk9 - >>> https://bugs.openjdk.java.net/browse/JDK-8057538 >>> >>>> >>>> [...] >>>> >>> >>> -- >>> -Alex >> > From peter at asgalon.net Thu Dec 22 11:50:02 2016 From: peter at asgalon.net (Peter Koellner) Date: Thu, 22 Dec 2016 12:50:02 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: <0b47e519-a032-4cc2-1f1d-fbf9a6919d00@oracle.com> References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> <0b47e519-a032-4cc2-1f1d-fbf9a6919d00@oracle.com> Message-ID: Hi! On Thu, 22 Dec 2016, David Holmes wrote: > On 21/12/2016 11:41 PM, Peter Koellner wrote: >> >> Hello Volker, >> >> thanks. This is very helpful information, especially about the tests. >> I still am a bit worried about the crypto package since we require >> smartcard cryptography support to work in our applications. > > Please be aware that the cryptography support in the OpenJDK is different to > that in the Oracle JDK. > > http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html > > For more info you'd need to ask on security-dev. I made another quick test today. Turns out it works just using the standard jre1.8.0_111 Java configuration panel to add the modified JRE to be used for firefox applets, which is quite a relief. We'll just test if smartcard support works with that. If not we will have to switch to Oracle JRE sources somehow if security-dev has no solution for any problems coming up... regards Peter -- peter kollner From szegedia at gmail.com Thu Dec 22 17:15:17 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 22 Dec 2016 18:15:17 +0100 Subject: [8u-dev] Request for Approval: 8171849: Collection and Queue conversions not prioritized for Arrays Message-ID: <8033BD3D-C434-4241-AE32-5C66A1561B6A@gmail.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8171849 jdk9 webrev: http://cr.openjdk.java.net/~attila/8171849/webrev.jdk9 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006758.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From rob.mckenna at oracle.com Thu Dec 22 18:19:21 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 22 Dec 2016 18:19:21 +0000 Subject: [8u-dev] Request for Approval: 8171849: Collection and Queue conversions not prioritized for Arrays In-Reply-To: <8033BD3D-C434-4241-AE32-5C66A1561B6A@gmail.com> References: <8033BD3D-C434-4241-AE32-5C66A1561B6A@gmail.com> Message-ID: <20161222181921.GA2543@vimes> Approved -Rob On 22/12/16 06:15, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171849 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8171849/webrev.jdk9 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006758.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. From dalibor.topic at oracle.com Fri Dec 23 12:36:00 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 23 Dec 2016 13:36:00 +0100 Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> Message-ID: <9c0f30b0-a54b-f2c5-c5b2-6b71e1e7d9a3@oracle.com> On 21.12.2016 15:23, Peter Koellner wrote: > Perhaps it would be better to backport the additional configuration to > the jdk8u repository? Unfortunately, I believe that a backport of http://hg.openjdk.java.net/jdk9/jdk9/rev/5d7de212359d is unlikely to be trivial enough and to fit well with http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-November/006095.html . cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From peter at asgalon.net Fri Dec 23 13:26:36 2016 From: peter at asgalon.net (Peter Koellner) Date: Fri, 23 Dec 2016 14:26:36 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: <9c0f30b0-a54b-f2c5-c5b2-6b71e1e7d9a3@oracle.com> References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> <9c0f30b0-a54b-f2c5-c5b2-6b71e1e7d9a3@oracle.com> Message-ID: On Fri, 23 Dec 2016, dalibor topic wrote: > On 21.12.2016 15:23, Peter Koellner wrote: >> Perhaps it would be better to backport the additional configuration to >> the jdk8u repository? > > Unfortunately, I believe that a backport of > http://hg.openjdk.java.net/jdk9/jdk9/rev/5d7de212359d is unlikely to be > trivial enough and to fit well with > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-November/006095.html . Ok, it worked using ./configure on jdk9 , so maybe a short note somewhere in the jdk8u build instructions would be enough... -- peter kollner From szegedia at gmail.com Mon Dec 26 17:19:24 2016 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 26 Dec 2016 18:19:24 +0100 Subject: [8u-dev] Request for Approval: 8139273: Small improvements to DynamicLinker and DynamicLinkerFactory Message-ID: Please approve. Yes, this is a a cca. 15 month old changeset from jdk9 codebase. I was debugging something and discovered that the problem it fixes (DynamicLinker.getLinkedCallSiteLocation() giving incorrect results with -XX:+ShowHiddenFrames) still persists in jdk8. This change essentially makes the stack walking code in DynamicLinker.getLinkedCallSiteLocation() operate correctly when the JVM is run with -XX:+ShowHiddenFrames. This method itself is only used to generate location information in diagnostic messages and call tracing counters. This problem thus makes Nashorn generate incorrect call-site linkage miss counters (a performance diagnostic feature of Nashorn) with -XX:+ShowHiddenFrames. The changeset also removes a deprecated method; this is safe as the method was never part of a public API and there have not been any internal uses of it for very long time (Nashorn internally uses its non-deprecated counterpart). Two never-subclassed, internal classes are also marked as final. I kept these changes too as they?re sensible, in order to not deviate from the already approved changeset. Bug: https://bugs.openjdk.java.net/browse/JDK-8139273 jdk9 webrev: http://cr.openjdk.java.net/~attila/8139273/webrev.jdk9 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-October/005394.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From rob.mckenna at oracle.com Mon Dec 26 21:09:46 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 26 Dec 2016 21:09:46 +0000 Subject: [8u-dev] Request for Approval: 8139273: Small improvements to DynamicLinker and DynamicLinkerFactory In-Reply-To: References: Message-ID: <20161226210946.GA7151@tecra> As this is an enhancement approval request, please follow the correct template: http://openjdk.java.net/projects/jdk8u/enhancement-template.html Specifically the subject line in order to make this easier to find in the future. -Rob On 26/12/16 06:19, Attila Szegedi wrote: > Please approve. > > Yes, this is a a cca. 15 month old changeset from jdk9 codebase. I was debugging something and discovered that the problem it fixes (DynamicLinker.getLinkedCallSiteLocation() giving incorrect results with -XX:+ShowHiddenFrames) still persists in jdk8. This change essentially makes the stack walking code in DynamicLinker.getLinkedCallSiteLocation() operate correctly when the JVM is run with -XX:+ShowHiddenFrames. > > This method itself is only used to generate location information in diagnostic messages and call tracing counters. This problem thus makes Nashorn generate incorrect call-site linkage miss counters (a performance diagnostic feature of Nashorn) with -XX:+ShowHiddenFrames. > > The changeset also removes a deprecated method; this is safe as the method was never part of a public API and there have not been any internal uses of it for very long time (Nashorn internally uses its non-deprecated counterpart). Two never-subclassed, internal classes are also marked as final. I kept these changes too as they?re sensible, in order to not deviate from the already approved changeset. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139273 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8139273/webrev.jdk9 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-October/005394.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. > From peter at asgalon.net Mon Dec 26 21:31:30 2016 From: peter at asgalon.net (Peter Koellner) Date: Mon, 26 Dec 2016 22:31:30 +0100 (CET) Subject: openjdk8u stable 32bit for windows build environment In-Reply-To: <0b47e519-a032-4cc2-1f1d-fbf9a6919d00@oracle.com> References: <58597E8A.2040309@redhat.com> <585A497E.3050900@redhat.com> <0b47e519-a032-4cc2-1f1d-fbf9a6919d00@oracle.com> Message-ID: Hi! Before logging off, I just wanted to say thanks for all the support and to give a bit of feedback how it all worked out. I tested the cryptography support separately from the other problems we had, and the openjdk smartcard support works fine. I was able to use a smartcard-enabled PDF signer with the jre to produce a valid digital signature with both my spanish and catalan id certificates from card after configuring the right windows opensc implementation library for the reader. The other problem dealing with changing the user.home property we solved using a gordian knot approach - by simply brute-forcing java.lang.System to return the desired value and replacing the class in rt.jar. This should suffice for the kind of internal application we have. Since it turned out to be unnecessary to modify the native initialization code we are fine with using the standard jre to avoid further problems with the third party applet. The freetype problem got solved by using jdk9-dev configure to build freetype and then set the configure flags appropriately in jdk8u-dev. So basically I am able to build openjdk 8u now, but won't really need it in the foreseeable future apart from analyzing upcoming problems, and our application is working. Thanks for all Peter On Thu, 22 Dec 2016, David Holmes wrote: > On 21/12/2016 11:41 PM, Peter Koellner wrote: >> >> Hello Volker, >> >> thanks. This is very helpful information, especially about the tests. >> I still am a bit worried about the crypto package since we require >> smartcard cryptography support to work in our applications. > > Please be aware that the cryptography support in the OpenJDK is different to > that in the Oracle JDK. > > http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html > > For more info you'd need to ask on security-dev. > > David > >> regards >> Peter >> >> >> On Wed, 21 Dec 2016, Volker Simonis wrote: >> >>> Hi Peter, >>> >>> I can not see which version of freetype you have installed. Maybe you >>> use one which was compiled for the cygwin environment? That would >>> obviously not work in OpenJDK which is compiled with the MSVC tool >>> chain. >>> >>> I know that getting a good version of freetype has always been a >>> problem on Windows. That's why I added the configuration option >>> "--with-freetype-src" to jdk9. You just pass in the directory of the >>> freetype sources (e.g. >>> --with-freetype-src=/cygdrive/c/Software/freetype-2-5-3) and it will >>> automatically build both, the 32- and the 64-bit versions of freetype >>> during the configuration step. >>> >>> I'd suggest you clone a jdk9 repo, download the freetype sources and >>> run the configuration step as described above. Afterwards you can use >>> the newly created freetype lib for your jdk8u build (i.e. >>> --with-freetype-lib=/cygdrive/c/Software/freetype-2-5-3/lib32) >>> >>> Best regards, >>> Volker >>> >>> PS: I don't think you should worry too much about the failing 26 jtreg >>> tests. First of all you can have a look at >>> http://download.java.net/openjdk/testresults/8/testresults.html to see >>> which tests are known to fail and second some of the tests are not >>> very stable on Windows. >>> >>> >>> On Wed, Dec 21, 2016 at 10:21 AM, Alex Kashchenko >>> wrote: >>>> Hi Peter, >>>> >>>> On 12/21/2016 03:13 AM, Peter Koellner wrote: >>>>> >>>>> >>>>> [...] >>>>> >>>>> cygcheck puts it a bit clearer, it looks like something went wrong with >>>>> manually copying/renaming the freetype.dll file. This should >>>>> probably be >>>>> automated. >>>>> Second problem was that freetype.dll depends on zlib1.dll, which >>>>> apparently was not copied. fontmanager depends on freetype6.dll instead >>>>> of freetype.dll, not sure what that means with >>>> >>>> >>>> GZIP support in FreeType is not needed for OpenJDK, you can build it >>>> without >>>> FT_CONFIG_OPTION_USE_ZLIB option. >>>> >>>> You also may want to look how FreeType is handled in jdk9 - >>>> https://bugs.openjdk.java.net/browse/JDK-8057538 >>>> >>>>> >>>>> [...] >>>>> >>>> >>>> -- >>>> -Alex >>> >> > -- peter kollner From volker.simonis at gmail.com Tue Dec 27 17:17:44 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Dec 2016 18:17:44 +0100 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) Message-ID: Hi, can I please have a review and approval for pushing the following small, ppc64-only fix to jdk8u-dev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ https://bugs.openjdk.java.net/browse/JDK-8172053 The problem is that the recent downport of "8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation" breaks the build of jdk8u with the original gcc 4.3 on linux/ppc64. We should however ensure, that an update-release will not break the original tool chain used for a released version of Java. Notice, that this change won't go to jdk9 because it only fixes an issue caused by the downport of another fix to jdk8u which doesn't exist in jdk9. JDK-8170153 increased the optimization level for the compilation of fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by using the option '-ffp-contract=off' which guaranteed correct IEEE floating point behavior. Unfortunately, '-ffp-contract' is only available since gcc 4.6. For ppc64le that's no problem since ppc64le support only appeared in gcc 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc 4.3 which only knows '-mno-fused-madd'. However, that's still not enough to get the float computations right - we additionally have to supply '-fno-strict-aliasing'. I've tested the new configuration (i.e. '-mno-fused-madd -fno-strict-aliasing') with the corresponding jtreg and JCK tests and couldn't find any issue. Thank you and best regards, Volker From david.holmes at oracle.com Tue Dec 27 22:30:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Dec 2016 08:30:38 +1000 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) In-Reply-To: References: Message-ID: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> Hi Volker, As this is a build change I have added build-dev. The change looks fine to me. Aside: More generally it would be nice if there was a simple way to record minimum compiler versions necessary for a given flag/option. Thanks, David On 28/12/2016 3:17 AM, Volker Simonis wrote: > Hi, > > can I please have a review and approval for pushing the following > small, ppc64-only fix to jdk8u-dev: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ > https://bugs.openjdk.java.net/browse/JDK-8172053 > > The problem is that the recent downport of "8170153: > PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized > compilation" breaks the build of jdk8u with the original gcc 4.3 on > linux/ppc64. We should however ensure, that an update-release will not > break the original tool chain used for a released version of Java. > Notice, that this change won't go to jdk9 because it only fixes an > issue caused by the downport of another fix to jdk8u which doesn't > exist in jdk9. > > JDK-8170153 increased the optimization level for the compilation of > fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by > using the option '-ffp-contract=off' which guaranteed correct IEEE > floating point behavior. > > Unfortunately, '-ffp-contract' is only available since gcc 4.6. For > ppc64le that's no problem since ppc64le support only appeared in gcc > 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc > 4.3 which only knows '-mno-fused-madd'. However, that's still not > enough to get the float computations right - we additionally have to > supply '-fno-strict-aliasing'. > > I've tested the new configuration (i.e. '-mno-fused-madd > -fno-strict-aliasing') with the corresponding jtreg and JCK tests and > couldn't find any issue. > > Thank you and best regards, > Volker > From erik.joelsson at oracle.com Wed Dec 28 08:08:23 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Dec 2016 09:08:23 +0100 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) In-Reply-To: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> References: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> Message-ID: Change looks ok. /Erik On 2016-12-27 23:30, David Holmes wrote: > Hi Volker, > > As this is a build change I have added build-dev. > > The change looks fine to me. > > Aside: More generally it would be nice if there was a simple way to > record minimum compiler versions necessary for a given flag/option. > > Thanks, > David > > On 28/12/2016 3:17 AM, Volker Simonis wrote: >> Hi, >> >> can I please have a review and approval for pushing the following >> small, ppc64-only fix to jdk8u-dev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ >> https://bugs.openjdk.java.net/browse/JDK-8172053 >> >> The problem is that the recent downport of "8170153: >> PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized >> compilation" breaks the build of jdk8u with the original gcc 4.3 on >> linux/ppc64. We should however ensure, that an update-release will not >> break the original tool chain used for a released version of Java. >> Notice, that this change won't go to jdk9 because it only fixes an >> issue caused by the downport of another fix to jdk8u which doesn't >> exist in jdk9. >> >> JDK-8170153 increased the optimization level for the compilation of >> fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by >> using the option '-ffp-contract=off' which guaranteed correct IEEE >> floating point behavior. >> >> Unfortunately, '-ffp-contract' is only available since gcc 4.6. For >> ppc64le that's no problem since ppc64le support only appeared in gcc >> 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc >> 4.3 which only knows '-mno-fused-madd'. However, that's still not >> enough to get the float computations right - we additionally have to >> supply '-fno-strict-aliasing'. >> >> I've tested the new configuration (i.e. '-mno-fused-madd >> -fno-strict-aliasing') with the corresponding jtreg and JCK tests and >> couldn't find any issue. >> >> Thank you and best regards, >> Volker >> From volker.simonis at gmail.com Wed Dec 28 08:32:25 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 28 Dec 2016 09:32:25 +0100 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) In-Reply-To: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> References: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> Message-ID: On Tue, Dec 27, 2016 at 11:30 PM, David Holmes wrote: > Hi Volker, > > As this is a build change I have added build-dev. > > The change looks fine to me. > Thanks for reviewing! > Aside: More generally it would be nice if there was a simple way to record > minimum compiler versions necessary for a given flag/option. > Yes, I first wanted to do this compiler-version dependent. Unfortunately that would have been much more complex because I don't have access to the compiler version in CoreLibraries.gmk and I didn't wanted to start it for legacy code which is not needed in jdk9 anyway. Regards, Volker > Thanks, > David > > > On 28/12/2016 3:17 AM, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review and approval for pushing the following >> small, ppc64-only fix to jdk8u-dev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ >> https://bugs.openjdk.java.net/browse/JDK-8172053 >> >> The problem is that the recent downport of "8170153: >> PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized >> compilation" breaks the build of jdk8u with the original gcc 4.3 on >> linux/ppc64. We should however ensure, that an update-release will not >> break the original tool chain used for a released version of Java. >> Notice, that this change won't go to jdk9 because it only fixes an >> issue caused by the downport of another fix to jdk8u which doesn't >> exist in jdk9. >> >> JDK-8170153 increased the optimization level for the compilation of >> fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by >> using the option '-ffp-contract=off' which guaranteed correct IEEE >> floating point behavior. >> >> Unfortunately, '-ffp-contract' is only available since gcc 4.6. For >> ppc64le that's no problem since ppc64le support only appeared in gcc >> 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc >> 4.3 which only knows '-mno-fused-madd'. However, that's still not >> enough to get the float computations right - we additionally have to >> supply '-fno-strict-aliasing'. >> >> I've tested the new configuration (i.e. '-mno-fused-madd >> -fno-strict-aliasing') with the corresponding jtreg and JCK tests and >> couldn't find any issue. >> >> Thank you and best regards, >> Volker >> > From christoph.langer at sap.com Thu Dec 29 09:37:29 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 29 Dec 2016 09:37:29 +0000 Subject: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set Message-ID: Hi, please review (and eventually approve) the change for downporting 8075484. Webrev for 8u-dev: http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd JDK9 Review Thread(s): http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010201.html We had customer reports who ran into that issue with Java 8. So this should be downported. The problem is, that the fix does not apply to Solaris as Solaris needs some calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still supported (though deprecated). But I think it is still worthwile to bring this down for the other platforms which I'm proposing with my changeset. So I extracted the new code manually from the JDK9 changeset and made it fit into JDK8 coding. Thanks & Best regards Christoph From dmitry.markov at oracle.com Thu Dec 29 09:47:25 2016 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 29 Dec 2016 12:47:25 +0300 Subject: [8u-dev] Request for approval 8171949: [macosx] AWT_ZoomFrame Automated tests fail with error: The bitwise mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state Message-ID: <434B4322-5697-4995-BFEF-ED5AD06BC5D4@oracle.com> Hello, Can I get an approval to port the fix for 8171949 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8171949 Webrev: http://cr.openjdk.java.net/~dmarkov/8171949/jdk8u/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-December/012485.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b69ce768cb7d Thanks, Dmitry From vyom.tewari at oracle.com Thu Dec 29 10:08:42 2016 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Thu, 29 Dec 2016 15:38:42 +0530 Subject: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set In-Reply-To: References: Message-ID: <3e607d3c-c614-d7b3-7246-b44f76516041@oracle.com> Hi Christoph, As this is not direct backport what about using the existing function "JVM_CurrentTimeMillis(env, 0);" instead of "NET_GetCurrentTime() ". When i did this code change i did not know that we already have this.If you use the existing one then you can simply remove the "NET_GetCurrentTime() " from your code change. Thanks, Vyom On Thursday 29 December 2016 03:07 PM, Langer, Christoph wrote: > > Hi, > > please review (and eventually approve) the change for downporting 8075484. > > Webrev for 8u-dev: > http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 > > > JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd > > JDK9 Review Thread(s): > > http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html > > http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010201.html > > We had customer reports who ran into that issue with Java 8. So this > should be downported. > > The problem is, that the fix does not apply to Solaris as Solaris > needs some calls into hotspot. This is because in JDK 8 the flag for > interruptible IO is still supported (though deprecated). But I think > it is still worthwile to bring this down for the other platforms which > I?m proposing with my changeset. So I extracted the new code manually > from the JDK9 changeset and made it fit into JDK8 coding. > > Thanks & Best regards > > Christoph > From christoph.langer at sap.com Thu Dec 29 11:14:04 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 29 Dec 2016 11:14:04 +0000 Subject: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set In-Reply-To: <3e607d3c-c614-d7b3-7246-b44f76516041@oracle.com> References: <3e607d3c-c614-d7b3-7246-b44f76516041@oracle.com> Message-ID: <41bf1d63b8614e9ca1ec9201eac38b93@DEWDFE13DE03.global.corp.sap> Hi Vyom, generally, I think it is a good idea to have a look at NET_GetCurrentTime vs. JVM_CurrentTimeMillis again. However, NET_GetCurrentTime is self-contained and does not need arguments whereas JVM_CurrentTimeMillis needs a JNI env pointer. And since NET_GetCurrentTime is called from NET_Timeout which currently does not have access to the JNI env pointer, it is not so easy to change this as I'd have to touch all places where NET_Timeout is called. So, for this downport I think we should leave this as is. But, as for JDK9 (or maybe JDK10) I think a change should be done to either go for JVM_CurrentTimeMillis which means touching all NET_Timeout calls or, alternatively, change all JVM_CurrentTimeMillis to NET_GetCurrentTime in libnet. Maybe the latter one is even more desirable as the local call could be a bit cheaper than calling into hotspot. I filed bug 8172125 for that and assigned it to me. Best regards Christoph From: Vyom Tewari [mailto:vyom.tewari at oracle.com] Sent: Donnerstag, 29. Dezember 2016 11:09 To: Langer, Christoph ; net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net Subject: Re: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set Hi Christoph, As this is not direct backport what about using the existing function "JVM_CurrentTimeMillis(env, 0);" instead of " NET_GetCurrentTime() ". When i did this code change i did not know that we already have this.If you use the existing one then you can simply remove the " NET_GetCurrentTime() " from your code change. Thanks, Vyom On Thursday 29 December 2016 03:07 PM, Langer, Christoph wrote: Hi, please review (and eventually approve) the change for downporting 8075484. Webrev for 8u-dev: http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd JDK9 Review Thread(s): http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010201.html We had customer reports who ran into that issue with Java 8. So this should be downported. The problem is, that the fix does not apply to Solaris as Solaris needs some calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still supported (though deprecated). But I think it is still worthwile to bring this down for the other platforms which I'm proposing with my changeset. So I extracted the new code manually from the JDK9 changeset and made it fit into JDK8 coding. Thanks & Best regards Christoph From dmitry.markov at oracle.com Thu Dec 29 17:47:42 2016 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 29 Dec 2016 20:47:42 +0300 Subject: [8u-dev] Request for approval 8171952: [macosx] AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked. Message-ID: <093CA487-CD70-4C5A-BC19-33057F7EAC9D@oracle.com> Hello, Can I get an approval to port the fix for 8171952 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8171952 Webrev: http://cr.openjdk.java.net/~dmarkov/8171952/jdk8u/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-December/012489.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9adbdbedae4f Thanks, Dmitry