From serguei.spitsyn at oracle.com Tue Nov 1 12:58:56 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 1 Nov 2016 08:58:56 -0400 Subject: RFR (XS): 8160024 jdb returns invalid argument count if first parameter to Arrays.asList is null In-Reply-To: References: Message-ID: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> Please, review this small fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8160024 JDK webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8160024-JDI-eval.jdk1/ The bug is confidential, so the RFR is sent to the confidential mailing lists. Summary: The JDI incorrectly evaluates the expression: Arrays.asList(null, "a"). The root cause is a special case in the method MethodImpl.handleVarArgs() that has been corrected in order to fix the problem. New unit test is included: jdk/test/com/sun/jdi/EvalArraysAsList.sh Testing: Ran new unit test, Jtreg com/sun/jdi and nsk.jdi.testlist. All tests are passed. Thanks, Serguei From serguei.spitsyn at oracle.com Tue Nov 1 13:03:16 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 1 Nov 2016 09:03:16 -0400 Subject: RFR (XS): 8160024 jdb returns invalid argument count if first parameter to Arrays.asList is null In-Reply-To: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> References: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> Message-ID: On 11/1/16 08:58, serguei.spitsyn at oracle.com wrote: > Please, review this small fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160024 > > JDK webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8160024-JDI-eval.jdk1/ > > > The bug is confidential, so the RFR is sent to the confidential mailing > lists. Sorry, I sent it in the open, but bug is confidential. Thanks, Serguei > > > Summary: > > The JDI incorrectly evaluates the expression: Arrays.asList(null, "a"). > The root cause is a special case in the method > MethodImpl.handleVarArgs() > that has been corrected in order to fix the problem. > > New unit test is included: jdk/test/com/sun/jdi/EvalArraysAsList.sh > > Testing: > Ran new unit test, Jtreg com/sun/jdi and nsk.jdi.testlist. > All tests are passed. > > Thanks, > Serguei > From daniel.daugherty at oracle.com Tue Nov 1 22:03:33 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 1 Nov 2016 16:03:33 -0600 Subject: RFR (XS): 8160024 jdb returns invalid argument count if first parameter to Arrays.asList is null In-Reply-To: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> References: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> Message-ID: On 11/1/16 6:58 AM, serguei.spitsyn at oracle.com wrote: > Please, review this small fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160024 > > JDK webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8160024-JDI-eval.jdk1/ > src/jdk.jdi/share/classes/com/sun/tools/jdi/MethodImpl.java L318: if (nthArgValue == null && argCount == paramCount) { L319: // The only one varargs parameter is null Perhaps this comment rewrite: // We have one varargs parameter and it is null // so we don't have to do anything. L322: Type nthArgType = (nthArgValue == null) ? null : nthArgValue.type(); Perhaps add this comment above L322: // If the first varargs parameter is null, then don't // access its type since it can't be an array. L347: argArray.setValues(0, arguments, paramCount - 1, count); Looks like setValues() will happily copy any null values that happen to be in the arguments List to the argArray. Good. test/com/sun/jdi/EvalArraysAsList.sh No comments. Thumbs up, but I thought we weren't suppose to add any more new shell script tests... :-) Dan > > The bug is confidential, so the RFR is sent to the confidential mailing > lists. > > > Summary: > > The JDI incorrectly evaluates the expression: Arrays.asList(null, "a"). > The root cause is a special case in the method > MethodImpl.handleVarArgs() > that has been corrected in order to fix the problem. > > New unit test is included: jdk/test/com/sun/jdi/EvalArraysAsList.sh > > Testing: > Ran new unit test, Jtreg com/sun/jdi and nsk.jdi.testlist. > All tests are passed. > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Wed Nov 2 02:53:35 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 1 Nov 2016 22:53:35 -0400 Subject: RFR (XS): 8160024 jdb returns invalid argument count if first parameter to Arrays.asList is null In-Reply-To: References: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> Message-ID: Dan, Thank you for the review and the suggestions! I'll add the suggested comments. The test is ridiculously simple so that I did not want to make it more complex just for the sake of no shell scripting. :) Thanks! Serguei On 11/1/16 18:03, Daniel D. Daugherty wrote: > On 11/1/16 6:58 AM, serguei.spitsyn at oracle.com wrote: >> Please, review this small fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160024 >> >> JDK webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8160024-JDI-eval.jdk1/ >> > > src/jdk.jdi/share/classes/com/sun/tools/jdi/MethodImpl.java > L318: if (nthArgValue == null && argCount == paramCount) { > L319: // The only one varargs parameter is null > Perhaps this comment rewrite: > // We have one varargs parameter and it is null > // so we don't have to do anything. > > L322: Type nthArgType = (nthArgValue == null) ? null : > nthArgValue.type(); > Perhaps add this comment above L322: > // If the first varargs parameter is null, then don't > // access its type since it can't be an array. > > L347: argArray.setValues(0, arguments, paramCount - 1, > count); > Looks like setValues() will happily copy any null values that > happen to be in the arguments List to the argArray. Good. > > test/com/sun/jdi/EvalArraysAsList.sh > No comments. > > Thumbs up, but I thought we weren't suppose to add any more > new shell script tests... :-) > > Dan > > >> >> The bug is confidential, so the RFR is sent to the confidential mailing >> lists. >> >> >> Summary: >> >> The JDI incorrectly evaluates the expression: Arrays.asList(null, >> "a"). >> The root cause is a special case in the method >> MethodImpl.handleVarArgs() >> that has been corrected in order to fix the problem. >> >> New unit test is included: jdk/test/com/sun/jdi/EvalArraysAsList.sh >> >> Testing: >> Ran new unit test, Jtreg com/sun/jdi and nsk.jdi.testlist. >> All tests are passed. >> >> Thanks, >> Serguei >> > From jini.george at oracle.com Wed Nov 2 03:59:57 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 1 Nov 2016 20:59:57 -0700 (PDT) Subject: RFR: JDK-8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure In-Reply-To: References: <6e9091dc-f677-44ef-91aa-8027c3195cb2@default> Message-ID: Could I get one more review done for this, please ? Thanks, Jini. > -----Original Message----- > From: Dmitry Samersoff > Sent: Monday, October 31, 2016 2:58 PM > To: Jini Susan George; serviceability-dev > Subject: Re: RFR: JDK-8164783: SA: jhsdb clhsdb 'printall' often throws > "Corrupted constant pool" assertion failure > > Jini, > > Looks good for me! > > -Dmitry > > > On 2016-10-31 11:21, Jini Susan George wrote: > > Please do review the changes for the SA defect: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8164783 > > > > > > > > The webrev is at: > > > > > > > > http://cr.openjdk.java.net/~jgeorge/8164783/webrev.00/ > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From sundararajan.athijegannathan at oracle.com Wed Nov 2 04:05:16 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 2 Nov 2016 09:35:16 +0530 Subject: RFR: JDK-8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure In-Reply-To: References: <6e9091dc-f677-44ef-91aa-8027c3195cb2@default> Message-ID: New files (LingeredAppWithInvokeDynamic.java, TestCpoolForInvokeDynamic.java) should just have current year for copyright (2005, 2015 should be removed). Other than that, +1 -Sundar On 11/2/2016 9:29 AM, Jini Susan George wrote: > Could I get one more review done for this, please ? > Thanks, > Jini. > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Monday, October 31, 2016 2:58 PM >> To: Jini Susan George; serviceability-dev >> Subject: Re: RFR: JDK-8164783: SA: jhsdb clhsdb 'printall' often throws >> "Corrupted constant pool" assertion failure >> >> Jini, >> >> Looks good for me! >> >> -Dmitry >> >> >> On 2016-10-31 11:21, Jini Susan George wrote: >>> Please do review the changes for the SA defect: >>> >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8164783 >>> >>> >>> >>> The webrev is at: >>> >>> >>> >>> http://cr.openjdk.java.net/~jgeorge/8164783/webrev.00/ >>> >>> >>> >>> Thanks, >>> >>> - Jini Susan George >>> >>> >>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Wed Nov 2 04:07:42 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 1 Nov 2016 21:07:42 -0700 (PDT) Subject: RFR: JDK-8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure In-Reply-To: References: <6e9091dc-f677-44ef-91aa-8027c3195cb2@default> Message-ID: <1f77bd54-4de1-4c17-a51b-19069bec770e@default> Thank you, Sundar! -jini > -----Original Message----- > From: Sundararajan Athijegannathan > Sent: Wednesday, November 02, 2016 9:35 AM > To: serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8164783: SA: jhsdb clhsdb 'printall' often throws > "Corrupted constant pool" assertion failure > > New files (LingeredAppWithInvokeDynamic.java, > TestCpoolForInvokeDynamic.java) should just have current year for > copyright (2005, 2015 should be removed). > > Other than that, +1 > > -Sundar > > > On 11/2/2016 9:29 AM, Jini Susan George wrote: > > Could I get one more review done for this, please ? > > Thanks, > > Jini. > > > >> -----Original Message----- > >> From: Dmitry Samersoff > >> Sent: Monday, October 31, 2016 2:58 PM > >> To: Jini Susan George; serviceability-dev > >> Subject: Re: RFR: JDK-8164783: SA: jhsdb clhsdb 'printall' often throws > >> "Corrupted constant pool" assertion failure > >> > >> Jini, > >> > >> Looks good for me! > >> > >> -Dmitry > >> > >> > >> On 2016-10-31 11:21, Jini Susan George wrote: > >>> Please do review the changes for the SA defect: > >>> > >>> > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8164783 > >>> > >>> > >>> > >>> The webrev is at: > >>> > >>> > >>> > >>> http://cr.openjdk.java.net/~jgeorge/8164783/webrev.00/ > >>> > >>> > >>> > >>> Thanks, > >>> > >>> - Jini Susan George > >>> > >>> > >>> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > From amit.sapre at oracle.com Wed Nov 2 09:58:49 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 2 Nov 2016 02:58:49 -0700 (PDT) Subject: RFR - JDK-8006078 : [findbugs] java.lang.management.ThreadInfo returns mutable objects In-Reply-To: <00f0af20-b56d-e016-f550-72ffef37575e@oracle.com> References: <51123e42-6f4c-43d9-81b1-b69017aeb699@default> <00f0af20-b56d-e016-f550-72ffef37575e@oracle.com> Message-ID: Hello, Can I have one more review for these changes ? > -----Original Message----- > From: David Holmes > Sent: Saturday, October 29, 2016 12:22 AM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR - JDK-8006078 : [findbugs] > java.lang.management.ThreadInfo returns mutable objects > > Hi Amit, > > On 28/10/2016 4:12 PM, Amit Sapre wrote: > > Hello, > > > > Summary : Fixed findbugs reported warnings. > > > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8006078 > > > > Webrev : http://cr.openjdk.java.net/~asapre/webrev/JDK- > 8006078/webrev.00/ > > Looks okay. I hope the extra memory usage is not an issue for any > tests. David, I had run svc sanity tests only. If there are specific tests which I should run as well, Do let me know. > > Thanks, > David > > > > > > > Thanks, > > > > Amit > > From frederic.parain at oracle.com Wed Nov 2 15:13:35 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 2 Nov 2016 11:13:35 -0400 Subject: RFR - JDK-8006078 : [findbugs] java.lang.management.ThreadInfo returns mutable objects In-Reply-To: References: <51123e42-6f4c-43d9-81b1-b69017aeb699@default> <00f0af20-b56d-e016-f550-72ffef37575e@oracle.com> Message-ID: <88f579f8-924c-6486-24fc-ca38a554aa78@oracle.com> Looks good to me too. Fred On 11/02/2016 05:58 AM, Amit Sapre wrote: > Hello, > Can I have one more review for these changes ? > >> -----Original Message----- >> From: David Holmes >> Sent: Saturday, October 29, 2016 12:22 AM >> To: Amit Sapre; serviceability-dev >> Subject: Re: RFR - JDK-8006078 : [findbugs] >> java.lang.management.ThreadInfo returns mutable objects >> >> Hi Amit, >> >> On 28/10/2016 4:12 PM, Amit Sapre wrote: >>> Hello, >>> >>> Summary : Fixed findbugs reported warnings. >>> >>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8006078 >>> >>> Webrev : http://cr.openjdk.java.net/~asapre/webrev/JDK- >> 8006078/webrev.00/ >> >> Looks okay. I hope the extra memory usage is not an issue for any >> tests. > > David, > I had run svc sanity tests only. If there are specific tests which I should run as well, Do let me know. > >> >> Thanks, >> David >> >>> >>> >>> Thanks, >>> >>> Amit >>> From jini.george at oracle.com Thu Nov 3 04:04:12 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 2 Nov 2016 21:04:12 -0700 (PDT) Subject: RFR: JDK-7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test Message-ID: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> Please review the trivial fix for the bug below (Unfortunately, the bug is marked confidential): https://bugs.openjdk.java.net/browse/JDK-7107018 Webrev: http://cr.openjdk.java.net/~jgeorge/7107018/webrev.00/index.html Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.sapre at oracle.com Thu Nov 3 06:08:35 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 2 Nov 2016 23:08:35 -0700 (PDT) Subject: RFR - JDK-8006078 : [findbugs] java.lang.management.ThreadInfo returns mutable objects In-Reply-To: <88f579f8-924c-6486-24fc-ca38a554aa78@oracle.com> References: <51123e42-6f4c-43d9-81b1-b69017aeb699@default> <00f0af20-b56d-e016-f550-72ffef37575e@oracle.com> <88f579f8-924c-6486-24fc-ca38a554aa78@oracle.com> Message-ID: Thanks Fred for the review. > -----Original Message----- > From: Frederic Parain > Sent: Wednesday, November 02, 2016 8:44 PM > To: Amit Sapre; David Holmes; serviceability-dev > Subject: Re: RFR - JDK-8006078 : [findbugs] > java.lang.management.ThreadInfo returns mutable objects > > Looks good to me too. > > Fred > > On 11/02/2016 05:58 AM, Amit Sapre wrote: > > Hello, > > Can I have one more review for these changes ? > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Saturday, October 29, 2016 12:22 AM > >> To: Amit Sapre; serviceability-dev > >> Subject: Re: RFR - JDK-8006078 : [findbugs] > >> java.lang.management.ThreadInfo returns mutable objects > >> > >> Hi Amit, > >> > >> On 28/10/2016 4:12 PM, Amit Sapre wrote: > >>> Hello, > >>> > >>> Summary : Fixed findbugs reported warnings. > >>> > >>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8006078 > >>> > >>> Webrev : http://cr.openjdk.java.net/~asapre/webrev/JDK- > >> 8006078/webrev.00/ > >> > >> Looks okay. I hope the extra memory usage is not an issue for any > >> tests. > > > > David, > > I had run svc sanity tests only. If there are specific tests which I > should run as well, Do let me know. > > > >> > >> Thanks, > >> David > >> > >>> > >>> > >>> Thanks, > >>> > >>> Amit > >>> From sharath.ballal at oracle.com Thu Nov 3 09:28:06 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 3 Nov 2016 02:28:06 -0700 (PDT) Subject: RFR: JDK-7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop Message-ID: <170bf3fc-d3c8-4270-84b8-c6e2053e2fed@default> Hello, Pls review the fix for Issue: https://bugs.openjdk.java.net/browse/JDK-7107014 Webrev: http://cr.openjdk.java.net/~sballal/7107014/webrev.00/ -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Fri Nov 4 12:31:19 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 4 Nov 2016 15:31:19 +0300 Subject: RFR (XS): 8160024 jdb returns invalid argument count if first parameter to Arrays.asList is null In-Reply-To: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> References: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> Message-ID: <23c267c0-6f36-69a6-9c46-bb97c04e267e@oracle.com> Serguei, Looks good to me. PS: It might be better to refactor this code sometimes to don't check the same things multiple time. -Dmitry On 2016-11-01 15:58, serguei.spitsyn at oracle.com wrote: > Please, review this small fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160024 > > JDK webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8160024-JDI-eval.jdk1/ > > > The bug is confidential, so the RFR is sent to the confidential mailing > lists. > > > Summary: > > The JDI incorrectly evaluates the expression: Arrays.asList(null, "a"). > The root cause is a special case in the method MethodImpl.handleVarArgs() > that has been corrected in order to fix the problem. > > New unit test is included: jdk/test/com/sun/jdi/EvalArraysAsList.sh > > Testing: > Ran new unit test, Jtreg com/sun/jdi and nsk.jdi.testlist. > All tests are passed. > > Thanks, > Serguei > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Nov 4 12:35:00 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 4 Nov 2016 08:35:00 -0400 Subject: RFR (XS): 8160024 jdb returns invalid argument count if first parameter to Arrays.asList is null In-Reply-To: <23c267c0-6f36-69a6-9c46-bb97c04e267e@oracle.com> References: <64c20710-5257-e4d6-c613-06ff0c66cae4@oracle.com> <23c267c0-6f36-69a6-9c46-bb97c04e267e@oracle.com> Message-ID: Dmitry, Thank you for the review! Serguei On 11/4/16 08:31, Dmitry Samersoff wrote: > Serguei, > > Looks good to me. > > PS: It might be better to refactor this code sometimes to don't check > the same things multiple time. > > -Dmitry > > On 2016-11-01 15:58, serguei.spitsyn at oracle.com wrote: >> Please, review this small fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160024 >> >> JDK webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8160024-JDI-eval.jdk1/ >> >> >> The bug is confidential, so the RFR is sent to the confidential mailing >> lists. >> >> >> Summary: >> >> The JDI incorrectly evaluates the expression: Arrays.asList(null, "a"). >> The root cause is a special case in the method MethodImpl.handleVarArgs() >> that has been corrected in order to fix the problem. >> >> New unit test is included: jdk/test/com/sun/jdi/EvalArraysAsList.sh >> >> Testing: >> Ran new unit test, Jtreg com/sun/jdi and nsk.jdi.testlist. >> All tests are passed. >> >> Thanks, >> Serguei >> > From ujwal.vangapally at oracle.com Fri Nov 4 11:03:39 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Fri, 4 Nov 2016 16:33:39 +0530 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! Message-ID: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> Please review this small change for the bug below https://bugs.openjdk.java.net/browse/JDK-8168141 Webrev: http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ Thanks, Ujwal. From jini.george at oracle.com Mon Nov 7 04:28:17 2016 From: jini.george at oracle.com (Jini Susan George) Date: Sun, 6 Nov 2016 20:28:17 -0800 (PST) Subject: RFR: JDK-7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test In-Reply-To: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> References: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> Message-ID: <25e14640-0275-48c3-ba02-f74b32cfd564@default> Gentle reminder ! Thanks, Jini. From: Jini Susan George Sent: Thursday, November 03, 2016 9:34 AM To: serviceability-dev at openjdk.java.net Subject: RFR: JDK-7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test Please review the trivial fix for the bug below (Unfortunately, the bug is marked confidential): https://bugs.openjdk.java.net/browse/JDK-7107018 Webrev: http://cr.openjdk.java.net/~jgeorge/7107018/webrev.00/index.html Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From ujwal.vangapally at oracle.com Mon Nov 7 15:38:31 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Mon, 7 Nov 2016 21:08:31 +0530 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> Message-ID: Gentle remainder Thanks, Ujwal. On 11/4/2016 4:33 PM, Ujwal Vangapally wrote: > Please review this small change for the bug below > > https://bugs.openjdk.java.net/browse/JDK-8168141 > > Webrev: > http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ > > Thanks, > Ujwal. From harsha.wardhana.b at oracle.com Mon Nov 7 15:41:19 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 7 Nov 2016 21:11:19 +0530 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> Message-ID: <3e931cf0-3ed7-494a-0d7a-72d3d7f89438@oracle.com> Looks good. -Harsha On Monday 07 November 2016 09:08 PM, Ujwal Vangapally wrote: > Gentle remainder > > Thanks, > > Ujwal. > > > On 11/4/2016 4:33 PM, Ujwal Vangapally wrote: >> Please review this small change for the bug below >> >> https://bugs.openjdk.java.net/browse/JDK-8168141 >> >> Webrev: >> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ >> >> Thanks, >> Ujwal. > From jini.george at oracle.com Tue Nov 8 04:08:58 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 7 Nov 2016 20:08:58 -0800 (PST) Subject: RFR: JDK-8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c Message-ID: Requesting a review for the small fix for: https://bugs.openjdk.java.net/browse/JDK-8169344 Webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.00/ Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Tue Nov 8 04:29:18 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 7 Nov 2016 20:29:18 -0800 (PST) Subject: RFR: JDK-7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop In-Reply-To: <170bf3fc-d3c8-4270-84b8-c6e2053e2fed@default> References: <170bf3fc-d3c8-4270-84b8-c6e2053e2fed@default> Message-ID: <1862c915-3d90-4b72-8464-56079b390131@default> Gentle reminder. -Sharath Ballal From: Sharath Ballal Sent: Thursday, November 03, 2016 2:58 PM To: serviceability-dev at openjdk.java.net Subject: RFR: JDK-7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop Hello, Pls review the fix for Issue: https://bugs.openjdk.java.net/browse/JDK-7107014 Webrev: http://cr.openjdk.java.net/~sballal/7107014/webrev.00/ -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Nov 8 04:35:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Nov 2016 14:35:20 +1000 Subject: RFR: JDK-8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c In-Reply-To: References: Message-ID: Hi, On 8/11/2016 2:08 PM, Jini Susan George wrote: > Requesting a review for the small fix for: > https://bugs.openjdk.java.net/browse/JDK-8169344 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.00/ Looks okay but it can now simplify down to: return access(fname, F_OK) == 0; :) Thanks, David > > > Thanks, > > - Jini Susan George > > > From jini.george at oracle.com Tue Nov 8 04:39:52 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 7 Nov 2016 20:39:52 -0800 (PST) Subject: RFR: JDK-8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c In-Reply-To: References: Message-ID: Thank you, David. Will make this change. -jini > -----Original Message----- > From: David Holmes > Sent: Tuesday, November 08, 2016 10:05 AM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of > hotspot/agent/src/os/bsd/ps_core.c > > Hi, > > On 8/11/2016 2:08 PM, Jini Susan George wrote: > > Requesting a review for the small fix for: > > https://bugs.openjdk.java.net/browse/JDK-8169344 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.00/ > > Looks okay but it can now simplify down to: > > return access(fname, F_OK) == 0; > > :) > > Thanks, > David > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > From dmitry.samersoff at oracle.com Tue Nov 8 05:52:23 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 8 Nov 2016 08:52:23 +0300 Subject: RFR: JDK-8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c In-Reply-To: References: Message-ID: <133d3f45-f76c-9d9d-c6fa-1549169e69c3@oracle.com> Jini, The fix looks OK to me (with David's suggestion). -Dmitry On 2016-11-08 07:39, Jini Susan George wrote: > Thank you, David. Will make this change. > > -jini > >> -----Original Message----- >> From: David Holmes >> Sent: Tuesday, November 08, 2016 10:05 AM >> To: Jini Susan George; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of >> hotspot/agent/src/os/bsd/ps_core.c >> >> Hi, >> >> On 8/11/2016 2:08 PM, Jini Susan George wrote: >>> Requesting a review for the small fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8169344 >>> >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.00/ >> >> Looks okay but it can now simplify down to: >> >> return access(fname, F_OK) == 0; >> >> :) >> >> Thanks, >> David >> >>> >>> >>> Thanks, >>> >>> - Jini Susan George >>> >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Tue Nov 8 05:54:19 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 7 Nov 2016 21:54:19 -0800 (PST) Subject: RFR: JDK-8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c In-Reply-To: <133d3f45-f76c-9d9d-c6fa-1549169e69c3@oracle.com> References: <133d3f45-f76c-9d9d-c6fa-1549169e69c3@oracle.com> Message-ID: <6ed5fb32-7752-451d-acd0-7ea0e949d0f4@default> Thank you, Dmitry. -jini > -----Original Message----- > From: Dmitry Samersoff > Sent: Tuesday, November 08, 2016 11:22 AM > To: Jini Susan George; David Holmes; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of > hotspot/agent/src/os/bsd/ps_core.c > > Jini, > > The fix looks OK to me (with David's suggestion). > > -Dmitry > > On 2016-11-08 07:39, Jini Susan George wrote: > > Thank you, David. Will make this change. > > > > -jini > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Tuesday, November 08, 2016 10:05 AM > >> To: Jini Susan George; serviceability-dev at openjdk.java.net > >> Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of > >> hotspot/agent/src/os/bsd/ps_core.c > >> > >> Hi, > >> > >> On 8/11/2016 2:08 PM, Jini Susan George wrote: > >>> Requesting a review for the small fix for: > >>> https://bugs.openjdk.java.net/browse/JDK-8169344 > >>> > >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.00/ > >> > >> Looks okay but it can now simplify down to: > >> > >> return access(fname, F_OK) == 0; > >> > >> :) > >> > >> Thanks, > >> David > >> > >>> > >>> > >>> Thanks, > >>> > >>> - Jini Susan George > >>> > >>> > >>> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue Nov 8 05:54:34 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 8 Nov 2016 08:54:34 +0300 Subject: RFR: JDK-7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test In-Reply-To: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> References: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> Message-ID: Jini, The fix looks good to me. -Dmitry On 2016-11-03 07:04, Jini Susan George wrote: > Please review the trivial fix for the bug below (Unfortunately, the bug > is marked confidential): > > > > https://bugs.openjdk.java.net/browse/JDK-7107018 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/7107018/webrev.00/index.html > > > > Thanks, > > - Jini Susan George > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Tue Nov 8 06:03:09 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 7 Nov 2016 22:03:09 -0800 (PST) Subject: RFR: JDK-7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test In-Reply-To: References: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> Message-ID: Thank you, Dmitry. -jini > -----Original Message----- > From: Dmitry Samersoff > Sent: Tuesday, November 08, 2016 11:25 AM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-7107018: > sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > > Jini, > > The fix looks good to me. > > -Dmitry > > > On 2016-11-03 07:04, Jini Susan George wrote: > > Please review the trivial fix for the bug below (Unfortunately, the bug > > is marked confidential): > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-7107018 > > > > > > > > Webrev: > http://cr.openjdk.java.net/~jgeorge/7107018/webrev.00/index.html > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Tue Nov 8 09:54:50 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 8 Nov 2016 01:54:50 -0800 (PST) Subject: RFR: JDK-8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c In-Reply-To: <133d3f45-f76c-9d9d-c6fa-1549169e69c3@oracle.com> References: <133d3f45-f76c-9d9d-c6fa-1549169e69c3@oracle.com> Message-ID: <77eb7934-92db-4f76-b9b3-844d51abd034@default> The updated webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.01/ - jini. > -----Original Message----- > From: Dmitry Samersoff > Sent: Tuesday, November 08, 2016 11:22 AM > To: Jini Susan George; David Holmes; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of > hotspot/agent/src/os/bsd/ps_core.c > > Jini, > > The fix looks OK to me (with David's suggestion). > > -Dmitry > > On 2016-11-08 07:39, Jini Susan George wrote: > > Thank you, David. Will make this change. > > > > -jini > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Tuesday, November 08, 2016 10:05 AM > >> To: Jini Susan George; serviceability-dev at openjdk.java.net > >> Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of > >> hotspot/agent/src/os/bsd/ps_core.c > >> > >> Hi, > >> > >> On 8/11/2016 2:08 PM, Jini Susan George wrote: > >>> Requesting a review for the small fix for: > >>> https://bugs.openjdk.java.net/browse/JDK-8169344 > >>> > >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.00/ > >> > >> Looks okay but it can now simplify down to: > >> > >> return access(fname, F_OK) == 0; > >> > >> :) > >> > >> Thanks, > >> David > >> > >>> > >>> > >>> Thanks, > >>> > >>> - Jini Susan George > >>> > >>> > >>> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Tue Nov 8 10:05:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Nov 2016 20:05:29 +1000 Subject: RFR: JDK-8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c In-Reply-To: <77eb7934-92db-4f76-b9b3-844d51abd034@default> References: <133d3f45-f76c-9d9d-c6fa-1549169e69c3@oracle.com> <77eb7934-92db-4f76-b9b3-844d51abd034@default> Message-ID: <7223d7b6-43bb-797e-d7f1-5b8677557679@oracle.com> Looks good! Thanks, David On 8/11/2016 7:54 PM, Jini Susan George wrote: > The updated webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.01/ > > - jini. > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Tuesday, November 08, 2016 11:22 AM >> To: Jini Susan George; David Holmes; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of >> hotspot/agent/src/os/bsd/ps_core.c >> >> Jini, >> >> The fix looks OK to me (with David's suggestion). >> >> -Dmitry >> >> On 2016-11-08 07:39, Jini Susan George wrote: >>> Thank you, David. Will make this change. >>> >>> -jini >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Tuesday, November 08, 2016 10:05 AM >>>> To: Jini Susan George; serviceability-dev at openjdk.java.net >>>> Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of >>>> hotspot/agent/src/os/bsd/ps_core.c >>>> >>>> Hi, >>>> >>>> On 8/11/2016 2:08 PM, Jini Susan George wrote: >>>>> Requesting a review for the small fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8169344 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.00/ >>>> >>>> Looks okay but it can now simplify down to: >>>> >>>> return access(fname, F_OK) == 0; >>>> >>>> :) >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> - Jini Susan George >>>>> >>>>> >>>>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue Nov 8 10:27:46 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 8 Nov 2016 13:27:46 +0300 Subject: RFR: JDK-8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c In-Reply-To: <77eb7934-92db-4f76-b9b3-844d51abd034@default> References: <133d3f45-f76c-9d9d-c6fa-1549169e69c3@oracle.com> <77eb7934-92db-4f76-b9b3-844d51abd034@default> Message-ID: <45e05533-bd95-a722-8cc1-e605169bb4da@oracle.com> Jini, Looks good to me. -Dmitry On 2016-11-08 12:54, Jini Susan George wrote: > The updated webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.01/ > > - jini. > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Tuesday, November 08, 2016 11:22 AM >> To: Jini Susan George; David Holmes; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of >> hotspot/agent/src/os/bsd/ps_core.c >> >> Jini, >> >> The fix looks OK to me (with David's suggestion). >> >> -Dmitry >> >> On 2016-11-08 07:39, Jini Susan George wrote: >>> Thank you, David. Will make this change. >>> >>> -jini >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Tuesday, November 08, 2016 10:05 AM >>>> To: Jini Susan George; serviceability-dev at openjdk.java.net >>>> Subject: Re: RFR: JDK-8169344: Potential open file descriptor in exists() of >>>> hotspot/agent/src/os/bsd/ps_core.c >>>> >>>> Hi, >>>> >>>> On 8/11/2016 2:08 PM, Jini Susan George wrote: >>>>> Requesting a review for the small fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8169344 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8169344/webrev.00/ >>>> >>>> Looks okay but it can now simplify down to: >>>> >>>> return access(fname, F_OK) == 0; >>>> >>>> :) >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> - Jini Susan George >>>>> >>>>> >>>>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From robbin.ehn at oracle.com Tue Nov 8 10:32:03 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 8 Nov 2016 11:32:03 +0100 Subject: RFR: JDK-7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test In-Reply-To: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> References: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> Message-ID: <1266938b-6508-1f85-77e7-e73971f54586@oracle.com> Hi Jini, Looks okay! I personally would prefer: if (k != null && l != null) { But I'll leave that up to you. Thanks! /Robbin ('r'eviewer) On 11/03/2016 05:04 AM, Jini Susan George wrote: > Please review the trivial fix for the bug below (Unfortunately, the bug > is marked confidential): > > > > https://bugs.openjdk.java.net/browse/JDK-7107018 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/7107018/webrev.00/index.html > > > > Thanks, > > - Jini Susan George > > > From robbin.ehn at oracle.com Tue Nov 8 10:34:08 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 8 Nov 2016 11:34:08 +0100 Subject: RFR: JDK-7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop In-Reply-To: <170bf3fc-d3c8-4270-84b8-c6e2053e2fed@default> References: <170bf3fc-d3c8-4270-84b8-c6e2053e2fed@default> Message-ID: <6edd25ac-1abd-ce3c-ff72-d34f0740377a@oracle.com> Looks good! /Robbin ('r'eviewer) On 11/03/2016 10:28 AM, Sharath Ballal wrote: > Hello, > > Pls review the fix for > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107014 > > Webrev: http://cr.openjdk.java.net/~sballal/7107014/webrev.00/ > > > > -Sharath Ballal > > > > > From robbin.ehn at oracle.com Tue Nov 8 10:44:34 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 8 Nov 2016 11:44:34 +0100 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> Message-ID: Hi Ujwal, synchronized(li) { while (li.received < 1) { li.wait(100); } } I don't see why we need while loop ? To me it looks like you could just do: synchronized(li) { li.wait(); } Since either we got notification and received must be bigger than 0. Or jtreg timed out. /Robbin ('r'eviewer) On 11/04/2016 12:03 PM, Ujwal Vangapally wrote: > Please review this small change for the bug below > > https://bugs.openjdk.java.net/browse/JDK-8168141 > > Webrev: > http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ > > > Thanks, > Ujwal. From dmitry.samersoff at oracle.com Tue Nov 8 10:51:18 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 8 Nov 2016 13:51:18 +0300 Subject: RFR: JDK-7107014: sun.jvm.hotspot.HSDB.FindObjectByTypeCleanupThunk.showConsole.attach infinite loop In-Reply-To: <170bf3fc-d3c8-4270-84b8-c6e2053e2fed@default> References: <170bf3fc-d3c8-4270-84b8-c6e2053e2fed@default> Message-ID: Sharath, Looks good to me! -Dmitry On 2016-11-03 12:28, Sharath Ballal wrote: > Hello, > > Pls review the fix for > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107014 > > Webrev: http://cr.openjdk.java.net/~sballal/7107014/webrev.00/ > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Tue Nov 8 10:56:05 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 8 Nov 2016 02:56:05 -0800 (PST) Subject: RFR: JDK-7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test In-Reply-To: <1266938b-6508-1f85-77e7-e73971f54586@oracle.com> References: <88d916b6-5fc7-4e1e-854d-704ed5bc78a4@default> <1266938b-6508-1f85-77e7-e73971f54586@oracle.com> Message-ID: <034ba0fd-1ac8-41d9-83cd-eeebaa40a2e5@default> Thank you, Robbin ! -jini > -----Original Message----- > From: Robbin Ehn > Sent: Tuesday, November 08, 2016 4:02 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-7107018: > sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > > Hi Jini, > > Looks okay! > > I personally would prefer: > if (k != null && l != null) { > > But I'll leave that up to you. > > Thanks! > > /Robbin ('r'eviewer) > > On 11/03/2016 05:04 AM, Jini Susan George wrote: > > Please review the trivial fix for the bug below (Unfortunately, the bug > > is marked confidential): > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-7107018 > > > > > > > > Webrev: > http://cr.openjdk.java.net/~jgeorge/7107018/webrev.00/index.html > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > From staffan.larsen at oracle.com Tue Nov 8 10:58:08 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 8 Nov 2016 11:58:08 +0100 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> Message-ID: <316D97BC-B60D-4321-8DE9-D82E6D811E60@oracle.com> Spurious wakeups can cause wait() to finish early in which case the while loop is needed. But the timeout to wait() doesn?t add anything. And if the while loop is there the next statement is not needed: 112 if (li.received < 1) { 113 throw new RuntimeException("No notif received!"); > On 8 Nov 2016, at 11:44, Robbin Ehn wrote: > > Hi Ujwal, > > synchronized(li) { > while (li.received < 1) { > li.wait(100); > } > } > > I don't see why we need while loop ? > > To me it looks like you could just do: > > synchronized(li) { > li.wait(); > } > > Since either we got notification and received must be bigger than 0. > Or jtreg timed out. > > /Robbin ('r'eviewer) > > On 11/04/2016 12:03 PM, Ujwal Vangapally wrote: >> Please review this small change for the bug below >> >> https://bugs.openjdk.java.net/browse/JDK-8168141 >> >> Webrev: >> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ >> >> >> Thanks, >> Ujwal. From robbin.ehn at oracle.com Tue Nov 8 11:06:08 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 8 Nov 2016 12:06:08 +0100 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: <316D97BC-B60D-4321-8DE9-D82E6D811E60@oracle.com> References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> <316D97BC-B60D-4321-8DE9-D82E6D811E60@oracle.com> Message-ID: Thanks for the clarification on while loop. On 11/08/2016 11:58 AM, Staffan Larsen wrote: > Spurious wakeups can cause wait() to finish early in which case the while loop is needed. But the timeout to wait() doesn?t add anything. And if the while loop is there the next statement is not needed: > > > 112 if (li.received < 1) { > 113 throw new RuntimeException("No notif received!"); Ujwal, please update webrev with the comments from Staffan above. Thanks! /Robbin ('r'eviewer) > > >> On 8 Nov 2016, at 11:44, Robbin Ehn wrote: >> >> Hi Ujwal, >> >> synchronized(li) { >> while (li.received < 1) { >> li.wait(100); >> } >> } >> >> I don't see why we need while loop ? >> >> To me it looks like you could just do: >> >> synchronized(li) { >> li.wait(); >> } >> >> Since either we got notification and received must be bigger than 0. >> Or jtreg timed out. >> >> /Robbin ('r'eviewer) >> >> On 11/04/2016 12:03 PM, Ujwal Vangapally wrote: >>> Please review this small change for the bug below >>> >>> https://bugs.openjdk.java.net/browse/JDK-8168141 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ >>> >>> >>> Thanks, >>> Ujwal. > From david.holmes at oracle.com Tue Nov 8 11:23:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Nov 2016 21:23:52 +1000 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> Message-ID: <01a62743-efc8-7200-142f-eada13530bf3@oracle.com> On 8/11/2016 8:44 PM, Robbin Ehn wrote: > Hi Ujwal, > > synchronized(li) { > while (li.received < 1) { > li.wait(100); > } > } > > I don't see why we need while loop ? You should always perform a wait() in a loop checking the condition that is being waited upon. This guards against lost-notifications and also spurious wakeups. > To me it looks like you could just do: > > synchronized(li) { > li.wait(); > } > > Since either we got notification and received must be bigger than 0. > Or jtreg timed out. If the notifyAll() happened before you get here then you will wait() until jtreg does time you out - even though the notification correctly occurred. That said, in this particular case doing a timed-wait achieves nothing other than waking the thread so that it can go back to waiting again. The "received" value will only change when a notifyAll occurs so there is no need to poll it (unless aborting due to a timeout as per the previous version). Because the loop will never exit, unless the thread is interrupted, this subsequent code has no affect: 112 if (li.received < 1) { 113 throw new RuntimeException("No notif received!"); David ----- > /Robbin ('r'eviewer) > > On 11/04/2016 12:03 PM, Ujwal Vangapally wrote: >> Please review this small change for the bug below >> >> https://bugs.openjdk.java.net/browse/JDK-8168141 >> >> Webrev: >> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ >> >> >> >> Thanks, >> Ujwal. From david.holmes at oracle.com Tue Nov 8 11:48:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Nov 2016 21:48:07 +1000 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: <01a62743-efc8-7200-142f-eada13530bf3@oracle.com> References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> <01a62743-efc8-7200-142f-eada13530bf3@oracle.com> Message-ID: Sorry didn't see Staffan's earlier reply :) David On 8/11/2016 9:23 PM, David Holmes wrote: > On 8/11/2016 8:44 PM, Robbin Ehn wrote: >> Hi Ujwal, >> >> synchronized(li) { >> while (li.received < 1) { >> li.wait(100); >> } >> } >> >> I don't see why we need while loop ? > > You should always perform a wait() in a loop checking the condition that > is being waited upon. This guards against lost-notifications and also > spurious wakeups. > >> To me it looks like you could just do: >> >> synchronized(li) { >> li.wait(); >> } >> >> Since either we got notification and received must be bigger than 0. >> Or jtreg timed out. > > If the notifyAll() happened before you get here then you will wait() > until jtreg does time you out - even though the notification correctly > occurred. > > That said, in this particular case doing a timed-wait achieves nothing > other than waking the thread so that it can go back to waiting again. > The "received" value will only change when a notifyAll occurs so there > is no need to poll it (unless aborting due to a timeout as per the > previous version). > > Because the loop will never exit, unless the thread is interrupted, this > subsequent code has no affect: > > 112 if (li.received < 1) { > 113 throw new RuntimeException("No notif received!"); > > David > ----- > >> /Robbin ('r'eviewer) >> >> On 11/04/2016 12:03 PM, Ujwal Vangapally wrote: >>> Please review this small change for the bug below >>> >>> https://bugs.openjdk.java.net/browse/JDK-8168141 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ >>> >>> >>> >>> >>> Thanks, >>> Ujwal. From robbin.ehn at oracle.com Tue Nov 8 12:00:49 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 8 Nov 2016 13:00:49 +0100 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> <01a62743-efc8-7200-142f-eada13530bf3@oracle.com> Message-ID: <02e3cb3d-494e-2fb0-01ef-a43e958aba7e@oracle.com> Hi David, On 11/08/2016 12:48 PM, David Holmes wrote: > Sorry didn't see Staffan's earlier reply :) Thanks anyways! >> You should always perform a wait() in a loop checking the condition that >> is being waited upon. This guards against lost-notifications and also >> spurious wakeups. If you both are talking about signals + pthread_cond_wait, we can fix that with e.g. semaphore instead. (since it keeps track of the number of posts) But that's whole nother discussion... :) Lost notification, I don't see that? >> If the notifyAll() happened before you get here then you will wait() >> until jtreg does time you out - even though the notification correctly >> occurred. Correct, might work with move the start of synch block just after listener creation, before addListener, but maybe deadlock prone with mbsc.invoke ... /Robbin From robbin.ehn at oracle.com Tue Nov 8 12:20:11 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 8 Nov 2016 13:20:11 +0100 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: <02e3cb3d-494e-2fb0-01ef-a43e958aba7e@oracle.com> References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> <01a62743-efc8-7200-142f-eada13530bf3@oracle.com> <02e3cb3d-494e-2fb0-01ef-a43e958aba7e@oracle.com> Message-ID: <69ef9dca-5c60-2dc7-7dc3-0fdcb4a5464c@oracle.com> Hi, On 11/08/2016 01:00 PM, Robbin Ehn wrote: > Lost notification, I don't see that? Yes, sorry, I understand what you meant. (was thinking of notification as in Notification) Thanks! /Robbin From sharath.ballal at oracle.com Wed Nov 9 16:30:50 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 9 Nov 2016 08:30:50 -0800 (PST) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled Message-ID: <340818af-a178-4084-99d4-bd9c0aa4125d@default> Hello, Pls review this small fix Issue: https://bugs.openjdk.java.net/browse/JDK-7107013 Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/ -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Nov 9 19:16:00 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 9 Nov 2016 22:16:00 +0300 Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: <340818af-a178-4084-99d4-bd9c0aa4125d@default> References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> Message-ID: Sharath, Please, add (int) to ll. 54 for better readability. PS: Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions. -Dmitry On 2016-11-09 19:30, Sharath Ballal wrote: > Hello, > > Pls review this small fix > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013 > > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/ > > > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From ujwal.vangapally at oracle.com Thu Nov 10 06:56:59 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Thu, 10 Nov 2016 12:26:59 +0530 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> <01a62743-efc8-7200-142f-eada13530bf3@oracle.com> Message-ID: <9e3c1e6e-4fbe-bb9a-1fbb-14bca94356b1@oracle.com> Thanks for the Review, please find the new webrev incorporating the review comments. webrev : http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.02/ -Ujwal. On 11/8/2016 5:18 PM, David Holmes wrote: > Sorry didn't see Staffan's earlier reply :) > > David > > On 8/11/2016 9:23 PM, David Holmes wrote: >> On 8/11/2016 8:44 PM, Robbin Ehn wrote: >>> Hi Ujwal, >>> >>> synchronized(li) { >>> while (li.received < 1) { >>> li.wait(100); >>> } >>> } >>> >>> I don't see why we need while loop ? >> >> You should always perform a wait() in a loop checking the condition that >> is being waited upon. This guards against lost-notifications and also >> spurious wakeups. >> >>> To me it looks like you could just do: >>> >>> synchronized(li) { >>> li.wait(); >>> } >>> >>> Since either we got notification and received must be bigger than 0. >>> Or jtreg timed out. >> >> If the notifyAll() happened before you get here then you will wait() >> until jtreg does time you out - even though the notification correctly >> occurred. >> >> That said, in this particular case doing a timed-wait achieves nothing >> other than waking the thread so that it can go back to waiting again. >> The "received" value will only change when a notifyAll occurs so there >> is no need to poll it (unless aborting due to a timeout as per the >> previous version). >> >> Because the loop will never exit, unless the thread is interrupted, this >> subsequent code has no affect: >> >> 112 if (li.received < 1) { >> 113 throw new RuntimeException("No notif received!"); >> >> David >> ----- >> >>> /Robbin ('r'eviewer) >>> >>> On 11/04/2016 12:03 PM, Ujwal Vangapally wrote: >>>> Please review this small change for the bug below >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8168141 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> Ujwal. From sharath.ballal at oracle.com Thu Nov 10 07:02:12 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 9 Nov 2016 23:02:12 -0800 (PST) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> Message-ID: <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> Thanks Dmitry. I have made the changes in line 54. http://cr.openjdk.java.net/~sballal/7107013/webrev.01/ I didn't change the recursive calls to swap functions because that looks more readable. -Sharath Ballal -----Original Message----- From: Dmitry Samersoff Sent: Thursday, November 10, 2016 12:46 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled Sharath, Please, add (int) to ll. 54 for better readability. PS: Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions. -Dmitry On 2016-11-09 19:30, Sharath Ballal wrote: > Hello, > > Pls review this small fix > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013 > > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/ > > > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From ecki at zusammenkunft.net Thu Nov 10 07:49:46 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 10 Nov 2016 07:49:46 +0000 (UTC) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> Message-ID: <57A008FAA9E6E1E3.77D2C8FE-F8ED-479D-A375-7521BF1BB32E@mail.outlook.com> Hello, Is the a reason why swapShort has a " lowbyte | highbyyte" and the other two methods the other way around? I would all write in the natural order of. Igendianess (I.e. Change the first). Gruss Bernd -- http://bernd.eckenfels.net On Thu, Nov 10, 2016 at 8:32 AM +0100, "Sharath Ballal" wrote: Thanks Dmitry. I have made the changes in line 54. http://cr.openjdk.java.net/~sballal/7107013/webrev.01/ I didn't change the recursive calls to swap functions because that looks more readable. -Sharath Ballal -----Original Message----- From: Dmitry Samersoff Sent: Thursday, November 10, 2016 12:46 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled Sharath, Please, add (int) to ll. 54 for better readability. PS: Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions. -Dmitry On 2016-11-09 19:30, Sharath Ballal wrote: > Hello, > > Pls review this small fix > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013 > > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/ > > > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Nov 10 08:30:30 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 10 Nov 2016 00:30:30 -0800 (PST) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: <57A008FAA9E6E1E3.77D2C8FE-F8ED-479D-A375-7521BF1BB32E@mail.outlook.com> References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> <57A008FAA9E6E1E3.77D2C8FE-F8ED-479D-A375-7521BF1BB32E@mail.outlook.com> Message-ID: Hello Bernd, ? For int also its ?low 2 bytes | high 2 bytes? and again these two byte pairs are swapped by the swapshort as ?lowbyte | highbyte? Similarly for long its ? low 4 bytes | high 4 bytes? and again these pairs are swapped recursively. ? So for int if the little endian byte order was 3 2 1 0 it is now converted to 0 1 2 3 and similarly for long. ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 1:20 PM To: serviceability-dev at openjdk.java.net; Dmitry Samersoff; Sharath Ballal Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, ? Is the a reason why swapShort has a " lowbyte | highbyyte" and the other two methods the other way around? I would all write in the natural order of. Igendianess (I.e. Change the first). Gruss Bernd -- http://bernd.eckenfels.net ? On Thu, Nov 10, 2016 at 8:32 AM +0100, "Sharath Ballal" wrote: Thanks Dmitry.? I have made the changes in line 54. http://cr.openjdk.java.net/~sballal/7107013/webrev.01/ ? I didn't change the recursive calls to swap functions because that looks more readable. ? -Sharath Ballal ? ? -----Original Message----- From: Dmitry Samersoff Sent: Thursday, November 10, 2016 12:46 AM To: Sharath Ballal; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Sharath, ? Please, add (int) to ll. 54 for better readability. ? PS: ? Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions. ? -Dmitry ? On 2016-11-09 19:30, Sharath Ballal wrote: > Hello, > > Pls review this small fix > >? > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013 > > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/ > >? > >? > > -Sharath Ballal > >? > >? > ? ? -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Thu Nov 10 08:42:22 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 10 Nov 2016 08:42:22 +0000 (UTC) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> <57A008FAA9E6E1E3.77D2C8FE-F8ED-479D-A375-7521BF1BB32E@mail.outlook.com> Message-ID: <57A008FAA9E6E1E3.0155FB83-590B-4B7A-A109-A81D7073DCAB@mail.outlook.com> Hello, I was talking about the code order not the semantics: ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8));? 54 return ((int)swapShort((short) x) << 16) | (swapShort((short) (x >> 16)) & 0xFFFF);? 63 return ((long)swapInt((int) x) << 32) | (swapInt((int) (x >> 32)) & 0xFFFFFFFF); In 45 the Low half is expressed first (and no masking) in 54 and 63 the MSB half is expressed first. I guess casting and masking and order should be the same for all 3? Gruss Bernd -- http://bernd.eckenfels.net On Thu, Nov 10, 2016 at 9:30 AM +0100, "Sharath Ballal" wrote: Hello Bernd, ? For int also its ?low 2 bytes | high 2 bytes? and again these two byte pairs are swapped by the swapshort as ?lowbyte | highbyte? Similarly for long its ? low 4 bytes | high 4 bytes? and again these pairs are swapped recursively. ? So for int if the little endian byte order was 3 2 1 0 it is now converted to 0 1 2 3 and similarly for long. ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 1:20 PM To: serviceability-dev at openjdk.java.net; Dmitry Samersoff; Sharath Ballal Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, ? Is the a reason why swapShort has a " lowbyte | highbyyte" and the other two methods the other way around? I would all write in the natural order of. Igendianess (I.e. Change the first). Gruss Bernd -- http://bernd.eckenfels.net ? On Thu, Nov 10, 2016 at 8:32 AM +0100, "Sharath Ballal" wrote:Thanks Dmitry.? I have made the changes in line 54.http://cr.openjdk.java.net/~sballal/7107013/webrev.01/ ?I didn't change the recursive calls to swap functions because that looks more readable.?-Sharath Ballal??-----Original Message-----From: Dmitry Samersoff Sent: Thursday, November 10, 2016 12:46 AMTo: Sharath Ballal; serviceability-dev at openjdk.java.netSubject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled?Sharath,?Please, add (int) to ll. 54 for better readability.?PS:?Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions.?-Dmitry?On 2016-11-09 19:30, Sharath Ballal wrote:> Hello,> > Pls review this small fix> >? > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013> > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/> >? > >? > > -Sharath Ballal> >? > >? > ??--Dmitry SamersoffOracle Java development team, Saint Petersburg, Russia* I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Nov 10 09:00:45 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2016 19:00:45 +1000 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: <9e3c1e6e-4fbe-bb9a-1fbb-14bca94356b1@oracle.com> References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> <01a62743-efc8-7200-142f-eada13530bf3@oracle.com> <9e3c1e6e-4fbe-bb9a-1fbb-14bca94356b1@oracle.com> Message-ID: Looks fine to me. Thanks, David On 10/11/2016 4:56 PM, Ujwal Vangapally wrote: > Thanks for the Review, please find the new webrev incorporating the > review comments. > > webrev : > http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.02/ > > > -Ujwal. > > On 11/8/2016 5:18 PM, David Holmes wrote: >> Sorry didn't see Staffan's earlier reply :) >> >> David >> >> On 8/11/2016 9:23 PM, David Holmes wrote: >>> On 8/11/2016 8:44 PM, Robbin Ehn wrote: >>>> Hi Ujwal, >>>> >>>> synchronized(li) { >>>> while (li.received < 1) { >>>> li.wait(100); >>>> } >>>> } >>>> >>>> I don't see why we need while loop ? >>> >>> You should always perform a wait() in a loop checking the condition that >>> is being waited upon. This guards against lost-notifications and also >>> spurious wakeups. >>> >>>> To me it looks like you could just do: >>>> >>>> synchronized(li) { >>>> li.wait(); >>>> } >>>> >>>> Since either we got notification and received must be bigger than 0. >>>> Or jtreg timed out. >>> >>> If the notifyAll() happened before you get here then you will wait() >>> until jtreg does time you out - even though the notification correctly >>> occurred. >>> >>> That said, in this particular case doing a timed-wait achieves nothing >>> other than waking the thread so that it can go back to waiting again. >>> The "received" value will only change when a notifyAll occurs so there >>> is no need to poll it (unless aborting due to a timeout as per the >>> previous version). >>> >>> Because the loop will never exit, unless the thread is interrupted, this >>> subsequent code has no affect: >>> >>> 112 if (li.received < 1) { >>> 113 throw new RuntimeException("No notif received!"); >>> >>> David >>> ----- >>> >>>> /Robbin ('r'eviewer) >>>> >>>> On 11/04/2016 12:03 PM, Ujwal Vangapally wrote: >>>>> Please review this small change for the bug below >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8168141 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Ujwal. > From robbin.ehn at oracle.com Thu Nov 10 09:26:14 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 10 Nov 2016 10:26:14 +0100 Subject: RFR: JDK-8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! In-Reply-To: References: <5e791486-03ce-c6fb-76b8-a5a6db24100c@oracle.com> <01a62743-efc8-7200-142f-eada13530bf3@oracle.com> <9e3c1e6e-4fbe-bb9a-1fbb-14bca94356b1@oracle.com> Message-ID: On 11/10/2016 10:00 AM, David Holmes wrote: > Looks fine to me. +1 Thanks for fixing! /Robbin > > Thanks, > David > > On 10/11/2016 4:56 PM, Ujwal Vangapally wrote: >> Thanks for the Review, please find the new webrev incorporating the >> review comments. >> >> webrev : >> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.02/ >> >> >> -Ujwal. >> >> On 11/8/2016 5:18 PM, David Holmes wrote: >>> Sorry didn't see Staffan's earlier reply :) >>> >>> David >>> >>> On 8/11/2016 9:23 PM, David Holmes wrote: >>>> On 8/11/2016 8:44 PM, Robbin Ehn wrote: >>>>> Hi Ujwal, >>>>> >>>>> synchronized(li) { >>>>> while (li.received < 1) { >>>>> li.wait(100); >>>>> } >>>>> } >>>>> >>>>> I don't see why we need while loop ? >>>> >>>> You should always perform a wait() in a loop checking the condition that >>>> is being waited upon. This guards against lost-notifications and also >>>> spurious wakeups. >>>> >>>>> To me it looks like you could just do: >>>>> >>>>> synchronized(li) { >>>>> li.wait(); >>>>> } >>>>> >>>>> Since either we got notification and received must be bigger than 0. >>>>> Or jtreg timed out. >>>> >>>> If the notifyAll() happened before you get here then you will wait() >>>> until jtreg does time you out - even though the notification correctly >>>> occurred. >>>> >>>> That said, in this particular case doing a timed-wait achieves nothing >>>> other than waking the thread so that it can go back to waiting again. >>>> The "received" value will only change when a notifyAll occurs so there >>>> is no need to poll it (unless aborting due to a timeout as per the >>>> previous version). >>>> >>>> Because the loop will never exit, unless the thread is interrupted, this >>>> subsequent code has no affect: >>>> >>>> 112 if (li.received < 1) { >>>> 113 throw new RuntimeException("No notif received!"); >>>> >>>> David >>>> ----- >>>> >>>>> /Robbin ('r'eviewer) >>>>> >>>>> On 11/04/2016 12:03 PM, Ujwal Vangapally wrote: >>>>>> Please review this small change for the bug below >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8168141 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8168141/webrev.01/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Ujwal. >> From sharath.ballal at oracle.com Fri Nov 11 06:47:27 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 10 Nov 2016 22:47:27 -0800 (PST) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: <57A008FAA9E6E1E3.0155FB83-590B-4B7A-A109-A81D7073DCAB@mail.outlook.com> References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> <57A008FAA9E6E1E3.77D2C8FE-F8ED-479D-A375-7521BF1BB32E@mail.outlook.com> <57A008FAA9E6E1E3.0155FB83-590B-4B7A-A109-A81D7073DCAB@mail.outlook.com> Message-ID: <1defe308-dc44-481f-bec4-7657b44161e9@default> Hello Bernd, ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8)); Or return (short)((x << 8) | ((x >> 8) & 0xFF)); ? In the above two lines of code, whichever you choose to write, they both will give the same result.? Short will be implicitly converted to int and then the operation will take place. ? If you write the code as below (to make it consistent with int and long), you will get an error saying ?possible lossy conversion from int to short? ? return ((short) (x << 8) | ((x >> 8) & 0xFF)); or return ((short) (x << 8) | (short)((x >> 8) & 0xFF)); ? So an explicit cast will be required in both the above cases. ? Let me know if you would want to see the code changed to ?return (short)((x << 8) | ((x >> 8) & 0xFF));? to make it look consistent with the rest of the code. ? (Since I was not in to/cc, it took me longer to see the mail) ? ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 2:12 PM To: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, I was talking about the code order not the semantics: ? ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8)); ? 54 return ((int)swapShort((short) x) << 16) | (swapShort((short) (x >> 16)) & 0xFFFF); ? 63 return ((long)swapInt((int) x) << 32) | (swapInt((int) (x >> 32)) & 0xFFFFFFFF); ? In 45 the Low half is expressed first (and no masking) in 54 and 63 the MSB half is expressed first. ? I guess casting and masking and order should be the same for all 3? ? Gruss Bernd -- http://bernd.eckenfels.net ? On Thu, Nov 10, 2016 at 9:30 AM +0100, "Sharath Ballal" wrote: Hello Bernd, ? For int also its ?low 2 bytes | high 2 bytes? and again these two byte pairs are swapped by the swapshort as ?lowbyte | highbyte? Similarly for long its ? low 4 bytes | high 4 bytes? and again these pairs are swapped recursively. ? So for int if the little endian byte order was 3 2 1 0 it is now converted to 0 1 2 3 and similarly for long. ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 1:20 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; Dmitry Samersoff; Sharath Ballal Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, ? Is the a reason why swapShort has a " lowbyte | highbyyte" and the other two methods the other way around? I would all write in the natural order of. Igendianess (I.e. Change the first). Gruss Bernd -- http://bernd.eckenfels.net ? On Thu, Nov 10, 2016 at 8:32 AM +0100, "Sharath Ballal" wrote: Thanks Dmitry.? I have made the changes in line 54. http://cr.openjdk.java.net/~sballal/7107013/webrev.01/ ? I didn't change the recursive calls to swap functions because that looks more readable. ? -Sharath Ballal ? ? -----Original Message----- From: Dmitry Samersoff Sent: Thursday, November 10, 2016 12:46 AM To: Sharath Ballal; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Sharath, ? Please, add (int) to ll. 54 for better readability. ? PS: ? Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions. ? -Dmitry ? On 2016-11-09 19:30, Sharath Ballal wrote: > Hello, > > Pls review this small fix > >? > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013 > > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/ > >? > >? > > -Sharath Ballal > >? > >? > ? ? -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Fri Nov 11 16:02:24 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 11 Nov 2016 21:32:24 +0530 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently Message-ID: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> Hello, Please review the fix for issue : https://bugs.openjdk.java.net/browse/JDK-8141591 webrev : http://cr.openjdk.java.net/~hb/8141591/webrev.00/ Fix details: > The root-cause for the issue is that NotifFetcher thread was suspended > at L562 after which main thread ran to completion shutting down both > client and server and stopping the executor. Fixing as > > synchronized (ClientNotifForwarder.this) { > if (state == STARTED) { > executor.execute(new NotifFetcher()); > } > } > > will not solve the problem since NotifFetcher can get suspended after > checking state==STARTED and still hit the same problem. > > One way to solve would be to catch RejectedExecutionException and then > fallback on linearExecutor. This will take care of necessary cleanup > if client/server are shutdown or keeps the system running if executor > is abrupty shutdown by the client without stopping the client/server. The comments section of the issue also has discussion about various ways of fixing the issue and merits/demerits of different approaches. It also helps in getting a perspective on issue and the fix. Thanks Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Nov 11 16:42:05 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Nov 2016 16:42:05 +0000 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> References: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> Message-ID: <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> Hi Harsha, // We reached here because the executor was shutdown. // If executor was supplied by client, then it was shutdown // abruptly or JMXConnector was shutdown along with executor // while this thread was suspended at L564. if (!(executor instanceof LinearExecutor)) { // Spawn new executor that will do cleanup if JMXConnector is closed // or keep notif system running otherwise executor = new LinearExecutor(); .... I find it a bit strange to 'keep notif system running' if the executor was shutdown. If the user that supplied the executor shuts it down, then does it make sense to continue running? Also if the old executor has already been shutdown - and you create a new one - then do we have any guarantee that the new executor will be shut down properly? I wonder whether you should instead perform the cleaning action directly in the catch clause - that is - copy the lines 553-562 over there, or maybe simply call this::doRun() - without submitting 'this' to an executor... But then we would have to have some guarantee that doRun() will terminate and not call doRun() again (hence my suggestion to copy lines 553-562 instead)... This code is very hairy - with states and multiple critical sections and wait() and notifyAll(), so it is difficult to reason about, and I can't guarantee that it would be the right thing to do... But maybe it would be worth prototyping it and see if it also passes all the non-reg tests? best regards, -- daniel On 11/11/16 16:02, Harsha Wardhana B wrote: > Hello, > > Please review the fix for > > issue : https://bugs.openjdk.java.net/browse/JDK-8141591 > > webrev : http://cr.openjdk.java.net/~hb/8141591/webrev.00/ > > Fix details: > >> The root-cause for the issue is that NotifFetcher thread was suspended >> at L562 after which main thread ran to completion shutting down both >> client and server and stopping the executor. Fixing as >> >> synchronized (ClientNotifForwarder.this) { >> if (state == STARTED) { >> executor.execute(new NotifFetcher()); >> } >> } >> >> will not solve the problem since NotifFetcher can get suspended after >> checking state==STARTED and still hit the same problem. >> >> One way to solve would be to catch RejectedExecutionException and then >> fallback on linearExecutor. This will take care of necessary cleanup >> if client/server are shutdown or keeps the system running if executor >> is abrupty shutdown by the client without stopping the client/server. > > The comments section of the issue also has discussion about various ways > of fixing the issue and merits/demerits of different approaches. It also > helps in getting a perspective on issue and the fix. > > Thanks > > Harsha > From harsha.wardhana.b at oracle.com Fri Nov 11 16:57:12 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 11 Nov 2016 22:27:12 +0530 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> References: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> Message-ID: <92a22820-d0ac-e35a-c62b-3983efd029f5@oracle.com> Hi Daniel, On Friday 11 November 2016 10:12 PM, Daniel Fuchs wrote: > Hi Harsha, > > // We reached here because the executor was shutdown. > // If executor was supplied by client, then it was shutdown > // abruptly or JMXConnector was shutdown along with executor > // while this thread was suspended at L564. > if (!(executor instanceof LinearExecutor)) { > // Spawn new executor that will do cleanup if JMXConnector is closed > // or keep notif system running otherwise > executor = new LinearExecutor(); > .... > > I find it a bit strange to 'keep notif system running' if > the executor was shutdown. > It may happen that user will not be aware of shutdown sequence (client->server->executor) and may shutdown executor first. In that case, we may need to keep notif system running. > If the user that supplied the executor shuts it down, > then does it make sense to continue running? Also > if the old executor has already been shutdown - and you > create a new one - then do we have any guarantee that > the new executor will be shut down properly? Old executor will be shutdown by the user. We are only swapping a user supplied executor with new linear executor. It will follow the same shutdown sequence as original one. > > I wonder whether you should instead perform the cleaning > action directly in the catch clause - that is - copy > the lines 553-562 over there, or maybe simply > call this::doRun() - without submitting 'this' > to an executor... But then we would have to have > some guarantee that doRun() will terminate and > not call doRun() again (hence my suggestion to > copy lines 553-562 instead)... Well, that will not cover the case where user shuts down executor but keeps the client/server alive. So we will need a executor that can keep notif system running as well as do clean-up if client/server is closed. > > This code is very hairy - with states and multiple > critical sections and wait() and notifyAll(), so it > is difficult to reason about, and I can't guarantee > that it would be the right thing to do... > But maybe it would be worth prototyping it and see if > it also passes all the non-reg tests? > Yes Daniel. It is a precarious section of code loosely held together by states. However, I think the changes are not too intrusive since it does not rely on states. It only looks for RejectedExecutionException. I have written test-case that can validate my changes. I haven't JPRT yet but would be happy to share test results if required. > best regards, > > -- daniel > > On 11/11/16 16:02, Harsha Wardhana B wrote: >> Hello, >> >> Please review the fix for >> >> issue : https://bugs.openjdk.java.net/browse/JDK-8141591 >> >> webrev : http://cr.openjdk.java.net/~hb/8141591/webrev.00/ >> >> Fix details: >> >>> The root-cause for the issue is that NotifFetcher thread was suspended >>> at L562 after which main thread ran to completion shutting down both >>> client and server and stopping the executor. Fixing as >>> >>> synchronized (ClientNotifForwarder.this) { >>> if (state == STARTED) { >>> executor.execute(new NotifFetcher()); >>> } >>> } >>> >>> will not solve the problem since NotifFetcher can get suspended after >>> checking state==STARTED and still hit the same problem. >>> >>> One way to solve would be to catch RejectedExecutionException and then >>> fallback on linearExecutor. This will take care of necessary cleanup >>> if client/server are shutdown or keeps the system running if executor >>> is abrupty shutdown by the client without stopping the client/server. >> >> The comments section of the issue also has discussion about various ways >> of fixing the issue and merits/demerits of different approaches. It also >> helps in getting a perspective on issue and the fix. >> >> Thanks >> >> Harsha >> > Thanks Harsha From daniel.fuchs at oracle.com Fri Nov 11 17:32:08 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Nov 2016 17:32:08 +0000 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: <92a22820-d0ac-e35a-c62b-3983efd029f5@oracle.com> References: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> <92a22820-d0ac-e35a-c62b-3983efd029f5@oracle.com> Message-ID: On 11/11/16 16:57, Harsha Wardhana B wrote: > Hi Daniel, > Old executor will be shutdown by the user. We are only swapping a user > supplied executor with new linear executor. It will follow the same > shutdown sequence as original one. OK - the LinearExecutor has only one thread and that thread will terminate gracefully when there is nothing more to fetch - so shutdown of the new executor will not be an issue. >> I wonder whether you should instead perform the cleaning >> action directly in the catch clause - that is - copy >> the lines 553-562 over there, or maybe simply >> call this::doRun() - without submitting 'this' >> to an executor... But then we would have to have >> some guarantee that doRun() will terminate and >> not call doRun() again (hence my suggestion to >> copy lines 553-562 instead)... > Well, that will not cover the case where user shuts down executor but > keeps the client/server alive. So we will need a executor that can keep > notif system running as well as do clean-up if client/server is closed. It's OK to continue in order to do clean up and shutdown gracefully. It seems wrong to keep going afterwards as if nothing had happened though (in the case the user shuts the supplied executor down). >> This code is very hairy - with states and multiple >> critical sections and wait() and notifyAll(), so it >> is difficult to reason about, and I can't guarantee >> that it would be the right thing to do... >> But maybe it would be worth prototyping it and see if >> it also passes all the non-reg tests? >> > Yes Daniel. It is a precarious section of code loosely held together by > states. However, I think the changes are not too intrusive since it does > not rely on states. It only looks for RejectedExecutionException. I have > written test-case that can validate my changes. I haven't JPRT yet but > would be happy to share test results if required. If executor is no longer final then it should be volatile. And you should use double locking when resetting its value: if (!(executor instanceof LinearExecutor)) { synchronized (ClientNotifForwarder.this) { if (!(executor instanceof LinearExecutor)) { executor = new LinearExecutor(); } } executor.submit(this); } -- daniel >> best regards, >> >> -- daniel >> >> On 11/11/16 16:02, Harsha Wardhana B wrote: >>> Hello, >>> >>> Please review the fix for >>> >>> issue : https://bugs.openjdk.java.net/browse/JDK-8141591 >>> >>> webrev : http://cr.openjdk.java.net/~hb/8141591/webrev.00/ >>> >>> Fix details: >>> >>>> The root-cause for the issue is that NotifFetcher thread was suspended >>>> at L562 after which main thread ran to completion shutting down both >>>> client and server and stopping the executor. Fixing as >>>> >>>> synchronized (ClientNotifForwarder.this) { >>>> if (state == STARTED) { >>>> executor.execute(new NotifFetcher()); >>>> } >>>> } >>>> >>>> will not solve the problem since NotifFetcher can get suspended after >>>> checking state==STARTED and still hit the same problem. >>>> >>>> One way to solve would be to catch RejectedExecutionException and then >>>> fallback on linearExecutor. This will take care of necessary cleanup >>>> if client/server are shutdown or keeps the system running if executor >>>> is abrupty shutdown by the client without stopping the client/server. >>> >>> The comments section of the issue also has discussion about various ways >>> of fixing the issue and merits/demerits of different approaches. It also >>> helps in getting a perspective on issue and the fix. >>> >>> Thanks >>> >>> Harsha >>> >> > Thanks > Harsha From harsha.wardhana.b at oracle.com Mon Nov 14 06:57:27 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 14 Nov 2016 12:27:27 +0530 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: References: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> <92a22820-d0ac-e35a-c62b-3983efd029f5@oracle.com> Message-ID: <3fd0a9e4-f9bb-12e3-8462-0c4cb56040b6@oracle.com> Hi Daniel, On Friday 11 November 2016 11:02 PM, Daniel Fuchs wrote: > On 11/11/16 16:57, Harsha Wardhana B wrote: >> Hi Daniel, >> Old executor will be shutdown by the user. We are only swapping a user >> supplied executor with new linear executor. It will follow the same >> shutdown sequence as original one. > > OK - the LinearExecutor has only one thread and that thread > will terminate gracefully when there is nothing more to > fetch - so shutdown of the new executor will not be an issue. > >>> I wonder whether you should instead perform the cleaning >>> action directly in the catch clause - that is - copy >>> the lines 553-562 over there, or maybe simply >>> call this::doRun() - without submitting 'this' >>> to an executor... But then we would have to have >>> some guarantee that doRun() will terminate and >>> not call doRun() again (hence my suggestion to >>> copy lines 553-562 instead)... >> Well, that will not cover the case where user shuts down executor but >> keeps the client/server alive. So we will need a executor that can keep >> notif system running as well as do clean-up if client/server is closed. > > It's OK to continue in order to do clean up and > shutdown gracefully. It seems wrong to keep going afterwards > as if nothing had happened though (in the case the > user shuts the supplied executor down). With current changes, we do continue to carry on with linear executor. If the user wants to shutdown the system, he can always do it by shutting down client and server along with executor. If he shuts down executor but not client/server, it may be safe to assume that he wants the system to be up and running. It may not be appropriate to assume user wants to shutdown notif system just because he shutdown executor. > >>> This code is very hairy - with states and multiple >>> critical sections and wait() and notifyAll(), so it >>> is difficult to reason about, and I can't guarantee >>> that it would be the right thing to do... >>> But maybe it would be worth prototyping it and see if >>> it also passes all the non-reg tests? >>> >> Yes Daniel. It is a precarious section of code loosely held together by >> states. However, I think the changes are not too intrusive since it does >> not rely on states. It only looks for RejectedExecutionException. I have >> written test-case that can validate my changes. I haven't JPRT yet but >> would be happy to share test results if required. > > If executor is no longer final then it should be volatile. > And you should use double locking when resetting its value: > > if (!(executor instanceof LinearExecutor)) { > synchronized (ClientNotifForwarder.this) { > if (!(executor instanceof LinearExecutor)) { > executor = new LinearExecutor(); > } > } > executor.submit(this); > } > > Sure. Will send the updated webrev. > > -- daniel > >>> best regards, >>> >>> -- daniel >>> >>> On 11/11/16 16:02, Harsha Wardhana B wrote: >>>> Hello, >>>> >>>> Please review the fix for >>>> >>>> issue : https://bugs.openjdk.java.net/browse/JDK-8141591 >>>> >>>> webrev : http://cr.openjdk.java.net/~hb/8141591/webrev.00/ >>>> >>>> Fix details: >>>> >>>>> The root-cause for the issue is that NotifFetcher thread was >>>>> suspended >>>>> at L562 after which main thread ran to completion shutting down both >>>>> client and server and stopping the executor. Fixing as >>>>> >>>>> synchronized (ClientNotifForwarder.this) { >>>>> if (state == STARTED) { >>>>> executor.execute(new NotifFetcher()); >>>>> } >>>>> } >>>>> >>>>> will not solve the problem since NotifFetcher can get suspended after >>>>> checking state==STARTED and still hit the same problem. >>>>> >>>>> One way to solve would be to catch RejectedExecutionException and >>>>> then >>>>> fallback on linearExecutor. This will take care of necessary cleanup >>>>> if client/server are shutdown or keeps the system running if executor >>>>> is abrupty shutdown by the client without stopping the client/server. >>>> >>>> The comments section of the issue also has discussion about various >>>> ways >>>> of fixing the issue and merits/demerits of different approaches. It >>>> also >>>> helps in getting a perspective on issue and the fix. >>>> >>>> Thanks >>>> >>>> Harsha >>>> >>> >> Thanks >> Harsha > -Harsha From sharath.ballal at oracle.com Mon Nov 14 08:29:40 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 14 Nov 2016 00:29:40 -0800 (PST) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: <1defe308-dc44-481f-bec4-7657b44161e9@default> References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> <57A008FAA9E6E1E3.77D2C8FE-F8ED-479D-A375-7521BF1BB32E@mail.outlook.com> <57A008FAA9E6E1E3.0155FB83-590B-4B7A-A109-A81D7073DCAB@mail.outlook.com> <1defe308-dc44-481f-bec4-7657b44161e9@default> Message-ID: <97f2704b-75c0-4608-ab7f-16a420b44f2b@default> Bernd, Are you ok with the explanation and existing changes ? ? -Sharath Ballal ? ? From: Sharath Ballal Sent: Friday, November 11, 2016 12:17 PM To: Bernd Eckenfels; serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello Bernd, ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8)); Or return (short)((x << 8) | ((x >> 8) & 0xFF)); ? In the above two lines of code, whichever you choose to write, they both will give the same result.? Short will be implicitly converted to int and then the operation will take place. ? If you write the code as below (to make it consistent with int and long), you will get an error saying ?possible lossy conversion from int to short? ? return ((short) (x << 8) | ((x >> 8) & 0xFF)); or return ((short) (x << 8) | (short)((x >> 8) & 0xFF)); ? So an explicit cast will be required in both the above cases. ? Let me know if you would want to see the code changed to ?return (short)((x << 8) | ((x >> 8) & 0xFF));? to make it look consistent with the rest of the code. ? (Since I was not in to/cc, it took me longer to see the mail) ? ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 2:12 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, I was talking about the code order not the semantics: ? ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8)); ? 54 return ((int)swapShort((short) x) << 16) | (swapShort((short) (x >> 16)) & 0xFFFF); ? 63 return ((long)swapInt((int) x) << 32) | (swapInt((int) (x >> 32)) & 0xFFFFFFFF); ? In 45 the Low half is expressed first (and no masking) in 54 and 63 the MSB half is expressed first. ? I guess casting and masking and order should be the same for all 3? ? Gruss Bernd -- http://bernd.eckenfels.net ? ? On Thu, Nov 10, 2016 at 9:30 AM +0100, "Sharath Ballal" wrote: Hello Bernd, ? For int also its ?low 2 bytes | high 2 bytes? and again these two byte pairs are swapped by the swapshort as ?lowbyte | highbyte? Similarly for long its ? low 4 bytes | high 4 bytes? and again these pairs are swapped recursively. ? So for int if the little endian byte order was 3 2 1 0 it is now converted to 0 1 2 3 and similarly for long. ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 1:20 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; Dmitry Samersoff; Sharath Ballal Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, ? Is the a reason why swapShort has a " lowbyte | highbyyte" and the other two methods the other way around? I would all write in the natural order of. Igendianess (I.e. Change the first). Gruss Bernd -- http://bernd.eckenfels.net ? On Thu, Nov 10, 2016 at 8:32 AM +0100, "Sharath Ballal" wrote: Thanks Dmitry.? I have made the changes in line 54. http://cr.openjdk.java.net/~sballal/7107013/webrev.01/ ? I didn't change the recursive calls to swap functions because that looks more readable. ? -Sharath Ballal ? ? -----Original Message----- From: Dmitry Samersoff Sent: Thursday, November 10, 2016 12:46 AM To: Sharath Ballal; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Sharath, ? Please, add (int) to ll. 54 for better readability. ? PS: ? Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions. ? -Dmitry ? On 2016-11-09 19:30, Sharath Ballal wrote: > Hello, > > Pls review this small fix > >? > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013 > > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/ > >? > >? > > -Sharath Ballal > >? > >? > ? ? -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Mon Nov 14 09:42:54 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 14 Nov 2016 09:42:54 +0000 (UTC) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: <97f2704b-75c0-4608-ab7f-16a420b44f2b@default> References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> <57A008FAA9E6E1E3.77D2C8FE-F8ED-479D-A375-7521BF1BB32E@mail.outlook.com> <57A008FAA9E6E1E3.0155FB83-590B-4B7A-A109-A81D7073DCAB@mail.outlook.com> <1defe308-dc44-481f-bec4-7657b44161e9@default> <97f2704b-75c0-4608-ab7f-16a420b44f2b@default> Message-ID: <57A008FAA9E6E1E3.2D982E42-E86A-4503-A469-2CCF8549C6D9@mail.outlook.com> Hello, Don't worry about by comment, I am not sure that I have seen an change update or understand the explanation, but as my observation was only a minor nit it is fine with me in all cases. (I am not an official reviewer) Gruss Bernd -- http://bernd.eckenfels.net On Mon, Nov 14, 2016 at 9:29 AM +0100, "Sharath Ballal" wrote: Bernd, Are you ok with the explanation and existing changes ? ? -Sharath Ballal ? ? From: Sharath Ballal Sent: Friday, November 11, 2016 12:17 PM To: Bernd Eckenfels; serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello Bernd, ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8)); Or return (short)((x << 8) | ((x >> 8) & 0xFF)); ? In the above two lines of code, whichever you choose to write, they both will give the same result.? Short will be implicitly converted to int and then the operation will take place. ? If you write the code as below (to make it consistent with int and long), you will get an error saying ?possible lossy conversion from int to short? ? return ((short) (x << 8) | ((x >> 8) & 0xFF)); or return ((short) (x << 8) | (short)((x >> 8) & 0xFF)); ? So an explicit cast will be required in both the above cases. ? Let me know if you would want to see the code changed to ?return (short)((x << 8) | ((x >> 8) & 0xFF));? to make it look consistent with the rest of the code. ? (Since I was not in to/cc, it took me longer to see the mail) ? ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 2:12 PM To: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, I was talking about the code order not the semantics: ? ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8)); ? 54 return ((int)swapShort((short) x) << 16) | (swapShort((short) (x >> 16)) & 0xFFFF); ? 63 return ((long)swapInt((int) x) << 32) | (swapInt((int) (x >> 32)) & 0xFFFFFFFF); ? In 45 the Low half is expressed first (and no masking) in 54 and 63 the MSB half is expressed first. ? I guess casting and masking and order should be the same for all 3? ? Gruss Bernd -- http://bernd.eckenfels.net ? ? On Thu, Nov 10, 2016 at 9:30 AM +0100, "Sharath Ballal" wrote: Hello Bernd, ? For int also its ?low 2 bytes | high 2 bytes? and again these two byte pairs are swapped by the swapshort as ?lowbyte | highbyte? Similarly for long its ? low 4 bytes | high 4 bytes? and again these pairs are swapped recursively. ? So for int if the little endian byte order was 3 2 1 0 it is now converted to 0 1 2 3 and similarly for long. ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 1:20 PM To: serviceability-dev at openjdk.java.net; Dmitry Samersoff; Sharath Ballal Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, ? Is the a reason why swapShort has a " lowbyte | highbyyte" and the other two methods the other way around? I would all write in the natural order of. Igendianess (I.e. Change the first). Gruss Bernd -- http://bernd.eckenfels.net ? On Thu, Nov 10, 2016 at 8:32 AM +0100, "Sharath Ballal" wrote:Thanks Dmitry.? I have made the changes in line 54.http://cr.openjdk.java.net/~sballal/7107013/webrev.01/ ?I didn't change the recursive calls to swap functions because that looks more readable.?-Sharath Ballal??-----Original Message-----From: Dmitry Samersoff Sent: Thursday, November 10, 2016 12:46 AMTo: Sharath Ballal; serviceability-dev at openjdk.java.netSubject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled?Sharath,?Please, add (int) to ll. 54 for better readability.?PS:?Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions.?-Dmitry?On 2016-11-09 19:30, Sharath Ballal wrote:> Hello,> > Pls review this small fix> >? > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013> > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/> >? > >? > > -Sharath Ballal> >? > >? > ??--Dmitry SamersoffOracle Java development team, Saint Petersburg, Russia* I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Mon Nov 14 09:48:31 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 14 Nov 2016 01:48:31 -0800 (PST) Subject: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled In-Reply-To: <57A008FAA9E6E1E3.2D982E42-E86A-4503-A469-2CCF8549C6D9@mail.outlook.com> References: <340818af-a178-4084-99d4-bd9c0aa4125d@default> <0be7442d-47bd-4e6d-b7a1-9685977a056c@default> <57A008FAA9E6E1E3.77D2C8FE-F8ED-479D-A375-7521BF1BB32E@mail.outlook.com> <57A008FAA9E6E1E3.0155FB83-590B-4B7A-A109-A81D7073DCAB@mail.outlook.com> <1defe308-dc44-481f-bec4-7657b44161e9@default> <97f2704b-75c0-4608-ab7f-16a420b44f2b@default> <57A008FAA9E6E1E3.2D982E42-E86A-4503-A469-2CCF8549C6D9@mail.outlook.com> Message-ID: <06b28d4b-c86d-49c5-b945-7cda9d50ecbe@default> Thanks Bernd. ? ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Monday, November 14, 2016 3:13 PM To: serviceability-dev at openjdk.java.net; Sharath Ballal Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, ? Don't worry about by comment, I am not sure that I have seen an change update or understand the explanation, but as my observation was only a minor nit it is fine with me in all cases. (I am not an official reviewer) Gruss Bernd -- http://bernd.eckenfels.net ? On Mon, Nov 14, 2016 at 9:29 AM +0100, "Sharath Ballal" wrote: Bernd, Are you ok with the explanation and existing changes ? ? -Sharath Ballal ? ? From: Sharath Ballal Sent: Friday, November 11, 2016 12:17 PM To: Bernd Eckenfels; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello Bernd, ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8)); Or return (short)((x << 8) | ((x >> 8) & 0xFF)); ? In the above two lines of code, whichever you choose to write, they both will give the same result.? Short will be implicitly converted to int and then the operation will take place. ? If you write the code as below (to make it consistent with int and long), you will get an error saying ?possible lossy conversion from int to short? ? return ((short) (x << 8) | ((x >> 8) & 0xFF)); or return ((short) (x << 8) | (short)((x >> 8) & 0xFF)); ? So an explicit cast will be required in both the above cases. ? Let me know if you would want to see the code changed to ?return (short)((x << 8) | ((x >> 8) & 0xFF));? to make it look consistent with the rest of the code. ? (Since I was not in to/cc, it took me longer to see the mail) ? ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 2:12 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, I was talking about the code order not the semantics: ? ? 45 return (short) (((x >> 8) & 0xFF) | (x << 8)); ? 54 return ((int)swapShort((short) x) << 16) | (swapShort((short) (x >> 16)) & 0xFFFF); ? 63 return ((long)swapInt((int) x) << 32) | (swapInt((int) (x >> 32)) & 0xFFFFFFFF); ? In 45 the Low half is expressed first (and no masking) in 54 and 63 the MSB half is expressed first. ? I guess casting and masking and order should be the same for all 3? ? Gruss Bernd -- http://bernd.eckenfels.net ? ? On Thu, Nov 10, 2016 at 9:30 AM +0100, "Sharath Ballal" wrote: Hello Bernd, ? For int also its ?low 2 bytes | high 2 bytes? and again these two byte pairs are swapped by the swapshort as ?lowbyte | highbyte? Similarly for long its ? low 4 bytes | high 4 bytes? and again these pairs are swapped recursively. ? So for int if the little endian byte order was 3 2 1 0 it is now converted to 0 1 2 3 and similarly for long. ? -Sharath Ballal ? ? From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, November 10, 2016 1:20 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; Dmitry Samersoff; Sharath Ballal Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Hello, ? Is the a reason why swapShort has a " lowbyte | highbyyte" and the other two methods the other way around? I would all write in the natural order of. Igendianess (I.e. Change the first). Gruss Bernd -- http://bernd.eckenfels.net ? On Thu, Nov 10, 2016 at 8:32 AM +0100, "Sharath Ballal" wrote: Thanks Dmitry.? I have made the changes in line 54. http://cr.openjdk.java.net/~sballal/7107013/webrev.01/ ? I didn't change the recursive calls to swap functions because that looks more readable. ? -Sharath Ballal ? ? -----Original Message----- From: Dmitry Samersoff Sent: Thursday, November 10, 2016 12:46 AM To: Sharath Ballal; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-7107013: sun.jvm.hotspot.runtime.Bytes.swapLong conversion to long mishandled ? Sharath, ? Please, add (int) to ll. 54 for better readability. ? PS: ? Despite the fact that C2 does a great job eliminating useless code (multiple calls to if (!swap) in this case) it would be nice to use simple, well known arithmetic directly instead of subsequent calls to other swap functions. ? -Dmitry ? On 2016-11-09 19:30, Sharath Ballal wrote: > Hello, > > Pls review this small fix > >? > > Issue: https://bugs.openjdk.java.net/browse/JDK-7107013 > > Webrev: http://cr.openjdk.java.net/~sballal/7107013/webrev.00/ > >? > >? > > -Sharath Ballal > >? > >? > ? ? -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Mon Nov 14 10:44:27 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 14 Nov 2016 10:44:27 +0000 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: <3fd0a9e4-f9bb-12e3-8462-0c4cb56040b6@oracle.com> References: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> <92a22820-d0ac-e35a-c62b-3983efd029f5@oracle.com> <3fd0a9e4-f9bb-12e3-8462-0c4cb56040b6@oracle.com> Message-ID: <857a5e3b-4995-9875-6908-ec4eac9a6799@oracle.com> On 14/11/16 06:57, Harsha Wardhana B wrote: >>> Well, that will not cover the case where user shuts down executor but >>> keeps the client/server alive. So we will need a executor that can keep >>> notif system running as well as do clean-up if client/server is closed. >> >> It's OK to continue in order to do clean up and >> shutdown gracefully. It seems wrong to keep going afterwards >> as if nothing had happened though (in the case the >> user shuts the supplied executor down). > With current changes, we do continue to carry on with linear executor. > If the user wants to shutdown the system, he can always do it by > shutting down client and server along with executor. If he shuts down > executor but not client/server, it may be safe to assume that he wants > the system to be up and running. It may not be appropriate to assume > user wants to shutdown notif system just because he shutdown executor. Well, it may also not be appropriate to invoke a user provided callback on another executor than the one provided by the user. If the user provides an executor, we must assume he has good reasons to do so. I'm not hard set to opposing to what you propose, but it makes me feel uncomfortable. best regards, -- daniel From harsha.wardhana.b at oracle.com Tue Nov 15 08:46:22 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 15 Nov 2016 14:16:22 +0530 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: <857a5e3b-4995-9875-6908-ec4eac9a6799@oracle.com> References: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> <92a22820-d0ac-e35a-c62b-3983efd029f5@oracle.com> <3fd0a9e4-f9bb-12e3-8462-0c4cb56040b6@oracle.com> <857a5e3b-4995-9875-6908-ec4eac9a6799@oracle.com> Message-ID: <681b1444-dc8a-6ac1-8f8a-7a6eb31b0dda@oracle.com> Hello, Please review below webrev incorporating Daniel's comments. http://cr.openjdk.java.net/~hb/8141591/webrev.01/ Regards Harsha On Monday 14 November 2016 04:14 PM, Daniel Fuchs wrote: > On 14/11/16 06:57, Harsha Wardhana B wrote: >>>> Well, that will not cover the case where user shuts down executor but >>>> keeps the client/server alive. So we will need a executor that can >>>> keep >>>> notif system running as well as do clean-up if client/server is >>>> closed. >>> >>> It's OK to continue in order to do clean up and >>> shutdown gracefully. It seems wrong to keep going afterwards >>> as if nothing had happened though (in the case the >>> user shuts the supplied executor down). >> With current changes, we do continue to carry on with linear executor. >> If the user wants to shutdown the system, he can always do it by >> shutting down client and server along with executor. If he shuts down >> executor but not client/server, it may be safe to assume that he wants >> the system to be up and running. It may not be appropriate to assume >> user wants to shutdown notif system just because he shutdown executor. > > Well, it may also not be appropriate to invoke a user provided callback > on another executor than the one provided by the user. > If the user provides an executor, we must assume he has good > reasons to do so. > I'm not hard set to opposing to what you propose, but it makes me > feel uncomfortable. > > best regards, > > -- daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Wed Nov 16 04:28:49 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 15 Nov 2016 20:28:49 -0800 (PST) Subject: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 Message-ID: <1cd79b1c-1aa6-4048-b9a0-0164de4b2938@default> Requesting a review of a possible fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8169232 Webrev: http://cr.openjdk.java.net/~jgeorge/8169232/webrev.00/ Details have been outlined in the bug. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Wed Nov 16 07:59:23 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 15 Nov 2016 23:59:23 -0800 (PST) Subject: RFR: JDK-8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation Message-ID: Requesting a review of the small fix for: https://bugs.openjdk.java.net/browse/JDK-8169638 Webrev: http://cr.openjdk.java.net/~jgeorge/8169638/webrev.00/ Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Nov 16 08:44:05 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 16 Nov 2016 11:44:05 +0300 Subject: RFR: JDK-8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation In-Reply-To: References: Message-ID: Jini, Looks good to me! -Dmitry On 2016-11-16 10:59, Jini Susan George wrote: > Requesting a review of the small fix for: > > > > https://bugs.openjdk.java.net/browse/JDK-8169638 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169638/webrev.00/ > > > > Thanks, > > - Jini Susan George > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Wed Nov 16 08:48:33 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 16 Nov 2016 00:48:33 -0800 (PST) Subject: RFR: JDK-8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation In-Reply-To: References: Message-ID: <19b84196-c406-4281-8ea8-1f3e6cdda024@default> Thank you, Dmitry. - Jini. > -----Original Message----- > From: Dmitry Samersoff > Sent: Wednesday, November 16, 2016 2:14 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8169638: serviceability/sa/TestInstanceKlassSize.java > and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > > Jini, > > Looks good to me! > > -Dmitry > > > On 2016-11-16 10:59, Jini Susan George wrote: > > Requesting a review of the small fix for: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8169638 > > > > > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169638/webrev.00/ > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From robbin.ehn at oracle.com Wed Nov 16 09:11:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 16 Nov 2016 10:11:17 +0100 Subject: RFR: JDK-8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation In-Reply-To: References: Message-ID: <03d4151f-5a29-763c-0258-f52010ca3430@oracle.com> Looks good! /Robbin On 11/16/2016 08:59 AM, Jini Susan George wrote: > Requesting a review of the small fix for: > > > > https://bugs.openjdk.java.net/browse/JDK-8169638 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169638/webrev.00/ > > > > Thanks, > > - Jini Susan George > > > From jini.george at oracle.com Wed Nov 16 09:12:08 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 16 Nov 2016 01:12:08 -0800 (PST) Subject: RFR: JDK-8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation In-Reply-To: <03d4151f-5a29-763c-0258-f52010ca3430@oracle.com> References: <03d4151f-5a29-763c-0258-f52010ca3430@oracle.com> Message-ID: <51806667-28bb-44b7-8aab-6caa586549ed@default> Thank you, Robbin. - jini. > -----Original Message----- > From: Robbin Ehn > Sent: Wednesday, November 16, 2016 2:41 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8169638: serviceability/sa/TestInstanceKlassSize.java > and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > > Looks good! > > /Robbin > > On 11/16/2016 08:59 AM, Jini Susan George wrote: > > Requesting a review of the small fix for: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8169638 > > > > > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169638/webrev.00/ > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > From dmitry.samersoff at oracle.com Wed Nov 16 10:36:28 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 16 Nov 2016 13:36:28 +0300 Subject: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 In-Reply-To: <1cd79b1c-1aa6-4048-b9a0-0164de4b2938@default> References: <1cd79b1c-1aa6-4048-b9a0-0164de4b2938@default> Message-ID: <162cb1de-a75d-2375-9993-0e853803207a@oracle.com> Jini, Looks good to me! -Dmitry On 2016-11-16 07:28, Jini Susan George wrote: > Requesting a review of a possible fix for the following issue: > > > > https://bugs.openjdk.java.net/browse/JDK-8169232 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169232/webrev.00/ > > > > Details have been outlined in the bug. > > > > Thanks, > > - Jini Susan George > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Wed Nov 16 10:44:12 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 16 Nov 2016 02:44:12 -0800 (PST) Subject: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 In-Reply-To: <162cb1de-a75d-2375-9993-0e853803207a@oracle.com> References: <1cd79b1c-1aa6-4048-b9a0-0164de4b2938@default> <162cb1de-a75d-2375-9993-0e853803207a@oracle.com> Message-ID: <1fc725c8-9b79-497c-b247-4dbe00cbb04b@default> Thank you, Dmitry ! -jini > -----Original Message----- > From: Dmitry Samersoff > Sent: Wednesday, November 16, 2016 4:06 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails > with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: > should have found entry 1 > > Jini, > > Looks good to me! > > -Dmitry > > On 2016-11-16 07:28, Jini Susan George wrote: > > Requesting a review of a possible fix for the following issue: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8169232 > > > > > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169232/webrev.00/ > > > > > > > > Details have been outlined in the bug. > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From harsha.wardhana.b at oracle.com Thu Nov 17 13:14:15 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 17 Nov 2016 18:44:15 +0530 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: <681b1444-dc8a-6ac1-8f8a-7a6eb31b0dda@oracle.com> References: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> <92a22820-d0ac-e35a-c62b-3983efd029f5@oracle.com> <3fd0a9e4-f9bb-12e3-8462-0c4cb56040b6@oracle.com> <857a5e3b-4995-9875-6908-ec4eac9a6799@oracle.com> <681b1444-dc8a-6ac1-8f8a-7a6eb31b0dda@oracle.com> Message-ID: Hello, Gentle reminder !! -Harsha On Tuesday 15 November 2016 02:16 PM, Harsha Wardhana B wrote: > > Hello, > > Please review below webrev incorporating Daniel's comments. > > http://cr.openjdk.java.net/~hb/8141591/webrev.01/ > > Regards > Harsha > > On Monday 14 November 2016 04:14 PM, Daniel Fuchs wrote: >> On 14/11/16 06:57, Harsha Wardhana B wrote: >>>>> Well, that will not cover the case where user shuts down executor but >>>>> keeps the client/server alive. So we will need a executor that can >>>>> keep >>>>> notif system running as well as do clean-up if client/server is >>>>> closed. >>>> >>>> It's OK to continue in order to do clean up and >>>> shutdown gracefully. It seems wrong to keep going afterwards >>>> as if nothing had happened though (in the case the >>>> user shuts the supplied executor down). >>> With current changes, we do continue to carry on with linear executor. >>> If the user wants to shutdown the system, he can always do it by >>> shutting down client and server along with executor. If he shuts down >>> executor but not client/server, it may be safe to assume that he wants >>> the system to be up and running. It may not be appropriate to assume >>> user wants to shutdown notif system just because he shutdown executor. >> >> Well, it may also not be appropriate to invoke a user provided callback >> on another executor than the one provided by the user. >> If the user provides an executor, we must assume he has good >> reasons to do so. >> I'm not hard set to opposing to what you propose, but it makes me >> feel uncomfortable. >> >> best regards, >> >> -- daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Nov 18 03:52:38 2016 From: jini.george at oracle.com (Jini Susan George) Date: Thu, 17 Nov 2016 19:52:38 -0800 (PST) Subject: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 In-Reply-To: <162cb1de-a75d-2375-9993-0e853803207a@oracle.com> References: <1cd79b1c-1aa6-4048-b9a0-0164de4b2938@default> <162cb1de-a75d-2375-9993-0e853803207a@oracle.com> Message-ID: <23513147-7aa9-40a8-918d-a289a7051a3f@default> Could I get one more reviewer to take a look at this, please? Thanks, Jini. > -----Original Message----- > From: Dmitry Samersoff > Sent: Wednesday, November 16, 2016 4:06 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails > with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: > should have found entry 1 > > Jini, > > Looks good to me! > > -Dmitry > > On 2016-11-16 07:28, Jini Susan George wrote: > > Requesting a review of a possible fix for the following issue: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8169232 > > > > > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8169232/webrev.00/ > > > > > > > > Details have been outlined in the bug. > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From amy.lu at oracle.com Fri Nov 18 04:53:27 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 18 Nov 2016 12:53:27 +0800 Subject: JDK 9 RFR of JDK-8169836: ProblemList update for java/lang/management/MemoryMXBean/PendingAllGC.sh Message-ID: <43f09a59-47d9-e15f-d559-5df68db992b3@oracle.com> Please review the patch to correct the bugid in ProblemList.txt for test java/lang/management/MemoryMXBean/PendingAllGC.sh bug: https://bugs.openjdk.java.net/browse/JDK-8169836 Thanks, Amy --- old/test/ProblemList.txt 2016-11-18 12:49:58.000000000 +0800 +++ new/test/ProblemList.txt 2016-11-18 12:49:58.000000000 +0800 @@ -135,7 +135,7 @@ java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 macosx-all java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all -java/lang/management/MemoryMXBean/PendingAllGC.sh 8158760 generic-all +java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all ############################################################################ From mandy.chung at oracle.com Fri Nov 18 06:23:51 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Nov 2016 22:23:51 -0800 Subject: JDK 9 RFR of JDK-8169836: ProblemList update for java/lang/management/MemoryMXBean/PendingAllGC.sh In-Reply-To: <43f09a59-47d9-e15f-d559-5df68db992b3@oracle.com> References: <43f09a59-47d9-e15f-d559-5df68db992b3@oracle.com> Message-ID: +1 Mandy > On Nov 17, 2016, at 8:53 PM, Amy Lu wrote: > > Please review the patch to correct the bugid in ProblemList.txt for test > java/lang/management/MemoryMXBean/PendingAllGC.sh > > bug: https://bugs.openjdk.java.net/browse/JDK-8169836 > > Thanks, > Amy > > > --- old/test/ProblemList.txt 2016-11-18 12:49:58.000000000 +0800 > +++ new/test/ProblemList.txt 2016-11-18 12:49:58.000000000 +0800 > @@ -135,7 +135,7 @@ > java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 macosx-all > > java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all > -java/lang/management/MemoryMXBean/PendingAllGC.sh 8158760 generic-all > +java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all > > ############################################################################ > > From amy.lu at oracle.com Fri Nov 18 06:40:09 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 18 Nov 2016 14:40:09 +0800 Subject: JDK 9 RFR of JDK-8169836: ProblemList update for java/lang/management/MemoryMXBean/PendingAllGC.sh In-Reply-To: References: <43f09a59-47d9-e15f-d559-5df68db992b3@oracle.com> Message-ID: <93e962b9-bed3-638c-be26-9953a0eba0d7@oracle.com> Thank you Mandy for reviewing! Thanks, Amy On 11/18/16 2:23 PM, Mandy Chung wrote: > +1 > > Mandy > >> On Nov 17, 2016, at 8:53 PM, Amy Lu wrote: >> >> Please review the patch to correct the bugid in ProblemList.txt for test >> java/lang/management/MemoryMXBean/PendingAllGC.sh >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8169836 >> >> Thanks, >> Amy >> >> >> --- old/test/ProblemList.txt 2016-11-18 12:49:58.000000000 +0800 >> +++ new/test/ProblemList.txt 2016-11-18 12:49:58.000000000 +0800 >> @@ -135,7 +135,7 @@ >> java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 macosx-all >> >> java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all >> -java/lang/management/MemoryMXBean/PendingAllGC.sh 8158760 generic-all >> +java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all >> >> ############################################################################ >> >> From amy.lu at oracle.com Fri Nov 18 06:57:15 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 18 Nov 2016 14:57:15 +0800 Subject: JDK 9 RFR of JDK-8169949: Remove java/lang/instrument/BootClassPath/BootClassPathTest.sh from ProblemList.txt Message-ID: Please review the patch to bring back test: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX As mentioned in JDK-8072130, failure is not reproducible. I also tested it with different version of macOS, test all pass. JPRT results for all platforms are good, test pass. bug: https://bugs.openjdk.java.net/browse/JDK-8169949 Thanks, Amy --- old/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 +++ new/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 @@ -132,8 +132,6 @@ java/lang/instrument/RedefineBigClass.sh 8065756 generic-all java/lang/instrument/RetransformBigClass.sh 8065756 generic-all -java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 macosx-all - java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all From harsha.wardhana.b at oracle.com Fri Nov 18 09:47:54 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 18 Nov 2016 15:17:54 +0530 Subject: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip Message-ID: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> Hello All, Please review below fix for issue https://bugs.openjdk.java.net/browse/JDK-8169575 having webrev at, http://cr.openjdk.java.net/~hb/8169575/webrev.00/ Regards Harsha From frederic.parain at oracle.com Fri Nov 18 14:19:41 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 18 Nov 2016 09:19:41 -0500 Subject: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip In-Reply-To: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> References: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> Message-ID: <5c868191-5db4-1a04-ad91-4f327bac8bcf@oracle.com> Looks good to me. Fred On 11/18/2016 04:47 AM, Harsha Wardhana B wrote: > Hello All, > > Please review below fix for issue > > https://bugs.openjdk.java.net/browse/JDK-8169575 > > having webrev at, > > http://cr.openjdk.java.net/~hb/8169575/webrev.00/ > > Regards > > Harsha > From Roger.Riggs at Oracle.com Fri Nov 18 14:18:30 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 18 Nov 2016 09:18:30 -0500 Subject: JDK 9 RFR of JDK-8169949: Remove java/lang/instrument/BootClassPath/BootClassPathTest.sh from ProblemList.txt In-Reply-To: References: Message-ID: <99f7d1d5-2684-1a59-a73e-39427ef44b18@Oracle.com> Looks fine. Roger On 11/18/2016 1:57 AM, Amy Lu wrote: > Please review the patch to bring back test: > java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX > > As mentioned in JDK-8072130, failure is not reproducible. > I also tested it with different version of macOS, test all pass. JPRT > results for all platforms are good, test pass. > > bug: https://bugs.openjdk.java.net/browse/JDK-8169949 > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 > +++ new/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 > @@ -132,8 +132,6 @@ > java/lang/instrument/RedefineBigClass.sh 8065756 generic-all > java/lang/instrument/RetransformBigClass.sh 8065756 generic-all > > -java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 > macosx-all > - > java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all > java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all > > From Roger.Riggs at Oracle.com Fri Nov 18 15:28:09 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 18 Nov 2016 10:28:09 -0500 Subject: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip In-Reply-To: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> References: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> Message-ID: Hi Harsha, The addition of the permission for "getProperty.jdk.jar.disabledAlgorithms" is fine. But the addition of a permission for exitVM.95 to satisfy the need of the test harness to exit cleanly should instead be fixed by changing the "exitVM.97" to "exitVM.*" to avoid future maintenance in the case where the test harness changes its exit status. Roger On 11/18/2016 4:47 AM, Harsha Wardhana B wrote: > Hello All, > > Please review below fix for issue > > https://bugs.openjdk.java.net/browse/JDK-8169575 > > having webrev at, > > http://cr.openjdk.java.net/~hb/8169575/webrev.00/ > > Regards > > Harsha > From harsha.wardhana.b at oracle.com Fri Nov 18 15:32:21 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 18 Nov 2016 21:02:21 +0530 Subject: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip In-Reply-To: References: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> Message-ID: Hi Roger, I was not sure about adding exitVM.* as that would give permissions for all exit codes. Maybe Fred can comment since he is the test case author. -Harsha On Friday 18 November 2016 08:58 PM, Roger Riggs wrote: > Hi Harsha, > > The addition of the permission for > "getProperty.jdk.jar.disabledAlgorithms" is fine. > > But the addition of a permission for exitVM.95 to satisfy the need of > the test harness to exit cleanly > should instead be fixed by changing the "exitVM.97" to "exitVM.*" to > avoid future maintenance > in the case where the test harness changes its exit status. > > Roger > > > On 11/18/2016 4:47 AM, Harsha Wardhana B wrote: >> Hello All, >> >> Please review below fix for issue >> >> https://bugs.openjdk.java.net/browse/JDK-8169575 >> >> having webrev at, >> >> http://cr.openjdk.java.net/~hb/8169575/webrev.00/ >> >> Regards >> >> Harsha >> > From frederic.parain at oracle.com Fri Nov 18 15:38:37 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 18 Nov 2016 10:38:37 -0500 Subject: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip In-Reply-To: References: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> Message-ID: <7f1df59e-9d1b-bc1f-6206-666b57546777@oracle.com> "exitVM.*" should be fine to avoid future maintenance burden. Thank you for pointing this out Roger. Fred On 11/18/2016 10:32 AM, Harsha Wardhana B wrote: > Hi Roger, > > I was not sure about adding exitVM.* as that would give permissions for > all exit codes. > > Maybe Fred can comment since he is the test case author. > > -Harsha > > > On Friday 18 November 2016 08:58 PM, Roger Riggs wrote: >> Hi Harsha, >> >> The addition of the permission for >> "getProperty.jdk.jar.disabledAlgorithms" is fine. >> >> But the addition of a permission for exitVM.95 to satisfy the need of >> the test harness to exit cleanly >> should instead be fixed by changing the "exitVM.97" to "exitVM.*" to >> avoid future maintenance >> in the case where the test harness changes its exit status. >> >> Roger >> >> >> On 11/18/2016 4:47 AM, Harsha Wardhana B wrote: >>> Hello All, >>> >>> Please review below fix for issue >>> >>> https://bugs.openjdk.java.net/browse/JDK-8169575 >>> >>> having webrev at, >>> >>> http://cr.openjdk.java.net/~hb/8169575/webrev.00/ >>> >>> Regards >>> >>> Harsha >>> >> > From harsha.wardhana.b at oracle.com Fri Nov 18 15:43:25 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 18 Nov 2016 21:13:25 +0530 Subject: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip In-Reply-To: <7f1df59e-9d1b-bc1f-6206-666b57546777@oracle.com> References: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> <7f1df59e-9d1b-bc1f-6206-666b57546777@oracle.com> Message-ID: Hello, Please review below webrev incorporating Roger's comment. http://cr.openjdk.java.net/~hb/8169575/webrev.01/ -Harsha On Friday 18 November 2016 09:08 PM, Frederic Parain wrote: > "exitVM.*" should be fine to avoid future maintenance burden. > Thank you for pointing this out Roger. > > Fred > > On 11/18/2016 10:32 AM, Harsha Wardhana B wrote: >> Hi Roger, >> >> I was not sure about adding exitVM.* as that would give permissions for >> all exit codes. >> >> Maybe Fred can comment since he is the test case author. >> >> -Harsha >> >> >> On Friday 18 November 2016 08:58 PM, Roger Riggs wrote: >>> Hi Harsha, >>> >>> The addition of the permission for >>> "getProperty.jdk.jar.disabledAlgorithms" is fine. >>> >>> But the addition of a permission for exitVM.95 to satisfy the need of >>> the test harness to exit cleanly >>> should instead be fixed by changing the "exitVM.97" to "exitVM.*" to >>> avoid future maintenance >>> in the case where the test harness changes its exit status. >>> >>> Roger >>> >>> >>> On 11/18/2016 4:47 AM, Harsha Wardhana B wrote: >>>> Hello All, >>>> >>>> Please review below fix for issue >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8169575 >>>> >>>> having webrev at, >>>> >>>> http://cr.openjdk.java.net/~hb/8169575/webrev.00/ >>>> >>>> Regards >>>> >>>> Harsha >>>> >>> >> From Roger.Riggs at Oracle.com Fri Nov 18 15:56:11 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 18 Nov 2016 10:56:11 -0500 Subject: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip In-Reply-To: References: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> <7f1df59e-9d1b-bc1f-6206-666b57546777@oracle.com> Message-ID: +1 On 11/18/2016 10:43 AM, Harsha Wardhana B wrote: > Hello, > > Please review below webrev incorporating Roger's comment. > > http://cr.openjdk.java.net/~hb/8169575/webrev.01/ > > -Harsha > > > On Friday 18 November 2016 09:08 PM, Frederic Parain wrote: >> "exitVM.*" should be fine to avoid future maintenance burden. >> Thank you for pointing this out Roger. >> >> Fred >> >> On 11/18/2016 10:32 AM, Harsha Wardhana B wrote: >>> Hi Roger, >>> >>> I was not sure about adding exitVM.* as that would give permissions for >>> all exit codes. >>> >>> Maybe Fred can comment since he is the test case author. >>> >>> -Harsha >>> >>> >>> On Friday 18 November 2016 08:58 PM, Roger Riggs wrote: >>>> Hi Harsha, >>>> >>>> The addition of the permission for >>>> "getProperty.jdk.jar.disabledAlgorithms" is fine. >>>> >>>> But the addition of a permission for exitVM.95 to satisfy the need of >>>> the test harness to exit cleanly >>>> should instead be fixed by changing the "exitVM.97" to "exitVM.*" to >>>> avoid future maintenance >>>> in the case where the test harness changes its exit status. >>>> >>>> Roger >>>> >>>> >>>> On 11/18/2016 4:47 AM, Harsha Wardhana B wrote: >>>>> Hello All, >>>>> >>>>> Please review below fix for issue >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8169575 >>>>> >>>>> having webrev at, >>>>> >>>>> http://cr.openjdk.java.net/~hb/8169575/webrev.00/ >>>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>> >>> > From frederic.parain at oracle.com Fri Nov 18 15:59:33 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 18 Nov 2016 10:59:33 -0500 Subject: RFR - 8169575: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java failing with jtreg tip In-Reply-To: References: <07687900-179c-b7a6-0726-7ffec91a4183@oracle.com> <7f1df59e-9d1b-bc1f-6206-666b57546777@oracle.com> Message-ID: <2f1ac291-c23b-0eab-545c-2f8f6b0915d4@oracle.com> Thumbs up. Fred On 11/18/2016 10:43 AM, Harsha Wardhana B wrote: > Hello, > > Please review below webrev incorporating Roger's comment. > > http://cr.openjdk.java.net/~hb/8169575/webrev.01/ > > -Harsha > > > On Friday 18 November 2016 09:08 PM, Frederic Parain wrote: >> "exitVM.*" should be fine to avoid future maintenance burden. >> Thank you for pointing this out Roger. >> >> Fred >> >> On 11/18/2016 10:32 AM, Harsha Wardhana B wrote: >>> Hi Roger, >>> >>> I was not sure about adding exitVM.* as that would give permissions for >>> all exit codes. >>> >>> Maybe Fred can comment since he is the test case author. >>> >>> -Harsha >>> >>> >>> On Friday 18 November 2016 08:58 PM, Roger Riggs wrote: >>>> Hi Harsha, >>>> >>>> The addition of the permission for >>>> "getProperty.jdk.jar.disabledAlgorithms" is fine. >>>> >>>> But the addition of a permission for exitVM.95 to satisfy the need of >>>> the test harness to exit cleanly >>>> should instead be fixed by changing the "exitVM.97" to "exitVM.*" to >>>> avoid future maintenance >>>> in the case where the test harness changes its exit status. >>>> >>>> Roger >>>> >>>> >>>> On 11/18/2016 4:47 AM, Harsha Wardhana B wrote: >>>>> Hello All, >>>>> >>>>> Please review below fix for issue >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8169575 >>>>> >>>>> having webrev at, >>>>> >>>>> http://cr.openjdk.java.net/~hb/8169575/webrev.00/ >>>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>> >>> > From serguei.spitsyn at oracle.com Sat Nov 19 00:49:05 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Nov 2016 16:49:05 -0800 Subject: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 In-Reply-To: <23513147-7aa9-40a8-918d-a289a7051a3f@default> References: <1cd79b1c-1aa6-4048-b9a0-0164de4b2938@default> <162cb1de-a75d-2375-9993-0e853803207a@oracle.com> <23513147-7aa9-40a8-918d-a289a7051a3f@default> Message-ID: <85954881-72ad-fc54-e599-840c4d67aa56@oracle.com> Hi Jini, This looks good to me. Thanks, Serguei On 11/17/16 19:52, Jini Susan George wrote: > Could I get one more reviewer to take a look at this, please? > Thanks, > Jini. > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Wednesday, November 16, 2016 4:06 PM >> To: Jini Susan George; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails >> with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: >> should have found entry 1 >> >> Jini, >> >> Looks good to me! >> >> -Dmitry >> >> On 2016-11-16 07:28, Jini Susan George wrote: >>> Requesting a review of a possible fix for the following issue: >>> >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8169232 >>> >>> >>> >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8169232/webrev.00/ >>> >>> >>> >>> Details have been outlined in the bug. >>> >>> >>> >>> Thanks, >>> >>> - Jini Susan George >>> >>> >>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Sat Nov 19 09:15:51 2016 From: jini.george at oracle.com (Jini Susan George) Date: Sat, 19 Nov 2016 01:15:51 -0800 (PST) Subject: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 In-Reply-To: <85954881-72ad-fc54-e599-840c4d67aa56@oracle.com> References: <1cd79b1c-1aa6-4048-b9a0-0164de4b2938@default> <162cb1de-a75d-2375-9993-0e853803207a@oracle.com> <23513147-7aa9-40a8-918d-a289a7051a3f@default> <85954881-72ad-fc54-e599-840c4d67aa56@oracle.com> Message-ID: Thank you, Serguei! -jini > -----Original Message----- > From: Serguei Spitsyn > Sent: Saturday, November 19, 2016 6:19 AM > To: Jini Susan George; Dmitry Samersoff; serviceability- > dev at openjdk.java.net > Subject: Re: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails > with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: > should have found entry 1 > > Hi Jini, > > This looks good to me. > > Thanks, > Serguei > > > On 11/17/16 19:52, Jini Susan George wrote: > > Could I get one more reviewer to take a look at this, please? > > Thanks, > > Jini. > > > >> -----Original Message----- > >> From: Dmitry Samersoff > >> Sent: Wednesday, November 16, 2016 4:06 PM > >> To: Jini Susan George; serviceability-dev at openjdk.java.net > >> Subject: Re: RFR: JDK-8169232: SA: TestCpoolForInvokeDynamic.java fails > >> with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: > >> should have found entry 1 > >> > >> Jini, > >> > >> Looks good to me! > >> > >> -Dmitry > >> > >> On 2016-11-16 07:28, Jini Susan George wrote: > >>> Requesting a review of a possible fix for the following issue: > >>> > >>> > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8169232 > >>> > >>> > >>> > >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8169232/webrev.00/ > >>> > >>> > >>> > >>> Details have been outlined in the bug. > >>> > >>> > >>> > >>> Thanks, > >>> > >>> - Jini Susan George > >>> > >>> > >>> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > From daniel.fuchs at oracle.com Mon Nov 21 09:56:57 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 21 Nov 2016 09:56:57 +0000 Subject: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently In-Reply-To: References: <0b9a0472-3626-6b7a-6d76-c26de7026ba5@oracle.com> <10f67f73-2413-d16c-5d79-05435e8a9732@oracle.com> <92a22820-d0ac-e35a-c62b-3983efd029f5@oracle.com> <3fd0a9e4-f9bb-12e3-8462-0c4cb56040b6@oracle.com> <857a5e3b-4995-9875-6908-ec4eac9a6799@oracle.com> <681b1444-dc8a-6ac1-8f8a-7a6eb31b0dda@oracle.com> Message-ID: <715872ac-2d13-2282-ffdf-e102e0478926@oracle.com> Hi Harsha, I'm still unsure that creating a new executor is the right solution, but we can give it a try... good to go. best regards, -- daniel On 17/11/16 13:14, Harsha Wardhana B wrote: > Hello, > > Gentle reminder !! > > -Harsha > > > On Tuesday 15 November 2016 02:16 PM, Harsha Wardhana B wrote: >> >> Hello, >> >> Please review below webrev incorporating Daniel's comments. >> >> http://cr.openjdk.java.net/~hb/8141591/webrev.01/ >> >> Regards >> Harsha >> >> On Monday 14 November 2016 04:14 PM, Daniel Fuchs wrote: >>> On 14/11/16 06:57, Harsha Wardhana B wrote: >>>>>> Well, that will not cover the case where user shuts down executor but >>>>>> keeps the client/server alive. So we will need a executor that can >>>>>> keep >>>>>> notif system running as well as do clean-up if client/server is >>>>>> closed. >>>>> >>>>> It's OK to continue in order to do clean up and >>>>> shutdown gracefully. It seems wrong to keep going afterwards >>>>> as if nothing had happened though (in the case the >>>>> user shuts the supplied executor down). >>>> With current changes, we do continue to carry on with linear executor. >>>> If the user wants to shutdown the system, he can always do it by >>>> shutting down client and server along with executor. If he shuts down >>>> executor but not client/server, it may be safe to assume that he wants >>>> the system to be up and running. It may not be appropriate to assume >>>> user wants to shutdown notif system just because he shutdown executor. >>> >>> Well, it may also not be appropriate to invoke a user provided callback >>> on another executor than the one provided by the user. >>> If the user provides an executor, we must assume he has good >>> reasons to do so. >>> I'm not hard set to opposing to what you propose, but it makes me >>> feel uncomfortable. >>> >>> best regards, >>> >>> -- daniel >> > From amy.lu at oracle.com Wed Nov 23 02:35:25 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 23 Nov 2016 10:35:25 +0800 Subject: JDK 9 RFR of JDK-8169949: Remove java/lang/instrument/BootClassPath/BootClassPathTest.sh from ProblemList.txt In-Reply-To: References: Message-ID: <2f959df9-672f-bb2b-c577-c2d8f6c75b4f@oracle.com> Please review. Thanks, Amy On 11/18/16 2:57 PM, Amy Lu wrote: > Please review the patch to bring back test: > java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX > > As mentioned in JDK-8072130, failure is not reproducible. > I also tested it with different version of macOS, test all pass. JPRT > results for all platforms are good, test pass. > > bug: https://bugs.openjdk.java.net/browse/JDK-8169949 > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 > +++ new/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 > @@ -132,8 +132,6 @@ > java/lang/instrument/RedefineBigClass.sh 8065756 generic-all > java/lang/instrument/RetransformBigClass.sh 8065756 generic-all > > -java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 > macosx-all > - > java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all > java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all > > From mandy.chung at oracle.com Wed Nov 23 02:38:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Nov 2016 18:38:24 -0800 Subject: JDK 9 RFR of JDK-8169949: Remove java/lang/instrument/BootClassPath/BootClassPathTest.sh from ProblemList.txt In-Reply-To: <2f959df9-672f-bb2b-c577-c2d8f6c75b4f@oracle.com> References: <2f959df9-672f-bb2b-c577-c2d8f6c75b4f@oracle.com> Message-ID: <59AD1B9D-9F1B-4455-9344-5382A5B1BD1E@oracle.com> +1 Mandy > On Nov 22, 2016, at 6:35 PM, Amy Lu wrote: > > Please review. > > Thanks, > Amy > > On 11/18/16 2:57 PM, Amy Lu wrote: >> Please review the patch to bring back test: >> java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX >> >> As mentioned in JDK-8072130, failure is not reproducible. >> I also tested it with different version of macOS, test all pass. JPRT results for all platforms are good, test pass. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8169949 >> >> Thanks, >> Amy >> >> --- old/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 >> +++ new/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 >> @@ -132,8 +132,6 @@ >> java/lang/instrument/RedefineBigClass.sh 8065756 generic-all >> java/lang/instrument/RetransformBigClass.sh 8065756 generic-all >> >> -java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 macosx-all >> - >> java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all >> java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all >> >> > From david.holmes at oracle.com Wed Nov 23 02:40:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Nov 2016 12:40:09 +1000 Subject: JDK 9 RFR of JDK-8169949: Remove java/lang/instrument/BootClassPath/BootClassPathTest.sh from ProblemList.txt In-Reply-To: <2f959df9-672f-bb2b-c577-c2d8f6c75b4f@oracle.com> References: <2f959df9-672f-bb2b-c577-c2d8f6c75b4f@oracle.com> Message-ID: <33569dc3-2599-22b8-9942-6de438e08855@oracle.com> Hi Amy, On 23/11/2016 12:35 PM, Amy Lu wrote: > Please review. > > Thanks, > Amy > > On 11/18/16 2:57 PM, Amy Lu wrote: >> Please review the patch to bring back test: >> java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX >> >> As mentioned in JDK-8072130, failure is not reproducible. JDK-8072130 is not closed but marked incomplete. The problem was observed on an internal test system and access to such a system was requested and not forthcoming - hence the bug remains open. >> I also tested it with different version of macOS, test all pass. JPRT >> results for all platforms are good, test pass. JPRT was not the issue, nor was local testing. Have you tested on the system that was causing the failures? Thanks, David ----- >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8169949 >> >> Thanks, >> Amy >> >> --- old/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 >> +++ new/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 >> @@ -132,8 +132,6 @@ >> java/lang/instrument/RedefineBigClass.sh 8065756 generic-all >> java/lang/instrument/RetransformBigClass.sh 8065756 generic-all >> >> -java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 >> macosx-all >> - >> java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all >> java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all >> >> > From david.holmes at oracle.com Wed Nov 23 03:56:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Nov 2016 13:56:24 +1000 Subject: JDK 9 RFR of JDK-8169949: Remove java/lang/instrument/BootClassPath/BootClassPathTest.sh from ProblemList.txt In-Reply-To: <33569dc3-2599-22b8-9942-6de438e08855@oracle.com> References: <2f959df9-672f-bb2b-c577-c2d8f6c75b4f@oracle.com> <33569dc3-2599-22b8-9942-6de438e08855@oracle.com> Message-ID: <78a07ac7-6600-da9c-efd1-bf438b76a118@oracle.com> The system that has the problem will not by default run this test so to allow the test to continue to provide some test coverage value it can be reenabled. Though as per the bug report the typical execution environment of this test is such that it passes in a trivial manner. Thanks, David On 23/11/2016 12:40 PM, David Holmes wrote: > Hi Amy, > > On 23/11/2016 12:35 PM, Amy Lu wrote: >> Please review. >> >> Thanks, >> Amy >> >> On 11/18/16 2:57 PM, Amy Lu wrote: >>> Please review the patch to bring back test: >>> java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX >>> >>> As mentioned in JDK-8072130, failure is not reproducible. > > JDK-8072130 is not closed but marked incomplete. The problem was > observed on an internal test system and access to such a system was > requested and not forthcoming - hence the bug remains open. > >>> I also tested it with different version of macOS, test all pass. JPRT >>> results for all platforms are good, test pass. > > JPRT was not the issue, nor was local testing. Have you tested on the > system that was causing the failures? > > Thanks, > David > ----- > >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8169949 >>> >>> Thanks, >>> Amy >>> >>> --- old/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 >>> +++ new/test/ProblemList.txt 2016-11-18 14:51:43.000000000 +0800 >>> @@ -132,8 +132,6 @@ >>> java/lang/instrument/RedefineBigClass.sh 8065756 generic-all >>> java/lang/instrument/RetransformBigClass.sh 8065756 generic-all >>> >>> -java/lang/instrument/BootClassPath/BootClassPathTest.sh 8072130 >>> macosx-all >>> - >>> java/lang/management/MemoryMXBean/Pending.java 8158837 generic-all >>> java/lang/management/MemoryMXBean/PendingAllGC.sh 8158837 generic-all >>> >>> >> From ujwal.vangapally at oracle.com Wed Nov 23 09:08:13 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Wed, 23 Nov 2016 14:38:13 +0530 Subject: RFR: JDK-8165765: javax/management/remote/mandatory/connection/RMIConnectionIdTest.java: failed when looking at RMI connection IDs: Message-ID: <38330779-5d67-3e4e-bbe0-54670542c1e0@oracle.com> Please review this small change for the bug below https://bugs.openjdk.java.net/browse/JDK-8165765 Webrev: http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.00/ Thanks, Ujwal. From Roger.Riggs at Oracle.com Wed Nov 23 16:40:37 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 23 Nov 2016 11:40:37 -0500 Subject: RFR: JDK-8165765: javax/management/remote/mandatory/connection/RMIConnectionIdTest.java: failed when looking at RMI connection IDs: In-Reply-To: <38330779-5d67-3e4e-bbe0-54670542c1e0@oracle.com> References: <38330779-5d67-3e4e-bbe0-54670542c1e0@oracle.com> Message-ID: <96a739db-2193-4e63-cac9-f15d877dcca6@Oracle.com> Hi, RMIConnectionIdTest.java: - The method NetworkInterface.getByInetAddress(addr) may be a better choice without all the looping and repetitive checks of localAddr == null. Roger p.s. This would have been a good use of streams with NetworkInterface.networkInterfaces and NetworkInterface.inetAddresses. On 11/23/2016 4:08 AM, Ujwal Vangapally wrote: > Please review this small change for the bug below > > https://bugs.openjdk.java.net/browse/JDK-8165765 > > Webrev: http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.00/ > > Thanks, > > Ujwal. > > > From ujwal.vangapally at oracle.com Thu Nov 24 08:20:00 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Thu, 24 Nov 2016 13:50:00 +0530 Subject: RFR: JDK-8165765: javax/management/remote/mandatory/connection/RMIConnectionIdTest.java: failed when looking at RMI connection IDs: In-Reply-To: <96a739db-2193-4e63-cac9-f15d877dcca6@Oracle.com> References: <38330779-5d67-3e4e-bbe0-54670542c1e0@oracle.com> <96a739db-2193-4e63-cac9-f15d877dcca6@Oracle.com> Message-ID: <78970f02-1a5e-a369-a0df-49a174d2f0c3@oracle.com> Thanks for the review Roger, please find the new webrev incorporating the review comments. webrev :http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.01/ -Ujwal On 11/23/2016 10:10 PM, Roger Riggs wrote: > Hi, > > RMIConnectionIdTest.java: > > - The method NetworkInterface.getByInetAddress(addr) may be a better > choice > without all the looping and repetitive checks of localAddr == null. > > Roger > > p.s. > > This would have been a good use of streams with > NetworkInterface.networkInterfaces > and NetworkInterface.inetAddresses. > > > On 11/23/2016 4:08 AM, Ujwal Vangapally wrote: >> Please review this small change for the bug below >> >> https://bugs.openjdk.java.net/browse/JDK-8165765 >> >> Webrev: http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.00/ >> >> Thanks, >> >> Ujwal. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ujwal.vangapally at oracle.com Mon Nov 28 04:47:13 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Mon, 28 Nov 2016 10:17:13 +0530 Subject: RFR: JDK-8165765: javax/management/remote/mandatory/connection/RMIConnectionIdTest.java: failed when looking at RMI connection IDs: In-Reply-To: <78970f02-1a5e-a369-a0df-49a174d2f0c3@oracle.com> References: <38330779-5d67-3e4e-bbe0-54670542c1e0@oracle.com> <96a739db-2193-4e63-cac9-f15d877dcca6@Oracle.com> <78970f02-1a5e-a369-a0df-49a174d2f0c3@oracle.com> Message-ID: <3d5f3b42-9d0f-26c1-1fb9-b3dd8f0998cf@oracle.com> gentle reminder Thanks, Ujwal On 11/24/2016 1:50 PM, Ujwal Vangapally wrote: > > Thanks for the review Roger, please find the new webrev incorporating > the review comments. > > webrev :http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.01/ > > -Ujwal > > On 11/23/2016 10:10 PM, Roger Riggs wrote: >> Hi, >> >> RMIConnectionIdTest.java: >> >> - The method NetworkInterface.getByInetAddress(addr) may be a better >> choice >> without all the looping and repetitive checks of localAddr == null. >> >> Roger >> >> p.s. >> >> This would have been a good use of streams with >> NetworkInterface.networkInterfaces >> and NetworkInterface.inetAddresses. >> >> >> On 11/23/2016 4:08 AM, Ujwal Vangapally wrote: >>> Please review this small change for the bug below >>> >>> https://bugs.openjdk.java.net/browse/JDK-8165765 >>> >>> Webrev: http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.00/ >>> >>> Thanks, >>> >>> Ujwal. >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Mon Nov 28 14:41:42 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 28 Nov 2016 14:41:42 +0000 Subject: RFR 8170401: JConsole might use System.Logger Message-ID: <825c48de-42d9-a582-d3f0-6e1d7e440d0d@oracle.com> Hi, Please find below a trivial fix for 8170401: JConsole might use System.Logger https://bugs.openjdk.java.net/browse/JDK-8170401 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8170401/webrev.00/ best regards, -- daniel From mandy.chung at oracle.com Mon Nov 28 17:35:18 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 28 Nov 2016 09:35:18 -0800 Subject: RFR 8170401: JConsole might use System.Logger In-Reply-To: <825c48de-42d9-a582-d3f0-6e1d7e440d0d@oracle.com> References: <825c48de-42d9-a582-d3f0-6e1d7e440d0d@oracle.com> Message-ID: <4AFA3536-6710-4F02-AFC9-1FCDDDAA754D@oracle.com> +1 Mandy > On Nov 28, 2016, at 6:41 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a trivial fix for > > 8170401: JConsole might use System.Logger > https://bugs.openjdk.java.net/browse/JDK-8170401 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8170401/webrev.00/ > > best regards, > > -- daniel From Roger.Riggs at Oracle.com Mon Nov 28 21:42:01 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 28 Nov 2016 16:42:01 -0500 Subject: RFR: JDK-8165765: javax/management/remote/mandatory/connection/RMIConnectionIdTest.java: failed when looking at RMI connection IDs: In-Reply-To: <3d5f3b42-9d0f-26c1-1fb9-b3dd8f0998cf@oracle.com> References: <38330779-5d67-3e4e-bbe0-54670542c1e0@oracle.com> <96a739db-2193-4e63-cac9-f15d877dcca6@Oracle.com> <78970f02-1a5e-a369-a0df-49a174d2f0c3@oracle.com> <3d5f3b42-9d0f-26c1-1fb9-b3dd8f0998cf@oracle.com> Message-ID: <8961680e-9638-9c22-a883-71e5679a8300@Oracle.com> Hi Ujwal, looks fine. Have you been able to verify the test on a system similar to where it failed originally? Thanks, Roger On 11/27/2016 11:47 PM, Ujwal Vangapally wrote: > > gentle reminder > > Thanks, > > Ujwal > > > On 11/24/2016 1:50 PM, Ujwal Vangapally wrote: >> >> Thanks for the review Roger, please find the new webrev incorporating >> the review comments. >> >> webrev :http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.01/ >> >> -Ujwal >> >> On 11/23/2016 10:10 PM, Roger Riggs wrote: >>> Hi, >>> >>> RMIConnectionIdTest.java: >>> >>> - The method NetworkInterface.getByInetAddress(addr) may be a >>> better choice >>> without all the looping and repetitive checks of localAddr == null. >>> >>> Roger >>> >>> p.s. >>> >>> This would have been a good use of streams with >>> NetworkInterface.networkInterfaces >>> and NetworkInterface.inetAddresses. >>> >>> >>> On 11/23/2016 4:08 AM, Ujwal Vangapally wrote: >>>> Please review this small change for the bug below >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8165765 >>>> >>>> Webrev: http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Ujwal. >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Nov 29 00:01:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Nov 2016 10:01:57 +1000 Subject: [PATCH] 8168677: Typo in API docs for com.sun.tools.attach In-Reply-To: References: Message-ID: <62381a68-db3b-6525-9922-ba405da49f21@oracle.com> cc'ing serviceability-dev as they own this. Thanks for that Denis. David On 29/11/2016 9:01 AM, Denis Istomin wrote: > # HG changeset patch > # User Denis Istomin > # Date 1480189378 -18000 > # Sun Nov 27 00:42:58 2016 +0500 > # Node ID 5d6770e434e672a485a2cf0281c5828d4a04b346 > # Parent c9d97eff6bfd0d7376dc22d9be454f4136609df3 > Fix typo > > diff --git a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java > b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java > --- a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java > +++ b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java > @@ -29,7 +29,7 @@ > > /** > * Thrown by {@link com.sun.tools.attach.VirtualMachine#attach > - * VirtalMachine.attach} when attempting to attach to a Java virtual machine > + * VirtualMachine.attach} when attempting to attach to a Java virtual machine > * for which a compatible {@link com.sun.tools.attach.spi.AttachProvider > * AttachProvider} does not exist. It is also thrown by {@link > * com.sun.tools.attach.spi.AttachProvider#attachVirtualMachine > diff --git a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachPermission.java > b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachPermission.java > --- a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachPermission.java > +++ b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachPermission.java > @@ -28,7 +28,7 @@ > /** > * When a {@link java.lang.SecurityManager SecurityManager} set, this > * is the permission which will be checked when code invokes {@link > - * VirtualMachine#attach VirtalMachine.attach} to attach to a target virtual > + * VirtualMachine#attach VirtualMachine.attach} to attach to a target virtual > * machine. > * This permission is also checked when an {@link > * com.sun.tools.attach.spi.AttachProvider AttachProvider} is created. > From ujwal.vangapally at oracle.com Tue Nov 29 09:24:34 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Tue, 29 Nov 2016 14:54:34 +0530 Subject: RFR: JDK-8165765: javax/management/remote/mandatory/connection/RMIConnectionIdTest.java: failed when looking at RMI connection IDs: In-Reply-To: <8961680e-9638-9c22-a883-71e5679a8300@Oracle.com> References: <38330779-5d67-3e4e-bbe0-54670542c1e0@oracle.com> <96a739db-2193-4e63-cac9-f15d877dcca6@Oracle.com> <78970f02-1a5e-a369-a0df-49a174d2f0c3@oracle.com> <3d5f3b42-9d0f-26c1-1fb9-b3dd8f0998cf@oracle.com> <8961680e-9638-9c22-a883-71e5679a8300@Oracle.com> Message-ID: <34bdf08e-ac8d-9572-9118-0c45ee399a2c@oracle.com> Hi Roger, I didn't verify it on a similar system as it is difficult to find one , instead verified by just hard coding a InetAddress different from which it is picking by default to String clientAddr and executed the test . Thanks, Ujwal On 11/29/2016 3:12 AM, Roger Riggs wrote: > Hi Ujwal, > > looks fine. > > Have you been able to verify the test on a system similar to where it > failed originally? > > Thanks, Roger > > > > On 11/27/2016 11:47 PM, Ujwal Vangapally wrote: >> >> gentle reminder >> >> Thanks, >> >> Ujwal >> >> >> On 11/24/2016 1:50 PM, Ujwal Vangapally wrote: >>> >>> Thanks for the review Roger, please find the new webrev >>> incorporating the review comments. >>> >>> webrev :http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.01/ >>> >>> -Ujwal >>> >>> On 11/23/2016 10:10 PM, Roger Riggs wrote: >>>> Hi, >>>> >>>> RMIConnectionIdTest.java: >>>> >>>> - The method NetworkInterface.getByInetAddress(addr) may be a >>>> better choice >>>> without all the looping and repetitive checks of localAddr == null. >>>> >>>> Roger >>>> >>>> p.s. >>>> >>>> This would have been a good use of streams with >>>> NetworkInterface.networkInterfaces >>>> and NetworkInterface.inetAddresses. >>>> >>>> >>>> On 11/23/2016 4:08 AM, Ujwal Vangapally wrote: >>>>> Please review this small change for the bug below >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8165765 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Ujwal. >>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Tue Nov 29 14:41:44 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 29 Nov 2016 09:41:44 -0500 Subject: RFR: JDK-8165765: javax/management/remote/mandatory/connection/RMIConnectionIdTest.java: failed when looking at RMI connection IDs: In-Reply-To: <34bdf08e-ac8d-9572-9118-0c45ee399a2c@oracle.com> References: <38330779-5d67-3e4e-bbe0-54670542c1e0@oracle.com> <96a739db-2193-4e63-cac9-f15d877dcca6@Oracle.com> <78970f02-1a5e-a369-a0df-49a174d2f0c3@oracle.com> <3d5f3b42-9d0f-26c1-1fb9-b3dd8f0998cf@oracle.com> <8961680e-9638-9c22-a883-71e5679a8300@Oracle.com> <34bdf08e-ac8d-9572-9118-0c45ee399a2c@oracle.com> Message-ID: <3e802d44-7d7b-810c-9eef-e0f3b73662c6@Oracle.com> Hi Juwal, Ok, thanks for the followup. If you need a sponsor for this patch, let me know. Roger On 11/29/2016 4:24 AM, Ujwal Vangapally wrote: > > Hi Roger, > > I didn't verify it on a similar system as it is difficult to find one > , instead verified by just hard coding a InetAddress different from > which it is picking by default to String clientAddr and executed the > test . > > Thanks, > Ujwal > > > > On 11/29/2016 3:12 AM, Roger Riggs wrote: >> Hi Ujwal, >> >> looks fine. >> >> Have you been able to verify the test on a system similar to where it >> failed originally? >> >> Thanks, Roger >> >> >> >> On 11/27/2016 11:47 PM, Ujwal Vangapally wrote: >>> >>> gentle reminder >>> >>> Thanks, >>> >>> Ujwal >>> >>> >>> On 11/24/2016 1:50 PM, Ujwal Vangapally wrote: >>>> >>>> Thanks for the review Roger, please find the new webrev >>>> incorporating the review comments. >>>> >>>> webrev :http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.01/ >>>> >>>> -Ujwal >>>> >>>> On 11/23/2016 10:10 PM, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> RMIConnectionIdTest.java: >>>>> >>>>> - The method NetworkInterface.getByInetAddress(addr) may be a >>>>> better choice >>>>> without all the looping and repetitive checks of localAddr == >>>>> null. >>>>> >>>>> Roger >>>>> >>>>> p.s. >>>>> >>>>> This would have been a good use of streams with >>>>> NetworkInterface.networkInterfaces >>>>> and NetworkInterface.inetAddresses. >>>>> >>>>> >>>>> On 11/23/2016 4:08 AM, Ujwal Vangapally wrote: >>>>>> Please review this small change for the bug below >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8165765 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~hb/sponsorship/8165765/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ujwal. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: