From ivan.gerasimov at oracle.com Sat Aug 1 16:45:19 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 01 Aug 2015 19:45:19 +0300 Subject: [8u-dev] Request for approval to backport: 6854417: TESTBUG: java/util/regex/RegExTest.java fails intermittently Message-ID: <55BCF79F.4070907@oracle.com> Hi! I'd like to backport this test bug fix. The fix applies cleanly modulo copyright header change. BugId: https://bugs.openjdk.java.net/browse/JDK-6854417 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8afadc476af7 Jdk9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034544.html Sincerely yours, Ivan From Sergey.Bylokhov at oracle.com Mon Aug 3 15:45:02 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 3 Aug 2015 18:45:02 +0300 Subject: [8u60] Request for Approval: 8132382 [macosx] Crash during JMC or JavaFX execution when NSApplication is controlled by SWT or JavaFX libraries Message-ID: <55BF8C7E.5050005@oracle.com> Hello, This is a direct back port from jdk9 to jdk 8u60. Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 Review: http://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009734.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/a6127e88f6d8 Reviewers: Alexander Scherbatiy, Alexander Zuev -- Best regards, Sergey. From rob.mckenna at oracle.com Mon Aug 3 17:59:54 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 03 Aug 2015 18:59:54 +0100 Subject: [8u60] Request for Approval: 8132382 [macosx] Crash during JMC or JavaFX execution when NSApplication is controlled by SWT or JavaFX libraries In-Reply-To: <55BF8C7E.5050005@oracle.com> References: <55BF8C7E.5050005@oracle.com> Message-ID: <55BFAC1A.1070907@oracle.com> Approved. -Rob On 03/08/15 16:45, Sergey Bylokhov wrote: > Hello, > This is a direct back port from jdk9 to jdk 8u60. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8132382 > Review: > http://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009734.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/a6127e88f6d8 > > Reviewers: Alexander Scherbatiy, Alexander Zuev > > -- > Best regards, Sergey. > From rob.mckenna at oracle.com Mon Aug 3 18:00:02 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 03 Aug 2015 19:00:02 +0100 Subject: [8u-dev] Request for approval to backport: 6854417: TESTBUG: java/util/regex/RegExTest.java fails intermittently In-Reply-To: <55BCF79F.4070907@oracle.com> References: <55BCF79F.4070907@oracle.com> Message-ID: <55BFAC22.3070403@oracle.com> Approved. -Rob On 01/08/15 17:45, Ivan Gerasimov wrote: > Hi! > > I'd like to backport this test bug fix. > The fix applies cleanly modulo copyright header change. > > BugId: https://bugs.openjdk.java.net/browse/JDK-6854417 > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8afadc476af7 > Jdk9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034544.html > > Sincerely yours, > Ivan From sundararajan.athijegannathan at oracle.com Tue Aug 4 13:32:47 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 04 Aug 2015 19:02:47 +0530 Subject: [8u-dev] approval request for 8073733: TypeError messages with "call" and "new" could be improved Message-ID: <55C0BEFF.2040601@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8073733 jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8073733/8u-dev/webrev.00/ jdk9-dev review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/004984.html Backported "as is" except for modular source layout difference. Thanks, -Sundar From rob.mckenna at oracle.com Tue Aug 4 13:33:43 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 04 Aug 2015 14:33:43 +0100 Subject: [8u-dev] approval request for 8073733: TypeError messages with "call" and "new" could be improved In-Reply-To: <55C0BEFF.2040601@oracle.com> References: <55C0BEFF.2040601@oracle.com> Message-ID: <55C0BF37.5030807@oracle.com> Approved -Rob On 04/08/15 14:32, Sundararajan Athijegannathan wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073733 > jdk8u-dev webrev: > http://cr.openjdk.java.net/~sundar/8073733/8u-dev/webrev.00/ > jdk9-dev review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/004984.html > > Backported "as is" except for modular source layout difference. > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Thu Aug 6 16:52:10 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 06 Aug 2015 22:22:10 +0530 Subject: [8u-dev] approval request for 8133119: Error message associated with TypeError for call and new should include stringified Node Message-ID: <55C390BA.5050105@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8133119 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/004989.html jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8133119/8u-dev/webrev.00/ All files except 2 files are backported "as is" except for modular layout difference. These files have just copyright header missing comma change. But these files don't exist in jdk8u (new files in jdk9-dev) and so not backported: test/script/basic/JDK-8036743.js test/script/basic/JDK-8114838.js * *CC'ing nashorn-dev alias in case additional review is preferred. Thanks, -Sundar From rob.mckenna at oracle.com Thu Aug 6 16:56:29 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 06 Aug 2015 17:56:29 +0100 Subject: [8u-dev] approval request for 8133119: Error message associated with TypeError for call and new should include stringified Node In-Reply-To: <55C390BA.5050105@oracle.com> References: <55C390BA.5050105@oracle.com> Message-ID: <55C391BD.5070100@oracle.com> Approved. I'm ok with the missing files. -Rob On 06/08/15 17:52, Sundararajan Athijegannathan wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133119 > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/004989.html > jdk8u-dev webrev: > http://cr.openjdk.java.net/~sundar/8133119/8u-dev/webrev.00/ > > All files except 2 files are backported "as is" except for modular > layout difference. > > These files have just copyright header missing comma change. But these > files don't exist in jdk8u (new files in jdk9-dev) and so not backported: > > test/script/basic/JDK-8036743.js > test/script/basic/JDK-8114838.js > * > *CC'ing nashorn-dev alias in case additional review is preferred. > > Thanks, > -Sundar From ivan.gerasimov at oracle.com Fri Aug 7 16:07:07 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 07 Aug 2015 19:07:07 +0300 Subject: [8u-dev] Request for approval to backport: 8132551: Initialize local varibales before returning them in p11_convert.c Message-ID: <55C4D7AB.2060402@oracle.com> Hi! I'd like to backport this fix to jdk8u. Would you please approve? Bug: https://bugs.openjdk.java.net/browse/JDK-8132551 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/862ca7e758f9 Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012629.html Sincerely yours, Ivan From rob.mckenna at oracle.com Fri Aug 7 16:08:46 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 07 Aug 2015 17:08:46 +0100 Subject: [8u-dev] Request for approval to backport: 8132551: Initialize local varibales before returning them in p11_convert.c In-Reply-To: <55C4D7AB.2060402@oracle.com> References: <55C4D7AB.2060402@oracle.com> Message-ID: <55C4D80E.3040805@oracle.com> Approved assuming a clean backport. -Rob On 07/08/15 17:07, Ivan Gerasimov wrote: > Hi! > > I'd like to backport this fix to jdk8u. Would you please approve? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8132551 > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/862ca7e758f9 > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012629.html > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Fri Aug 7 16:29:08 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 07 Aug 2015 19:29:08 +0300 Subject: [8u-dev] Request for approval to backport: 8132551: Initialize local varibales before returning them in p11_convert.c In-Reply-To: <55C4D80E.3040805@oracle.com> References: <55C4D7AB.2060402@oracle.com> <55C4D80E.3040805@oracle.com> Message-ID: <55C4DCD4.9060401@oracle.com> Thanks! Yes, forgot to mention that the diff is applied cleanly after un-shuffling. Sincerely yours, Ivan On 07.08.2015 19:08, Rob McKenna wrote: > Approved assuming a clean backport. > > -Rob > > On 07/08/15 17:07, Ivan Gerasimov wrote: >> Hi! >> >> I'd like to backport this fix to jdk8u. Would you please approve? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8132551 >> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/862ca7e758f9 >> Jdk9 review: >> http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012629.html >> >> >> Sincerely yours, >> Ivan > > From ivan.gerasimov at oracle.com Fri Aug 7 16:35:46 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 07 Aug 2015 19:35:46 +0300 Subject: [8u-dev] Request for approval to backport: 8133205, 8133022... Message-ID: <55C4DE62.1000903@oracle.com> Hi! I'd like to backport these two fixes related to the Instant.toEpochMilli() method. The unshuffled patches apply cleanly when applied one after another. Bugs: https://bugs.openjdk.java.net/browse/JDK-8133205 https://bugs.openjdk.java.net/browse/JDK-8133022 Jdk9 changes: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7c6d6f1b7a56 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/17577017dfe2 Reviews: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031945.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034864.html Sincerely yours, Ivan From sean.coffey at oracle.com Fri Aug 7 17:04:59 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 07 Aug 2015 18:04:59 +0100 Subject: [8u-dev] Request for approval to backport: 8133205, 8133022... In-Reply-To: <55C4DE62.1000903@oracle.com> References: <55C4DE62.1000903@oracle.com> Message-ID: <55C4E53B.5060103@oracle.com> Thanks for looking after this. Approved. Regards, Sean. On 07/08/15 17:35, Ivan Gerasimov wrote: > Hi! > > I'd like to backport these two fixes related to the > Instant.toEpochMilli() method. > The unshuffled patches apply cleanly when applied one after another. > > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8133205 > https://bugs.openjdk.java.net/browse/JDK-8133022 > > Jdk9 changes: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7c6d6f1b7a56 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/17577017dfe2 > > Reviews: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031945.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034864.html > > > Sincerely yours, > Ivan From Dale.Topley at rbsint.com Mon Aug 10 14:53:28 2015 From: Dale.Topley at rbsint.com (Topley, Dale (SBMC, RBS International)) Date: Mon, 10 Aug 2015 14:53:28 +0000 Subject: Java 8u60 Release Date Message-ID: <94EA69DFA40E994CABCBA5C3DA45B62743BFCEFD@rije1excmr01v> Afternoon all, Is there an anticipated release date for java 8u60 yet? Even a rough idea as to whether it will be soon or nearer to the end of the month? Many thanks Dale _______________________________________________________________ DISCLAIMER This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the intended addressee, please return the message to the sender by replying to it and then delete the message from your computer. This e-mail may also be legally privileged and any unauthorised use may be unlawful and result in civil and or criminal proceedings being taken against you. Internet e-mails are not necessarily secure as information might be intercepted, lost or destroyed. Please do not e-mail any account or other confidential information. The Royal Bank of Scotland International Limited and the Isle of Man Bank Limited, (the "Companies") do not accept responsibility for changes made to this message after it was sent. If you have received this message in error please contact our IT helpdesk immediately on (+44) (0) 1534 285 268. While all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the Companies in this regard and the recipient should carry out such virus and other checks as it considers appropriate. This e-mail facility is provided by the Companies, which are members of The Royal Bank of Scotland Group. Calls may be recorded. Please refer to http://www.rbsinternational.com/legal-info _______________________________________________________________ From sean.coffey at oracle.com Mon Aug 10 15:48:11 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Mon, 10 Aug 2015 16:48:11 +0100 Subject: Java 8u60 Release Date In-Reply-To: <94EA69DFA40E994CABCBA5C3DA45B62743BFCEFD@rije1excmr01v> References: <94EA69DFA40E994CABCBA5C3DA45B62743BFCEFD@rije1excmr01v> Message-ID: <55C8C7BB.80900@oracle.com> 8u60 should be released within the next 2 weeks. Final testing is ramping down. Release schedules are always preliminary. Please note that early access binaries from Oracle are available at https://jdk8.java.net/download.html Regards, Sean. On 10/08/15 15:53, Topley, Dale (SBMC, RBS International) wrote: > Afternoon all, > > Is there an anticipated release date for java 8u60 yet? Even a rough idea as to whether it will be soon or nearer to the end of the month? > > Many thanks > > Dale > _______________________________________________________________ > > DISCLAIMER > > This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the intended addressee, please return the message to the sender by replying to it and then delete the message from your computer. This e-mail may also be legally privileged and any unauthorised use may be unlawful and result in civil and or criminal proceedings being taken against you. > > Internet e-mails are not necessarily secure as information might be intercepted, lost or destroyed. Please do not e-mail any account or other confidential information. > > The Royal Bank of Scotland International Limited and the Isle of Man Bank Limited, (the "Companies") do not accept responsibility for changes made to this message after it was sent. > > If you have received this message in error please contact our IT helpdesk immediately on (+44) (0) 1534 285 268. > > While all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the Companies in this regard and the recipient should carry out such virus and other checks as it considers appropriate. > > This e-mail facility is provided by the Companies, which are members of The Royal Bank of Scotland Group. > > Calls may be recorded. > > Please refer to http://www.rbsinternational.com/legal-info > > > _______________________________________________________________ From gs.biju at gmail.com Mon Aug 10 16:57:07 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Mon, 10 Aug 2015 12:57:07 -0400 Subject: Java DirectByteBuffer and OOM In-Reply-To: <55C8C313.3030501@redhat.com> References: <55C8C313.3030501@redhat.com> Message-ID: Thanks Andrew for the response. Hi JDK8 development team, Could you please back port and merge the patch https://bugs.openjdk.java.net/browse/JDK-6857566 in JDK 8. This will help in resolving OOM issues in our applications which is using DirectByteBuffer. This will also help the JDK 7 dev team to merge the patch into their code base and that is the version we are using. Thanks, Biju Thanks, Biju On Mon, Aug 10, 2015 at 11:28 AM, Andrew Haley wrote: > On 08/10/2015 04:25 PM, Biju G.S Nair wrote: > > Hi There, > > Our application is failing with unexpected OOM when using Java > > DirectByteBuffer and the fix > > https://bugs.openjdk.java.net/browse/JDK-6857566 currently merged to > JDK 9 > > which includes a scaling sleep time should help us and may be others as > > well who are using JDK 7. Is there a way this patch can be back ported > and > > merged into JDK 7 since the fix seems to be pretty straight forward. That > > will be very helpful and your response is much appreciated. > > Yes, but it should be back-ported to JDK8u. It's not at all conventional > to skip a JDK release. > > Andrew. > > > From ivan.gerasimov at oracle.com Mon Aug 10 20:01:53 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 10 Aug 2015 23:01:53 +0300 Subject: Java DirectByteBuffer and OOM In-Reply-To: References: <55C8C313.3030501@redhat.com> Message-ID: <55C90331.7000304@oracle.com> Hi Biju! I'll see if I can backport that change to jdk8u. Sincerely yours, Ivan On 10.08.2015 19:57, Biju G.S Nair wrote: > Thanks Andrew for the response. > > Hi JDK8 development team, > Could you please back port and merge the patch > https://bugs.openjdk.java.net/browse/JDK-6857566 in JDK 8. This will help > in resolving OOM issues in our applications which is using > DirectByteBuffer. This will also help the JDK 7 dev team to merge the patch > into their code base and that is the version we are using. > > Thanks, > Biju > > > > Thanks, > Biju > > On Mon, Aug 10, 2015 at 11:28 AM, Andrew Haley wrote: > >> On 08/10/2015 04:25 PM, Biju G.S Nair wrote: >>> Hi There, >>> Our application is failing with unexpected OOM when using Java >>> DirectByteBuffer and the fix >>> https://bugs.openjdk.java.net/browse/JDK-6857566 currently merged to >> JDK 9 >>> which includes a scaling sleep time should help us and may be others as >>> well who are using JDK 7. Is there a way this patch can be back ported >> and >>> merged into JDK 7 since the fix seems to be pretty straight forward. That >>> will be very helpful and your response is much appreciated. >> Yes, but it should be back-ported to JDK8u. It's not at all conventional >> to skip a JDK release. >> >> Andrew. >> >> >> > From neugens at redhat.com Tue Aug 11 09:29:51 2015 From: neugens at redhat.com (Mario Torre) Date: Tue, 11 Aug 2015 11:29:51 +0200 Subject: Request for Approval: JDK-8075584: [TESTBUG] test for 8067364 depends on hardwired text advance Message-ID: <1439285391.24713.4.camel@galactica.localdomain> Hi all! I would like to backport the fix for JDK-8075584 into the jdk8u-dev repository if possible. The patch is exactly the same as the one committed on the jdk9 client repository, applies with no modifications: http://hg.openjdk.java.net/jdk9/client/jdk/rev/f45d4e52e7e2 There is already a backport request created and linked to the main bug: JDK-8075585 Cheers, Mario From gs.biju at gmail.com Tue Aug 11 10:29:22 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Tue, 11 Aug 2015 06:29:22 -0400 Subject: Java DirectByteBuffer and OOM In-Reply-To: <55C90331.7000304@oracle.com> References: <55C8C313.3030501@redhat.com> <55C90331.7000304@oracle.com> Message-ID: Thank you Ivan for looking into the request. Hope the merge is pretty straight forward. Thanks, Biju On Mon, Aug 10, 2015 at 4:01 PM, Ivan Gerasimov wrote: > Hi Biju! > > I'll see if I can backport that change to jdk8u. > > Sincerely yours, > Ivan > > > On 10.08.2015 19:57, Biju G.S Nair wrote: > >> Thanks Andrew for the response. >> >> Hi JDK8 development team, >> Could you please back port and merge the patch >> https://bugs.openjdk.java.net/browse/JDK-6857566 in JDK 8. This will help >> in resolving OOM issues in our applications which is using >> DirectByteBuffer. This will also help the JDK 7 dev team to merge the >> patch >> into their code base and that is the version we are using. >> >> Thanks, >> Biju >> >> >> >> Thanks, >> Biju >> >> On Mon, Aug 10, 2015 at 11:28 AM, Andrew Haley wrote: >> >> On 08/10/2015 04:25 PM, Biju G.S Nair wrote: >>> >>>> Hi There, >>>> Our application is failing with unexpected OOM when using Java >>>> DirectByteBuffer and the fix >>>> https://bugs.openjdk.java.net/browse/JDK-6857566 currently merged to >>>> >>> JDK 9 >>> >>>> which includes a scaling sleep time should help us and may be others as >>>> well who are using JDK 7. Is there a way this patch can be back ported >>>> >>> and >>> >>>> merged into JDK 7 since the fix seems to be pretty straight forward. >>>> That >>>> will be very helpful and your response is much appreciated. >>>> >>> Yes, but it should be back-ported to JDK8u. It's not at all conventional >>> to skip a JDK release. >>> >>> Andrew. >>> >>> >>> >>> >> > From gs.biju at gmail.com Tue Aug 11 14:11:43 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Tue, 11 Aug 2015 10:11:43 -0400 Subject: DirectByteBuffer change proposal Message-ID: Hello All, While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 currently applied to jdk 9 (which I had requested to be back ported to JDK 8 & 7) fixes the OOM exception during memory allocation by exponentially increasing the sleep time, this can negatively impact low latency applications using DirectByteBuffers. If we are able to provide a new JVM parameter which the users can set to a percentage value of DirectBuffer use as threshold when the "System.gc()" call in java/nio/Bits.java to be made, then the probability of sleep time being much lower is high. Also it gives users some control over when the gc() need to be requested instead of starting the gc() at the last moment when the direct memory is used fully. Without knowing all the details, to me it looks like a straight forward change. Let me know if there is any issue with the proposed change. If this change is a possibility let me know how I can make a request for this change. Thanks, Biju From sean.coffey at oracle.com Tue Aug 11 14:30:08 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 11 Aug 2015 15:30:08 +0100 Subject: DirectByteBuffer change proposal In-Reply-To: References: Message-ID: <55CA06F0.9020705@oracle.com> Biju, These lists are often not suitable for JDK component specific issues. You should discuss your issue on the nio-dev specific mailing list : http://mail.openjdk.java.net/mailman/listinfo/nio-dev Regards, Sean. On 11/08/2015 15:11, Biju G.S Nair wrote: > Hello All, > While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 > currently applied to jdk 9 (which I had requested to be back ported to JDK > 8 & 7) fixes the OOM exception during memory allocation by exponentially > increasing the sleep time, this can negatively impact low latency > applications using DirectByteBuffers. If we are able to provide a new JVM > parameter which the users can set to a percentage value of DirectBuffer use > as threshold when the "System.gc()" call in java/nio/Bits.java to be made, > then the probability of sleep time being much lower is high. Also it gives > users some control over when the gc() need to be requested instead of > starting the gc() at the last moment when the direct memory is used fully. > Without knowing all the details, to me it looks like a straight forward > change. Let me know if there is any issue with the proposed change. If this > change is a possibility let me know how I can make a request for this > change. > > Thanks, > Biju From gs.biju at gmail.com Tue Aug 11 15:21:32 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Tue, 11 Aug 2015 11:21:32 -0400 Subject: DirectByteBuffer change proposal In-Reply-To: <55CA06F0.9020705@oracle.com> References: <55CA06F0.9020705@oracle.com> Message-ID: Thanks Sean for the guidance. Made a request to the nio-dev team. Thanks, Biju On Tue, Aug 11, 2015 at 10:30 AM, Se?n Coffey wrote: > Biju, > > These lists are often not suitable for JDK component specific issues. You > should discuss your issue on the nio-dev specific mailing list : > http://mail.openjdk.java.net/mailman/listinfo/nio-dev > > Regards, > Sean. > > > On 11/08/2015 15:11, Biju G.S Nair wrote: > >> Hello All, >> While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 >> currently applied to jdk 9 (which I had requested to be back ported to JDK >> 8 & 7) fixes the OOM exception during memory allocation by exponentially >> increasing the sleep time, this can negatively impact low latency >> applications using DirectByteBuffers. If we are able to provide a new JVM >> parameter which the users can set to a percentage value of DirectBuffer >> use >> as threshold when the "System.gc()" call in java/nio/Bits.java to be made, >> then the probability of sleep time being much lower is high. Also it gives >> users some control over when the gc() need to be requested instead of >> starting the gc() at the last moment when the direct memory is used fully. >> Without knowing all the details, to me it looks like a straight forward >> change. Let me know if there is any issue with the proposed change. If >> this >> change is a possibility let me know how I can make a request for this >> change. >> >> Thanks, >> Biju >> > > From peter.levart at gmail.com Tue Aug 11 21:22:13 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Aug 2015 23:22:13 +0200 Subject: DirectByteBuffer change proposal In-Reply-To: References: Message-ID: <55CA6785.9080705@gmail.com> Hi Biju, When I was preparing this patch for JDK9, I did the following measurement: Using LongAdders (to avoid Heisenberg) I counted various exit paths from Bits.reserveMemory() during a test that spawned 128 allocating threads on a 4-core i7 machine, allocating direct buffers randomly sized between 256KB and 1MB for 60 seconds, using -XX:MaxDirectMemorySize=512m: Total of 909960 allocations were performed: - 247993 were satisfied before attempting to help ReferenceHandler thread - 660184 were satisfied while helping ReferenceHandler thread but before triggering System.gc() - 1783 were satisfied after triggering System.gc() but before doing any sleep - no sleeping has been performed The same test, just changing -XX:MaxDirectMemorySize=128m (that means 1MB per thread each allocating direct buffers randomly sized between 256KB and 1MB): Total of 579943 allocations were performed: - 131547 were satisfied before attempting to help ReferenceHandler thread - 438345 were satisfied while helping ReferenceHandler thread but before triggering System.gc() - 10016 were satisfied after triggering System.gc() but before doing any sleep - 34 were satisfied after sleep(1) - 1 was satisfied after sleep(1) followed by sleep(2) Have your observations been different? Did you observe sleep() been called in a real-world application? Regards, Peter On 08/11/2015 04:11 PM, Biju G.S Nair wrote: > Hello All, > While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 > currently applied to jdk 9 (which I had requested to be back ported to JDK > 8 & 7) fixes the OOM exception during memory allocation by exponentially > increasing the sleep time, this can negatively impact low latency > applications using DirectByteBuffers. If we are able to provide a new JVM > parameter which the users can set to a percentage value of DirectBuffer use > as threshold when the "System.gc()" call in java/nio/Bits.java to be made, > then the probability of sleep time being much lower is high. Also it gives > users some control over when the gc() need to be requested instead of > starting the gc() at the last moment when the direct memory is used fully. > Without knowing all the details, to me it looks like a straight forward > change. Let me know if there is any issue with the proposed change. If this > change is a possibility let me know how I can make a request for this > change. > > Thanks, > Biju From gs.biju at gmail.com Tue Aug 11 21:43:39 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Tue, 11 Aug 2015 17:43:39 -0400 Subject: DirectByteBuffer change proposal In-Reply-To: <55CA6785.9080705@gmail.com> References: <55CA6785.9080705@gmail.com> Message-ID: Hi Peter, Thanks for the background. Yes. We have seen sleep being called since we are using DirectByteBuffers in GBs and the plan is to see whether we can go up more than 90 GB. Also we have seen in certain version of Linux kernel the 100 ms sleep was insufficient (looking for the real issue on the kernel end). This is primarily to best use all the resources on our servers which are mostly 32 cores and > 126 GB physical memory. By giving users the additional option to set the threshold that would give users like us additional lever to control based on the work load/pattern. That is the thought. Hope this helps. Please let me know if you have any further questions. Thanks, Biju On Tue, Aug 11, 2015 at 5:22 PM, Peter Levart wrote: > Hi Biju, > > When I was preparing this patch for JDK9, I did the following measurement: > Using LongAdders (to avoid Heisenberg) I counted various exit paths from > Bits.reserveMemory() during a test that spawned 128 allocating threads on a > 4-core i7 machine, allocating direct buffers randomly sized between 256KB > and 1MB for 60 seconds, using -XX:MaxDirectMemorySize=512m: > > Total of 909960 allocations were performed: > > - 247993 were satisfied before attempting to help ReferenceHandler thread > - 660184 were satisfied while helping ReferenceHandler thread but before > triggering System.gc() > - 1783 were satisfied after triggering System.gc() but before doing any > sleep > - no sleeping has been performed > > The same test, just changing -XX:MaxDirectMemorySize=128m (that means 1MB > per thread each allocating direct buffers randomly sized between 256KB and > 1MB): > > Total of 579943 allocations were performed: > > - 131547 were satisfied before attempting to help ReferenceHandler thread > - 438345 were satisfied while helping ReferenceHandler thread but before > triggering System.gc() > - 10016 were satisfied after triggering System.gc() but before doing any > sleep > - 34 were satisfied after sleep(1) > - 1 was satisfied after sleep(1) followed by sleep(2) > > > Have your observations been different? Did you observe sleep() been called > in a real-world application? > > > Regards, Peter > > > > On 08/11/2015 04:11 PM, Biju G.S Nair wrote: > > Hello All, > While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 > currently applied to jdk 9 (which I had requested to be back ported to JDK > 8 & 7) fixes the OOM exception during memory allocation by exponentially > increasing the sleep time, this can negatively impact low latency > applications using DirectByteBuffers. If we are able to provide a new JVM > parameter which the users can set to a percentage value of DirectBuffer use > as threshold when the "System.gc()" call in java/nio/Bits.java to be made, > then the probability of sleep time being much lower is high. Also it gives > users some control over when the gc() need to be requested instead of > starting the gc() at the last moment when the direct memory is used fully. > Without knowing all the details, to me it looks like a straight forward > change. Let me know if there is any issue with the proposed change. If this > change is a possibility let me know how I can make a request for this > change. > > Thanks, > Biju > > > From lana.steuck at oracle.com Tue Aug 11 22:21:31 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Aug 2015 15:21:31 -0700 (PDT) Subject: jdk8u-b01: jdk8u-dev Message-ID: <201508112221.t7BMLVJr001505@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk8u/jdk8u/rev/d0afaafe3790 http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/rev/645ffd6ff142 http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/a44348b50794 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2a9fa9e2f50 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/121e784f01d1 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/176a2ce2e2d6 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/2119e5536f3e http://hg.openjdk.java.net/jdk8u/jdk8u/corba/rev/f0c760a2a888 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8132382 client-libs [macosx] Crash during JMC or JavaFX execution when NSApplication is co JDK-8065081 client-libs Intermittent NPE in Java2Demo applet on Stop/Restart in appletviewer JDK-8130776 client-libs Remove EmbeddedFrame.requestFocusToEmbedder() method JDK-8005226 core-libs [TEST_BUG]: java/rmi/transport/pinClientSocketFactory/PinClientSocketF JDK-8130663 core-libs 6 fields can be static fields in Global class JDK-8131039 core-libs after adding a function property to Object.prototype, JSON.parse with JDK-8114838 core-libs Anonymous functions escape to surrounding scope when defined under "wi JDK-8129959 core-libs DebugLogger has unnecessary API methods JDK-8131683 core-libs Delete fails over multiple scopes JDK-8130234 core-libs Get rid of JSType.isNegativeZero JDK-8130424 core-libs if directory specified with --dest-dir does not exist, only .class fil JDK-8130307 core-libs improve Nashorn Javadoc target JDK-8130006 core-libs java/lang/invoke/MethodHandles/CatchExceptionTest Fails JDK-8130853 core-libs Non-extensible global is not handled property JDK-8130476 core-libs Remove unused methods in Global.java JDK-6854417 core-libs TESTBUG: java/util/regex/RegExTest.java fails intermittently JDK-8073733 core-libs TypeError messages with "call" and "new" could be improved JDK-8131340 core-libs Varargs function is recompiled each time it is linked JDK-8129950 core-libs Wrong condition for checking absence of logger in MethodHandleFactory JDK-8077380 deploy JNLPSigning exception when signed jnlp is launched from local tomcat s JDK-8048353 hotspot jstack -l crashes VM when a Java mirror for a primitive type is locked From peter.levart at gmail.com Wed Aug 12 06:51:22 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Aug 2015 08:51:22 +0200 Subject: DirectByteBuffer change proposal In-Reply-To: References: <55CA6785.9080705@gmail.com> Message-ID: <55CAECEA.6000009@gmail.com> Hi Biju, Just to clear any doubts. You have seen sleep() being called with JDK9 which already includes the patch for 6857566 ? The cleanup of native memory for DirecByteBuffers was and after 6857566 still is designed around sun.misc.Cleaner which is basically a PhantomReference pointing to the DirecByteBuffer. When DirectByteBuffer instance becomes phantom-reachable, VM will at some later time discover it as a pending reference and ReferenceHandlerThread will "clean" it (execute Cleaner's thunk) releasing the native memory. So ordinarily, cleanup of native memory is performed asynchronously short time after VM decides to execute code to discover pending references. This is usually performed when heap allocation reaches certain point (maybe also periodically?). The problem is that memory pressure detected by VM is based on heap memory allocation which does not include native memory. It can and frequently happens that there's no heap memory pressure, but native memory reserved for DirectByteBuffers is exhausted. Current strategy works by waiting until this exhaustion happens and then: - attempts to "help" ReferenceHandlerThread to drain the pending references already discovered by VM, executing any sun.misc.Cleaners on the way; if that does not help, it - triggers System.gc() which hopefully also triggers discovery of pending references, followed by a round of ReferenceHandlerThread helping; if that does not help, it - retries the gc/tryHandlePending cycle, introducing exponentially increasing delays (from 1ms up to 512ms) which also acts as some kind of back-pressure; if that does not help, it - considers native memory full and throws OutOfMemoryError You propose to add triggering of gc() when native memory occupancy reaches certain % of max. memory allowed for native buffers. This sounds reasonable as it mimics roughly what happens when heap allocation reaches certain point. Reference handling would still be performed asynchronously solely by ReferenceHandlerThread in this case (no helping with tryHandlePending()) until native memory is exhausted. But note that System.gc() is not free. It usually is implemented as a blocking call which triggers safe-point VM processing and waits for it to complete before returning. So if you wanted to see low latencies for native buffer allocations, this should be performed by a background thread that continuously monitors current occupancy. You can try doing this in client code. There's a JMX bean that exposes native buffer allocation state (BufferPoolMXBean). Can you try doing this and report if it helps with allocation latencies in your application? Regards, Peter On 08/11/2015 11:43 PM, Biju G.S Nair wrote: > Hi Peter, > Thanks for the background. Yes. We have seen sleep being called since > we are using DirectByteBuffers in GBs and the plan is to see whether > we can go up more than 90 GB. Also we have seen in certain version of > Linux kernel the 100 ms sleep was insufficient (looking for the real > issue on the kernel end). This is primarily to best use all the > resources on our servers which are mostly 32 cores and > 126 GB > physical memory. By giving users the additional option to set the > threshold that would give users like us additional lever to control > based on the work load/pattern. That is the thought. Hope this helps. > Please let me know if you have any further questions. > > Thanks, > Biju > > On Tue, Aug 11, 2015 at 5:22 PM, Peter Levart > wrote: > > Hi Biju, > > When I was preparing this patch for JDK9, I did the following > measurement: Using LongAdders (to avoid Heisenberg) I counted > various exit paths from Bits.reserveMemory() during a test that > spawned 128 allocating threads on a 4-core i7 machine, allocating > direct buffers randomly sized between 256KB and 1MB for 60 > seconds, using -XX:MaxDirectMemorySize=512m: > > Total of 909960 allocations were performed: > > - 247993 were satisfied before attempting to help ReferenceHandler > thread > - 660184 were satisfied while helping ReferenceHandler thread but > before triggering System.gc() > - 1783 were satisfied after triggering System.gc() but before > doing any sleep > - no sleeping has been performed > > The same test, just changing -XX:MaxDirectMemorySize=128m (that > means 1MB per thread each allocating direct buffers randomly sized > between 256KB and 1MB): > > Total of 579943 allocations were performed: > > - 131547 were satisfied before attempting to help ReferenceHandler > thread > - 438345 were satisfied while helping ReferenceHandler thread but > before triggering System.gc() > - 10016 were satisfied after triggering System.gc() but before > doing any sleep > - 34 were satisfied after sleep(1) > - 1 was satisfied after sleep(1) followed by sleep(2) > > > Have your observations been different? Did you observe sleep() > been called in a real-world application? > > > Regards, Peter > > > > On 08/11/2015 04:11 PM, Biju G.S Nair wrote: >> Hello All, >> While the patchhttps://bugs.openjdk.java.net/browse/JDK-6857566 >> currently applied to jdk 9 (which I had requested to be back ported to JDK >> 8 & 7) fixes the OOM exception during memory allocation by exponentially >> increasing the sleep time, this can negatively impact low latency >> applications using DirectByteBuffers. If we are able to provide a new JVM >> parameter which the users can set to a percentage value of DirectBuffer use >> as threshold when the "System.gc()" call in java/nio/Bits.java to be made, >> then the probability of sleep time being much lower is high. Also it gives >> users some control over when the gc() need to be requested instead of >> starting the gc() at the last moment when the direct memory is used fully. >> Without knowing all the details, to me it looks like a straight forward >> change. Let me know if there is any issue with the proposed change. If this >> change is a possibility let me know how I can make a request for this >> change. >> >> Thanks, >> Biju > > From cheleswer.sahu at oracle.com Wed Aug 12 10:23:25 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Wed, 12 Aug 2015 15:53:25 +0530 Subject: [8u60] request for approval: 8075773 : jps running as root fails after the fix of JDK-8050807 In-Reply-To: <55CB03AE.5010009@oracle.com> References: <55CB03AE.5010009@oracle.com> Message-ID: <55CB1E9D.7060906@oracle.com> Hi! May I please have approval to backport this fix from JDK9 to JDK8. I have built the JDK-8 hotspot and tested already. JDK9 fix applies cleanly to JDK8. As I do not have an account for OPENJDK, Kevin Walls will push the fix into jdk8u/hs-dev/hotspot. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8075773 JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0762dac98888 Review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015593.html Regards, Cheleswer From sean.coffey at oracle.com Wed Aug 12 10:42:07 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 12 Aug 2015 11:42:07 +0100 Subject: [8u60] request for approval: 8075773 : jps running as root fails after the fix of JDK-8050807 In-Reply-To: <55CB1E9D.7060906@oracle.com> References: <55CB03AE.5010009@oracle.com> <55CB1E9D.7060906@oracle.com> Message-ID: <55CB22FF.90404@oracle.com> Cheleswer, 8u60 forest is in RDP2 mode. 8u66 is also in RDP2 mode. jdk8u-dev is gathering fixes for 8u72 at the moment. Please add a suitable noreg- label : http://openjdk.java.net/guide/changePlanning.html#noreg Approved for jdk8u-dev. Regards, Sean. On 12/08/15 11:23, cheleswer sahu wrote: > Hi! > > May I please have approval to backport this fix from JDK9 to JDK8. I > have built the JDK-8 hotspot and tested already. JDK9 fix applies > cleanly to JDK8. > As I do not have an account for OPENJDK, Kevin Walls will push the fix > into jdk8u/hs-dev/hotspot. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8075773 > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0762dac98888 > > Review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015593.html > > Regards, > Cheleswer > > > > > > > > > > From gs.biju at gmail.com Wed Aug 12 12:53:54 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Wed, 12 Aug 2015 08:53:54 -0400 Subject: DirectByteBuffer change proposal In-Reply-To: <55CAECEA.6000009@gmail.com> References: <55CA6785.9080705@gmail.com> <55CAECEA.6000009@gmail.com> Message-ID: Thanks Peter for the detailed response. Currently we are in JDK 7 since the underlying datastore is still being certified for moving to 8. So the issues we are seeing is not on JDK 9 with the patch. I have requested the jdk8u-dev and jdk9u-dev team through the dev email whether they can back port the patch to the two versions so that we can test. Waiting to get the patch merged. Will update you as soon as the JDK is updated. Thanks, Biju On Wed, Aug 12, 2015 at 2:51 AM, Peter Levart wrote: > Hi Biju, > > Just to clear any doubts. You have seen sleep() being called with JDK9 > which already includes the patch for 6857566 ? > > The cleanup of native memory for DirecByteBuffers was and after 6857566 > still is designed around sun.misc.Cleaner which is basically a > PhantomReference pointing to the DirecByteBuffer. When DirectByteBuffer > instance becomes phantom-reachable, VM will at some later time discover it > as a pending reference and ReferenceHandlerThread will "clean" it (execute > Cleaner's thunk) releasing the native memory. So ordinarily, cleanup of > native memory is performed asynchronously short time after VM decides to > execute code to discover pending references. This is usually performed when > heap allocation reaches certain point (maybe also periodically?). The > problem is that memory pressure detected by VM is based on heap memory > allocation which does not include native memory. It can and frequently > happens that there's no heap memory pressure, but native memory reserved > for DirectByteBuffers is exhausted. > > Current strategy works by waiting until this exhaustion happens and then: > - attempts to "help" ReferenceHandlerThread to drain the pending > references already discovered by VM, executing any sun.misc.Cleaners on the > way; if that does not help, it > - triggers System.gc() which hopefully also triggers discovery of pending > references, followed by a round of ReferenceHandlerThread helping; if that > does not help, it > - retries the gc/tryHandlePending cycle, introducing exponentially > increasing delays (from 1ms up to 512ms) which also acts as some kind of > back-pressure; if that does not help, it > - considers native memory full and throws OutOfMemoryError > > You propose to add triggering of gc() when native memory occupancy reaches > certain % of max. memory allowed for native buffers. This sounds reasonable > as it mimics roughly what happens when heap allocation reaches certain > point. Reference handling would still be performed asynchronously solely by > ReferenceHandlerThread in this case (no helping with tryHandlePending()) > until native memory is exhausted. But note that System.gc() is not free. It > usually is implemented as a blocking call which triggers safe-point VM > processing and waits for it to complete before returning. So if you wanted > to see low latencies for native buffer allocations, this should be > performed by a background thread that continuously monitors current > occupancy. You can try doing this in client code. There's a JMX bean that > exposes native buffer allocation state (BufferPoolMXBean). Can you try > doing this and report if it helps with allocation latencies in your > application? > > Regards, Peter > > > On 08/11/2015 11:43 PM, Biju G.S Nair wrote: > > Hi Peter, > Thanks for the background. Yes. We have seen sleep being called since > we are using DirectByteBuffers in GBs and the plan is to see whether we can > go up more than 90 GB. Also we have seen in certain version of Linux kernel > the 100 ms sleep was insufficient (looking for the real issue on the kernel > end). This is primarily to best use all the resources on our servers which > are mostly 32 cores and > 126 GB physical memory. By giving users the > additional option to set the threshold that would give users like us > additional lever to control based on the work load/pattern. That is the > thought. Hope this helps. Please let me know if you have any further > questions. > > Thanks, > Biju > > On Tue, Aug 11, 2015 at 5:22 PM, Peter Levart > wrote: > >> Hi Biju, >> >> When I was preparing this patch for JDK9, I did the following >> measurement: Using LongAdders (to avoid Heisenberg) I counted various exit >> paths from Bits.reserveMemory() during a test that spawned 128 allocating >> threads on a 4-core i7 machine, allocating direct buffers randomly sized >> between 256KB and 1MB for 60 seconds, using -XX:MaxDirectMemorySize=512m: >> >> Total of 909960 allocations were performed: >> >> - 247993 were satisfied before attempting to help ReferenceHandler thread >> - 660184 were satisfied while helping ReferenceHandler thread but before >> triggering System.gc() >> - 1783 were satisfied after triggering System.gc() but before doing any >> sleep >> - no sleeping has been performed >> >> The same test, just changing -XX:MaxDirectMemorySize=128m (that means 1MB >> per thread each allocating direct buffers randomly sized between 256KB and >> 1MB): >> >> Total of 579943 allocations were performed: >> >> - 131547 were satisfied before attempting to help ReferenceHandler thread >> - 438345 were satisfied while helping ReferenceHandler thread but before >> triggering System.gc() >> - 10016 were satisfied after triggering System.gc() but before doing any >> sleep >> - 34 were satisfied after sleep(1) >> - 1 was satisfied after sleep(1) followed by sleep(2) >> >> >> Have your observations been different? Did you observe sleep() been >> called in a real-world application? >> >> >> Regards, Peter >> >> >> >> On 08/11/2015 04:11 PM, Biju G.S Nair wrote: >> >> Hello All, >> While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 >> currently applied to jdk 9 (which I had requested to be back ported to JDK >> 8 & 7) fixes the OOM exception during memory allocation by exponentially >> increasing the sleep time, this can negatively impact low latency >> applications using DirectByteBuffers. If we are able to provide a new JVM >> parameter which the users can set to a percentage value of DirectBuffer use >> as threshold when the "System.gc()" call in java/nio/Bits.java to be made, >> then the probability of sleep time being much lower is high. Also it gives >> users some control over when the gc() need to be requested instead of >> starting the gc() at the last moment when the direct memory is used fully. >> Without knowing all the details, to me it looks like a straight forward >> change. Let me know if there is any issue with the proposed change. If this >> change is a possibility let me know how I can make a request for this >> change. >> >> Thanks, >> Biju >> >> >> > > From peter.levart at gmail.com Wed Aug 12 14:05:49 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Aug 2015 16:05:49 +0200 Subject: DirectByteBuffer change proposal In-Reply-To: References: <55CA6785.9080705@gmail.com> <55CAECEA.6000009@gmail.com> Message-ID: <55CB52BD.1000604@gmail.com> Hi Biju, Well, seeing sleep() in JDK7 is understandable, since before the patch for 6857566, the strategy was to simply call System.gc() followed by a constant sleep(100L) every time native memory exhaustion was detected. There was no attempt to help process references synchronously before the 1st sleep. My measurements after patch for 6857566 show that sleep() will only be called very infrequently in extreme situations provoked only with stress tests that do nothing but allocate direct buffers in multiple threads. I would be surprised if this happens in any real-world application. The amount of max. direct buffer memory should play a positive role here as more memory there is for native buffers, less probability it is that sleep() will be called. Sleep is called only in situations where the amount of native memory freed when calling gc()/tryHandlePending() - which should be all the memory allocated by currently unreachable buffers - is not enough to cope with concurrent allocation in a time slot between calling gc()/tryHandlePending() and attempting the allocation. At that point, sleep represents a kind of back-pressure to slow-down allocation and allow the program to continue to function over unexpected peaks (like DDOS attacks for example). If you size the max. memory for native buffers to be big enough compared to max. expected allocated and used memory at any time with some spare share, sleep() will not occur. If it occurs regularly, it is a sign that you should increase the max. native memory limit, as your program really needs more memory. Regards, Peter On 08/12/2015 02:53 PM, Biju G.S Nair wrote: > Thanks Peter for the detailed response. Currently we are in JDK 7 > since the underlying datastore is still being certified for moving to > 8. So the issues we are seeing is not on JDK 9 with the patch. I have > requested the jdk8u-dev and jdk9u-dev team through the dev email > whether they can back port the patch to the two versions so that we > can test. Waiting to get the patch merged. Will update you as soon as > the JDK is updated. > > Thanks, > Biju > > On Wed, Aug 12, 2015 at 2:51 AM, Peter Levart > wrote: > > Hi Biju, > > Just to clear any doubts. You have seen sleep() being called with > JDK9 which already includes the patch for 6857566 ? > > The cleanup of native memory for DirecByteBuffers was and after > 6857566 still is designed around sun.misc.Cleaner which is > basically a PhantomReference pointing to the DirecByteBuffer. When > DirectByteBuffer instance becomes phantom-reachable, VM will at > some later time discover it as a pending reference and > ReferenceHandlerThread will "clean" it (execute Cleaner's thunk) > releasing the native memory. So ordinarily, cleanup of native > memory is performed asynchronously short time after VM decides to > execute code to discover pending references. This is usually > performed when heap allocation reaches certain point (maybe also > periodically?). The problem is that memory pressure detected by VM > is based on heap memory allocation which does not include native > memory. It can and frequently happens that there's no heap memory > pressure, but native memory reserved for DirectByteBuffers is > exhausted. > > Current strategy works by waiting until this exhaustion happens > and then: > - attempts to "help" ReferenceHandlerThread to drain the pending > references already discovered by VM, executing any > sun.misc.Cleaners on the way; if that does not help, it > - triggers System.gc() which hopefully also triggers discovery of > pending references, followed by a round of ReferenceHandlerThread > helping; if that does not help, it > - retries the gc/tryHandlePending cycle, introducing exponentially > increasing delays (from 1ms up to 512ms) which also acts as some > kind of back-pressure; if that does not help, it > - considers native memory full and throws OutOfMemoryError > > You propose to add triggering of gc() when native memory occupancy > reaches certain % of max. memory allowed for native buffers. This > sounds reasonable as it mimics roughly what happens when heap > allocation reaches certain point. Reference handling would still > be performed asynchronously solely by ReferenceHandlerThread in > this case (no helping with tryHandlePending()) until native memory > is exhausted. But note that System.gc() is not free. It usually is > implemented as a blocking call which triggers safe-point VM > processing and waits for it to complete before returning. So if > you wanted to see low latencies for native buffer allocations, > this should be performed by a background thread that continuously > monitors current occupancy. You can try doing this in client code. > There's a JMX bean that exposes native buffer allocation state > (BufferPoolMXBean). Can you try doing this and report if it helps > with allocation latencies in your application? > > Regards, Peter > > > On 08/11/2015 11:43 PM, Biju G.S Nair wrote: >> Hi Peter, >> Thanks for the background. Yes. We have seen sleep being >> called since we are using DirectByteBuffers in GBs and the plan >> is to see whether we can go up more than 90 GB. Also we have seen >> in certain version of Linux kernel the 100 ms sleep was >> insufficient (looking for the real issue on the kernel end). This >> is primarily to best use all the resources on our servers which >> are mostly 32 cores and > 126 GB physical memory. By giving users >> the additional option to set the threshold that would give users >> like us additional lever to control based on the work >> load/pattern. That is the thought. Hope this helps. Please let me >> know if you have any further questions. >> >> Thanks, >> Biju >> >> On Tue, Aug 11, 2015 at 5:22 PM, Peter Levart >> > wrote: >> >> Hi Biju, >> >> When I was preparing this patch for JDK9, I did the following >> measurement: Using LongAdders (to avoid Heisenberg) I counted >> various exit paths from Bits.reserveMemory() during a test >> that spawned 128 allocating threads on a 4-core i7 machine, >> allocating direct buffers randomly sized between 256KB and >> 1MB for 60 seconds, using -XX:MaxDirectMemorySize=512m: >> >> Total of 909960 allocations were performed: >> >> - 247993 were satisfied before attempting to help >> ReferenceHandler thread >> - 660184 were satisfied while helping ReferenceHandler thread >> but before triggering System.gc() >> - 1783 were satisfied after triggering System.gc() but before >> doing any sleep >> - no sleeping has been performed >> >> The same test, just changing -XX:MaxDirectMemorySize=128m >> (that means 1MB per thread each allocating direct buffers >> randomly sized between 256KB and 1MB): >> >> Total of 579943 allocations were performed: >> >> - 131547 were satisfied before attempting to help >> ReferenceHandler thread >> - 438345 were satisfied while helping ReferenceHandler thread >> but before triggering System.gc() >> - 10016 were satisfied after triggering System.gc() but >> before doing any sleep >> - 34 were satisfied after sleep(1) >> - 1 was satisfied after sleep(1) followed by sleep(2) >> >> >> Have your observations been different? Did you observe >> sleep() been called in a real-world application? >> >> >> Regards, Peter >> >> >> >> On 08/11/2015 04:11 PM, Biju G.S Nair wrote: >>> Hello All, >>> While the patchhttps://bugs.openjdk.java.net/browse/JDK-6857566 >>> currently applied to jdk 9 (which I had requested to be back ported to JDK >>> 8 & 7) fixes the OOM exception during memory allocation by exponentially >>> increasing the sleep time, this can negatively impact low latency >>> applications using DirectByteBuffers. If we are able to provide a new JVM >>> parameter which the users can set to a percentage value of DirectBuffer use >>> as threshold when the "System.gc()" call in java/nio/Bits.java to be made, >>> then the probability of sleep time being much lower is high. Also it gives >>> users some control over when the gc() need to be requested instead of >>> starting the gc() at the last moment when the direct memory is used fully. >>> Without knowing all the details, to me it looks like a straight forward >>> change. Let me know if there is any issue with the proposed change. If this >>> change is a possibility let me know how I can make a request for this >>> change. >>> >>> Thanks, >>> Biju >> >> > > From gs.biju at gmail.com Wed Aug 12 14:24:31 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Wed, 12 Aug 2015 10:24:31 -0400 Subject: DirectByteBuffer change proposal In-Reply-To: <55CB52BD.1000604@gmail.com> References: <55CA6785.9080705@gmail.com> <55CAECEA.6000009@gmail.com> <55CB52BD.1000604@gmail.com> Message-ID: Peter, that sounds very good. Hope the patch will be back-ported and made available in JDK 7 & 8 so that we can test. I will help resolve our issues as well. Thanks, Biju On Wed, Aug 12, 2015 at 10:05 AM, Peter Levart wrote: > Hi Biju, > > Well, seeing sleep() in JDK7 is understandable, since before the patch for > 6857566, the strategy was to simply call System.gc() followed by a constant > sleep(100L) every time native memory exhaustion was detected. There was no > attempt to help process references synchronously before the 1st sleep. My > measurements after patch for 6857566 show that sleep() will only be called > very infrequently in extreme situations provoked only with stress tests > that do nothing but allocate direct buffers in multiple threads. I would be > surprised if this happens in any real-world application. The amount of max. > direct buffer memory should play a positive role here as more memory there > is for native buffers, less probability it is that sleep() will be called. > Sleep is called only in situations where the amount of native memory freed > when calling gc()/tryHandlePending() - which should be all the memory > allocated by currently unreachable buffers - is not enough to cope with > concurrent allocation in a time slot between calling > gc()/tryHandlePending() and attempting the allocation. At that point, sleep > represents a kind of back-pressure to slow-down allocation and allow the > program to continue to function over unexpected peaks (like DDOS attacks > for example). > > If you size the max. memory for native buffers to be big enough compared > to max. expected allocated and used memory at any time with some spare > share, sleep() will not occur. If it occurs regularly, it is a sign that > you should increase the max. native memory limit, as your program really > needs more memory. > > Regards, Peter > > > On 08/12/2015 02:53 PM, Biju G.S Nair wrote: > > Thanks Peter for the detailed response. Currently we are in JDK 7 since > the underlying datastore is still being certified for moving to 8. So the > issues we are seeing is not on JDK 9 with the patch. I have requested the > jdk8u-dev and jdk9u-dev team through the dev email whether they can back > port the patch to the two versions so that we can test. Waiting to get the > patch merged. Will update you as soon as the JDK is updated. > > Thanks, > Biju > > On Wed, Aug 12, 2015 at 2:51 AM, Peter Levart > wrote: > >> Hi Biju, >> >> Just to clear any doubts. You have seen sleep() being called with JDK9 >> which already includes the patch for 6857566 ? >> >> The cleanup of native memory for DirecByteBuffers was and after 6857566 >> still is designed around sun.misc.Cleaner which is basically a >> PhantomReference pointing to the DirecByteBuffer. When DirectByteBuffer >> instance becomes phantom-reachable, VM will at some later time discover it >> as a pending reference and ReferenceHandlerThread will "clean" it (execute >> Cleaner's thunk) releasing the native memory. So ordinarily, cleanup of >> native memory is performed asynchronously short time after VM decides to >> execute code to discover pending references. This is usually performed when >> heap allocation reaches certain point (maybe also periodically?). The >> problem is that memory pressure detected by VM is based on heap memory >> allocation which does not include native memory. It can and frequently >> happens that there's no heap memory pressure, but native memory reserved >> for DirectByteBuffers is exhausted. >> >> Current strategy works by waiting until this exhaustion happens and then: >> - attempts to "help" ReferenceHandlerThread to drain the pending >> references already discovered by VM, executing any sun.misc.Cleaners on the >> way; if that does not help, it >> - triggers System.gc() which hopefully also triggers discovery of pending >> references, followed by a round of ReferenceHandlerThread helping; if that >> does not help, it >> - retries the gc/tryHandlePending cycle, introducing exponentially >> increasing delays (from 1ms up to 512ms) which also acts as some kind of >> back-pressure; if that does not help, it >> - considers native memory full and throws OutOfMemoryError >> >> You propose to add triggering of gc() when native memory occupancy >> reaches certain % of max. memory allowed for native buffers. This sounds >> reasonable as it mimics roughly what happens when heap allocation reaches >> certain point. Reference handling would still be performed asynchronously >> solely by ReferenceHandlerThread in this case (no helping with >> tryHandlePending()) until native memory is exhausted. But note that >> System.gc() is not free. It usually is implemented as a blocking call which >> triggers safe-point VM processing and waits for it to complete before >> returning. So if you wanted to see low latencies for native buffer >> allocations, this should be performed by a background thread that >> continuously monitors current occupancy. You can try doing this in client >> code. There's a JMX bean that exposes native buffer allocation state >> (BufferPoolMXBean). Can you try doing this and report if it helps with >> allocation latencies in your application? >> >> Regards, Peter >> >> >> On 08/11/2015 11:43 PM, Biju G.S Nair wrote: >> >> Hi Peter, >> Thanks for the background. Yes. We have seen sleep being called since >> we are using DirectByteBuffers in GBs and the plan is to see whether we can >> go up more than 90 GB. Also we have seen in certain version of Linux kernel >> the 100 ms sleep was insufficient (looking for the real issue on the kernel >> end). This is primarily to best use all the resources on our servers which >> are mostly 32 cores and > 126 GB physical memory. By giving users the >> additional option to set the threshold that would give users like us >> additional lever to control based on the work load/pattern. That is the >> thought. Hope this helps. Please let me know if you have any further >> questions. >> >> Thanks, >> Biju >> >> On Tue, Aug 11, 2015 at 5:22 PM, Peter Levart < >> peter.levart at gmail.com> wrote: >> >>> Hi Biju, >>> >>> When I was preparing this patch for JDK9, I did the following >>> measurement: Using LongAdders (to avoid Heisenberg) I counted various exit >>> paths from Bits.reserveMemory() during a test that spawned 128 allocating >>> threads on a 4-core i7 machine, allocating direct buffers randomly sized >>> between 256KB and 1MB for 60 seconds, using -XX:MaxDirectMemorySize=512m: >>> >>> Total of 909960 allocations were performed: >>> >>> - 247993 were satisfied before attempting to help ReferenceHandler thread >>> - 660184 were satisfied while helping ReferenceHandler thread but before >>> triggering System.gc() >>> - 1783 were satisfied after triggering System.gc() but before doing any >>> sleep >>> - no sleeping has been performed >>> >>> The same test, just changing -XX:MaxDirectMemorySize=128m (that means >>> 1MB per thread each allocating direct buffers randomly sized between 256KB >>> and 1MB): >>> >>> Total of 579943 allocations were performed: >>> >>> - 131547 were satisfied before attempting to help ReferenceHandler thread >>> - 438345 were satisfied while helping ReferenceHandler thread but before >>> triggering System.gc() >>> - 10016 were satisfied after triggering System.gc() but before doing any >>> sleep >>> - 34 were satisfied after sleep(1) >>> - 1 was satisfied after sleep(1) followed by sleep(2) >>> >>> >>> Have your observations been different? Did you observe sleep() been >>> called in a real-world application? >>> >>> >>> Regards, Peter >>> >>> >>> >>> On 08/11/2015 04:11 PM, Biju G.S Nair wrote: >>> >>> Hello All, >>> While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 >>> currently applied to jdk 9 (which I had requested to be back ported to JDK >>> 8 & 7) fixes the OOM exception during memory allocation by exponentially >>> increasing the sleep time, this can negatively impact low latency >>> applications using DirectByteBuffers. If we are able to provide a new JVM >>> parameter which the users can set to a percentage value of DirectBuffer use >>> as threshold when the "System.gc()" call in java/nio/Bits.java to be made, >>> then the probability of sleep time being much lower is high. Also it gives >>> users some control over when the gc() need to be requested instead of >>> starting the gc() at the last moment when the direct memory is used fully. >>> Without knowing all the details, to me it looks like a straight forward >>> change. Let me know if there is any issue with the proposed change. If this >>> change is a possibility let me know how I can make a request for this >>> change. >>> >>> Thanks, >>> Biju >>> >>> >>> >> >> > > From kevin.walls at oracle.com Wed Aug 12 15:03:58 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 12 Aug 2015 16:03:58 +0100 Subject: [8u60] request for approval: 8075773 : jps running as root fails after the fix of JDK-8050807 In-Reply-To: <55CB22FF.90404@oracle.com> References: <55CB03AE.5010009@oracle.com> <55CB1E9D.7060906@oracle.com> <55CB22FF.90404@oracle.com> Message-ID: <55CB605E.7030205@oracle.com> Hi - just to clarify - this will go into hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot (not hg.openjdk.java.net/jdk8u/hs-dev/hotspot). Thanks Kevin On 12/08/2015 11:42, Se?n Coffey wrote: > Cheleswer, > > 8u60 forest is in RDP2 mode. 8u66 is also in RDP2 mode. jdk8u-dev is > gathering fixes for 8u72 at the moment. > Please add a suitable noreg- label : > http://openjdk.java.net/guide/changePlanning.html#noreg > > Approved for jdk8u-dev. > > Regards, > Sean. > > On 12/08/15 11:23, cheleswer sahu wrote: >> Hi! >> >> May I please have approval to backport this fix from JDK9 to JDK8. I >> have built the JDK-8 hotspot and tested already. JDK9 fix applies >> cleanly to JDK8. >> As I do not have an account for OPENJDK, Kevin Walls will push the >> fix into jdk8u/hs-dev/hotspot. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8075773 >> >> JDK9 changeset: >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0762dac98888 >> >> Review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015593.html >> >> Regards, >> Cheleswer >> >> >> >> >> >> >> >> >> >> > From mikhail.cherkasov at oracle.com Thu Aug 13 12:33:23 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 13 Aug 2015 15:33:23 +0300 Subject: [8u-dev] request for approval: 8081787, [macosx] MalformedURLException is thrown during reading data for application/x-java-url; class=java.net.URL flavor Message-ID: <55CC8E93.3030605@oracle.com> Hello, Could you please arrove a direct backport of 8081787 from 9 to 8? bug url: https://bugs.openjdk.java.net/browse/JDK-8081787 JDK9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b5da75248534 Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009579.html http://mail.openjdk.java.net/pipermail/awt-dev/2015-August/009781.html Thanks, Mikhail. From sean.coffey at oracle.com Thu Aug 13 13:04:41 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 13 Aug 2015 14:04:41 +0100 Subject: [8u-dev] request for approval: 8081787, [macosx] MalformedURLException is thrown during reading data for application/x-java-url; class=java.net.URL flavor In-Reply-To: <55CC8E93.3030605@oracle.com> References: <55CC8E93.3030605@oracle.com> Message-ID: <55CC95E9.5040404@oracle.com> Approved. Regards, Sean. On 13/08/2015 13:33, mikhail cherkasov wrote: > Hello, > > Could you please arrove a direct backport of 8081787 from 9 to 8? > > bug url: https://bugs.openjdk.java.net/browse/JDK-8081787 > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b5da75248534 > > Review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009579.html > http://mail.openjdk.java.net/pipermail/awt-dev/2015-August/009781.html > > Thanks, > Mikhail. > > > > > > > > > From ivan.gerasimov at oracle.com Sat Aug 15 12:23:02 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 15 Aug 2015 15:23:02 +0300 Subject: [8u-dev] Request for approval to backport: 8133232: [fs] Regex has redundant | in the char class Message-ID: <55CF2F26.6050803@oracle.com> Hi! I'd like to backport this trivial fix to jdk8. The fix applies cleanly after unshuffling. Would you please approve? Bug: https://bugs.openjdk.java.net/browse/JDK-8133232 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9934cd41afaa Jdk9 review: http://mail.openjdk.java.net/pipermail/nio-dev/2015-August/003282.html Sincerely yours, Ivan From rob.mckenna at oracle.com Sun Aug 16 19:26:50 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Sun, 16 Aug 2015 20:26:50 +0100 Subject: [8u-dev] Request for approval to backport: 8133232: [fs] Regex has redundant | in the char class In-Reply-To: <55CF2F26.6050803@oracle.com> References: <55CF2F26.6050803@oracle.com> Message-ID: <55D0E3FA.8080002@oracle.com> Approved. -Rob On 15/08/15 13:23, Ivan Gerasimov wrote: > Hi! > > I'd like to backport this trivial fix to jdk8. > The fix applies cleanly after unshuffling. > > Would you please approve? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133232 > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9934cd41afaa > Jdk9 review: > http://mail.openjdk.java.net/pipermail/nio-dev/2015-August/003282.html > > Sincerely yours, > Ivan From konstantin.shefov at oracle.com Mon Aug 17 09:40:25 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 17 Aug 2015 12:40:25 +0300 Subject: [8u-dev] Request for approval: 8060717: [TESTBUG] Improve test coverage of MethodHandles.explicitCastArguments() Message-ID: <55D1AC09.5000204@oracle.com> Hello, Could you approve the direct backport of the test only fix to JDK 8u-dev. The bug: https://bugs.openjdk.java.net/browse/JDK-8060717 The webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.01/ Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034764.html The JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/698c03ee0d7b Thanks, Konstantin From konstantin.shefov at oracle.com Mon Aug 17 09:41:55 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 17 Aug 2015 12:41:55 +0300 Subject: [8u-dev] Request for approval: 8133543: [TESTBUG] java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java should be modified Message-ID: <55D1AC63.1080702@oracle.com> Hello, Could you approve the direct backport of the test only fix to JDK 8u-dev. The bug: https://bugs.openjdk.java.net/browse/JDK-8133543 The webrev: http://cr.openjdk.java.net/~kshefov/8133543/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034915.html The JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/53ef4019871f Thanks, Konstantin From maurizio.cimadamore at oracle.com Mon Aug 17 11:03:38 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 17 Aug 2015 12:03:38 +0100 Subject: [8u] request for review: 8068489: remove unnecessary complexity in Flow and Bits, after JDK-8064857 Message-ID: <55D1BF8A.4060404@oracle.com> Hi, Please review the backport of bug: JDK-8133659: Compiler fails to NullPointerException when calling super with Object<>() JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8065986 backport: https://bugs.openjdk.java.net/browse/JDK-8133659 original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/caa3490d5aee public review: http://cr.openjdk.java.net/~mcimadamore/8133659/ The 9 patch doesn't apply cleanly to 8u because of the changes around the Kind.java class (which has been converted into an enum in 9). Changes are only superficial though. Thanks, Maurizio From rob.mckenna at oracle.com Mon Aug 17 11:45:37 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 17 Aug 2015 12:45:37 +0100 Subject: [8u-dev] Request for approval: 8060717: [TESTBUG] Improve test coverage of MethodHandles.explicitCastArguments() In-Reply-To: <55D1AC09.5000204@oracle.com> References: <55D1AC09.5000204@oracle.com> Message-ID: <55D1C961.8010200@oracle.com> Approved. -Rob On 17/08/15 10:40, Konstantin Shefov wrote: > Hello, > > Could you approve the direct backport of the test only fix to JDK 8u-dev. > > The bug: https://bugs.openjdk.java.net/browse/JDK-8060717 > The webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.01/ > Review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034764.html > The JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/698c03ee0d7b > > Thanks, > Konstantin From rob.mckenna at oracle.com Mon Aug 17 11:45:44 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 17 Aug 2015 12:45:44 +0100 Subject: [8u-dev] Request for approval: 8133543: [TESTBUG] java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java should be modified In-Reply-To: <55D1AC63.1080702@oracle.com> References: <55D1AC63.1080702@oracle.com> Message-ID: <55D1C968.10608@oracle.com> Approved. -Rob On 17/08/15 10:41, Konstantin Shefov wrote: > Hello, > > Could you approve the direct backport of the test only fix to JDK 8u-dev. > > The bug: https://bugs.openjdk.java.net/browse/JDK-8133543 > The webrev: http://cr.openjdk.java.net/~kshefov/8133543/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034915.html > > The JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/53ef4019871f > > Thanks, > Konstantin From gs.biju at gmail.com Mon Aug 17 23:21:18 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Mon, 17 Aug 2015 19:21:18 -0400 Subject: Java DirectByteBuffer and OOM In-Reply-To: References: <55C8C313.3030501@redhat.com> <55C90331.7000304@oracle.com> Message-ID: Hi Ivan, Since our applications are getting killed under load due to OOM, it will be very helpful if we can get this patch back ported so that we can use them immediately. I am not familiar with the process of how patches are prioritized. Please let me know if I can do anything to get priority for this patch. Thanks, Biju On Tue, Aug 11, 2015 at 6:29 AM, Biju G.S Nair wrote: > Thank you Ivan for looking into the request. Hope the merge is pretty > straight forward. > > Thanks, > Biju > > On Mon, Aug 10, 2015 at 4:01 PM, Ivan Gerasimov > wrote: > >> Hi Biju! >> >> I'll see if I can backport that change to jdk8u. >> >> Sincerely yours, >> Ivan >> >> >> On 10.08.2015 19:57, Biju G.S Nair wrote: >> >>> Thanks Andrew for the response. >>> >>> Hi JDK8 development team, >>> Could you please back port and merge the patch >>> https://bugs.openjdk.java.net/browse/JDK-6857566 in JDK 8. This will >>> help >>> in resolving OOM issues in our applications which is using >>> DirectByteBuffer. This will also help the JDK 7 dev team to merge the >>> patch >>> into their code base and that is the version we are using. >>> >>> Thanks, >>> Biju >>> >>> >>> >>> Thanks, >>> Biju >>> >>> On Mon, Aug 10, 2015 at 11:28 AM, Andrew Haley wrote: >>> >>> On 08/10/2015 04:25 PM, Biju G.S Nair wrote: >>>> >>>>> Hi There, >>>>> Our application is failing with unexpected OOM when using Java >>>>> DirectByteBuffer and the fix >>>>> https://bugs.openjdk.java.net/browse/JDK-6857566 currently merged to >>>>> >>>> JDK 9 >>>> >>>>> which includes a scaling sleep time should help us and may be others as >>>>> well who are using JDK 7. Is there a way this patch can be back ported >>>>> >>>> and >>>> >>>>> merged into JDK 7 since the fix seems to be pretty straight forward. >>>>> That >>>>> will be very helpful and your response is much appreciated. >>>>> >>>> Yes, but it should be back-ported to JDK8u. It's not at all >>>> conventional >>>> to skip a JDK release. >>>> >>>> Andrew. >>>> >>>> >>>> >>>> >>> >> > From david.holmes at oracle.com Tue Aug 18 01:39:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Aug 2015 11:39:08 +1000 Subject: [8u] Request for approval: 8133629: java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed by timeout Message-ID: <55D28CBC.9000601@oracle.com> Please approve this simple backport to jdk8u-dev Bug: https://bugs.openjdk.java.net/browse/JDK-8029453 Original Changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3e6c865104c Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015646.html The change applies cleanly. Thanks, David From david.holmes at oracle.com Tue Aug 18 01:42:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Aug 2015 11:42:53 +1000 Subject: [8u] Request for approval: 8133629: java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed by timeout In-Reply-To: <55D28CBC.9000601@oracle.com> References: <55D28CBC.9000601@oracle.com> Message-ID: <55D28D9D.8060609@oracle.com> Disregard - incorrect subject line. David On 18/08/2015 11:39 AM, David Holmes wrote: > Please approve this simple backport to jdk8u-dev > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029453 > Original Changeset: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3e6c865104c > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015646.html > > > The change applies cleanly. > > Thanks, > David > From david.holmes at oracle.com Tue Aug 18 01:43:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Aug 2015 11:43:47 +1000 Subject: [8u] Request for approval: 8029453: java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed by timeout In-Reply-To: <55D28CBC.9000601@oracle.com> References: <55D28CBC.9000601@oracle.com> Message-ID: <55D28DD3.1080301@oracle.com> Please approve this simple backport to jdk8u-dev Bug: https://bugs.openjdk.java.net/browse/JDK-8029453 Original Changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3e6c865104c Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015646.html The change applies cleanly. Thanks, David From sean.coffey at oracle.com Tue Aug 18 08:23:26 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 18 Aug 2015 09:23:26 +0100 Subject: [8u] Request for approval: 8029453: java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed by timeout In-Reply-To: <55D28DD3.1080301@oracle.com> References: <55D28CBC.9000601@oracle.com> <55D28DD3.1080301@oracle.com> Message-ID: <55D2EB7E.4050709@oracle.com> Approved for jdk8u-dev Regards, Sean. On 18/08/2015 02:43, David Holmes wrote: > Please approve this simple backport to jdk8u-dev > > Bug: https://bugs.openjdk.java.net/browse/JDK-8029453 > Original Changeset: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a3e6c865104c > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015646.html > > > The change applies cleanly. > > Thanks, > David > > > From sean.coffey at oracle.com Tue Aug 18 10:04:49 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 18 Aug 2015 11:04:49 +0100 Subject: Java DirectByteBuffer and OOM In-Reply-To: References: <55C8C313.3030501@redhat.com> <55C90331.7000304@oracle.com> Message-ID: <55D30341.5070800@oracle.com> Biju, Why don't you pull the patch into your own forest and build a local copy ? I could be a few weeks/months before this fix becomes public in an Oracle JDK release. Oracle jdk7u releases are no longer public. Last public one was 7u80. Regards, Sean. On 18/08/2015 00:21, Biju G.S Nair wrote: > Hi Ivan, > Since our applications are getting killed under load due to OOM, it will > be very helpful if we can get this patch back ported so that we can use > them immediately. I am not familiar with the process of how patches are > prioritized. Please let me know if I can do anything to get priority for > this patch. > > Thanks, > Biju > > On Tue, Aug 11, 2015 at 6:29 AM, Biju G.S Nair wrote: > >> Thank you Ivan for looking into the request. Hope the merge is pretty >> straight forward. >> >> Thanks, >> Biju >> >> On Mon, Aug 10, 2015 at 4:01 PM, Ivan Gerasimov >> wrote: >>> Hi Biju! >>> >>> I'll see if I can backport that change to jdk8u. >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 10.08.2015 19:57, Biju G.S Nair wrote: >>> >>>> Thanks Andrew for the response. >>>> >>>> Hi JDK8 development team, >>>> Could you please back port and merge the patch >>>> https://bugs.openjdk.java.net/browse/JDK-6857566 in JDK 8. This will >>>> help >>>> in resolving OOM issues in our applications which is using >>>> DirectByteBuffer. This will also help the JDK 7 dev team to merge the >>>> patch >>>> into their code base and that is the version we are using. >>>> >>>> Thanks, >>>> Biju >>>> >>>> >>>> >>>> Thanks, >>>> Biju >>>> >>>> On Mon, Aug 10, 2015 at 11:28 AM, Andrew Haley wrote: >>>> >>>> On 08/10/2015 04:25 PM, Biju G.S Nair wrote: >>>>>> Hi There, >>>>>> Our application is failing with unexpected OOM when using Java >>>>>> DirectByteBuffer and the fix >>>>>> https://bugs.openjdk.java.net/browse/JDK-6857566 currently merged to >>>>>> >>>>> JDK 9 >>>>> >>>>>> which includes a scaling sleep time should help us and may be others as >>>>>> well who are using JDK 7. Is there a way this patch can be back ported >>>>>> >>>>> and >>>>> >>>>>> merged into JDK 7 since the fix seems to be pretty straight forward. >>>>>> That >>>>>> will be very helpful and your response is much appreciated. >>>>>> >>>>> Yes, but it should be back-ported to JDK8u. It's not at all >>>>> conventional >>>>> to skip a JDK release. >>>>> >>>>> Andrew. >>>>> >>>>> >>>>> >>>>> From aleksej.efimov at oracle.com Tue Aug 18 10:29:28 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 18 Aug 2015 13:29:28 +0300 Subject: [8u-dev] Request for approval: 8133321: (tz) Support tzdata2015f Message-ID: <55D30908.8060902@oracle.com> Hello, Please, approve a backport of latest (2015f) tzdata integration to JDK8. The fix applies cleanly after reshuffling. Local and JPRT test runs showed no tz related failures on all platforms. With Best Regards, Aleksej JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1c0d6ff652c2 JDK9 review: http://mail.openjdk.java.net/pipermail/i18n-dev/2015-August/001731.html JBS: https://bugs.openjdk.java.net/browse/JDK-8133321 From sean.coffey at oracle.com Tue Aug 18 10:37:20 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 18 Aug 2015 11:37:20 +0100 Subject: [8u-dev] Request for approval: 8133321: (tz) Support tzdata2015f In-Reply-To: <55D30908.8060902@oracle.com> References: <55D30908.8060902@oracle.com> Message-ID: <55D30AE0.4070200@oracle.com> Approved. Regards, Sean. On 18/08/2015 11:29, Aleksej Efimov wrote: > Hello, > > Please, approve a backport of latest (2015f) tzdata integration to JDK8. > The fix applies cleanly after reshuffling. > Local and JPRT test runs showed no tz related failures on all platforms. > > With Best Regards, > Aleksej > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1c0d6ff652c2 > > JDK9 review: > http://mail.openjdk.java.net/pipermail/i18n-dev/2015-August/001731.html > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8133321 From aleksej.efimov at oracle.com Tue Aug 18 11:18:17 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 18 Aug 2015 14:18:17 +0300 Subject: [8u-dev] Request for approval: 8133321: (tz) Support tzdata2015f In-Reply-To: <55D30AE0.4070200@oracle.com> References: <55D30908.8060902@oracle.com> <55D30AE0.4070200@oracle.com> Message-ID: <55D31479.4090503@oracle.com> Thank you Sean! On 08/18/2015 01:37 PM, Se?n Coffey wrote: > Approved. > > Regards, > Sean. > > On 18/08/2015 11:29, Aleksej Efimov wrote: >> Hello, >> >> Please, approve a backport of latest (2015f) tzdata integration to JDK8. >> The fix applies cleanly after reshuffling. >> Local and JPRT test runs showed no tz related failures on all platforms. >> >> With Best Regards, >> Aleksej >> >> JDK9 changeset: >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1c0d6ff652c2 >> >> JDK9 review: >> http://mail.openjdk.java.net/pipermail/i18n-dev/2015-August/001731.html >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8133321 > From david.buck at oracle.com Tue Aug 18 16:21:50 2015 From: david.buck at oracle.com (david buck) Date: Wed, 19 Aug 2015 01:21:50 +0900 Subject: [8u-dev] RFA 8133666: OperatingSystemMXBean reports abnormally high machine CPU consumption on Linux Message-ID: <55D35B9E.10106@oracle.com> Hi! Please approve this trivial backport from jdk9 to jdk8. bug: https://bugs.openjdk.java.net/browse/JDK-8133666 jdk9 fix: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/d49f4e34e260 jdk9 review: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-August/017811.html The patch applies cleanly after reshuffling. After applying the patch, I will also update the copyright header for this year. Cheers, -Buck From sean.coffey at oracle.com Tue Aug 18 16:36:24 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 18 Aug 2015 17:36:24 +0100 Subject: [8u-dev] RFA 8133666: OperatingSystemMXBean reports abnormally high machine CPU consumption on Linux In-Reply-To: <55D35B9E.10106@oracle.com> References: <55D35B9E.10106@oracle.com> Message-ID: <55D35F08.4040800@oracle.com> Approved. Regards, Sean. On 18/08/2015 17:21, david buck wrote: > Hi! > > Please approve this trivial backport from jdk9 to jdk8. > > bug: https://bugs.openjdk.java.net/browse/JDK-8133666 > jdk9 fix: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/d49f4e34e260 > jdk9 review: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-August/017811.html > > The patch applies cleanly after reshuffling. After applying the patch, > I will also update the copyright header for this year. > > Cheers, > -Buck > From maurizio.cimadamore at oracle.com Tue Aug 18 16:54:19 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 18 Aug 2015 17:54:19 +0100 Subject: [8u] request for review: 8133659: Compiler fails to NullPointerException when calling super with Object<>() In-Reply-To: <55D1BF8A.4060404@oracle.com> References: <55D1BF8A.4060404@oracle.com> Message-ID: <55D3633B.6000206@oracle.com> Whoops - wrong subject on email (that's what I get for using cut and paste :-)) Maurizio On 17/08/15 12:03, Maurizio Cimadamore wrote: > Hi, > Please review the backport of bug: > > JDK-8133659: Compiler fails to NullPointerException when calling super > with Object<>() > > JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8065986 > backport: https://bugs.openjdk.java.net/browse/JDK-8133659 > original patch pushed to 9: > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/caa3490d5aee > public review: http://cr.openjdk.java.net/~mcimadamore/8133659/ > > The 9 patch doesn't apply cleanly to 8u because of the changes around > the Kind.java class (which has been converted into an enum in 9). > Changes are only superficial though. > > Thanks, > Maurizio From rob.mckenna at oracle.com Tue Aug 18 19:14:25 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 18 Aug 2015 20:14:25 +0100 Subject: [8u-communication] JDK 8u60 released today! (and 8u72 timeline) Message-ID: <55D38411.7080002@oracle.com> I'd like to announce that JDK 8u60 has become available for download today [0]. Thanks to all those who have contributed towards it. OpenJDK 8u60 source code is available via the 8u60 stabilization forest [1]. I plan to update the OpenJDK 8u project page with latest status and to also ask the OpenJDK ops team to mark the 8u60 forests as read-only. If you're packaging this release, it could be useful to let subscribed members know about it via communication on this mailing list. Please continue to contribute fixes back to the jdk8u-dev forest [2] which is already gathering changes for the next non-CPU JDK8u release. In addition to that the JDK 8u72 timeline page [3] has been published. Thanks, -Rob [0] http://www.oracle.com/technetwork/java/javase/downloads/index.html [1] http://hg.openjdk.java.net/jdk8u/jdk8u60/ [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev [3] http://openjdk.java.net/projects/jdk8u/releases/8u72.html From alexey.ivanov at oracle.com Wed Aug 19 14:03:09 2015 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 19 Aug 2015 17:03:09 +0300 Subject: [8u-dev] Request for approval for 8132850: java.lang.ArrayIndexOutOfBoundsException during text rendering with many fonts installed Message-ID: <55D48C9D.1090103@oracle.com> Hello, Could you please approve the following backport of the fix to 8u-dev? JBS: https://bugs.openjdk.java.net/browse/JDK-8132850 Webrev: http://cr.openjdk.java.net/~aivanov/8132850/jdk8/webrev.00/ The patch from JDK 9 applies cleanly after paths unshuffling. jdk9 webrev: http://cr.openjdk.java.net/~prr/8132850/ jdk9 review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005624.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b1d64eb06735 Thanks, Alexey From rob.mckenna at oracle.com Wed Aug 19 14:17:39 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 19 Aug 2015 15:17:39 +0100 Subject: [8u-dev] Request for approval for 8132850: java.lang.ArrayIndexOutOfBoundsException during text rendering with many fonts installed In-Reply-To: <55D48C9D.1090103@oracle.com> References: <55D48C9D.1090103@oracle.com> Message-ID: <55D49003.8040809@oracle.com> Approved -Rob On 19/08/15 15:03, Alexey Ivanov wrote: > Hello, > > Could you please approve the following backport of the fix to 8u-dev? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8132850 > Webrev: http://cr.openjdk.java.net/~aivanov/8132850/jdk8/webrev.00/ > > The patch from JDK 9 applies cleanly after paths unshuffling. > > jdk9 webrev: http://cr.openjdk.java.net/~prr/8132850/ > jdk9 review: > http://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005624.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b1d64eb06735 > > > Thanks, > Alexey From rkennke at redhat.com Wed Aug 19 14:57:48 2015 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 19 Aug 2015 16:57:48 +0200 Subject: Request for approval to backport: JDK-8133917 X11FontManager refactor Message-ID: <1439996268.22650.29.camel@redhat.com> This is a backport of: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8072436 It refactors X11FontManager such that the fontconfig specific parts go into its own superclass FcFontManager. It's needed for Caciocavallo, and probably useful for any non-X11 implementation that still wants to use fontconfig. The backport request is: https://bugs.openjdk.java.net/browse/JDK-8133917 The actual backport is: http://cr.openjdk.java.net/~rkennke/refactor-x11fm/webrev-jdk8u.00/ It is exactly the same change that has been applied to JDK9 and lived there for a while, except modules source path changes: http://cr.openjdk.java.net/~rkennke/refactor-x11fm/webrev.02/ Best regards, Roman From ivan.gerasimov at oracle.com Wed Aug 19 14:57:58 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Aug 2015 17:57:58 +0300 Subject: RFR/RFA (8u-dev) 8133253: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profile Message-ID: <55D49976.20908@oracle.com> Hi! The test FieldSetAccessibleTest.java fails when testing with compact3 even after fixing JDK-8080524. The reason is that the test tries to access classes which are only available in full jdk. The proposed fix is to include the test in the corresponding group in TEST.groups file. Would you please help review the fix and approve pushing it into jdk8u-dev repo? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8133253 WEBREV: http://cr.openjdk.java.net/~igerasim/8133253/00/webrev/ Sincerely yours, Ivan From gnu.andrew at redhat.com Wed Aug 19 15:12:33 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Aug 2015 11:12:33 -0400 (EDT) Subject: [8u-communication] JDK 8u60 released today! (and 8u72 timeline) In-Reply-To: <55D38411.7080002@oracle.com> References: <55D38411.7080002@oracle.com> Message-ID: <2132082391.12414344.1439997153546.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I'd like to announce that JDK 8u60 has become available for download > today [0]. Thanks to all those who have contributed towards it. > > OpenJDK 8u60 source code is available via the 8u60 stabilization forest > [1]. I plan to update the OpenJDK 8u project page with latest status > and to also ask the OpenJDK ops team to mark the 8u60 forests as read-only. > > If you're packaging this release, it could be useful to let subscribed > members know about it via communication on this mailing list. Please > continue to contribute fixes back to the jdk8u-dev forest [2] which is > already gathering changes for the next non-CPU JDK8u release. > > In addition to that the JDK 8u72 timeline page [3] has been published. > > Thanks, > > -Rob > > [0] http://www.oracle.com/technetwork/java/javase/downloads/index.html > [1] http://hg.openjdk.java.net/jdk8u/jdk8u60/ > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev > [3] http://openjdk.java.net/projects/jdk8u/releases/8u72.html > The 8u66 release page states that 8u66 should have forked for a stabilisation branch by now: http://openjdk.java.net/projects/jdk8u/releases/8u66.html But I don't see this on: http://hg.openjdk.java.net/jdk8u/jdk8u/ yet 8u72 tags have started appearing in jdk8u-dev. When will the 8u66 release branch appear? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From rob.mckenna at oracle.com Wed Aug 19 16:36:26 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 19 Aug 2015 17:36:26 +0100 Subject: Request for approval to backport: JDK-8133917 X11FontManager refactor In-Reply-To: <1439996268.22650.29.camel@redhat.com> References: <1439996268.22650.29.camel@redhat.com> Message-ID: <55D4B08A.2000708@oracle.com> Approved for 8u-dev -Rob On 19/08/15 15:57, Roman Kennke wrote: > This is a backport of: > > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8072436 > > It refactors X11FontManager such that the fontconfig specific parts go > into its own superclass FcFontManager. It's needed for Caciocavallo, > and probably useful for any non-X11 implementation that still wants to > use fontconfig. > > The backport request is: > https://bugs.openjdk.java.net/browse/JDK-8133917 > > The actual backport is: > http://cr.openjdk.java.net/~rkennke/refactor-x11fm/webrev-jdk8u.00/ > > It is exactly the same change that has been applied to JDK9 and lived > there for a while, except modules source path changes: > http://cr.openjdk.java.net/~rkennke/refactor-x11fm/webrev.02/ > > Best regards, > Roman > From ivan.gerasimov at oracle.com Wed Aug 19 17:09:53 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Aug 2015 20:09:53 +0300 Subject: [8u-dev] Request for approval to backport: 8022321, 6857566 Message-ID: <55D4B861.6030309@oracle.com> Hello! I'd like to backport these two fixes to jdk8u-dev: 8022321: java/lang/ref/OOMEInReferenceHandler.java fails intermittently 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation They should make usage of DirectByteBuffer more robust. Bugs: https://bugs.openjdk.java.net/browse/JDK-8022321 https://bugs.openjdk.java.net/browse/JDK-6857566 Jdk9 changes: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d04102f69d46 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9934d34ed3c0 Jdk9 reviewes: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024740.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/025266.html Would you please approve? Sincerely yours, Ivan From ivan.gerasimov at oracle.com Wed Aug 19 17:12:04 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Aug 2015 20:12:04 +0300 Subject: [8u-dev] Request for approval to backport: 8022321, 6857566 In-Reply-To: <55D4B861.6030309@oracle.com> References: <55D4B861.6030309@oracle.com> Message-ID: <55D4B8E4.7010000@oracle.com> And yes, the changes are applied cleanly when done in order :) On 19.08.2015 20:09, Ivan Gerasimov wrote: > Hello! > > I'd like to backport these two fixes to jdk8u-dev: > 8022321: java/lang/ref/OOMEInReferenceHandler.java fails intermittently > 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation > > They should make usage of DirectByteBuffer more robust. > > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8022321 > https://bugs.openjdk.java.net/browse/JDK-6857566 > Jdk9 changes: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d04102f69d46 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9934d34ed3c0 > Jdk9 reviewes: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024740.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/025266.html > > > Would you please approve? > > Sincerely yours, > Ivan > > From rob.mckenna at oracle.com Wed Aug 19 17:26:07 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 19 Aug 2015 18:26:07 +0100 Subject: [8u-communication] JDK 8u60 released today! (and 8u72 timeline) In-Reply-To: <2132082391.12414344.1439997153546.JavaMail.zimbra@redhat.com> References: <55D38411.7080002@oracle.com> <2132082391.12414344.1439997153546.JavaMail.zimbra@redhat.com> Message-ID: <55D4BC2F.3010407@oracle.com> Hi Andrew, As per Sean's earlier mail on release plans for 8 (http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html) we're using a similar approach for future JDK 8 Updates releases as was used for 7u76 and 7u72, with new releases accompanying corresponding CPU releases, as those releases did for 7u75 and 7u71. Just like the final phase of the JDK 7 Updates Project, that means there are no separate forests in our Mercurial repositories for those few remaining releases. Some folks may be wondering how they get fixes pushed into 8u66 so just to reiterate, all you have to do is follow the critical approval process [1] and the maintainers will take care of the rest! -Rob [1] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html On 19/08/15 16:12, Andrew Hughes wrote: > ----- Original Message ----- >> I'd like to announce that JDK 8u60 has become available for download >> today [0]. Thanks to all those who have contributed towards it. >> >> OpenJDK 8u60 source code is available via the 8u60 stabilization forest >> [1]. I plan to update the OpenJDK 8u project page with latest status >> and to also ask the OpenJDK ops team to mark the 8u60 forests as read-only. >> >> If you're packaging this release, it could be useful to let subscribed >> members know about it via communication on this mailing list. Please >> continue to contribute fixes back to the jdk8u-dev forest [2] which is >> already gathering changes for the next non-CPU JDK8u release. >> >> In addition to that the JDK 8u72 timeline page [3] has been published. >> >> Thanks, >> >> -Rob >> >> [0] http://www.oracle.com/technetwork/java/javase/downloads/index.html >> [1] http://hg.openjdk.java.net/jdk8u/jdk8u60/ >> [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev >> [3] http://openjdk.java.net/projects/jdk8u/releases/8u72.html >> > > The 8u66 release page states that 8u66 should have forked for a > stabilisation branch by now: > > http://openjdk.java.net/projects/jdk8u/releases/8u66.html > > But I don't see this on: > > http://hg.openjdk.java.net/jdk8u/jdk8u/ > > yet 8u72 tags have started appearing in jdk8u-dev. When will > the 8u66 release branch appear? > > Thanks, > From rob.mckenna at oracle.com Wed Aug 19 17:32:39 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 19 Aug 2015 18:32:39 +0100 Subject: [8u-dev] Request for approval to backport: 8022321, 6857566 In-Reply-To: <55D4B8E4.7010000@oracle.com> References: <55D4B861.6030309@oracle.com> <55D4B8E4.7010000@oracle.com> Message-ID: <55D4BDB7.8000206@oracle.com> Approved. -Rob On 19/08/15 18:12, Ivan Gerasimov wrote: > And yes, the changes are applied cleanly when done in order :) > > On 19.08.2015 20:09, Ivan Gerasimov wrote: >> Hello! >> >> I'd like to backport these two fixes to jdk8u-dev: >> 8022321: java/lang/ref/OOMEInReferenceHandler.java fails intermittently >> 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation >> >> They should make usage of DirectByteBuffer more robust. >> >> Bugs: >> https://bugs.openjdk.java.net/browse/JDK-8022321 >> https://bugs.openjdk.java.net/browse/JDK-6857566 >> Jdk9 changes: >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d04102f69d46 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9934d34ed3c0 >> Jdk9 reviewes: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024740.html >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/025266.html >> >> >> Would you please approve? >> >> Sincerely yours, >> Ivan >> >> > From rob.mckenna at oracle.com Wed Aug 19 17:33:27 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 19 Aug 2015 18:33:27 +0100 Subject: RFR/RFA (8u-dev) 8133253: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profile In-Reply-To: <55D49976.20908@oracle.com> References: <55D49976.20908@oracle.com> Message-ID: <55D4BDE7.2080506@oracle.com> Approved pending positive codrereview. -Rob On 19/08/15 15:57, Ivan Gerasimov wrote: > Hi! > > The test FieldSetAccessibleTest.java fails when testing with compact3 > even after fixing JDK-8080524. > The reason is that the test tries to access classes which are only > available in full jdk. > > The proposed fix is to include the test in the corresponding group in > TEST.groups file. > Would you please help review the fix and approve pushing it into > jdk8u-dev repo? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8133253 > WEBREV: http://cr.openjdk.java.net/~igerasim/8133253/00/webrev/ > > Sincerely yours, > Ivan From david.holmes at oracle.com Thu Aug 20 05:11:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Aug 2015 15:11:32 +1000 Subject: RFR/RFA (8u-dev) 8133253: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profile In-Reply-To: <55D49976.20908@oracle.com> References: <55D49976.20908@oracle.com> Message-ID: <55D56184.5040502@oracle.com> On 20/08/2015 12:57 AM, Ivan Gerasimov wrote: > Hi! > > The test FieldSetAccessibleTest.java fails when testing with compact3 > even after fixing JDK-8080524. Why wasn't that determined at the time? > The reason is that the test tries to access classes which are only > available in full jdk. > > The proposed fix is to include the test in the corresponding group in > TEST.groups file. Fix seems fine. Thanks, David > Would you please help review the fix and approve pushing it into > jdk8u-dev repo? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8133253 > WEBREV: http://cr.openjdk.java.net/~igerasim/8133253/00/webrev/ > > Sincerely yours, > Ivan From Alan.Bateman at oracle.com Thu Aug 20 06:11:26 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Aug 2015 07:11:26 +0100 Subject: RFR/RFA (8u-dev) 8133253: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profile In-Reply-To: <55D56184.5040502@oracle.com> References: <55D49976.20908@oracle.com> <55D56184.5040502@oracle.com> Message-ID: <55D56F8E.3030803@oracle.com> On 20/08/2015 06:11, David Holmes wrote: > On 20/08/2015 12:57 AM, Ivan Gerasimov wrote: >> Hi! >> >> The test FieldSetAccessibleTest.java fails when testing with compact3 >> even after fixing JDK-8080524. > > Why wasn't that determined at the time? I think the general issue is that this section of TEST.groups is not easy to maintain. New tests are added or being changed all the time and if the tests aren't also run continuously on compact profile builds then it might be some time before anyone notices. Hopefully we will soon be at the point where we can completely remove this section from the TEST.groups file and use the jtreg @modules support. -Alan From sean.coffey at oracle.com Thu Aug 20 10:09:47 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 20 Aug 2015 11:09:47 +0100 Subject: [8u-dev] : request for approval : 8034057 : Files.getFileStore and Files.isWritable do not work with SUBST'ed drives (win) Message-ID: <55D5A76B.4080804@oracle.com> I'd like to get this fix backported to jdk8u-dev. It came up as a request recently on the nio-dev mailing list : http://mail.openjdk.java.net/pipermail/nio-dev/2015-August/003288.html Fix applies cleanly post module path unshuffle. Test results are good. bug report : https://bugs.openjdk.java.net/browse/JDK-8034057 jdk 9 changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cda85444cad2 -- Regards, Sean. From dalibor.topic at oracle.com Thu Aug 20 10:20:40 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 20 Aug 2015 12:20:40 +0200 Subject: [8u-dev] : request for approval : 8034057 : Files.getFileStore and Files.isWritable do not work with SUBST'ed drives (win) In-Reply-To: <55D5A76B.4080804@oracle.com> References: <55D5A76B.4080804@oracle.com> Message-ID: <55D5A9F8.7090004@oracle.com> Approved. On 20.08.2015 12:09, Se?n Coffey wrote: > I'd like to get this fix backported to jdk8u-dev. It came up as a > request recently on the nio-dev mailing list : > http://mail.openjdk.java.net/pipermail/nio-dev/2015-August/003288.html > > Fix applies cleanly post module path unshuffle. Test results are good. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8034057 > jdk 9 changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/cda85444cad2 > -- 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, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From erik.joelsson at oracle.com Thu Aug 20 12:38:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Aug 2015 14:38:41 +0200 Subject: [8u-dev]: request for approval: 8034179: Clean up nio genConstants Message-ID: <55D5CA51.4050400@oracle.com> I'd like to get approval for backporting this change from JDK 9. It will help fix JDK-8132205. The patch applies cleanly. Bug report: https://bugs.openjdk.java.net/browse/JDK-8034179 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/88fb01f57ffa JDK 9 review: http://mail.openjdk.java.net/pipermail/build-dev/2014-February/011821.html /Erik From sean.coffey at oracle.com Thu Aug 20 13:43:09 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 20 Aug 2015 14:43:09 +0100 Subject: [8u-dev]: request for approval: 8034179: Clean up nio genConstants In-Reply-To: <55D5CA51.4050400@oracle.com> References: <55D5CA51.4050400@oracle.com> Message-ID: <55D5D96D.9060003@oracle.com> Approved. Looks like this needs a noreg-build label. Regards, Sean. On 20/08/2015 13:38, Erik Joelsson wrote: > I'd like to get approval for backporting this change from JDK 9. It > will help fix JDK-8132205. The patch applies cleanly. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8034179 > JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/88fb01f57ffa > JDK 9 review: > http://mail.openjdk.java.net/pipermail/build-dev/2014-February/011821.html > > /Erik From peter.brunet at oracle.com Thu Aug 20 20:43:42 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 20 Aug 2015 15:43:42 -0500 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown Message-ID: <55D63BFE.1050705@oracle.com> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b It will be the same fix with the path adjusted for the 8u to 9 restructuring. It's a simple patch: public Rectangle getBounds() { - return parent.getUI().getTabBounds(parent, - parent.indexOfTab(title)); + int i = parent.indexOfTab(title); + // Check for no title. Even though that's a bug in the app we should + // inhibit an ArrayIndexOutOfBoundsException from getTabBounds. + return (i == -1) ? null : parent.getUI().getTabBounds(parent, i); } Thanks, Pete From rob.mckenna at oracle.com Thu Aug 20 20:50:23 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 20 Aug 2015 21:50:23 +0100 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D63BFE.1050705@oracle.com> References: <55D63BFE.1050705@oracle.com> Message-ID: <55D63D8F.1000400@oracle.com> Approved for 8u-dev. Please add an appropriate noreg label. -Rob On 20/08/15 21:43, Pete Brunet wrote: > Requesting approval to backport the 9 fix for JDK-8133897 into 8u. > > 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 > 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 > 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b > > It will be the same fix with the path adjusted for the 8u to 9 > restructuring. > > It's a simple patch: > > public Rectangle getBounds() { > - return parent.getUI().getTabBounds(parent, > - parent.indexOfTab(title)); > + int i = parent.indexOfTab(title); > + // Check for no title. Even though that's a bug in the app > we should > + // inhibit an ArrayIndexOutOfBoundsException from getTabBounds. > + return (i == -1) ? null : > parent.getUI().getTabBounds(parent, i); > } > > Thanks, Pete > From peter.brunet at oracle.com Thu Aug 20 21:07:37 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 20 Aug 2015 16:07:37 -0500 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D63D8F.1000400@oracle.com> References: <55D63BFE.1050705@oracle.com> <55D63D8F.1000400@oracle.com> Message-ID: <55D64199.2070306@oracle.com> Hi Rob, I asked on the swing-dev list but didn't get an answer yet so maybe I can get one here. The question is if this simple fix qualifies for a noreg-trivial tag. Pete On 8/20/15 3:50 PM, Rob McKenna wrote: > Approved for 8u-dev. Please add an appropriate noreg label. > > -Rob > > On 20/08/15 21:43, Pete Brunet wrote: >> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. >> >> 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 >> 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 >> 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b >> >> It will be the same fix with the path adjusted for the 8u to 9 >> restructuring. >> >> It's a simple patch: >> >> public Rectangle getBounds() { >> - return parent.getUI().getTabBounds(parent, >> - >> parent.indexOfTab(title)); >> + int i = parent.indexOfTab(title); >> + // Check for no title. Even though that's a bug in the app >> we should >> + // inhibit an ArrayIndexOutOfBoundsException from >> getTabBounds. >> + return (i == -1) ? null : >> parent.getUI().getTabBounds(parent, i); >> } >> >> Thanks, Pete >> From rob.mckenna at oracle.com Thu Aug 20 21:24:29 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 20 Aug 2015 22:24:29 +0100 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D64199.2070306@oracle.com> References: <55D63BFE.1050705@oracle.com> <55D63D8F.1000400@oracle.com> <55D64199.2070306@oracle.com> Message-ID: <55D6458D.3040109@oracle.com> If it can be tested I'd say it should have a test. If not then noreg-hard. Is there a test for getBounds generally? Perhaps this could be added to it. -Rob On 20/08/15 22:07, Pete Brunet wrote: > Hi Rob, I asked on the swing-dev list but didn't get an answer yet so > maybe I can get one here. The question is if this simple fix qualifies > for a noreg-trivial tag. > > Pete > > On 8/20/15 3:50 PM, Rob McKenna wrote: >> Approved for 8u-dev. Please add an appropriate noreg label. >> >> -Rob >> >> On 20/08/15 21:43, Pete Brunet wrote: >>> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. >>> >>> 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 >>> 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 >>> 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b >>> >>> It will be the same fix with the path adjusted for the 8u to 9 >>> restructuring. >>> >>> It's a simple patch: >>> >>> public Rectangle getBounds() { >>> - return parent.getUI().getTabBounds(parent, >>> - >>> parent.indexOfTab(title)); >>> + int i = parent.indexOfTab(title); >>> + // Check for no title. Even though that's a bug in the app >>> we should >>> + // inhibit an ArrayIndexOutOfBoundsException from >>> getTabBounds. >>> + return (i == -1) ? null : >>> parent.getUI().getTabBounds(parent, i); >>> } >>> >>> Thanks, Pete >>> > From peter.brunet at oracle.com Thu Aug 20 21:27:19 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 20 Aug 2015 16:27:19 -0500 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D6458D.3040109@oracle.com> References: <55D63BFE.1050705@oracle.com> <55D63D8F.1000400@oracle.com> <55D64199.2070306@oracle.com> <55D6458D.3040109@oracle.com> Message-ID: <55D64637.5000602@oracle.com> Thanks Rob, I'll investigate and open another bug if I see that I can test it since 8133897 is already pushed/resolved. -Pete On 8/20/15 4:24 PM, Rob McKenna wrote: > If it can be tested I'd say it should have a test. If not then > noreg-hard. > > Is there a test for getBounds generally? Perhaps this could be added > to it. > > -Rob > > On 20/08/15 22:07, Pete Brunet wrote: >> Hi Rob, I asked on the swing-dev list but didn't get an answer yet so >> maybe I can get one here. The question is if this simple fix qualifies >> for a noreg-trivial tag. >> >> Pete >> >> On 8/20/15 3:50 PM, Rob McKenna wrote: >>> Approved for 8u-dev. Please add an appropriate noreg label. >>> >>> -Rob >>> >>> On 20/08/15 21:43, Pete Brunet wrote: >>>> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. >>>> >>>> 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 >>>> 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 >>>> 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b >>>> >>>> It will be the same fix with the path adjusted for the 8u to 9 >>>> restructuring. >>>> >>>> It's a simple patch: >>>> >>>> public Rectangle getBounds() { >>>> - return parent.getUI().getTabBounds(parent, >>>> - >>>> parent.indexOfTab(title)); >>>> + int i = parent.indexOfTab(title); >>>> + // Check for no title. Even though that's a bug in the >>>> app >>>> we should >>>> + // inhibit an ArrayIndexOutOfBoundsException from >>>> getTabBounds. >>>> + return (i == -1) ? null : >>>> parent.getUI().getTabBounds(parent, i); >>>> } >>>> >>>> Thanks, Pete >>>> >> From peter.brunet at oracle.com Thu Aug 20 21:36:08 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 20 Aug 2015 16:36:08 -0500 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D64637.5000602@oracle.com> References: <55D63BFE.1050705@oracle.com> <55D63D8F.1000400@oracle.com> <55D64199.2070306@oracle.com> <55D6458D.3040109@oracle.com> <55D64637.5000602@oracle.com> Message-ID: <55D64848.6010707@oracle.com> On 8/20/15 4:27 PM, Pete Brunet wrote: > Thanks Rob, I'll investigate and open another bug if I see that I can > test it since 8133897 is already pushed/resolved. -Pete unless there is a way to update the existing changeset? > > On 8/20/15 4:24 PM, Rob McKenna wrote: >> If it can be tested I'd say it should have a test. If not then >> noreg-hard. >> >> Is there a test for getBounds generally? Perhaps this could be added >> to it. >> >> -Rob >> >> On 20/08/15 22:07, Pete Brunet wrote: >>> Hi Rob, I asked on the swing-dev list but didn't get an answer yet so >>> maybe I can get one here. The question is if this simple fix qualifies >>> for a noreg-trivial tag. >>> >>> Pete >>> >>> On 8/20/15 3:50 PM, Rob McKenna wrote: >>>> Approved for 8u-dev. Please add an appropriate noreg label. >>>> >>>> -Rob >>>> >>>> On 20/08/15 21:43, Pete Brunet wrote: >>>>> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. >>>>> >>>>> 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 >>>>> 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 >>>>> 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b >>>>> >>>>> It will be the same fix with the path adjusted for the 8u to 9 >>>>> restructuring. >>>>> >>>>> It's a simple patch: >>>>> >>>>> public Rectangle getBounds() { >>>>> - return parent.getUI().getTabBounds(parent, >>>>> - >>>>> parent.indexOfTab(title)); >>>>> + int i = parent.indexOfTab(title); >>>>> + // Check for no title. Even though that's a bug in the >>>>> app >>>>> we should >>>>> + // inhibit an ArrayIndexOutOfBoundsException from >>>>> getTabBounds. >>>>> + return (i == -1) ? null : >>>>> parent.getUI().getTabBounds(parent, i); >>>>> } >>>>> >>>>> Thanks, Pete >>>>> From peter.brunet at oracle.com Thu Aug 20 22:06:11 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 20 Aug 2015 17:06:11 -0500 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D64848.6010707@oracle.com> References: <55D63BFE.1050705@oracle.com> <55D63D8F.1000400@oracle.com> <55D64199.2070306@oracle.com> <55D6458D.3040109@oracle.com> <55D64637.5000602@oracle.com> <55D64848.6010707@oracle.com> Message-ID: <55D64F53.3010700@oracle.com> On 8/20/15 4:36 PM, Pete Brunet wrote: > > On 8/20/15 4:27 PM, Pete Brunet wrote: >> Thanks Rob, I'll investigate and open another bug if I see that I can >> test it since 8133897 is already pushed/resolved. -Pete > unless there is a way to update the existing changeset? or update an existing resolved bug with an additional changeset? >> On 8/20/15 4:24 PM, Rob McKenna wrote: >>> If it can be tested I'd say it should have a test. If not then >>> noreg-hard. >>> >>> Is there a test for getBounds generally? Perhaps this could be added >>> to it. >>> >>> -Rob >>> >>> On 20/08/15 22:07, Pete Brunet wrote: >>>> Hi Rob, I asked on the swing-dev list but didn't get an answer yet so >>>> maybe I can get one here. The question is if this simple fix qualifies >>>> for a noreg-trivial tag. >>>> >>>> Pete >>>> >>>> On 8/20/15 3:50 PM, Rob McKenna wrote: >>>>> Approved for 8u-dev. Please add an appropriate noreg label. >>>>> >>>>> -Rob >>>>> >>>>> On 20/08/15 21:43, Pete Brunet wrote: >>>>>> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. >>>>>> >>>>>> 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 >>>>>> 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 >>>>>> 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b >>>>>> >>>>>> It will be the same fix with the path adjusted for the 8u to 9 >>>>>> restructuring. >>>>>> >>>>>> It's a simple patch: >>>>>> >>>>>> public Rectangle getBounds() { >>>>>> - return parent.getUI().getTabBounds(parent, >>>>>> - >>>>>> parent.indexOfTab(title)); >>>>>> + int i = parent.indexOfTab(title); >>>>>> + // Check for no title. Even though that's a bug in the >>>>>> app >>>>>> we should >>>>>> + // inhibit an ArrayIndexOutOfBoundsException from >>>>>> getTabBounds. >>>>>> + return (i == -1) ? null : >>>>>> parent.getUI().getTabBounds(parent, i); >>>>>> } >>>>>> >>>>>> Thanks, Pete >>>>>> From rob.mckenna at oracle.com Thu Aug 20 22:08:13 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 20 Aug 2015 23:08:13 +0100 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D64F53.3010700@oracle.com> References: <55D63BFE.1050705@oracle.com> <55D63D8F.1000400@oracle.com> <55D64199.2070306@oracle.com> <55D6458D.3040109@oracle.com> <55D64637.5000602@oracle.com> <55D64848.6010707@oracle.com> <55D64F53.3010700@oracle.com> Message-ID: <55D64FCD.4070809@oracle.com> Nope, new bug is the way to go. -Rob On 20/08/15 23:06, Pete Brunet wrote: > > > On 8/20/15 4:36 PM, Pete Brunet wrote: >> >> On 8/20/15 4:27 PM, Pete Brunet wrote: >>> Thanks Rob, I'll investigate and open another bug if I see that I can >>> test it since 8133897 is already pushed/resolved. -Pete >> unless there is a way to update the existing changeset? > or update an existing resolved bug with an additional changeset? >>> On 8/20/15 4:24 PM, Rob McKenna wrote: >>>> If it can be tested I'd say it should have a test. If not then >>>> noreg-hard. >>>> >>>> Is there a test for getBounds generally? Perhaps this could be added >>>> to it. >>>> >>>> -Rob >>>> >>>> On 20/08/15 22:07, Pete Brunet wrote: >>>>> Hi Rob, I asked on the swing-dev list but didn't get an answer yet so >>>>> maybe I can get one here. The question is if this simple fix qualifies >>>>> for a noreg-trivial tag. >>>>> >>>>> Pete >>>>> >>>>> On 8/20/15 3:50 PM, Rob McKenna wrote: >>>>>> Approved for 8u-dev. Please add an appropriate noreg label. >>>>>> >>>>>> -Rob >>>>>> >>>>>> On 20/08/15 21:43, Pete Brunet wrote: >>>>>>> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. >>>>>>> >>>>>>> 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 >>>>>>> 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 >>>>>>> 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b >>>>>>> >>>>>>> It will be the same fix with the path adjusted for the 8u to 9 >>>>>>> restructuring. >>>>>>> >>>>>>> It's a simple patch: >>>>>>> >>>>>>> public Rectangle getBounds() { >>>>>>> - return parent.getUI().getTabBounds(parent, >>>>>>> - >>>>>>> parent.indexOfTab(title)); >>>>>>> + int i = parent.indexOfTab(title); >>>>>>> + // Check for no title. Even though that's a bug in the >>>>>>> app >>>>>>> we should >>>>>>> + // inhibit an ArrayIndexOutOfBoundsException from >>>>>>> getTabBounds. >>>>>>> + return (i == -1) ? null : >>>>>>> parent.getUI().getTabBounds(parent, i); >>>>>>> } >>>>>>> >>>>>>> Thanks, Pete >>>>>>> > From Sergey.Bylokhov at oracle.com Fri Aug 21 09:34:19 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 21 Aug 2015 12:34:19 +0300 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D63BFE.1050705@oracle.com> References: <55D63BFE.1050705@oracle.com> Message-ID: <55D6F09B.4080800@oracle.com> HI, Pete. This request should be rejected since the fix to jdk9 was pushed without approvals. As far as I understand discussion on the swing-dev alias still in progress. On 20.08.15 23:43, Pete Brunet wrote: > Requesting approval to backport the 9 fix for JDK-8133897 into 8u. > > 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 > 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 > 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b > > It will be the same fix with the path adjusted for the 8u to 9 > restructuring. > > It's a simple patch: > > public Rectangle getBounds() { > - return parent.getUI().getTabBounds(parent, > - parent.indexOfTab(title)); > + int i = parent.indexOfTab(title); > + // Check for no title. Even though that's a bug in the app > we should > + // inhibit an ArrayIndexOutOfBoundsException from getTabBounds. > + return (i == -1) ? null : > parent.getUI().getTabBounds(parent, i); > } > > Thanks, Pete > -- Best regards, Sergey. From rob.mckenna at oracle.com Fri Aug 21 12:55:34 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 21 Aug 2015 13:55:34 +0100 Subject: [8u-dev] Request for approval - 8071291: Compiler crashes trying to cast UnionType to IntersectionClassType Message-ID: <55D71FC6.1000403@oracle.com> Hi folks, I'd like to backport this fix to 8: Bug: https://bugs.openjdk.java.net/browse/JDK-8071291 Webrev: http://cr.openjdk.java.net/~robm/8071291/webrev/ Review: http://mail.openjdk.java.net/pipermail/compiler-dev/2015-August/009746.html -Rob From sean.coffey at oracle.com Fri Aug 21 13:16:51 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 21 Aug 2015 14:16:51 +0100 Subject: [8u-dev] Request for approval - 8071291: Compiler crashes trying to cast UnionType to IntersectionClassType In-Reply-To: <55D71FC6.1000403@oracle.com> References: <55D71FC6.1000403@oracle.com> Message-ID: <55D724C3.8080800@oracle.com> Approved. Regards, Sean. On 21/08/15 13:55, Rob McKenna wrote: > Hi folks, I'd like to backport this fix to 8: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8071291 > Webrev: http://cr.openjdk.java.net/~robm/8071291/webrev/ > Review: > http://mail.openjdk.java.net/pipermail/compiler-dev/2015-August/009746.html > > -Rob From peter.brunet at oracle.com Fri Aug 21 13:27:28 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 21 Aug 2015 08:27:28 -0500 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D6F09B.4080800@oracle.com> References: <55D63BFE.1050705@oracle.com> <55D6F09B.4080800@oracle.com> Message-ID: <55D72740.1090905@oracle.com> Hi Sergery, Did you mean "pushed without approvals" or "pushed without approved reviews"? Do we now need approvals for pushes into 9 client? I received two +1s on my RfR before pushing the patch. The related discussion was not about the patch but about how the bug might have been exposed in the first place. The only issue I have right now (other than possibly the issue you raised about an RfA vs RfR approval) is that I need to create a regression test. I am working on that, JDK-8134116. Pete On 8/21/15 4:34 AM, Sergey Bylokhov wrote: > HI, Pete. > This request should be rejected since the fix to jdk9 was pushed > without approvals. As far as I understand discussion on the swing-dev > alias still in progress. > > On 20.08.15 23:43, Pete Brunet wrote: >> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. >> >> 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 >> 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 >> 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b >> >> It will be the same fix with the path adjusted for the 8u to 9 >> restructuring. >> >> It's a simple patch: >> >> public Rectangle getBounds() { >> - return parent.getUI().getTabBounds(parent, >> - >> parent.indexOfTab(title)); >> + int i = parent.indexOfTab(title); >> + // Check for no title. Even though that's a bug in the app >> we should >> + // inhibit an ArrayIndexOutOfBoundsException from >> getTabBounds. >> + return (i == -1) ? null : >> parent.getUI().getTabBounds(parent, i); >> } >> >> Thanks, Pete >> > > From peter.brunet at oracle.com Fri Aug 21 13:34:02 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 21 Aug 2015 08:34:02 -0500 Subject: RfA: JDK-8133897, ACC: IndexOutOfBounds exception being thrown In-Reply-To: <55D72740.1090905@oracle.com> References: <55D63BFE.1050705@oracle.com> <55D6F09B.4080800@oracle.com> <55D72740.1090905@oracle.com> Message-ID: <55D728CA.6050105@oracle.com> On 8/21/15 8:27 AM, Pete Brunet wrote: > Hi Sergery, Did you mean "pushed without approvals" or "pushed without > approved reviews"? Do we now need approvals for pushes into 9 client? > > I received two +1s on my RfR before pushing the patch. The related > discussion was not about the patch but about how the bug might have been > exposed in the first place. My apologies - I misread my emails and did not get two approvals for the RfR. > > The only issue I have right now (other than possibly the issue you > raised about an RfA vs RfR approval) is that I need to create a > regression test. I am working on that, JDK-8134116. > > Pete > > On 8/21/15 4:34 AM, Sergey Bylokhov wrote: >> HI, Pete. >> This request should be rejected since the fix to jdk9 was pushed >> without approvals. As far as I understand discussion on the swing-dev >> alias still in progress. >> >> On 20.08.15 23:43, Pete Brunet wrote: >>> Requesting approval to backport the 9 fix for JDK-8133897 into 8u. >>> >>> 9 Bug: https://bugs.openjdk.java.net/browse/JDK-8133897 >>> 8u backport bug: https://bugs.openjdk.java.net/browse/JDK-8134001 >>> 9 Fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9cad345fb47b >>> >>> It will be the same fix with the path adjusted for the 8u to 9 >>> restructuring. >>> >>> It's a simple patch: >>> >>> public Rectangle getBounds() { >>> - return parent.getUI().getTabBounds(parent, >>> - >>> parent.indexOfTab(title)); >>> + int i = parent.indexOfTab(title); >>> + // Check for no title. Even though that's a bug in the app >>> we should >>> + // inhibit an ArrayIndexOutOfBoundsException from >>> getTabBounds. >>> + return (i == -1) ? null : >>> parent.getUI().getTabBounds(parent, i); >>> } >>> >>> Thanks, Pete >>> >> From ivan.gerasimov at oracle.com Fri Aug 21 17:27:05 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 21 Aug 2015 20:27:05 +0300 Subject: Java DirectByteBuffer and OOM In-Reply-To: References: <55C8C313.3030501@redhat.com> <55C90331.7000304@oracle.com> Message-ID: <55D75F69.5070509@oracle.com> Hi Biju! FYI, the fix was backported to jdk8u with the following two changes: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3d7b2dfd922c http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/dcc009356125 Please note that currently we've got no plans to backport this to earlier releases of jdk. Sincerely yours, Ivan On 11.08.2015 13:29, Biju G.S Nair wrote: > Thank you Ivan for looking into the request. Hope the merge is pretty > straight forward. > > Thanks, > Biju > > On Mon, Aug 10, 2015 at 4:01 PM, Ivan Gerasimov > > wrote: > > Hi Biju! > > I'll see if I can backport that change to jdk8u. > > Sincerely yours, > Ivan > > > On 10.08.2015 19:57, Biju G.S Nair wrote: > > Thanks Andrew for the response. > > Hi JDK8 development team, > Could you please back port and merge the patch > https://bugs.openjdk.java.net/browse/JDK-6857566 in JDK 8. > This will help > in resolving OOM issues in our applications which is using > DirectByteBuffer. This will also help the JDK 7 dev team to > merge the patch > into their code base and that is the version we are using. > > Thanks, > Biju > > > > Thanks, > Biju > > On Mon, Aug 10, 2015 at 11:28 AM, Andrew Haley > wrote: > > On 08/10/2015 04:25 PM, Biju G.S Nair wrote: > > Hi There, > Our application is failing with unexpected OOM > when using Java > DirectByteBuffer and the fix > https://bugs.openjdk.java.net/browse/JDK-6857566 > currently merged to > > JDK 9 > > which includes a scaling sleep time should help us and > may be others as > well who are using JDK 7. Is there a way this patch > can be back ported > > and > > merged into JDK 7 since the fix seems to be pretty > straight forward. That > will be very helpful and your response is much > appreciated. > > Yes, but it should be back-ported to JDK8u. It's not at > all conventional > to skip a JDK release. > > Andrew. > > > > > > From rob.mckenna at oracle.com Mon Aug 24 20:38:22 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 24 Aug 2015 21:38:22 +0100 Subject: Request for Approval: JDK-8075584: [TESTBUG] test for 8067364 depends on hardwired text advance In-Reply-To: <1439285391.24713.4.camel@galactica.localdomain> References: <1439285391.24713.4.camel@galactica.localdomain> Message-ID: <55DB80BE.6030500@oracle.com> Approved. Sorry, this passed me by. -Rob On 11/08/15 10:29, Mario Torre wrote: > Hi all! > > I would like to backport the fix for JDK-8075584 into the jdk8u-dev > repository if possible. > > The patch is exactly the same as the one committed on the jdk9 client > repository, applies with no modifications: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/f45d4e52e7e2 > > There is already a backport request created and linked to the main bug: > JDK-8075585 > > Cheers, > Mario > > From rob.mckenna at oracle.com Tue Aug 25 15:32:04 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 25 Aug 2015 16:32:04 +0100 Subject: [8u-dev] Request for approval - 8087190: Regression in sun.net.util.IPAddressUtil.isIPv4LiteralAddress(String) Message-ID: <55DC8A74.50603@oracle.com> Hi folks, Looking to backport this simple change. (the fix applies cleanly post shuffle) https://bugs.openjdk.java.net/browse/JDK-8087190 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cdd4d5fedb9c http://mail.openjdk.java.net/pipermail/net-dev/2015-August/009072.html -Rob From sean.coffey at oracle.com Tue Aug 25 15:35:23 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 25 Aug 2015 16:35:23 +0100 Subject: [8u-dev] Request for approval - 8087190: Regression in sun.net.util.IPAddressUtil.isIPv4LiteralAddress(String) In-Reply-To: <55DC8A74.50603@oracle.com> References: <55DC8A74.50603@oracle.com> Message-ID: <55DC8B3B.3070207@oracle.com> Approved. Regards, Sean. On 25/08/2015 16:32, Rob McKenna wrote: > Hi folks, > > Looking to backport this simple change. (the fix applies cleanly post > shuffle) > > https://bugs.openjdk.java.net/browse/JDK-8087190 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cdd4d5fedb9c > http://mail.openjdk.java.net/pipermail/net-dev/2015-August/009072.html > > -Rob From neugens at redhat.com Wed Aug 26 13:46:42 2015 From: neugens at redhat.com (Mario Torre) Date: Wed, 26 Aug 2015 15:46:42 +0200 Subject: Request for Approval: JDK-8075584: [TESTBUG] test for 8067364 depends on hardwired text advance In-Reply-To: <1439285391.24713.4.camel@galactica.localdomain> References: <1439285391.24713.4.camel@galactica.localdomain> Message-ID: <1440596802.5250.57.camel@galactica.localdomain> On Tue, 2015-08-11 at 11:29 +0200, Mario Torre wrote: > Hi all! > > I would like to backport the fix for JDK-8075584 into the jdk8u-dev > repository if possible. > > The patch is exactly the same as the one committed on the jdk9 client > repository, applies with no modifications: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/f45d4e52e7e2 > > There is already a backport request created and linked to the main bug: > JDK-8075585 Ping? Cheers, Mario From dalibor.topic at oracle.com Wed Aug 26 15:57:24 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 26 Aug 2015 17:57:24 +0200 Subject: Request for Approval: JDK-8075584: [TESTBUG] test for 8067364 depends on hardwired text advance In-Reply-To: <1440596802.5250.57.camel@galactica.localdomain> References: <1439285391.24713.4.camel@galactica.localdomain> <1440596802.5250.57.camel@galactica.localdomain> Message-ID: <55DDE1E4.5050909@oracle.com> Hi Mario, It is approved for jdk8u-dev: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-August/004157.html . cheers, dalibor topic On 26.08.2015 15:46, Mario Torre wrote: > On Tue, 2015-08-11 at 11:29 +0200, Mario Torre wrote: >> Hi all! >> >> I would like to backport the fix for JDK-8075584 into the jdk8u-dev >> repository if possible. >> >> The patch is exactly the same as the one committed on the jdk9 client >> repository, applies with no modifications: >> >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/f45d4e52e7e2 >> >> There is already a backport request created and linked to the main bug: >> JDK-8075585 > > Ping? > > Cheers, > Mario > > -- 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, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From gnu.andrew at redhat.com Wed Aug 26 16:31:45 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Aug 2015 12:31:45 -0400 (EDT) Subject: [8u-communication] JDK 8u60 released today! (and 8u72 timeline) In-Reply-To: <55D4BC2F.3010407@oracle.com> References: <55D38411.7080002@oracle.com> <2132082391.12414344.1439997153546.JavaMail.zimbra@redhat.com> <55D4BC2F.3010407@oracle.com> Message-ID: <1873269103.1638751.1440606705141.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Andrew, > > As per Sean's earlier mail on release plans for 8 > (http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html) > we're using a similar approach for future JDK 8 Updates releases as was > used for 7u76 and 7u72, with new releases accompanying corresponding CPU > releases, as those releases did for 7u75 and 7u71. Yes, I've seen this. It doesn't explain why the 8u66 page [0] says 'Fork for the stabilization forests' if you don't plan to do so. Is this a mistake? > > Just like the final phase of the JDK 7 Updates Project, that means there > are no separate forests in our Mercurial repositories for those few > remaining releases. But 8 is hardly in final stages. It's currently the only supported OpenJDK release; there is nothing after it yet. If a bug needs to be fixed, it has to go in 8 as a minimum in order to get to end-users. If OpenJDK 8 is being supported until at least September 2017 [1], then there will be at least 16 releases (8 CPUs with two releases per CPU). I don't think that meets anyone's definition of 'a few'. > > Some folks may be wondering how they get fixes pushed into 8u66 so just > to reiterate, all you have to do is follow the critical approval process > [1] and the maintainers will take care of the rest! This document still refers to a 'dedicated (stabilization) jdk8u$N forest'. But you've said this won't be created going forward? It seems that some of this documentation needs updating. > > -Rob > [0] http://openjdk.java.net/projects/jdk8u/releases/8u66.html [1] http://www.oracle.com/technetwork/java/eol-135779.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From attila.szegedi at oracle.com Wed Aug 26 18:51:38 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 26 Aug 2015 20:51:38 +0200 Subject: [8u-dev] Request for Approval: 8134403: Nashorn react.js benchmark performance regression Message-ID: <1485E884-1856-49B1-A11F-1B2A3384BA45@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8134403 jdk9 webrev: http://cr.openjdk.java.net/~attila/8134403/webrev.jdk9 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005082.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From rob.mckenna at oracle.com Wed Aug 26 19:26:40 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 26 Aug 2015 20:26:40 +0100 Subject: [8u-dev] Request for Approval: 8134403: Nashorn react.js benchmark performance regression In-Reply-To: <1485E884-1856-49B1-A11F-1B2A3384BA45@oracle.com> References: <1485E884-1856-49B1-A11F-1B2A3384BA45@oracle.com> Message-ID: <55DE12F0.8080801@oracle.com> Approved. -Rob On 26/08/15 19:51, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134403 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8134403/webrev.jdk9 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005082.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. > From neugens at redhat.com Thu Aug 27 11:29:43 2015 From: neugens at redhat.com (Mario Torre) Date: Thu, 27 Aug 2015 13:29:43 +0200 Subject: Request for Approval: JDK-8075584: [TESTBUG] test for 8067364 depends on hardwired text advance In-Reply-To: <55DDE1E4.5050909@oracle.com> References: <1439285391.24713.4.camel@galactica.localdomain> <1440596802.5250.57.camel@galactica.localdomain> <55DDE1E4.5050909@oracle.com> Message-ID: <1440674983.5250.86.camel@galactica.localdomain> On Wed, 2015-08-26 at 17:57 +0200, dalibor topic wrote: > Hi Mario, > > It is approved for jdk8u-dev: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-August/004157.html . Thanks Dalibor and Rob, Somehow I didn't see the previous mail, I must have some troubles with my email filters... The fix is now in for jdk8u-dev. Cheers, Mario From ivan.gerasimov at oracle.com Thu Aug 27 17:11:47 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 27 Aug 2015 20:11:47 +0300 Subject: [8u-dev] Request for approval to backport: 8030785, 8134356 Message-ID: <55DF44D3.8070603@oracle.com> Hi! Would you please approve backporting this two java-doc only fixes? 8030785: @since 1.8 tag was missed in a couple of places, so it would be logical to fix this in jdk8 repo. 8134356: cleanup in @code blocks If the javadoc is ever regenerated for jdk8, it would be nice to have these fixes in. Bugs: https://bugs.openjdk.java.net/browse/JDK-8030785 https://bugs.openjdk.java.net/browse/JDK-8134356 Jdk9 changes: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b42d9d8d0689 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/676296719391 Reviews: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024093.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034976.html The patches apply cleanly after unshuffling. Sincerely yours, Ivan From rob.mckenna at oracle.com Thu Aug 27 17:21:33 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 27 Aug 2015 18:21:33 +0100 Subject: [8u-dev] Request for approval to backport: 8030785, 8134356 In-Reply-To: <55DF44D3.8070603@oracle.com> References: <55DF44D3.8070603@oracle.com> Message-ID: <55DF471D.7050004@oracle.com> Approved. Please add an appropriate noreg label to 8134356. -Rob On 27/08/15 18:11, Ivan Gerasimov wrote: > Hi! > > Would you please approve backporting this two java-doc only fixes? > 8030785: @since 1.8 tag was missed in a couple of places, so it would be > logical to fix this in jdk8 repo. > 8134356: cleanup in @code blocks > > If the javadoc is ever regenerated for jdk8, it would be nice to have > these fixes in. > > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8030785 > https://bugs.openjdk.java.net/browse/JDK-8134356 > Jdk9 changes: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b42d9d8d0689 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/676296719391 > Reviews: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024093.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034976.html > > > The patches apply cleanly after unshuffling. > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Thu Aug 27 17:34:59 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 27 Aug 2015 20:34:59 +0300 Subject: [8u-dev] Request for approval to backport: 8030785, 8134356 In-Reply-To: <55DF471D.7050004@oracle.com> References: <55DF44D3.8070603@oracle.com> <55DF471D.7050004@oracle.com> Message-ID: <55DF4A43.7050807@oracle.com> On 27.08.2015 20:21, Rob McKenna wrote: > Approved. Please add an appropriate noreg label to 8134356. > Thanks! Will do. Sincerely yours, Ivan > -Rob > > On 27/08/15 18:11, Ivan Gerasimov wrote: >> Hi! >> >> Would you please approve backporting this two java-doc only fixes? >> 8030785: @since 1.8 tag was missed in a couple of places, so it would be >> logical to fix this in jdk8 repo. >> 8134356: cleanup in @code blocks >> >> If the javadoc is ever regenerated for jdk8, it would be nice to have >> these fixes in. >> >> Bugs: >> https://bugs.openjdk.java.net/browse/JDK-8030785 >> https://bugs.openjdk.java.net/browse/JDK-8134356 >> Jdk9 changes: >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b42d9d8d0689 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/676296719391 >> Reviews: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024093.html >> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034976.html >> >> >> >> The patches apply cleanly after unshuffling. >> >> Sincerely yours, >> Ivan >> > From rob.mckenna at oracle.com Thu Aug 27 20:31:53 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 27 Aug 2015 21:31:53 +0100 Subject: [8u-communication] JDK 8u60 released today! (and 8u72 timeline) In-Reply-To: <1873269103.1638751.1440606705141.JavaMail.zimbra@redhat.com> References: <55D38411.7080002@oracle.com> <2132082391.12414344.1439997153546.JavaMail.zimbra@redhat.com> <55D4BC2F.3010407@oracle.com> <1873269103.1638751.1440606705141.JavaMail.zimbra@redhat.com> Message-ID: <55DF73B9.7020204@oracle.com> On 26/08/15 17:31, Andrew Hughes wrote: > ----- Original Message ----- >> Hi Andrew, >> >> As per Sean's earlier mail on release plans for 8 >> (http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html) >> we're using a similar approach for future JDK 8 Updates releases as was >> used for 7u76 and 7u72, with new releases accompanying corresponding CPU >> releases, as those releases did for 7u75 and 7u71. > > Yes, I've seen this. It doesn't explain why the 8u66 page [0] says > 'Fork for the stabilization forests' if you don't plan to do so. > Is this a mistake? Good point. I've just pushed a change to the 8u documentation that removes that out-of-date terminology. Thanks. > >> >> Just like the final phase of the JDK 7 Updates Project, that means there >> are no separate forests in our Mercurial repositories for those few >> remaining releases. > > But 8 is hardly in final stages. No, but its still just like the final phase of the 7 updates project :) > It's currently the only supported OpenJDK > release; there is nothing after it yet. If a bug needs to be fixed, it has > to go in 8 as a minimum in order to get to end-users. > > If OpenJDK 8 is being supported until at least September 2017 [1], > then there will be at least 16 releases (8 CPUs with two releases per CPU). > I don't think that meets anyone's definition of 'a few'. Technically correct. Subjectively I tend to combine the CPU/PSUs into a single release. (so I was counting 8) It may not meet the definition of "a few", but I don't think it qualifies as "many" either! -Rob > >> >> Some folks may be wondering how they get fixes pushed into 8u66 so just >> to reiterate, all you have to do is follow the critical approval process >> [1] and the maintainers will take care of the rest! > > This document still refers to a 'dedicated (stabilization) jdk8u$N forest'. > But you've said this won't be created going forward? > > It seems that some of this documentation needs updating. > >> >> -Rob >> > > [0] http://openjdk.java.net/projects/jdk8u/releases/8u66.html > [1] http://www.oracle.com/technetwork/java/eol-135779.html > From michael.haupt at oracle.com Fri Aug 28 08:05:49 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 28 Aug 2015 10:05:49 +0200 Subject: [8u60] Request for Approval: 8073613: Here documents Message-ID: <3F15AEDF-194B-44E2-A2D8-A1ED2BB7221E@oracle.com> Dear all, please approve this backport request. Bug: https://bugs.openjdk.java.net/browse/JDK-8073613 jdk9 webrev: http://cr.openjdk.java.net/~mhaupt/8073613/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005075.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Fri Aug 28 08:05:52 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 28 Aug 2015 10:05:52 +0200 Subject: [8u60] Request for Approval: 8134484: disallow backquotes as heredoc end marker delimiters Message-ID: <84DFA77A-934A-45ED-A0DB-CD02C81B6C32@oracle.com> Dear all, please approve this backport request. Bug: https://bugs.openjdk.java.net/browse/JDK-8134484 jdk9 webrev: http://cr.openjdk.java.net/~mhaupt/8134484/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005078.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Fri Aug 28 12:22:35 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 28 Aug 2015 14:22:35 +0200 Subject: [8u-dev] Request for Approval: 8073613: Here documents Message-ID: Dear all, please approve this backport request. Bug: https://bugs.openjdk.java.net/browse/JDK-8073613 jdk9 webrev: http://cr.openjdk.java.net/~mhaupt/8073613/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005075.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Fri Aug 28 12:23:09 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 28 Aug 2015 14:23:09 +0200 Subject: [8u-dev] Request for Approval: 8134484: disallow backquotes as heredoc end marker delimiters Message-ID: Dear all, please approve this backport request. Bug: https://bugs.openjdk.java.net/browse/JDK-8134484 jdk9 webrev: http://cr.openjdk.java.net/~mhaupt/8134484/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005078.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Fri Aug 28 12:26:19 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 28 Aug 2015 14:26:19 +0200 Subject: [8u60] Request for Approval: 8134484: disallow backquotes as heredoc end marker delimiters In-Reply-To: <84DFA77A-934A-45ED-A0DB-CD02C81B6C32@oracle.com> References: <84DFA77A-934A-45ED-A0DB-CD02C81B6C32@oracle.com> Message-ID: ... please disregard this message as it was sent with the wrong subject line. Michael > Am 28.08.2015 um 10:05 schrieb Michael Haupt : > > Dear all, > > please approve this backport request. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134484 > jdk9 webrev: http://cr.openjdk.java.net/~mhaupt/8134484/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005078.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > > Michael > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From rob.mckenna at oracle.com Fri Aug 28 12:40:29 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 28 Aug 2015 13:40:29 +0100 Subject: [8u-dev] Request for Approval: 8073613: Here documents In-Reply-To: References: Message-ID: <55E056BD.60605@oracle.com> Approved. -Rob On 28/08/15 13:22, Michael Haupt wrote: > Dear all, > > please approve this backport request. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073613 > jdk9 webrev: http://cr.openjdk.java.net/~mhaupt/8073613/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005075.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > > Michael > From rob.mckenna at oracle.com Fri Aug 28 12:40:35 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 28 Aug 2015 13:40:35 +0100 Subject: [8u-dev] Request for Approval: 8134484: disallow backquotes as heredoc end marker delimiters In-Reply-To: References: Message-ID: <55E056C3.9090502@oracle.com> Approved. -Rob On 28/08/15 13:23, Michael Haupt wrote: > Dear all, > > please approve this backport request. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134484 > jdk9 webrev: http://cr.openjdk.java.net/~mhaupt/8134484/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005078.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > > Michael > From brian.burkhalter at oracle.com Fri Aug 28 18:14:17 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 28 Aug 2015 11:14:17 -0700 Subject: [8u-dev] Request for approval 8131905: (fs) Crash while using WatchService Message-ID: <174E883A-4416-4878-ABDB-C48E93319B89@oracle.com> Please approve this backport request. Issue: https://bugs.openjdk.java.net/browse/JDK-8131905 JDK 9 webrev: http://cr.openjdk.java.net/~alanb/8029516/webrev/ JDK 9 review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2014-September/002735.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout, and the jdk_nio regression tests pass. The JDK 9 patch was approved by its author as suitable for backporting. Thanks, Brian From rob.mckenna at oracle.com Fri Aug 28 18:32:12 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 28 Aug 2015 19:32:12 +0100 Subject: [8u-dev] Request for approval 8131905: (fs) Crash while using WatchService In-Reply-To: <174E883A-4416-4878-ABDB-C48E93319B89@oracle.com> References: <174E883A-4416-4878-ABDB-C48E93319B89@oracle.com> Message-ID: <55E0A92C.7030503@oracle.com> Hi Brian, This needs to be pushed to 9 before we can approve it. Please reply with a link to the 9 changeset and I'll approve then. Thanks, -Rob On 28/08/15 19:14, Brian Burkhalter wrote: > Please approve this backport request. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8131905 > JDK 9 webrev: http://cr.openjdk.java.net/~alanb/8029516/webrev/ > JDK 9 review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2014-September/002735.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout, and the jdk_nio regression tests pass. The JDK 9 patch was approved by its author as suitable for backporting. > > Thanks, > > Brian > From brian.burkhalter at oracle.com Fri Aug 28 18:38:10 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 28 Aug 2015 11:38:10 -0700 Subject: [8u-dev] Request for approval 8131905: (fs) Crash while using WatchService In-Reply-To: <55E0A92C.7030503@oracle.com> References: <174E883A-4416-4878-ABDB-C48E93319B89@oracle.com> <55E0A92C.7030503@oracle.com> Message-ID: Hi Rob, The JDK 9 changeset is here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4f0cc1ad85b4 I?ll resolve 8131905 as a duplicate of 8029516. Thanks, Brian On Aug 28, 2015, at 11:32 AM, Rob McKenna wrote: > Hi Brian, > > This needs to be pushed to 9 before we can approve it. Please reply with a link to the 9 changeset and I'll approve then. > > Thanks, > > -Rob > > On 28/08/15 19:14, Brian Burkhalter wrote: >> Please approve this backport request. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8131905 >> JDK 9 webrev: http://cr.openjdk.java.net/~alanb/8029516/webrev/ >> JDK 9 review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2014-September/002735.html >> >> Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout, and the jdk_nio regression tests pass. The JDK 9 patch was approved by its author as suitable for backporting. >> >> Thanks, >> >> Brian >> From rob.mckenna at oracle.com Fri Aug 28 18:39:22 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 28 Aug 2015 19:39:22 +0100 Subject: [8u-dev] Request for approval 8029516: (fs) WatchKey cancel unreliable on Windows In-Reply-To: References: <174E883A-4416-4878-ABDB-C48E93319B89@oracle.com> <55E0A92C.7030503@oracle.com> Message-ID: <55E0AADA.7080007@oracle.com> Altering the subject for future reference. Approved, -Rob On 28/08/15 19:38, Brian Burkhalter wrote: > Hi Rob, > > The JDK 9 changeset is here: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4f0cc1ad85b4 > > I?ll resolve 8131905 as a duplicate of 8029516. > > Thanks, > > Brian > > On Aug 28, 2015, at 11:32 AM, Rob McKenna wrote: > >> Hi Brian, >> >> This needs to be pushed to 9 before we can approve it. Please reply with a link to the 9 changeset and I'll approve then. >> >> Thanks, >> >> -Rob >> >> On 28/08/15 19:14, Brian Burkhalter wrote: >>> Please approve this backport request. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8131905 >>> JDK 9 webrev: http://cr.openjdk.java.net/~alanb/8029516/webrev/ >>> JDK 9 review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2014-September/002735.html >>> >>> Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout, and the jdk_nio regression tests pass. The JDK 9 patch was approved by its author as suitable for backporting. >>> >>> Thanks, >>> >>> Brian >>> > From sundararajan.athijegannathan at oracle.com Mon Aug 31 16:42:37 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 31 Aug 2015 22:12:37 +0530 Subject: [8u-dev] approval request for 8134731: `Function.prototype.apply` interacts incorrectly with `arguments` Message-ID: <55E483FD.50606@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8134731 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005104.html jdk8u webrev: http://cr.openjdk.java.net/~sundar/8134731/8u/webrev.00/ backported 'as is' except for modular source layout difference. Thanks, -Sundar From rob.mckenna at oracle.com Mon Aug 31 17:26:41 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 31 Aug 2015 18:26:41 +0100 Subject: [8u-dev] approval request for 8134731: `Function.prototype.apply` interacts incorrectly with `arguments` In-Reply-To: <55E483FD.50606@oracle.com> References: <55E483FD.50606@oracle.com> Message-ID: <55E48E51.6070008@oracle.com> Approved -Rob On 31/08/15 17:42, Sundararajan Athijegannathan wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134731 > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-August/005104.html > jdk8u webrev: http://cr.openjdk.java.net/~sundar/8134731/8u/webrev.00/ > > backported 'as is' except for modular source layout difference. > > Thanks, > -Sundar