From mikhail.cherkasov at oracle.com Thu Mar 2 10:40:08 2017 From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov) Date: Thu, 2 Mar 2017 13:40:08 +0300 Subject: Request for approval: 8171808: Performance problems in dialogs with large tables when JAB activated Message-ID: <7d82b47b-7cb1-9237-37aa-758179a325b9@oracle.com> Hello, Could you please approve this backport to 8u-dev: Bug: https://bugs.openjdk.java.net/browse/JDK-8171808 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/a8cd8b6b53bc 9 reviewer's approves: http://mail.openjdk.java.net/pipermail/swing-dev/2017-March/007215.html http://mail.openjdk.java.net/pipermail/swing-dev/2017-March/007217.html 8 webrev: http://cr.openjdk.java.net/~mcherkas/8171808/8/ Patch is applied without any changes after un-shuffling. Thanks, Mikhail. From david.buck at oracle.com Thu Mar 2 11:35:53 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 2 Mar 2017 20:35:53 +0900 Subject: Request for approval: 8171808: Performance problems in dialogs with large tables when JAB activated In-Reply-To: <7d82b47b-7cb1-9237-37aa-758179a325b9@oracle.com> References: <7d82b47b-7cb1-9237-37aa-758179a325b9@oracle.com> Message-ID: <2e74172c-d105-4331-240f-7c573e70d49b@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/03/02 19:40, Mikhail Cherkasov wrote: > Hello, > > Could you please approve this backport to 8u-dev: > Bug: https://bugs.openjdk.java.net/browse/JDK-8171808 > 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/a8cd8b6b53bc > 9 reviewer's approves: > http://mail.openjdk.java.net/pipermail/swing-dev/2017-March/007215.html > http://mail.openjdk.java.net/pipermail/swing-dev/2017-March/007217.html > 8 webrev: http://cr.openjdk.java.net/~mcherkas/8171808/8/ > > Patch is applied without any changes after un-shuffling. > > Thanks, > Mikhail. From rwestrel at redhat.com Thu Mar 2 16:35:34 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 02 Mar 2017 17:35:34 +0100 Subject: [8u] request for approval: 8174164 & 8175097: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: <5f99874c-8f2e-735c-315e-bd9c454435e6@oracle.com> References: <5f99874c-8f2e-735c-315e-bd9c454435e6@oracle.com> Message-ID: > 8u changes looks good. Thanks Vladimir. Can I get approval from the jdk 8u gatekeepers for this and a sponsor? Thanks, Roland. From shade at redhat.com Fri Mar 3 17:48:31 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Mar 2017 18:48:31 +0100 Subject: RFA (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect Message-ID: <77ca2f0e-dddd-8357-f94e-bde773bdab49@redhat.com> Hi, Please approve the backport of this important bugfix to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8175887 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2ff05d967fb2 Compiler folks agree with backport, and nightlies seem clean: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025767.html JDK 8u webrev: http://cr.openjdk.java.net/~shade/8175887/webrev.04.8u/ Product change applies cleanly, but test needs to change j.i.m.Unsafe to s.m.Unsafe. Testing: Linux x86_64/release hotspot/test/compiler/c1 before/after the fix. Need a sponsor to push. Thanks, -Aleksey From cthalinger at twitter.com Fri Mar 3 20:19:25 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 3 Mar 2017 10:19:25 -1000 Subject: What to pass to --with-custom-make-dir? Message-ID: <641A8C06-331C-4F47-BDF0-FC1DE8CF6D10@twitter.com> At Twitter we are using the custom extension mechanism to separate our additional code from upstream in order to minimize conflicts. Yesterday I wanted to add a custom extension for: jdk/make/lib/ServiceabilityLibraries.gmk which has this include directive: # Include custom extensions if available. -include $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk We are already using the mechanism for top-level make files, e.g. make/Main.gmk: # Include the corresponding custom file, if present. -include $(CUSTOM_MAKE_DIR)/Main.gmk and we a configuring with: --with-custom-make-dir=make/closed This works fine for make/ but not for jdk/make/: $ make jdk CUSTOM_MAKE_DIR=make/closed ? ## Starting jdk lib/ServiceabilityLibraries.gmk:27: make/closed/lib/ServiceabilityLibraries.gmk: No such file or directory make[2]: *** No rule to make target `make/closed/lib/ServiceabilityLibraries.gmk'. Stop. make[1]: *** [libs-only] Error 2 make: *** [jdk-only] Error 2 (I changed "-include" to ?include? to provoke the error.) jdk/make/ files expect CUSTOM_MAKE_DIR to be just ?closed? but that doesn?t work for top-level: $ make jdk CUSTOM_MAKE_DIR=closed /Users/cthalinger/twitter8//make/Main.gmk:35: closed/Main.gmk: No such file or directory make: *** No rule to make target `closed/Main.gmk'. Stop. How is this supposed to work? From rob.mckenna at oracle.com Fri Mar 3 23:09:03 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 3 Mar 2017 23:09:03 +0000 Subject: RFA (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <77ca2f0e-dddd-8357-f94e-bde773bdab49@redhat.com> References: <77ca2f0e-dddd-8357-f94e-bde773bdab49@redhat.com> Message-ID: <20170303230903.GA3196@vimes> Approved, please work with the compiler team to find an appropriate sponsor. -Rob On 03/03/17 06:48, Aleksey Shipilev wrote: > Hi, > > Please approve the backport of this important bugfix to 8u: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8175887 > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2ff05d967fb2 > > Compiler folks agree with backport, and nightlies seem clean: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025767.html > > JDK 8u webrev: > http://cr.openjdk.java.net/~shade/8175887/webrev.04.8u/ > > Product change applies cleanly, but test needs to change j.i.m.Unsafe to > s.m.Unsafe. > > Testing: Linux x86_64/release hotspot/test/compiler/c1 before/after the fix. > > Need a sponsor to push. > > Thanks, > -Aleksey > From shade at redhat.com Mon Mar 6 09:36:19 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Mar 2017 10:36:19 +0100 Subject: RFA (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <20170303230903.GA3196@vimes> References: <77ca2f0e-dddd-8357-f94e-bde773bdab49@redhat.com> <20170303230903.GA3196@vimes> Message-ID: <993390c4-88c4-1c65-03af-47314dbdbfa2@redhat.com> Thanks Rob! Vladimir Ivanov, could you sponsor this one too, please? -Aleksey On 03/04/2017 12:09 AM, Rob McKenna wrote: > Approved, please work with the compiler team to find an appropriate > sponsor. > > -Rob > > On 03/03/17 06:48, Aleksey Shipilev wrote: >> Hi, >> >> Please approve the backport of this important bugfix to 8u: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8175887 >> >> JDK 9 changeset: >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2ff05d967fb2 >> >> Compiler folks agree with backport, and nightlies seem clean: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025767.html >> >> JDK 8u webrev: >> http://cr.openjdk.java.net/~shade/8175887/webrev.04.8u/ >> >> Product change applies cleanly, but test needs to change j.i.m.Unsafe to >> s.m.Unsafe. >> >> Testing: Linux x86_64/release hotspot/test/compiler/c1 before/after the fix. >> >> Need a sponsor to push. >> >> Thanks, >> -Aleksey >> From amoss at tikalk.com Mon Mar 6 15:34:59 2017 From: amoss at tikalk.com (Amos Sonnenwirth) Date: Mon, 6 Mar 2017 17:34:59 +0200 Subject: What is the procedure to install specific OpenJDK Java 8 update ? Message-ID: All, Currently, the latest Java8 OpenJDK update is 121. How can someone install a specific update and not the "latest" one ? I encountered this requirement when trying to install specific Java 8 version on Ubuntu 16 machine. This is crucial especially for automation scripts where you want to have full control of the installed version. Amos From neugens at redhat.com Mon Mar 6 15:40:56 2017 From: neugens at redhat.com (Mario Torre) Date: Mon, 6 Mar 2017 16:40:56 +0100 Subject: What is the procedure to install specific OpenJDK Java 8 update ? In-Reply-To: References: Message-ID: Hello Amos, This is pretty much a downstream question and depends on how distribution of the binary take place, so you need to ask to your provider of the binaries. I, however, strongly recommend to install the latest update, since older version lack the critical security patches (and while downstream distributions may decide to add different things into their packages, this is generally the only difference between minor versions). Cheers, Mario On Mon, Mar 6, 2017 at 4:34 PM, Amos Sonnenwirth wrote: > All, > > Currently, the latest Java8 OpenJDK update is 121. > > How can someone install a specific update and not the "latest" one ? > I encountered this requirement when trying to install specific Java 8 > version on Ubuntu 16 machine. > > This is crucial especially for automation scripts where you want to have > full control of the installed version. > > Amos From rob.mckenna at oracle.com Mon Mar 6 16:37:39 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 6 Mar 2017 16:37:39 +0000 Subject: [8u] request for approval: 8174164 & 8175097: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <5f99874c-8f2e-735c-315e-bd9c454435e6@oracle.com> Message-ID: <20170306163739.GA3656@tecra> Approved, please work with the hotspot team to find a sponsor. -Rob On 02/03/17 05:35, Roland Westrelin wrote: > > > 8u changes looks good. > > Thanks Vladimir. Can I get approval from the jdk 8u gatekeepers for this > and a sponsor? > > Thanks, > Roland. From tobias.hartmann at oracle.com Tue Mar 7 09:41:40 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 7 Mar 2017 10:41:40 +0100 Subject: [8u] request for approval: 8174164 & 8175097: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <5f99874c-8f2e-735c-315e-bd9c454435e6@oracle.com> Message-ID: <63143c2f-2370-772b-5ca9-99b8a01e5d2c@oracle.com> Hi Roland, On 02.03.2017 17:35, Roland Westrelin wrote: > >> 8u changes looks good. > > Thanks Vladimir. Can I get approval from the jdk 8u gatekeepers for this > and a sponsor? I can do the sponsoring, please send me the 8u changeset. Best regards, Tobias From dmitry.markov at oracle.com Wed Mar 8 10:46:57 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 8 Mar 2017 13:46:57 +0300 Subject: [8u-dev] Request for approval 8058316: lookupDefaultPrintService returns null on Solaris 11 when default printer is set using lpoptions command Message-ID: <0A51533E-A02B-46C7-B2C6-C658A29160C5@oracle.com> Hello, Can I get an approval to port the fix for 8058316 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8058316 Webrev: http://cr.openjdk.java.net/~dmarkov/8058316/jdk8u/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006403.html jdk9 changes: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a68589dd5181 Thanks, Dmitry From david.buck at oracle.com Wed Mar 8 10:57:54 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 8 Mar 2017 19:57:54 +0900 Subject: [8u-dev] Request for approval 8058316: lookupDefaultPrintService returns null on Solaris 11 when default printer is set using lpoptions command In-Reply-To: <0A51533E-A02B-46C7-B2C6-C658A29160C5@oracle.com> References: <0A51533E-A02B-46C7-B2C6-C658A29160C5@oracle.com> Message-ID: approved for backport to 8u-dev Cheers, -Buck On 2017/03/08 19:46, Dmitry Markov wrote: > Hello, > > Can I get an approval to port the fix for 8058316 to jdk8u-dev, please? The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8058316 > Webrev: http://cr.openjdk.java.net/~dmarkov/8058316/jdk8u/webrev.00/ > Review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006403.html > jdk9 changes: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a68589dd5181 > > Thanks, > Dmitry > From shade at redhat.com Wed Mar 8 13:24:36 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Mar 2017 14:24:36 +0100 Subject: RFA (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <993390c4-88c4-1c65-03af-47314dbdbfa2@redhat.com> References: <77ca2f0e-dddd-8357-f94e-bde773bdab49@redhat.com> <20170303230903.GA3196@vimes> <993390c4-88c4-1c65-03af-47314dbdbfa2@redhat.com> Message-ID: <1f3bb596-8945-2ab5-b0d1-0ef37812a6d2@redhat.com> (should have copied hs-comp-dev@, sorry) Need a sponsor, thanks! 8u changeset, if you need one: http://cr.openjdk.java.net/~shade/8175887/hs-8175887-8u.changeset -Aleksey On 03/06/2017 10:36 AM, Aleksey Shipilev wrote: > Thanks Rob! > > Vladimir Ivanov, could you sponsor this one too, please? > > -Aleksey > > On 03/04/2017 12:09 AM, Rob McKenna wrote: >> Approved, please work with the compiler team to find an appropriate >> sponsor. >> >> -Rob >> >> On 03/03/17 06:48, Aleksey Shipilev wrote: >>> Hi, >>> >>> Please approve the backport of this important bugfix to 8u: >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8175887 >>> >>> JDK 9 changeset: >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2ff05d967fb2 >>> >>> Compiler folks agree with backport, and nightlies seem clean: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025767.html >>> >>> JDK 8u webrev: >>> http://cr.openjdk.java.net/~shade/8175887/webrev.04.8u/ >>> >>> Product change applies cleanly, but test needs to change j.i.m.Unsafe to >>> s.m.Unsafe. >>> >>> Testing: Linux x86_64/release hotspot/test/compiler/c1 before/after the fix. >>> >>> Need a sponsor to push. >>> >>> Thanks, >>> -Aleksey >>> > From ramanand.patil at oracle.com Thu Mar 9 10:29:58 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 9 Mar 2017 02:29:58 -0800 (PST) Subject: [8u-dev] Request for Approval: Backport of 8176044: (tz) Support tzdata2017a Message-ID: Hi, Please approve the backport of 8176044 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4752e7a805fd JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2017-March/002266.html Changes apply cleanly to jdk8u-dev after path reshuffling. Regards, Ramanand. From rob.mckenna at oracle.com Thu Mar 9 14:09:17 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 9 Mar 2017 14:09:17 +0000 Subject: [8u-dev] Request for Approval: Backport of 8176044: (tz) Support tzdata2017a In-Reply-To: References: Message-ID: <20170309140917.GA2806@vimes> Approved -Rob On 09/03/17 02:29, Ramanand Patil wrote: > Hi, > Please approve the backport of 8176044 to 8u-dev. > Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 > JDK9 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4752e7a805fd > JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2017-March/002266.html > Changes apply cleanly to jdk8u-dev after path reshuffling. > > > Regards, > Ramanand. From Sunny.Chan at gs.com Fri Mar 10 07:01:32 2017 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Fri, 10 Mar 2017 07:01:32 +0000 Subject: RFA: 8169556: Wrapping of FileInputStream's native skip and available methods Message-ID: Hello, I would like to propose backporting JDK-8169556 to JDK8u-dev. The patch mostly applies cleanly except for the make/mapfiles/libjava/mapfile-vers. As a result I have attached the JDK 8 patch in the email. The patch has been tested with java.io test cases. JBS: https://bugs.openjdk.java.net/browse/JDK-8169556 JDK9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/47a8e055bab1 JDK9 patch review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044614.html Sunny Chan Executive Director Technology Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 Learn more about Goldman Sachs GS.com | Blog | LinkedIn | YouTube | Twitter This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. From Sunny.Chan at gs.com Fri Mar 10 07:33:36 2017 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Fri, 10 Mar 2017 07:33:36 +0000 Subject: RFA: 8169556: Wrapping of FileInputStream's native skip and available methods Message-ID: <9515d3d22889474b8390088e764acae4@gsdghkp03etn1.firmwide.corp.gs.com> (It seems like the mailing list filtered the attachment so I am going to inline the patch) Hello, I would like to propose backporting JDK-8169556 to JDK8u-dev. The patch mostly applies cleanly except for the make/mapfiles/libjava/mapfile-vers. As a result I have attached the JDK 8 patch in the email. The patch has been tested with java.io test cases. JBS: https://bugs.openjdk.java.net/browse/JDK-8169556 JDK9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/47a8e055bab1 JDK9 patch review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044614.html # HG changeset patch # User Sunny Chan # Date 1489128533 0 # Fri Mar 10 06:48:53 2017 +0000 # Node ID 0d1759fe196541b8d171c63e4cdfca0b6a20031c # Parent d355fca1b03770f97fc6747ee27d55bb839029a9 8169556: Wrapping of FileInputStream's native skip and available methods Summary: Wrap further native methods in FileInputStreams Contributed-by: sunny.chan at gs.com diff --git a/make/mapfiles/libjava/mapfile-vers b/make/mapfiles/libjava/mapfile-vers --- a/make/mapfiles/libjava/mapfile-vers +++ b/make/mapfiles/libjava/mapfile-vers @@ -76,13 +76,13 @@ Java_java_io_FileDescriptor_initIDs; Java_java_io_FileDescriptor_sync; - Java_java_io_FileInputStream_available; + Java_java_io_FileInputStream_available0; Java_java_io_FileInputStream_close0; Java_java_io_FileInputStream_initIDs; Java_java_io_FileInputStream_open0; Java_java_io_FileInputStream_read0; Java_java_io_FileInputStream_readBytes; - Java_java_io_FileInputStream_skip; + Java_java_io_FileInputStream_skip0; Java_java_io_FileOutputStream_close0; Java_java_io_FileOutputStream_initIDs; Java_java_io_FileOutputStream_open0; diff --git a/make/mapfiles/libjava/reorder-sparc b/make/mapfiles/libjava/reorder-sparc --- a/make/mapfiles/libjava/reorder-sparc +++ b/make/mapfiles/libjava/reorder-sparc @@ -48,7 +48,7 @@ text: .text%fileOpen; text: .text%Java_java_io_FileInputStream_readBytes; text: .text%readBytes; -text: .text%Java_java_io_FileInputStream_available; +text: .text%Java_java_io_FileInputStream_available0; text: .text%Java_java_io_FileInputStream_close0; text: .text%Java_java_lang_System_mapLibraryName; text: .text%Java_java_io_UnixFileSystem_getBooleanAttributes0; diff --git a/make/mapfiles/libjava/reorder-sparcv9 b/make/mapfiles/libjava/reorder-sparcv9 --- a/make/mapfiles/libjava/reorder-sparcv9 +++ b/make/mapfiles/libjava/reorder-sparcv9 @@ -51,7 +51,7 @@ text: .text%fileOpen; text: .text%Java_java_io_FileInputStream_readBytes; text: .text%readBytes; -text: .text%Java_java_io_FileInputStream_available; +text: .text%Java_java_io_FileInputStream_available0; text: .text%Java_java_io_FileInputStream_close0; text: .text%Java_java_lang_Compiler_registerNatives; text: .text%Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2; diff --git a/make/mapfiles/libjava/reorder-x86 b/make/mapfiles/libjava/reorder-x86 --- a/make/mapfiles/libjava/reorder-x86 +++ b/make/mapfiles/libjava/reorder-x86 @@ -78,7 +78,7 @@ text: .text%JNU_GetEnv; text: .text%Java_java_io_UnixFileSystem_checkAccess; text: .text%Java_sun_reflect_NativeMethodAccessorImpl_invoke0; -text: .text%Java_java_io_FileInputStream_available; +text: .text%Java_java_io_FileInputStream_available0; text: .text%Java_java_lang_reflect_Array_newArray; text: .text%Java_java_lang_Throwable_getStackTraceDepth; text: .text%Java_java_lang_Throwable_getStackTraceElement; diff --git a/src/share/classes/java/io/FileInputStream.java b/src/share/classes/java/io/FileInputStream.java --- a/src/share/classes/java/io/FileInputStream.java +++ b/src/share/classes/java/io/FileInputStream.java @@ -279,7 +279,11 @@ * @exception IOException if n is negative, if the stream does not * support seek, or if an I/O error occurs. */ - public native long skip(long n) throws IOException; + public long skip(long n) throws IOException { + return skip0(n); + } + + private native long skip0(long n) throws IOException; /** * Returns an estimate of the number of remaining bytes that can be read (or @@ -298,7 +302,11 @@ * @exception IOException if this file input stream has been closed by calling * {@code close} or an I/O error occurs. */ - public native int available() throws IOException; + public int available() throws IOException { + return available0(); + } + + private native int available0() throws IOException; /** * Closes this file input stream and releases any system resources diff --git a/src/share/native/java/io/FileInputStream.c b/src/share/native/java/io/FileInputStream.c --- a/src/share/native/java/io/FileInputStream.c +++ b/src/share/native/java/io/FileInputStream.c @@ -73,7 +73,7 @@ } JNIEXPORT jlong JNICALL -Java_java_io_FileInputStream_skip(JNIEnv *env, jobject this, jlong toSkip) { +Java_java_io_FileInputStream_skip0(JNIEnv *env, jobject this, jlong toSkip) { jlong cur = jlong_zero; jlong end = jlong_zero; FD fd = GET_FD(this, fis_fd); @@ -90,7 +90,7 @@ } JNIEXPORT jint JNICALL -Java_java_io_FileInputStream_available(JNIEnv *env, jobject this) { +Java_java_io_FileInputStream_available0(JNIEnv *env, jobject this) { jlong ret; FD fd = GET_FD(this, fis_fd); if (fd == -1) { Sunny Chan Executive Director Technology Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 Learn more about Goldman Sachs GS.com | Blog | LinkedIn | YouTube | Twitter This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. From roger.riggs at oracle.com Fri Mar 10 13:05:03 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 10 Mar 2017 08:05:03 -0500 Subject: RFA: 8169556: Wrapping of FileInputStream's native skip and available methods In-Reply-To: <9515d3d22889474b8390088e764acae4@gsdghkp03etn1.firmwide.corp.gs.com> References: <9515d3d22889474b8390088e764acae4@gsdghkp03etn1.firmwide.corp.gs.com> Message-ID: Hi Sunny, yes, the openjdk mail lists filter attachments that don't appear to be text. The in-line patch is fine. I think we need approval from the jdk8u maintenance lead and a sponsor to commit it (I can volunteer if no one else does). Thanks, Roger On 3/10/17 2:33 AM, Chan, Sunny wrote: > (It seems like the mailing list filtered the attachment so I am going to inline the patch) > > Hello, > > I would like to propose backporting JDK-8169556 to JDK8u-dev. The patch mostly applies cleanly except for the make/mapfiles/libjava/mapfile-vers. As a result I have attached the JDK 8 patch in the email. The patch has been tested with java.io test cases. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8169556 > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/47a8e055bab1 > > JDK9 patch review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044614.html > > # HG changeset patch > # User Sunny Chan > # Date 1489128533 0 > # Fri Mar 10 06:48:53 2017 +0000 > # Node ID 0d1759fe196541b8d171c63e4cdfca0b6a20031c > # Parent d355fca1b03770f97fc6747ee27d55bb839029a9 > 8169556: Wrapping of FileInputStream's native skip and available methods > Summary: Wrap further native methods in FileInputStreams > Contributed-by: sunny.chan at gs.com > > diff --git a/make/mapfiles/libjava/mapfile-vers b/make/mapfiles/libjava/mapfile-vers > --- a/make/mapfiles/libjava/mapfile-vers > +++ b/make/mapfiles/libjava/mapfile-vers > @@ -76,13 +76,13 @@ > Java_java_io_FileDescriptor_initIDs; > Java_java_io_FileDescriptor_sync; > - Java_java_io_FileInputStream_available; > + Java_java_io_FileInputStream_available0; > Java_java_io_FileInputStream_close0; > Java_java_io_FileInputStream_initIDs; > Java_java_io_FileInputStream_open0; > Java_java_io_FileInputStream_read0; > Java_java_io_FileInputStream_readBytes; > - Java_java_io_FileInputStream_skip; > + Java_java_io_FileInputStream_skip0; > Java_java_io_FileOutputStream_close0; > Java_java_io_FileOutputStream_initIDs; > Java_java_io_FileOutputStream_open0; > diff --git a/make/mapfiles/libjava/reorder-sparc b/make/mapfiles/libjava/reorder-sparc > --- a/make/mapfiles/libjava/reorder-sparc > +++ b/make/mapfiles/libjava/reorder-sparc > @@ -48,7 +48,7 @@ > text: .text%fileOpen; > text: .text%Java_java_io_FileInputStream_readBytes; > text: .text%readBytes; > -text: .text%Java_java_io_FileInputStream_available; > +text: .text%Java_java_io_FileInputStream_available0; > text: .text%Java_java_io_FileInputStream_close0; > text: .text%Java_java_lang_System_mapLibraryName; > text: .text%Java_java_io_UnixFileSystem_getBooleanAttributes0; > diff --git a/make/mapfiles/libjava/reorder-sparcv9 b/make/mapfiles/libjava/reorder-sparcv9 > --- a/make/mapfiles/libjava/reorder-sparcv9 > +++ b/make/mapfiles/libjava/reorder-sparcv9 > @@ -51,7 +51,7 @@ > text: .text%fileOpen; > text: .text%Java_java_io_FileInputStream_readBytes; > text: .text%readBytes; > -text: .text%Java_java_io_FileInputStream_available; > +text: .text%Java_java_io_FileInputStream_available0; > text: .text%Java_java_io_FileInputStream_close0; > text: .text%Java_java_lang_Compiler_registerNatives; > text: .text%Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2; > diff --git a/make/mapfiles/libjava/reorder-x86 b/make/mapfiles/libjava/reorder-x86 > --- a/make/mapfiles/libjava/reorder-x86 > +++ b/make/mapfiles/libjava/reorder-x86 > @@ -78,7 +78,7 @@ > text: .text%JNU_GetEnv; > text: .text%Java_java_io_UnixFileSystem_checkAccess; > text: .text%Java_sun_reflect_NativeMethodAccessorImpl_invoke0; > -text: .text%Java_java_io_FileInputStream_available; > +text: .text%Java_java_io_FileInputStream_available0; > text: .text%Java_java_lang_reflect_Array_newArray; > text: .text%Java_java_lang_Throwable_getStackTraceDepth; > text: .text%Java_java_lang_Throwable_getStackTraceElement; > diff --git a/src/share/classes/java/io/FileInputStream.java b/src/share/classes/java/io/FileInputStream.java > --- a/src/share/classes/java/io/FileInputStream.java > +++ b/src/share/classes/java/io/FileInputStream.java > @@ -279,7 +279,11 @@ > * @exception IOException if n is negative, if the stream does not > * support seek, or if an I/O error occurs. > */ > - public native long skip(long n) throws IOException; > + public long skip(long n) throws IOException { > + return skip0(n); > + } > + > + private native long skip0(long n) throws IOException; > /** > * Returns an estimate of the number of remaining bytes that can be read (or > @@ -298,7 +302,11 @@ > * @exception IOException if this file input stream has been closed by calling > * {@code close} or an I/O error occurs. > */ > - public native int available() throws IOException; > + public int available() throws IOException { > + return available0(); > + } > + > + private native int available0() throws IOException; > /** > * Closes this file input stream and releases any system resources > diff --git a/src/share/native/java/io/FileInputStream.c b/src/share/native/java/io/FileInputStream.c > --- a/src/share/native/java/io/FileInputStream.c > +++ b/src/share/native/java/io/FileInputStream.c > @@ -73,7 +73,7 @@ > } > JNIEXPORT jlong JNICALL > -Java_java_io_FileInputStream_skip(JNIEnv *env, jobject this, jlong toSkip) { > +Java_java_io_FileInputStream_skip0(JNIEnv *env, jobject this, jlong toSkip) { > jlong cur = jlong_zero; > jlong end = jlong_zero; > FD fd = GET_FD(this, fis_fd); > @@ -90,7 +90,7 @@ > } > JNIEXPORT jint JNICALL > -Java_java_io_FileInputStream_available(JNIEnv *env, jobject this) { > +Java_java_io_FileInputStream_available0(JNIEnv *env, jobject this) { > jlong ret; > FD fd = GET_FD(this, fis_fd); > if (fd == -1) { > > > Sunny Chan > Executive Director > Technology > > Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong > Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 > > Learn more about Goldman Sachs > GS.com | Blog | LinkedIn | YouTube | Twitter > > This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. > From rob.mckenna at oracle.com Fri Mar 10 13:58:49 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 10 Mar 2017 13:58:49 +0000 Subject: RFA: 8169556: Wrapping of FileInputStream's native skip and available methods In-Reply-To: References: <9515d3d22889474b8390088e764acae4@gsdghkp03etn1.firmwide.corp.gs.com> Message-ID: <20170310135849.GA2958@vimes> Approved -Rob On 10/03/17 08:05, Roger Riggs wrote: > Hi Sunny, > > yes, the openjdk mail lists filter attachments that don't appear to be text. > The in-line patch is fine. > > I think we need approval from the jdk8u maintenance lead and a sponsor to > commit it > (I can volunteer if no one else does). > > Thanks, Roger > > > > On 3/10/17 2:33 AM, Chan, Sunny wrote: > >(It seems like the mailing list filtered the attachment so I am going to inline the patch) > > > >Hello, > > > >I would like to propose backporting JDK-8169556 to JDK8u-dev. The patch mostly applies cleanly except for the make/mapfiles/libjava/mapfile-vers. As a result I have attached the JDK 8 patch in the email. The patch has been tested with java.io test cases. > > > >JBS: > >https://bugs.openjdk.java.net/browse/JDK-8169556 > > > >JDK9 changeset: > >http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/47a8e055bab1 > > > >JDK9 patch review thread: > >http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044614.html > > > ># HG changeset patch > ># User Sunny Chan > ># Date 1489128533 0 > ># Fri Mar 10 06:48:53 2017 +0000 > ># Node ID 0d1759fe196541b8d171c63e4cdfca0b6a20031c > ># Parent d355fca1b03770f97fc6747ee27d55bb839029a9 > >8169556: Wrapping of FileInputStream's native skip and available methods > >Summary: Wrap further native methods in FileInputStreams > >Contributed-by: sunny.chan at gs.com > > > >diff --git a/make/mapfiles/libjava/mapfile-vers b/make/mapfiles/libjava/mapfile-vers > >--- a/make/mapfiles/libjava/mapfile-vers > >+++ b/make/mapfiles/libjava/mapfile-vers > >@@ -76,13 +76,13 @@ > > Java_java_io_FileDescriptor_initIDs; > > Java_java_io_FileDescriptor_sync; > >- Java_java_io_FileInputStream_available; > >+ Java_java_io_FileInputStream_available0; > > Java_java_io_FileInputStream_close0; > > Java_java_io_FileInputStream_initIDs; > > Java_java_io_FileInputStream_open0; > > Java_java_io_FileInputStream_read0; > > Java_java_io_FileInputStream_readBytes; > >- Java_java_io_FileInputStream_skip; > >+ Java_java_io_FileInputStream_skip0; > > Java_java_io_FileOutputStream_close0; > > Java_java_io_FileOutputStream_initIDs; > > Java_java_io_FileOutputStream_open0; > >diff --git a/make/mapfiles/libjava/reorder-sparc b/make/mapfiles/libjava/reorder-sparc > >--- a/make/mapfiles/libjava/reorder-sparc > >+++ b/make/mapfiles/libjava/reorder-sparc > >@@ -48,7 +48,7 @@ > >text: .text%fileOpen; > >text: .text%Java_java_io_FileInputStream_readBytes; > >text: .text%readBytes; > >-text: .text%Java_java_io_FileInputStream_available; > >+text: .text%Java_java_io_FileInputStream_available0; > >text: .text%Java_java_io_FileInputStream_close0; > >text: .text%Java_java_lang_System_mapLibraryName; > >text: .text%Java_java_io_UnixFileSystem_getBooleanAttributes0; > >diff --git a/make/mapfiles/libjava/reorder-sparcv9 b/make/mapfiles/libjava/reorder-sparcv9 > >--- a/make/mapfiles/libjava/reorder-sparcv9 > >+++ b/make/mapfiles/libjava/reorder-sparcv9 > >@@ -51,7 +51,7 @@ > >text: .text%fileOpen; > >text: .text%Java_java_io_FileInputStream_readBytes; > >text: .text%readBytes; > >-text: .text%Java_java_io_FileInputStream_available; > >+text: .text%Java_java_io_FileInputStream_available0; > >text: .text%Java_java_io_FileInputStream_close0; > >text: .text%Java_java_lang_Compiler_registerNatives; > >text: .text%Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2; > >diff --git a/make/mapfiles/libjava/reorder-x86 b/make/mapfiles/libjava/reorder-x86 > >--- a/make/mapfiles/libjava/reorder-x86 > >+++ b/make/mapfiles/libjava/reorder-x86 > >@@ -78,7 +78,7 @@ > >text: .text%JNU_GetEnv; > >text: .text%Java_java_io_UnixFileSystem_checkAccess; > >text: .text%Java_sun_reflect_NativeMethodAccessorImpl_invoke0; > >-text: .text%Java_java_io_FileInputStream_available; > >+text: .text%Java_java_io_FileInputStream_available0; > >text: .text%Java_java_lang_reflect_Array_newArray; > >text: .text%Java_java_lang_Throwable_getStackTraceDepth; > >text: .text%Java_java_lang_Throwable_getStackTraceElement; > >diff --git a/src/share/classes/java/io/FileInputStream.java b/src/share/classes/java/io/FileInputStream.java > >--- a/src/share/classes/java/io/FileInputStream.java > >+++ b/src/share/classes/java/io/FileInputStream.java > >@@ -279,7 +279,11 @@ > > * @exception IOException if n is negative, if the stream does not > > * support seek, or if an I/O error occurs. > > */ > >- public native long skip(long n) throws IOException; > >+ public long skip(long n) throws IOException { > >+ return skip0(n); > >+ } > >+ > >+ private native long skip0(long n) throws IOException; > > /** > > * Returns an estimate of the number of remaining bytes that can be read (or > >@@ -298,7 +302,11 @@ > > * @exception IOException if this file input stream has been closed by calling > > * {@code close} or an I/O error occurs. > > */ > >- public native int available() throws IOException; > >+ public int available() throws IOException { > >+ return available0(); > >+ } > >+ > >+ private native int available0() throws IOException; > > /** > > * Closes this file input stream and releases any system resources > >diff --git a/src/share/native/java/io/FileInputStream.c b/src/share/native/java/io/FileInputStream.c > >--- a/src/share/native/java/io/FileInputStream.c > >+++ b/src/share/native/java/io/FileInputStream.c > >@@ -73,7 +73,7 @@ > >} > > JNIEXPORT jlong JNICALL > >-Java_java_io_FileInputStream_skip(JNIEnv *env, jobject this, jlong toSkip) { > >+Java_java_io_FileInputStream_skip0(JNIEnv *env, jobject this, jlong toSkip) { > > jlong cur = jlong_zero; > > jlong end = jlong_zero; > > FD fd = GET_FD(this, fis_fd); > >@@ -90,7 +90,7 @@ > >} > > JNIEXPORT jint JNICALL > >-Java_java_io_FileInputStream_available(JNIEnv *env, jobject this) { > >+Java_java_io_FileInputStream_available0(JNIEnv *env, jobject this) { > > jlong ret; > > FD fd = GET_FD(this, fis_fd); > > if (fd == -1) { > > > > > >Sunny Chan > >Executive Director > >Technology > > > >Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong > >Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 > > > >Learn more about Goldman Sachs > >GS.com | Blog | LinkedIn | YouTube | Twitter > > > >This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. > > > From Sunny.Chan at gs.com Tue Mar 14 02:28:43 2017 From: Sunny.Chan at gs.com (Chan, Sunny) Date: Tue, 14 Mar 2017 02:28:43 +0000 Subject: RFA: 8169556: Wrapping of FileInputStream's native skip and available methods Message-ID: Hi Roger, Could you commit the change, please? ------------------------------ Message: 3 Date: Fri, 10 Mar 2017 13:58:49 +0000 From: Rob McKenna To: Roger Riggs Cc: jdk8u-dev at openjdk.java.net Subject: Re: RFA: 8169556: Wrapping of FileInputStream's native skip and available methods Message-ID: <20170310135849.GA2958 at vimes> Content-Type: text/plain; charset=us-ascii Approved -Rob On 10/03/17 08:05, Roger Riggs wrote: > Hi Sunny, > > yes, the openjdk mail lists filter attachments that don't appear to be text. > The in-line patch is fine. > > I think we need approval from the jdk8u maintenance lead and a sponsor > to commit it (I can volunteer if no one else does). > > Thanks, Roger > > > > On 3/10/17 2:33 AM, Chan, Sunny wrote: > >(It seems like the mailing list filtered the attachment so I am going > >to inline the patch) > > > >Hello, > > > >I would like to propose backporting JDK-8169556 to JDK8u-dev. The patch mostly applies cleanly except for the make/mapfiles/libjava/mapfile-vers. As a result I have attached the JDK 8 patch in the email. The patch has been tested with java.io test cases. > > > >JBS: > >https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.jav > >a.net_browse_JDK-2D8169556&d=DgICAg&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rT > >ZOYPxLxfZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=g8JC-8bK > >Y4zCKUW7SdImmGCCn7LBQBLD5Z6pAe598uo&s=ME5fTW83mCNaV65jbt7wnhdfl5uPlZD > >nWcmhX87_6HQ&e= > > > >JDK9 changeset: > >https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.n > >et_jdk9_jdk9_jdk_rev_47a8e055bab1&d=DgICAg&c=7563p3e2zaQw0AB1wrFVgyag > >b2IE5rTZOYPxLxfZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=g > >8JC-8bKY4zCKUW7SdImmGCCn7LBQBLD5Z6pAe598uo&s=jMGzbs0iV9X2klPr2G8s3ufu > >oywgnWkDK2UCQ92-0cw&e= > > > >JDK9 patch review thread: > >https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java > >.net_pipermail_core-2Dlibs-2Ddev_2016-2DNovember_044614.html&d=DgICAg > >&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=e-nMYEAYoRWWms8SM-H9 > >7SgyQYsz-xaiLmQPYwZ3m5E&m=g8JC-8bKY4zCKUW7SdImmGCCn7LBQBLD5Z6pAe598uo > >&s=EyVcTSFnFCvGdr5-DyoKZ5oTjcVtvHqVg7euSbMWeE0&e= > > > ># HG changeset patch > ># User Sunny Chan # Date 1489128533 0 > ># Fri Mar 10 06:48:53 2017 +0000 > ># Node ID 0d1759fe196541b8d171c63e4cdfca0b6a20031c > ># Parent d355fca1b03770f97fc6747ee27d55bb839029a9 > >8169556: Wrapping of FileInputStream's native skip and available > >methods > >Summary: Wrap further native methods in FileInputStreams > >Contributed-by: sunny.chan at gs.com > > > >diff --git a/make/mapfiles/libjava/mapfile-vers > >b/make/mapfiles/libjava/mapfile-vers > >--- a/make/mapfiles/libjava/mapfile-vers > >+++ b/make/mapfiles/libjava/mapfile-vers > >@@ -76,13 +76,13 @@ > > Java_java_io_FileDescriptor_initIDs; > > Java_java_io_FileDescriptor_sync; > >- Java_java_io_FileInputStream_available; > >+ > >+ Java_java_io_FileInputStream_available0; > > Java_java_io_FileInputStream_close0; > > Java_java_io_FileInputStream_initIDs; > > Java_java_io_FileInputStream_open0; > > Java_java_io_FileInputStream_read0; > > Java_java_io_FileInputStream_readBytes; > >- Java_java_io_FileInputStream_skip; > >+ Java_java_io_FileInputStream_skip0; > > Java_java_io_FileOutputStream_close0; > > Java_java_io_FileOutputStream_initIDs; > > Java_java_io_FileOutputStream_open0; > >diff --git a/make/mapfiles/libjava/reorder-sparc > >b/make/mapfiles/libjava/reorder-sparc > >--- a/make/mapfiles/libjava/reorder-sparc > >+++ b/make/mapfiles/libjava/reorder-sparc > >@@ -48,7 +48,7 @@ > >text: .text%fileOpen; > >text: .text%Java_java_io_FileInputStream_readBytes; > >text: .text%readBytes; > >-text: .text%Java_java_io_FileInputStream_available; > >+text: .text%Java_java_io_FileInputStream_available0; > >text: .text%Java_java_io_FileInputStream_close0; > >text: .text%Java_java_lang_System_mapLibraryName; > >text: .text%Java_java_io_UnixFileSystem_getBooleanAttributes0; > >diff --git a/make/mapfiles/libjava/reorder-sparcv9 > >b/make/mapfiles/libjava/reorder-sparcv9 > >--- a/make/mapfiles/libjava/reorder-sparcv9 > >+++ b/make/mapfiles/libjava/reorder-sparcv9 > >@@ -51,7 +51,7 @@ > >text: .text%fileOpen; > >text: .text%Java_java_io_FileInputStream_readBytes; > >text: .text%readBytes; > >-text: .text%Java_java_io_FileInputStream_available; > >+text: .text%Java_java_io_FileInputStream_available0; > >text: .text%Java_java_io_FileInputStream_close0; > >text: .text%Java_java_lang_Compiler_registerNatives; > >text: > >.text%Java_java_security_AccessController_doPrivileged__Ljava_securit > >y_PrivilegedExceptionAction_2; diff --git > >a/make/mapfiles/libjava/reorder-x86 > >b/make/mapfiles/libjava/reorder-x86 > >--- a/make/mapfiles/libjava/reorder-x86 > >+++ b/make/mapfiles/libjava/reorder-x86 > >@@ -78,7 +78,7 @@ > >text: .text%JNU_GetEnv; > >text: .text%Java_java_io_UnixFileSystem_checkAccess; > >text: .text%Java_sun_reflect_NativeMethodAccessorImpl_invoke0; > >-text: .text%Java_java_io_FileInputStream_available; > >+text: .text%Java_java_io_FileInputStream_available0; > >text: .text%Java_java_lang_reflect_Array_newArray; > >text: .text%Java_java_lang_Throwable_getStackTraceDepth; > >text: .text%Java_java_lang_Throwable_getStackTraceElement; > >diff --git a/src/share/classes/java/io/FileInputStream.java > >b/src/share/classes/java/io/FileInputStream.java > >--- a/src/share/classes/java/io/FileInputStream.java > >+++ b/src/share/classes/java/io/FileInputStream.java > >@@ -279,7 +279,11 @@ > > * @exception IOException if n is negative, if the stream does not > > * support seek, or if an I/O error occurs. > > */ > >- public native long skip(long n) throws IOException; > >+ public long skip(long n) throws IOException { > >+ return skip0(n); > >+ } > >+ > >+ private native long skip0(long n) throws IOException; > > /** > > * Returns an estimate of the number of remaining bytes that > >can be read (or @@ -298,7 +302,11 @@ > > * @exception IOException if this file input stream has been closed by calling > > * {@code close} or an I/O error occurs. > > */ > >- public native int available() throws IOException; > >+ public int available() throws IOException { > >+ return available0(); > >+ } > >+ > >+ private native int available0() throws IOException; > > /** > > * Closes this file input stream and releases any system > >resources diff --git a/src/share/native/java/io/FileInputStream.c > >b/src/share/native/java/io/FileInputStream.c > >--- a/src/share/native/java/io/FileInputStream.c > >+++ b/src/share/native/java/io/FileInputStream.c > >@@ -73,7 +73,7 @@ > >} > > JNIEXPORT jlong JNICALL > >-Java_java_io_FileInputStream_skip(JNIEnv *env, jobject this, jlong > >toSkip) { > >+Java_java_io_FileInputStream_skip0(JNIEnv *env, jobject this, jlong > >+toSkip) { > > jlong cur = jlong_zero; > > jlong end = jlong_zero; > > FD fd = GET_FD(this, fis_fd); > >@@ -90,7 +90,7 @@ > >} > > JNIEXPORT jint JNICALL > >-Java_java_io_FileInputStream_available(JNIEnv *env, jobject this) { > >+Java_java_io_FileInputStream_available0(JNIEnv *env, jobject this) { > > jlong ret; > > FD fd = GET_FD(this, fis_fd); > > if (fd == -1) { > > > > > >Sunny Chan > >Executive Director > >Technology > > > >Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens > >Road Central | Hong Kong > >Email: sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633 > > > >Learn more about Goldman Sachs > >GS.com | > >Blog | > >LinkedIn >edin.com_company_goldman-2Dsachs_careers&d=DgICAg&c=7563p3e2zaQw0AB1w > >rFVgyagb2IE5rTZOYPxLxfZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3 > >m5E&m=g8JC-8bKY4zCKUW7SdImmGCCn7LBQBLD5Z6pAe598uo&s=BN--VVWrR5Js_oUGC > >OF-nN-4vy5RsICzBRXHF9gahXs&e= > | > >YouTube >be.com_goldmansachs&d=DgICAg&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLx > >fZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=g8JC-8bKY4zCKUW > >7SdImmGCCn7LBQBLD5Z6pAe598uo&s=X5I9ZcWMLNh2AnSwoqLekvzwex4DRdr0LFlBhs > >qArk0&e= > | > >Twitter >er.com_goldmansachs&d=DgICAg&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLx > >fZlX4&r=e-nMYEAYoRWWms8SM-H97SgyQYsz-xaiLmQPYwZ3m5E&m=g8JC-8bKY4zCKUW > >7SdImmGCCn7LBQBLD5Z6pAe598uo&s=sTAowGTKigVmr5xAeBtLwZ2_Lbqy-bPcdmlT5r > >TsF3s&e= > > > > >This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication. > > > End of jdk8u-dev Digest, Vol 40, Issue 3 **************************************** From dmitry.markov at oracle.com Tue Mar 14 07:33:17 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Tue, 14 Mar 2017 10:33:17 +0300 Subject: [8u-dev] Request for approval 8173853: IllegalArgumentException in java.awt.image.ReplicateScaleFilter Message-ID: <58C79CBD.6020009@oracle.com> Hello, Can I get an approval to port the fix for 8173853 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8173853 Webrev: http://cr.openjdk.java.net/~dmarkov/8173853/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-March/012643.html jdk9 changes: http://hg.openjdk.java.net/jdk9/client/jdk/rev/75a8a6117014 Thanks, Dmitry From david.buck at oracle.com Tue Mar 14 07:54:00 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 14 Mar 2017 16:54:00 +0900 Subject: [8u-dev] Request for approval 8173853: IllegalArgumentException in java.awt.image.ReplicateScaleFilter In-Reply-To: <58C79CBD.6020009@oracle.com> References: <58C79CBD.6020009@oracle.com> Message-ID: approved for backport to 8u-dev # I am assuming the linked webrev matches the Mercurial push exactly. Cheers, -Buck On 2017/03/14 16:33, dmitry markov wrote: > Hello, > > Can I get an approval to port the fix for 8173853 to jdk8u-dev, please? > The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8173853 > Webrev: http://cr.openjdk.java.net/~dmarkov/8173853/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2017-March/012643.html > jdk9 changes: http://hg.openjdk.java.net/jdk9/client/jdk/rev/75a8a6117014 > > Thanks, > Dmitry > From kevin.walls at oracle.com Tue Mar 14 22:48:09 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 14 Mar 2017 22:48:09 +0000 Subject: RFA: 8043913: remove legacy code in SPARC's VM_Version::platform_features Message-ID: Hi, I'm seeking approval to backport into jdk8u: 8043913: remove legacy code in SPARC's VM_Version::platform_features https://bugs.openjdk.java.net/browse/JDK-8043913 This is a straight import of the change in 9: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 It removes some getisax() checks and does some reformatting in the Solaris SPARC VM_Version code in src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp. We're presuming we are always on Solaris 10 or later, and this change will make further changes in that area more straightforward (there are a couple more backports to come...). Thanks Kevin From shafi.s.ahmad at oracle.com Wed Mar 15 05:01:35 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Tue, 14 Mar 2017 22:01:35 -0700 (PDT) Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field Message-ID: <3eb77923-9e97-4846-abcb-773707938320@default> Hi, May I get the approval of enhancement backport of 'JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field' to jdk8u-dev. Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 "java.lang.ClassFormatError: Duplicate field name&signature in class file CampaignClient" >From the above Exception message, there is no easy way of knowing what is triggering the problem. If the class in question is quite big so removing code by trial and error is very time consuming. With field name + signature, pinpointing the actual problematic code will be easy and time saving. I have tested it with the jprt and jtreg tests. Regards, Shafi From sean.coffey at oracle.com Wed Mar 15 09:09:20 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 15 Mar 2017 09:09:20 +0000 Subject: RFA: 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: References: Message-ID: Hi Kevin, this is an enhancement backport request. Please see rule 3 [1]. You'll need to file such a request first. regards, Sean. On 14/03/2017 22:48, Kevin Walls wrote: > Hi, > > I'm seeking approval to backport into jdk8u: > > 8043913: remove legacy code in SPARC's VM_Version::platform_features > https://bugs.openjdk.java.net/browse/JDK-8043913 > > This is a straight import of the change in 9: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 > > It removes some getisax() checks and does some reformatting in the > Solaris SPARC VM_Version code in > src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp. We're > presuming we are always on Solaris 10 or later, and this change will > make further changes in that area more straightforward (there are a > couple more backports to come...). > > Thanks > Kevin > From sean.coffey at oracle.com Wed Mar 15 09:32:12 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 15 Mar 2017 09:32:12 +0000 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <3eb77923-9e97-4846-abcb-773707938320@default> References: <3eb77923-9e97-4846-abcb-773707938320@default> Message-ID: <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> Hi Shafi, Your request has been logged and I'll update you once a decision has been reached. If this was for porting, you should have pushed the original change to jdk9 and not jdk10. This has already been widely communicated on the jdk10 OpenJDK mailing list. regards, Sean. On 15/03/2017 05:01, Shafi Ahmad wrote: > Hi, > > May I get the approval of enhancement backport of 'JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field' to jdk8u-dev. > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 > > "java.lang.ClassFormatError: Duplicate field name&signature in class file CampaignClient" > > From the above Exception message, there is no easy way of knowing what is triggering the problem. > If the class in question is quite big so removing code by trial and error is very time consuming. > > With field name + signature, pinpointing the actual problematic code will be easy and time saving. > > I have tested it with the jprt and jtreg tests. > > Regards, > Shafi > From sean.coffey at oracle.com Wed Mar 15 09:37:46 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 15 Mar 2017 09:37:46 +0000 Subject: RFA: 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: References: Message-ID: Forgot the link : [1] http://openjdk.java.net/projects/jdk8u/groundrules.html On 15/03/2017 09:09, Se?n Coffey wrote: > Hi Kevin, > > this is an enhancement backport request. Please see rule 3 [1]. You'll > need to file such a request first. > > regards, > Sean. > > On 14/03/2017 22:48, Kevin Walls wrote: >> Hi, >> >> I'm seeking approval to backport into jdk8u: >> >> 8043913: remove legacy code in SPARC's VM_Version::platform_features >> https://bugs.openjdk.java.net/browse/JDK-8043913 >> >> This is a straight import of the change in 9: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/99995cb1ae44 >> >> It removes some getisax() checks and does some reformatting in the >> Solaris SPARC VM_Version code in >> src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp. We're >> presuming we are always on Solaris 10 or later, and this change will >> make further changes in that area more straightforward (there are a >> couple more backports to come...). >> >> Thanks >> Kevin >> > From shafi.s.ahmad at oracle.com Wed Mar 15 09:59:25 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 15 Mar 2017 02:59:25 -0700 (PDT) Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> References: <3eb77923-9e97-4846-abcb-773707938320@default> <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> Message-ID: <3768907d-2603-43d9-ad24-574019d07240@default> Hi Sean, I am sorry I should have asked for push to jdk9 but I didn't do because I had asked for other issue and it was not approved to push first into jdk9. So I thought I have to follow same process but my assumption may not be correct as this is a P3 and other one was P4. --------------------------------------- http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-February/026004.html Hi Shafi, On 23/02/2017 7:28 PM, Shafi Ahmad wrote: > Hi Coleen, David, > > This is reviewed for jdk10 but when I sent for push to one of my colleague he has suggested me to push is jdk9 and this will automatically pushed to jdk10. > > So can this be pushed this to jdk9? If yes should I sent a separate review request or current review is sufficient? No - this is a P4 bug and we are in RDP1 for JDK 9 so this can not be pushed to 9 unless it goes through a specific critical approval process. --------------------------------------- Regards, Shafi > -----Original Message----- > From: Se?n Coffey > Sent: Wednesday, March 15, 2017 3:02 PM > To: Shafi Ahmad ; jdk8u-dev at openjdk.java.net > Cc: Kevin Walls > Subject: Re: [8u] Request for enhancement backport approval for CR JDK- > 8171194: Exception "Duplicate field name&signature in class file" should > report the name and signature of the field > > Hi Shafi, > > Your request has been logged and I'll update you once a decision has been > reached. > > If this was for porting, you should have pushed the original change to > jdk9 and not jdk10. This has already been widely communicated on the > jdk10 OpenJDK mailing list. > > regards, > Sean. > > > On 15/03/2017 05:01, Shafi Ahmad wrote: > > Hi, > > > > May I get the approval of enhancement backport of 'JDK-8171194: > Exception "Duplicate field name&signature in class file" should report the > name and signature of the field' to jdk8u-dev. > > > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 > > > > "java.lang.ClassFormatError: Duplicate field name&signature in class file > CampaignClient" > > > > From the above Exception message, there is no easy way of knowing what > is triggering the problem. > > If the class in question is quite big so removing code by trial and error is > very time consuming. > > > > With field name + signature, pinpointing the actual problematic code will be > easy and time saving. > > > > I have tested it with the jprt and jtreg tests. > > > > Regards, > > Shafi > > > From david.holmes at oracle.com Wed Mar 15 10:07:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Mar 2017 20:07:35 +1000 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> References: <3eb77923-9e97-4846-abcb-773707938320@default> <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> Message-ID: <57c3b02e-9d90-26c3-b319-cbd8d38c9786@oracle.com> Hi Sean, On 15/03/2017 7:32 PM, Se?n Coffey wrote: > Hi Shafi, > > Your request has been logged and I'll update you once a decision has > been reached. > > If this was for porting, you should have pushed the original change to > jdk9 and not jdk10. This has already been widely communicated on the > jdk10 OpenJDK mailing list. I assume you are referring to: http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-March/000105.html But 9 is closed for RFEs so that is not a possible workflow here. David ----- > regards, > Sean. > > > On 15/03/2017 05:01, Shafi Ahmad wrote: >> Hi, >> >> May I get the approval of enhancement backport of 'JDK-8171194: >> Exception "Duplicate field name&signature in class file" should report >> the name and signature of the field' to jdk8u-dev. >> >> Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 >> >> "java.lang.ClassFormatError: Duplicate field name&signature in class >> file CampaignClient" >> >> From the above Exception message, there is no easy way of knowing >> what is triggering the problem. >> If the class in question is quite big so removing code by trial and >> error is very time consuming. >> >> With field name + signature, pinpointing the actual problematic code >> will be easy and time saving. >> >> I have tested it with the jprt and jtreg tests. >> >> Regards, >> Shafi >> > From kevin.walls at oracle.com Wed Mar 15 10:29:09 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 15 Mar 2017 10:29:09 +0000 Subject: [8u] Request for enhancement backport approval for CR 8043913: remove legacy code in SPARC's VM_Version::platform_features Message-ID: <74822698-123f-b765-54b7-17fb6afef844@oracle.com> Hi, 8043913: remove legacy code in SPARC's VM_Version::platform_features https://bugs.openjdk.java.net/browse/JDK-8043913 This backport is required to support other changes in the same area in 8u. In 9, this change happens before other changes in the same file, so having this change will make other work simpler and have the histories more similar in 8u and later releases. Thanks Kevin From sean.coffey at oracle.com Wed Mar 15 12:01:14 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 15 Mar 2017 12:01:14 +0000 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <57c3b02e-9d90-26c3-b319-cbd8d38c9786@oracle.com> References: <3eb77923-9e97-4846-abcb-773707938320@default> <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> <57c3b02e-9d90-26c3-b319-cbd8d38c9786@oracle.com> Message-ID: <2caeaa44-bcf0-853f-c473-c934e44f8300@oracle.com> David, I think Shafi should iron out his plans for JDK 9 inclusion before getting to a JDK 8u request then. We need to start looking at plans around how JDK 9 fixes occur post JDK 9 GA. JDK 9 RFEs are still possible via an approved process but I'm aware that JDK 9 will start to close down on contributions given that GA is approaching. Regards, Sean. On 15/03/17 10:07, David Holmes wrote: > Hi Sean, > > On 15/03/2017 7:32 PM, Se?n Coffey wrote: >> Hi Shafi, >> >> Your request has been logged and I'll update you once a decision has >> been reached. >> >> If this was for porting, you should have pushed the original change to >> jdk9 and not jdk10. This has already been widely communicated on the >> jdk10 OpenJDK mailing list. > > I assume you are referring to: > > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-March/000105.html > > But 9 is closed for RFEs so that is not a possible workflow here. > > David > ----- > >> regards, >> Sean. >> >> >> On 15/03/2017 05:01, Shafi Ahmad wrote: >>> Hi, >>> >>> May I get the approval of enhancement backport of 'JDK-8171194: >>> Exception "Duplicate field name&signature in class file" should report >>> the name and signature of the field' to jdk8u-dev. >>> >>> Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 >>> >>> "java.lang.ClassFormatError: Duplicate field name&signature in class >>> file CampaignClient" >>> >>> From the above Exception message, there is no easy way of knowing >>> what is triggering the problem. >>> If the class in question is quite big so removing code by trial and >>> error is very time consuming. >>> >>> With field name + signature, pinpointing the actual problematic code >>> will be easy and time saving. >>> >>> I have tested it with the jprt and jtreg tests. >>> >>> Regards, >>> Shafi >>> >> From david.holmes at oracle.com Wed Mar 15 12:18:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Mar 2017 22:18:00 +1000 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <2caeaa44-bcf0-853f-c473-c934e44f8300@oracle.com> References: <3eb77923-9e97-4846-abcb-773707938320@default> <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> <57c3b02e-9d90-26c3-b319-cbd8d38c9786@oracle.com> <2caeaa44-bcf0-853f-c473-c934e44f8300@oracle.com> Message-ID: Hi Sean, On 15/03/2017 10:01 PM, Se?n Coffey wrote: > David, > > I think Shafi should iron out his plans for JDK 9 inclusion before > getting to a JDK 8u request then. We need to start looking at plans > around how JDK 9 fixes occur post JDK 9 GA. JDK 9 RFEs are still > possible via an approved process but I'm aware that JDK 9 will start to > close down on contributions given that GA is approaching. There may be numerous issues (not just RFE's) that miss the cutoff for 9 but which are worth backporting to 8u. Are you saying there is no way for these to get into 8u unless they go through the currently non-existent 9u first? JDK 9 is effectively closed in this case because it is both a RFE and low-priority. It would not get through the approval process nor does it warrant even attempting to do so. The general 8u backport process requires pushing to the "current release" first - but that is not possible at this stage of the 9 release. So pushing to 10 is the only alternative and then backport to 8u from there. Once 9u exists then it can be backported to there as well. Thanks, David ----- > Regards, > Sean. > > On 15/03/17 10:07, David Holmes wrote: >> Hi Sean, >> >> On 15/03/2017 7:32 PM, Se?n Coffey wrote: >>> Hi Shafi, >>> >>> Your request has been logged and I'll update you once a decision has >>> been reached. >>> >>> If this was for porting, you should have pushed the original change to >>> jdk9 and not jdk10. This has already been widely communicated on the >>> jdk10 OpenJDK mailing list. >> >> I assume you are referring to: >> >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-March/000105.html >> >> But 9 is closed for RFEs so that is not a possible workflow here. >> >> David >> ----- >> >>> regards, >>> Sean. >>> >>> >>> On 15/03/2017 05:01, Shafi Ahmad wrote: >>>> Hi, >>>> >>>> May I get the approval of enhancement backport of 'JDK-8171194: >>>> Exception "Duplicate field name&signature in class file" should report >>>> the name and signature of the field' to jdk8u-dev. >>>> >>>> Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 >>>> >>>> "java.lang.ClassFormatError: Duplicate field name&signature in class >>>> file CampaignClient" >>>> >>>> From the above Exception message, there is no easy way of knowing >>>> what is triggering the problem. >>>> If the class in question is quite big so removing code by trial and >>>> error is very time consuming. >>>> >>>> With field name + signature, pinpointing the actual problematic code >>>> will be easy and time saving. >>>> >>>> I have tested it with the jprt and jtreg tests. >>>> >>>> Regards, >>>> Shafi >>>> >>> > From dalibor.topic at oracle.com Wed Mar 15 13:29:22 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 15 Mar 2017 14:29:22 +0100 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: References: <3eb77923-9e97-4846-abcb-773707938320@default> <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> <57c3b02e-9d90-26c3-b319-cbd8d38c9786@oracle.com> <2caeaa44-bcf0-853f-c473-c934e44f8300@oracle.com> Message-ID: On 15.03.2017 13:18, David Holmes wrote: > There may be numerous issues (not just RFE's) that miss the cutoff for 9 > but which are worth backporting to 8u. Are you saying there is no way > for these to get into 8u unless they go through the currently > non-existent 9u first? I think it would be helpful if the set of such issues could be illuminated more closely, for example through a JIRA query. Do you happen to have one at hand? 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 david.holmes at oracle.com Wed Mar 15 21:19:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Mar 2017 07:19:03 +1000 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: References: <3eb77923-9e97-4846-abcb-773707938320@default> <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> <57c3b02e-9d90-26c3-b319-cbd8d38c9786@oracle.com> <2caeaa44-bcf0-853f-c473-c934e44f8300@oracle.com> Message-ID: <06c2ddb7-bf6a-8f08-ca64-90d3af93d91d@oracle.com> On 15/03/2017 11:29 PM, dalibor topic wrote: > > > On 15.03.2017 13:18, David Holmes wrote: >> There may be numerous issues (not just RFE's) that miss the cutoff for 9 >> but which are worth backporting to 8u. Are you saying there is no way >> for these to get into 8u unless they go through the currently >> non-existent 9u first? > > I think it would be helpful if the set of such issues could be illuminated > more closely, for example through a JIRA query. Do you happen to have one > at hand? I was speaking generally. I don't know how you would recognize such an issue in JIRA unless labelled a particular way. The question is on what the process should be if we do have them. Thanks, David > cheers, > dalibor topic From dalibor.topic at oracle.com Thu Mar 16 09:55:51 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 16 Mar 2017 10:55:51 +0100 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: <06c2ddb7-bf6a-8f08-ca64-90d3af93d91d@oracle.com> References: <3eb77923-9e97-4846-abcb-773707938320@default> <3de254fe-2955-d714-3794-55c6c7a351f8@oracle.com> <57c3b02e-9d90-26c3-b319-cbd8d38c9786@oracle.com> <2caeaa44-bcf0-853f-c473-c934e44f8300@oracle.com> <06c2ddb7-bf6a-8f08-ca64-90d3af93d91d@oracle.com> Message-ID: On 15.03.2017 22:19, David Holmes wrote: > On 15/03/2017 11:29 PM, dalibor topic wrote: >> >> >> On 15.03.2017 13:18, David Holmes wrote: >>> There may be numerous issues (not just RFE's) that miss the cutoff for 9 >>> but which are worth backporting to 8u. Are you saying there is no way >>> for these to get into 8u unless they go through the currently >>> non-existent 9u first? >> >> I think it would be helpful if the set of such issues could be >> illuminated >> more closely, for example through a JIRA query. Do you happen to have one >> at hand? > > I was speaking generally. I don't know how you would recognize such an > issue in JIRA unless labelled a particular way. The question is on what > the process should be if we do have them. I think that would ultimately depend on their number and the length of the time period in question. If their number is high in the interim until 9u appears, then in my opinion it would be useful to go through adjusting and documenting the process accordingly. Same would hold if the interim is long. Unfortunately, it doesn't seem that we can know either quantity with sufficient precision at this time. So while I would agree that it would be useful to adjust the backporting process going forward in some way (and then potentially adjust it again once 9u is there), it's not clear to me yet how urgent that is. And if it's not urgent, it may be simpler to avoid doing those changes back and forth in the first place. Of course, any uncertainty is bad, too. That's why I was curious about any data at hand. 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 philip.race at oracle.com Thu Mar 16 19:49:59 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 16 Mar 2017 12:49:59 -0700 Subject: RFA: 8u backports 8039412 and 8067059 Message-ID: Hi, These two fixes which affect the Page Setup printing dialog on Linux are needed to make it easier to backport an additional critical fix for FX printing (coming afterwards), however these fixes are warranted on their own, and should have been backported already Both backported cleanly without changes (other than reshuffled paths as usual) Bug : https://bugs.openjdk.java.net/browse/JDK-8039412 Stack overflow on Linux using DialogTypeSelection.NATIVE 9-changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a24cd7ec0891 9-review : http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005822.html Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/eade2306738c 9-review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005807.html -phil. From ivan.gerasimov at oracle.com Thu Mar 16 21:16:58 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 16 Mar 2017 14:16:58 -0700 Subject: [8u-dev] Request for Approval to Backport: 8175251: Failed to load RSA private key from pkcs12 Message-ID: <206b4d15-0440-af99-faf7-38c985fa7823@oracle.com> Hello! Would you please approve backport of this fix to jdk8u-dev? The unshuffled patch applies cleanly. BUG: https://bugs.openjdk.java.net/browse/JDK-8175251 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50911d8e5cc5 Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2017-March/015695.html -- With kind regards, Ivan Gerasimov From philip.race at oracle.com Fri Mar 17 15:44:22 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 17 Mar 2017 08:44:22 -0700 Subject: RFA: 8u backports 8039412 and 8067059 In-Reply-To: References: Message-ID: <6e264979-746d-2292-a10e-2018d1b7d1fe@oracle.com> PING ! On 03/16/2017 12:49 PM, Phil Race wrote: > Hi, > > These two fixes which affect the Page Setup printing dialog on Linux > are needed > to make it easier to backport an additional critical fix for FX > printing (coming afterwards), > however these fixes are warranted on their own, and should have been > backported already > > Both backported cleanly without changes (other than reshuffled paths > as usual) > > Bug : https://bugs.openjdk.java.net/browse/JDK-8039412 Stack overflow > on Linux using DialogTypeSelection.NATIVE > 9-changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a24cd7ec0891 > 9-review : > http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005822.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 > 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/eade2306738c > 9-review: > http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005807.html > > -phil. > From naoto.sato at oracle.com Fri Mar 17 16:34:10 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 17 Mar 2017 09:34:10 -0700 Subject: RFA: 8u backports 8039412 and 8067059 In-Reply-To: <6e264979-746d-2292-a10e-2018d1b7d1fe@oracle.com> References: <6e264979-746d-2292-a10e-2018d1b7d1fe@oracle.com> Message-ID: <4028ddb4-d8cc-5e58-31cc-834dc4be0bd2@oracle.com> Approved for backport to 8u. Naoto On 3/17/17 8:44 AM, Phil Race wrote: > PING ! > > On 03/16/2017 12:49 PM, Phil Race wrote: >> Hi, >> >> These two fixes which affect the Page Setup printing dialog on Linux >> are needed >> to make it easier to backport an additional critical fix for FX >> printing (coming afterwards), >> however these fixes are warranted on their own, and should have been >> backported already >> >> Both backported cleanly without changes (other than reshuffled paths >> as usual) >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8039412 Stack overflow >> on Linux using DialogTypeSelection.NATIVE >> 9-changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a24cd7ec0891 >> 9-review : >> http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005822.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 >> 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/eade2306738c >> 9-review: >> http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005807.html >> >> -phil. >> > From ivan.gerasimov at oracle.com Fri Mar 17 17:25:01 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 17 Mar 2017 10:25:01 -0700 Subject: [8u-dev] Request for Approval to Backport: 8175251: Failed to load RSA private key from pkcs12 In-Reply-To: <206b4d15-0440-af99-faf7-38c985fa7823@oracle.com> References: <206b4d15-0440-af99-faf7-38c985fa7823@oracle.com> Message-ID: <0dd9903b-c17d-148b-3d52-decac360abcb@oracle.com> Hi Naoto! Would you please also approve my request? Thanks in advance, Ivan On 3/16/17 2:16 PM, Ivan Gerasimov wrote: > Hello! > > Would you please approve backport of this fix to jdk8u-dev? > The unshuffled patch applies cleanly. > > BUG: https://bugs.openjdk.java.net/browse/JDK-8175251 > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50911d8e5cc5 > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2017-March/015695.html > -- With kind regards, Ivan Gerasimov From naoto.sato at oracle.com Fri Mar 17 17:53:06 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 17 Mar 2017 10:53:06 -0700 Subject: [8u-dev] Request for Approval to Backport: 8175251: Failed to load RSA private key from pkcs12 In-Reply-To: <0dd9903b-c17d-148b-3d52-decac360abcb@oracle.com> References: <206b4d15-0440-af99-faf7-38c985fa7823@oracle.com> <0dd9903b-c17d-148b-3d52-decac360abcb@oracle.com> Message-ID: <08ae6c36-9577-13ef-eaca-3bfd3fc3f574@oracle.com> Approved for backport. Sorry for the late reply. Naoto On 3/17/17 10:25 AM, Ivan Gerasimov wrote: > Hi Naoto! > > Would you please also approve my request? > > Thanks in advance, > > Ivan > > > On 3/16/17 2:16 PM, Ivan Gerasimov wrote: >> Hello! >> >> Would you please approve backport of this fix to jdk8u-dev? >> The unshuffled patch applies cleanly. >> >> BUG: https://bugs.openjdk.java.net/browse/JDK-8175251 >> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50911d8e5cc5 >> Jdk9 review: >> http://mail.openjdk.java.net/pipermail/security-dev/2017-March/015695.html >> >> > From ivan.gerasimov at oracle.com Fri Mar 17 18:52:19 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 17 Mar 2017 11:52:19 -0700 Subject: [8u-dev] Request for Approval to Backport: 8175251: Failed to load RSA private key from pkcs12 In-Reply-To: <08ae6c36-9577-13ef-eaca-3bfd3fc3f574@oracle.com> References: <206b4d15-0440-af99-faf7-38c985fa7823@oracle.com> <0dd9903b-c17d-148b-3d52-decac360abcb@oracle.com> <08ae6c36-9577-13ef-eaca-3bfd3fc3f574@oracle.com> Message-ID: <5af5eac0-6c5a-b100-7095-29d57c862489@oracle.com> Thanks! On 3/17/17 10:53 AM, Naoto Sato wrote: > Approved for backport. Sorry for the late reply. > No problem. With kind regards, Ivan > Naoto > > On 3/17/17 10:25 AM, Ivan Gerasimov wrote: >> Hi Naoto! >> >> Would you please also approve my request? >> >> Thanks in advance, >> >> Ivan >> >> >> On 3/16/17 2:16 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> Would you please approve backport of this fix to jdk8u-dev? >>> The unshuffled patch applies cleanly. >>> >>> BUG: https://bugs.openjdk.java.net/browse/JDK-8175251 >>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50911d8e5cc5 >>> Jdk9 review: >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-March/015695.html >>> >>> >>> >> > -- With kind regards, Ivan Gerasimov From philip.race at oracle.com Fri Mar 17 23:34:27 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 17 Mar 2017 16:34:27 -0700 Subject: RFA 8u backport : 8176530: JDK support for JavaFX modal print dialogs Message-ID: <2f889116-de5e-8a46-311c-e9eb51f20d88@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8176530 9 review thread : http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008233.html 9 changeset :http://hg.openjdk.java.net/jdk9/client/jdk/rev/00c2a0d8e1cb -phil. From philip.race at oracle.com Fri Mar 17 23:38:48 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 17 Mar 2017 16:38:48 -0700 Subject: RFA 8u backport : 8176530: JDK support for JavaFX modal print dialogs In-Reply-To: <2f889116-de5e-8a46-311c-e9eb51f20d88@oracle.com> References: <2f889116-de5e-8a46-311c-e9eb51f20d88@oracle.com> Message-ID: PS .. I forgot to say the 8 change is identical to 9 .. and has been tested. -phil. On 03/17/2017 04:34 PM, Phil Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8176530 > > 9 review thread : > http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008233.html > > 9 changeset > :http://hg.openjdk.java.net/jdk9/client/jdk/rev/00c2a0d8e1cb > > > -phil. From naoto.sato at oracle.com Fri Mar 17 23:49:32 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 17 Mar 2017 16:49:32 -0700 Subject: RFA 8u backport : 8176530: JDK support for JavaFX modal print dialogs In-Reply-To: References: <2f889116-de5e-8a46-311c-e9eb51f20d88@oracle.com> Message-ID: <294d62d7-878f-1ad0-5f26-af63eb32fe56@oracle.com> Approved. I was going to ask about the changeset :-) Naoto On 3/17/17 4:38 PM, Phil Race wrote: > PS .. I forgot to say the 8 change is identical to 9 .. and has been > tested. > > -phil. > > On 03/17/2017 04:34 PM, Phil Race wrote: >> Bug : https://bugs.openjdk.java.net/browse/JDK-8176530 >> >> 9 review thread : >> http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008233.html >> >> 9 changeset >> :http://hg.openjdk.java.net/jdk9/client/jdk/rev/00c2a0d8e1cb >> >> >> -phil. > From prasanta.sadhukhan at oracle.com Mon Mar 20 06:08:07 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 20 Mar 2017 11:38:07 +0530 Subject: [8u-dev] Request for approval to backport JDK-8176287 : [macosx] The print test crashed with Nimbus L&F Message-ID: Hi All, Can I please get an approval to port the fix for JDK-8176287 to jdk8u-dev? The 9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8176287 webrev:http://cr.openjdk.java.net/~psadhukhan/8176287/8udev/webrev/ 9 Review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008234.html JDK9 changset: /http://hg.openjdk.java.net/jdk9/client/jdk/rev/e607ebd99004/ Regards Prasanta From rob.mckenna at oracle.com Mon Mar 20 11:58:54 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 20 Mar 2017 11:58:54 +0000 Subject: [8u-dev] Request for approval to backport JDK-8176287 : [macosx] The print test crashed with Nimbus L&F In-Reply-To: References: Message-ID: <20170320115854.GB4230@tecra> Approved -Rob On 20/03/17 11:38, Prasanta Sadhukhan wrote: > Hi All, > > Can I please get an approval to port the fix for JDK-8176287 to jdk8u-dev? > The 9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8176287 > webrev:http://cr.openjdk.java.net/~psadhukhan/8176287/8udev/webrev/ > 9 Review thread: > http://mail.openjdk.java.net/pipermail/2d-dev/2017-March/008234.html > JDK9 changset: /http://hg.openjdk.java.net/jdk9/client/jdk/rev/e607ebd99004/ > > Regards > Prasanta From anthony.scarpino at oracle.com Tue Mar 21 18:51:06 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 21 Mar 2017 11:51:06 -0700 Subject: RFA 8176536: Improved algorithm constraints checking Message-ID: <4b4da979-11b5-9a6e-350b-58353ccc3743@oracle.com> Hi, Please approve this backport for new algorithm constraints changes from jdk9 to jdk8. Bug https://bugs.openjdk.java.net/browse/JDK-8176536 Webrev http://cr.openjdk.java.net/~ascarpino/8176536/webrev.01/ Review http://mail.openjdk.java.net/pipermail/security-dev/2017-March/015696.html thanks Tony From david.buck at oracle.com Wed Mar 22 08:30:26 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 22 Mar 2017 17:30:26 +0900 Subject: RFA 8176536: Improved algorithm constraints checking In-Reply-To: <4b4da979-11b5-9a6e-350b-58353ccc3743@oracle.com> References: <4b4da979-11b5-9a6e-350b-58353ccc3743@oracle.com> Message-ID: Hi Tony! It doesn't look like there is a new testcase included in the webrev. Please add an appropriate noreg label to the bug report. [ noreg bug labels ] http://openjdk.java.net/guide/changePlanning.html#noreg Once the noreg label has been added, please consider this change approved for push to 8u-dev. Cheers, -Buck On 2017/03/22 3:51, Anthony Scarpino wrote: > Hi, > > Please approve this backport for new algorithm constraints changes from > jdk9 to jdk8. > > Bug > https://bugs.openjdk.java.net/browse/JDK-8176536 > > Webrev > http://cr.openjdk.java.net/~ascarpino/8176536/webrev.01/ > > Review > http://mail.openjdk.java.net/pipermail/security-dev/2017-March/015696.html > > thanks > > Tony From ivan.gerasimov at oracle.com Thu Mar 23 00:26:57 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 22 Mar 2017 17:26:57 -0700 Subject: [8u-dev] (XS) RFR 8169056: StringIndexOutOfBoundsException in Pattern.compile with CANON_EQ flag Message-ID: <5916899f-625e-bd48-3c89-2bc0321b21b6@oracle.com> Hello! This is an 8u-dev only fix. (In 9 the bug was fixed with a massive update [1]). The fix is essentially one-liner: just check that the index remains within the bounds after update. Regression test was updated to cover the case. Would you please help review at your convenience? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169056 WEBREV: http://cr.openjdk.java.net/~igerasim/8169056/00/webrev/ [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0c319c32334 -- With kind regards, Ivan Gerasimov From sean.coffey at oracle.com Thu Mar 23 08:55:33 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 23 Mar 2017 08:55:33 +0000 Subject: [8u-dev] (XS) RFR 8169056: StringIndexOutOfBoundsException in Pattern.compile with CANON_EQ flag In-Reply-To: <5916899f-625e-bd48-3c89-2bc0321b21b6@oracle.com> References: <5916899f-625e-bd48-3c89-2bc0321b21b6@oracle.com> Message-ID: <7f31e396-7503-819e-5271-a3a1c4da1a19@oracle.com> Looks good. regards, Sean. On 23/03/2017 00:26, Ivan Gerasimov wrote: > Hello! > > This is an 8u-dev only fix. > (In 9 the bug was fixed with a massive update [1]). > > The fix is essentially one-liner: just check that the index remains > within the bounds after update. > Regression test was updated to cover the case. > > Would you please help review at your convenience? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169056 > WEBREV: http://cr.openjdk.java.net/~igerasim/8169056/00/webrev/ > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0c319c32334 > From david.buck at oracle.com Thu Mar 23 08:59:50 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 23 Mar 2017 17:59:50 +0900 Subject: [8u-dev] (XS) RFR 8169056: StringIndexOutOfBoundsException in Pattern.compile with CANON_EQ flag In-Reply-To: <7f31e396-7503-819e-5271-a3a1c4da1a19@oracle.com> References: <5916899f-625e-bd48-3c89-2bc0321b21b6@oracle.com> <7f31e396-7503-819e-5271-a3a1c4da1a19@oracle.com> Message-ID: approved for push to 8u-dev Cheers, -Buck On 2017/03/23 17:55, Se?n Coffey wrote: > Looks good. > > regards, > Sean. > > > On 23/03/2017 00:26, Ivan Gerasimov wrote: >> Hello! >> >> This is an 8u-dev only fix. >> (In 9 the bug was fixed with a massive update [1]). >> >> The fix is essentially one-liner: just check that the index remains >> within the bounds after update. >> Regression test was updated to cover the case. >> >> Would you please help review at your convenience? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169056 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8169056/00/webrev/ >> >> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0c319c32334 >> > From ivan.gerasimov at oracle.com Thu Mar 23 18:50:18 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 23 Mar 2017 11:50:18 -0700 Subject: [8u-dev] (XS) RFR 8169056: StringIndexOutOfBoundsException in Pattern.compile with CANON_EQ flag In-Reply-To: References: <5916899f-625e-bd48-3c89-2bc0321b21b6@oracle.com> <7f31e396-7503-819e-5271-a3a1c4da1a19@oracle.com> Message-ID: <0db43723-f2c4-f882-3148-55cb5de21327@oracle.com> Thank you Se?n and David! On 3/23/17 1:59 AM, David Buck wrote: > approved for push to 8u-dev > > Cheers, > -Buck > > On 2017/03/23 17:55, Se?n Coffey wrote: >> Looks good. >> >> regards, >> Sean. >> >> >> On 23/03/2017 00:26, Ivan Gerasimov wrote: >>> Hello! >>> >>> This is an 8u-dev only fix. >>> (In 9 the bug was fixed with a massive update [1]). >>> >>> The fix is essentially one-liner: just check that the index remains >>> within the bounds after update. >>> Regression test was updated to cover the case. >>> >>> Would you please help review at your convenience? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8169056 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8169056/00/webrev/ >>> >>> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0c319c32334 >>> >> > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Fri Mar 24 01:36:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Mar 2017 11:36:23 +1000 Subject: Request for clarification about changes in Hotspot across 8, 9, and 10 In-Reply-To: <58D44B33.6030507@linux.vnet.ibm.com> References: <58D44B33.6030507@linux.vnet.ibm.com> Message-ID: Hi Gustavo, This is really a question for jdk8u-dev - cc'd. On 24/03/2017 8:24 AM, Gustavo Romero wrote: > Hi, > > I understand the current status of OpenJDK 8, 9, and 10 regarding changes in > Hotspot as: > > jdk8u: "We're open for fixes for 8u152 in the jdk8u-dev forest" [1] > jdk9 : We passed Rampdown Phase 2 (2017/03/16) so "only showstopper bugs can be fixed" [2] > jdk10: "As of today these forests are open for bug fixes and small enhancements" [3] > > Distros in general will repackage (update) OpenJDK following the CPU cycles [4]. > The next CPU release is on 18 April. If a change is already in jdk8u when > repackaging due to the CPU release occurs, then distros can - under request - > take the change into the new updated OpenJDK 8 package. > > But to get a change into jdk8u I need to get it first into 10, then request > backport to 9, and finally request a backport to 8u. However, jdk9 passed the > Rampdown Phase 2, so the change can't get into 9 and hence can't get into jdk8u > by now. So it looks like jdk9 current status is blocking the path to jdk8u. I raised this recently in relation to a RFE that was being backported to 8u and thus could not now go into 9: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-March/006486.html The "conclusion" was that this would be re-examined as the need arose. So if you have need ... > If the change (bug fix or enhancement) is PPC64-only (let's say a change in the > ppc.ad file), is it possible to get it into 8u before 18 April (next CPU release) > somehow? If not, what are the options? Is it necessary to wait 9 GA and so jdk9u? I don't know how you handle producing eg PPC64 builds to match a given CPU release. I would have presumed you would simply wait till the CPU changes are pushed to jdk8u-dev and then produce a build containing all CPU fixes along with any other fixes already accumulating in 8u-dev ? David ----- > Thank you very much. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/projects/jdk8u/ > [2] http://openjdk.java.net/projects/jdk9/ > [3] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html > [4] http://www.oracle.com/technetwork/es/topics/security/alerts-086861.html > From sean.coffey at oracle.com Sat Mar 25 10:20:03 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Sat, 25 Mar 2017 10:20:03 +0000 Subject: [8u communication] JDK 8 Updates porting process Message-ID: <598cb189-554a-46c3-de55-a196a62c3ded@oracle.com> With JDK 9 now entering the RDP2 phase, the bar for getting fixes into that release is high. A current requirement for JDK 8u fixes is ensuring that the changes are integrated into later JDK release families first [Rule 1, [1]]. If jdk8u ports are being blocked because of this, please let the JDK 8 Update Project maintainers know. While we wait for the JDK 9 Updates Project to form, I'd like to propose that we allow ports from JDK 10 into JDK 8 Updates where needed. We can open a '9-pool' record to track the JDK 9 port. I'll make the proposed change to the JDK 8 Updates rules next Friday if no objections are heard. [1] http://openjdk.java.net/projects/jdk8u/groundrules.html From sean.coffey at oracle.com Sat Mar 25 10:22:26 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Sat, 25 Mar 2017 10:22:26 +0000 Subject: Request for clarification about changes in Hotspot across 8, 9, and 10 In-Reply-To: References: <58D44B33.6030507@linux.vnet.ibm.com> Message-ID: Hi David, we're aware of this issue and are taking steps to address it. See http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-March/006512.html regards, Sean. On 24/03/2017 01:36, David Holmes wrote: > Hi Gustavo, > > This is really a question for jdk8u-dev - cc'd. > > On 24/03/2017 8:24 AM, Gustavo Romero wrote: >> Hi, >> >> I understand the current status of OpenJDK 8, 9, and 10 regarding >> changes in >> Hotspot as: >> >> jdk8u: "We're open for fixes for 8u152 in the jdk8u-dev >> forest" [1] >> jdk9 : We passed Rampdown Phase 2 (2017/03/16) so "only showstopper >> bugs can be fixed" [2] >> jdk10: "As of today these forests are open for bug fixes and small >> enhancements" [3] >> >> Distros in general will repackage (update) OpenJDK following the CPU >> cycles [4]. >> The next CPU release is on 18 April. If a change is already in jdk8u >> when >> repackaging due to the CPU release occurs, then distros can - under >> request - >> take the change into the new updated OpenJDK 8 package. >> >> But to get a change into jdk8u I need to get it first into 10, then >> request >> backport to 9, and finally request a backport to 8u. However, jdk9 >> passed the >> Rampdown Phase 2, so the change can't get into 9 and hence can't get >> into jdk8u >> by now. So it looks like jdk9 current status is blocking the path to >> jdk8u. > > I raised this recently in relation to a RFE that was being backported > to 8u and thus could not now go into 9: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-March/006486.html > > The "conclusion" was that this would be re-examined as the need arose. > So if you have need ... > >> If the change (bug fix or enhancement) is PPC64-only (let's say a >> change in the >> ppc.ad file), is it possible to get it into 8u before 18 April (next >> CPU release) >> somehow? If not, what are the options? Is it necessary to wait 9 GA >> and so jdk9u? > > I don't know how you handle producing eg PPC64 builds to match a given > CPU release. I would have presumed you would simply wait till the CPU > changes are pushed to jdk8u-dev and then produce a build containing > all CPU fixes along with any other fixes already accumulating in 8u-dev ? > > David > ----- > >> Thank you very much. >> >> Best regards, >> Gustavo >> >> [1] http://openjdk.java.net/projects/jdk8u/ >> [2] http://openjdk.java.net/projects/jdk9/ >> [3] >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html >> [4] >> http://www.oracle.com/technetwork/es/topics/security/alerts-086861.html >> From philip.race at oracle.com Sat Mar 25 15:16:08 2017 From: philip.race at oracle.com (Philip Race) Date: Sat, 25 Mar 2017 08:16:08 -0700 Subject: [8u communication] JDK 8 Updates porting process In-Reply-To: <598cb189-554a-46c3-de55-a196a62c3ded@oracle.com> References: <598cb189-554a-46c3-de55-a196a62c3ded@oracle.com> Message-ID: <58D689B8.6040103@oracle.com> Could we use 9-bp instead of 9-pool ? 9-bp strikes a bit more urgency without identifying a release. X-pool has traditionally been the Sargasso Sea of releases -phil. On 3/25/17, 3:20 AM, Se?n Coffey wrote: > With JDK 9 now entering the RDP2 phase, the bar for getting fixes into > that release is high. A current requirement for JDK 8u fixes is > ensuring that the changes are integrated into later JDK release > families first [Rule 1, [1]]. If jdk8u ports are being blocked because > of this, please let the JDK 8 Update Project maintainers know. > > While we wait for the JDK 9 Updates Project to form, I'd like to > propose that we allow ports from JDK 10 into JDK 8 Updates where > needed. We can open a '9-pool' record to track the JDK 9 port. I'll > make the proposed change to the JDK 8 Updates rules next Friday if no > objections are heard. > > [1] http://openjdk.java.net/projects/jdk8u/groundrules.html > From tobias.hartmann at oracle.com Mon Mar 27 09:17:09 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Mar 2017 11:17:09 +0200 Subject: [8u, 9] RFR(S): 8177095: Range check dependent CastII/ConvI2L is prematurely eliminated In-Reply-To: References: Message-ID: <1bb0de44-20f2-e658-165b-c229aa2b12b7@oracle.com> Hi, could I please get approval to backport this fix to JDK 8u? The fix has been reviewed and was pushed to JDK 9: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025891.html I'll wait for some nightly runs to complete before pushing this to JDK 8u. Thanks, Tobias On 22.03.2017 13:31, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8177095 > > JDK 9: > http://cr.openjdk.java.net/~thartmann/8177095/webrev.00/ > JDK 8u: > http://cr.openjdk.java.net/~thartmann/8177095_8u/webrev.00/ > > A CastII (or a ConvI2L before the fix for JDK-6675699 [1]) with a narrow type that represents the index of an array access is eliminated because its type range does not intersect with the input range. This happens because the node is pushed upwards through an AddI. However, the control path to the array access is not eliminated leaving the graph in a corrupted state. We either crash during loop optimizations because we use a value from a non-dominating region or we crash in the register allocator because a Phi has a TOP input (and therefore an undefined live range). > > For more details see changes in TestLoopPeeling.java: > Load1 and the corresponding range check are moved out of the loop and both are used after the old loop and the peeled iteration exit. For the peeled iteration, storeIndex is always Integer.MIN_VALUE and for the old loop it is 0. Hence, the merging phi has type int:<=0. Load1 reads the array at index ConvI2L(CastII(AddI(storeIndex, -1))) where the CastII is range check dependent and has type int:>=0. The CastII gets pushed through the AddI and its type is changed to int:>=1 which does not overlap with the input type of storeIndex (int:<=0). The CastII is replaced by TOP causing a cascade of other eliminations. Since the control path through the range check CmpU(AddI(storeIndex, -1)) is not eliminated, the graph is in a corrupted state. We fail once we merge with the result of Load2 because we get data from a non-dominating region. > > I attempted to fix this issue with JDK-6675699 but missed these cases. The problem is similar to JDK-8154831 [2] and affects the latest JDK 6, 7, 8 and 9. > > I disabled narrowing of range check dependent CastIIs (either through the CastII(AddI) optimization or through CastIINode::Ideal). > > Tested with customer provided reproducer, regression test and RBT (running). > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-6675699 > [2] https://bugs.openjdk.java.net/browse/JDK-8154831 > From rob.mckenna at oracle.com Mon Mar 27 15:43:57 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 27 Mar 2017 16:43:57 +0100 Subject: [8u, 9] RFR(S): 8177095: Range check dependent CastII/ConvI2L is prematurely eliminated In-Reply-To: <1bb0de44-20f2-e658-165b-c229aa2b12b7@oracle.com> References: <1bb0de44-20f2-e658-165b-c229aa2b12b7@oracle.com> Message-ID: <20170327154357.GA3492@tecra> Approved pending successful nightly results. Please follow the approval request template for future requests: http://openjdk.java.net/projects/jdk8u/approval-template.html -Rob On 27/03/17 11:17, Tobias Hartmann wrote: > Hi, > > could I please get approval to backport this fix to JDK 8u? > > The fix has been reviewed and was pushed to JDK 9: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025891.html > > I'll wait for some nightly runs to complete before pushing this to JDK 8u. > > Thanks, > Tobias > > On 22.03.2017 13:31, Tobias Hartmann wrote: > > Hi, > > > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8177095 > > > > JDK 9: > > http://cr.openjdk.java.net/~thartmann/8177095/webrev.00/ > > JDK 8u: > > http://cr.openjdk.java.net/~thartmann/8177095_8u/webrev.00/ > > > > A CastII (or a ConvI2L before the fix for JDK-6675699 [1]) with a narrow type that represents the index of an array access is eliminated because its type range does not intersect with the input range. This happens because the node is pushed upwards through an AddI. However, the control path to the array access is not eliminated leaving the graph in a corrupted state. We either crash during loop optimizations because we use a value from a non-dominating region or we crash in the register allocator because a Phi has a TOP input (and therefore an undefined live range). > > > > For more details see changes in TestLoopPeeling.java: > > Load1 and the corresponding range check are moved out of the loop and both are used after the old loop and the peeled iteration exit. For the peeled iteration, storeIndex is always Integer.MIN_VALUE and for the old loop it is 0. Hence, the merging phi has type int:<=0. Load1 reads the array at index ConvI2L(CastII(AddI(storeIndex, -1))) where the CastII is range check dependent and has type int:>=0. The CastII gets pushed through the AddI and its type is changed to int:>=1 which does not overlap with the input type of storeIndex (int:<=0). The CastII is replaced by TOP causing a cascade of other eliminations. Since the control path through the range check CmpU(AddI(storeIndex, -1)) is not eliminated, the graph is in a corrupted state. We fail once we merge with the result of Load2 because we get data from a non-dominating region. > > > > I attempted to fix this issue with JDK-6675699 but missed these cases. The problem is similar to JDK-8154831 [2] and affects the latest JDK 6, 7, 8 and 9. > > > > I disabled narrowing of range check dependent CastIIs (either through the CastII(AddI) optimization or through CastIINode::Ideal). > > > > Tested with customer provided reproducer, regression test and RBT (running). > > > > Thanks, > > Tobias > > > > [1] https://bugs.openjdk.java.net/browse/JDK-6675699 > > [2] https://bugs.openjdk.java.net/browse/JDK-8154831 > > From brent.christian at oracle.com Mon Mar 27 23:43:10 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 27 Mar 2017 16:43:10 -0700 Subject: Request for approval: 7131356, 8160370, 8161039, 8174779, 8174736 Message-ID: <68b6561c-440f-ea3e-0a2e-d5b9a9c463b1@oracle.com> Hi, I am seeking approval to backport JDK 9 fixes for these 5 related bugs: 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b88aa53f3dc6 8160370 : System.getProperty("os.version") returns "Unknown" on Mac JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b72c37787a5e 8161039 : System.getProperty("os.version") returns incorrect version number on Mac JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/165e4d9c7afa 8174779 : Locale issues with Mac 10.12 JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d014ae449563 8174736 : [JCP] [Mac]Cannot launch JCP on Mac os with language set to "Chinese, Simplified" while region is not China JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1c14d0ba40e0 To summarize, 7131356 replaced use of Apple's JavaRuntimeSupport framework with CoreFoundation calls to setup the locale and os name/version. The fix has had some time to bake in JDK 9 (since June), during which time four related bugs were found and fixed, mostly around specific MacOS versions (e.g. 8160370 - MacOS 10.8, 8161039 - MacOS 10.11.0, 8174779 - MacOS 10.12). Here's the jdk8u-dev webrev: http://cr.openjdk.java.net/~bchristi/7131356/8u/webrev.00/ The JDK 9 patches apply to 8u-dev, with the following (trivial, IMO) caveats: 1. unshuffle_list.txt needs to be updated for java_props_macosx.[ch] (filed 8177556). 2. 'hg import' didn't like that the copyright year for the JDK 9 changeset was 2015, but in 8u is 2013 3. The fix [1] for unrelated bug 8136556 [2] added an #ifdef [3] in the getJRSFramework() function. This backport removes that function altogether, but 'hg import' didn't like that the #ifdef isn't there to remove. Original review threads, for reference: 7131356[4], 8160370[5], 8161039[6], 8174779[7], 8174736[8]. Thanks, -Brent 1. http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/55573c377d64 2. https://bugs.openjdk.java.net/browse/JDK-8136556 3. http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/55573c377d64/src/java.base/macosx/native/libjava/java_props_macosx.c#l41 4. http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041771.html 5. http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/042096.html 6. http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042499.html 7. http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046406.html 8. http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046610.html From tobias.hartmann at oracle.com Tue Mar 28 06:02:10 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Mar 2017 08:02:10 +0200 Subject: [8u, 9] RFR(S): 8177095: Range check dependent CastII/ConvI2L is prematurely eliminated In-Reply-To: <20170327154357.GA3492@tecra> References: <1bb0de44-20f2-e658-165b-c229aa2b12b7@oracle.com> <20170327154357.GA3492@tecra> Message-ID: <43441e53-c285-c370-5de1-84992b66dd23@oracle.com> On 27.03.2017 17:43, Rob McKenna wrote: > Approved pending successful nightly results. > > Please follow the approval request template for future requests: > > http://openjdk.java.net/projects/jdk8u/approval-template.html Thanks, Rob. I'll do so! Best regards, Tobias > On 27/03/17 11:17, Tobias Hartmann wrote: >> Hi, >> >> could I please get approval to backport this fix to JDK 8u? >> >> The fix has been reviewed and was pushed to JDK 9: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025891.html >> >> I'll wait for some nightly runs to complete before pushing this to JDK 8u. >> >> Thanks, >> Tobias >> >> On 22.03.2017 13:31, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8177095 >>> >>> JDK 9: >>> http://cr.openjdk.java.net/~thartmann/8177095/webrev.00/ >>> JDK 8u: >>> http://cr.openjdk.java.net/~thartmann/8177095_8u/webrev.00/ >>> >>> A CastII (or a ConvI2L before the fix for JDK-6675699 [1]) with a narrow type that represents the index of an array access is eliminated because its type range does not intersect with the input range. This happens because the node is pushed upwards through an AddI. However, the control path to the array access is not eliminated leaving the graph in a corrupted state. We either crash during loop optimizations because we use a value from a non-dominating region or we crash in the register allocator because a Phi has a TOP input (and therefore an undefined live range). >>> >>> For more details see changes in TestLoopPeeling.java: >>> Load1 and the corresponding range check are moved out of the loop and both are used after the old loop and the peeled iteration exit. For the peeled iteration, storeIndex is always Integer.MIN_VALUE and for the old loop it is 0. Hence, the merging phi has type int:<=0. Load1 reads the array at index ConvI2L(CastII(AddI(storeIndex, -1))) where the CastII is range check dependent and has type int:>=0. The CastII gets pushed through the AddI and its type is changed to int:>=1 which does not overlap with the input type of storeIndex (int:<=0). The CastII is replaced by TOP causing a cascade of other eliminations. Since the control path through the range check CmpU(AddI(storeIndex, -1)) is not eliminated, the graph is in a corrupted state. We fail once we merge with the result of Load2 because we get data from a non-dominating region. >>> >>> I attempted to fix this issue with JDK-6675699 but missed these cases. The problem is similar to JDK-8154831 [2] and affects the latest JDK 6, 7, 8 and 9. >>> >>> I disabled narrowing of range check dependent CastIIs (either through the CastII(AddI) optimization or through CastIINode::Ideal). >>> >>> Tested with customer provided reproducer, regression test and RBT (running). >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-6675699 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8154831 >>> From rob.mckenna at oracle.com Tue Mar 28 16:35:10 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 28 Mar 2017 17:35:10 +0100 Subject: [8u-dev] Request for approval - 8136570: Stop changing user environment variables related to /usr/dt Message-ID: <20170328163510.GA4541@vimes> Hi folks, Looking for approval for this clean backport as suggested by Martin & Tiago a while back: https://bugs.openjdk.java.net/browse/JDK-8136570 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/acf424f856ce http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035212.html -Rob From martinrb at google.com Tue Mar 28 16:40:21 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 Mar 2017 09:40:21 -0700 Subject: [8u-dev] Request for approval - 8136570: Stop changing user environment variables related to /usr/dt In-Reply-To: <20170328163510.GA4541@vimes> References: <20170328163510.GA4541@vimes> Message-ID: Looks good to me! On Tue, Mar 28, 2017 at 9:35 AM, Rob McKenna wrote: > Hi folks, > > Looking for approval for this clean backport as suggested by Martin & > Tiago a while back: > > https://bugs.openjdk.java.net/browse/JDK-8136570 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/acf424f856ce > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015- > September/035212.html > > -Rob > > From sean.coffey at oracle.com Tue Mar 28 16:50:59 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 28 Mar 2017 17:50:59 +0100 Subject: [8u-dev] Request for approval - 8136570, 4953367: Stop changing user environment variables related to /usr/dt In-Reply-To: References: <20170328163510.GA4541@vimes> Message-ID: Looks like : 4953367: MAWT: Java should be more careful manipulating NLSPATH, XFILESEARCHPATH env variables also gets ported. Updating subject bug IDs. Approved. Regards, Sean. On 28/03/2017 17:40, Martin Buchholz wrote: > Looks good to me! > > On Tue, Mar 28, 2017 at 9:35 AM, Rob McKenna wrote: > >> Hi folks, >> >> Looking for approval for this clean backport as suggested by Martin & >> Tiago a while back: >> >> https://bugs.openjdk.java.net/browse/JDK-8136570 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/acf424f856ce >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015- >> September/035212.html >> >> -Rob >> >> From sean.coffey at oracle.com Tue Mar 28 17:14:05 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 28 Mar 2017 18:14:05 +0100 Subject: [8u] Request for enhancement backport approval for CR 8043913: remove legacy code in SPARC's VM_Version::platform_features In-Reply-To: <74822698-123f-b765-54b7-17fb6afef844@oracle.com> References: <74822698-123f-b765-54b7-17fb6afef844@oracle.com> Message-ID: Thanks for logging this request Kevin. This is approved for porting to jdk8u-dev. regards, Sean. On 15/03/2017 10:29, Kevin Walls wrote: > Hi, > > 8043913: remove legacy code in SPARC's VM_Version::platform_features > https://bugs.openjdk.java.net/browse/JDK-8043913 > > This backport is required to support other changes in the same area in > 8u. In 9, this change happens before other changes in the same file, > so having this change will make other work simpler and have the > histories more similar in 8u and later releases. > > Thanks > Kevin > From naoto.sato at oracle.com Tue Mar 28 17:50:27 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 28 Mar 2017 10:50:27 -0700 Subject: Request for approval: 7131356, 8160370, 8161039, 8174779, 8174736 In-Reply-To: <68b6561c-440f-ea3e-0a2e-d5b9a9c463b1@oracle.com> References: <68b6561c-440f-ea3e-0a2e-d5b9a9c463b1@oracle.com> Message-ID: <82c28868-e244-7b51-f4f8-034aa09c687a@oracle.com> Hi Brent, I reviewed the extra changes for 8u and looks fine to me. Please consider this approved for 8u-dev backport. Naoto On 3/27/17 4:43 PM, Brent Christian wrote: > Hi, > > I am seeking approval to backport JDK 9 fixes for these 5 related bugs: > > 7131356 : (props) "No Java runtime present, requesting install" when > creating VM from JNI [macosx] > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b88aa53f3dc6 > > 8160370 : System.getProperty("os.version") returns "Unknown" on Mac > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b72c37787a5e > > 8161039 : System.getProperty("os.version") returns incorrect version > number on Mac > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/165e4d9c7afa > > 8174779 : Locale issues with Mac 10.12 > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d014ae449563 > > 8174736 : [JCP] [Mac]Cannot launch JCP on Mac os with language set to > "Chinese, Simplified" while region is not China > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1c14d0ba40e0 > > > To summarize, 7131356 replaced use of Apple's JavaRuntimeSupport > framework with CoreFoundation calls to setup the locale and os > name/version. The fix has had some time to bake in JDK 9 (since June), > during which time four related bugs were found and fixed, mostly around > specific MacOS versions (e.g. 8160370 - MacOS 10.8, 8161039 - MacOS > 10.11.0, 8174779 - MacOS 10.12). > > > Here's the jdk8u-dev webrev: > http://cr.openjdk.java.net/~bchristi/7131356/8u/webrev.00/ > > The JDK 9 patches apply to 8u-dev, with the following (trivial, IMO) > caveats: > > 1. unshuffle_list.txt needs to be updated for java_props_macosx.[ch] > (filed 8177556). > > 2. 'hg import' didn't like that the copyright year for the JDK 9 > changeset was 2015, but in 8u is 2013 > > 3. The fix [1] for unrelated bug 8136556 [2] added an #ifdef [3] in the > getJRSFramework() function. This backport removes that function > altogether, but 'hg import' didn't like that the #ifdef isn't there to > remove. > > Original review threads, for reference: 7131356[4], 8160370[5], > 8161039[6], 8174779[7], 8174736[8]. > > Thanks, > -Brent > > 1. http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/55573c377d64 > 2. https://bugs.openjdk.java.net/browse/JDK-8136556 > 3. > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/55573c377d64/src/java.base/macosx/native/libjava/java_props_macosx.c#l41 > > 4. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041771.html > 5. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/042096.html > 6. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042499.html > 7. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046406.html > > 8. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046610.html From naoto.sato at oracle.com Tue Mar 28 21:59:57 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 28 Mar 2017 14:59:57 -0700 Subject: [8u-dev] Request for approval for Japanese supplemental era related fixes - 8054214, 8173423, 8177678 Message-ID: <0c1a470e-452d-aa9c-23c6-389757548661@oracle.com> Hello, Please approve the backport of the fixes for the supplemental Japanese era related bugs. The issue-links/changesets/discussions for JDK9 are as follows: https://bugs.openjdk.java.net/browse/JDK-8054214 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/21b45d72c6c0 http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045310.html https://bugs.openjdk.java.net/browse/JDK-8173423 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e0ab92b7360f http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/046150.html https://bugs.openjdk.java.net/browse/JDK-8177678 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e685e3197f62 http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046956.html The proposed webrev is located at: http://cr.openjdk.java.net/~naoto/8054214.8173423.8177678/webrev.00/ The changes apply cleanly, except the copyright year and test cases that are specific to JDK9, which are removed in this request. Naoto From gromero at linux.vnet.ibm.com Wed Mar 29 02:05:05 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 28 Mar 2017 23:05:05 -0300 Subject: Request for clarification about changes in Hotspot across 8, 9, and 10 In-Reply-To: References: <58D44B33.6030507@linux.vnet.ibm.com> Message-ID: <58DB1651.1050803@linux.vnet.ibm.com> Hi David, Sean Sorry for the delay on replaying... On 25-03-2017 07:22, Se?n Coffey wrote: > Hi David, > > we're aware of this issue and are taking steps to address it. See > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-March/006512.html > > regards, > Sean. Sean, thanks for pointing out your proposal, it's much appreciated. > > On 24/03/2017 01:36, David Holmes wrote: >> Hi Gustavo, >> >> This is really a question for jdk8u-dev - cc'd. >> >> On 24/03/2017 8:24 AM, Gustavo Romero wrote: >>> Hi, >>> >>> I understand the current status of OpenJDK 8, 9, and 10 regarding changes in >>> Hotspot as: >>> >>> jdk8u: "We're open for fixes for 8u152 in the jdk8u-dev forest" [1] >>> jdk9 : We passed Rampdown Phase 2 (2017/03/16) so "only showstopper bugs can be fixed" [2] >>> jdk10: "As of today these forests are open for bug fixes and small enhancements" [3] >>> >>> Distros in general will repackage (update) OpenJDK following the CPU cycles [4]. >>> The next CPU release is on 18 April. If a change is already in jdk8u when >>> repackaging due to the CPU release occurs, then distros can - under request - >>> take the change into the new updated OpenJDK 8 package. >>> >>> But to get a change into jdk8u I need to get it first into 10, then request >>> backport to 9, and finally request a backport to 8u. However, jdk9 passed the >>> Rampdown Phase 2, so the change can't get into 9 and hence can't get into jdk8u >>> by now. So it looks like jdk9 current status is blocking the path to jdk8u. >> >> I raised this recently in relation to a RFE that was being backported to 8u and thus could not now go into 9: >> >> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-March/006486.html >> >> The "conclusion" was that this would be re-examined as the need arose. So if you have need ... >> >>> If the change (bug fix or enhancement) is PPC64-only (let's say a change in the >>> ppc.ad file), is it possible to get it into 8u before 18 April (next CPU release) >>> somehow? If not, what are the options? Is it necessary to wait 9 GA and so jdk9u? >> >> I don't know how you handle producing eg PPC64 builds to match a given CPU release. I would have presumed you would simply wait till the CPU changes are pushed to jdk8u-dev and then produce a build >> containing all CPU fixes along with any other fixes already accumulating in 8u-dev ? Yes, except that I believe distros will just add the fixes accumulated in 8u-dev under a request/justification (in addition to all security fixes). Thanks! Regards, Gustavo >> David >> ----- >> >>> Thank you very much. >>> >>> Best regards, >>> Gustavo >>> >>> [1] http://openjdk.java.net/projects/jdk8u/ >>> [2] http://openjdk.java.net/projects/jdk9/ >>> [3] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-January/000041.html >>> [4] http://www.oracle.com/technetwork/es/topics/security/alerts-086861.html >>> > From sean.coffey at oracle.com Wed Mar 29 10:32:42 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 29 Mar 2017 11:32:42 +0100 Subject: [8u-dev] Request for approval for Japanese supplemental era related fixes - 8054214, 8173423, 8177678 In-Reply-To: <0c1a470e-452d-aa9c-23c6-389757548661@oracle.com> References: <0c1a470e-452d-aa9c-23c6-389757548661@oracle.com> Message-ID: <845d3beb-554b-3de3-de54-94a13afd6a6b@oracle.com> Naoto, A CCC was logged for 8054214 in JDK 9. I'd be even more cautious in JDK 8u porting. Please log a CCC for JDK 8u port request. If you're dropping the jdk9 testcase for 8u porting, can you please consider updating an existing one to test this new functionality ? It should be possible and it'll help verify the backport for quality team. Regards, Sean. On 28/03/17 22:59, Naoto Sato wrote: > Hello, > > Please approve the backport of the fixes for the supplemental Japanese > era related bugs. The issue-links/changesets/discussions for JDK9 are > as follows: > > https://bugs.openjdk.java.net/browse/JDK-8054214 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/21b45d72c6c0 > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045310.html > > > https://bugs.openjdk.java.net/browse/JDK-8173423 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e0ab92b7360f > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/046150.html > > > https://bugs.openjdk.java.net/browse/JDK-8177678 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e685e3197f62 > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046956.html > > > The proposed webrev is located at: > > http://cr.openjdk.java.net/~naoto/8054214.8173423.8177678/webrev.00/ > > The changes apply cleanly, except the copyright year and test cases > that are specific to JDK9, which are removed in this request. > > Naoto > From hannes.wallnoefer at oracle.com Wed Mar 29 15:34:50 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 29 Mar 2017 17:34:50 +0200 Subject: [8u-dev] Request for approval: 8176511: JSObject property access is broken for numeric keys outside the int range Message-ID: <5684F961-BA5F-4E12-A845-06E1B8793BCD@oracle.com> Please approve back port of 8176511 to 8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8176511 Webrev: http://cr.openjdk.java.net/~hannesw/8176511/webrev/ Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-March/006893.html Changes apply cleanly to jdk8u-dev after path reshuffling. Thanks, Hannes From rob.mckenna at oracle.com Wed Mar 29 15:53:44 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 29 Mar 2017 16:53:44 +0100 Subject: [8u-dev] Request for approval: 8176511: JSObject property access is broken for numeric keys outside the int range In-Reply-To: <5684F961-BA5F-4E12-A845-06E1B8793BCD@oracle.com> References: <5684F961-BA5F-4E12-A845-06E1B8793BCD@oracle.com> Message-ID: <20170329155344.GA3587@vimes> Approved -Rob On 29/03/17 05:34, Hannes Walln?fer wrote: > Please approve back port of 8176511 to 8u-dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176511 > Webrev: http://cr.openjdk.java.net/~hannesw/8176511/webrev/ > Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-March/006893.html > > Changes apply cleanly to jdk8u-dev after path reshuffling. > > Thanks, > Hannes From naoto.sato at oracle.com Wed Mar 29 16:18:58 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 29 Mar 2017 09:18:58 -0700 Subject: [8u-dev] Request for approval for Japanese supplemental era related fixes - 8054214, 8173423, 8177678 In-Reply-To: <845d3beb-554b-3de3-de54-94a13afd6a6b@oracle.com> References: <0c1a470e-452d-aa9c-23c6-389757548661@oracle.com> <845d3beb-554b-3de3-de54-94a13afd6a6b@oracle.com> Message-ID: Thanks, Sean. On 3/29/17 3:32 AM, Se?n Coffey wrote: > Naoto, > > A CCC was logged for 8054214 in JDK 9. I'd be even more cautious in JDK > 8u porting. Please log a CCC for JDK 8u port request. Will file a CCC for the backport. > > If you're dropping the jdk9 testcase for 8u porting, can you please > consider updating an existing one to test this new functionality ? It > should be possible and it'll help verify the backport for quality team. It's not a new functionality per se, but in JDK9 the property is provided with the command line option, while in JDK8 it was a static calendar.properties file. Filed the following issue to create a JDK8 specific test case. https://bugs.openjdk.java.net/browse/JDK-8177776 Naoto > > Regards, > Sean. > > On 28/03/17 22:59, Naoto Sato wrote: >> Hello, >> >> Please approve the backport of the fixes for the supplemental Japanese >> era related bugs. The issue-links/changesets/discussions for JDK9 are >> as follows: >> >> https://bugs.openjdk.java.net/browse/JDK-8054214 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/21b45d72c6c0 >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045310.html >> >> >> https://bugs.openjdk.java.net/browse/JDK-8173423 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e0ab92b7360f >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/046150.html >> >> >> https://bugs.openjdk.java.net/browse/JDK-8177678 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e685e3197f62 >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046956.html >> >> >> The proposed webrev is located at: >> >> http://cr.openjdk.java.net/~naoto/8054214.8173423.8177678/webrev.00/ >> >> The changes apply cleanly, except the copyright year and test cases >> that are specific to JDK9, which are removed in this request. >> >> Naoto >> > From dmitry.markov at oracle.com Wed Mar 29 19:13:32 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 29 Mar 2017 22:13:32 +0300 Subject: [8u-dev] Request for approval 8176490: [macosx] Sometimes NSWindow.isZoomed hangs Message-ID: <0C7F23DC-0A98-484F-92D1-F59ADE27ADDB@oracle.com> Hello, Can I get an approval to port the fix for 8176490 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8176490 Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-March/012708.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/cdb6fd420176 Thanks, Dmitry From naoto.sato at oracle.com Wed Mar 29 20:04:04 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 29 Mar 2017 13:04:04 -0700 Subject: [8u-dev] Request for approval 8176490: [macosx] Sometimes NSWindow.isZoomed hangs In-Reply-To: <0C7F23DC-0A98-484F-92D1-F59ADE27ADDB@oracle.com> References: <0C7F23DC-0A98-484F-92D1-F59ADE27ADDB@oracle.com> Message-ID: Approved. Naoto On 3/29/17 12:13 PM, Dmitry Markov wrote: > Hello, > > Can I get an approval to port the fix for 8176490 to jdk8u-dev, please? The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8176490 > Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-March/012708.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/cdb6fd420176 > > Thanks, > Dmitry > From shafi.s.ahmad at oracle.com Thu Mar 30 06:46:06 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 29 Mar 2017 23:46:06 -0700 (PDT) Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field Message-ID: Hi, May I get the approval of enhancement backport of 'JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field' to jdk8u-dev. Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 "java.lang.ClassFormatError: Duplicate field name&signature in class file CampaignClient" >From the above Exception message, it is difficult of knowing what is triggering the problem. If the class in question is quite big so removing code by trial and error is very time consuming. With field name + signature, pinpointing the actual problematic code will be easy and time saving. I have tested it with the jprt and jtreg tests. Please note the original bug was raised against jdk8u. Regards, Shafi From kevin.walls at oracle.com Thu Mar 30 08:26:55 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 30 Mar 2017 09:26:55 +0100 Subject: [8u-dev] Request for approval for CR: 8049717: expose L1_data_cache_line_size for diagnostic/sanity checks Message-ID: Hi, I'd like to get approval to backport 8049717 into 8u from 9. JBS: https://bugs.openjdk.java.net/browse/JDK-8049717 9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/553f14d70527 8u-dev webrev: http://cr.openjdk.java.net/~kevinw/8049717.8u/webrev.01/index.html The change almost imports cleanly, but required "obvious" manual changes in a couple of places, e.g. vm_version_sparc.cpp was not exactly the same in 8u at the places changed, due to other changes. Similarly the change in jni.cpp needed editing as the list of tests called in execute_internal_vm_tests() is slightly different in 8u. This change is needed to make further changes in the same area apply, e.g. to get 8134119 to "fit" into 8u. Thanks Kevin From rob.mckenna at oracle.com Thu Mar 30 13:09:48 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 30 Mar 2017 14:09:48 +0100 Subject: [8u-dev] Request for approval for CR: 8049717: expose L1_data_cache_line_size for diagnostic/sanity checks In-Reply-To: References: Message-ID: <20170330130948.GA3771@vimes> Approved -Rob On 30/03/17 09:26, Kevin Walls wrote: > Hi, > > I'd like to get approval to backport 8049717 into 8u from 9. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8049717 > > 9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/553f14d70527 > > 8u-dev webrev: > http://cr.openjdk.java.net/~kevinw/8049717.8u/webrev.01/index.html > > The change almost imports cleanly, but required "obvious" manual changes in > a couple of places, e.g. vm_version_sparc.cpp was not exactly the same in 8u > at the places changed, due to other changes. Similarly the change in > jni.cpp needed editing as the list of tests called in > execute_internal_vm_tests() is slightly different in 8u. > > This change is needed to make further changes in the same area apply, e.g. > to get 8134119 to "fit" into 8u. > > Thanks > Kevin > From kevin.walls at oracle.com Thu Mar 30 13:10:38 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 30 Mar 2017 14:10:38 +0100 Subject: [8u-dev] Request for approval for CR: 8049717: expose L1_data_cache_line_size for diagnostic/sanity checks In-Reply-To: <20170330130948.GA3771@vimes> References: <20170330130948.GA3771@vimes> Message-ID: <9d7e7432-449d-8f41-2b20-29566efa0299@oracle.com> Thanks Rob, next one coming soon! On 30/03/2017 14:09, Rob McKenna wrote: > Approved > > -Rob > > On 30/03/17 09:26, Kevin Walls wrote: >> Hi, >> >> I'd like to get approval to backport 8049717 into 8u from 9. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8049717 >> >> 9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/553f14d70527 >> >> 8u-dev webrev: >> http://cr.openjdk.java.net/~kevinw/8049717.8u/webrev.01/index.html >> >> The change almost imports cleanly, but required "obvious" manual changes in >> a couple of places, e.g. vm_version_sparc.cpp was not exactly the same in 8u >> at the places changed, due to other changes. Similarly the change in >> jni.cpp needed editing as the list of tests called in >> execute_internal_vm_tests() is slightly different in 8u. >> >> This change is needed to make further changes in the same area apply, e.g. >> to get 8134119 to "fit" into 8u. >> >> Thanks >> Kevin >> From rob.mckenna at oracle.com Thu Mar 30 14:17:09 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 30 Mar 2017 15:17:09 +0100 Subject: [8u] Request for enhancement backport approval for CR JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field In-Reply-To: References: Message-ID: <20170330141709.GB3771@vimes> Hi Shafi, This request has been rejected by the PM as: "There isn't any justification as to why this shouldn't simply be done on the next major release but should also be backported to already released versions" It may help to update the justification in this thread focusing on the servicability aspects and the impact on older releases. -Rob On 29/03/17 11:46, Shafi Ahmad wrote: > Hi, > > May I get the approval of enhancement backport of 'JDK-8171194: Exception "Duplicate field name&signature in class file" should report the name and signature of the field' to jdk8u-dev. > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8171194 > > "java.lang.ClassFormatError: Duplicate field name&signature in class file CampaignClient" > > From the above Exception message, it is difficult of knowing what is triggering the problem. > If the class in question is quite big so removing code by trial and error is very time consuming. > > With field name + signature, pinpointing the actual problematic code will be easy and time saving. > > I have tested it with the jprt and jtreg tests. > > Please note the original bug was raised against jdk8u. > > Regards, > Shafi > From kevin.walls at oracle.com Fri Mar 31 09:46:43 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 31 Mar 2017 10:46:43 +0100 Subject: [8u-dev] Request for approval: 8177817 (new small change for 8u), and 8134119 (backport) Message-ID: <238942fb-e6c0-7738-3e10-0034bf31700a@oracle.com> Hi, This is an approval request for a backport to 8u of: 8134119: Use new API to get cache line sizes https://bugs.openjdk.java.net/browse/JDK-8134119 9 change: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/raw-rev/be30670bbd35 This will backport almost cleanly: must change os:strdup_check_oom() to just os::strdup(). However, I first need to push the following new CR to 8u, so this is also a request for approval for: 8177817: Remove assertions in 8u that were removed by 8056124 in 9. https://bugs.openjdk.java.net/browse/JDK-8177817 9 change for 8056124: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/63934ec778a2 This is a new change to do some code removal exactly as 8056124 did in 9, also explained in hotspot-compiler-dev: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025923.html I've been over this plan with the original author. The new CR 8177817 lets other changes backport almost unchanged from their 9 changesets. In the bug comment for 8177817 I've put the diff, it's the removals insrc/cpu/sparc/vm/vm_version_sparc.cpp from 8056124, which have not yet been put back into 8u. The diff is also in the above hotspot-compiler-dev thread. This builds on 8049717 which we discussed yesterday. I plan to push these 3 together. Many thanks Kevin From sean.coffey at oracle.com Fri Mar 31 10:26:11 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 31 Mar 2017 11:26:11 +0100 Subject: [8u-dev] Request for approval: 8177817 (new small change for 8u), and 8134119 (backport) In-Reply-To: <238942fb-e6c0-7738-3e10-0034bf31700a@oracle.com> References: <238942fb-e6c0-7738-3e10-0034bf31700a@oracle.com> Message-ID: <3f317bd9-ef01-c8cc-37e6-db6650600a5e@oracle.com> Looks fine Kevin. Approved. Regards, Sean. On 31/03/17 10:46, Kevin Walls wrote: > Hi, > > This is an approval request for a backport to 8u of: > > 8134119: Use new API to get cache line sizes > https://bugs.openjdk.java.net/browse/JDK-8134119 > 9 change: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/raw-rev/be30670bbd35 > > This will backport almost cleanly: must change os:strdup_check_oom() > to just os::strdup(). > > However, I first need to push the following new CR to 8u, so this is > also a request for approval for: > > 8177817: Remove assertions in 8u that were removed by 8056124 in 9. > https://bugs.openjdk.java.net/browse/JDK-8177817 > 9 change for 8056124: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/63934ec778a2 > > This is a new change to do some code removal exactly as 8056124 did in > 9, also explained in hotspot-compiler-dev: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025923.html > > I've been over this plan with the original author. The new CR 8177817 > lets other changes backport almost unchanged from their 9 changesets. > > In the bug comment for 8177817 I've put the diff, it's the removals > insrc/cpu/sparc/vm/vm_version_sparc.cpp from 8056124, which have not > yet been put back into 8u. The diff is also in the above > hotspot-compiler-dev thread. > > This builds on 8049717 which we discussed yesterday. I plan to push > these 3 together. > > Many thanks > Kevin > > From kevin.walls at oracle.com Fri Mar 31 10:27:10 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 31 Mar 2017 11:27:10 +0100 Subject: [8u-dev] Request for approval: 8177817 (new small change for 8u), and 8134119 (backport) In-Reply-To: <3f317bd9-ef01-c8cc-37e6-db6650600a5e@oracle.com> References: <238942fb-e6c0-7738-3e10-0034bf31700a@oracle.com> <3f317bd9-ef01-c8cc-37e6-db6650600a5e@oracle.com> Message-ID: Thanks! On 31/03/2017 11:26, Se?n Coffey wrote: > Looks fine Kevin. Approved. > > Regards, > Sean. > > On 31/03/17 10:46, Kevin Walls wrote: >> Hi, >> >> This is an approval request for a backport to 8u of: >> >> 8134119: Use new API to get cache line sizes >> https://bugs.openjdk.java.net/browse/JDK-8134119 >> 9 change: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/raw-rev/be30670bbd35 >> >> This will backport almost cleanly: must change os:strdup_check_oom() >> to just os::strdup(). >> >> However, I first need to push the following new CR to 8u, so this is >> also a request for approval for: >> >> 8177817: Remove assertions in 8u that were removed by 8056124 in 9. >> https://bugs.openjdk.java.net/browse/JDK-8177817 >> 9 change for 8056124: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/63934ec778a2 >> >> This is a new change to do some code removal exactly as 8056124 did >> in 9, also explained in hotspot-compiler-dev: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025923.html >> >> I've been over this plan with the original author. The new CR >> 8177817 lets other changes backport almost unchanged from their 9 >> changesets. >> >> In the bug comment for 8177817 I've put the diff, it's the removals >> insrc/cpu/sparc/vm/vm_version_sparc.cpp from 8056124, which have not >> yet been put back into 8u. The diff is also in the above >> hotspot-compiler-dev thread. >> >> This builds on 8049717 which we discussed yesterday. I plan to push >> these 3 together. >> >> Many thanks >> Kevin >> >> > From kevin.walls at oracle.com Fri Mar 31 14:32:26 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 31 Mar 2017 15:32:26 +0100 Subject: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems Message-ID: Hi, This is an approval request to backport into 8u: 8165482: java in ldoms, with cpu-arch=generic has problems 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dfff5edc66df With a few routine changes this backports OK: src/cpu/sparc/vm/vm_version_sparc.cpp: has a different initial number of %s in a call to jio_snprintf(), so it's not automatic, but the backport adds one %s. src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: in 8u we have an #ifndef PRODUCT which isn't in 9, not part of the change, but means the diff won't apply automatically. 9 uses log(), logging in 8u uses tty->print_cr, and needs err_msg() to form a message rather than having printf-style formatting built-in. 8u also uses #ifndef PRODUCT also, and in some places if (PrintMiscellaneous && Verbose) Webrev in 8u of these changes: http://cr.openjdk.java.net/~kevinw/8165482.8u/webrev.00/ Thanks Kevin From rob.mckenna at oracle.com Fri Mar 31 17:50:09 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 31 Mar 2017 18:50:09 +0100 Subject: [8u-dev] Request for approval for CR: 8165482: java in ldoms, with cpu-arch=generic has problems In-Reply-To: References: Message-ID: <20170331175009.GC3631@vimes> Hi Kevin, These changes will need codereview. -Rob On 31/03/17 03:32, Kevin Walls wrote: > Hi, > > This is an approval request to backport into 8u: > > 8165482: java in ldoms, with cpu-arch=generic has problems > 9 changeset: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dfff5edc66df > > With a few routine changes this backports OK: > > src/cpu/sparc/vm/vm_version_sparc.cpp: has a different initial number of %s > in a call to jio_snprintf(), so it's not automatic, but the backport adds > one %s. > > src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: in 8u we have an > #ifndef PRODUCT which isn't in 9, not part of the change, but means the diff > won't apply automatically. > > 9 uses log(), logging in 8u uses tty->print_cr, and needs err_msg() to form > a message rather than having printf-style formatting built-in. 8u also uses > #ifndef PRODUCT also, and in some places if (PrintMiscellaneous && Verbose) > > Webrev in 8u of these changes: > http://cr.openjdk.java.net/~kevinw/8165482.8u/webrev.00/ > > Thanks > Kevin > > > > From anton.litvinov at oracle.com Fri Mar 31 18:08:19 2017 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 31 Mar 2017 21:08:19 +0300 Subject: [8u-dev] Request for approval for CR 8061258: [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges Message-ID: Hello, I would like to request for approval to push a straight backport of the fix from JDK 9 to JDK 8. The patch from JDK 9 applies to JDK 8 after correction of a file path. Bug: https://bugs.openjdk.java.net/browse/JDK-8061258 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/255bd388febe JDK 9 review thread: Approval 1 - http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006606.html Approval 2 - http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006621.html Reviewers: prr, jdv This backport fix is necessary for me to allow to backport my fix for the bug JDK-8167102. Prasanta Sadhukhan, the author of the fix, is added in "Cc:" list of this e-mail. I verified that the bug JDK-8061258 exists in "jdk8u-dev" and that this backport fix resolves it. If this request is approved, I will commit this backport fix with "-u psadhukhan" option to reflect Prasanta as the author of the fix. Thank you, Anton From rob.mckenna at oracle.com Fri Mar 31 21:48:10 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 31 Mar 2017 22:48:10 +0100 Subject: [8u-dev] Request for approval for CR 8061258: [macosx] PrinterJob's native Print Dialog does not reflect specified Copies or Page Ranges In-Reply-To: References: Message-ID: <20170331214810.GD3631@vimes> Approved -Rob On 31/03/17 09:08, Anton Litvinov wrote: > Hello, > > I would like to request for approval to push a straight backport of the fix > from JDK 9 to JDK 8. The patch from JDK 9 applies to JDK 8 after correction > of a file path. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061258 > JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/255bd388febe > JDK 9 review thread: > Approval 1 - > http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006606.html > Approval 2 - > http://mail.openjdk.java.net/pipermail/2d-dev/2016-March/006621.html > Reviewers: prr, jdv > > This backport fix is necessary for me to allow to backport my fix for the > bug JDK-8167102. Prasanta Sadhukhan, the author of the fix, is added in > "Cc:" list of this e-mail. I verified that the bug JDK-8061258 exists in > "jdk8u-dev" and that this backport fix resolves it. If this request is > approved, I will commit this backport fix with "-u psadhukhan" option to > reflect Prasanta as the author of the fix. > > Thank you, > Anton From rob.mckenna at oracle.com Fri Mar 3 23:11:41 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 03 Mar 2017 23:11:41 -0000 Subject: What to pass to --with-custom-make-dir? In-Reply-To: <641A8C06-331C-4F47-BDF0-FC1DE8CF6D10@twitter.com> References: <641A8C06-331C-4F47-BDF0-FC1DE8CF6D10@twitter.com> Message-ID: <20170303231115.GB3196@vimes> Hi Christian, I'm cc'ing build-dev (and bcc'ing jdk8u-dev) as that may be a more appropriate venue for this discussion. -Rob On 03/03/17 10:19, Christian Thalinger wrote: > At Twitter we are using the custom extension mechanism to separate our additional code from upstream in order to minimize conflicts. Yesterday I wanted to add a custom extension for: > > jdk/make/lib/ServiceabilityLibraries.gmk > > which has this include directive: > > # Include custom extensions if available. > -include $(CUSTOM_MAKE_DIR)/lib/ServiceabilityLibraries.gmk > > We are already using the mechanism for top-level make files, e.g. make/Main.gmk: > > # Include the corresponding custom file, if present. > -include $(CUSTOM_MAKE_DIR)/Main.gmk > > and we a configuring with: > > --with-custom-make-dir=make/closed > > This works fine for make/ but not for jdk/make/: > > $ make jdk CUSTOM_MAKE_DIR=make/closed > ? > > ## Starting jdk > lib/ServiceabilityLibraries.gmk:27: make/closed/lib/ServiceabilityLibraries.gmk: No such file or directory > make[2]: *** No rule to make target `make/closed/lib/ServiceabilityLibraries.gmk'. Stop. > make[1]: *** [libs-only] Error 2 > make: *** [jdk-only] Error 2 > > (I changed "-include" to ?include? to provoke the error.) > > jdk/make/ files expect CUSTOM_MAKE_DIR to be just ?closed? but that doesn?t work for top-level: > > $ make jdk CUSTOM_MAKE_DIR=closed > /Users/cthalinger/twitter8//make/Main.gmk:35: closed/Main.gmk: No such file or directory > make: *** No rule to make target `closed/Main.gmk'. Stop. > > How is this supposed to work? From bruno.kremel at gmail.com Wed Mar 29 20:23:25 2017 From: bruno.kremel at gmail.com (Bruno Kremel) Date: Wed, 29 Mar 2017 22:23:25 +0200 Subject: Cross compiling Openjdk 8 for ARM, can't locate compiler Message-ID: <8760irn876.fsf@bruno-dell> Hi All, As I was not able to compile OpenJDK 9 (there is disscussion in other mailing list). I tried to compile OpenJDK 8 precisely changeset 152-b02. I configure this way: ./configure --with-jvm-interpreter=cpp \ --with-jvm-variants=zero --enable-openjdk-only \ --with-freetype-include=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/freetype2\ --with-freetype-lib=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib\ --with-freetype=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/\ --with-debug-level=release --openjdk-target=arm-buildroot-linux-gnueabi \ --with-sys-root=~/linux/buildroot-openjdk8/output/host/usr/arm-buildroot-linux-gnueabi/sysroot\ --with-tools-dir=~/linux/buildroot-openjdk8/output/host \ --disable-freetype-bundling --enable-unlimited-crypto --disable-headful\ OBJCOPY=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-objcopy STRIP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-strip CPP_FLAGS=-lstdc++ CXX_FLAGS=-lstdc++ CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ BUILD_CPP=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-cpp\ BUILD_CXX=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++\ BUILD_CC=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc\ BUILD_LD=~/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc The configure script seems to have some bug that it can't locate the compiler properly: ... checking for cl... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc configure: Resolving BUILD_CC (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) faile d, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc directly. checking for cl... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ configure: Resolving BUILD_CXX (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++) fail ed, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-g++ directly. checking for ld... /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc configure: Resolving BUILD_LD (as /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc) faile d, using /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc directly. checking for /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... no checking for /home/bruno/linux/buildroot-openjdk8/output/host/usr/bin/arm-linux-gnueabi-gcc... no configure: error: Could not find a C compiler. You might be able to fix this by running 'sudo apt-get install build-ess ential'. configure exiting with result code 1 ... Those files that it claims "no" do exist and they are indeed a GCC crosscompiler. The same parameters work for OpenJDK 9 (it does find the compiler). How can I resolve this issue? Thanks Bruno Kremel