From yekaterina.kantserova at oracle.com Thu Jul 9 10:39:50 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 09 Jul 2015 12:39:50 +0200 Subject: RFR(XSS): 8032763: Remove use of sun.misc.Ref from hprof parser in testlibrary Message-ID: <559E4F76.6000504@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8032763 webrev: http://cr.openjdk.java.net/~ykantser/8032763/webrev.00 Thanks, Katja From jaroslav.bachorik at oracle.com Thu Jul 9 10:41:04 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Jul 2015 12:41:04 +0200 Subject: RFR(XSS): 8032763: Remove use of sun.misc.Ref from hprof parser in testlibrary In-Reply-To: <559E4F76.6000504@oracle.com> References: <559E4F76.6000504@oracle.com> Message-ID: <559E4FC0.3000202@oracle.com> Looks good! -JB- On 9.7.2015 12:39, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8032763 > webrev: http://cr.openjdk.java.net/~ykantser/8032763/webrev.00 > > Thanks, > Katja From Alan.Bateman at oracle.com Thu Jul 9 10:41:26 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 Jul 2015 11:41:26 +0100 Subject: RFR(XSS): 8032763: Remove use of sun.misc.Ref from hprof parser in testlibrary In-Reply-To: <559E4F76.6000504@oracle.com> References: <559E4F76.6000504@oracle.com> Message-ID: <559E4FD6.3070402@oracle.com> On 09/07/2015 11:39, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8032763 > webrev: http://cr.openjdk.java.net/~ykantser/8032763/webrev.00 This looks okay to me, a reminder of HPROF's history. -Alan From yekaterina.kantserova at oracle.com Thu Jul 9 10:43:03 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 09 Jul 2015 12:43:03 +0200 Subject: RFR(XSS): 8032763: Remove use of sun.misc.Ref from hprof parser in testlibrary In-Reply-To: <559E4FC0.3000202@oracle.com> References: <559E4F76.6000504@oracle.com> <559E4FC0.3000202@oracle.com> Message-ID: <559E5037.2090904@oracle.com> Jaroslav, Alan, thanks for your reviews! // Katja On 07/09/2015 12:41 PM, Jaroslav Bachorik wrote: > Looks good! > > -JB- > > On 9.7.2015 12:39, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8032763 >> webrev: http://cr.openjdk.java.net/~ykantser/8032763/webrev.00 >> >> Thanks, >> Katja > From jaroslav.bachorik at oracle.com Thu Jul 9 16:45:35 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Jul 2015 18:45:35 +0200 Subject: RFR 8129976: RunFinalizationTest.java times out frequently Message-ID: <559EA52F.7000507@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8129976 Webrev: http://cr.openjdk.java.net/~jbachorik/8129976/webrev.00 The test, as it is now, most of the times does not test the desired functionality (that invoking GC.run_finalization DCMD actually runs finalization) because the preceding call to System.gc() will finalize the test object sooner. But without calling System.gc() it is non predictable when the test object will be eligible for finalization so we have to call System.gc(). In the rare occasions when System.gc() induced finalization does not finish before invoking GC.run_finalization the test deadlocks because its locking logic is flawed. In order to make this test work I had to: a\ Switch from '@run testng' to '@run main/othervm' b\ Run the finalization testing code in shutdown handler - this seems to prevent the finalization happening prematurely after calling System.gc() while still making the test object eligible for finalization c\ Switch from ReentrantLock to a Phaser for synchronization d\ Make sure that the finalization is not carried out on the default "Finalizer" thread to rule out finalization due to System.gc() After these changes the test seems to be rather stable (ran 1000 iterations in a tight loop without single failure). Thanks, -JB- From yekaterina.kantserova at oracle.com Fri Jul 10 12:55:16 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 10 Jul 2015 14:55:16 +0200 Subject: RFR(XS): 8076471: Remove hprof agent tests in JDK Message-ID: <559FC0B4.2070704@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8076471 webrev: http://cr.openjdk.java.net/~ykantser/8076471/webrev.00 More details can be found in JEP 240: Remove the JVM TI hprof Agent (https://bugs.openjdk.java.net/browse/JDK-8046661). Thanks, Katja From Alan.Bateman at oracle.com Fri Jul 10 12:59:57 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jul 2015 13:59:57 +0100 Subject: RFR(XS): 8076471: Remove hprof agent tests in JDK In-Reply-To: <559FC0B4.2070704@oracle.com> References: <559FC0B4.2070704@oracle.com> Message-ID: <559FC1CD.5080701@oracle.com> On 10/07/2015 13:55, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8076471 > webrev: http://cr.openjdk.java.net/~ykantser/8076471/webrev.00 > > More details can be found in JEP 240: Remove the JVM TI hprof Agent > (https://bugs.openjdk.java.net/browse/JDK-8046661). This looks okay to me although I would have thought they would be removed at the same time as the HPROF code. -Alan. From andreas.eriksson at oracle.com Fri Jul 10 11:20:58 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Fri, 10 Jul 2015 13:20:58 +0200 Subject: Jdk8 backports of 6904403 and 8044364 Message-ID: <559FAA9A.6030608@oracle.com> Hi, Just a heads up that I'm backporting these fixes to jdk8: https://bugs.openjdk.java.net/browse/JDK-6904403: assert(f == k->has_finalizer(),"inconsistent has_finalizer") with debug VM https://bugs.openjdk.java.net/browse/JDK-8044364: [TESTBUG] runtime/RedefineFinalizer test fails on windows Both of them applies cleanly from the jdk9 changesets (so no review required). http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c597dc3eb862 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/29d15865d20f Unless someone objects I'll get them pushed later today. - Andreas From yekaterina.kantserova at oracle.com Mon Jul 13 13:40:49 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 13 Jul 2015 15:40:49 +0200 Subject: RFR(XXS): 8131035: [TESTBUG] sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java needs to enable UsePerfData Message-ID: <55A3BFE1.5060109@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8131035 webrev: http://cr.openjdk.java.net/~ykantser/8131035/webrev.00 Thanks, Katja From jaroslav.bachorik at oracle.com Mon Jul 13 13:51:00 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 13 Jul 2015 15:51:00 +0200 Subject: RFR(XXS): 8131035: [TESTBUG] sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java needs to enable UsePerfData In-Reply-To: <55A3BFE1.5060109@oracle.com> References: <55A3BFE1.5060109@oracle.com> Message-ID: <55A3C244.9000207@oracle.com> Looks good! (btw, removing the 'author' tag was intentional?) -JB- On 13.7.2015 15:40, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8131035 > webrev: http://cr.openjdk.java.net/~ykantser/8131035/webrev.00 > > Thanks, > Katja From yekaterina.kantserova at oracle.com Mon Jul 13 13:55:31 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 13 Jul 2015 15:55:31 +0200 Subject: RFR(XXS): 8131035: [TESTBUG] sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java needs to enable UsePerfData In-Reply-To: <55A3C244.9000207@oracle.com> References: <55A3BFE1.5060109@oracle.com> <55A3C244.9000207@oracle.com> Message-ID: <55A3C353.2010803@oracle.com> Jaroslav, Thanks for the review! Yes, removing the 'author' tag was intentional. My understanding has been it's good to avoid 'author' tag. // Katja On 07/13/2015 03:51 PM, Jaroslav Bachorik wrote: > Looks good! > > (btw, removing the 'author' tag was intentional?) > > -JB- > > On 13.7.2015 15:40, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8131035 >> webrev: http://cr.openjdk.java.net/~ykantser/8131035/webrev.00 >> >> Thanks, >> Katja > From david.holmes at oracle.com Tue Jul 14 04:19:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jul 2015 14:19:14 +1000 Subject: RFR(XXS): 8131035: [TESTBUG] sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java needs to enable UsePerfData In-Reply-To: <55A3BFE1.5060109@oracle.com> References: <55A3BFE1.5060109@oracle.com> Message-ID: <55A48DC2.5050808@oracle.com> Ship it! :) Thanks, David On 13/07/2015 11:40 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8131035 > webrev: http://cr.openjdk.java.net/~ykantser/8131035/webrev.00 > > Thanks, > Katja From yekaterina.kantserova at oracle.com Tue Jul 14 07:12:26 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 14 Jul 2015 09:12:26 +0200 Subject: RFR(XXS): 8131035: [TESTBUG] sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java needs to enable UsePerfData In-Reply-To: <55A48DC2.5050808@oracle.com> References: <55A3BFE1.5060109@oracle.com> <55A48DC2.5050808@oracle.com> Message-ID: <55A4B65A.6030803@oracle.com> Thanks David! // Katja On 07/14/2015 06:19 AM, David Holmes wrote: > Ship it! :) > > Thanks, > David > > On 13/07/2015 11:40 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8131035 >> webrev: http://cr.openjdk.java.net/~ykantser/8131035/webrev.00 >> >> Thanks, >> Katja From yekaterina.kantserova at oracle.com Tue Jul 14 09:44:33 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 14 Jul 2015 11:44:33 +0200 Subject: RFR(XXS): 8130057: serviceability/sa/TestStackTrace.java should be quarantined Message-ID: <55A4DA01.9010601@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8130057 webrev: http://cr.openjdk.java.net/~ykantser/8130057/webrev.00/ Thanks, Katja From erik.gahlin at oracle.com Tue Jul 14 10:13:18 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 14 Jul 2015 12:13:18 +0200 Subject: RFR(XXS): 8130057: serviceability/sa/TestStackTrace.java should be quarantined In-Reply-To: <55A4DA01.9010601@oracle.com> References: <55A4DA01.9010601@oracle.com> Message-ID: <55A4E0BE.2090707@oracle.com> Looks good Erik Yekaterina Kantserova skrev den 14/07/15 11:44: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8130057 > webrev: http://cr.openjdk.java.net/~ykantser/8130057/webrev.00/ > > Thanks, > Katja From jaroslav.bachorik at oracle.com Tue Jul 14 11:21:16 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jul 2015 13:21:16 +0200 Subject: RFR(XXS): 8130057: serviceability/sa/TestStackTrace.java should be quarantined In-Reply-To: <55A4DA01.9010601@oracle.com> References: <55A4DA01.9010601@oracle.com> Message-ID: <55A4F0AC.8020209@oracle.com> Looks good! -JB- On 14.7.2015 11:44, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8130057 > webrev: http://cr.openjdk.java.net/~ykantser/8130057/webrev.00/ > > Thanks, > Katja From yekaterina.kantserova at oracle.com Tue Jul 14 12:39:52 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 14 Jul 2015 14:39:52 +0200 Subject: RFR(XXS): 8130057: serviceability/sa/TestStackTrace.java should be quarantined In-Reply-To: <55A4E0BE.2090707@oracle.com> References: <55A4DA01.9010601@oracle.com> <55A4E0BE.2090707@oracle.com> Message-ID: <55A50318.5020105@oracle.com> Thanks for the review! // Katja On 07/14/2015 12:13 PM, Erik Gahlin wrote: > Looks good > > Erik > > Yekaterina Kantserova skrev den 14/07/15 11:44: >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8130057 >> webrev: http://cr.openjdk.java.net/~ykantser/8130057/webrev.00/ >> >> Thanks, >> Katja > From daniel.daugherty at oracle.com Tue Jul 14 15:56:18 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Jul 2015 09:56:18 -0600 Subject: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked In-Reply-To: <55A53006.1030307@oracle.com> References: <55A53006.1030307@oracle.com> Message-ID: <55A53122.8000409@oracle.com> Adding serviceability-dev at ... since jstack belongs to the Serviceability team... The jstack and/or tmtools tests should also be run... Dan On 7/14/15 9:51 AM, Vladimir Kempik wrote: > Hello, > > Please review the patch to fix 8048353. > Customer has an issue with this bug when running jstack on jdk7. > He tested FVB and cofirmed it has fixed the issue. > Before pushing jdk7 backport I need to get the fix to 9 and 8. > > Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353 > > testing: JPRT. > > Thanks, Vladimir. From daniel.daugherty at oracle.com Tue Jul 14 16:21:22 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Jul 2015 10:21:22 -0600 Subject: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked In-Reply-To: <55A53122.8000409@oracle.com> References: <55A53006.1030307@oracle.com> <55A53122.8000409@oracle.com> Message-ID: <55A53702.6000309@oracle.com> > Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ src/share/vm/classfile/javaClasses.cpp No comments. (Thanks for including the "" case.) src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/runtime/vframe.cpp No comments. Thumbs up (modulo running the proper tests). Dan On 7/14/15 9:56 AM, Daniel D. Daugherty wrote: > Adding serviceability-dev at ... since jstack belongs to the > Serviceability team... > > The jstack and/or tmtools tests should also be run... > > Dan > > > On 7/14/15 9:51 AM, Vladimir Kempik wrote: >> Hello, >> >> Please review the patch to fix 8048353. >> Customer has an issue with this bug when running jstack on jdk7. >> He tested FVB and cofirmed it has fixed the issue. >> Before pushing jdk7 backport I need to get the fix to 9 and 8. >> >> Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353 >> >> testing: JPRT. >> >> Thanks, Vladimir. > From daniel.daugherty at oracle.com Tue Jul 14 17:32:14 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Jul 2015 11:32:14 -0600 Subject: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked In-Reply-To: <55A546D4.2090600@oracle.com> References: <55A53006.1030307@oracle.com> <55A546D4.2090600@oracle.com> Message-ID: <55A5479E.1010407@oracle.com> Adding in serviceability-dev at ... so that both aliases see that we now have two (R)eviews. Dan On 7/14/15 11:28 AM, Coleen Phillimore wrote: > > This looks good to me. Thank you for fixing it. > Coleen > > On 7/14/15 11:51 AM, Vladimir Kempik wrote: >> Hello, >> >> Please review the patch to fix 8048353. >> Customer has an issue with this bug when running jstack on jdk7. >> He tested FVB and cofirmed it has fixed the issue. >> Before pushing jdk7 backport I need to get the fix to 9 and 8. >> >> Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353 >> >> testing: JPRT. >> >> Thanks, Vladimir. > From david.holmes at oracle.com Wed Jul 15 00:13:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jul 2015 10:13:04 +1000 Subject: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked In-Reply-To: <55A53702.6000309@oracle.com> References: <55A53006.1030307@oracle.com> <55A53122.8000409@oracle.com> <55A53702.6000309@oracle.com> Message-ID: <55A5A590.9020100@oracle.com> I'll add a third Review :) My only query is whether just type2name is the right choice here - I'm not sure what the actual output will display in context? Thanks, David On 15/07/2015 2:21 AM, Daniel D. Daugherty wrote: > > Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ > > src/share/vm/classfile/javaClasses.cpp > No comments. (Thanks for including the "" case.) > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/runtime/vframe.cpp > No comments. > > Thumbs up (modulo running the proper tests). > > Dan > > > On 7/14/15 9:56 AM, Daniel D. Daugherty wrote: >> Adding serviceability-dev at ... since jstack belongs to the >> Serviceability team... >> >> The jstack and/or tmtools tests should also be run... >> >> Dan >> >> >> On 7/14/15 9:51 AM, Vladimir Kempik wrote: >>> Hello, >>> >>> Please review the patch to fix 8048353. >>> Customer has an issue with this bug when running jstack on jdk7. >>> He tested FVB and cofirmed it has fixed the issue. >>> Before pushing jdk7 backport I need to get the fix to 9 and 8. >>> >>> Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353 >>> >>> testing: JPRT. >>> >>> Thanks, Vladimir. >> > From yekaterina.kantserova at oracle.com Wed Jul 15 09:22:52 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Jul 2015 11:22:52 +0200 Subject: RFR(XS): 8076471: Remove hprof agent tests in JDK In-Reply-To: <559FC0B4.2070704@oracle.com> References: <559FC0B4.2070704@oracle.com> Message-ID: <55A6266C.5030804@oracle.com> Hi, I've forgotten to remove serviceability/hprof/cpu002.java test in hotspot repo. Could I please have a review for this change? webrev: http://cr.openjdk.java.net/~ykantser/8076471.hotspot/webrev.00 Thanks, Katja On 07/10/2015 02:55 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8076471 > webrev: http://cr.openjdk.java.net/~ykantser/8076471/webrev.00 > > More details can be found in JEP 240: Remove the JVM TI hprof Agent > (https://bugs.openjdk.java.net/browse/JDK-8046661). > > Thanks, > Katja From david.holmes at oracle.com Wed Jul 15 09:31:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jul 2015 19:31:26 +1000 Subject: RFR(XS): 8076471: Remove hprof agent tests in JDK In-Reply-To: <55A6266C.5030804@oracle.com> References: <559FC0B4.2070704@oracle.com> <55A6266C.5030804@oracle.com> Message-ID: <55A6286E.30506@oracle.com> Hi Katja, On 15/07/2015 7:22 PM, Yekaterina Kantserova wrote: > Hi, > > I've forgotten to remove serviceability/hprof/cpu002.java test in > hotspot repo. Could I please have a review for this change? > > webrev: http://cr.openjdk.java.net/~ykantser/8076471.hotspot/webrev.00 Reviewed. As this is in a separate repo to the changesets already pushed as part of this bug you can push with the same bug number. But make sure you check with the hs-rt gatekeeper to ensure it is included when the changes are pushed to hs. Otherwise it will need a new CR. Thanks, David > Thanks, > Katja > > > > On 07/10/2015 02:55 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8076471 >> webrev: http://cr.openjdk.java.net/~ykantser/8076471/webrev.00 >> >> More details can be found in JEP 240: Remove the JVM TI hprof Agent >> (https://bugs.openjdk.java.net/browse/JDK-8046661). >> >> Thanks, >> Katja > From yekaterina.kantserova at oracle.com Wed Jul 15 09:35:45 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Jul 2015 11:35:45 +0200 Subject: RFR(XS): 8076471: Remove hprof agent tests in JDK In-Reply-To: <55A6286E.30506@oracle.com> References: <559FC0B4.2070704@oracle.com> <55A6266C.5030804@oracle.com> <55A6286E.30506@oracle.com> Message-ID: <55A62971.20701@oracle.com> David, thanks for the review! Yes, I will. // Katja On 07/15/2015 11:31 AM, David Holmes wrote: > Hi Katja, > > On 15/07/2015 7:22 PM, Yekaterina Kantserova wrote: >> Hi, >> >> I've forgotten to remove serviceability/hprof/cpu002.java test in >> hotspot repo. Could I please have a review for this change? >> >> webrev: http://cr.openjdk.java.net/~ykantser/8076471.hotspot/webrev.00 > > Reviewed. As this is in a separate repo to the changesets already > pushed as part of this bug you can push with the same bug number. But > make sure you check with the hs-rt gatekeeper to ensure it is included > when the changes are pushed to hs. Otherwise it will need a new CR. > > Thanks, > David > >> Thanks, >> Katja >> >> >> >> On 07/10/2015 02:55 PM, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8076471 >>> webrev: http://cr.openjdk.java.net/~ykantser/8076471/webrev.00 >>> >>> More details can be found in JEP 240: Remove the JVM TI hprof Agent >>> (https://bugs.openjdk.java.net/browse/JDK-8046661). >>> >>> Thanks, >>> Katja >> From serguei.spitsyn at oracle.com Wed Jul 15 09:58:30 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Jul 2015 02:58:30 -0700 Subject: RFR(XS): 8076471: Remove hprof agent tests in JDK In-Reply-To: <55A6266C.5030804@oracle.com> References: <559FC0B4.2070704@oracle.com> <55A6266C.5030804@oracle.com> Message-ID: <55A62EC6.5030100@oracle.com> Hi Katya, On 7/15/15 2:22 AM, Yekaterina Kantserova wrote: > Hi, > > I've forgotten to remove serviceability/hprof/cpu002.java test in > hotspot repo. Could I please have a review for this change? > > webrev: http://cr.openjdk.java.net/~ykantser/8076471.hotspot/webrev.00 This looks good. > > Thanks, > Katja > > > > On 07/10/2015 02:55 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8076471 >> webrev: http://cr.openjdk.java.net/~ykantser/8076471/webrev.00 It looks good but I'm not sure why have you deleted these tests as well: |------ ------ ------ ------ Old --- ----- --- | *test/demo/jvmti/minst/MinstExample.java* |------ ------ ------ ------ Old --- ----- --- | *test/demo/jvmti/minst/MinstTest.java* |------ ------ ------ ------ Old --- ----- --- | *test/demo/jvmti/versionCheck/FailsWhenJvmtiVersionDiffers.java* |------ ------ ------ ------ Old --- ----- --- | *test/demo/jvmti/waiters/WaitersTest.java* Did you want to remove all the demo tests, not hprof only? Just want to make sure you did not get rid of them unintentionally. Thanks, Serguei >> >> More details can be found in JEP 240: Remove the JVM TI hprof Agent >> (https://bugs.openjdk.java.net/browse/JDK-8046661). >> >> Thanks, >> Katja > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Wed Jul 15 10:07:28 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Jul 2015 12:07:28 +0200 Subject: RFR(XS): 8076471: Remove hprof agent tests in JDK In-Reply-To: <55A62EC6.5030100@oracle.com> References: <559FC0B4.2070704@oracle.com> <55A6266C.5030804@oracle.com> <55A62EC6.5030100@oracle.com> Message-ID: <55A630E0.7010009@oracle.com> Hi Serguei, Thanks a lot for looking at it! Yes, I unintentionally removed test/demo/jvmti instead of test/demo/jvmti/hprof :( Will restore the tests asap. // Katja On 07/15/2015 11:58 AM, serguei.spitsyn at oracle.com wrote: > Hi Katya, > > > On 7/15/15 2:22 AM, Yekaterina Kantserova wrote: >> Hi, >> >> I've forgotten to remove serviceability/hprof/cpu002.java test in >> hotspot repo. Could I please have a review for this change? >> >> webrev: http://cr.openjdk.java.net/~ykantser/8076471.hotspot/webrev.00 > > This looks good. > >> >> Thanks, >> Katja >> >> >> >> On 07/10/2015 02:55 PM, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8076471 >>> webrev: http://cr.openjdk.java.net/~ykantser/8076471/webrev.00 > > It looks good but I'm not sure why have you deleted these tests as well: > > |------ ------ ------ ------ Old > > --- ----- --- | *test/demo/jvmti/minst/MinstExample.java* > > |------ ------ ------ ------ Old > > --- ----- --- | *test/demo/jvmti/minst/MinstTest.java* > > |------ ------ ------ ------ Old > > --- ----- --- | > *test/demo/jvmti/versionCheck/FailsWhenJvmtiVersionDiffers.java* > > |------ ------ ------ ------ Old > > --- ----- --- | *test/demo/jvmti/waiters/WaitersTest.java* > > > Did you want to remove all the demo tests, not hprof only? > Just want to make sure you did not get rid of them unintentionally. > > > Thanks, > Serguei > > >>> >>> More details can be found in JEP 240: Remove the JVM TI hprof Agent >>> (https://bugs.openjdk.java.net/browse/JDK-8046661). >>> >>> Thanks, >>> Katja >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jul 15 10:12:47 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Jul 2015 03:12:47 -0700 Subject: RFR(XS): 8076471: Remove hprof agent tests in JDK In-Reply-To: <55A630E0.7010009@oracle.com> References: <559FC0B4.2070704@oracle.com> <55A6266C.5030804@oracle.com> <55A62EC6.5030100@oracle.com> <55A630E0.7010009@oracle.com> Message-ID: <55A6321F.8010402@oracle.com> Ok, thanks! Serguei On 7/15/15 3:07 AM, Yekaterina Kantserova wrote: > Hi Serguei, > > Thanks a lot for looking at it! Yes, I unintentionally removed > test/demo/jvmti instead of test/demo/jvmti/hprof :( Will restore the > tests asap. > > // Katja > > > > On 07/15/2015 11:58 AM, serguei.spitsyn at oracle.com wrote: >> Hi Katya, >> >> >> On 7/15/15 2:22 AM, Yekaterina Kantserova wrote: >>> Hi, >>> >>> I've forgotten to remove serviceability/hprof/cpu002.java test in >>> hotspot repo. Could I please have a review for this change? >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8076471.hotspot/webrev.00 >> >> This looks good. >> >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 07/10/2015 02:55 PM, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8076471 >>>> webrev: http://cr.openjdk.java.net/~ykantser/8076471/webrev.00 >> >> It looks good but I'm not sure why have you deleted these tests as well: >> >> |------ ------ ------ ------ Old >> >> --- ----- --- | *test/demo/jvmti/minst/MinstExample.java* >> >> |------ ------ ------ ------ Old >> >> --- ----- --- | *test/demo/jvmti/minst/MinstTest.java* >> >> |------ ------ ------ ------ Old >> >> --- ----- --- | >> *test/demo/jvmti/versionCheck/FailsWhenJvmtiVersionDiffers.java* >> >> |------ ------ ------ ------ Old >> >> --- ----- --- | *test/demo/jvmti/waiters/WaitersTest.java* >> >> >> Did you want to remove all the demo tests, not hprof only? >> Just want to make sure you did not get rid of them unintentionally. >> >> >> Thanks, >> Serguei >> >> >>>> >>>> More details can be found in JEP 240: Remove the JVM TI hprof Agent >>>> (https://bugs.openjdk.java.net/browse/JDK-8046661). >>>> >>>> Thanks, >>>> Katja >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Wed Jul 15 10:55:45 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Jul 2015 12:55:45 +0200 Subject: RFR(XS): 8131328: Restore demo/jvmti tests Message-ID: <55A63C31.4030208@oracle.com> Hi, Could I please have a review of this fix. demo/jvmti tests were unintentionally removed by https://bugs.openjdk.java.net/browse/JDK-8076471. This fix will restore the tests unrelated to hprof. bug: https://bugs.openjdk.java.net/browse/JDK-8131328 webrev: http://cr.openjdk.java.net/~ykantser/8131328/webrev.00 Thanks, Katja From serguei.spitsyn at oracle.com Wed Jul 15 11:10:50 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Jul 2015 04:10:50 -0700 Subject: RFR(XS): 8131328: Restore demo/jvmti tests In-Reply-To: <55A63C31.4030208@oracle.com> References: <55A63C31.4030208@oracle.com> Message-ID: <55A63FBA.20404@oracle.com> Looks good to me. Sorry, I did not notice it earlier. Thanks, Serguei On 7/15/15 3:55 AM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. demo/jvmti tests were > unintentionally removed by > https://bugs.openjdk.java.net/browse/JDK-8076471. This fix will > restore the tests unrelated to hprof. > > bug: https://bugs.openjdk.java.net/browse/JDK-8131328 > webrev: http://cr.openjdk.java.net/~ykantser/8131328/webrev.00 > > Thanks, > Katja From yekaterina.kantserova at oracle.com Wed Jul 15 11:14:41 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Jul 2015 13:14:41 +0200 Subject: RFR(XS): 8131328: Restore demo/jvmti tests In-Reply-To: <55A63FBA.20404@oracle.com> References: <55A63C31.4030208@oracle.com> <55A63FBA.20404@oracle.com> Message-ID: <55A640A1.7080308@oracle.com> Serguei, Thanks a lot for the discovery and the review! // Katja On 07/15/2015 01:10 PM, serguei.spitsyn at oracle.com wrote: > Looks good to me. > Sorry, I did not notice it earlier. > > Thanks, > Serguei > > On 7/15/15 3:55 AM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. demo/jvmti tests were >> unintentionally removed by >> https://bugs.openjdk.java.net/browse/JDK-8076471. This fix will >> restore the tests unrelated to hprof. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8131328 >> webrev: http://cr.openjdk.java.net/~ykantser/8131328/webrev.00 >> >> Thanks, >> Katja > From dmitry.samersoff at oracle.com Wed Jul 15 11:52:17 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Jul 2015 14:52:17 +0300 Subject: RFR(S): JDK-8129971 TestStackTrace.java: ArrayIndexOutOfBoundsException thrown by AARCH64ThreadContext.setRegister Message-ID: <55A64971.50506@oracle.com> Everybody, Please, review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8129971/webrev.01/ Added one more register counted in frame context. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Wed Jul 15 12:12:38 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 15 Jul 2015 14:12:38 +0200 Subject: RFR(S): JDK-8129971 TestStackTrace.java: ArrayIndexOutOfBoundsException thrown by AARCH64ThreadContext.setRegister In-Reply-To: <55A64971.50506@oracle.com> References: <55A64971.50506@oracle.com> Message-ID: <55A64E36.6070807@oracle.com> Looks good! -JB- On 15.7.2015 13:52, Dmitry Samersoff wrote: > Everybody, > > Please, review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8129971/webrev.01/ > > Added one more register counted in frame context. > > -Dmitry > From yekaterina.kantserova at oracle.com Wed Jul 15 12:16:16 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 15 Jul 2015 14:16:16 +0200 Subject: RFR(S): JDK-8129971 TestStackTrace.java: ArrayIndexOutOfBoundsException thrown by AARCH64ThreadContext.setRegister In-Reply-To: <55A64971.50506@oracle.com> References: <55A64971.50506@oracle.com> Message-ID: <55A64F10.6060401@oracle.com> Dmitry, could you please remove @ignore tag in TestStackTrace.java as well? // Katja On 07/15/2015 01:52 PM, Dmitry Samersoff wrote: > Everybody, > > Please, review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8129971/webrev.01/ > > Added one more register counted in frame context. > > -Dmitry > From dmitry.samersoff at oracle.com Wed Jul 15 14:25:09 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Jul 2015 17:25:09 +0300 Subject: RFR(S): JDK-8129971 TestStackTrace.java: ArrayIndexOutOfBoundsException thrown by AARCH64ThreadContext.setRegister In-Reply-To: <55A64F10.6060401@oracle.com> References: <55A64971.50506@oracle.com> <55A64F10.6060401@oracle.com> Message-ID: <55A66D45.4070705@oracle.com> Katja, done. Webrev updated in-place (press shift-reload) -Dmitry On 2015-07-15 15:16, Yekaterina Kantserova wrote: > Dmitry, > > could you please remove @ignore tag in TestStackTrace.java as well? > > // Katja > > On 07/15/2015 01:52 PM, Dmitry Samersoff wrote: >> Everybody, >> >> Please, review the fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8129971/webrev.01/ >> >> Added one more register counted in frame context. >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kempik at oracle.com Wed Jul 15 14:31:28 2015 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 15 Jul 2015 17:31:28 +0300 Subject: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked In-Reply-To: <55A53702.6000309@oracle.com> References: <55A53006.1030307@oracle.com> <55A53122.8000409@oracle.com> <55A53702.6000309@oracle.com> Message-ID: <55A66EC0.2020202@oracle.com> Hello Thanks for looking into this. Where can I find jstack/tmtools tests to run them ? Thanks, Vladimir. On 14.07.2015 19:21, Daniel D. Daugherty wrote: > > Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ > > src/share/vm/classfile/javaClasses.cpp > No comments. (Thanks for including the "" case.) > > src/share/vm/classfile/javaClasses.hpp > No comments. > > src/share/vm/runtime/vframe.cpp > No comments. > > Thumbs up (modulo running the proper tests). > > Dan > > > On 7/14/15 9:56 AM, Daniel D. Daugherty wrote: >> Adding serviceability-dev at ... since jstack belongs to the >> Serviceability team... >> >> The jstack and/or tmtools tests should also be run... >> >> Dan >> >> >> On 7/14/15 9:51 AM, Vladimir Kempik wrote: >>> Hello, >>> >>> Please review the patch to fix 8048353. >>> Customer has an issue with this bug when running jstack on jdk7. >>> He tested FVB and cofirmed it has fixed the issue. >>> Before pushing jdk7 backport I need to get the fix to 9 and 8. >>> >>> Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353 >>> >>> testing: JPRT. >>> >>> Thanks, Vladimir. >> > From alexander.kulyakhtin at oracle.com Wed Jul 15 16:57:46 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 15 Jul 2015 09:57:46 -0700 (PDT) Subject: RFR: JDK-8114828: wrong class file error when compiling tests Message-ID: <72310951-2401-4c8c-beaa-23f46188236b@default> Hi, Could you, please, review these simple test-only changes: CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html Before the change the @library tags in the tests pointed to the directory above the tests repository. With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. The tests have been modified accordingly, so they now compile successfully. Best regards, Alexander From yumin.qi at oracle.com Wed Jul 15 17:37:35 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 15 Jul 2015 10:37:35 -0700 Subject: RFR: 8130115: REDO - Reduce Symbol::_identity_hash to 2 bytes Message-ID: <55A69A5F.3070504@oracle.com> Hi, This is redo for bug 8087143, in that push, it caused failure on Serviceability Agent failed to get type for "_identity_hash": mistakenly used JShortField for it, but in fact it still is CIntegerField. In this change, besides of the original change in hotspot/src, I add code to calculate identity_hash in hotspot/agent based on the changed in hotspot. Old webrev for 8087143: bug: https://bugs.openjdk.java.net/browse/JDK-8087143 webrev: http://cr.openjdk.java.net/~minqi/8087143/webrev03/ Summary: _identity_hash is an integer in Symbol (SymbolBase), it is used to compute hash bucket index by modulus division of table size. Currently in hotspot, no table size is more than 65535 so we can use short instead. For case with table size over 65535 we can use the first two bytes of symbol data to be as the upper 16 bits for the calculation but rare cases. New webrev for 8130115: bug: https://bugs.openjdk.java.net/browse/JDK-8130115 webrev: http://cr.openjdk.java.net/~minqi/8130115/webrev01/ Tests: JPRT, SA manual tests, -atk quick, jtreg hotspot/runtime Also internal large application used for hashtable data analysis --- the No. of loaded classes is big(over 19K), and tested with different bucket sizes including over 65535 to see the new algorithm for identity_hash calculation, result shows the consistency before and after the fix. Thanks Yumin From david.holmes at oracle.com Thu Jul 16 01:53:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jul 2015 11:53:00 +1000 Subject: RFR: JDK-8114828: wrong class file error when compiling tests In-Reply-To: <72310951-2401-4c8c-beaa-23f46188236b@default> References: <72310951-2401-4c8c-beaa-23f46188236b@default> Message-ID: <55A70E7C.9040602@oracle.com> Adding in hotspot-dev as there's a meta-question here Hi Alexander, On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review these simple test-only changes: > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) > > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Before the change the @library tags in the tests pointed to the directory above the tests repository. > With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. > > The tests have been modified accordingly, so they now compile successfully. We currently have 272 tests in hotspot/test that specify some variant of: @library /testlibrary /../../test/lib Are these now all broken with jtreg b12? Why do these serviceability tests specify: test/lib/share/classes when all the other tests just specify: test/lib ? Thanks, David > Best regards, > Alexander > From yekaterina.kantserova at oracle.com Thu Jul 16 07:30:21 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 16 Jul 2015 09:30:21 +0200 Subject: RFR(S): JDK-8129971 TestStackTrace.java: ArrayIndexOutOfBoundsException thrown by AARCH64ThreadContext.setRegister In-Reply-To: <55A66D45.4070705@oracle.com> References: <55A64971.50506@oracle.com> <55A64F10.6060401@oracle.com> <55A66D45.4070705@oracle.com> Message-ID: <55A75D8D.7040803@oracle.com> Looks good! Thanks! // Katja On 07/15/2015 04:25 PM, Dmitry Samersoff wrote: > Katja, > > done. > > Webrev updated in-place (press shift-reload) > > -Dmitry > > On 2015-07-15 15:16, Yekaterina Kantserova wrote: >> Dmitry, >> >> could you please remove @ignore tag in TestStackTrace.java as well? >> >> // Katja >> >> On 07/15/2015 01:52 PM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please, review the fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8129971/webrev.01/ >>> >>> Added one more register counted in frame context. >>> >>> -Dmitry >>> > From yekaterina.kantserova at oracle.com Thu Jul 16 07:47:11 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 16 Jul 2015 09:47:11 +0200 Subject: RFR: JDK-8114828: wrong class file error when compiling tests In-Reply-To: <72310951-2401-4c8c-beaa-23f46188236b@default> References: <72310951-2401-4c8c-beaa-23f46188236b@default> Message-ID: <55A7617F.4050804@oracle.com> Looks good! (Not a reviewer) I've switched the issue to be open. // Katja On 07/15/2015 06:57 PM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review these simple test-only changes: > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) > > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Before the change the @library tags in the tests pointed to the directory above the tests repository. > With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. > > The tests have been modified accordingly, so they now compile successfully. > > Best regards, > Alexander From alexander.kulyakhtin at oracle.com Thu Jul 16 13:39:14 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 16 Jul 2015 06:39:14 -0700 (PDT) Subject: RFR: JDK-8114828: wrong class file error when compiling tests Message-ID: David, I was mistaken saying that jtreg does not allow @library to point out above the test root. On further investigation the issue appears to be an Aurora setup issue and the proposed earlier fix is not needed. We are investigating the cause of the issue. Best regards, Alexander ----- Original Message ----- From: david.holmes at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Thursday, July 16, 2015 4:53:08 AM GMT +03:00 Iraq Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests Adding in hotspot-dev as there's a meta-question here Hi Alexander, On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review these simple test-only changes: > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) > > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Before the change the @library tags in the tests pointed to the directory above the tests repository. > With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. > > The tests have been modified accordingly, so they now compile successfully. We currently have 272 tests in hotspot/test that specify some variant of: @library /testlibrary /../../test/lib Are these now all broken with jtreg b12? Why do these serviceability tests specify: test/lib/share/classes when all the other tests just specify: test/lib ? Thanks, David > Best regards, > Alexander > From dmitry.samersoff at oracle.com Thu Jul 16 15:23:21 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 16 Jul 2015 18:23:21 +0300 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <558DEB23.8000401@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> Message-ID: <55A7CC69.4020507@oracle.com> Serguei, http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 Webrev updated in-place (press shift-reload). Code changes at ll.119. Added more comments to other places. -Dmitry On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > Thank you for the update! > The SALauncher.java changes are really nice. > I have just couple of small comments. > > agent/src/share/classes/sun/jvm/hotspot/SALauncher.java > > 343 // Run tmtools > 344 if (args[0].equals("jstack")) { > 345 runJSTACK(oldArgs); > > Why the comment says "Run tmtools", not jstack? > BTW, other fragments have no such a comment which is Ok at it is obvious. > > > agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java > > There are no checks of the carg length in several places where it is needed: > > 61 if (_argv[_optind].charAt(0) == '-') { > > 112 if (carg.charAt(0) != '-' || carg.equals("--")) { > 117 if (carg.charAt(0) == '-' && carg.charAt(1) == '-') { > 124 carg = carg.substring(2); > > 136 ch = carg.charAt(_optopt); > 139 ch = carg.charAt(_optopt); > > > Otherwise, the fix looks good. > > > Thanks, > Serguei > > > On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Thank you for the review. >> >> New webrev is here: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >> >> I didn't change naming convention in SAGetoptTest.java and keep a_opt, >> b_opt etc as it gives better readability. Other concerns are addressed. >> >> BasicLauncherTest changed to use LingeredApp from testlib. >> >> -Dmitry >> >> >> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>> Hi Dmitry, >>> >>> Some quick minor comments. >>> >>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>> >>> Formatting is wrong: >>> >>> 57 if (_optind >_argv.length) { >>> >>> 71 String[] ca = carg.split("=",2); >>> >>> 80 if (los.contains(ca[0]+"=")) { >>> >>> >>> Need to use camel case for java method names: >>> >>> 55 private void extract_optarg(String opt) { >>> >>> 69 private String process_long_options(String carg, String[] longOptStr) { >>> >>> >>> Need to use quotes for '-': >>> >>> 109 // End of option batch like -abc reached, expect option to start from - >>> >>> Example is: >>> >>> 133 // At this point carg[0] contains '-' >>> >>> >>> Wrong indent at 87, 139, 120-121: >>> >>> 85 else { >>> 86 // Mixed style options --file name >>> 87 extract_optarg(ca[0]); >>> 88 } >>> >>> 138 else { >>> 139 ch = carg.charAt(_optopt); >>> 140 } >>> >>> 119 if (longOptStr == null || longOptStr.length == 0) { >>> 120 // No long options specified, stop options processing >>> 121 return null; >>> 122 } >>> >>> >>> >>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>> >>> Uninitialized local: >>> >>> 128 String s; >>> >>> Need to use camel case: >>> >>> 126 String exe_or_pid = null; >>> >>> >>> The main method is too long, I'd suggest to split with the sub-methods for: >>> clhsdb, hsdb, jstack, jmap, jinfo >>> >>> >>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>> >>> Wrong indent at 82, 85: >>> >>> 80 return toolProcess.exitValue(); >>> 81 } finally { >>> 82 theApp.stopApp(); >>> 83 } >>> 84 } catch (IOException | InterruptedException ex) { >>> 85 throw new RuntimeException("Test ERROR " + ex, ex); >>> 86 } >>> >>> >>> I do not understand what is the need for nested try statements, just one >>> try would be enough: >>> >>> 54 System.out.println("Starting LingeredApp"); >>> 55 try { >>> 56 try { >>> . . . >>> 81 } finally { >>> 82 theApp.stopApp(); >>> 83 } >>> 84 } catch (IOException | InterruptedException ex) { >>> 85 throw new RuntimeException("Test ERROR " + ex, ex); >>> 86 } >>> >>> 98 try { >>> 99 try { >>> . . . >>> 116 } finally { >>> 117 theApp.stopApp(); >>> 118 } >>> 119 } catch (Exception ex) { >>> 120 throw new RuntimeException("Test ERROR " + ex, ex); >>> 121 } >>> >>> >>> Why do you catch exceptions and throw the RuntimeException's in the >>> launch() methods >>> but catch the IOException in main? Would it be better to catch any >>> Exception? >>> >>> Too many empty lines: >>> >>> 88 >>> 89 >>> 90 >>> >>> >>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>> >>> Too many empty lines: >>> >>> 275 >>> 276 >>> >>> 369 >>> >>> >>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>> >>> Need to use Java naming convention: >>> >>> 36 private static boolean a_opt; >>> 37 private static boolean b_opt; >>> 38 private static boolean c_opt; >>> 39 private static boolean e_opt; >>> 40 private static boolean mixed_opt; >>> 41 >>> 42 private static String d_value; >>> 43 private static String exe_value; >>> 44 private static String core_value; >>> >>> Wrong indent 2 instead of 4: >>> >>> 70 if (s.equals("a")) { >>> 71 a_opt = true; >>> 72 continue; >>> 73 } >>> 74 >>> 75 if (s.equals("b")) { >>> 76 b_opt = true; >>> 77 continue; >>> 78 } >>> 79 >>> 80 if (s.equals("c")) { >>> 81 c_opt = true; >>> 82 continue; >>> 83 } >>> 84 >>> 85 if (s.equals("e")) { >>> 86 e_opt = true; >>> 87 continue; >>> 88 } >>> 89 >>> 90 if (s.equals("mixed")) { >>> 91 mixed_opt = true; >>> 92 continue; >>> 93 } >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>> Hi Everybody, >>>> >>>> Please review the changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>> >>>> I'm about to file CCC request for it but would like to get internal >>>> feedback before that. >>>> >>>> This fix is introducing native launcher jhsdb for serviceability agent. >>>> >>>> jhsdb >>>> >>>> will launch command line debugger clhsdb >>>> >>>> jhsdb jstack file core >>>> jhsdb jmap file core >>>> jhsdb jinfo file core >>>> >>>> will launch corresponding SA based utility. >>>> >>>> >>>> -Dmitry >>>> >>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Thu Jul 16 22:00:33 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Jul 2015 15:00:33 -0700 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A7CC69.4020507@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> Message-ID: <55A82981.1090505@oracle.com> Hi Dmitry, I do not see any changes. Could you please, generate .06 version ? In such a case, it will be much easier to compare the code. Thanks, Serguei On 7/16/15 8:23 AM, Dmitry Samersoff wrote: > Serguei, > > http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 > > Webrev updated in-place (press shift-reload). > > Code changes at ll.119. > > Added more comments to other places. > > -Dmitry > > On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> Thank you for the update! >> The SALauncher.java changes are really nice. >> I have just couple of small comments. >> >> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >> >> 343 // Run tmtools >> 344 if (args[0].equals("jstack")) { >> 345 runJSTACK(oldArgs); >> >> Why the comment says "Run tmtools", not jstack? >> BTW, other fragments have no such a comment which is Ok at it is obvious. >> >> >> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >> >> There are no checks of the carg length in several places where it is needed: >> >> 61 if (_argv[_optind].charAt(0) == '-') { >> >> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == '-') { >> 124 carg = carg.substring(2); >> >> 136 ch = carg.charAt(_optopt); >> 139 ch = carg.charAt(_optopt); >> >> >> Otherwise, the fix looks good. >> >> >> Thanks, >> Serguei >> >> >> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Thank you for the review. >>> >>> New webrev is here: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>> >>> I didn't change naming convention in SAGetoptTest.java and keep a_opt, >>> b_opt etc as it gives better readability. Other concerns are addressed. >>> >>> BasicLauncherTest changed to use LingeredApp from testlib. >>> >>> -Dmitry >>> >>> >>> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>>> Hi Dmitry, >>>> >>>> Some quick minor comments. >>>> >>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>> >>>> Formatting is wrong: >>>> >>>> 57 if (_optind >_argv.length) { >>>> >>>> 71 String[] ca = carg.split("=",2); >>>> >>>> 80 if (los.contains(ca[0]+"=")) { >>>> >>>> >>>> Need to use camel case for java method names: >>>> >>>> 55 private void extract_optarg(String opt) { >>>> >>>> 69 private String process_long_options(String carg, String[] longOptStr) { >>>> >>>> >>>> Need to use quotes for '-': >>>> >>>> 109 // End of option batch like -abc reached, expect option to start from - >>>> >>>> Example is: >>>> >>>> 133 // At this point carg[0] contains '-' >>>> >>>> >>>> Wrong indent at 87, 139, 120-121: >>>> >>>> 85 else { >>>> 86 // Mixed style options --file name >>>> 87 extract_optarg(ca[0]); >>>> 88 } >>>> >>>> 138 else { >>>> 139 ch = carg.charAt(_optopt); >>>> 140 } >>>> >>>> 119 if (longOptStr == null || longOptStr.length == 0) { >>>> 120 // No long options specified, stop options processing >>>> 121 return null; >>>> 122 } >>>> >>>> >>>> >>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>> >>>> Uninitialized local: >>>> >>>> 128 String s; >>>> >>>> Need to use camel case: >>>> >>>> 126 String exe_or_pid = null; >>>> >>>> >>>> The main method is too long, I'd suggest to split with the sub-methods for: >>>> clhsdb, hsdb, jstack, jmap, jinfo >>>> >>>> >>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>> >>>> Wrong indent at 82, 85: >>>> >>>> 80 return toolProcess.exitValue(); >>>> 81 } finally { >>>> 82 theApp.stopApp(); >>>> 83 } >>>> 84 } catch (IOException | InterruptedException ex) { >>>> 85 throw new RuntimeException("Test ERROR " + ex, ex); >>>> 86 } >>>> >>>> >>>> I do not understand what is the need for nested try statements, just one >>>> try would be enough: >>>> >>>> 54 System.out.println("Starting LingeredApp"); >>>> 55 try { >>>> 56 try { >>>> . . . >>>> 81 } finally { >>>> 82 theApp.stopApp(); >>>> 83 } >>>> 84 } catch (IOException | InterruptedException ex) { >>>> 85 throw new RuntimeException("Test ERROR " + ex, ex); >>>> 86 } >>>> >>>> 98 try { >>>> 99 try { >>>> . . . >>>> 116 } finally { >>>> 117 theApp.stopApp(); >>>> 118 } >>>> 119 } catch (Exception ex) { >>>> 120 throw new RuntimeException("Test ERROR " + ex, ex); >>>> 121 } >>>> >>>> >>>> Why do you catch exceptions and throw the RuntimeException's in the >>>> launch() methods >>>> but catch the IOException in main? Would it be better to catch any >>>> Exception? >>>> >>>> Too many empty lines: >>>> >>>> 88 >>>> 89 >>>> 90 >>>> >>>> >>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>> >>>> Too many empty lines: >>>> >>>> 275 >>>> 276 >>>> >>>> 369 >>>> >>>> >>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>> >>>> Need to use Java naming convention: >>>> >>>> 36 private static boolean a_opt; >>>> 37 private static boolean b_opt; >>>> 38 private static boolean c_opt; >>>> 39 private static boolean e_opt; >>>> 40 private static boolean mixed_opt; >>>> 41 >>>> 42 private static String d_value; >>>> 43 private static String exe_value; >>>> 44 private static String core_value; >>>> >>>> Wrong indent 2 instead of 4: >>>> >>>> 70 if (s.equals("a")) { >>>> 71 a_opt = true; >>>> 72 continue; >>>> 73 } >>>> 74 >>>> 75 if (s.equals("b")) { >>>> 76 b_opt = true; >>>> 77 continue; >>>> 78 } >>>> 79 >>>> 80 if (s.equals("c")) { >>>> 81 c_opt = true; >>>> 82 continue; >>>> 83 } >>>> 84 >>>> 85 if (s.equals("e")) { >>>> 86 e_opt = true; >>>> 87 continue; >>>> 88 } >>>> 89 >>>> 90 if (s.equals("mixed")) { >>>> 91 mixed_opt = true; >>>> 92 continue; >>>> 93 } >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>> Hi Everybody, >>>>> >>>>> Please review the changes: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>> >>>>> I'm about to file CCC request for it but would like to get internal >>>>> feedback before that. >>>>> >>>>> This fix is introducing native launcher jhsdb for serviceability agent. >>>>> >>>>> jhsdb >>>>> >>>>> will launch command line debugger clhsdb >>>>> >>>>> jhsdb jstack file core >>>>> jhsdb jmap file core >>>>> jhsdb jinfo file core >>>>> >>>>> will launch corresponding SA based utility. >>>>> >>>>> >>>>> -Dmitry >>>>> >>>>> > From dmitry.samersoff at oracle.com Fri Jul 17 09:46:52 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 17 Jul 2015 12:46:52 +0300 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A82981.1090505@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> <55A82981.1090505@oracle.com> Message-ID: <55A8CF0C.7090401@oracle.com> Serguei, Previous webrev is: http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05.old Latest webrev is: http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 Diff between webrev.05.old and webrev.05 attached -Dmitry On 2015-07-17 01:00, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > I do not see any changes. > Could you please, generate .06 version ? > In such a case, it will be much easier to compare the code. > > Thanks, > Serguei > > On 7/16/15 8:23 AM, Dmitry Samersoff wrote: >> Serguei, >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >> >> Webrev updated in-place (press shift-reload). >> >> Code changes at ll.119. >> >> Added more comments to other places. >> >> -Dmitry >> >> On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: >>> Hi Dmitry, >>> >>> Thank you for the update! >>> The SALauncher.java changes are really nice. >>> I have just couple of small comments. >>> >>> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>> >>> 343 // Run tmtools >>> 344 if (args[0].equals("jstack")) { >>> 345 runJSTACK(oldArgs); >>> >>> Why the comment says "Run tmtools", not jstack? >>> BTW, other fragments have no such a comment which is Ok at it is >>> obvious. >>> >>> >>> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>> >>> There are no checks of the carg length in several places where it is >>> needed: >>> >>> 61 if (_argv[_optind].charAt(0) == '-') { >>> >>> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >>> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == '-') { >>> 124 carg = carg.substring(2); >>> >>> 136 ch = carg.charAt(_optopt); >>> 139 ch = carg.charAt(_optopt); >>> >>> >>> Otherwise, the fix looks good. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> Thank you for the review. >>>> >>>> New webrev is here: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>>> >>>> I didn't change naming convention in SAGetoptTest.java and keep a_opt, >>>> b_opt etc as it gives better readability. Other concerns are addressed. >>>> >>>> BasicLauncherTest changed to use LingeredApp from testlib. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dmitry, >>>>> >>>>> Some quick minor comments. >>>>> >>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>> >>>>> Formatting is wrong: >>>>> >>>>> 57 if (_optind >_argv.length) { >>>>> >>>>> 71 String[] ca = carg.split("=",2); >>>>> >>>>> 80 if (los.contains(ca[0]+"=")) { >>>>> >>>>> >>>>> Need to use camel case for java method names: >>>>> >>>>> 55 private void extract_optarg(String opt) { >>>>> >>>>> 69 private String process_long_options(String carg, String[] >>>>> longOptStr) { >>>>> >>>>> >>>>> Need to use quotes for '-': >>>>> >>>>> 109 // End of option batch like -abc reached, expect >>>>> option to start from - >>>>> >>>>> Example is: >>>>> >>>>> 133 // At this point carg[0] contains '-' >>>>> >>>>> >>>>> Wrong indent at 87, 139, 120-121: >>>>> >>>>> 85 else { >>>>> 86 // Mixed style options --file name >>>>> 87 extract_optarg(ca[0]); >>>>> 88 } >>>>> >>>>> 138 else { >>>>> 139 ch = carg.charAt(_optopt); >>>>> 140 } >>>>> >>>>> 119 if (longOptStr == null || longOptStr.length == >>>>> 0) { >>>>> 120 // No long options specified, stop options >>>>> processing >>>>> 121 return null; >>>>> 122 } >>>>> >>>>> >>>>> >>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>> >>>>> Uninitialized local: >>>>> >>>>> 128 String s; >>>>> >>>>> Need to use camel case: >>>>> >>>>> 126 String exe_or_pid = null; >>>>> >>>>> >>>>> The main method is too long, I'd suggest to split with the >>>>> sub-methods for: >>>>> clhsdb, hsdb, jstack, jmap, jinfo >>>>> >>>>> >>>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>>> >>>>> Wrong indent at 82, 85: >>>>> >>>>> 80 return toolProcess.exitValue(); >>>>> 81 } finally { >>>>> 82 theApp.stopApp(); >>>>> 83 } >>>>> 84 } catch (IOException | InterruptedException ex) { >>>>> 85 throw new RuntimeException("Test ERROR " + ex, >>>>> ex); >>>>> 86 } >>>>> >>>>> >>>>> I do not understand what is the need for nested try statements, >>>>> just one >>>>> try would be enough: >>>>> >>>>> 54 System.out.println("Starting LingeredApp"); >>>>> 55 try { >>>>> 56 try { >>>>> . . . >>>>> 81 } finally { >>>>> 82 theApp.stopApp(); >>>>> 83 } >>>>> 84 } catch (IOException | InterruptedException ex) { >>>>> 85 throw new RuntimeException("Test ERROR " + ex, >>>>> ex); >>>>> 86 } >>>>> >>>>> 98 try { >>>>> 99 try { >>>>> . . . >>>>> 116 } finally { >>>>> 117 theApp.stopApp(); >>>>> 118 } >>>>> 119 } catch (Exception ex) { >>>>> 120 throw new RuntimeException("Test ERROR " + ex, ex); >>>>> 121 } >>>>> >>>>> >>>>> Why do you catch exceptions and throw the RuntimeException's in the >>>>> launch() methods >>>>> but catch the IOException in main? Would it be better to catch any >>>>> Exception? >>>>> >>>>> Too many empty lines: >>>>> >>>>> 88 >>>>> 89 >>>>> 90 >>>>> >>>>> >>>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>>> >>>>> Too many empty lines: >>>>> >>>>> 275 >>>>> 276 >>>>> >>>>> 369 >>>>> >>>>> >>>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>>> >>>>> Need to use Java naming convention: >>>>> >>>>> 36 private static boolean a_opt; >>>>> 37 private static boolean b_opt; >>>>> 38 private static boolean c_opt; >>>>> 39 private static boolean e_opt; >>>>> 40 private static boolean mixed_opt; >>>>> 41 >>>>> 42 private static String d_value; >>>>> 43 private static String exe_value; >>>>> 44 private static String core_value; >>>>> >>>>> Wrong indent 2 instead of 4: >>>>> >>>>> 70 if (s.equals("a")) { >>>>> 71 a_opt = true; >>>>> 72 continue; >>>>> 73 } >>>>> 74 >>>>> 75 if (s.equals("b")) { >>>>> 76 b_opt = true; >>>>> 77 continue; >>>>> 78 } >>>>> 79 >>>>> 80 if (s.equals("c")) { >>>>> 81 c_opt = true; >>>>> 82 continue; >>>>> 83 } >>>>> 84 >>>>> 85 if (s.equals("e")) { >>>>> 86 e_opt = true; >>>>> 87 continue; >>>>> 88 } >>>>> 89 >>>>> 90 if (s.equals("mixed")) { >>>>> 91 mixed_opt = true; >>>>> 92 continue; >>>>> 93 } >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>>> Hi Everybody, >>>>>> >>>>>> Please review the changes: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>>> >>>>>> I'm about to file CCC request for it but would like to get internal >>>>>> feedback before that. >>>>>> >>>>>> This fix is introducing native launcher jhsdb for serviceability >>>>>> agent. >>>>>> >>>>>> jhsdb >>>>>> >>>>>> will launch command line debugger clhsdb >>>>>> >>>>>> jhsdb jstack file core >>>>>> jhsdb jmap file core >>>>>> jhsdb jinfo file core >>>>>> >>>>>> will launch corresponding SA based utility. >>>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- zombie:hs-rt#diff -ur webrevs_001/hotspot_webrev/raw_files webrevs/hotspot_webrev/raw_files diff -ur webrevs_001/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java --- webrevs_001/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java 2015-06-24 15:14:58.000000000 +0300 +++ webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java 2015-07-16 17:54:08.000000000 +0300 @@ -58,6 +58,7 @@ throw new RuntimeException("Not enough arguments for '" + opt + "'"); } + // _argv[_optind] can't be empty, so it's safe to expect at least one character if (_argv[_optind].charAt(0) == '-') { throw new RuntimeException("Argument is expected for '" + opt + "'"); } @@ -109,18 +110,21 @@ // End of option batch like '-abc' reached, expect option to start from '-' carg = _argv[_optind]; + // carg can't be empty so it's safe to expect at least one character if (carg.charAt(0) != '-' || carg.equals("--")) { // Stop processing on -- or first non-option argument; return null; } - if (carg.charAt(0) == '-' && carg.charAt(1) == '-') { + if (carg.startsWith("--")) { // Handle long options, it can't be combined so it's simple if (longOptStr == null || longOptStr.length == 0) { - // No long options specified, stop options processing + // No long options expected, stop options processing return null; } ++ _optind; + + // at this point carg contains at least one character besides -- carg = carg.substring(2); return processLongOptions(carg, longOptStr); } @@ -133,9 +137,11 @@ // At this point carg[0] contains '-' _optreset = false; _optopt = 1; + // Length of carg checked below ch = carg.charAt(_optopt); } else { + // Length of carg checked below ch = carg.charAt(_optopt); } diff -ur webrevs_001/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java --- webrevs_001/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java 2015-06-24 15:15:01.000000000 +0300 +++ webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java 2015-07-16 17:54:09.000000000 +0300 @@ -329,7 +329,7 @@ String[] oldArgs = Arrays.copyOfRange(args, 1, args.length); - // Run SA + // Run SA interactive mode if (args[0].equals("clhsdb")) { runCLHSDB(oldArgs); return; @@ -340,7 +340,7 @@ return; } - // Run tmtools + // Run SA tmtools mode if (args[0].equals("jstack")) { runJSTACK(oldArgs); return; From serguei.spitsyn at oracle.com Fri Jul 17 10:46:50 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jul 2015 03:46:50 -0700 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A8CF0C.7090401@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> <55A82981.1090505@oracle.com> <55A8CF0C.7090401@oracle.com> Message-ID: <55A8DD1A.10407@oracle.com> Dmitry, Thanks for the diff, it helps! hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java Uninitialized local definition: 105 char ch; Unneded second initialization at 111: 104 String carg = _argv[_optind]; 111 carg = _argv[_optind]; It is not clear why carg can't be empty: 61 // _argv[_optind] can't be empty, so it's safe to expect at least one character 62 if (_argv[_optind].charAt(0) == '-') { ... 113 // carg can't be empty so it's safe to expect at least one character 114 if (carg.charAt(0) != '-' || carg.equals("--")) { The _argv comes from outside of the method. How can we be sure that the value _argv[_optind] is not empty String? Does it comes from an assumption that the outside processing works correctly? Would it be better to always check that it is not empty? It feels like this code is not clear and more complex than has to be. But I can't tell yet what has to be simplified. For example, I do not like this part: 37 private boolean _optreset; // special handling of first call 44 _optreset = true; 108 if (_optreset) { 138 _optreset = false; Would it be better to separate this first step from the next() method and make it a separate method that is called reset() or init()? Also, there is no clue why all this is necessary. Other files look good to me. Do you have another reviewer? Thanks, Serguei On 7/17/15 2:46 AM, Dmitry Samersoff wrote: > Serguei, > > Previous webrev is: > http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05.old > > Latest webrev is: > http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 > > Diff between webrev.05.old and webrev.05 attached > > -Dmitry > > On 2015-07-17 01:00, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> I do not see any changes. >> Could you please, generate .06 version ? >> In such a case, it will be much easier to compare the code. >> >> Thanks, >> Serguei >> >> On 7/16/15 8:23 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>> >>> Webrev updated in-place (press shift-reload). >>> >>> Code changes at ll.119. >>> >>> Added more comments to other places. >>> >>> -Dmitry >>> >>> On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: >>>> Hi Dmitry, >>>> >>>> Thank you for the update! >>>> The SALauncher.java changes are really nice. >>>> I have just couple of small comments. >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>> >>>> 343 // Run tmtools >>>> 344 if (args[0].equals("jstack")) { >>>> 345 runJSTACK(oldArgs); >>>> >>>> Why the comment says "Run tmtools", not jstack? >>>> BTW, other fragments have no such a comment which is Ok at it is >>>> obvious. >>>> >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>> >>>> There are no checks of the carg length in several places where it is >>>> needed: >>>> >>>> 61 if (_argv[_optind].charAt(0) == '-') { >>>> >>>> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == '-') { >>>> 124 carg = carg.substring(2); >>>> >>>> 136 ch = carg.charAt(_optopt); >>>> 139 ch = carg.charAt(_optopt); >>>> >>>> >>>> Otherwise, the fix looks good. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> Thank you for the review. >>>>> >>>>> New webrev is here: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>>>> >>>>> I didn't change naming convention in SAGetoptTest.java and keep a_opt, >>>>> b_opt etc as it gives better readability. Other concerns are addressed. >>>>> >>>>> BasicLauncherTest changed to use LingeredApp from testlib. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> Some quick minor comments. >>>>>> >>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>> >>>>>> Formatting is wrong: >>>>>> >>>>>> 57 if (_optind >_argv.length) { >>>>>> >>>>>> 71 String[] ca = carg.split("=",2); >>>>>> >>>>>> 80 if (los.contains(ca[0]+"=")) { >>>>>> >>>>>> >>>>>> Need to use camel case for java method names: >>>>>> >>>>>> 55 private void extract_optarg(String opt) { >>>>>> >>>>>> 69 private String process_long_options(String carg, String[] >>>>>> longOptStr) { >>>>>> >>>>>> >>>>>> Need to use quotes for '-': >>>>>> >>>>>> 109 // End of option batch like -abc reached, expect >>>>>> option to start from - >>>>>> >>>>>> Example is: >>>>>> >>>>>> 133 // At this point carg[0] contains '-' >>>>>> >>>>>> >>>>>> Wrong indent at 87, 139, 120-121: >>>>>> >>>>>> 85 else { >>>>>> 86 // Mixed style options --file name >>>>>> 87 extract_optarg(ca[0]); >>>>>> 88 } >>>>>> >>>>>> 138 else { >>>>>> 139 ch = carg.charAt(_optopt); >>>>>> 140 } >>>>>> >>>>>> 119 if (longOptStr == null || longOptStr.length == >>>>>> 0) { >>>>>> 120 // No long options specified, stop options >>>>>> processing >>>>>> 121 return null; >>>>>> 122 } >>>>>> >>>>>> >>>>>> >>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>> >>>>>> Uninitialized local: >>>>>> >>>>>> 128 String s; >>>>>> >>>>>> Need to use camel case: >>>>>> >>>>>> 126 String exe_or_pid = null; >>>>>> >>>>>> >>>>>> The main method is too long, I'd suggest to split with the >>>>>> sub-methods for: >>>>>> clhsdb, hsdb, jstack, jmap, jinfo >>>>>> >>>>>> >>>>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>>>> >>>>>> Wrong indent at 82, 85: >>>>>> >>>>>> 80 return toolProcess.exitValue(); >>>>>> 81 } finally { >>>>>> 82 theApp.stopApp(); >>>>>> 83 } >>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>> 85 throw new RuntimeException("Test ERROR " + ex, >>>>>> ex); >>>>>> 86 } >>>>>> >>>>>> >>>>>> I do not understand what is the need for nested try statements, >>>>>> just one >>>>>> try would be enough: >>>>>> >>>>>> 54 System.out.println("Starting LingeredApp"); >>>>>> 55 try { >>>>>> 56 try { >>>>>> . . . >>>>>> 81 } finally { >>>>>> 82 theApp.stopApp(); >>>>>> 83 } >>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>> 85 throw new RuntimeException("Test ERROR " + ex, >>>>>> ex); >>>>>> 86 } >>>>>> >>>>>> 98 try { >>>>>> 99 try { >>>>>> . . . >>>>>> 116 } finally { >>>>>> 117 theApp.stopApp(); >>>>>> 118 } >>>>>> 119 } catch (Exception ex) { >>>>>> 120 throw new RuntimeException("Test ERROR " + ex, ex); >>>>>> 121 } >>>>>> >>>>>> >>>>>> Why do you catch exceptions and throw the RuntimeException's in the >>>>>> launch() methods >>>>>> but catch the IOException in main? Would it be better to catch any >>>>>> Exception? >>>>>> >>>>>> Too many empty lines: >>>>>> >>>>>> 88 >>>>>> 89 >>>>>> 90 >>>>>> >>>>>> >>>>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>>>> >>>>>> Too many empty lines: >>>>>> >>>>>> 275 >>>>>> 276 >>>>>> >>>>>> 369 >>>>>> >>>>>> >>>>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>>>> >>>>>> Need to use Java naming convention: >>>>>> >>>>>> 36 private static boolean a_opt; >>>>>> 37 private static boolean b_opt; >>>>>> 38 private static boolean c_opt; >>>>>> 39 private static boolean e_opt; >>>>>> 40 private static boolean mixed_opt; >>>>>> 41 >>>>>> 42 private static String d_value; >>>>>> 43 private static String exe_value; >>>>>> 44 private static String core_value; >>>>>> >>>>>> Wrong indent 2 instead of 4: >>>>>> >>>>>> 70 if (s.equals("a")) { >>>>>> 71 a_opt = true; >>>>>> 72 continue; >>>>>> 73 } >>>>>> 74 >>>>>> 75 if (s.equals("b")) { >>>>>> 76 b_opt = true; >>>>>> 77 continue; >>>>>> 78 } >>>>>> 79 >>>>>> 80 if (s.equals("c")) { >>>>>> 81 c_opt = true; >>>>>> 82 continue; >>>>>> 83 } >>>>>> 84 >>>>>> 85 if (s.equals("e")) { >>>>>> 86 e_opt = true; >>>>>> 87 continue; >>>>>> 88 } >>>>>> 89 >>>>>> 90 if (s.equals("mixed")) { >>>>>> 91 mixed_opt = true; >>>>>> 92 continue; >>>>>> 93 } >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>>>> Hi Everybody, >>>>>>> >>>>>>> Please review the changes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>>>> >>>>>>> I'm about to file CCC request for it but would like to get internal >>>>>>> feedback before that. >>>>>>> >>>>>>> This fix is introducing native launcher jhsdb for serviceability >>>>>>> agent. >>>>>>> >>>>>>> jhsdb >>>>>>> >>>>>>> will launch command line debugger clhsdb >>>>>>> >>>>>>> jhsdb jstack file core >>>>>>> jhsdb jmap file core >>>>>>> jhsdb jinfo file core >>>>>>> >>>>>>> will launch corresponding SA based utility. >>>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kulyakhtin at oracle.com Fri Jul 17 11:13:12 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 17 Jul 2015 04:13:12 -0700 (PDT) Subject: RFR: JDK-8114828: wrong class file error when compiling tests Message-ID: <1414e112-569b-466b-a5cc-f9be0bba0100@default> Hi, Can the changes below be approven? Although they are not strictly necessary, it is better to use external.lib.roots property instead of specifying too many upper-level directories, to take advantage of the latest jtreg version. The issue itself has not been observed with the latest JDK9 build on any platform. CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html Best regards, Alexander ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: david.holmes at oracle.com Cc: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Thursday, July 16, 2015 4:39:14 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests David, I was mistaken saying that jtreg does not allow @library to point out above the test root. On further investigation the issue appears to be an Aurora setup issue and the proposed earlier fix is not needed. We are investigating the cause of the issue. Best regards, Alexander ----- Original Message ----- From: david.holmes at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Thursday, July 16, 2015 4:53:08 AM GMT +03:00 Iraq Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests Adding in hotspot-dev as there's a meta-question here Hi Alexander, On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review these simple test-only changes: > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) > > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Before the change the @library tags in the tests pointed to the directory above the tests repository. > With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. > > The tests have been modified accordingly, so they now compile successfully. We currently have 272 tests in hotspot/test that specify some variant of: @library /testlibrary /../../test/lib Are these now all broken with jtreg b12? Why do these serviceability tests specify: test/lib/share/classes when all the other tests just specify: test/lib ? Thanks, David > Best regards, > Alexander > From yekaterina.kantserova at oracle.com Fri Jul 17 11:59:59 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 17 Jul 2015 13:59:59 +0200 Subject: RFR(XXS): 8037957: [TEST_BUG] javax/management/mxbean/LeakTest.java misses MerlinMXBean & TigerMXBean in @run build tag Message-ID: <55A8EE3F.9090102@oracle.com> Hi, Could I please have a review of this small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8037957 webrev: http://cr.openjdk.java.net/~ykantser/8037957/webrev.00 Thanks, Katja From jaroslav.bachorik at oracle.com Fri Jul 17 12:01:25 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 17 Jul 2015 14:01:25 +0200 Subject: RFR(XXS): 8037957: [TEST_BUG] javax/management/mxbean/LeakTest.java misses MerlinMXBean & TigerMXBean in @run build tag In-Reply-To: <55A8EE3F.9090102@oracle.com> References: <55A8EE3F.9090102@oracle.com> Message-ID: <55A8EE95.3060209@oracle.com> Looks good! -JB- On 17.7.2015 13:59, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8037957 > webrev: http://cr.openjdk.java.net/~ykantser/8037957/webrev.00 > > Thanks, > Katja From yekaterina.kantserova at oracle.com Fri Jul 17 12:02:46 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 17 Jul 2015 14:02:46 +0200 Subject: RFR(XXS): 8037957: [TEST_BUG] javax/management/mxbean/LeakTest.java misses MerlinMXBean & TigerMXBean in @run build tag In-Reply-To: <55A8EE95.3060209@oracle.com> References: <55A8EE3F.9090102@oracle.com> <55A8EE95.3060209@oracle.com> Message-ID: <55A8EEE6.9010304@oracle.com> Thanks Jaroslav! // Katja On 07/17/2015 02:01 PM, Jaroslav Bachorik wrote: > Looks good! > > -JB- > > On 17.7.2015 13:59, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8037957 >> webrev: http://cr.openjdk.java.net/~ykantser/8037957/webrev.00 >> >> Thanks, >> Katja > From jaroslav.bachorik at oracle.com Fri Jul 17 12:40:58 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 17 Jul 2015 14:40:58 +0200 Subject: RFR: JDK-8114828: wrong class file error when compiling tests In-Reply-To: <1414e112-569b-466b-a5cc-f9be0bba0100@default> References: <1414e112-569b-466b-a5cc-f9be0bba0100@default> Message-ID: <55A8F7DA.5030402@oracle.com> I'm OK with this change. However, I think it would be better to open a new issue for the code cleanup and not use the nightly-failure related one - especially since the change would not be really fixing the failure. Thanks, -JB- On 17.7.2015 13:13, Alexander Kulyakhtin wrote: > Hi, > > Can the changes below be approven? > Although they are not strictly necessary, it is better to use external.lib.roots property instead of specifying too many upper-level directories, to take advantage of the latest jtreg version. > > The issue itself has not been observed with the latest JDK9 build on any platform. > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Best regards, > Alexander > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com > Cc: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Thursday, July 16, 2015 4:39:14 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests > > David, > > I was mistaken saying that jtreg does not allow @library to point out above the test root. > On further investigation the issue appears to be an Aurora setup issue and the proposed earlier fix is not needed. > We are investigating the cause of the issue. > > Best regards, > Alexander > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Thursday, July 16, 2015 4:53:08 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests > > Adding in hotspot-dev as there's a meta-question here > > Hi Alexander, > > On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review these simple test-only changes: >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" >> (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) >> >> Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html >> >> Before the change the @library tags in the tests pointed to the directory above the tests repository. >> With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. >> >> The tests have been modified accordingly, so they now compile successfully. > > We currently have 272 tests in hotspot/test that specify some variant of: > > @library /testlibrary /../../test/lib > > Are these now all broken with jtreg b12? > > Why do these serviceability tests specify: > > test/lib/share/classes > > when all the other tests just specify: > > test/lib > > ? > > Thanks, > David > >> Best regards, >> Alexander >> From yekaterina.kantserova at oracle.com Fri Jul 17 12:47:16 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 17 Jul 2015 14:47:16 +0200 Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests Message-ID: <55A8F954.8050202@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8075658 webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00 Thanks, Katja From alexander.kulyakhtin at oracle.com Fri Jul 17 12:59:13 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 17 Jul 2015 05:59:13 -0700 (PDT) Subject: RFR: JDK-8114828: wrong class file error when compiling tests Message-ID: <1e7848f5-da70-497a-bc2a-a082ebb54e82@default> Jaroslav, Ok, I'm going to create a new low-severity issue to replace /../.. with external.lib.roots property throughout the hotspot repo. The original issue, as the development team pointed out in the comments, is likely to be caused by the concurrent running of jtreg tests and will remain open for further investigation. Best regards, Alexander ----- Original Message ----- From: jaroslav.bachorik at oracle.com To: serviceability-dev at openjdk.java.net Sent: Friday, July 17, 2015 3:41:19 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests I'm OK with this change. However, I think it would be better to open a new issue for the code cleanup and not use the nightly-failure related one - especially since the change would not be really fixing the failure. Thanks, -JB- On 17.7.2015 13:13, Alexander Kulyakhtin wrote: > Hi, > > Can the changes below be approven? > Although they are not strictly necessary, it is better to use external.lib.roots property instead of specifying too many upper-level directories, to take advantage of the latest jtreg version. > > The issue itself has not been observed with the latest JDK9 build on any platform. > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Best regards, > Alexander > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com > Cc: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Thursday, July 16, 2015 4:39:14 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests > > David, > > I was mistaken saying that jtreg does not allow @library to point out above the test root. > On further investigation the issue appears to be an Aurora setup issue and the proposed earlier fix is not needed. > We are investigating the cause of the issue. > > Best regards, > Alexander > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Thursday, July 16, 2015 4:53:08 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests > > Adding in hotspot-dev as there's a meta-question here > > Hi Alexander, > > On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review these simple test-only changes: >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" >> (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) >> >> Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html >> >> Before the change the @library tags in the tests pointed to the directory above the tests repository. >> With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. >> >> The tests have been modified accordingly, so they now compile successfully. > > We currently have 272 tests in hotspot/test that specify some variant of: > > @library /testlibrary /../../test/lib > > Are these now all broken with jtreg b12? > > Why do these serviceability tests specify: > > test/lib/share/classes > > when all the other tests just specify: > > test/lib > > ? > > Thanks, > David > >> Best regards, >> Alexander >> From jaroslav.bachorik at oracle.com Fri Jul 17 13:04:07 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 17 Jul 2015 15:04:07 +0200 Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests In-Reply-To: <55A8F954.8050202@oracle.com> References: <55A8F954.8050202@oracle.com> Message-ID: <55A8FD47.6030404@oracle.com> Looks good. Is there any way to check that all the issues from the JBS query mentioned in JDK-8075658 are addressed? -JB- On 17.7.2015 14:47, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075658 > webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00 > > Thanks, > Katja From dmitry.samersoff at oracle.com Fri Jul 17 13:21:39 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 17 Jul 2015 16:21:39 +0300 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A8DD1A.10407@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> <55A82981.1090505@oracle.com> <55A8CF0C.7090401@oracle.com> <55A8DD1A.10407@oracle.com> Message-ID: <55A90163.2080509@oracle.com> Serguei, new webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 diff to webrev.05.old attached please see also below. On 2015-07-17 13:46, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thanks for the diff, it helps! > > hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java > > Uninitialized local definition: > > 105 char ch; changed. ch is initialized later, so we actually don't need it. > Unneded second initialization at 111: > 104 String carg = _argv[_optind]; > 111 carg = _argv[_optind]; fixed. > It is not clear why carg can't be empty: > > 61 // _argv[_optind] can't be empty, so it's safe to expect at least one character > 62 if (_argv[_optind].charAt(0) == '-') { > ... > > 113 // carg can't be empty so it's safe to expect at least one character > 114 if (carg.charAt(0) != '-' || carg.equals("--")) { changed. An array passed to getopt is result of splitting arguments string, so no empty array element possible. But changed it to be on safe side. > The _argv comes from outside of the method. > How can we be sure that the value _argv[_optind] is not empty String? > Does it comes from an assumption that the outside processing works correctly? > Would it be better to always check that it is not empty? > > > It feels like this code is not clear and more complex than has to be. > But I can't tell yet what has to be simplified. > > For example, I do not like this part: > 37 private boolean _optreset; // special handling of first call > > 44 _optreset = true; > > 108 if (_optreset) { > > 138 _optreset = false; > > > Would it be better to separate this first step from the next() method > and make it a separate method that is called reset() or init()? Reset called every time when we finish the option batch: prog -xzvf filename /*reset here*/ -abc > Also, there is no clue why all this is necessary. This is a port of standard BSD getopt (based on C++ code I wrote back in 2004), that takes care of all possible option combinations and allow to process it uniform way. I would love to have it JDK-wide instead of a separate parser for each tool. > Other files look good to me. > Do you have another reviewer? Stefan Larsen reviewed one of the previous versions. -Dmitry > > > > On 7/17/15 2:46 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Previous webrev is: >> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05.old >> >> Latest webrev is: >> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >> >> Diff between webrev.05.old and webrev.05 attached >> >> -Dmitry >> >> On 2015-07-17 01:00, serguei.spitsyn at oracle.com wrote: >>> Hi Dmitry, >>> >>> I do not see any changes. >>> Could you please, generate .06 version ? >>> In such a case, it will be much easier to compare the code. >>> >>> Thanks, >>> Serguei >>> >>> On 7/16/15 8:23 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>> >>>> Webrev updated in-place (press shift-reload). >>>> >>>> Code changes at ll.119. >>>> >>>> Added more comments to other places. >>>> >>>> -Dmitry >>>> >>>> On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dmitry, >>>>> >>>>> Thank you for the update! >>>>> The SALauncher.java changes are really nice. >>>>> I have just couple of small comments. >>>>> >>>>> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>> >>>>> 343 // Run tmtools >>>>> 344 if (args[0].equals("jstack")) { >>>>> 345 runJSTACK(oldArgs); >>>>> >>>>> Why the comment says "Run tmtools", not jstack? >>>>> BTW, other fragments have no such a comment which is Ok at it is >>>>> obvious. >>>>> >>>>> >>>>> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>> >>>>> There are no checks of the carg length in several places where it is >>>>> needed: >>>>> >>>>> 61 if (_argv[_optind].charAt(0) == '-') { >>>>> >>>>> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>>> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == '-') { >>>>> 124 carg = carg.substring(2); >>>>> >>>>> 136 ch = carg.charAt(_optopt); >>>>> 139 ch = carg.charAt(_optopt); >>>>> >>>>> >>>>> Otherwise, the fix looks good. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> Thank you for the review. >>>>>> >>>>>> New webrev is here: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>>>>> >>>>>> I didn't change naming convention in SAGetoptTest.java and keep a_opt, >>>>>> b_opt etc as it gives better readability. Other concerns are addressed. >>>>>> >>>>>> BasicLauncherTest changed to use LingeredApp from testlib. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> Some quick minor comments. >>>>>>> >>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>> >>>>>>> Formatting is wrong: >>>>>>> >>>>>>> 57 if (_optind >_argv.length) { >>>>>>> >>>>>>> 71 String[] ca = carg.split("=",2); >>>>>>> >>>>>>> 80 if (los.contains(ca[0]+"=")) { >>>>>>> >>>>>>> >>>>>>> Need to use camel case for java method names: >>>>>>> >>>>>>> 55 private void extract_optarg(String opt) { >>>>>>> >>>>>>> 69 private String process_long_options(String carg, String[] >>>>>>> longOptStr) { >>>>>>> >>>>>>> >>>>>>> Need to use quotes for '-': >>>>>>> >>>>>>> 109 // End of option batch like -abc reached, expect >>>>>>> option to start from - >>>>>>> >>>>>>> Example is: >>>>>>> >>>>>>> 133 // At this point carg[0] contains '-' >>>>>>> >>>>>>> >>>>>>> Wrong indent at 87, 139, 120-121: >>>>>>> >>>>>>> 85 else { >>>>>>> 86 // Mixed style options --file name >>>>>>> 87 extract_optarg(ca[0]); >>>>>>> 88 } >>>>>>> >>>>>>> 138 else { >>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>> 140 } >>>>>>> >>>>>>> 119 if (longOptStr == null || longOptStr.length == >>>>>>> 0) { >>>>>>> 120 // No long options specified, stop options >>>>>>> processing >>>>>>> 121 return null; >>>>>>> 122 } >>>>>>> >>>>>>> >>>>>>> >>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>> >>>>>>> Uninitialized local: >>>>>>> >>>>>>> 128 String s; >>>>>>> >>>>>>> Need to use camel case: >>>>>>> >>>>>>> 126 String exe_or_pid = null; >>>>>>> >>>>>>> >>>>>>> The main method is too long, I'd suggest to split with the >>>>>>> sub-methods for: >>>>>>> clhsdb, hsdb, jstack, jmap, jinfo >>>>>>> >>>>>>> >>>>>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>>>>> >>>>>>> Wrong indent at 82, 85: >>>>>>> >>>>>>> 80 return toolProcess.exitValue(); >>>>>>> 81 } finally { >>>>>>> 82 theApp.stopApp(); >>>>>>> 83 } >>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>> 85 throw new RuntimeException("Test ERROR " + ex, >>>>>>> ex); >>>>>>> 86 } >>>>>>> >>>>>>> >>>>>>> I do not understand what is the need for nested try statements, >>>>>>> just one >>>>>>> try would be enough: >>>>>>> >>>>>>> 54 System.out.println("Starting LingeredApp"); >>>>>>> 55 try { >>>>>>> 56 try { >>>>>>> . . . >>>>>>> 81 } finally { >>>>>>> 82 theApp.stopApp(); >>>>>>> 83 } >>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>> 85 throw new RuntimeException("Test ERROR " + ex, >>>>>>> ex); >>>>>>> 86 } >>>>>>> >>>>>>> 98 try { >>>>>>> 99 try { >>>>>>> . . . >>>>>>> 116 } finally { >>>>>>> 117 theApp.stopApp(); >>>>>>> 118 } >>>>>>> 119 } catch (Exception ex) { >>>>>>> 120 throw new RuntimeException("Test ERROR " + ex, ex); >>>>>>> 121 } >>>>>>> >>>>>>> >>>>>>> Why do you catch exceptions and throw the RuntimeException's in the >>>>>>> launch() methods >>>>>>> but catch the IOException in main? Would it be better to catch any >>>>>>> Exception? >>>>>>> >>>>>>> Too many empty lines: >>>>>>> >>>>>>> 88 >>>>>>> 89 >>>>>>> 90 >>>>>>> >>>>>>> >>>>>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>>>>> >>>>>>> Too many empty lines: >>>>>>> >>>>>>> 275 >>>>>>> 276 >>>>>>> >>>>>>> 369 >>>>>>> >>>>>>> >>>>>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>>>>> >>>>>>> Need to use Java naming convention: >>>>>>> >>>>>>> 36 private static boolean a_opt; >>>>>>> 37 private static boolean b_opt; >>>>>>> 38 private static boolean c_opt; >>>>>>> 39 private static boolean e_opt; >>>>>>> 40 private static boolean mixed_opt; >>>>>>> 41 >>>>>>> 42 private static String d_value; >>>>>>> 43 private static String exe_value; >>>>>>> 44 private static String core_value; >>>>>>> >>>>>>> Wrong indent 2 instead of 4: >>>>>>> >>>>>>> 70 if (s.equals("a")) { >>>>>>> 71 a_opt = true; >>>>>>> 72 continue; >>>>>>> 73 } >>>>>>> 74 >>>>>>> 75 if (s.equals("b")) { >>>>>>> 76 b_opt = true; >>>>>>> 77 continue; >>>>>>> 78 } >>>>>>> 79 >>>>>>> 80 if (s.equals("c")) { >>>>>>> 81 c_opt = true; >>>>>>> 82 continue; >>>>>>> 83 } >>>>>>> 84 >>>>>>> 85 if (s.equals("e")) { >>>>>>> 86 e_opt = true; >>>>>>> 87 continue; >>>>>>> 88 } >>>>>>> 89 >>>>>>> 90 if (s.equals("mixed")) { >>>>>>> 91 mixed_opt = true; >>>>>>> 92 continue; >>>>>>> 93 } >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>>>>> Hi Everybody, >>>>>>>> >>>>>>>> Please review the changes: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>>>>> >>>>>>>> I'm about to file CCC request for it but would like to get internal >>>>>>>> feedback before that. >>>>>>>> >>>>>>>> This fix is introducing native launcher jhsdb for serviceability >>>>>>>> agent. >>>>>>>> >>>>>>>> jhsdb >>>>>>>> >>>>>>>> will launch command line debugger clhsdb >>>>>>>> >>>>>>>> jhsdb jstack file core >>>>>>>> jhsdb jmap file core >>>>>>>> jhsdb jinfo file core >>>>>>>> >>>>>>>> will launch corresponding SA based utility. >>>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- diff -ur webrevs_001/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java --- webrevs_001/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java 2015-06-24 15:14:58.000000000 +0300 +++ webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java 2015-07-17 16:01:36.000000000 +0300 @@ -58,7 +58,7 @@ throw new RuntimeException("Not enough arguments for '" + opt + "'"); } - if (_argv[_optind].charAt(0) == '-') { + if (! _argv[_optind].isEmpty() && _argv[_optind].charAt(0) == '-') { throw new RuntimeException("Argument is expected for '" + opt + "'"); } @@ -95,32 +95,32 @@ public String next(String optStr, String[] longOptStr) { - if (_optind >= _argv.length) { + if (_optind >= _argv.length || _argv[_optind] == null) { // All arguments processed return null; } String carg = _argv[_optind]; - char ch; + char ch = '-'; _optarg = null; if (_optreset) { - // End of option batch like '-abc' reached, expect option to start from '-' - carg = _argv[_optind]; - if (carg.charAt(0) != '-' || carg.equals("--")) { + if (carg.isEmpty() || carg.charAt(0) != '-' || carg.equals("--")) { // Stop processing on -- or first non-option argument; return null; } - if (carg.charAt(0) == '-' && carg.charAt(1) == '-') { + if (carg.startsWith("--")) { // Handle long options, it can't be combined so it's simple if (longOptStr == null || longOptStr.length == 0) { - // No long options specified, stop options processing + // No long options expected, stop options processing return null; } ++ _optind; + + // at this point carg contains at least one character besides -- carg = carg.substring(2); return processLongOptions(carg, longOptStr); } diff -ur webrevs_001/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java --- webrevs_001/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java 2015-06-24 15:15:01.000000000 +0300 +++ webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java 2015-07-17 16:01:38.000000000 +0300 @@ -329,7 +329,7 @@ String[] oldArgs = Arrays.copyOfRange(args, 1, args.length); - // Run SA + // Run SA interactive mode if (args[0].equals("clhsdb")) { runCLHSDB(oldArgs); return; @@ -340,7 +340,7 @@ return; } - // Run tmtools + // Run SA tmtools mode if (args[0].equals("jstack")) { runJSTACK(oldArgs); return; From serguei.spitsyn at oracle.com Fri Jul 17 13:28:38 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jul 2015 06:28:38 -0700 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A90163.2080509@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> <55A82981.1090505@oracle.com> <55A8CF0C.7090401@oracle.com> <55A8DD1A.10407@oracle.com> <55A90163.2080509@oracle.com> Message-ID: <55A90306.9070400@oracle.com> On 7/17/15 6:21 AM, Dmitry Samersoff wrote: > Serguei, > > new webrev: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 The webrev is the same. I do not see the changes you claim below. Could you, please, generate a webrev with another version number? Thanks, Serguei > > diff to webrev.05.old attached > > please see also below. > > On 2015-07-17 13:46, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> Thanks for the diff, it helps! >> >> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >> >> Uninitialized local definition: >> >> 105 char ch; > changed. ch is initialized later, so we actually don't need it. > > >> Unneded second initialization at 111: >> 104 String carg = _argv[_optind]; >> 111 carg = _argv[_optind]; > fixed. > >> It is not clear why carg can't be empty: >> >> 61 // _argv[_optind] can't be empty, so it's safe to expect at least one character >> 62 if (_argv[_optind].charAt(0) == '-') { >> ... >> >> 113 // carg can't be empty so it's safe to expect at least one character >> 114 if (carg.charAt(0) != '-' || carg.equals("--")) { > changed. > > An array passed to getopt is result of splitting arguments string, so no > empty array element possible. But changed it to be on safe side. > >> The _argv comes from outside of the method. >> How can we be sure that the value _argv[_optind] is not empty String? >> Does it comes from an assumption that the outside processing works correctly? >> Would it be better to always check that it is not empty? >> >> >> It feels like this code is not clear and more complex than has to be. >> But I can't tell yet what has to be simplified. >> >> For example, I do not like this part: >> 37 private boolean _optreset; // special handling of first call >> >> 44 _optreset = true; >> >> 108 if (_optreset) { >> >> 138 _optreset = false; >> >> >> Would it be better to separate this first step from the next() method >> and make it a separate method that is called reset() or init()? > Reset called every time when we finish the option batch: > > prog -xzvf filename /*reset here*/ -abc > >> Also, there is no clue why all this is necessary. > This is a port of standard BSD getopt (based on C++ code I wrote back in > 2004), that takes care of all possible option combinations and allow to > process it uniform way. > > I would love to have it JDK-wide instead of a separate parser for each tool. > >> Other files look good to me. >> Do you have another reviewer? > Stefan Larsen reviewed one of the previous versions. > > -Dmitry > >> >> >> On 7/17/15 2:46 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Previous webrev is: >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05.old >>> >>> Latest webrev is: >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>> >>> Diff between webrev.05.old and webrev.05 attached >>> >>> -Dmitry >>> >>> On 2015-07-17 01:00, serguei.spitsyn at oracle.com wrote: >>>> Hi Dmitry, >>>> >>>> I do not see any changes. >>>> Could you please, generate .06 version ? >>>> In such a case, it will be much easier to compare the code. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 7/16/15 8:23 AM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>>> >>>>> Webrev updated in-place (press shift-reload). >>>>> >>>>> Code changes at ll.119. >>>>> >>>>> Added more comments to other places. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> Thank you for the update! >>>>>> The SALauncher.java changes are really nice. >>>>>> I have just couple of small comments. >>>>>> >>>>>> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>> >>>>>> 343 // Run tmtools >>>>>> 344 if (args[0].equals("jstack")) { >>>>>> 345 runJSTACK(oldArgs); >>>>>> >>>>>> Why the comment says "Run tmtools", not jstack? >>>>>> BTW, other fragments have no such a comment which is Ok at it is >>>>>> obvious. >>>>>> >>>>>> >>>>>> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>> >>>>>> There are no checks of the carg length in several places where it is >>>>>> needed: >>>>>> >>>>>> 61 if (_argv[_optind].charAt(0) == '-') { >>>>>> >>>>>> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>>>> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == '-') { >>>>>> 124 carg = carg.substring(2); >>>>>> >>>>>> 136 ch = carg.charAt(_optopt); >>>>>> 139 ch = carg.charAt(_optopt); >>>>>> >>>>>> >>>>>> Otherwise, the fix looks good. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>>>>>> Serguei, >>>>>>> >>>>>>> Thank you for the review. >>>>>>> >>>>>>> New webrev is here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>>>>>> >>>>>>> I didn't change naming convention in SAGetoptTest.java and keep a_opt, >>>>>>> b_opt etc as it gives better readability. Other concerns are addressed. >>>>>>> >>>>>>> BasicLauncherTest changed to use LingeredApp from testlib. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> Some quick minor comments. >>>>>>>> >>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>>> >>>>>>>> Formatting is wrong: >>>>>>>> >>>>>>>> 57 if (_optind >_argv.length) { >>>>>>>> >>>>>>>> 71 String[] ca = carg.split("=",2); >>>>>>>> >>>>>>>> 80 if (los.contains(ca[0]+"=")) { >>>>>>>> >>>>>>>> >>>>>>>> Need to use camel case for java method names: >>>>>>>> >>>>>>>> 55 private void extract_optarg(String opt) { >>>>>>>> >>>>>>>> 69 private String process_long_options(String carg, String[] >>>>>>>> longOptStr) { >>>>>>>> >>>>>>>> >>>>>>>> Need to use quotes for '-': >>>>>>>> >>>>>>>> 109 // End of option batch like -abc reached, expect >>>>>>>> option to start from - >>>>>>>> >>>>>>>> Example is: >>>>>>>> >>>>>>>> 133 // At this point carg[0] contains '-' >>>>>>>> >>>>>>>> >>>>>>>> Wrong indent at 87, 139, 120-121: >>>>>>>> >>>>>>>> 85 else { >>>>>>>> 86 // Mixed style options --file name >>>>>>>> 87 extract_optarg(ca[0]); >>>>>>>> 88 } >>>>>>>> >>>>>>>> 138 else { >>>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>>> 140 } >>>>>>>> >>>>>>>> 119 if (longOptStr == null || longOptStr.length == >>>>>>>> 0) { >>>>>>>> 120 // No long options specified, stop options >>>>>>>> processing >>>>>>>> 121 return null; >>>>>>>> 122 } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>>> >>>>>>>> Uninitialized local: >>>>>>>> >>>>>>>> 128 String s; >>>>>>>> >>>>>>>> Need to use camel case: >>>>>>>> >>>>>>>> 126 String exe_or_pid = null; >>>>>>>> >>>>>>>> >>>>>>>> The main method is too long, I'd suggest to split with the >>>>>>>> sub-methods for: >>>>>>>> clhsdb, hsdb, jstack, jmap, jinfo >>>>>>>> >>>>>>>> >>>>>>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>>>>>> >>>>>>>> Wrong indent at 82, 85: >>>>>>>> >>>>>>>> 80 return toolProcess.exitValue(); >>>>>>>> 81 } finally { >>>>>>>> 82 theApp.stopApp(); >>>>>>>> 83 } >>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>> 85 throw new RuntimeException("Test ERROR " + ex, >>>>>>>> ex); >>>>>>>> 86 } >>>>>>>> >>>>>>>> >>>>>>>> I do not understand what is the need for nested try statements, >>>>>>>> just one >>>>>>>> try would be enough: >>>>>>>> >>>>>>>> 54 System.out.println("Starting LingeredApp"); >>>>>>>> 55 try { >>>>>>>> 56 try { >>>>>>>> . . . >>>>>>>> 81 } finally { >>>>>>>> 82 theApp.stopApp(); >>>>>>>> 83 } >>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>> 85 throw new RuntimeException("Test ERROR " + ex, >>>>>>>> ex); >>>>>>>> 86 } >>>>>>>> >>>>>>>> 98 try { >>>>>>>> 99 try { >>>>>>>> . . . >>>>>>>> 116 } finally { >>>>>>>> 117 theApp.stopApp(); >>>>>>>> 118 } >>>>>>>> 119 } catch (Exception ex) { >>>>>>>> 120 throw new RuntimeException("Test ERROR " + ex, ex); >>>>>>>> 121 } >>>>>>>> >>>>>>>> >>>>>>>> Why do you catch exceptions and throw the RuntimeException's in the >>>>>>>> launch() methods >>>>>>>> but catch the IOException in main? Would it be better to catch any >>>>>>>> Exception? >>>>>>>> >>>>>>>> Too many empty lines: >>>>>>>> >>>>>>>> 88 >>>>>>>> 89 >>>>>>>> 90 >>>>>>>> >>>>>>>> >>>>>>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>>>>>> >>>>>>>> Too many empty lines: >>>>>>>> >>>>>>>> 275 >>>>>>>> 276 >>>>>>>> >>>>>>>> 369 >>>>>>>> >>>>>>>> >>>>>>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>>>>>> >>>>>>>> Need to use Java naming convention: >>>>>>>> >>>>>>>> 36 private static boolean a_opt; >>>>>>>> 37 private static boolean b_opt; >>>>>>>> 38 private static boolean c_opt; >>>>>>>> 39 private static boolean e_opt; >>>>>>>> 40 private static boolean mixed_opt; >>>>>>>> 41 >>>>>>>> 42 private static String d_value; >>>>>>>> 43 private static String exe_value; >>>>>>>> 44 private static String core_value; >>>>>>>> >>>>>>>> Wrong indent 2 instead of 4: >>>>>>>> >>>>>>>> 70 if (s.equals("a")) { >>>>>>>> 71 a_opt = true; >>>>>>>> 72 continue; >>>>>>>> 73 } >>>>>>>> 74 >>>>>>>> 75 if (s.equals("b")) { >>>>>>>> 76 b_opt = true; >>>>>>>> 77 continue; >>>>>>>> 78 } >>>>>>>> 79 >>>>>>>> 80 if (s.equals("c")) { >>>>>>>> 81 c_opt = true; >>>>>>>> 82 continue; >>>>>>>> 83 } >>>>>>>> 84 >>>>>>>> 85 if (s.equals("e")) { >>>>>>>> 86 e_opt = true; >>>>>>>> 87 continue; >>>>>>>> 88 } >>>>>>>> 89 >>>>>>>> 90 if (s.equals("mixed")) { >>>>>>>> 91 mixed_opt = true; >>>>>>>> 92 continue; >>>>>>>> 93 } >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>>>>>> Hi Everybody, >>>>>>>>> >>>>>>>>> Please review the changes: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>>>>>> >>>>>>>>> I'm about to file CCC request for it but would like to get internal >>>>>>>>> feedback before that. >>>>>>>>> >>>>>>>>> This fix is introducing native launcher jhsdb for serviceability >>>>>>>>> agent. >>>>>>>>> >>>>>>>>> jhsdb >>>>>>>>> >>>>>>>>> will launch command line debugger clhsdb >>>>>>>>> >>>>>>>>> jhsdb jstack file core >>>>>>>>> jhsdb jmap file core >>>>>>>>> jhsdb jinfo file core >>>>>>>>> >>>>>>>>> will launch corresponding SA based utility. >>>>>>>>> >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> > From yekaterina.kantserova at oracle.com Fri Jul 17 13:33:27 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 17 Jul 2015 15:33:27 +0200 Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests In-Reply-To: <55A8FD47.6030404@oracle.com> References: <55A8F954.8050202@oracle.com> <55A8FD47.6030404@oracle.com> Message-ID: <55A90427.5040808@oracle.com> Jaroslav, Thank you for the review! It has been a relatively manual process and I'm not aware of a mechanism how to sync test-key-bug. What I can do is to mark bugs I went through with for example 'key-intermittent' label to distinguish them form the new ones. Are there other suggestions? // Katja On 07/17/2015 03:04 PM, Jaroslav Bachorik wrote: > Looks good. > > Is there any way to check that all the issues from the JBS query > mentioned in JDK-8075658 are addressed? > > -JB- > > On 17.7.2015 14:47, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8075658 >> webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00 >> >> Thanks, >> Katja > From olivier.lagneau at oracle.com Fri Jul 17 13:34:42 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Fri, 17 Jul 2015 15:34:42 +0200 Subject: RFR: JDK-8114828: wrong class file error when compiling tests In-Reply-To: <1414e112-569b-466b-a5cc-f9be0bba0100@default> References: <1414e112-569b-466b-a5cc-f9be0bba0100@default> Message-ID: <55A90472.1060801@oracle.com> Hi Alexander, Looks ok to me with same remark as Jaroslav. Last failure was 10th of July in Comp baseline. Let's hope it fixes it. Olivier. On 17/07/2015 13:13, Alexander Kulyakhtin wrote: > Hi, > > Can the changes below be approven? > Although they are not strictly necessary, it is better to use external.lib.roots property instead of specifying too many upper-level directories, to take advantage of the latest jtreg version. > > The issue itself has not been observed with the latest JDK9 build on any platform. > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Best regards, > Alexander > > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: david.holmes at oracle.com > Cc: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Thursday, July 16, 2015 4:39:14 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests > > David, > > I was mistaken saying that jtreg does not allow @library to point out above the test root. > On further investigation the issue appears to be an Aurora setup issue and the proposed earlier fix is not needed. > We are investigating the cause of the issue. > > Best regards, > Alexander > > ----- Original Message ----- > From: david.holmes at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Sent: Thursday, July 16, 2015 4:53:08 AM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests > > Adding in hotspot-dev as there's a meta-question here > > Hi Alexander, > > On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review these simple test-only changes: >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" >> (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) >> >> Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html >> >> Before the change the @library tags in the tests pointed to the directory above the tests repository. >> With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. >> >> The tests have been modified accordingly, so they now compile successfully. > We currently have 272 tests in hotspot/test that specify some variant of: > > @library /testlibrary /../../test/lib > > Are these now all broken with jtreg b12? > > Why do these serviceability tests specify: > > test/lib/share/classes > > when all the other tests just specify: > > test/lib > > ? > > Thanks, > David > >> Best regards, >> Alexander >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.lagneau at oracle.com Fri Jul 17 13:39:41 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Fri, 17 Jul 2015 15:39:41 +0200 Subject: RFR: JDK-8114828: wrong class file error when compiling tests In-Reply-To: <1e7848f5-da70-497a-bc2a-a082ebb54e82@default> References: <1e7848f5-da70-497a-bc2a-a082ebb54e82@default> Message-ID: <55A9059D.6010109@oracle.com> On 17/07/2015 14:59, Alexander Kulyakhtin wrote: > Jaroslav, > > Ok, I'm going to create a new low-severity issue to replace /../.. with external.lib.roots property throughout the hotspot repo. > > The original issue, as the development team pointed out in the comments, is likely to be caused by the concurrent running of jtreg tests and will remain open for further investigation. Yes please do ;-) > > Best regards, > Alexander > > ----- Original Message ----- > From: jaroslav.bachorik at oracle.com > To: serviceability-dev at openjdk.java.net > Sent: Friday, July 17, 2015 3:41:19 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests > > I'm OK with this change. > However, I think it would be better to open a new issue for the code > cleanup and not use the nightly-failure related one - especially since > the change would not be really fixing the failure. > > Thanks, > > -JB- > > On 17.7.2015 13:13, Alexander Kulyakhtin wrote: >> Hi, >> >> Can the changes below be approven? >> Although they are not strictly necessary, it is better to use external.lib.roots property instead of specifying too many upper-level directories, to take advantage of the latest jtreg version. >> >> The issue itself has not been observed with the latest JDK9 build on any platform. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" >> Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html >> >> Best regards, >> Alexander >> >> >> ----- Original Message ----- >> From: alexander.kulyakhtin at oracle.com >> To: david.holmes at oracle.com >> Cc: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net >> Sent: Thursday, July 16, 2015 4:39:14 PM GMT +03:00 Iraq >> Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests >> >> David, >> >> I was mistaken saying that jtreg does not allow @library to point out above the test root. >> On further investigation the issue appears to be an Aurora setup issue and the proposed earlier fix is not needed. >> We are investigating the cause of the issue. >> >> Best regards, >> Alexander >> >> ----- Original Message ----- >> From: david.holmes at oracle.com >> To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net >> Sent: Thursday, July 16, 2015 4:53:08 AM GMT +03:00 Iraq >> Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests >> >> Adding in hotspot-dev as there's a meta-question here >> >> Hi Alexander, >> >> On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: >>> Hi, >>> >>> Could you, please, review these simple test-only changes: >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" >>> (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) >>> >>> Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html >>> >>> Before the change the @library tags in the tests pointed to the directory above the tests repository. >>> With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. >>> >>> The tests have been modified accordingly, so they now compile successfully. >> We currently have 272 tests in hotspot/test that specify some variant of: >> >> @library /testlibrary /../../test/lib >> >> Are these now all broken with jtreg b12? >> >> Why do these serviceability tests specify: >> >> test/lib/share/classes >> >> when all the other tests just specify: >> >> test/lib >> >> ? >> >> Thanks, >> David >> >>> Best regards, >>> Alexander >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.lagneau at oracle.com Fri Jul 17 13:53:47 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Fri, 17 Jul 2015 15:53:47 +0200 Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests In-Reply-To: <55A90427.5040808@oracle.com> References: <55A8F954.8050202@oracle.com> <55A8FD47.6030404@oracle.com> <55A90427.5040808@oracle.com> Message-ID: <55A908EB.2030500@oracle.com> Hi Katja, Looks ok to me too. > > It has been a relatively manual process and I'm not aware of a > mechanism how to sync test-key-bug. What I can do is to mark bugs I > went through with for example 'key-intermittent' label to distinguish > them form the new ones. That's another additional label, and as I understand Joe's comment most important is to mark them intermittent with jtreg flag. Don't have any other suggestions however. Olivier. On 17/07/2015 15:33, Yekaterina Kantserova wrote: > Jaroslav, > > Thank you for the review! > > It has been a relatively manual process and I'm not aware of a > mechanism how to sync test-key-bug. What I can do is to mark bugs I > went through with for example 'key-intermittent' label to distinguish > them form the new ones. > > Are there other suggestions? > > // Katja > > > > On 07/17/2015 03:04 PM, Jaroslav Bachorik wrote: >> Looks good. >> >> Is there any way to check that all the issues from the JBS query >> mentioned in JDK-8075658 are addressed? >> >> -JB- >> >> On 17.7.2015 14:47, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8075658 >>> webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00 >>> >>> Thanks, >>> Katja >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Fri Jul 17 14:13:48 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 17 Jul 2015 17:13:48 +0300 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A90306.9070400@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> <55A82981.1090505@oracle.com> <55A8CF0C.7090401@oracle.com> <55A8DD1A.10407@oracle.com> <55A90163.2080509@oracle.com> <55A90306.9070400@oracle.com> Message-ID: <55A90D9C.10501@oracle.com> Serguei, Sorry for typeo new webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.06 -Dmitry On 2015-07-17 16:28, serguei.spitsyn at oracle.com wrote: > On 7/17/15 6:21 AM, Dmitry Samersoff wrote: >> Serguei, >> >> new webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 > > The webrev is the same. > I do not see the changes you claim below. > Could you, please, generate a webrev with another version number? > > > Thanks, > Serguei > >> >> diff to webrev.05.old attached >> >> please see also below. >> >> On 2015-07-17 13:46, serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> Thanks for the diff, it helps! >>> >>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>> >>> Uninitialized local definition: >>> >>> 105 char ch; >> changed. ch is initialized later, so we actually don't need it. >> >> >>> Unneded second initialization at 111: >>> 104 String carg = _argv[_optind]; >>> 111 carg = _argv[_optind]; >> fixed. >> >>> It is not clear why carg can't be empty: >>> >>> 61 // _argv[_optind] can't be empty, so it's safe to >>> expect at least one character >>> 62 if (_argv[_optind].charAt(0) == '-') { >>> ... >>> >>> 113 // carg can't be empty so it's safe to expect at >>> least one character >>> 114 if (carg.charAt(0) != '-' || carg.equals("--")) { >> changed. >> >> An array passed to getopt is result of splitting arguments string, so no >> empty array element possible. But changed it to be on safe side. >> >>> The _argv comes from outside of the method. >>> How can we be sure that the value _argv[_optind] is not empty String? >>> Does it comes from an assumption that the outside processing works >>> correctly? >>> Would it be better to always check that it is not empty? >>> >>> >>> It feels like this code is not clear and more complex than has to be. >>> But I can't tell yet what has to be simplified. >>> >>> For example, I do not like this part: >>> 37 private boolean _optreset; // special handling of first call >>> >>> 44 _optreset = true; >>> >>> 108 if (_optreset) { >>> >>> 138 _optreset = false; >>> >>> >>> Would it be better to separate this first step from the next() method >>> and make it a separate method that is called reset() or init()? >> Reset called every time when we finish the option batch: >> >> prog -xzvf filename /*reset here*/ -abc >> >>> Also, there is no clue why all this is necessary. >> This is a port of standard BSD getopt (based on C++ code I wrote back in >> 2004), that takes care of all possible option combinations and allow to >> process it uniform way. >> >> I would love to have it JDK-wide instead of a separate parser for each >> tool. >> >>> Other files look good to me. >>> Do you have another reviewer? >> Stefan Larsen reviewed one of the previous versions. >> >> -Dmitry >> >>> >>> >>> On 7/17/15 2:46 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> Previous webrev is: >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05.old >>>> >>>> Latest webrev is: >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>> >>>> Diff between webrev.05.old and webrev.05 attached >>>> >>>> -Dmitry >>>> >>>> On 2015-07-17 01:00, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dmitry, >>>>> >>>>> I do not see any changes. >>>>> Could you please, generate .06 version ? >>>>> In such a case, it will be much easier to compare the code. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 7/16/15 8:23 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>>>> >>>>>> Webrev updated in-place (press shift-reload). >>>>>> >>>>>> Code changes at ll.119. >>>>>> >>>>>> Added more comments to other places. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> Thank you for the update! >>>>>>> The SALauncher.java changes are really nice. >>>>>>> I have just couple of small comments. >>>>>>> >>>>>>> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>> >>>>>>> 343 // Run tmtools >>>>>>> 344 if (args[0].equals("jstack")) { >>>>>>> 345 runJSTACK(oldArgs); >>>>>>> >>>>>>> Why the comment says "Run tmtools", not jstack? >>>>>>> BTW, other fragments have no such a comment which is Ok at it is >>>>>>> obvious. >>>>>>> >>>>>>> >>>>>>> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>> >>>>>>> There are no checks of the carg length in several places where it is >>>>>>> needed: >>>>>>> >>>>>>> 61 if (_argv[_optind].charAt(0) == '-') { >>>>>>> >>>>>>> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>>>>> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == >>>>>>> '-') { >>>>>>> 124 carg = carg.substring(2); >>>>>>> >>>>>>> 136 ch = carg.charAt(_optopt); >>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>> >>>>>>> >>>>>>> Otherwise, the fix looks good. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>>>>>>> Serguei, >>>>>>>> >>>>>>>> Thank you for the review. >>>>>>>> >>>>>>>> New webrev is here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>>>>>>> >>>>>>>> I didn't change naming convention in SAGetoptTest.java and keep >>>>>>>> a_opt, >>>>>>>> b_opt etc as it gives better readability. Other concerns are >>>>>>>> addressed. >>>>>>>> >>>>>>>> BasicLauncherTest changed to use LingeredApp from testlib. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> Some quick minor comments. >>>>>>>>> >>>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>>>> >>>>>>>>> >>>>>>>>> Formatting is wrong: >>>>>>>>> >>>>>>>>> 57 if (_optind >_argv.length) { >>>>>>>>> >>>>>>>>> 71 String[] ca = carg.split("=",2); >>>>>>>>> >>>>>>>>> 80 if (los.contains(ca[0]+"=")) { >>>>>>>>> >>>>>>>>> >>>>>>>>> Need to use camel case for java method names: >>>>>>>>> >>>>>>>>> 55 private void extract_optarg(String opt) { >>>>>>>>> >>>>>>>>> 69 private String process_long_options(String carg, String[] >>>>>>>>> longOptStr) { >>>>>>>>> >>>>>>>>> >>>>>>>>> Need to use quotes for '-': >>>>>>>>> >>>>>>>>> 109 // End of option batch like -abc reached, expect >>>>>>>>> option to start from - >>>>>>>>> >>>>>>>>> Example is: >>>>>>>>> >>>>>>>>> 133 // At this point carg[0] contains '-' >>>>>>>>> >>>>>>>>> >>>>>>>>> Wrong indent at 87, 139, 120-121: >>>>>>>>> >>>>>>>>> 85 else { >>>>>>>>> 86 // Mixed style options --file name >>>>>>>>> 87 extract_optarg(ca[0]); >>>>>>>>> 88 } >>>>>>>>> >>>>>>>>> 138 else { >>>>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>>>> 140 } >>>>>>>>> >>>>>>>>> 119 if (longOptStr == null || >>>>>>>>> longOptStr.length == >>>>>>>>> 0) { >>>>>>>>> 120 // No long options specified, stop >>>>>>>>> options >>>>>>>>> processing >>>>>>>>> 121 return null; >>>>>>>>> 122 } >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>>>> >>>>>>>>> >>>>>>>>> Uninitialized local: >>>>>>>>> >>>>>>>>> 128 String s; >>>>>>>>> >>>>>>>>> Need to use camel case: >>>>>>>>> >>>>>>>>> 126 String exe_or_pid = null; >>>>>>>>> >>>>>>>>> >>>>>>>>> The main method is too long, I'd suggest to split with the >>>>>>>>> sub-methods for: >>>>>>>>> clhsdb, hsdb, jstack, jmap, jinfo >>>>>>>>> >>>>>>>>> >>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>>>>>>> >>>>>>>>> Wrong indent at 82, 85: >>>>>>>>> >>>>>>>>> 80 return toolProcess.exitValue(); >>>>>>>>> 81 } finally { >>>>>>>>> 82 theApp.stopApp(); >>>>>>>>> 83 } >>>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>>> 85 throw new RuntimeException("Test ERROR " >>>>>>>>> + ex, >>>>>>>>> ex); >>>>>>>>> 86 } >>>>>>>>> >>>>>>>>> >>>>>>>>> I do not understand what is the need for nested try statements, >>>>>>>>> just one >>>>>>>>> try would be enough: >>>>>>>>> >>>>>>>>> 54 System.out.println("Starting LingeredApp"); >>>>>>>>> 55 try { >>>>>>>>> 56 try { >>>>>>>>> . . . >>>>>>>>> 81 } finally { >>>>>>>>> 82 theApp.stopApp(); >>>>>>>>> 83 } >>>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>>> 85 throw new RuntimeException("Test ERROR " >>>>>>>>> + ex, >>>>>>>>> ex); >>>>>>>>> 86 } >>>>>>>>> >>>>>>>>> 98 try { >>>>>>>>> 99 try { >>>>>>>>> . . . >>>>>>>>> 116 } finally { >>>>>>>>> 117 theApp.stopApp(); >>>>>>>>> 118 } >>>>>>>>> 119 } catch (Exception ex) { >>>>>>>>> 120 throw new RuntimeException("Test ERROR " + >>>>>>>>> ex, ex); >>>>>>>>> 121 } >>>>>>>>> >>>>>>>>> >>>>>>>>> Why do you catch exceptions and throw the RuntimeException's in >>>>>>>>> the >>>>>>>>> launch() methods >>>>>>>>> but catch the IOException in main? Would it be better to catch any >>>>>>>>> Exception? >>>>>>>>> >>>>>>>>> Too many empty lines: >>>>>>>>> >>>>>>>>> 88 >>>>>>>>> 89 >>>>>>>>> 90 >>>>>>>>> >>>>>>>>> >>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>>>>>>> >>>>>>>>> Too many empty lines: >>>>>>>>> >>>>>>>>> 275 >>>>>>>>> 276 >>>>>>>>> >>>>>>>>> 369 >>>>>>>>> >>>>>>>>> >>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>>>>>>> >>>>>>>>> Need to use Java naming convention: >>>>>>>>> >>>>>>>>> 36 private static boolean a_opt; >>>>>>>>> 37 private static boolean b_opt; >>>>>>>>> 38 private static boolean c_opt; >>>>>>>>> 39 private static boolean e_opt; >>>>>>>>> 40 private static boolean mixed_opt; >>>>>>>>> 41 >>>>>>>>> 42 private static String d_value; >>>>>>>>> 43 private static String exe_value; >>>>>>>>> 44 private static String core_value; >>>>>>>>> >>>>>>>>> Wrong indent 2 instead of 4: >>>>>>>>> >>>>>>>>> 70 if (s.equals("a")) { >>>>>>>>> 71 a_opt = true; >>>>>>>>> 72 continue; >>>>>>>>> 73 } >>>>>>>>> 74 >>>>>>>>> 75 if (s.equals("b")) { >>>>>>>>> 76 b_opt = true; >>>>>>>>> 77 continue; >>>>>>>>> 78 } >>>>>>>>> 79 >>>>>>>>> 80 if (s.equals("c")) { >>>>>>>>> 81 c_opt = true; >>>>>>>>> 82 continue; >>>>>>>>> 83 } >>>>>>>>> 84 >>>>>>>>> 85 if (s.equals("e")) { >>>>>>>>> 86 e_opt = true; >>>>>>>>> 87 continue; >>>>>>>>> 88 } >>>>>>>>> 89 >>>>>>>>> 90 if (s.equals("mixed")) { >>>>>>>>> 91 mixed_opt = true; >>>>>>>>> 92 continue; >>>>>>>>> 93 } >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>>>>>>> Hi Everybody, >>>>>>>>>> >>>>>>>>>> Please review the changes: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>>>>>>> >>>>>>>>>> I'm about to file CCC request for it but would like to get >>>>>>>>>> internal >>>>>>>>>> feedback before that. >>>>>>>>>> >>>>>>>>>> This fix is introducing native launcher jhsdb for serviceability >>>>>>>>>> agent. >>>>>>>>>> >>>>>>>>>> jhsdb >>>>>>>>>> >>>>>>>>>> will launch command line debugger clhsdb >>>>>>>>>> >>>>>>>>>> jhsdb jstack file core >>>>>>>>>> jhsdb jmap file core >>>>>>>>>> jhsdb jinfo file core >>>>>>>>>> >>>>>>>>>> will launch corresponding SA based utility. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Jul 17 14:29:38 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jul 2015 07:29:38 -0700 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A90D9C.10501@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> <55A82981.1090505@oracle.com> <55A8CF0C.7090401@oracle.com> <55A8DD1A.10407@oracle.com> <55A90163.2080509@oracle.com> <55A90306.9070400@oracle.com> <55A90D9C.10501@oracle.com> Message-ID: <55A91152.905@oracle.com> Dmitry, Thanks for new webrev! A couple of comments on hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java The following fragment has the same invariant for both branches: 136 ch = carg.charAt(_optopt); 137 } 138 else { 139 ch = carg.charAt(_optopt); 140 } It can be replaced with: } ch = carg.charAt(_optopt); One more suggestion would be to refactor the if (_optreset) { ... } with a cal to a new method optReset(). But I leave it up to you. Thumbs up from me. Thanks, Serguei On 7/17/15 7:13 AM, Dmitry Samersoff wrote: > Serguei, > > Sorry for typeo > > new webrev: > http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.06 > > -Dmitry > > > On 2015-07-17 16:28, serguei.spitsyn at oracle.com wrote: >> On 7/17/15 6:21 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> new webrev: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >> The webrev is the same. >> I do not see the changes you claim below. >> Could you, please, generate a webrev with another version number? >> >> >> Thanks, >> Serguei >> >>> diff to webrev.05.old attached >>> >>> please see also below. >>> >>> On 2015-07-17 13:46, serguei.spitsyn at oracle.com wrote: >>>> Dmitry, >>>> >>>> Thanks for the diff, it helps! >>>> >>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>> >>>> Uninitialized local definition: >>>> >>>> 105 char ch; >>> changed. ch is initialized later, so we actually don't need it. >>> >>> >>>> Unneded second initialization at 111: >>>> 104 String carg = _argv[_optind]; >>>> 111 carg = _argv[_optind]; >>> fixed. >>> >>>> It is not clear why carg can't be empty: >>>> >>>> 61 // _argv[_optind] can't be empty, so it's safe to >>>> expect at least one character >>>> 62 if (_argv[_optind].charAt(0) == '-') { >>>> ... >>>> >>>> 113 // carg can't be empty so it's safe to expect at >>>> least one character >>>> 114 if (carg.charAt(0) != '-' || carg.equals("--")) { >>> changed. >>> >>> An array passed to getopt is result of splitting arguments string, so no >>> empty array element possible. But changed it to be on safe side. >>> >>>> The _argv comes from outside of the method. >>>> How can we be sure that the value _argv[_optind] is not empty String? >>>> Does it comes from an assumption that the outside processing works >>>> correctly? >>>> Would it be better to always check that it is not empty? >>>> >>>> >>>> It feels like this code is not clear and more complex than has to be. >>>> But I can't tell yet what has to be simplified. >>>> >>>> For example, I do not like this part: >>>> 37 private boolean _optreset; // special handling of first call >>>> >>>> 44 _optreset = true; >>>> >>>> 108 if (_optreset) { >>>> >>>> 138 _optreset = false; >>>> >>>> >>>> Would it be better to separate this first step from the next() method >>>> and make it a separate method that is called reset() or init()? >>> Reset called every time when we finish the option batch: >>> >>> prog -xzvf filename /*reset here*/ -abc >>> >>>> Also, there is no clue why all this is necessary. >>> This is a port of standard BSD getopt (based on C++ code I wrote back in >>> 2004), that takes care of all possible option combinations and allow to >>> process it uniform way. >>> >>> I would love to have it JDK-wide instead of a separate parser for each >>> tool. >>> >>>> Other files look good to me. >>>> Do you have another reviewer? >>> Stefan Larsen reviewed one of the previous versions. >>> >>> -Dmitry >>> >>>> >>>> On 7/17/15 2:46 AM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> Previous webrev is: >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05.old >>>>> >>>>> Latest webrev is: >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>>> >>>>> Diff between webrev.05.old and webrev.05 attached >>>>> >>>>> -Dmitry >>>>> >>>>> On 2015-07-17 01:00, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> I do not see any changes. >>>>>> Could you please, generate .06 version ? >>>>>> In such a case, it will be much easier to compare the code. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 7/16/15 8:23 AM, Dmitry Samersoff wrote: >>>>>>> Serguei, >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>>>>> >>>>>>> Webrev updated in-place (press shift-reload). >>>>>>> >>>>>>> Code changes at ll.119. >>>>>>> >>>>>>> Added more comments to other places. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> Thank you for the update! >>>>>>>> The SALauncher.java changes are really nice. >>>>>>>> I have just couple of small comments. >>>>>>>> >>>>>>>> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>>> >>>>>>>> 343 // Run tmtools >>>>>>>> 344 if (args[0].equals("jstack")) { >>>>>>>> 345 runJSTACK(oldArgs); >>>>>>>> >>>>>>>> Why the comment says "Run tmtools", not jstack? >>>>>>>> BTW, other fragments have no such a comment which is Ok at it is >>>>>>>> obvious. >>>>>>>> >>>>>>>> >>>>>>>> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>>> >>>>>>>> There are no checks of the carg length in several places where it is >>>>>>>> needed: >>>>>>>> >>>>>>>> 61 if (_argv[_optind].charAt(0) == '-') { >>>>>>>> >>>>>>>> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>>>>>> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == >>>>>>>> '-') { >>>>>>>> 124 carg = carg.substring(2); >>>>>>>> >>>>>>>> 136 ch = carg.charAt(_optopt); >>>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>>> >>>>>>>> >>>>>>>> Otherwise, the fix looks good. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>>>>>>>> Serguei, >>>>>>>>> >>>>>>>>> Thank you for the review. >>>>>>>>> >>>>>>>>> New webrev is here: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>>>>>>>> >>>>>>>>> I didn't change naming convention in SAGetoptTest.java and keep >>>>>>>>> a_opt, >>>>>>>>> b_opt etc as it gives better readability. Other concerns are >>>>>>>>> addressed. >>>>>>>>> >>>>>>>>> BasicLauncherTest changed to use LingeredApp from testlib. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> Some quick minor comments. >>>>>>>>>> >>>>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Formatting is wrong: >>>>>>>>>> >>>>>>>>>> 57 if (_optind >_argv.length) { >>>>>>>>>> >>>>>>>>>> 71 String[] ca = carg.split("=",2); >>>>>>>>>> >>>>>>>>>> 80 if (los.contains(ca[0]+"=")) { >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Need to use camel case for java method names: >>>>>>>>>> >>>>>>>>>> 55 private void extract_optarg(String opt) { >>>>>>>>>> >>>>>>>>>> 69 private String process_long_options(String carg, String[] >>>>>>>>>> longOptStr) { >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Need to use quotes for '-': >>>>>>>>>> >>>>>>>>>> 109 // End of option batch like -abc reached, expect >>>>>>>>>> option to start from - >>>>>>>>>> >>>>>>>>>> Example is: >>>>>>>>>> >>>>>>>>>> 133 // At this point carg[0] contains '-' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Wrong indent at 87, 139, 120-121: >>>>>>>>>> >>>>>>>>>> 85 else { >>>>>>>>>> 86 // Mixed style options --file name >>>>>>>>>> 87 extract_optarg(ca[0]); >>>>>>>>>> 88 } >>>>>>>>>> >>>>>>>>>> 138 else { >>>>>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>>>>> 140 } >>>>>>>>>> >>>>>>>>>> 119 if (longOptStr == null || >>>>>>>>>> longOptStr.length == >>>>>>>>>> 0) { >>>>>>>>>> 120 // No long options specified, stop >>>>>>>>>> options >>>>>>>>>> processing >>>>>>>>>> 121 return null; >>>>>>>>>> 122 } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Uninitialized local: >>>>>>>>>> >>>>>>>>>> 128 String s; >>>>>>>>>> >>>>>>>>>> Need to use camel case: >>>>>>>>>> >>>>>>>>>> 126 String exe_or_pid = null; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The main method is too long, I'd suggest to split with the >>>>>>>>>> sub-methods for: >>>>>>>>>> clhsdb, hsdb, jstack, jmap, jinfo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>>>>>>>> >>>>>>>>>> Wrong indent at 82, 85: >>>>>>>>>> >>>>>>>>>> 80 return toolProcess.exitValue(); >>>>>>>>>> 81 } finally { >>>>>>>>>> 82 theApp.stopApp(); >>>>>>>>>> 83 } >>>>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>>>> 85 throw new RuntimeException("Test ERROR " >>>>>>>>>> + ex, >>>>>>>>>> ex); >>>>>>>>>> 86 } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I do not understand what is the need for nested try statements, >>>>>>>>>> just one >>>>>>>>>> try would be enough: >>>>>>>>>> >>>>>>>>>> 54 System.out.println("Starting LingeredApp"); >>>>>>>>>> 55 try { >>>>>>>>>> 56 try { >>>>>>>>>> . . . >>>>>>>>>> 81 } finally { >>>>>>>>>> 82 theApp.stopApp(); >>>>>>>>>> 83 } >>>>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>>>> 85 throw new RuntimeException("Test ERROR " >>>>>>>>>> + ex, >>>>>>>>>> ex); >>>>>>>>>> 86 } >>>>>>>>>> >>>>>>>>>> 98 try { >>>>>>>>>> 99 try { >>>>>>>>>> . . . >>>>>>>>>> 116 } finally { >>>>>>>>>> 117 theApp.stopApp(); >>>>>>>>>> 118 } >>>>>>>>>> 119 } catch (Exception ex) { >>>>>>>>>> 120 throw new RuntimeException("Test ERROR " + >>>>>>>>>> ex, ex); >>>>>>>>>> 121 } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Why do you catch exceptions and throw the RuntimeException's in >>>>>>>>>> the >>>>>>>>>> launch() methods >>>>>>>>>> but catch the IOException in main? Would it be better to catch any >>>>>>>>>> Exception? >>>>>>>>>> >>>>>>>>>> Too many empty lines: >>>>>>>>>> >>>>>>>>>> 88 >>>>>>>>>> 89 >>>>>>>>>> 90 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>>>>>>>> >>>>>>>>>> Too many empty lines: >>>>>>>>>> >>>>>>>>>> 275 >>>>>>>>>> 276 >>>>>>>>>> >>>>>>>>>> 369 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>>>>>>>> >>>>>>>>>> Need to use Java naming convention: >>>>>>>>>> >>>>>>>>>> 36 private static boolean a_opt; >>>>>>>>>> 37 private static boolean b_opt; >>>>>>>>>> 38 private static boolean c_opt; >>>>>>>>>> 39 private static boolean e_opt; >>>>>>>>>> 40 private static boolean mixed_opt; >>>>>>>>>> 41 >>>>>>>>>> 42 private static String d_value; >>>>>>>>>> 43 private static String exe_value; >>>>>>>>>> 44 private static String core_value; >>>>>>>>>> >>>>>>>>>> Wrong indent 2 instead of 4: >>>>>>>>>> >>>>>>>>>> 70 if (s.equals("a")) { >>>>>>>>>> 71 a_opt = true; >>>>>>>>>> 72 continue; >>>>>>>>>> 73 } >>>>>>>>>> 74 >>>>>>>>>> 75 if (s.equals("b")) { >>>>>>>>>> 76 b_opt = true; >>>>>>>>>> 77 continue; >>>>>>>>>> 78 } >>>>>>>>>> 79 >>>>>>>>>> 80 if (s.equals("c")) { >>>>>>>>>> 81 c_opt = true; >>>>>>>>>> 82 continue; >>>>>>>>>> 83 } >>>>>>>>>> 84 >>>>>>>>>> 85 if (s.equals("e")) { >>>>>>>>>> 86 e_opt = true; >>>>>>>>>> 87 continue; >>>>>>>>>> 88 } >>>>>>>>>> 89 >>>>>>>>>> 90 if (s.equals("mixed")) { >>>>>>>>>> 91 mixed_opt = true; >>>>>>>>>> 92 continue; >>>>>>>>>> 93 } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>>>>>>>> Hi Everybody, >>>>>>>>>>> >>>>>>>>>>> Please review the changes: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>>>>>>>> >>>>>>>>>>> I'm about to file CCC request for it but would like to get >>>>>>>>>>> internal >>>>>>>>>>> feedback before that. >>>>>>>>>>> >>>>>>>>>>> This fix is introducing native launcher jhsdb for serviceability >>>>>>>>>>> agent. >>>>>>>>>>> >>>>>>>>>>> jhsdb >>>>>>>>>>> >>>>>>>>>>> will launch command line debugger clhsdb >>>>>>>>>>> >>>>>>>>>>> jhsdb jstack file core >>>>>>>>>>> jhsdb jmap file core >>>>>>>>>>> jhsdb jinfo file core >>>>>>>>>>> >>>>>>>>>>> will launch corresponding SA based utility. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Fri Jul 17 15:10:47 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 17 Jul 2015 18:10:47 +0300 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A91152.905@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> <55A82981.1090505@oracle.com> <55A8CF0C.7090401@oracle.com> <55A8DD1A.10407@oracle.com> <55A90163.2080509@oracle.com> <55A90306.9070400@oracle.com> <55A90D9C.10501@oracle.com> <55A91152.905@oracle.com> Message-ID: <55A91AF7.6090604@oracle.com> Serguei, Thank you for review. > The following fragment has the same invariant for both branches: fixed. (webrev updated in-place, diff to webrev.06.old is attached) > One more suggestion would be to refactor the if (_optreset) { ... } > with a cal to a new method optReset(). I would prefer to leave it as is. The parser reaches one of *tree* sates after optReset: {end_of_processing, processLongOptions_result, need_to_process_short_options} so refactoring it to a separate method adds extra complication. -Dmitry On 2015-07-17 17:29, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thanks for new webrev! > > A couple of comments on > hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java > > The following fragment has the same invariant for both branches: > > 136 ch = carg.charAt(_optopt); > 137 } > 138 else { > 139 ch = carg.charAt(_optopt); > 140 } > > It can be replaced with: > > } > ch = carg.charAt(_optopt); > > > One more suggestion would be to refactor the if (_optreset) { ... } with a cal to a new method optReset(). > > But I leave it up to you. > Thumbs up from me. > > > Thanks, > Serguei > > > On 7/17/15 7:13 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Sorry for typeo >> >> new webrev: >> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.06 >> >> -Dmitry >> >> >> On 2015-07-17 16:28, serguei.spitsyn at oracle.com wrote: >>> On 7/17/15 6:21 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> new webrev: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>> The webrev is the same. >>> I do not see the changes you claim below. >>> Could you, please, generate a webrev with another version number? >>> >>> >>> Thanks, >>> Serguei >>> >>>> diff to webrev.05.old attached >>>> >>>> please see also below. >>>> >>>> On 2015-07-17 13:46, serguei.spitsyn at oracle.com wrote: >>>>> Dmitry, >>>>> >>>>> Thanks for the diff, it helps! >>>>> >>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>> >>>>> Uninitialized local definition: >>>>> >>>>> 105 char ch; >>>> changed. ch is initialized later, so we actually don't need it. >>>> >>>> >>>>> Unneded second initialization at 111: >>>>> 104 String carg = _argv[_optind]; >>>>> 111 carg = _argv[_optind]; >>>> fixed. >>>> >>>>> It is not clear why carg can't be empty: >>>>> >>>>> 61 // _argv[_optind] can't be empty, so it's safe to >>>>> expect at least one character >>>>> 62 if (_argv[_optind].charAt(0) == '-') { >>>>> ... >>>>> >>>>> 113 // carg can't be empty so it's safe to expect at >>>>> least one character >>>>> 114 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>> changed. >>>> >>>> An array passed to getopt is result of splitting arguments string, so no >>>> empty array element possible. But changed it to be on safe side. >>>> >>>>> The _argv comes from outside of the method. >>>>> How can we be sure that the value _argv[_optind] is not empty String? >>>>> Does it comes from an assumption that the outside processing works >>>>> correctly? >>>>> Would it be better to always check that it is not empty? >>>>> >>>>> >>>>> It feels like this code is not clear and more complex than has to be. >>>>> But I can't tell yet what has to be simplified. >>>>> >>>>> For example, I do not like this part: >>>>> 37 private boolean _optreset; // special handling of first call >>>>> >>>>> 44 _optreset = true; >>>>> >>>>> 108 if (_optreset) { >>>>> >>>>> 138 _optreset = false; >>>>> >>>>> >>>>> Would it be better to separate this first step from the next() method >>>>> and make it a separate method that is called reset() or init()? >>>> Reset called every time when we finish the option batch: >>>> >>>> prog -xzvf filename /*reset here*/ -abc >>>> >>>>> Also, there is no clue why all this is necessary. >>>> This is a port of standard BSD getopt (based on C++ code I wrote back in >>>> 2004), that takes care of all possible option combinations and allow to >>>> process it uniform way. >>>> >>>> I would love to have it JDK-wide instead of a separate parser for each >>>> tool. >>>> >>>>> Other files look good to me. >>>>> Do you have another reviewer? >>>> Stefan Larsen reviewed one of the previous versions. >>>> >>>> -Dmitry >>>> >>>>> >>>>> On 7/17/15 2:46 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> Previous webrev is: >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05.old >>>>>> >>>>>> Latest webrev is: >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>>>> >>>>>> Diff between webrev.05.old and webrev.05 attached >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2015-07-17 01:00, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> I do not see any changes. >>>>>>> Could you please, generate .06 version ? >>>>>>> In such a case, it will be much easier to compare the code. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 7/16/15 8:23 AM, Dmitry Samersoff wrote: >>>>>>>> Serguei, >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>>>>>> >>>>>>>> Webrev updated in-place (press shift-reload). >>>>>>>> >>>>>>>> Code changes at ll.119. >>>>>>>> >>>>>>>> Added more comments to other places. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2015-06-27 03:15, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> Thank you for the update! >>>>>>>>> The SALauncher.java changes are really nice. >>>>>>>>> I have just couple of small comments. >>>>>>>>> >>>>>>>>> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>>>> >>>>>>>>> 343 // Run tmtools >>>>>>>>> 344 if (args[0].equals("jstack")) { >>>>>>>>> 345 runJSTACK(oldArgs); >>>>>>>>> >>>>>>>>> Why the comment says "Run tmtools", not jstack? >>>>>>>>> BTW, other fragments have no such a comment which is Ok at it is >>>>>>>>> obvious. >>>>>>>>> >>>>>>>>> >>>>>>>>> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>>>> >>>>>>>>> There are no checks of the carg length in several places where it is >>>>>>>>> needed: >>>>>>>>> >>>>>>>>> 61 if (_argv[_optind].charAt(0) == '-') { >>>>>>>>> >>>>>>>>> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>>>>>>> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == >>>>>>>>> '-') { >>>>>>>>> 124 carg = carg.substring(2); >>>>>>>>> >>>>>>>>> 136 ch = carg.charAt(_optopt); >>>>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>>>> >>>>>>>>> >>>>>>>>> Otherwise, the fix looks good. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>>>>>>>>> Serguei, >>>>>>>>>> >>>>>>>>>> Thank you for the review. >>>>>>>>>> >>>>>>>>>> New webrev is here: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>>>>>>>>> >>>>>>>>>> I didn't change naming convention in SAGetoptTest.java and keep >>>>>>>>>> a_opt, >>>>>>>>>> b_opt etc as it gives better readability. Other concerns are >>>>>>>>>> addressed. >>>>>>>>>> >>>>>>>>>> BasicLauncherTest changed to use LingeredApp from testlib. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2015-06-24 08:32, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> Some quick minor comments. >>>>>>>>>>> >>>>>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Formatting is wrong: >>>>>>>>>>> >>>>>>>>>>> 57 if (_optind >_argv.length) { >>>>>>>>>>> >>>>>>>>>>> 71 String[] ca = carg.split("=",2); >>>>>>>>>>> >>>>>>>>>>> 80 if (los.contains(ca[0]+"=")) { >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Need to use camel case for java method names: >>>>>>>>>>> >>>>>>>>>>> 55 private void extract_optarg(String opt) { >>>>>>>>>>> >>>>>>>>>>> 69 private String process_long_options(String carg, String[] >>>>>>>>>>> longOptStr) { >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Need to use quotes for '-': >>>>>>>>>>> >>>>>>>>>>> 109 // End of option batch like -abc reached, expect >>>>>>>>>>> option to start from - >>>>>>>>>>> >>>>>>>>>>> Example is: >>>>>>>>>>> >>>>>>>>>>> 133 // At this point carg[0] contains '-' >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Wrong indent at 87, 139, 120-121: >>>>>>>>>>> >>>>>>>>>>> 85 else { >>>>>>>>>>> 86 // Mixed style options --file name >>>>>>>>>>> 87 extract_optarg(ca[0]); >>>>>>>>>>> 88 } >>>>>>>>>>> >>>>>>>>>>> 138 else { >>>>>>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>>>>>> 140 } >>>>>>>>>>> >>>>>>>>>>> 119 if (longOptStr == null || >>>>>>>>>>> longOptStr.length == >>>>>>>>>>> 0) { >>>>>>>>>>> 120 // No long options specified, stop >>>>>>>>>>> options >>>>>>>>>>> processing >>>>>>>>>>> 121 return null; >>>>>>>>>>> 122 } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Uninitialized local: >>>>>>>>>>> >>>>>>>>>>> 128 String s; >>>>>>>>>>> >>>>>>>>>>> Need to use camel case: >>>>>>>>>>> >>>>>>>>>>> 126 String exe_or_pid = null; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The main method is too long, I'd suggest to split with the >>>>>>>>>>> sub-methods for: >>>>>>>>>>> clhsdb, hsdb, jstack, jmap, jinfo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>>>>>>>>> >>>>>>>>>>> Wrong indent at 82, 85: >>>>>>>>>>> >>>>>>>>>>> 80 return toolProcess.exitValue(); >>>>>>>>>>> 81 } finally { >>>>>>>>>>> 82 theApp.stopApp(); >>>>>>>>>>> 83 } >>>>>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>>>>> 85 throw new RuntimeException("Test ERROR " >>>>>>>>>>> + ex, >>>>>>>>>>> ex); >>>>>>>>>>> 86 } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I do not understand what is the need for nested try statements, >>>>>>>>>>> just one >>>>>>>>>>> try would be enough: >>>>>>>>>>> >>>>>>>>>>> 54 System.out.println("Starting LingeredApp"); >>>>>>>>>>> 55 try { >>>>>>>>>>> 56 try { >>>>>>>>>>> . . . >>>>>>>>>>> 81 } finally { >>>>>>>>>>> 82 theApp.stopApp(); >>>>>>>>>>> 83 } >>>>>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>>>>> 85 throw new RuntimeException("Test ERROR " >>>>>>>>>>> + ex, >>>>>>>>>>> ex); >>>>>>>>>>> 86 } >>>>>>>>>>> >>>>>>>>>>> 98 try { >>>>>>>>>>> 99 try { >>>>>>>>>>> . . . >>>>>>>>>>> 116 } finally { >>>>>>>>>>> 117 theApp.stopApp(); >>>>>>>>>>> 118 } >>>>>>>>>>> 119 } catch (Exception ex) { >>>>>>>>>>> 120 throw new RuntimeException("Test ERROR " + >>>>>>>>>>> ex, ex); >>>>>>>>>>> 121 } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Why do you catch exceptions and throw the RuntimeException's in >>>>>>>>>>> the >>>>>>>>>>> launch() methods >>>>>>>>>>> but catch the IOException in main? Would it be better to catch any >>>>>>>>>>> Exception? >>>>>>>>>>> >>>>>>>>>>> Too many empty lines: >>>>>>>>>>> >>>>>>>>>>> 88 >>>>>>>>>>> 89 >>>>>>>>>>> 90 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>>>>>>>>> >>>>>>>>>>> Too many empty lines: >>>>>>>>>>> >>>>>>>>>>> 275 >>>>>>>>>>> 276 >>>>>>>>>>> >>>>>>>>>>> 369 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>>>>>>>>> >>>>>>>>>>> Need to use Java naming convention: >>>>>>>>>>> >>>>>>>>>>> 36 private static boolean a_opt; >>>>>>>>>>> 37 private static boolean b_opt; >>>>>>>>>>> 38 private static boolean c_opt; >>>>>>>>>>> 39 private static boolean e_opt; >>>>>>>>>>> 40 private static boolean mixed_opt; >>>>>>>>>>> 41 >>>>>>>>>>> 42 private static String d_value; >>>>>>>>>>> 43 private static String exe_value; >>>>>>>>>>> 44 private static String core_value; >>>>>>>>>>> >>>>>>>>>>> Wrong indent 2 instead of 4: >>>>>>>>>>> >>>>>>>>>>> 70 if (s.equals("a")) { >>>>>>>>>>> 71 a_opt = true; >>>>>>>>>>> 72 continue; >>>>>>>>>>> 73 } >>>>>>>>>>> 74 >>>>>>>>>>> 75 if (s.equals("b")) { >>>>>>>>>>> 76 b_opt = true; >>>>>>>>>>> 77 continue; >>>>>>>>>>> 78 } >>>>>>>>>>> 79 >>>>>>>>>>> 80 if (s.equals("c")) { >>>>>>>>>>> 81 c_opt = true; >>>>>>>>>>> 82 continue; >>>>>>>>>>> 83 } >>>>>>>>>>> 84 >>>>>>>>>>> 85 if (s.equals("e")) { >>>>>>>>>>> 86 e_opt = true; >>>>>>>>>>> 87 continue; >>>>>>>>>>> 88 } >>>>>>>>>>> 89 >>>>>>>>>>> 90 if (s.equals("mixed")) { >>>>>>>>>>> 91 mixed_opt = true; >>>>>>>>>>> 92 continue; >>>>>>>>>>> 93 } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>> >>>>>>>>>>>> Please review the changes: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>>>>>>>>> >>>>>>>>>>>> I'm about to file CCC request for it but would like to get >>>>>>>>>>>> internal >>>>>>>>>>>> feedback before that. >>>>>>>>>>>> >>>>>>>>>>>> This fix is introducing native launcher jhsdb for serviceability >>>>>>>>>>>> agent. >>>>>>>>>>>> >>>>>>>>>>>> jhsdb >>>>>>>>>>>> >>>>>>>>>>>> will launch command line debugger clhsdb >>>>>>>>>>>> >>>>>>>>>>>> jhsdb jstack file core >>>>>>>>>>>> jhsdb jmap file core >>>>>>>>>>>> jhsdb jinfo file core >>>>>>>>>>>> >>>>>>>>>>>> will launch corresponding SA based utility. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- diff -ur webrevs_003/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java --- webrevs_003/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java 2015-07-17 16:01:36.000000000 +0300 +++ webrevs/hotspot_webrev/raw_files/new/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java 2015-07-17 17:56:00.000000000 +0300 @@ -101,7 +101,6 @@ } String carg = _argv[_optind]; - char ch = '-'; _optarg = null; if (_optreset) { @@ -133,12 +132,10 @@ // At this point carg[0] contains '-' _optreset = false; _optopt = 1; - ch = carg.charAt(_optopt); - } - else { - ch = carg.charAt(_optopt); } + char ch = carg.charAt(_optopt); + // adjust pointer to next character _optopt += 1; From joe.darcy at oracle.com Fri Jul 17 16:46:25 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 17 Jul 2015 09:46:25 -0700 Subject: RFR(XS): 8075658: Mark intermittently failuring core-svc tests In-Reply-To: <55A908EB.2030500@oracle.com> References: <55A8F954.8050202@oracle.com> <55A8FD47.6030404@oracle.com> <55A90427.5040808@oracle.com> <55A908EB.2030500@oracle.com> Message-ID: <55A93161.6060001@oracle.com> Hello, Yes, my general guidance is to make sure flaky tests are marked as "intermittent" in the test itself. This lets someone running the test easily check if the test is known to be unreliable *in that state of the sources*. There is a upfront overhead to collecting information about the current unreliable tests from the bug database, personal notes, etc. However, I would expect the marginal cost to keep the intermittent-ness updated to be small and marking the tests this way should allow easier analysis of failures. Thanks, -Joe On 7/17/2015 6:53 AM, olivier.lagneau at oracle.com wrote: > Hi Katja, > > Looks ok to me too. > >> >> It has been a relatively manual process and I'm not aware of a >> mechanism how to sync test-key-bug. What I can do is to mark bugs I >> went through with for example 'key-intermittent' label to distinguish >> them form the new ones. > That's another additional label, and as I understand Joe's comment > most important is to mark them intermittent with jtreg flag. > Don't have any other suggestions however. > > Olivier. > > On 17/07/2015 15:33, Yekaterina Kantserova wrote: >> Jaroslav, >> >> Thank you for the review! >> >> It has been a relatively manual process and I'm not aware of a >> mechanism how to sync test-key-bug. What I can do is to mark bugs I >> went through with for example 'key-intermittent' label to distinguish >> them form the new ones. >> >> Are there other suggestions? >> >> // Katja >> >> >> >> On 07/17/2015 03:04 PM, Jaroslav Bachorik wrote: >>> Looks good. >>> >>> Is there any way to check that all the issues from the JBS query >>> mentioned in JDK-8075658 are addressed? >>> >>> -JB- >>> >>> On 17.7.2015 14:47, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075658 >>>> webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00 >>>> >>>> Thanks, >>>> Katja >>> >> > From dmitry.samersoff at oracle.com Sat Jul 18 10:12:30 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 18 Jul 2015 13:12:30 +0300 Subject: RFR: JDK-8114828: wrong class file error when compiling tests In-Reply-To: <1e7848f5-da70-497a-bc2a-a082ebb54e82@default> References: <1e7848f5-da70-497a-bc2a-a082ebb54e82@default> Message-ID: <55AA268E.9020104@oracle.com> Alexander, Looks good for me. But I'm second to Jaroslav - please, file other CR to push these changes. -Dmitry On 2015-07-17 15:59, Alexander Kulyakhtin wrote: > Jaroslav, > > Ok, I'm going to create a new low-severity issue to replace /../.. with external.lib.roots property throughout the hotspot repo. > > The original issue, as the development team pointed out in the comments, is likely to be caused by the concurrent running of jtreg tests and will remain open for further investigation. > > Best regards, > Alexander > > ----- Original Message ----- > From: jaroslav.bachorik at oracle.com > To: serviceability-dev at openjdk.java.net > Sent: Friday, July 17, 2015 3:41:19 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests > > I'm OK with this change. > However, I think it would be better to open a new issue for the code > cleanup and not use the nightly-failure related one - especially since > the change would not be really fixing the failure. > > Thanks, > > -JB- > > On 17.7.2015 13:13, Alexander Kulyakhtin wrote: >> Hi, >> >> Can the changes below be approven? >> Although they are not strictly necessary, it is better to use external.lib.roots property instead of specifying too many upper-level directories, to take advantage of the latest jtreg version. >> >> The issue itself has not been observed with the latest JDK9 build on any platform. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" >> Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html >> >> Best regards, >> Alexander >> >> >> ----- Original Message ----- >> From: alexander.kulyakhtin at oracle.com >> To: david.holmes at oracle.com >> Cc: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net >> Sent: Thursday, July 16, 2015 4:39:14 PM GMT +03:00 Iraq >> Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests >> >> David, >> >> I was mistaken saying that jtreg does not allow @library to point out above the test root. >> On further investigation the issue appears to be an Aurora setup issue and the proposed earlier fix is not needed. >> We are investigating the cause of the issue. >> >> Best regards, >> Alexander >> >> ----- Original Message ----- >> From: david.holmes at oracle.com >> To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net >> Sent: Thursday, July 16, 2015 4:53:08 AM GMT +03:00 Iraq >> Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests >> >> Adding in hotspot-dev as there's a meta-question here >> >> Hi Alexander, >> >> On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: >>> Hi, >>> >>> Could you, please, review these simple test-only changes: >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" >>> (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) >>> >>> Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html >>> >>> Before the change the @library tags in the tests pointed to the directory above the tests repository. >>> With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. >>> >>> The tests have been modified accordingly, so they now compile successfully. >> >> We currently have 272 tests in hotspot/test that specify some variant of: >> >> @library /testlibrary /../../test/lib >> >> Are these now all broken with jtreg b12? >> >> Why do these serviceability tests specify: >> >> test/lib/share/classes >> >> when all the other tests just specify: >> >> test/lib >> >> ? >> >> Thanks, >> David >> >>> Best regards, >>> Alexander >>> > -- 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 vladimir.kempik at oracle.com Mon Jul 20 14:20:45 2015 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Mon, 20 Jul 2015 17:20:45 +0300 Subject: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked In-Reply-To: <55A66EC0.2020202@oracle.com> References: <55A53006.1030307@oracle.com> <55A53122.8000409@oracle.com> <55A53702.6000309@oracle.com> <55A66EC0.2020202@oracle.com> Message-ID: <55AD03BD.9050306@oracle.com> hello Can I have one more review for this please? jstack/tmtools tested passed fine. Thanks, Vladimir. On 15.07.2015 17:31, Vladimir Kempik wrote: > Hello > > Thanks for looking into this. > > Where can I find jstack/tmtools tests to run them ? > > Thanks, Vladimir. > > On 14.07.2015 19:21, Daniel D. Daugherty wrote: >> > Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ >> >> src/share/vm/classfile/javaClasses.cpp >> No comments. (Thanks for including the "" case.) >> >> src/share/vm/classfile/javaClasses.hpp >> No comments. >> >> src/share/vm/runtime/vframe.cpp >> No comments. >> >> Thumbs up (modulo running the proper tests). >> >> Dan >> >> >> On 7/14/15 9:56 AM, Daniel D. Daugherty wrote: >>> Adding serviceability-dev at ... since jstack belongs to the >>> Serviceability team... >>> >>> The jstack and/or tmtools tests should also be run... >>> >>> Dan >>> >>> >>> On 7/14/15 9:51 AM, Vladimir Kempik wrote: >>>> Hello, >>>> >>>> Please review the patch to fix 8048353. >>>> Customer has an issue with this bug when running jstack on jdk7. >>>> He tested FVB and cofirmed it has fixed the issue. >>>> Before pushing jdk7 backport I need to get the fix to 9 and 8. >>>> >>>> Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353 >>>> >>>> testing: JPRT. >>>> >>>> Thanks, Vladimir. >>> >> > From daniel.daugherty at oracle.com Mon Jul 20 14:39:46 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 Jul 2015 08:39:46 -0600 Subject: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked In-Reply-To: <55AD03BD.9050306@oracle.com> References: <55A53006.1030307@oracle.com> <55A53122.8000409@oracle.com> <55A53702.6000309@oracle.com> <55A66EC0.2020202@oracle.com> <55AD03BD.9050306@oracle.com> Message-ID: <55AD0832.90309@oracle.com> Vladimir, I see reviews from me, Coleen, and David H. That's three (R)eviewers. Are you waiting for a review from someone in Serviceability? Dan On 7/20/15 8:20 AM, Vladimir Kempik wrote: > hello > > Can I have one more review for this please? > > jstack/tmtools tested passed fine. > > Thanks, Vladimir. > > On 15.07.2015 17:31, Vladimir Kempik wrote: >> Hello >> >> Thanks for looking into this. >> >> Where can I find jstack/tmtools tests to run them ? >> >> Thanks, Vladimir. >> >> On 14.07.2015 19:21, Daniel D. Daugherty wrote: >>> > Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ >>> >>> src/share/vm/classfile/javaClasses.cpp >>> No comments. (Thanks for including the "" case.) >>> >>> src/share/vm/classfile/javaClasses.hpp >>> No comments. >>> >>> src/share/vm/runtime/vframe.cpp >>> No comments. >>> >>> Thumbs up (modulo running the proper tests). >>> >>> Dan >>> >>> >>> On 7/14/15 9:56 AM, Daniel D. Daugherty wrote: >>>> Adding serviceability-dev at ... since jstack belongs to the >>>> Serviceability team... >>>> >>>> The jstack and/or tmtools tests should also be run... >>>> >>>> Dan >>>> >>>> >>>> On 7/14/15 9:51 AM, Vladimir Kempik wrote: >>>>> Hello, >>>>> >>>>> Please review the patch to fix 8048353. >>>>> Customer has an issue with this bug when running jstack on jdk7. >>>>> He tested FVB and cofirmed it has fixed the issue. >>>>> Before pushing jdk7 backport I need to get the fix to 9 and 8. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/ >>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353 >>>>> >>>>> testing: JPRT. >>>>> >>>>> Thanks, Vladimir. >>>> >>> >> > > > From iris.clark at oracle.com Tue Jul 21 05:30:30 2015 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 20 Jul 2015 22:30:30 -0700 (PDT) Subject: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning) Message-ID: Hi. Please review changes to resolve the following bug: 8132003: Update javax/management regression test for Verona (versioning) Bug: https://bugs.openjdk.java.net/browse/JDK-8132003 The regression test javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails in Verona [0,1] builds because it assumes that the system property java.verison will always begin with "1.". Verona drops this part of the version string for JDK 9 and later. The test attempts to discern whether it is being run against JDK 1.4 or earlier. Since I believe that this test will never be run against JDK 1.4, I expect that we can entirely remove the conditional. Here's the required diff: --- a/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java Mon Jul 20 11:01:24 2015 -0700 +++ b/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java Mon Jul 20 19:31:54 2015 -0700 @@ -24,7 +24,7 @@ /* * @test * @summary Tests to send a not serializable notification. - * @bug 5022196 + * @bug 5022196 8132003 * @author Shanliang JIANG * @modules java.management * @run clean NotSerializableNotifTest @@ -53,22 +53,13 @@ private static final MBeanServer mbeanServer = MBeanServerFactory.createMBeanServer(); private static ObjectName emitter; - private static String[] protocols; + private static String[] protocols = new String[] {"rmi", "iiop", "jmxmp"}; private static final int sentNotifs = 10; public static void main(String[] args) throws Exception { System.out.println(">>> Test to send a not serializable notification"); - // IIOP fails on JDK1.4, see 5034318 - final String v = System.getProperty("java.version"); - float f = Float.parseFloat(v.substring(0, 3)); - if (f<1.5) { - protocols = new String[] {"rmi", "jmxmp"}; - } else { - protocols = new String[] {"rmi", "iiop", "jmxmp"}; - } - emitter = new ObjectName("Default:name=NotificationEmitter"); mbeanServer.registerMBean(new NotificationEmitter(), emitter); If you believe that we need to keep the conditional, I can submit an alternate diff. Let me know what you'd prefer. Please also let me know if there are any JMX-specific development processes I should be aware of (e.g. required number of Reviewers, testing requirements, etc.). After review, the changeset will be pushed to verona/stage [2]. The changeset will go to jdk9/* when Verona is complete later this summer. Thanks, iris [0] http://openjdk.java.net/projects/verona [1] http://openjdk.java.net/jeps/223 [2] http://hg.openjdk.java.net/verona/stage From daniel.fuchs at oracle.com Tue Jul 21 10:14:34 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 21 Jul 2015 12:14:34 +0200 Subject: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning) In-Reply-To: References: Message-ID: <55AE1B8A.5050903@oracle.com> Hi Iris, This looks reasonable to me. best regards, -- daniel On 21/07/15 07:30, Iris Clark wrote: > Hi. > > Please review changes to resolve the following bug: > > 8132003: Update javax/management regression test for Verona (versioning) > Bug: https://bugs.openjdk.java.net/browse/JDK-8132003 > > The regression test javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails in Verona [0,1] builds because it assumes that the system property java.verison will always begin with "1.". Verona drops this part of the version string for JDK 9 and later. > > The test attempts to discern whether it is being run against JDK 1.4 or earlier. Since I believe that this test will never be run against JDK 1.4, I expect that we can entirely remove the conditional. Here's the required diff: > > --- a/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java > Mon Jul 20 11:01:24 2015 -0700 > +++ b/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java > Mon Jul 20 19:31:54 2015 -0700 > @@ -24,7 +24,7 @@ > /* > * @test > * @summary Tests to send a not serializable notification. > - * @bug 5022196 > + * @bug 5022196 8132003 > * @author Shanliang JIANG > * @modules java.management > * @run clean NotSerializableNotifTest > @@ -53,22 +53,13 @@ > private static final MBeanServer mbeanServer = MBeanServerFactory.createMBeanServer(); > private static ObjectName emitter; > > - private static String[] protocols; > + private static String[] protocols = new String[] {"rmi", "iiop", "jmxmp"}; > > private static final int sentNotifs = 10; > > public static void main(String[] args) throws Exception { > System.out.println(">>> Test to send a not serializable notification"); > > - // IIOP fails on JDK1.4, see 5034318 > - final String v = System.getProperty("java.version"); > - float f = Float.parseFloat(v.substring(0, 3)); > - if (f<1.5) { > - protocols = new String[] {"rmi", "jmxmp"}; > - } else { > - protocols = new String[] {"rmi", "iiop", "jmxmp"}; > - } > - > emitter = new ObjectName("Default:name=NotificationEmitter"); > mbeanServer.registerMBean(new NotificationEmitter(), emitter); > > If you believe that we need to keep the conditional, I can submit an alternate diff. Let me know what you'd prefer. Please also let me know if there are any JMX-specific development processes I should be aware of (e.g. required number of Reviewers, testing requirements, etc.). > > After review, the changeset will be pushed to verona/stage [2]. The changeset will go to jdk9/* when Verona is complete later this summer. > > Thanks, > iris > > [0] http://openjdk.java.net/projects/verona > [1] http://openjdk.java.net/jeps/223 > [2] http://hg.openjdk.java.net/verona/stage > From shanliang.jiang at oracle.com Tue Jul 21 10:21:19 2015 From: shanliang.jiang at oracle.com (Shanliang Jiang) Date: Tue, 21 Jul 2015 12:21:19 +0200 Subject: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning) In-Reply-To: References: Message-ID: <55AE1D1F.6000800@oracle.com> Iris, The fix ooks good. Shanliang Iris Clark wrote: > Hi. > > Please review changes to resolve the following bug: > > 8132003: Update javax/management regression test for Verona (versioning) > Bug: https://bugs.openjdk.java.net/browse/JDK-8132003 > > The regression test javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails in Verona [0,1] builds because it assumes that the system property java.verison will always begin with "1.". Verona drops this part of the version string for JDK 9 and later. > > The test attempts to discern whether it is being run against JDK 1.4 or earlier. Since I believe that this test will never be run against JDK 1.4, I expect that we can entirely remove the conditional. Here's the required diff: > > --- a/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java > Mon Jul 20 11:01:24 2015 -0700 > +++ b/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java > Mon Jul 20 19:31:54 2015 -0700 > @@ -24,7 +24,7 @@ > /* > * @test > * @summary Tests to send a not serializable notification. > - * @bug 5022196 > + * @bug 5022196 8132003 > * @author Shanliang JIANG > * @modules java.management > * @run clean NotSerializableNotifTest > @@ -53,22 +53,13 @@ > private static final MBeanServer mbeanServer = MBeanServerFactory.createMBeanServer(); > private static ObjectName emitter; > > - private static String[] protocols; > + private static String[] protocols = new String[] {"rmi", "iiop", "jmxmp"}; > > private static final int sentNotifs = 10; > > public static void main(String[] args) throws Exception { > System.out.println(">>> Test to send a not serializable notification"); > > - // IIOP fails on JDK1.4, see 5034318 > - final String v = System.getProperty("java.version"); > - float f = Float.parseFloat(v.substring(0, 3)); > - if (f<1.5) { > - protocols = new String[] {"rmi", "jmxmp"}; > - } else { > - protocols = new String[] {"rmi", "iiop", "jmxmp"}; > - } > - > emitter = new ObjectName("Default:name=NotificationEmitter"); > mbeanServer.registerMBean(new NotificationEmitter(), emitter); > > If you believe that we need to keep the conditional, I can submit an alternate diff. Let me know what you'd prefer. Please also let me know if there are any JMX-specific development processes I should be aware of (e.g. required number of Reviewers, testing requirements, etc.). > > After review, the changeset will be pushed to verona/stage [2]. The changeset will go to jdk9/* when Verona is complete later this summer. > > Thanks, > iris > > [0] http://openjdk.java.net/projects/verona > [1] http://openjdk.java.net/jeps/223 > [2] http://hg.openjdk.java.net/verona/stage > From jaroslav.bachorik at oracle.com Tue Jul 21 10:32:57 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jul 2015 12:32:57 +0200 Subject: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning) In-Reply-To: References: Message-ID: <55AE1FD9.8000608@oracle.com> Looks fine. Not likely this test will ever be run on pre JDK 1.5. -JB- On 21.7.2015 07:30, Iris Clark wrote: > Hi. > > Please review changes to resolve the following bug: > > 8132003: Update javax/management regression test for Verona (versioning) > Bug: https://bugs.openjdk.java.net/browse/JDK-8132003 > > The regression test javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails in Verona [0,1] builds because it assumes that the system property java.verison will always begin with "1.". Verona drops this part of the version string for JDK 9 and later. > > The test attempts to discern whether it is being run against JDK 1.4 or earlier. Since I believe that this test will never be run against JDK 1.4, I expect that we can entirely remove the conditional. Here's the required diff: > > --- a/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java > Mon Jul 20 11:01:24 2015 -0700 > +++ b/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java > Mon Jul 20 19:31:54 2015 -0700 > @@ -24,7 +24,7 @@ > /* > * @test > * @summary Tests to send a not serializable notification. > - * @bug 5022196 > + * @bug 5022196 8132003 > * @author Shanliang JIANG > * @modules java.management > * @run clean NotSerializableNotifTest > @@ -53,22 +53,13 @@ > private static final MBeanServer mbeanServer = MBeanServerFactory.createMBeanServer(); > private static ObjectName emitter; > > - private static String[] protocols; > + private static String[] protocols = new String[] {"rmi", "iiop", "jmxmp"}; > > private static final int sentNotifs = 10; > > public static void main(String[] args) throws Exception { > System.out.println(">>> Test to send a not serializable notification"); > > - // IIOP fails on JDK1.4, see 5034318 > - final String v = System.getProperty("java.version"); > - float f = Float.parseFloat(v.substring(0, 3)); > - if (f<1.5) { > - protocols = new String[] {"rmi", "jmxmp"}; > - } else { > - protocols = new String[] {"rmi", "iiop", "jmxmp"}; > - } > - > emitter = new ObjectName("Default:name=NotificationEmitter"); > mbeanServer.registerMBean(new NotificationEmitter(), emitter); > > If you believe that we need to keep the conditional, I can submit an alternate diff. Let me know what you'd prefer. Please also let me know if there are any JMX-specific development processes I should be aware of (e.g. required number of Reviewers, testing requirements, etc.). > > After review, the changeset will be pushed to verona/stage [2]. The changeset will go to jdk9/* when Verona is complete later this summer. > > Thanks, > iris > > [0] http://openjdk.java.net/projects/verona > [1] http://openjdk.java.net/jeps/223 > [2] http://hg.openjdk.java.net/verona/stage > From iris.clark at oracle.com Tue Jul 21 17:21:44 2015 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 21 Jul 2015 10:21:44 -0700 (PDT) Subject: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning) In-Reply-To: <55AE1FD9.8000608@oracle.com> References: <55AE1FD9.8000608@oracle.com> Message-ID: Hi, Jaroslav, Shanliang, and Daniel. Thank you all for speedy review. I'll push the changeset to verona/stage shortly. Regards, iris -----Original Message----- From: Jaroslav Bachorik Sent: Tuesday, July 21, 2015 3:33 AM To: serviceability-dev at openjdk.java.net Subject: Re: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning) Looks fine. Not likely this test will ever be run on pre JDK 1.5. -JB- On 21.7.2015 07:30, Iris Clark wrote: > Hi. > > Please review changes to resolve the following bug: > > 8132003: Update javax/management regression test for Verona > (versioning) > Bug: https://bugs.openjdk.java.net/browse/JDK-8132003 > > The regression test javax/management/remote/mandatory/notif/NotSerializableNotifTest.java fails in Verona [0,1] builds because it assumes that the system property java.verison will always begin with "1.". Verona drops this part of the version string for JDK 9 and later. > > The test attempts to discern whether it is being run against JDK 1.4 or earlier. Since I believe that this test will never be run against JDK 1.4, I expect that we can entirely remove the conditional. Here's the required diff: > > --- a/test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java > Mon Jul 20 11:01:24 2015 -0700 > +++ b/test/javax/management/remote/mandatory/notif/NotSerializableNoti > +++ fTest.java > Mon Jul 20 19:31:54 2015 -0700 @@ -24,7 +24,7 @@ > /* > * @test > * @summary Tests to send a not serializable notification. > - * @bug 5022196 > + * @bug 5022196 8132003 > * @author Shanliang JIANG > * @modules java.management > * @run clean NotSerializableNotifTest @@ -53,22 +53,13 @@ > private static final MBeanServer mbeanServer = MBeanServerFactory.createMBeanServer(); > private static ObjectName emitter; > > - private static String[] protocols; > + private static String[] protocols = new String[] {"rmi", "iiop", > + "jmxmp"}; > > private static final int sentNotifs = 10; > > public static void main(String[] args) throws Exception { > System.out.println(">>> Test to send a not serializable > notification"); > > - // IIOP fails on JDK1.4, see 5034318 > - final String v = System.getProperty("java.version"); > - float f = Float.parseFloat(v.substring(0, 3)); > - if (f<1.5) { > - protocols = new String[] {"rmi", "jmxmp"}; > - } else { > - protocols = new String[] {"rmi", "iiop", "jmxmp"}; > - } > - > emitter = new ObjectName("Default:name=NotificationEmitter"); > mbeanServer.registerMBean(new NotificationEmitter(), > emitter); > > If you believe that we need to keep the conditional, I can submit an alternate diff. Let me know what you'd prefer. Please also let me know if there are any JMX-specific development processes I should be aware of (e.g. required number of Reviewers, testing requirements, etc.). > > After review, the changeset will be pushed to verona/stage [2]. The changeset will go to jdk9/* when Verona is complete later this summer. > > Thanks, > iris > > [0] http://openjdk.java.net/projects/verona > [1] http://openjdk.java.net/jeps/223 > [2] http://hg.openjdk.java.net/verona/stage > From jaroslav.bachorik at oracle.com Tue Jul 21 17:37:49 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jul 2015 19:37:49 +0200 Subject: RFR 8132059: com/sun/jdi/BreakpointTest.java fails with java.lang.IllegalArgumentException: Bad line number Message-ID: <55AE836D.1000509@oracle.com> Please, review this plain backout of JDK-8075658 (http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6148d6f85eaa). Issue : https://bugs.openjdk.java.net/browse/JDK-8132059 Webrev: http://cr.openjdk.java.net/~jbachorik/8132059/webrev.00 The changeset for JDK-8075658 caused several tests to fail due to their dependency on the exact line number. This request is to backout the change till the original fix is revisited. Thanks, -JB- From iris.clark at oracle.com Tue Jul 21 17:39:35 2015 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 21 Jul 2015 10:39:35 -0700 (PDT) Subject: RFR (xs) 8132003: Update javax/management regression test for Verona (versioning) Message-ID: <315afcec-e298-48d0-88cb-4dfb1da5bb1c@default> Hi, Jaroslav, Shanliang, and Daniel. I pushed the changeset this morning to verona/stage. Expect the changeset to get to jdk9/* when we Verona is complete, later this summer. Thanks again for all your help. iris -----Original Message----- From: verona-dev [mailto:verona-dev-bounces at openjdk.java.net] On Behalf Of iris.clark at oracle.com Sent: Tuesday, July 21, 2015 10:29 AM To: verona-dev at openjdk.java.net Subject: hg: verona/stage/jdk: 8132003: Update javax/management regression test for Verona (versioning) Changeset: 5b2729b93dee Author: iris Date: 2015-07-21 10:28 -0700 URL: http://hg.openjdk.java.net/verona/stage/jdk/rev/5b2729b93dee 8132003: Update javax/management regression test for Verona (versioning) Reviewed-by: dfuchs, jbachorik, sjiang ! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java From daniel.daugherty at oracle.com Tue Jul 21 18:01:22 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Jul 2015 12:01:22 -0600 Subject: RFR 8132059: com/sun/jdi/BreakpointTest.java fails with java.lang.IllegalArgumentException: Bad line number In-Reply-To: <55AE836D.1000509@oracle.com> References: <55AE836D.1000509@oracle.com> Message-ID: <55AE88F2.4040202@oracle.com> On 7/21/15 11:37 AM, Jaroslav Bachorik wrote: > Please, review this plain backout of JDK-8075658 > (http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/6148d6f85eaa). > > Issue : https://bugs.openjdk.java.net/browse/JDK-8132059 > Webrev: http://cr.openjdk.java.net/~jbachorik/8132059/webrev.00 Thumbs up. Thanks for taking care of this so quickly. Dan > > The changeset for JDK-8075658 caused several tests to fail due to > their dependency on the exact line number. This request is to backout > the change till the original fix is revisited. > > Thanks, > > -JB- From yekaterina.kantserova at oracle.com Wed Jul 22 13:50:54 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 22 Jul 2015 15:50:54 +0200 Subject: RFR(XS): 8132094: Mark intermittently failuring core-svc tests Message-ID: <55AF9FBE.2060209@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8132094 webrev: http://cr.openjdk.java.net/~ykantser/8132094/webrev.00 Thanks, Katja From olivier.lagneau at oracle.com Wed Jul 22 16:25:21 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Wed, 22 Jul 2015 18:25:21 +0200 Subject: RFR (XXS): JDK-8131783 : Put LowMemoryTest.java in quarantine Message-ID: <55AFC3F1.9040900@oracle.com> Hi, Could you please review this very light fix: bug: https://bugs.openjdk.java.net/browse/JDK-8131783 webrev: http://cr.openjdk.java.net/~olagneau/8131783/webrev.00/ We first quarantine the test. We will then add tracing information to help diagnosing the problem (https://bugs.openjdk.java.net/browse/JDK-8131784), monitoring the quarantined runs when it fails again. Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Jul 22 17:22:12 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jul 2015 13:22:12 -0400 Subject: RFR 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine Message-ID: <55AFD144.9010102@oracle.com> Summary: Need to get source_file_name from the_class's constant pool not previous version constant pool open webrev at http://cr.openjdk.java.net/~coleenp/8087315.01/ bug link https://bugs.openjdk.java.net/browse/JDK-8087315 Tested with added test (yay!), RBT (remote build and test), vm.redefine.testlist, jdk/test/java/lang/instrument and failing testcase 1000 times (reproduced <400). Thanks, Coleen From jeremymanson at google.com Wed Jul 22 18:22:14 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 22 Jul 2015 11:22:14 -0700 Subject: os::current_thread_id on Linux Message-ID: Hey folks, os::current_thread_id on Linux now maps to pthread_self. The problem with pthread_self is that it only makes sense in the context of the running process. When it is written out to the log (as it is in several places), there really isn't a way (AFAICT) for the user to map it back to anything useful. As it happens, that value is mostly used to write to the log. The places where it doesn't do so don't seem to need to use pthread_self for any particular reason. Meanwhile, the SIGQUIT stack dump uses java_thread->osthread()->thread_id() as the nid. On Linux, that maps back to os::Linux::gettid(), whish is also what gets exposed in /proc. That makes it much easier to see what threads might be doing the log write. Would it be okay to change os::current_thread_id to point to os::Linux::gettid()? That way, it can be mapped back to the output of a SIGQUIT dump. The downside of gettid() is that it is only available on Linux>2.4.11, but that dates from 2001. If we really still want to support it, we could check for that. Thoughts? Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Jul 22 18:52:38 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Jul 2015 21:52:38 +0300 Subject: os::current_thread_id on Linux In-Reply-To: References: Message-ID: <55AFE676.3080806@oracle.com> Jeremy, Please take in account that gettid() returns a value that unique for the *running threads* across a system. I.e. for long running java process gettid() can return a value that was previously assigned to one of dead threads. -Dmitry On 2015-07-22 21:22, Jeremy Manson wrote: > Hey folks, > > os::current_thread_id on Linux now maps to pthread_self. The problem with > pthread_self is that it only makes sense in the context of the running > process. When it is written out to the log (as it is in several places), > there really isn't a way (AFAICT) for the user to map it back to anything > useful. > > As it happens, that value is mostly used to write to the log. The places > where it doesn't do so don't seem to need to use pthread_self for any > particular reason. > > Meanwhile, the SIGQUIT stack dump uses java_thread->osthread()->thread_id() > as the nid. On Linux, that maps back to os::Linux::gettid(), whish is also > what gets exposed in /proc. That makes it much easier to see what threads > might be doing the log write. > > Would it be okay to change os::current_thread_id to point > to os::Linux::gettid()? That way, it can be mapped back to the output of a > SIGQUIT dump. > > The downside of gettid() is that it is only available on Linux>2.4.11, but > that dates from 2001. If we really still want to support it, we could > check for that. > > Thoughts? > > Jeremy > -- 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 jeremymanson at google.com Wed Jul 22 18:52:49 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 22 Jul 2015 11:52:49 -0700 Subject: os::current_thread_id on Linux In-Reply-To: References: Message-ID: Example of where this would help: Current output of SIGQUIT: "C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f0890247800 nid=0x2e3d waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f0890245000 nid=0x2e3c waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f0890243800 nid=0x2e3b waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f0890240800 nid=0x2e3a waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE Current directory listing from /tmp with -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation: $ ls -d /tmp/hs* hs_c139673756251904_pid11818.log hs_c139673759409920_pid11818.log hs_c139673757304576_pid11818.log hsperfdata_jeremymanson/ hs_c139673758357248_pid11818.log hsperfdata_root/ Output with this change would look like: $ ls -d /tmp/hs* hs_c11837_pid11818.log hs_c11834_pid11818.log hs_c11836_pid11818.log hsperfdata_jeremymanson/ hs_c11835_pid11818.log hsperfdata_root/ Where 1183x maps neatly back to 0x2e3x in the SIGQUIT dump. Jeremy On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson wrote: > Hey folks, > > os::current_thread_id on Linux now maps to pthread_self. The problem with > pthread_self is that it only makes sense in the context of the running > process. When it is written out to the log (as it is in several places), > there really isn't a way (AFAICT) for the user to map it back to anything > useful. > > As it happens, that value is mostly used to write to the log. The places > where it doesn't do so don't seem to need to use pthread_self for any > particular reason. > > Meanwhile, the SIGQUIT stack dump > uses java_thread->osthread()->thread_id() as the nid. On Linux, that maps > back to os::Linux::gettid(), whish is also what gets exposed in /proc. > That makes it much easier to see what threads might be doing the log write. > > Would it be okay to change os::current_thread_id to point > to os::Linux::gettid()? That way, it can be mapped back to the output of a > SIGQUIT dump. > > The downside of gettid() is that it is only available on Linux>2.4.11, but > that dates from 2001. If we really still want to support it, we could > check for that. > > Thoughts? > > Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Wed Jul 22 18:53:55 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 22 Jul 2015 11:53:55 -0700 Subject: os::current_thread_id on Linux In-Reply-To: <55AFE676.3080806@oracle.com> References: <55AFE676.3080806@oracle.com> Message-ID: That's also true of pthread_self. From the man page: Thread IDs are guaranteed to be unique only within a process. A thread ID may be reused after a terminated thread has been joined, or a detached thread has terminated. Jeremy On Wed, Jul 22, 2015 at 11:52 AM, Dmitry Samersoff < dmitry.samersoff at oracle.com> wrote: > Jeremy, > > Please take in account that gettid() returns a value that unique for > the *running threads* across a system. > > I.e. for long running java process gettid() can return a value that was > previously assigned to one of dead threads. > > -Dmitry > > > On 2015-07-22 21:22, Jeremy Manson wrote: > > Hey folks, > > > > os::current_thread_id on Linux now maps to pthread_self. The problem > with > > pthread_self is that it only makes sense in the context of the running > > process. When it is written out to the log (as it is in several places), > > there really isn't a way (AFAICT) for the user to map it back to anything > > useful. > > > > As it happens, that value is mostly used to write to the log. The places > > where it doesn't do so don't seem to need to use pthread_self for any > > particular reason. > > > > Meanwhile, the SIGQUIT stack dump uses > java_thread->osthread()->thread_id() > > as the nid. On Linux, that maps back to os::Linux::gettid(), whish is > also > > what gets exposed in /proc. That makes it much easier to see what > threads > > might be doing the log write. > > > > Would it be okay to change os::current_thread_id to point > > to os::Linux::gettid()? That way, it can be mapped back to the output > of a > > SIGQUIT dump. > > > > The downside of gettid() is that it is only available on Linux>2.4.11, > but > > that dates from 2001. If we really still want to support it, we could > > check for that. > > > > Thoughts? > > > > Jeremy > > > > > -- > 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 rainer.jung at kippdata.de Wed Jul 22 21:10:28 2015 From: rainer.jung at kippdata.de (Rainer Jung) Date: Wed, 22 Jul 2015 23:10:28 +0200 Subject: os::current_thread_id on Linux In-Reply-To: References: Message-ID: <55B006C4.8010202@kippdata.de> Am 22.07.2015 um 20:52 schrieb Jeremy Manson: > Example of where this would help: > > Current output of SIGQUIT: > > "C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f0890247800 > nid=0x2e3d waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f0890245000 > nid=0x2e3c waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f0890243800 > nid=0x2e3b waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f0890240800 > nid=0x2e3a waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > Current directory listing from /tmp with -XX:+UnlockDiagnosticVMOptions > -XX:+LogCompilation: > > $ ls -d /tmp/hs* > hs_c139673756251904_pid11818.log hs_c139673759409920_pid11818.log > hs_c139673757304576_pid11818.log hsperfdata_jeremymanson/ > hs_c139673758357248_pid11818.log hsperfdata_root/ > > > Output with this change would look like: > > $ ls -d /tmp/hs* > hs_c11837_pid11818.log hs_c11834_pid11818.log > hs_c11836_pid11818.log hsperfdata_jeremymanson/ > hs_c11835_pid11818.log hsperfdata_root/ > > Where 1183x maps neatly back to 0x2e3x in the SIGQUIT dump. I always though the other thread id is the tid printed above. At least I vaguely remember to have successfully used that id to match against thread IDs as ouput by the gstack command. In your concrete example above, tid and long thread ID do not exactly match though, e.g. 139673756251904 = 0x00007f0854a03700 Regards, Rainer From jeremymanson at google.com Wed Jul 22 21:14:31 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 22 Jul 2015 14:14:31 -0700 Subject: os::current_thread_id on Linux In-Reply-To: <55B006C4.8010202@kippdata.de> References: <55B006C4.8010202@kippdata.de> Message-ID: Right. Those values were taken off of actual output from a JVM. I think that, generally, they will be relatively close to each other in memory, but not actually the same. That jibes with one being pthread_self and the other being the address of the JVM's thread object - they would be created at roughly the same time. Since no one has noticed this for the O(years) that it has been in place, I argue that no one is relying on this behavior. :) Jeremy On Wed, Jul 22, 2015 at 2:10 PM, Rainer Jung wrote: > Am 22.07.2015 um 20:52 schrieb Jeremy Manson: > >> Example of where this would help: >> >> Current output of SIGQUIT: >> >> "C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f0890247800 >> nid=0x2e3d waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f0890245000 >> nid=0x2e3c waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f0890243800 >> nid=0x2e3b waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f0890240800 >> nid=0x2e3a waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> Current directory listing from /tmp with -XX:+UnlockDiagnosticVMOptions >> -XX:+LogCompilation: >> >> $ ls -d /tmp/hs* >> hs_c139673756251904_pid11818.log hs_c139673759409920_pid11818.log >> hs_c139673757304576_pid11818.log hsperfdata_jeremymanson/ >> hs_c139673758357248_pid11818.log hsperfdata_root/ >> >> >> Output with this change would look like: >> >> $ ls -d /tmp/hs* >> hs_c11837_pid11818.log hs_c11834_pid11818.log >> hs_c11836_pid11818.log hsperfdata_jeremymanson/ >> hs_c11835_pid11818.log hsperfdata_root/ >> >> Where 1183x maps neatly back to 0x2e3x in the SIGQUIT dump. >> > > I always though the other thread id is the tid printed above. At least I > vaguely remember to have successfully used that id to match against thread > IDs as ouput by the gstack command. In your concrete example above, tid and > long thread ID do not exactly match though, e.g. > > 139673756251904 = 0x00007f0854a03700 > > Regards, > > Rainer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Wed Jul 22 21:51:37 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 22 Jul 2015 14:51:37 -0700 Subject: os::current_thread_id on Linux In-Reply-To: References: <55B006C4.8010202@kippdata.de> Message-ID: It would be nice if even internal hotspot APIs had clear specs. All we have now is: // thread id on Linux/64bit is 64bit, on Windows and Solaris, it's 32bit static intx current_thread_id(); pthread_self() is documented as being an opaque value that cannot necessarily be stored in a native integral type, so casting to intx is a bit bogus. (but yeah, this is hotspot, we can get away with non-portable code) For debugging purposes, it would be nice to have convenient access to all of the various "current thread" values: pthread_self(), gettid(), hotspot C++ thread object, java thread object, java thread id. But that doesn't fit with a function returning intx, and whose uniqueness is also used for locking. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Wed Jul 22 22:01:20 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 22 Jul 2015 15:01:20 -0700 Subject: os::current_thread_id on Linux In-Reply-To: References: Message-ID: Based on the feedback, this seems to be a good idea, approximately. Coleen would have sponsored, but she's going on vacation. Anyone else feel like sponsoring? Jeremy On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson wrote: > Hey folks, > > os::current_thread_id on Linux now maps to pthread_self. The problem with > pthread_self is that it only makes sense in the context of the running > process. When it is written out to the log (as it is in several places), > there really isn't a way (AFAICT) for the user to map it back to anything > useful. > > As it happens, that value is mostly used to write to the log. The places > where it doesn't do so don't seem to need to use pthread_self for any > particular reason. > > Meanwhile, the SIGQUIT stack dump > uses java_thread->osthread()->thread_id() as the nid. On Linux, that maps > back to os::Linux::gettid(), whish is also what gets exposed in /proc. > That makes it much easier to see what threads might be doing the log write. > > Would it be okay to change os::current_thread_id to point > to os::Linux::gettid()? That way, it can be mapped back to the output of a > SIGQUIT dump. > > The downside of gettid() is that it is only available on Linux>2.4.11, but > that dates from 2001. If we really still want to support it, we could > check for that. > > Thoughts? > > Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jul 23 00:21:30 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jul 2015 17:21:30 -0700 Subject: RFR (XXS): JDK-8131783 : Put LowMemoryTest.java in quarantine In-Reply-To: <55AFC3F1.9040900@oracle.com> References: <55AFC3F1.9040900@oracle.com> Message-ID: <55B0338A.2030807@oracle.com> Hi Olivier, The fix is good. Thanks, Serguei On 7/22/15 9:25 AM, olivier.lagneau at oracle.com wrote: > Hi, > > Could you please review this very light fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8131783 > webrev: http://cr.openjdk.java.net/~olagneau/8131783/webrev.00/ > > We first quarantine the test. > > We will then add tracing information to help diagnosing the problem > (https://bugs.openjdk.java.net/browse/JDK-8131784), > monitoring the quarantined runs when it fails again. > > Thanks, > Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Jul 23 00:57:58 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Jul 2015 18:57:58 -0600 Subject: RFR 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine In-Reply-To: <55AFD144.9010102@oracle.com> References: <55AFD144.9010102@oracle.com> Message-ID: <55B03C16.50007@oracle.com> On 7/22/15 11:22 AM, Coleen Phillimore wrote: > Summary: Need to get source_file_name from the_class's constant pool > not previous version constant pool > > open webrev at http://cr.openjdk.java.net/~coleenp/8087315.01/ src/share/vm/classfile/javaClasses.cpp So in the new code, you avoid the use of holder->source_file_name() (where holder has been reset to a previous version ik) to fetch the Symbol because you can't trust that the source file name CP index saved in the previous version ik will work with that ik's constant pool. Interesting problem with previous versions... So you added a helper that grabs the source file name CP index out of the previous version ik and sanity checks it before using it with the merged CP. And you had to do this in two places so yet another reason for the helper... Sorry for verbiage... I had to remind myself how this stuff works... test/runtime/RedefineTests/RedefineRunningMethodsWithBacktrace.java Nice test. So what does the output look like when the test is run without your fix? Something like what is in the bug report? Thumbs up. Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8087315 > > Tested with added test (yay!), RBT (remote build and test), > vm.redefine.testlist, jdk/test/java/lang/instrument and failing > testcase 1000 times (reproduced <400). > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Jul 23 01:31:33 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jul 2015 21:31:33 -0400 Subject: RFR 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine In-Reply-To: <55B03C16.50007@oracle.com> References: <55AFD144.9010102@oracle.com> <55B03C16.50007@oracle.com> Message-ID: <55B043F5.1030300@oracle.com> Dan, Thank you again for the quick code review. On 7/22/15 8:57 PM, Daniel D. Daugherty wrote: > On 7/22/15 11:22 AM, Coleen Phillimore wrote: >> Summary: Need to get source_file_name from the_class's constant pool >> not previous version constant pool >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8087315.01/ > > src/share/vm/classfile/javaClasses.cpp > So in the new code, you avoid the use of holder->source_file_name() > (where holder has been reset to a previous version ik) to fetch the > Symbol because you can't trust that the source file name CP index > saved in the previous version ik will work with that ik's constant > pool. Interesting problem with previous versions... > > So you added a helper that grabs the source file name CP index out > of the previous version ik and sanity checks it before using it > with the merged CP. > > And you had to do this in two places so yet another reason for > the helper... > > Sorry for verbiage... I had to remind myself how this stuff works... Yes, you are exactly right. I'm so glad you remember this. I don't know how, but I'm glad you do. :) > > test/runtime/RedefineTests/RedefineRunningMethodsWithBacktrace.java > Nice test. > > So what does the output look like when the test is > run without your fix? Something like what is in the > bug report? Yes, it crashes like the bug report. I was really happy to get a small test to reproduce this. Thanks! Coleen > > Thumbs up. > > Dan > > > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8087315 >> >> Tested with added test (yay!), RBT (remote build and test), >> vm.redefine.testlist, jdk/test/java/lang/instrument and failing >> testcase 1000 times (reproduced <400). >> >> Thanks, >> Coleen > From david.holmes at oracle.com Thu Jul 23 02:08:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2015 12:08:08 +1000 Subject: os::current_thread_id on Linux In-Reply-To: References: Message-ID: <55B04C88.5080302@oracle.com> On 23/07/2015 8:01 AM, Jeremy Manson wrote: > Based on the feedback, this seems to be a good idea, approximately. > Coleen would have sponsored, but she's going on vacation. Anyone else > feel like sponsoring? Hold up a minute! :) There are different notions of "native thread id" that exist. First we have the "user level thread id" - this is what is reported by pthread_self in POSIX and thr_self in UI. Then we also have the OS specific "thread" id, also referred to as a LWP or "kernel scheduling entity" or "kernel thread" - the id for this is what gettid() maps back to on Linux. This distinction may not exist on all platforms. Unfortunately os::current_thread_id does not define which of these it represents: // thread id on Linux/64bit is 64bit, on Windows and Solaris, it's 32bit static intx current_thread_id(); and so on some platforms it returns the "user thread id" (eg pthread_self()), and on some it returns the same as gettid (ie OSX - but I don't know if the mach thread id is truly a "LWP" id ?). Also note that on some platforms the osThread stores the id of the "user-level thread" and on some the "kernel thread". Hence another source of confusion. :( So if you want to enforce that os::current_thread_id() represents the "kernel thread" then that should be applied consistently across all platforms**, and for platforms for which there is a change to make you have to ensure the usage of os::current_thread_id() is not semantically altered by the change. ** Of course a platform may only have a single notion of "thread" I'm happy to sponsor such a proposal. And don't worry about maintaining compatibility with archaic Linux versions for JDK9 (less cleanup to do later). Thanks, David > Jeremy > > On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson > wrote: > > Hey folks, > > os::current_thread_id on Linux now maps to pthread_self. The > problem with pthread_self is that it only makes sense in the context > of the running process. When it is written out to the log (as it is > in several places), there really isn't a way (AFAICT) for the user > to map it back to anything useful. > > As it happens, that value is mostly used to write to the log. The > places where it doesn't do so don't seem to need to use pthread_self > for any particular reason. > > Meanwhile, the SIGQUIT stack dump > uses java_thread->osthread()->thread_id() as the nid. On Linux, > that maps back to os::Linux::gettid(), whish is also what gets > exposed in /proc. That makes it much easier to see what threads > might be doing the log write. > > Would it be okay to change os::current_thread_id to point > to os::Linux::gettid()? That way, it can be mapped back to the > output of a SIGQUIT dump. > > The downside of gettid() is that it is only available on > Linux>2.4.11, but that dates from 2001. If we really still want to > support it, we could check for that. > > Thoughts? > > Jeremy > > From jeremymanson at google.com Thu Jul 23 05:15:46 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 22 Jul 2015 22:15:46 -0700 Subject: os::current_thread_id on Linux In-Reply-To: <55B04C88.5080302@oracle.com> References: <55B04C88.5080302@oracle.com> Message-ID: Hey David, Thanks for the offer of sponsorship. My goal here is really to make the log output on Linux usable. I want to be able to map the log output back to an actual thread. I don't think it really matters to users if the API consistently means "kernel thread ID" or "threading API thread ID", as long as they can figure out what the output means. Since what I am doing (in effect) to accomplish my goal is to ensure that the API returns the same value as osthread()->thread_id() does for the current thread, I could just... do precisely that. os::current_thread_id could just return osthread()->thread_id() for the current thread. I don't have easy access to anything for testing other than Linux, though, so whether it worked (or even compiled) on the other platforms would be a bit of a guess (per the last time we did this dance). Seem reasonable? Jeremy On Wed, Jul 22, 2015 at 7:08 PM, David Holmes wrote: > On 23/07/2015 8:01 AM, Jeremy Manson wrote: > >> Based on the feedback, this seems to be a good idea, approximately. >> Coleen would have sponsored, but she's going on vacation. Anyone else >> feel like sponsoring? >> > > Hold up a minute! :) There are different notions of "native thread id" > that exist. First we have the "user level thread id" - this is what is > reported by pthread_self in POSIX and thr_self in UI. Then we also have the > OS specific "thread" id, also referred to as a LWP or "kernel scheduling > entity" or "kernel thread" - the id for this is what gettid() maps back to > on Linux. This distinction may not exist on all platforms. > > Unfortunately os::current_thread_id does not define which of these it > represents: > > // thread id on Linux/64bit is 64bit, on Windows and Solaris, it's 32bit > static intx current_thread_id(); > > and so on some platforms it returns the "user thread id" (eg > pthread_self()), and on some it returns the same as gettid (ie OSX - but I > don't know if the mach thread id is truly a "LWP" id ?). > > Also note that on some platforms the osThread stores the id of the > "user-level thread" and on some the "kernel thread". Hence another source > of confusion. :( > > So if you want to enforce that os::current_thread_id() represents the > "kernel thread" then that should be applied consistently across all > platforms**, and for platforms for which there is a change to make you have > to ensure the usage of os::current_thread_id() is not semantically altered > by the change. > > ** Of course a platform may only have a single notion of "thread" > > I'm happy to sponsor such a proposal. And don't worry about maintaining > compatibility with archaic Linux versions for JDK9 (less cleanup to do > later). > > Thanks, > David > > Jeremy >> >> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson > > wrote: >> >> Hey folks, >> >> os::current_thread_id on Linux now maps to pthread_self. The >> problem with pthread_self is that it only makes sense in the context >> of the running process. When it is written out to the log (as it is >> in several places), there really isn't a way (AFAICT) for the user >> to map it back to anything useful. >> >> As it happens, that value is mostly used to write to the log. The >> places where it doesn't do so don't seem to need to use pthread_self >> for any particular reason. >> >> Meanwhile, the SIGQUIT stack dump >> uses java_thread->osthread()->thread_id() as the nid. On Linux, >> that maps back to os::Linux::gettid(), whish is also what gets >> exposed in /proc. That makes it much easier to see what threads >> might be doing the log write. >> >> Would it be okay to change os::current_thread_id to point >> to os::Linux::gettid()? That way, it can be mapped back to the >> output of a SIGQUIT dump. >> >> The downside of gettid() is that it is only available on >> Linux>2.4.11, but that dates from 2001. If we really still want to >> support it, we could check for that. >> >> Thoughts? >> >> Jeremy >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jul 23 05:57:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2015 15:57:37 +1000 Subject: os::current_thread_id on Linux In-Reply-To: References: <55B04C88.5080302@oracle.com> Message-ID: <55B08251.6030909@oracle.com> On 23/07/2015 3:15 PM, Jeremy Manson wrote: > Hey David, > > Thanks for the offer of sponsorship. My goal here is really to make the > log output on Linux usable. I want to be able to map the log output > back to an actual thread. I don't think it really matters to users if > the API consistently means "kernel thread ID" or "threading API thread > ID", as long as they can figure out what the output means. I think consistency is important else developers don't know what they should be using where - which is the current situation. > Since what I am doing (in effect) to accomplish my goal is to ensure > that the API returns the same value as osthread()->thread_id() does for > the current thread, I could just... do precisely that. > os::current_thread_id could just return osthread()->thread_id() for the > current thread. I don't have easy access to anything for testing other > than Linux, though, so whether it worked (or even compiled) on the other > platforms would be a bit of a guess (per the last time we did this dance). Defining os::current_thread_id() to be Thread::current()->osThread()->thread_id() assumes you can make those calls in the context in which os::current_thread_id() is used - if we crash during thread startup then some of those may be null and the id not even set. The current implementation is independent of the state of thread within the VM. So its okay to return the same thing as Thread::current()->osThread()->thread_id() but it needs to be done directly. Again any platform for which this would cause a change in behaviour needs to be examined. It may be other platforms have the same problem you are trying to fix for linux. If I get time later I'll try to check what each platform does. Thanks, David > Seem reasonable? > > Jeremy > > On Wed, Jul 22, 2015 at 7:08 PM, David Holmes > wrote: > > On 23/07/2015 8:01 AM, Jeremy Manson wrote: > > Based on the feedback, this seems to be a good idea, approximately. > Coleen would have sponsored, but she's going on vacation. > Anyone else > feel like sponsoring? > > > Hold up a minute! :) There are different notions of "native thread > id" that exist. First we have the "user level thread id" - this is > what is reported by pthread_self in POSIX and thr_self in UI. Then > we also have the OS specific "thread" id, also referred to as a LWP > or "kernel scheduling entity" or "kernel thread" - the id for this > is what gettid() maps back to on Linux. This distinction may not > exist on all platforms. > > Unfortunately os::current_thread_id does not define which of these > it represents: > > // thread id on Linux/64bit is 64bit, on Windows and Solaris, it's > 32bit > static intx current_thread_id(); > > and so on some platforms it returns the "user thread id" (eg > pthread_self()), and on some it returns the same as gettid (ie OSX - > but I don't know if the mach thread id is truly a "LWP" id ?). > > Also note that on some platforms the osThread stores the id of the > "user-level thread" and on some the "kernel thread". Hence another > source of confusion. :( > > So if you want to enforce that os::current_thread_id() represents > the "kernel thread" then that should be applied consistently across > all platforms**, and for platforms for which there is a change to > make you have to ensure the usage of os::current_thread_id() is not > semantically altered by the change. > > ** Of course a platform may only have a single notion of "thread" > > I'm happy to sponsor such a proposal. And don't worry about > maintaining compatibility with archaic Linux versions for JDK9 (less > cleanup to do later). > > Thanks, > David > > Jeremy > > On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson > > >> wrote: > > Hey folks, > > os::current_thread_id on Linux now maps to pthread_self. The > problem with pthread_self is that it only makes sense in > the context > of the running process. When it is written out to the log > (as it is > in several places), there really isn't a way (AFAICT) for > the user > to map it back to anything useful. > > As it happens, that value is mostly used to write to the > log. The > places where it doesn't do so don't seem to need to use > pthread_self > for any particular reason. > > Meanwhile, the SIGQUIT stack dump > uses java_thread->osthread()->thread_id() as the nid. On > Linux, > that maps back to os::Linux::gettid(), whish is also what gets > exposed in /proc. That makes it much easier to see what > threads > might be doing the log write. > > Would it be okay to change os::current_thread_id to point > to os::Linux::gettid()? That way, it can be mapped back to the > output of a SIGQUIT dump. > > The downside of gettid() is that it is only available on > Linux>2.4.11, but that dates from 2001. If we really still > want to > support it, we could check for that. > > Thoughts? > > Jeremy > > > From jeremymanson at google.com Thu Jul 23 06:11:43 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 22 Jul 2015 23:11:43 -0700 Subject: os::current_thread_id on Linux In-Reply-To: <55B08251.6030909@oracle.com> References: <55B04C88.5080302@oracle.com> <55B08251.6030909@oracle.com> Message-ID: Okay. TBH, thinking about it more, it's a little weird for something named os::current_thread_id() to be different from Thread::current()->osThread->thread_id(), or for either of them to be different from "what the OS thinks the thread id is", so it seems like the Right Thing to Do (in the absence of any platform-specific issues). Jeremy On Wed, Jul 22, 2015 at 10:57 PM, David Holmes wrote: > On 23/07/2015 3:15 PM, Jeremy Manson wrote: > >> Hey David, >> >> Thanks for the offer of sponsorship. My goal here is really to make the >> log output on Linux usable. I want to be able to map the log output >> back to an actual thread. I don't think it really matters to users if >> the API consistently means "kernel thread ID" or "threading API thread >> ID", as long as they can figure out what the output means. >> > > I think consistency is important else developers don't know what they > should be using where - which is the current situation. > > Since what I am doing (in effect) to accomplish my goal is to ensure >> that the API returns the same value as osthread()->thread_id() does for >> the current thread, I could just... do precisely that. >> os::current_thread_id could just return osthread()->thread_id() for the >> current thread. I don't have easy access to anything for testing other >> than Linux, though, so whether it worked (or even compiled) on the other >> platforms would be a bit of a guess (per the last time we did this dance). >> > > Defining os::current_thread_id() to be > Thread::current()->osThread()->thread_id() assumes you can make those calls > in the context in which os::current_thread_id() is used - if we crash > during thread startup then some of those may be null and the id not even > set. The current implementation is independent of the state of thread > within the VM. > > So its okay to return the same thing as > Thread::current()->osThread()->thread_id() but it needs to be done directly. > > Again any platform for which this would cause a change in behaviour needs > to be examined. It may be other platforms have the same problem you are > trying to fix for linux. > > If I get time later I'll try to check what each platform does. > > Thanks, > David > > Seem reasonable? >> >> Jeremy >> >> On Wed, Jul 22, 2015 at 7:08 PM, David Holmes > > wrote: >> >> On 23/07/2015 8:01 AM, Jeremy Manson wrote: >> >> Based on the feedback, this seems to be a good idea, >> approximately. >> Coleen would have sponsored, but she's going on vacation. >> Anyone else >> feel like sponsoring? >> >> >> Hold up a minute! :) There are different notions of "native thread >> id" that exist. First we have the "user level thread id" - this is >> what is reported by pthread_self in POSIX and thr_self in UI. Then >> we also have the OS specific "thread" id, also referred to as a LWP >> or "kernel scheduling entity" or "kernel thread" - the id for this >> is what gettid() maps back to on Linux. This distinction may not >> exist on all platforms. >> >> Unfortunately os::current_thread_id does not define which of these >> it represents: >> >> // thread id on Linux/64bit is 64bit, on Windows and Solaris, it's >> 32bit >> static intx current_thread_id(); >> >> and so on some platforms it returns the "user thread id" (eg >> pthread_self()), and on some it returns the same as gettid (ie OSX - >> but I don't know if the mach thread id is truly a "LWP" id ?). >> >> Also note that on some platforms the osThread stores the id of the >> "user-level thread" and on some the "kernel thread". Hence another >> source of confusion. :( >> >> So if you want to enforce that os::current_thread_id() represents >> the "kernel thread" then that should be applied consistently across >> all platforms**, and for platforms for which there is a change to >> make you have to ensure the usage of os::current_thread_id() is not >> semantically altered by the change. >> >> ** Of course a platform may only have a single notion of "thread" >> >> I'm happy to sponsor such a proposal. And don't worry about >> maintaining compatibility with archaic Linux versions for JDK9 (less >> cleanup to do later). >> >> Thanks, >> David >> >> Jeremy >> >> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson >> >> > >> >> wrote: >> >> Hey folks, >> >> os::current_thread_id on Linux now maps to pthread_self. The >> problem with pthread_self is that it only makes sense in >> the context >> of the running process. When it is written out to the log >> (as it is >> in several places), there really isn't a way (AFAICT) for >> the user >> to map it back to anything useful. >> >> As it happens, that value is mostly used to write to the >> log. The >> places where it doesn't do so don't seem to need to use >> pthread_self >> for any particular reason. >> >> Meanwhile, the SIGQUIT stack dump >> uses java_thread->osthread()->thread_id() as the nid. On >> Linux, >> that maps back to os::Linux::gettid(), whish is also what >> gets >> exposed in /proc. That makes it much easier to see what >> threads >> might be doing the log write. >> >> Would it be okay to change os::current_thread_id to point >> to os::Linux::gettid()? That way, it can be mapped back to >> the >> output of a SIGQUIT dump. >> >> The downside of gettid() is that it is only available on >> Linux>2.4.11, but that dates from 2001. If we really still >> want to >> support it, we could check for that. >> >> Thoughts? >> >> Jeremy >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jul 23 06:35:32 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jul 2015 23:35:32 -0700 Subject: RFR 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine In-Reply-To: <55AFD144.9010102@oracle.com> References: <55AFD144.9010102@oracle.com> Message-ID: <55B08B34.7080707@oracle.com> Coleen, The fix looks good in general. There is one more place where the same may need to be fixed. It is in the function java_lang_StackTraceElement::create (): 1911 // Fill in source file name and line number. 1912 // Use specific ik version as a holder since the mirror might 1913 // refer to version that is now obsolete and no longer accessible 1914 // via the previous versions list. 1915 holder = holder->get_klass_version(version); 1916 assert(holder != NULL, "sanity check"); 1917 Symbol* source = holder->source_file_name(); I'm still reviewing the test. Thanks, Serguei On 7/22/15 10:22 AM, Coleen Phillimore wrote: > Summary: Need to get source_file_name from the_class's constant pool > not previous version constant pool > > open webrev at http://cr.openjdk.java.net/~coleenp/8087315.01/ > bug link https://bugs.openjdk.java.net/browse/JDK-8087315 > > Tested with added test (yay!), RBT (remote build and test), > vm.redefine.testlist, jdk/test/java/lang/instrument and failing > testcase 1000 times (reproduced <400). > > Thanks, > Coleen -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jul 23 07:16:07 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2015 17:16:07 +1000 Subject: os::current_thread_id on Linux In-Reply-To: References: <55B04C88.5080302@oracle.com> <55B08251.6030909@oracle.com> Message-ID: <55B094B7.6060309@oracle.com> On 23/07/2015 4:11 PM, Jeremy Manson wrote: > Okay. TBH, thinking about it more, it's a little weird for something > named os::current_thread_id() to be different from > Thread::current()->osThread->thread_id(), or for either of them to be > different from "what the OS thinks the thread id is", so it seems like > the Right Thing to Do (in the absence of any platform-specific issues). When there are two different levels of thread ID it isn't that simple - especially as, like you say, one can be used to look in /proc while the other can't. So perhaps better naming is in order. Cheers, David > Jeremy > > On Wed, Jul 22, 2015 at 10:57 PM, David Holmes > wrote: > > On 23/07/2015 3:15 PM, Jeremy Manson wrote: > > Hey David, > > Thanks for the offer of sponsorship. My goal here is really to > make the > log output on Linux usable. I want to be able to map the log output > back to an actual thread. I don't think it really matters to > users if > the API consistently means "kernel thread ID" or "threading API > thread > ID", as long as they can figure out what the output means. > > > I think consistency is important else developers don't know what > they should be using where - which is the current situation. > > Since what I am doing (in effect) to accomplish my goal is to ensure > that the API returns the same value as osthread()->thread_id() > does for > the current thread, I could just... do precisely that. > os::current_thread_id could just return osthread()->thread_id() > for the > current thread. I don't have easy access to anything for testing > other > than Linux, though, so whether it worked (or even compiled) on > the other > platforms would be a bit of a guess (per the last time we did > this dance). > > > Defining os::current_thread_id() to be > Thread::current()->osThread()->thread_id() assumes you can make > those calls in the context in which os::current_thread_id() is used > - if we crash during thread startup then some of those may be null > and the id not even set. The current implementation is independent > of the state of thread within the VM. > > So its okay to return the same thing as > Thread::current()->osThread()->thread_id() but it needs to be done > directly. > > Again any platform for which this would cause a change in behaviour > needs to be examined. It may be other platforms have the same > problem you are trying to fix for linux. > > If I get time later I'll try to check what each platform does. > > Thanks, > David > > Seem reasonable? > > Jeremy > > On Wed, Jul 22, 2015 at 7:08 PM, David Holmes > > >> wrote: > > On 23/07/2015 8:01 AM, Jeremy Manson wrote: > > Based on the feedback, this seems to be a good idea, > approximately. > Coleen would have sponsored, but she's going on vacation. > Anyone else > feel like sponsoring? > > > Hold up a minute! :) There are different notions of "native > thread > id" that exist. First we have the "user level thread id" - > this is > what is reported by pthread_self in POSIX and thr_self in > UI. Then > we also have the OS specific "thread" id, also referred to > as a LWP > or "kernel scheduling entity" or "kernel thread" - the id > for this > is what gettid() maps back to on Linux. This distinction > may not > exist on all platforms. > > Unfortunately os::current_thread_id does not define which > of these > it represents: > > // thread id on Linux/64bit is 64bit, on Windows and > Solaris, it's > 32bit > static intx current_thread_id(); > > and so on some platforms it returns the "user thread id" (eg > pthread_self()), and on some it returns the same as gettid > (ie OSX - > but I don't know if the mach thread id is truly a "LWP" id ?). > > Also note that on some platforms the osThread stores the id > of the > "user-level thread" and on some the "kernel thread". Hence > another > source of confusion. :( > > So if you want to enforce that os::current_thread_id() > represents > the "kernel thread" then that should be applied > consistently across > all platforms**, and for platforms for which there is a > change to > make you have to ensure the usage of > os::current_thread_id() is not > semantically altered by the change. > > ** Of course a platform may only have a single notion of > "thread" > > I'm happy to sponsor such a proposal. And don't worry about > maintaining compatibility with archaic Linux versions for > JDK9 (less > cleanup to do later). > > Thanks, > David > > Jeremy > > On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson > > > > > >>> wrote: > > Hey folks, > > os::current_thread_id on Linux now maps to > pthread_self. The > problem with pthread_self is that it only makes > sense in > the context > of the running process. When it is written out to > the log > (as it is > in several places), there really isn't a way > (AFAICT) for > the user > to map it back to anything useful. > > As it happens, that value is mostly used to write > to the > log. The > places where it doesn't do so don't seem to need > to use > pthread_self > for any particular reason. > > Meanwhile, the SIGQUIT stack dump > uses java_thread->osthread()->thread_id() as the > nid. On > Linux, > that maps back to os::Linux::gettid(), whish is > also what gets > exposed in /proc. That makes it much easier to > see what > threads > might be doing the log write. > > Would it be okay to change os::current_thread_id > to point > to os::Linux::gettid()? That way, it can be > mapped back to the > output of a SIGQUIT dump. > > The downside of gettid() is that it is only > available on > Linux>2.4.11, but that dates from 2001. If we > really still > want to > support it, we could check for that. > > Thoughts? > > Jeremy > > > > From jaroslav.bachorik at oracle.com Thu Jul 23 07:27:34 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 23 Jul 2015 09:27:34 +0200 Subject: RFR(XS): 8132094: Mark intermittently failuring core-svc tests In-Reply-To: <55AF9FBE.2060209@oracle.com> References: <55AF9FBE.2060209@oracle.com> Message-ID: <55B09766.7090802@oracle.com> Looks good! -JB- On 22.7.2015 15:50, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8132094 > webrev: http://cr.openjdk.java.net/~ykantser/8132094/webrev.00 > > Thanks, > Katja From jaroslav.bachorik at oracle.com Thu Jul 23 07:38:07 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 23 Jul 2015 09:38:07 +0200 Subject: RFR (XXS): JDK-8131783 : Put LowMemoryTest.java in quarantine In-Reply-To: <55AFC3F1.9040900@oracle.com> References: <55AFC3F1.9040900@oracle.com> Message-ID: <55B099DF.80909@oracle.com> Good to go! -JB- On 22.7.2015 18:25, olivier.lagneau at oracle.com wrote: > Hi, > > Could you please review this very light fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8131783 > webrev: http://cr.openjdk.java.net/~olagneau/8131783/webrev.00/ > > We first quarantine the test. > > We will then add tracing information to help diagnosing the problem > (https://bugs.openjdk.java.net/browse/JDK-8131784), > monitoring the quarantined runs when it fails again. > > Thanks, > Olivier. From serguei.spitsyn at oracle.com Thu Jul 23 10:09:00 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jul 2015 03:09:00 -0700 Subject: RFR(XS): 8132094: Mark intermittently failuring core-svc tests In-Reply-To: <55AF9FBE.2060209@oracle.com> References: <55AF9FBE.2060209@oracle.com> Message-ID: <55B0BD3C.5060004@oracle.com> Looks good. Thanks, Serguei On 7/22/15 6:50 AM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8132094 > webrev: http://cr.openjdk.java.net/~ykantser/8132094/webrev.00 > > Thanks, > Katja From yekaterina.kantserova at oracle.com Thu Jul 23 11:36:41 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 23 Jul 2015 13:36:41 +0200 Subject: RFR(XS): 8132094: Mark intermittently failuring core-svc tests In-Reply-To: <55B0BD3C.5060004@oracle.com> References: <55AF9FBE.2060209@oracle.com> <55B0BD3C.5060004@oracle.com> Message-ID: <55B0D1C9.5060003@oracle.com> Jaroslav, Serguei, thanks for the review! // Katja On 07/23/2015 12:09 PM, serguei.spitsyn at oracle.com wrote: > Looks good. > > Thanks, > Serguei > > On 7/22/15 6:50 AM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8132094 >> webrev: http://cr.openjdk.java.net/~ykantser/8132094/webrev.00 >> >> Thanks, >> Katja > From coleen.phillimore at oracle.com Thu Jul 23 11:49:26 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 23 Jul 2015 07:49:26 -0400 Subject: RFR 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine In-Reply-To: <55B08B34.7080707@oracle.com> References: <55AFD144.9010102@oracle.com> <55B08B34.7080707@oracle.com> Message-ID: <55B0D4C6.8060303@oracle.com> Hi Serguei, On 7/23/15 2:35 AM, serguei.spitsyn at oracle.com wrote: > Coleen, > > The fix looks good in general. > There is one more place where the same may need to be fixed. > It is in the function java_lang_StackTraceElement::create (): > 1911 // Fill in source file name and line number. > 1912 // Use specific ik version as a holder since the mirror might > 1913 // refer to version that is now obsolete and no longer accessible > 1914 // via the previous versions list. > 1915 holder = holder->get_klass_version(version); > 1916 assert(holder != NULL, "sanity check"); > 1917 Symbol* source = holder->source_file_name(); > I did change both places, I think you're looking at the old version. java_lang_StackTraceElement::create() was where the crash was. thanks for getting to this so quickly. Coleen > I'm still reviewing the test. > > Thanks, > Serguei > > > On 7/22/15 10:22 AM, Coleen Phillimore wrote: >> Summary: Need to get source_file_name from the_class's constant pool >> not previous version constant pool >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8087315.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8087315 >> >> Tested with added test (yay!), RBT (remote build and test), >> vm.redefine.testlist, jdk/test/java/lang/instrument and failing >> testcase 1000 times (reproduced <400). >> >> Thanks, >> Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jul 23 11:57:53 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jul 2015 04:57:53 -0700 Subject: RFR 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine In-Reply-To: <55B0D4C6.8060303@oracle.com> References: <55AFD144.9010102@oracle.com> <55B08B34.7080707@oracle.com> <55B0D4C6.8060303@oracle.com> Message-ID: <55B0D6C1.8000503@oracle.com> Hi Coleen, On 7/23/15 4:49 AM, Coleen Phillimore wrote: > > Hi Serguei, > > On 7/23/15 2:35 AM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> The fix looks good in general. >> There is one more place where the same may need to be fixed. >> It is in the function java_lang_StackTraceElement::create (): >> 1911 // Fill in source file name and line number. >> 1912 // Use specific ik version as a holder since the mirror might >> 1913 // refer to version that is now obsolete and no longer accessible >> 1914 // via the previous versions list. >> 1915 holder = holder->get_klass_version(version); >> 1916 assert(holder != NULL, "sanity check"); >> 1917 Symbol* source = holder->source_file_name(); >> > > I did change both places, I think you're looking at the old version. > java_lang_StackTraceElement::create() was where the crash was. > thanks for getting to this so quickly. You are right, sorry. I've overlooked the second place. It is because both fragments look similar. It is nice that you have fixed them both! Still reviewing the test. Thanks, Serguei > Coleen > > >> I'm still reviewing the test. >> >> Thanks, >> Serguei >> >> >> On 7/22/15 10:22 AM, Coleen Phillimore wrote: >>> Summary: Need to get source_file_name from the_class's constant pool >>> not previous version constant pool >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8087315.01/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8087315 >>> >>> Tested with added test (yay!), RBT (remote build and test), >>> vm.redefine.testlist, jdk/test/java/lang/instrument and failing >>> testcase 1000 times (reproduced <400). >>> >>> Thanks, >>> Coleen >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jul 23 12:30:36 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jul 2015 05:30:36 -0700 Subject: RFR 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine In-Reply-To: <55B0D6C1.8000503@oracle.com> References: <55AFD144.9010102@oracle.com> <55B08B34.7080707@oracle.com> <55B0D4C6.8060303@oracle.com> <55B0D6C1.8000503@oracle.com> Message-ID: <55B0DE6C.9030601@oracle.com> The fix is good. Nice test! A couple of places with indent 2: 78 static void localSleep() { 79 try{ 80 Thread.currentThread().sleep(10);//sleep for 10 ms 81 } catch(InterruptedException ie) { 82 } 83 } 119 for (int i = 0; i < stackTrace.length; i++) { 120 StackTraceElement frame = stackTrace[i]; 121 if (frame.getClassName() == null) { 122 System.out.println("\nTest failed: trace[" + i + "].getClassName() returned null"); 123 } 124 if (frame.getMethodName() == null) { 125 System.out.println("\nTest failed: trace[" + i + "].getMethodName() returned null"); 126 } 127 } Thank you a lot for fixing this issue! Thanks, Serguei On 7/23/15 4:57 AM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > > On 7/23/15 4:49 AM, Coleen Phillimore wrote: >> >> Hi Serguei, >> >> On 7/23/15 2:35 AM, serguei.spitsyn at oracle.com wrote: >>> Coleen, >>> >>> The fix looks good in general. >>> There is one more place where the same may need to be fixed. >>> It is in the function java_lang_StackTraceElement::create (): >>> 1911 // Fill in source file name and line number. >>> 1912 // Use specific ik version as a holder since the mirror might >>> 1913 // refer to version that is now obsolete and no longer accessible >>> 1914 // via the previous versions list. >>> 1915 holder = holder->get_klass_version(version); >>> 1916 assert(holder != NULL, "sanity check"); >>> 1917 Symbol* source = holder->source_file_name(); >>> >> >> I did change both places, I think you're looking at the old >> version. java_lang_StackTraceElement::create() was where the crash was. >> thanks for getting to this so quickly. > > You are right, sorry. > I've overlooked the second place. > It is because both fragments look similar. > It is nice that you have fixed them both! > Still reviewing the test. > > Thanks, > Serguei > >> Coleen >> >> >>> I'm still reviewing the test. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/22/15 10:22 AM, Coleen Phillimore wrote: >>>> Summary: Need to get source_file_name from the_class's constant >>>> pool not previous version constant pool >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8087315.01/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8087315 >>>> >>>> Tested with added test (yay!), RBT (remote build and test), >>>> vm.redefine.testlist, jdk/test/java/lang/instrument and failing >>>> testcase 1000 times (reproduced <400). >>>> >>>> Thanks, >>>> Coleen >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Jul 23 13:35:16 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 23 Jul 2015 07:35:16 -0600 Subject: RFR(XS): 8132094: Mark intermittently failuring core-svc tests In-Reply-To: <55AF9FBE.2060209@oracle.com> References: <55AF9FBE.2060209@oracle.com> Message-ID: <55B0ED94.3090002@oracle.com> What testing of these changes was done? Dan On 7/22/15 7:50 AM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8132094 > webrev: http://cr.openjdk.java.net/~ykantser/8132094/webrev.00 > > Thanks, > Katja From yekaterina.kantserova at oracle.com Thu Jul 23 14:02:02 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 23 Jul 2015 16:02:02 +0200 Subject: RFR(XS): 8132094: Mark intermittently failuring core-svc tests In-Reply-To: <55B0ED94.3090002@oracle.com> References: <55AF9FBE.2060209@oracle.com> <55B0ED94.3090002@oracle.com> Message-ID: <55B0F3DA.8050904@oracle.com> Hi, In order to test the fix I ran the svc_tools, jdk_management, jdk_jmx and jdk_jdi tests on all of the core platforms. // Katja On 07/23/2015 03:35 PM, Daniel D. Daugherty wrote: > What testing of these changes was done? > > Dan > > > On 7/22/15 7:50 AM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8132094 >> webrev: http://cr.openjdk.java.net/~ykantser/8132094/webrev.00 >> >> Thanks, >> Katja > From vladimir.kempik at oracle.com Thu Jul 23 14:56:34 2015 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 23 Jul 2015 17:56:34 +0300 Subject: [8u] request for approval: backport of JDK-8048353 Message-ID: <55B100A2.7090202@oracle.com> Hi All, I would like to backport fix for JDK-8048353 to 8u Bug id: https://bugs.openjdk.java.net/browse/JDK-8048353 Changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5133956b4a98 Fix applies cleanly to jdk8 Review thread for original fix: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015408.html testing: jprt Thanks, Vladimir From jaroslav.bachorik at oracle.com Thu Jul 23 15:01:30 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 23 Jul 2015 17:01:30 +0200 Subject: RFR(S): JDK-8059038 Create new launcher for SA tools In-Reply-To: <55A91152.905@oracle.com> References: <558967C9.9070902@oracle.com> <558A40DF.6040201@oracle.com> <558AA47E.3090902@oracle.com> <558DEB23.8000401@oracle.com> <55A7CC69.4020507@oracle.com> <55A82981.1090505@oracle.com> <55A8CF0C.7090401@oracle.com> <55A8DD1A.10407@oracle.com> <55A90163.2080509@oracle.com> <55A90306.9070400@oracle.com> <55A90D9C.10501@oracle.com> <55A91152.905@oracle.com> Message-ID: <55B101CA.3030403@oracle.com> Dmitry, thanks for undertaking this. Thumbs up from me! -JB- On 17.7.2015 16:29, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thanks for new webrev! > > A couple of comments on > hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java > > The following fragment has the same invariant for both branches: > > 136 ch = carg.charAt(_optopt); > 137 } > 138 else { > 139 ch = carg.charAt(_optopt); > 140 } > > It can be replaced with: > > } > ch = carg.charAt(_optopt); > > > One more suggestion would be to refactor the if (_optreset) { ... } with a cal to a new method optReset(). > > But I leave it up to you. > Thumbs up from me. > > > Thanks, > Serguei > > > On 7/17/15 7:13 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Sorry for typeo >> >> new webrev: >> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.06 >> >> -Dmitry >> >> >> On 2015-07-17 16:28,serguei.spitsyn at oracle.com wrote: >>> On 7/17/15 6:21 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> new webrev: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>> The webrev is the same. >>> I do not see the changes you claim below. >>> Could you, please, generate a webrev with another version number? >>> >>> >>> Thanks, >>> Serguei >>> >>>> diff to webrev.05.old attached >>>> >>>> please see also below. >>>> >>>> On 2015-07-17 13:46,serguei.spitsyn at oracle.com wrote: >>>>> Dmitry, >>>>> >>>>> Thanks for the diff, it helps! >>>>> >>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>> >>>>> Uninitialized local definition: >>>>> >>>>> 105 char ch; >>>> changed. ch is initialized later, so we actually don't need it. >>>> >>>> >>>>> Unneded second initialization at 111: >>>>> 104 String carg = _argv[_optind]; >>>>> 111 carg = _argv[_optind]; >>>> fixed. >>>> >>>>> It is not clear why carg can't be empty: >>>>> >>>>> 61 // _argv[_optind] can't be empty, so it's safe to >>>>> expect at least one character >>>>> 62 if (_argv[_optind].charAt(0) == '-') { >>>>> ... >>>>> >>>>> 113 // carg can't be empty so it's safe to expect at >>>>> least one character >>>>> 114 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>> changed. >>>> >>>> An array passed to getopt is result of splitting arguments string, so no >>>> empty array element possible. But changed it to be on safe side. >>>> >>>>> The _argv comes from outside of the method. >>>>> How can we be sure that the value _argv[_optind] is not empty String? >>>>> Does it comes from an assumption that the outside processing works >>>>> correctly? >>>>> Would it be better to always check that it is not empty? >>>>> >>>>> >>>>> It feels like this code is not clear and more complex than has to be. >>>>> But I can't tell yet what has to be simplified. >>>>> >>>>> For example, I do not like this part: >>>>> 37 private boolean _optreset; // special handling of first call >>>>> >>>>> 44 _optreset = true; >>>>> >>>>> 108 if (_optreset) { >>>>> >>>>> 138 _optreset = false; >>>>> >>>>> >>>>> Would it be better to separate this first step from the next() method >>>>> and make it a separate method that is called reset() or init()? >>>> Reset called every time when we finish the option batch: >>>> >>>> prog -xzvf filename /*reset here*/ -abc >>>> >>>>> Also, there is no clue why all this is necessary. >>>> This is a port of standard BSD getopt (based on C++ code I wrote back in >>>> 2004), that takes care of all possible option combinations and allow to >>>> process it uniform way. >>>> >>>> I would love to have it JDK-wide instead of a separate parser for each >>>> tool. >>>> >>>>> Other files look good to me. >>>>> Do you have another reviewer? >>>> Stefan Larsen reviewed one of the previous versions. >>>> >>>> -Dmitry >>>> >>>>> >>>>> On 7/17/15 2:46 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> Previous webrev is: >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05.old >>>>>> >>>>>> Latest webrev is: >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>>>> >>>>>> Diff between webrev.05.old and webrev.05 attached >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2015-07-17 01:00,serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> I do not see any changes. >>>>>>> Could you please, generate .06 version ? >>>>>>> In such a case, it will be much easier to compare the code. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 7/16/15 8:23 AM, Dmitry Samersoff wrote: >>>>>>>> Serguei, >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05 >>>>>>>> >>>>>>>> Webrev updated in-place (press shift-reload). >>>>>>>> >>>>>>>> Code changes at ll.119. >>>>>>>> >>>>>>>> Added more comments to other places. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2015-06-27 03:15,serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> Thank you for the update! >>>>>>>>> The SALauncher.java changes are really nice. >>>>>>>>> I have just couple of small comments. >>>>>>>>> >>>>>>>>> agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>>>> >>>>>>>>> 343 // Run tmtools >>>>>>>>> 344 if (args[0].equals("jstack")) { >>>>>>>>> 345 runJSTACK(oldArgs); >>>>>>>>> >>>>>>>>> Why the comment says "Run tmtools", not jstack? >>>>>>>>> BTW, other fragments have no such a comment which is Ok at it is >>>>>>>>> obvious. >>>>>>>>> >>>>>>>>> >>>>>>>>> agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>>>> >>>>>>>>> There are no checks of the carg length in several places where it is >>>>>>>>> needed: >>>>>>>>> >>>>>>>>> 61 if (_argv[_optind].charAt(0) == '-') { >>>>>>>>> >>>>>>>>> 112 if (carg.charAt(0) != '-' || carg.equals("--")) { >>>>>>>>> 117 if (carg.charAt(0) == '-' && carg.charAt(1) == >>>>>>>>> '-') { >>>>>>>>> 124 carg = carg.substring(2); >>>>>>>>> >>>>>>>>> 136 ch = carg.charAt(_optopt); >>>>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>>>> >>>>>>>>> >>>>>>>>> Otherwise, the fix looks good. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/24/15 5:37 AM, Dmitry Samersoff wrote: >>>>>>>>>> Serguei, >>>>>>>>>> >>>>>>>>>> Thank you for the review. >>>>>>>>>> >>>>>>>>>> New webrev is here: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.05/ >>>>>>>>>> >>>>>>>>>> I didn't change naming convention in SAGetoptTest.java and keep >>>>>>>>>> a_opt, >>>>>>>>>> b_opt etc as it gives better readability. Other concerns are >>>>>>>>>> addressed. >>>>>>>>>> >>>>>>>>>> BasicLauncherTest changed to use LingeredApp from testlib. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2015-06-24 08:32,serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> Some quick minor comments. >>>>>>>>>>> >>>>>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SAGetopt.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Formatting is wrong: >>>>>>>>>>> >>>>>>>>>>> 57 if (_optind >_argv.length) { >>>>>>>>>>> >>>>>>>>>>> 71 String[] ca = carg.split("=",2); >>>>>>>>>>> >>>>>>>>>>> 80 if (los.contains(ca[0]+"=")) { >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Need to use camel case for java method names: >>>>>>>>>>> >>>>>>>>>>> 55 private void extract_optarg(String opt) { >>>>>>>>>>> >>>>>>>>>>> 69 private String process_long_options(String carg, String[] >>>>>>>>>>> longOptStr) { >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Need to use quotes for '-': >>>>>>>>>>> >>>>>>>>>>> 109 // End of option batch like -abc reached, expect >>>>>>>>>>> option to start from - >>>>>>>>>>> >>>>>>>>>>> Example is: >>>>>>>>>>> >>>>>>>>>>> 133 // At this point carg[0] contains '-' >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Wrong indent at 87, 139, 120-121: >>>>>>>>>>> >>>>>>>>>>> 85 else { >>>>>>>>>>> 86 // Mixed style options --file name >>>>>>>>>>> 87 extract_optarg(ca[0]); >>>>>>>>>>> 88 } >>>>>>>>>>> >>>>>>>>>>> 138 else { >>>>>>>>>>> 139 ch = carg.charAt(_optopt); >>>>>>>>>>> 140 } >>>>>>>>>>> >>>>>>>>>>> 119 if (longOptStr == null || >>>>>>>>>>> longOptStr.length == >>>>>>>>>>> 0) { >>>>>>>>>>> 120 // No long options specified, stop >>>>>>>>>>> options >>>>>>>>>>> processing >>>>>>>>>>> 121 return null; >>>>>>>>>>> 122 } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> hotspot_webrev/agent/src/share/classes/sun/jvm/hotspot/SALauncher.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Uninitialized local: >>>>>>>>>>> >>>>>>>>>>> 128 String s; >>>>>>>>>>> >>>>>>>>>>> Need to use camel case: >>>>>>>>>>> >>>>>>>>>>> 126 String exe_or_pid = null; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The main method is too long, I'd suggest to split with the >>>>>>>>>>> sub-methods for: >>>>>>>>>>> clhsdb, hsdb, jstack, jmap, jinfo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java >>>>>>>>>>> >>>>>>>>>>> Wrong indent at 82, 85: >>>>>>>>>>> >>>>>>>>>>> 80 return toolProcess.exitValue(); >>>>>>>>>>> 81 } finally { >>>>>>>>>>> 82 theApp.stopApp(); >>>>>>>>>>> 83 } >>>>>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>>>>> 85 throw new RuntimeException("Test ERROR " >>>>>>>>>>> + ex, >>>>>>>>>>> ex); >>>>>>>>>>> 86 } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I do not understand what is the need for nested try statements, >>>>>>>>>>> just one >>>>>>>>>>> try would be enough: >>>>>>>>>>> >>>>>>>>>>> 54 System.out.println("Starting LingeredApp"); >>>>>>>>>>> 55 try { >>>>>>>>>>> 56 try { >>>>>>>>>>> . . . >>>>>>>>>>> 81 } finally { >>>>>>>>>>> 82 theApp.stopApp(); >>>>>>>>>>> 83 } >>>>>>>>>>> 84 } catch (IOException | InterruptedException ex) { >>>>>>>>>>> 85 throw new RuntimeException("Test ERROR " >>>>>>>>>>> + ex, >>>>>>>>>>> ex); >>>>>>>>>>> 86 } >>>>>>>>>>> >>>>>>>>>>> 98 try { >>>>>>>>>>> 99 try { >>>>>>>>>>> . . . >>>>>>>>>>> 116 } finally { >>>>>>>>>>> 117 theApp.stopApp(); >>>>>>>>>>> 118 } >>>>>>>>>>> 119 } catch (Exception ex) { >>>>>>>>>>> 120 throw new RuntimeException("Test ERROR " + >>>>>>>>>>> ex, ex); >>>>>>>>>>> 121 } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Why do you catch exceptions and throw the RuntimeException's in >>>>>>>>>>> the >>>>>>>>>>> launch() methods >>>>>>>>>>> but catch the IOException in main? Would it be better to catch any >>>>>>>>>>> Exception? >>>>>>>>>>> >>>>>>>>>>> Too many empty lines: >>>>>>>>>>> >>>>>>>>>>> 88 >>>>>>>>>>> 89 >>>>>>>>>>> 90 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/LingeredApp.java >>>>>>>>>>> >>>>>>>>>>> Too many empty lines: >>>>>>>>>>> >>>>>>>>>>> 275 >>>>>>>>>>> 276 >>>>>>>>>>> >>>>>>>>>>> 369 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> jdk_webrev/test/sun/tools/jhsdb/SAGetoptTest.java >>>>>>>>>>> >>>>>>>>>>> Need to use Java naming convention: >>>>>>>>>>> >>>>>>>>>>> 36 private static boolean a_opt; >>>>>>>>>>> 37 private static boolean b_opt; >>>>>>>>>>> 38 private static boolean c_opt; >>>>>>>>>>> 39 private static boolean e_opt; >>>>>>>>>>> 40 private static boolean mixed_opt; >>>>>>>>>>> 41 >>>>>>>>>>> 42 private static String d_value; >>>>>>>>>>> 43 private static String exe_value; >>>>>>>>>>> 44 private static String core_value; >>>>>>>>>>> >>>>>>>>>>> Wrong indent 2 instead of 4: >>>>>>>>>>> >>>>>>>>>>> 70 if (s.equals("a")) { >>>>>>>>>>> 71 a_opt = true; >>>>>>>>>>> 72 continue; >>>>>>>>>>> 73 } >>>>>>>>>>> 74 >>>>>>>>>>> 75 if (s.equals("b")) { >>>>>>>>>>> 76 b_opt = true; >>>>>>>>>>> 77 continue; >>>>>>>>>>> 78 } >>>>>>>>>>> 79 >>>>>>>>>>> 80 if (s.equals("c")) { >>>>>>>>>>> 81 c_opt = true; >>>>>>>>>>> 82 continue; >>>>>>>>>>> 83 } >>>>>>>>>>> 84 >>>>>>>>>>> 85 if (s.equals("e")) { >>>>>>>>>>> 86 e_opt = true; >>>>>>>>>>> 87 continue; >>>>>>>>>>> 88 } >>>>>>>>>>> 89 >>>>>>>>>>> 90 if (s.equals("mixed")) { >>>>>>>>>>> 91 mixed_opt = true; >>>>>>>>>>> 92 continue; >>>>>>>>>>> 93 } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 6/23/15 7:06 AM, Dmitry Samersoff wrote: >>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>> >>>>>>>>>>>> Please review the changes: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.04/ >>>>>>>>>>>> >>>>>>>>>>>> I'm about to file CCC request for it but would like to get >>>>>>>>>>>> internal >>>>>>>>>>>> feedback before that. >>>>>>>>>>>> >>>>>>>>>>>> This fix is introducing native launcher jhsdb for serviceability >>>>>>>>>>>> agent. >>>>>>>>>>>> >>>>>>>>>>>> jhsdb >>>>>>>>>>>> >>>>>>>>>>>> will launch command line debugger clhsdb >>>>>>>>>>>> >>>>>>>>>>>> jhsdb jstack file core >>>>>>>>>>>> jhsdb jmap file core >>>>>>>>>>>> jhsdb jinfo file core >>>>>>>>>>>> >>>>>>>>>>>> will launch corresponding SA based utility. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >> > From daniel.daugherty at oracle.com Thu Jul 23 15:33:17 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 23 Jul 2015 09:33:17 -0600 Subject: [8u] request for approval: backport of JDK-8048353 In-Reply-To: <55B100A2.7090202@oracle.com> References: <55B100A2.7090202@oracle.com> Message-ID: <55B1093D.1030302@oracle.com> Thumbs up modulo running the jstack and tmtools on the JDK8u version. Dan On 7/23/15 8:56 AM, Vladimir Kempik wrote: > Hi All, > > I would like to backport fix for JDK-8048353 to 8u > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8048353 > > Changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5133956b4a98 > > Fix applies cleanly to jdk8 > > Review thread for original fix: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015408.html > > testing: jprt > > Thanks, > Vladimir From coleen.phillimore at oracle.com Thu Jul 23 15:34:03 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 23 Jul 2015 11:34:03 -0400 Subject: RFR 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine In-Reply-To: <55B0DE6C.9030601@oracle.com> References: <55AFD144.9010102@oracle.com> <55B08B34.7080707@oracle.com> <55B0D4C6.8060303@oracle.com> <55B0D6C1.8000503@oracle.com> <55B0DE6C.9030601@oracle.com> Message-ID: <55B1096B.8000705@oracle.com> Thank you Serguei. I'll fix the indentation to 4 since that's the coding style for Java (I like 2 better!) Coleen On 7/23/15 8:30 AM, serguei.spitsyn at oracle.com wrote: > The fix is good. > Nice test! > > A couple of places with indent 2: > 78 static void localSleep() { > 79 try{ > 80 Thread.currentThread().sleep(10);//sleep for 10 ms > 81 } catch(InterruptedException ie) { > 82 } > 83 } > > 119 for (int i = 0; i < stackTrace.length; i++) { > 120 StackTraceElement frame = stackTrace[i]; > 121 if (frame.getClassName() == null) { > 122 System.out.println("\nTest failed: trace[" + i + "].getClassName() returned null"); > 123 } > 124 if (frame.getMethodName() == null) { > 125 System.out.println("\nTest failed: trace[" + i + "].getMethodName() returned null"); > 126 } > 127 } > > Thank you a lot for fixing this issue! > > Thanks, > Serguei > > > > On 7/23/15 4:57 AM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> >> On 7/23/15 4:49 AM, Coleen Phillimore wrote: >>> >>> Hi Serguei, >>> >>> On 7/23/15 2:35 AM, serguei.spitsyn at oracle.com wrote: >>>> Coleen, >>>> >>>> The fix looks good in general. >>>> There is one more place where the same may need to be fixed. >>>> It is in the function java_lang_StackTraceElement::create (): >>>> 1911 // Fill in source file name and line number. >>>> 1912 // Use specific ik version as a holder since the mirror might >>>> 1913 // refer to version that is now obsolete and no longer accessible >>>> 1914 // via the previous versions list. >>>> 1915 holder = holder->get_klass_version(version); >>>> 1916 assert(holder != NULL, "sanity check"); >>>> 1917 Symbol* source = holder->source_file_name(); >>>> >>> >>> I did change both places, I think you're looking at the old >>> version. java_lang_StackTraceElement::create() was where the crash >>> was. >>> thanks for getting to this so quickly. >> >> You are right, sorry. >> I've overlooked the second place. >> It is because both fragments look similar. >> It is nice that you have fixed them both! >> Still reviewing the test. >> >> Thanks, >> Serguei >> >>> Coleen >>> >>> >>>> I'm still reviewing the test. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 7/22/15 10:22 AM, Coleen Phillimore wrote: >>>>> Summary: Need to get source_file_name from the_class's constant >>>>> pool not previous version constant pool >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8087315.01/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8087315 >>>>> >>>>> Tested with added test (yay!), RBT (remote build and test), >>>>> vm.redefine.testlist, jdk/test/java/lang/instrument and failing >>>>> testcase 1000 times (reproduced <400). >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Thu Jul 23 18:03:48 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 23 Jul 2015 11:03:48 -0700 Subject: os::current_thread_id on Linux In-Reply-To: <55B094B7.6060309@oracle.com> References: <55B04C88.5080302@oracle.com> <55B08251.6030909@oracle.com> <55B094B7.6060309@oracle.com> Message-ID: Quick rundown: On Solaris, osthread and current_thread_id are the same (thr_self()). On Windows, they are the same (GetCurrentThreadId()). On OS X, they are the same (pthread_mach_thread_np(::pthread_self())) On AIX, current_thread_id is pthread_self, and osthread is thread_self() On non-OS X BSD, current_thread_id is pthread_self, and osthread is the syscall. I don't see any code that depends on the particular value of current_thread_id (for example, assuming that it is the same as thread_self in a meaningful way on AIX, or that it is pthread_self on AIX). My guess is that the AIX and non-OS X code are just following the Linux convention. I'm happy to make current_thread_id consistent with osthread on all of the platforms, or just on Linux (with the understanding that I can't really test AIX and OS X easily). Jeremy On Thu, Jul 23, 2015 at 12:16 AM, David Holmes wrote: > On 23/07/2015 4:11 PM, Jeremy Manson wrote: > >> Okay. TBH, thinking about it more, it's a little weird for something >> named os::current_thread_id() to be different from >> Thread::current()->osThread->thread_id(), or for either of them to be >> different from "what the OS thinks the thread id is", so it seems like >> the Right Thing to Do (in the absence of any platform-specific issues). >> > > When there are two different levels of thread ID it isn't that simple - > especially as, like you say, one can be used to look in /proc while the > other can't. So perhaps better naming is in order. > > Cheers, > David > > Jeremy >> >> On Wed, Jul 22, 2015 at 10:57 PM, David Holmes > > wrote: >> >> On 23/07/2015 3:15 PM, Jeremy Manson wrote: >> >> Hey David, >> >> Thanks for the offer of sponsorship. My goal here is really to >> make the >> log output on Linux usable. I want to be able to map the log >> output >> back to an actual thread. I don't think it really matters to >> users if >> the API consistently means "kernel thread ID" or "threading API >> thread >> ID", as long as they can figure out what the output means. >> >> >> I think consistency is important else developers don't know what >> they should be using where - which is the current situation. >> >> Since what I am doing (in effect) to accomplish my goal is to >> ensure >> that the API returns the same value as osthread()->thread_id() >> does for >> the current thread, I could just... do precisely that. >> os::current_thread_id could just return osthread()->thread_id() >> for the >> current thread. I don't have easy access to anything for testing >> other >> than Linux, though, so whether it worked (or even compiled) on >> the other >> platforms would be a bit of a guess (per the last time we did >> this dance). >> >> >> Defining os::current_thread_id() to be >> Thread::current()->osThread()->thread_id() assumes you can make >> those calls in the context in which os::current_thread_id() is used >> - if we crash during thread startup then some of those may be null >> and the id not even set. The current implementation is independent >> of the state of thread within the VM. >> >> So its okay to return the same thing as >> Thread::current()->osThread()->thread_id() but it needs to be done >> directly. >> >> Again any platform for which this would cause a change in behaviour >> needs to be examined. It may be other platforms have the same >> problem you are trying to fix for linux. >> >> If I get time later I'll try to check what each platform does. >> >> Thanks, >> David >> >> Seem reasonable? >> >> Jeremy >> >> On Wed, Jul 22, 2015 at 7:08 PM, David Holmes >> >> > >> >> wrote: >> >> On 23/07/2015 8:01 AM, Jeremy Manson wrote: >> >> Based on the feedback, this seems to be a good idea, >> approximately. >> Coleen would have sponsored, but she's going on vacation. >> Anyone else >> feel like sponsoring? >> >> >> Hold up a minute! :) There are different notions of "native >> thread >> id" that exist. First we have the "user level thread id" - >> this is >> what is reported by pthread_self in POSIX and thr_self in >> UI. Then >> we also have the OS specific "thread" id, also referred to >> as a LWP >> or "kernel scheduling entity" or "kernel thread" - the id >> for this >> is what gettid() maps back to on Linux. This distinction >> may not >> exist on all platforms. >> >> Unfortunately os::current_thread_id does not define which >> of these >> it represents: >> >> // thread id on Linux/64bit is 64bit, on Windows and >> Solaris, it's >> 32bit >> static intx current_thread_id(); >> >> and so on some platforms it returns the "user thread id" (eg >> pthread_self()), and on some it returns the same as gettid >> (ie OSX - >> but I don't know if the mach thread id is truly a "LWP" id >> ?). >> >> Also note that on some platforms the osThread stores the id >> of the >> "user-level thread" and on some the "kernel thread". Hence >> another >> source of confusion. :( >> >> So if you want to enforce that os::current_thread_id() >> represents >> the "kernel thread" then that should be applied >> consistently across >> all platforms**, and for platforms for which there is a >> change to >> make you have to ensure the usage of >> os::current_thread_id() is not >> semantically altered by the change. >> >> ** Of course a platform may only have a single notion of >> "thread" >> >> I'm happy to sponsor such a proposal. And don't worry about >> maintaining compatibility with archaic Linux versions for >> JDK9 (less >> cleanup to do later). >> >> Thanks, >> David >> >> Jeremy >> >> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson >> > > > >> > >> >> > >>> wrote: >> >> Hey folks, >> >> os::current_thread_id on Linux now maps to >> pthread_self. The >> problem with pthread_self is that it only makes >> sense in >> the context >> of the running process. When it is written out to >> the log >> (as it is >> in several places), there really isn't a way >> (AFAICT) for >> the user >> to map it back to anything useful. >> >> As it happens, that value is mostly used to write >> to the >> log. The >> places where it doesn't do so don't seem to need >> to use >> pthread_self >> for any particular reason. >> >> Meanwhile, the SIGQUIT stack dump >> uses java_thread->osthread()->thread_id() as the >> nid. On >> Linux, >> that maps back to os::Linux::gettid(), whish is >> also what gets >> exposed in /proc. That makes it much easier to >> see what >> threads >> might be doing the log write. >> >> Would it be okay to change os::current_thread_id >> to point >> to os::Linux::gettid()? That way, it can be >> mapped back to the >> output of a SIGQUIT dump. >> >> The downside of gettid() is that it is only >> available on >> Linux>2.4.11, but that dates from 2001. If we >> really still >> want to >> support it, we could check for that. >> >> Thoughts? >> >> Jeremy >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Jul 24 00:28:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jul 2015 10:28:49 +1000 Subject: os::current_thread_id on Linux In-Reply-To: References: <55B04C88.5080302@oracle.com> <55B08251.6030909@oracle.com> <55B094B7.6060309@oracle.com> Message-ID: <55B186C1.1080706@oracle.com> On 24/07/2015 4:03 AM, Jeremy Manson wrote: > Quick rundown: Thanks - sorry I couldn't get to this last night. > On Solaris, osthread and current_thread_id are the same (thr_self()). So both user-thread > On Windows, they are the same (GetCurrentThreadId()). Windows is single-level. > On OS X, they are the same (pthread_mach_thread_np(::pthread_self())) Both "kernel" thread > On AIX, current_thread_id is pthread_self, and osthread is thread_self() > On non-OS X BSD, current_thread_id is pthread_self, and osthread is the > syscall. One user and one kernel. > I don't see any code that depends on the particular value of > current_thread_id (for example, assuming that it is the same as > thread_self in a meaningful way on AIX, or that it is pthread_self on > AIX). My guess is that the AIX and non-OS X code are just following the > Linux convention. Yes - port by copy. :( > I'm happy to make current_thread_id consistent with > osthread on all of the platforms, or just on Linux (with the > understanding that I can't really test AIX and OS X easily). Just make the change on Linux, there's really no consistency here to aim for. :( Thanks, David > Jeremy > > On Thu, Jul 23, 2015 at 12:16 AM, David Holmes > wrote: > > On 23/07/2015 4:11 PM, Jeremy Manson wrote: > > Okay. TBH, thinking about it more, it's a little weird for > something > named os::current_thread_id() to be different from > Thread::current()->osThread->thread_id(), or for either of them > to be > different from "what the OS thinks the thread id is", so it > seems like > the Right Thing to Do (in the absence of any platform-specific > issues). > > > When there are two different levels of thread ID it isn't that > simple - especially as, like you say, one can be used to look in > /proc while the other can't. So perhaps better naming is in order. > > Cheers, > David > > Jeremy > > On Wed, Jul 22, 2015 at 10:57 PM, David Holmes > > >> wrote: > > On 23/07/2015 3:15 PM, Jeremy Manson wrote: > > Hey David, > > Thanks for the offer of sponsorship. My goal here is > really to > make the > log output on Linux usable. I want to be able to map > the log output > back to an actual thread. I don't think it really > matters to > users if > the API consistently means "kernel thread ID" or > "threading API > thread > ID", as long as they can figure out what the output means. > > > I think consistency is important else developers don't know > what > they should be using where - which is the current situation. > > Since what I am doing (in effect) to accomplish my goal > is to ensure > that the API returns the same value as > osthread()->thread_id() > does for > the current thread, I could just... do precisely that. > os::current_thread_id could just return > osthread()->thread_id() > for the > current thread. I don't have easy access to anything > for testing > other > than Linux, though, so whether it worked (or even > compiled) on > the other > platforms would be a bit of a guess (per the last time > we did > this dance). > > > Defining os::current_thread_id() to be > Thread::current()->osThread()->thread_id() assumes you can make > those calls in the context in which os::current_thread_id() > is used > - if we crash during thread startup then some of those may > be null > and the id not even set. The current implementation is > independent > of the state of thread within the VM. > > So its okay to return the same thing as > Thread::current()->osThread()->thread_id() but it needs to > be done > directly. > > Again any platform for which this would cause a change in > behaviour > needs to be examined. It may be other platforms have the same > problem you are trying to fix for linux. > > If I get time later I'll try to check what each platform does. > > Thanks, > David > > Seem reasonable? > > Jeremy > > On Wed, Jul 22, 2015 at 7:08 PM, David Holmes > > > > > >>> wrote: > > On 23/07/2015 8:01 AM, Jeremy Manson wrote: > > Based on the feedback, this seems to be a good > idea, > approximately. > Coleen would have sponsored, but she's going > on vacation. > Anyone else > feel like sponsoring? > > > Hold up a minute! :) There are different notions > of "native > thread > id" that exist. First we have the "user level > thread id" - > this is > what is reported by pthread_self in POSIX and > thr_self in > UI. Then > we also have the OS specific "thread" id, also > referred to > as a LWP > or "kernel scheduling entity" or "kernel thread" - > the id > for this > is what gettid() maps back to on Linux. This > distinction > may not > exist on all platforms. > > Unfortunately os::current_thread_id does not > define which > of these > it represents: > > // thread id on Linux/64bit is 64bit, on Windows and > Solaris, it's > 32bit > static intx current_thread_id(); > > and so on some platforms it returns the "user > thread id" (eg > pthread_self()), and on some it returns the same > as gettid > (ie OSX - > but I don't know if the mach thread id is truly a > "LWP" id ?). > > Also note that on some platforms the osThread > stores the id > of the > "user-level thread" and on some the "kernel > thread". Hence > another > source of confusion. :( > > So if you want to enforce that os::current_thread_id() > represents > the "kernel thread" then that should be applied > consistently across > all platforms**, and for platforms for which there > is a > change to > make you have to ensure the usage of > os::current_thread_id() is not > semantically altered by the change. > > ** Of course a platform may only have a single > notion of > "thread" > > I'm happy to sponsor such a proposal. And don't > worry about > maintaining compatibility with archaic Linux > versions for > JDK9 (less > cleanup to do later). > > Thanks, > David > > Jeremy > > On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson > > > > > >> > > > > > > >>>> wrote: > > Hey folks, > > os::current_thread_id on Linux now maps to > pthread_self. The > problem with pthread_self is that it only > makes > sense in > the context > of the running process. When it is > written out to > the log > (as it is > in several places), there really isn't a way > (AFAICT) for > the user > to map it back to anything useful. > > As it happens, that value is mostly used > to write > to the > log. The > places where it doesn't do so don't seem > to need > to use > pthread_self > for any particular reason. > > Meanwhile, the SIGQUIT stack dump > uses java_thread->osthread()->thread_id() > as the > nid. On > Linux, > that maps back to os::Linux::gettid(), > whish is > also what gets > exposed in /proc. That makes it much > easier to > see what > threads > might be doing the log write. > > Would it be okay to change > os::current_thread_id > to point > to os::Linux::gettid()? That way, it can be > mapped back to the > output of a SIGQUIT dump. > > The downside of gettid() is that it is only > available on > Linux>2.4.11, but that dates from 2001. > If we > really still > want to > support it, we could check for that. > > Thoughts? > > Jeremy > > > > > From yekaterina.kantserova at oracle.com Fri Jul 24 14:06:15 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 24 Jul 2015 16:06:15 +0200 Subject: RFR(XS): 8062938: sun/jvmstat/monitor/MonitoredVm/CR6672135.java: java.lang.IllegalArgumentException: Could not map vmid to user name Message-ID: <55B24657.1000002@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8062938 webrev: http://cr.openjdk.java.net/~ykantser/8062938/webrev.00 As David pointed out [1] the test is trying to monitor the first best VM from localHost.activeVms() which can result in various errors (https://bugs.openjdk.java.net/browse/JDK-8064572, https://bugs.openjdk.java.net/browse/JDK-8060736). The solution is to start a test VM and operate on it. In order to test the fix the test has been run on all supported platforms. Thanks, Katja [1] David Holmes added a comment - 2014-11-07 12:39 My theory is that this test finds all VMs running on the machine, but some of those are not accessible to it - perhaps even running under a different user. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Jul 24 15:02:35 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 24 Jul 2015 17:02:35 +0200 Subject: RFR(XS): 8062938: sun/jvmstat/monitor/MonitoredVm/CR6672135.java: java.lang.IllegalArgumentException: Could not map vmid to user name In-Reply-To: <55B24657.1000002@oracle.com> References: <55B24657.1000002@oracle.com> Message-ID: <55B2538B.1000909@oracle.com> Thumbs up! -JB- On 24.7.2015 16:06, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8062938 > webrev: http://cr.openjdk.java.net/~ykantser/8062938/webrev.00 > > As David pointed out [1] the test is trying to monitor the first best VM > from localHost.activeVms() which can result in various errors > (https://bugs.openjdk.java.net/browse/JDK-8064572, > https://bugs.openjdk.java.net/browse/JDK-8060736). > > The solution is to start a test VM and operate on it. In order to test > the fix the test has been run on all supported platforms. > > Thanks, > Katja > > > > [1] David Holmes > > added a comment - 2014-11-07 12:39 > My theory is that this test finds all VMs running on the machine, but > some of those are not accessible to it - perhaps even running under a > different user. From yekaterina.kantserova at oracle.com Mon Jul 27 07:48:46 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 27 Jul 2015 09:48:46 +0200 Subject: RFR(XS): 8062938: sun/jvmstat/monitor/MonitoredVm/CR6672135.java: java.lang.IllegalArgumentException: Could not map vmid to user name In-Reply-To: <55B2538B.1000909@oracle.com> References: <55B24657.1000002@oracle.com> <55B2538B.1000909@oracle.com> Message-ID: <55B5E25E.7000807@oracle.com> Jaroslav, thanks for the review! // Katja On 07/24/2015 05:02 PM, Jaroslav Bachorik wrote: > Thumbs up! > > -JB- > > On 24.7.2015 16:06, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8062938 >> webrev: http://cr.openjdk.java.net/~ykantser/8062938/webrev.00 >> >> As David pointed out [1] the test is trying to monitor the first best VM >> from localHost.activeVms() which can result in various errors >> (https://bugs.openjdk.java.net/browse/JDK-8064572, >> https://bugs.openjdk.java.net/browse/JDK-8060736). >> >> The solution is to start a test VM and operate on it. In order to test >> the fix the test has been run on all supported platforms. >> >> Thanks, >> Katja >> >> >> >> [1] David Holmes >> >> added a comment - 2014-11-07 12:39 >> My theory is that this test finds all VMs running on the machine, but >> some of those are not accessible to it - perhaps even running under a >> different user. > From jeremymanson at google.com Mon Jul 27 18:11:18 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 27 Jul 2015 11:11:18 -0700 Subject: os::current_thread_id on Linux In-Reply-To: <55B186C1.1080706@oracle.com> References: <55B04C88.5080302@oracle.com> <55B08251.6030909@oracle.com> <55B094B7.6060309@oracle.com> <55B186C1.1080706@oracle.com> Message-ID: Okay, thanks, David. I'll submit a patch to make one API call the other, so that there will be no confusion in the future. Jeremy On Thu, Jul 23, 2015 at 5:28 PM, David Holmes wrote: > On 24/07/2015 4:03 AM, Jeremy Manson wrote: > >> Quick rundown: >> > > Thanks - sorry I couldn't get to this last night. > > On Solaris, osthread and current_thread_id are the same (thr_self()). >> > > So both user-thread > > On Windows, they are the same (GetCurrentThreadId()). >> > > Windows is single-level. > > On OS X, they are the same (pthread_mach_thread_np(::pthread_self())) >> > > Both "kernel" thread > > On AIX, current_thread_id is pthread_self, and osthread is thread_self() >> On non-OS X BSD, current_thread_id is pthread_self, and osthread is the >> syscall. >> > > One user and one kernel. > > I don't see any code that depends on the particular value of >> current_thread_id (for example, assuming that it is the same as >> thread_self in a meaningful way on AIX, or that it is pthread_self on >> AIX). My guess is that the AIX and non-OS X code are just following the >> Linux convention. >> > > Yes - port by copy. :( > > I'm happy to make current_thread_id consistent with >> osthread on all of the platforms, or just on Linux (with the >> understanding that I can't really test AIX and OS X easily). >> > > Just make the change on Linux, there's really no consistency here to aim > for. :( > > Thanks, > David > > Jeremy >> >> On Thu, Jul 23, 2015 at 12:16 AM, David Holmes > > wrote: >> >> On 23/07/2015 4:11 PM, Jeremy Manson wrote: >> >> Okay. TBH, thinking about it more, it's a little weird for >> something >> named os::current_thread_id() to be different from >> Thread::current()->osThread->thread_id(), or for either of them >> to be >> different from "what the OS thinks the thread id is", so it >> seems like >> the Right Thing to Do (in the absence of any platform-specific >> issues). >> >> >> When there are two different levels of thread ID it isn't that >> simple - especially as, like you say, one can be used to look in >> /proc while the other can't. So perhaps better naming is in order. >> >> Cheers, >> David >> >> Jeremy >> >> On Wed, Jul 22, 2015 at 10:57 PM, David Holmes >> >> > >> wrote: >> >> On 23/07/2015 3:15 PM, Jeremy Manson wrote: >> >> Hey David, >> >> Thanks for the offer of sponsorship. My goal here is >> really to >> make the >> log output on Linux usable. I want to be able to map >> the log output >> back to an actual thread. I don't think it really >> matters to >> users if >> the API consistently means "kernel thread ID" or >> "threading API >> thread >> ID", as long as they can figure out what the output >> means. >> >> >> I think consistency is important else developers don't know >> what >> they should be using where - which is the current situation. >> >> Since what I am doing (in effect) to accomplish my goal >> is to ensure >> that the API returns the same value as >> osthread()->thread_id() >> does for >> the current thread, I could just... do precisely that. >> os::current_thread_id could just return >> osthread()->thread_id() >> for the >> current thread. I don't have easy access to anything >> for testing >> other >> than Linux, though, so whether it worked (or even >> compiled) on >> the other >> platforms would be a bit of a guess (per the last time >> we did >> this dance). >> >> >> Defining os::current_thread_id() to be >> Thread::current()->osThread()->thread_id() assumes you can >> make >> those calls in the context in which os::current_thread_id() >> is used >> - if we crash during thread startup then some of those may >> be null >> and the id not even set. The current implementation is >> independent >> of the state of thread within the VM. >> >> So its okay to return the same thing as >> Thread::current()->osThread()->thread_id() but it needs to >> be done >> directly. >> >> Again any platform for which this would cause a change in >> behaviour >> needs to be examined. It may be other platforms have the same >> problem you are trying to fix for linux. >> >> If I get time later I'll try to check what each platform >> does. >> >> Thanks, >> David >> >> Seem reasonable? >> >> Jeremy >> >> On Wed, Jul 22, 2015 at 7:08 PM, David Holmes >> > > > >> > >> >> > >>> wrote: >> >> On 23/07/2015 8:01 AM, Jeremy Manson wrote: >> >> Based on the feedback, this seems to be a good >> idea, >> approximately. >> Coleen would have sponsored, but she's going >> on vacation. >> Anyone else >> feel like sponsoring? >> >> >> Hold up a minute! :) There are different notions >> of "native >> thread >> id" that exist. First we have the "user level >> thread id" - >> this is >> what is reported by pthread_self in POSIX and >> thr_self in >> UI. Then >> we also have the OS specific "thread" id, also >> referred to >> as a LWP >> or "kernel scheduling entity" or "kernel thread" - >> the id >> for this >> is what gettid() maps back to on Linux. This >> distinction >> may not >> exist on all platforms. >> >> Unfortunately os::current_thread_id does not >> define which >> of these >> it represents: >> >> // thread id on Linux/64bit is 64bit, on Windows >> and >> Solaris, it's >> 32bit >> static intx current_thread_id(); >> >> and so on some platforms it returns the "user >> thread id" (eg >> pthread_self()), and on some it returns the same >> as gettid >> (ie OSX - >> but I don't know if the mach thread id is truly a >> "LWP" id ?). >> >> Also note that on some platforms the osThread >> stores the id >> of the >> "user-level thread" and on some the "kernel >> thread". Hence >> another >> source of confusion. :( >> >> So if you want to enforce that >> os::current_thread_id() >> represents >> the "kernel thread" then that should be applied >> consistently across >> all platforms**, and for platforms for which there >> is a >> change to >> make you have to ensure the usage of >> os::current_thread_id() is not >> semantically altered by the change. >> >> ** Of course a platform may only have a single >> notion of >> "thread" >> >> I'm happy to sponsor such a proposal. And don't >> worry about >> maintaining compatibility with archaic Linux >> versions for >> JDK9 (less >> cleanup to do later). >> >> Thanks, >> David >> >> Jeremy >> >> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson >> > >> > > >> >> > >> >> > >> > > >> >> > >> > >>>> wrote: >> >> Hey folks, >> >> os::current_thread_id on Linux now maps to >> pthread_self. The >> problem with pthread_self is that it only >> makes >> sense in >> the context >> of the running process. When it is >> written out to >> the log >> (as it is >> in several places), there really isn't a >> way >> (AFAICT) for >> the user >> to map it back to anything useful. >> >> As it happens, that value is mostly used >> to write >> to the >> log. The >> places where it doesn't do so don't seem >> to need >> to use >> pthread_self >> for any particular reason. >> >> Meanwhile, the SIGQUIT stack dump >> uses java_thread->osthread()->thread_id() >> as the >> nid. On >> Linux, >> that maps back to os::Linux::gettid(), >> whish is >> also what gets >> exposed in /proc. That makes it much >> easier to >> see what >> threads >> might be doing the log write. >> >> Would it be okay to change >> os::current_thread_id >> to point >> to os::Linux::gettid()? That way, it can >> be >> mapped back to the >> output of a SIGQUIT dump. >> >> The downside of gettid() is that it is only >> available on >> Linux>2.4.11, but that dates from 2001. >> If we >> really still >> want to >> support it, we could check for that. >> >> Thoughts? >> >> Jeremy >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Mon Jul 27 18:14:09 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 27 Jul 2015 11:14:09 -0700 Subject: os::current_thread_id on Linux In-Reply-To: References: <55B04C88.5080302@oracle.com> <55B08251.6030909@oracle.com> <55B094B7.6060309@oracle.com> <55B186C1.1080706@oracle.com> Message-ID: Turns out JDK-6661889 already covered this. Jeremy On Mon, Jul 27, 2015 at 11:11 AM, Jeremy Manson wrote: > Okay, thanks, David. I'll submit a patch to make one API call the other, > so that there will be no confusion in the future. > > Jeremy > > On Thu, Jul 23, 2015 at 5:28 PM, David Holmes > wrote: > >> On 24/07/2015 4:03 AM, Jeremy Manson wrote: >> >>> Quick rundown: >>> >> >> Thanks - sorry I couldn't get to this last night. >> >> On Solaris, osthread and current_thread_id are the same (thr_self()). >>> >> >> So both user-thread >> >> On Windows, they are the same (GetCurrentThreadId()). >>> >> >> Windows is single-level. >> >> On OS X, they are the same (pthread_mach_thread_np(::pthread_self())) >>> >> >> Both "kernel" thread >> >> On AIX, current_thread_id is pthread_self, and osthread is thread_self() >>> On non-OS X BSD, current_thread_id is pthread_self, and osthread is the >>> syscall. >>> >> >> One user and one kernel. >> >> I don't see any code that depends on the particular value of >>> current_thread_id (for example, assuming that it is the same as >>> thread_self in a meaningful way on AIX, or that it is pthread_self on >>> AIX). My guess is that the AIX and non-OS X code are just following the >>> Linux convention. >>> >> >> Yes - port by copy. :( >> >> I'm happy to make current_thread_id consistent with >>> osthread on all of the platforms, or just on Linux (with the >>> understanding that I can't really test AIX and OS X easily). >>> >> >> Just make the change on Linux, there's really no consistency here to aim >> for. :( >> >> Thanks, >> David >> >> Jeremy >>> >>> On Thu, Jul 23, 2015 at 12:16 AM, David Holmes >> > wrote: >>> >>> On 23/07/2015 4:11 PM, Jeremy Manson wrote: >>> >>> Okay. TBH, thinking about it more, it's a little weird for >>> something >>> named os::current_thread_id() to be different from >>> Thread::current()->osThread->thread_id(), or for either of them >>> to be >>> different from "what the OS thinks the thread id is", so it >>> seems like >>> the Right Thing to Do (in the absence of any platform-specific >>> issues). >>> >>> >>> When there are two different levels of thread ID it isn't that >>> simple - especially as, like you say, one can be used to look in >>> /proc while the other can't. So perhaps better naming is in order. >>> >>> Cheers, >>> David >>> >>> Jeremy >>> >>> On Wed, Jul 22, 2015 at 10:57 PM, David Holmes >>> >>> >> >>> >> wrote: >>> >>> On 23/07/2015 3:15 PM, Jeremy Manson wrote: >>> >>> Hey David, >>> >>> Thanks for the offer of sponsorship. My goal here is >>> really to >>> make the >>> log output on Linux usable. I want to be able to map >>> the log output >>> back to an actual thread. I don't think it really >>> matters to >>> users if >>> the API consistently means "kernel thread ID" or >>> "threading API >>> thread >>> ID", as long as they can figure out what the output >>> means. >>> >>> >>> I think consistency is important else developers don't know >>> what >>> they should be using where - which is the current situation. >>> >>> Since what I am doing (in effect) to accomplish my goal >>> is to ensure >>> that the API returns the same value as >>> osthread()->thread_id() >>> does for >>> the current thread, I could just... do precisely that. >>> os::current_thread_id could just return >>> osthread()->thread_id() >>> for the >>> current thread. I don't have easy access to anything >>> for testing >>> other >>> than Linux, though, so whether it worked (or even >>> compiled) on >>> the other >>> platforms would be a bit of a guess (per the last time >>> we did >>> this dance). >>> >>> >>> Defining os::current_thread_id() to be >>> Thread::current()->osThread()->thread_id() assumes you can >>> make >>> those calls in the context in which os::current_thread_id() >>> is used >>> - if we crash during thread startup then some of those may >>> be null >>> and the id not even set. The current implementation is >>> independent >>> of the state of thread within the VM. >>> >>> So its okay to return the same thing as >>> Thread::current()->osThread()->thread_id() but it needs to >>> be done >>> directly. >>> >>> Again any platform for which this would cause a change in >>> behaviour >>> needs to be examined. It may be other platforms have the >>> same >>> problem you are trying to fix for linux. >>> >>> If I get time later I'll try to check what each platform >>> does. >>> >>> Thanks, >>> David >>> >>> Seem reasonable? >>> >>> Jeremy >>> >>> On Wed, Jul 22, 2015 at 7:08 PM, David Holmes >>> >> >> > >>> >> >>> >>> >> >>> wrote: >>> >>> On 23/07/2015 8:01 AM, Jeremy Manson wrote: >>> >>> Based on the feedback, this seems to be a good >>> idea, >>> approximately. >>> Coleen would have sponsored, but she's going >>> on vacation. >>> Anyone else >>> feel like sponsoring? >>> >>> >>> Hold up a minute! :) There are different notions >>> of "native >>> thread >>> id" that exist. First we have the "user level >>> thread id" - >>> this is >>> what is reported by pthread_self in POSIX and >>> thr_self in >>> UI. Then >>> we also have the OS specific "thread" id, also >>> referred to >>> as a LWP >>> or "kernel scheduling entity" or "kernel thread" - >>> the id >>> for this >>> is what gettid() maps back to on Linux. This >>> distinction >>> may not >>> exist on all platforms. >>> >>> Unfortunately os::current_thread_id does not >>> define which >>> of these >>> it represents: >>> >>> // thread id on Linux/64bit is 64bit, on Windows >>> and >>> Solaris, it's >>> 32bit >>> static intx current_thread_id(); >>> >>> and so on some platforms it returns the "user >>> thread id" (eg >>> pthread_self()), and on some it returns the same >>> as gettid >>> (ie OSX - >>> but I don't know if the mach thread id is truly a >>> "LWP" id ?). >>> >>> Also note that on some platforms the osThread >>> stores the id >>> of the >>> "user-level thread" and on some the "kernel >>> thread". Hence >>> another >>> source of confusion. :( >>> >>> So if you want to enforce that >>> os::current_thread_id() >>> represents >>> the "kernel thread" then that should be applied >>> consistently across >>> all platforms**, and for platforms for which there >>> is a >>> change to >>> make you have to ensure the usage of >>> os::current_thread_id() is not >>> semantically altered by the change. >>> >>> ** Of course a platform may only have a single >>> notion of >>> "thread" >>> >>> I'm happy to sponsor such a proposal. And don't >>> worry about >>> maintaining compatibility with archaic Linux >>> versions for >>> JDK9 (less >>> cleanup to do later). >>> >>> Thanks, >>> David >>> >>> Jeremy >>> >>> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson >>> >> >>> >> > >>> >>> >> >> >>> >> >>> >> > >>> >>> >> >>> >> >>>> wrote: >>> >>> Hey folks, >>> >>> os::current_thread_id on Linux now maps to >>> pthread_self. The >>> problem with pthread_self is that it only >>> makes >>> sense in >>> the context >>> of the running process. When it is >>> written out to >>> the log >>> (as it is >>> in several places), there really isn't a >>> way >>> (AFAICT) for >>> the user >>> to map it back to anything useful. >>> >>> As it happens, that value is mostly used >>> to write >>> to the >>> log. The >>> places where it doesn't do so don't seem >>> to need >>> to use >>> pthread_self >>> for any particular reason. >>> >>> Meanwhile, the SIGQUIT stack dump >>> uses java_thread->osthread()->thread_id() >>> as the >>> nid. On >>> Linux, >>> that maps back to os::Linux::gettid(), >>> whish is >>> also what gets >>> exposed in /proc. That makes it much >>> easier to >>> see what >>> threads >>> might be doing the log write. >>> >>> Would it be okay to change >>> os::current_thread_id >>> to point >>> to os::Linux::gettid()? That way, it can >>> be >>> mapped back to the >>> output of a SIGQUIT dump. >>> >>> The downside of gettid() is that it is >>> only >>> available on >>> Linux>2.4.11, but that dates from 2001. >>> If we >>> really still >>> want to >>> support it, we could check for that. >>> >>> Thoughts? >>> >>> Jeremy >>> >>> >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jul 28 01:40:56 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 27 Jul 2015 18:40:56 -0700 Subject: JDK 9 RFR of JDK-8122944: perfdata used is seen as too high on sparc zone with jdk1.9 and causes a test failure Message-ID: <55B6DDA8.3050103@oracle.com> Hello, In certain machine configurations (large SPARC boxes with lots of threads), the test sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java fails because the PerfDataMemorySize buffer gets too close to its limit. To allow the test to pass on machines like this as well as smaller boxes, I'd like to just bump its PerfDataMemorySize to 64k from the default of 32k. The patch to accomplish this is: --- a/test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java Sat Jul 25 08:50:45 2015 +0300 +++ b/test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java Mon Jul 27 18:37:23 2015 -0700 @@ -25,7 +25,7 @@ * @test * @bug 4990825 * @modules jdk.jvmstat/sun.jvmstat.monitor - * @run main/othervm -XX:+UsePerfData PrologSizeSanityCheck + * @run main/othervm -XX:+UsePerfData -XX:PerfDataMemorySize=64k PrologSizeSanityCheck * @summary prolog size and overflow sanity checks */ Thanks, -Joe From david.holmes at oracle.com Tue Jul 28 01:44:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jul 2015 11:44:16 +1000 Subject: JDK 9 RFR of JDK-8122944: perfdata used is seen as too high on sparc zone with jdk1.9 and causes a test failure In-Reply-To: <55B6DDA8.3050103@oracle.com> References: <55B6DDA8.3050103@oracle.com> Message-ID: <55B6DE70.8000505@oracle.com> Seems reasonable. Thanks, David On 28/07/2015 11:40 AM, Joseph D. Darcy wrote: > Hello, > > In certain machine configurations (large SPARC boxes with lots of > threads), the test > > sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java > > fails because the PerfDataMemorySize buffer gets too close to its limit. > To allow the test to pass on machines like this as well as smaller > boxes, I'd like to just bump its PerfDataMemorySize to 64k from the > default of 32k. The patch to accomplish this is: > > --- a/test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java > Sat Jul 25 08:50:45 2015 +0300 > +++ b/test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java > Mon Jul 27 18:37:23 2015 -0700 > @@ -25,7 +25,7 @@ > * @test > * @bug 4990825 > * @modules jdk.jvmstat/sun.jvmstat.monitor > - * @run main/othervm -XX:+UsePerfData PrologSizeSanityCheck > + * @run main/othervm -XX:+UsePerfData -XX:PerfDataMemorySize=64k > PrologSizeSanityCheck > * @summary prolog size and overflow sanity checks > */ > > Thanks, > > -Joe From alexander.kulyakhtin at oracle.com Wed Jul 29 14:29:29 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 29 Jul 2015 07:29:29 -0700 (PDT) Subject: RFR: JDK-8130527: serviceability tests fails with Can't attach to process Message-ID: Hi, Could you, please, review the following small test-only fix: CR: JDK-8130527 "Serviceability tests fails with Can't attach to process." (the CR was submitted as confidential for other reasons, all changes are in the public domain) Webrev: http://cr.openjdk.java.net/~akulyakh/8130527/index.html Before the fix we were excluding the tests from execution based on the contents of a certain Linux file, which we read into a single String for analysis. Due to a regression JDK-8132539 the API we used for reading the file into a string is broken. We are changing the reading method to use an older API. Best regards, Alexander From jaroslav.bachorik at oracle.com Wed Jul 29 15:05:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 29 Jul 2015 17:05:47 +0200 Subject: RFR: JDK-8130527: serviceability tests fails with Can't attach to process In-Reply-To: References: Message-ID: <55B8EBCB.50605@oracle.com> Looks good! -JB- On 29.7.2015 16:29, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following small test-only fix: > > CR: JDK-8130527 "Serviceability tests fails with Can't attach to process." (the CR was submitted as confidential for other reasons, all changes are in the public domain) > Webrev: http://cr.openjdk.java.net/~akulyakh/8130527/index.html > > Before the fix we were excluding the tests from execution based on the contents of a certain Linux file, which we read into a single String for analysis. > Due to a regression JDK-8132539 the API we used for reading the file into a string is broken. > We are changing the reading method to use an older API. > > Best regards, > Alexander > From jeremymanson at google.com Wed Jul 29 20:34:55 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 29 Jul 2015 13:34:55 -0700 Subject: RFR (XS): 6661889: thread id on Linux is inconsistent in error and log outputs Message-ID: David, can you review/sponsor this, per our conversation of last week? It fixes an issue where, on Linux, some of the Hotspot logging output identifies threads by pthread_id, and some of it identifies threads by kernel-level TID. This happened because Hotspot calls into two different APIs that provide the thread ID, and developers seem to have picked which one they call at random. The CR makes these APIs consistently use the kernel-level TID, and makes one of the APIs a thin shim over the other. Conversation: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015507.html Bug: https://bugs.openjdk.java.net/browse/JDK-6661889 Webrev: http://cr.openjdk.java.net/~jmanson/6661889/webrev.01/ Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jul 29 22:31:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2015 08:31:57 +1000 Subject: RFR (XS): 6661889: thread id on Linux is inconsistent in error and log outputs In-Reply-To: References: Message-ID: <55B9545D.8000506@oracle.com> Hi Jeremy, On 30/07/2015 6:34 AM, Jeremy Manson wrote: > David, can you review/sponsor this, per our conversation of last week? Yes I can sponsor and it is also Reviewed. But I'd like a second review from someone else. Thanks, David > It fixes an issue where, on Linux, some of the Hotspot logging output > identifies threads by pthread_id, and some of it identifies threads by > kernel-level TID. This happened because Hotspot calls into two > different APIs that provide the thread ID, and developers seem to have > picked which one they call at random. > > The CR makes these APIs consistently use the kernel-level TID, and makes > one of the APIs a thin shim over the other. > > Conversation: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015507.html > Bug: https://bugs.openjdk.java.net/browse/JDK-6661889 > Webrev: http://cr.openjdk.java.net/~jmanson/6661889/webrev.01/ > > Jeremy From vladimir.kozlov at oracle.com Wed Jul 29 23:07:44 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jul 2015 16:07:44 -0700 Subject: RFR (XS): 6661889: thread id on Linux is inconsistent in error and log outputs In-Reply-To: <55B9545D.8000506@oracle.com> References: <55B9545D.8000506@oracle.com> Message-ID: <55B95CC0.2090303@oracle.com> Finally after 7 years, since I filed this bug, it will be fixed :) Looks good. Thanks, Vladimir On 7/29/15 3:31 PM, David Holmes wrote: > Hi Jeremy, > > On 30/07/2015 6:34 AM, Jeremy Manson wrote: >> David, can you review/sponsor this, per our conversation of last week? > > Yes I can sponsor and it is also Reviewed. > > But I'd like a second review from someone else. > > Thanks, > David > >> It fixes an issue where, on Linux, some of the Hotspot logging output >> identifies threads by pthread_id, and some of it identifies threads by >> kernel-level TID. This happened because Hotspot calls into two >> different APIs that provide the thread ID, and developers seem to have >> picked which one they call at random. >> >> The CR makes these APIs consistently use the kernel-level TID, and makes >> one of the APIs a thin shim over the other. >> >> Conversation: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015507.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6661889 >> Webrev: http://cr.openjdk.java.net/~jmanson/6661889/webrev.01/ >> >> Jeremy From david.holmes at oracle.com Thu Jul 30 03:03:56 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2015 13:03:56 +1000 Subject: RFR (XS): 6661889: thread id on Linux is inconsistent in error and log outputs In-Reply-To: <55B95CC0.2090303@oracle.com> References: <55B9545D.8000506@oracle.com> <55B95CC0.2090303@oracle.com> Message-ID: <55B9941C.8050806@oracle.com> On 30/07/2015 9:07 AM, Vladimir Kozlov wrote: > Finally after 7 years, since I filed this bug, it will be fixed :) I hope it now does what you wanted :) On its way. Thanks, David > Looks good. > > Thanks, > Vladimir > > On 7/29/15 3:31 PM, David Holmes wrote: >> Hi Jeremy, >> >> On 30/07/2015 6:34 AM, Jeremy Manson wrote: >>> David, can you review/sponsor this, per our conversation of last week? >> >> Yes I can sponsor and it is also Reviewed. >> >> But I'd like a second review from someone else. >> >> Thanks, >> David >> >>> It fixes an issue where, on Linux, some of the Hotspot logging output >>> identifies threads by pthread_id, and some of it identifies threads by >>> kernel-level TID. This happened because Hotspot calls into two >>> different APIs that provide the thread ID, and developers seem to have >>> picked which one they call at random. >>> >>> The CR makes these APIs consistently use the kernel-level TID, and makes >>> one of the APIs a thin shim over the other. >>> >>> Conversation: >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015507.html >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6661889 >>> Webrev: http://cr.openjdk.java.net/~jmanson/6661889/webrev.01/ >>> >>> Jeremy From david.holmes at oracle.com Thu Jul 30 04:56:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2015 14:56:48 +1000 Subject: RFR: JDK-8130527: serviceability tests fails with Can't attach to process In-Reply-To: References: Message-ID: <55B9AE90.30405@oracle.com> On 30/07/2015 12:29 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following small test-only fix: > > CR: JDK-8130527 "Serviceability tests fails with Can't attach to process." (the CR was submitted as confidential for other reasons, all changes are in the public domain) > Webrev: http://cr.openjdk.java.net/~akulyakh/8130527/index.html > > Before the fix we were excluding the tests from execution based on the contents of a certain Linux file, which we read into a single String for analysis. > Due to a regression JDK-8132539 the API we used for reading the file into a string is broken. > We are changing the reading method to use an older API. Looks okay. Please add a space after "if": if(!Files.exists(filePath)) return null; Thanks, David > Best regards, > Alexander > From jeremymanson at google.com Thu Jul 30 05:48:28 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 29 Jul 2015 22:48:28 -0700 Subject: RFR (XS): 6661889: thread id on Linux is inconsistent in error and log outputs In-Reply-To: <55B9941C.8050806@oracle.com> References: <55B9545D.8000506@oracle.com> <55B95CC0.2090303@oracle.com> <55B9941C.8050806@oracle.com> Message-ID: Thanks, folks! Jeremy On Wed, Jul 29, 2015 at 8:03 PM, David Holmes wrote: > On 30/07/2015 9:07 AM, Vladimir Kozlov wrote: > >> Finally after 7 years, since I filed this bug, it will be fixed :) >> > > I hope it now does what you wanted :) > > On its way. > > Thanks, > David > > > Looks good. >> >> Thanks, >> Vladimir >> >> On 7/29/15 3:31 PM, David Holmes wrote: >> >>> Hi Jeremy, >>> >>> On 30/07/2015 6:34 AM, Jeremy Manson wrote: >>> >>>> David, can you review/sponsor this, per our conversation of last week? >>>> >>> >>> Yes I can sponsor and it is also Reviewed. >>> >>> But I'd like a second review from someone else. >>> >>> Thanks, >>> David >>> >>> It fixes an issue where, on Linux, some of the Hotspot logging output >>>> identifies threads by pthread_id, and some of it identifies threads by >>>> kernel-level TID. This happened because Hotspot calls into two >>>> different APIs that provide the thread ID, and developers seem to have >>>> picked which one they call at random. >>>> >>>> The CR makes these APIs consistently use the kernel-level TID, and makes >>>> one of the APIs a thin shim over the other. >>>> >>>> Conversation: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015507.html >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6661889 >>>> Webrev: http://cr.openjdk.java.net/~jmanson/6661889/webrev.01/ >>>> >>>> Jeremy >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.lagneau at oracle.com Thu Jul 30 16:55:13 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Thu, 30 Jul 2015 18:55:13 +0200 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis Message-ID: <55BA56F1.8020405@oracle.com> Hi, Could you please review this fix: bug: https://bugs.openjdk.java.net/browse/JDK-8131784 webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ We add tracing information to help diagnosing master bug problem (https://bugs.openjdk.java.net/browse/JDK-8130339), and we will monitor the quarantined runs to check for any failure and get more diagnosis info. Since the test already provides some information which is not collected when it fails with timeout, the idea is to collect subprocess I/O (stdout, stderr) by using ProcessTools.startProcess rather that OutputAnalyzer.executeProcess. The subprocess I/Os will be collected while it's running rather than waiting the subprocess termination. A few additional infos have also been added to get more information. Note that this "tracing" change should be temporary and will be removed when a fix for 8130339 has been found. Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Jul 30 17:13:38 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 30 Jul 2015 19:13:38 +0200 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis In-Reply-To: <55BA56F1.8020405@oracle.com> References: <55BA56F1.8020405@oracle.com> Message-ID: <55BA5B42.8060301@oracle.com> Hi Olivier, On 30.7.2015 18:55, olivier.lagneau at oracle.com wrote: > Hi, > > Could you please review this fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8131784 > webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ > > We add tracing information to help diagnosing master bug problem > (https://bugs.openjdk.java.net/browse/JDK-8130339), > and we will monitor the quarantined runs to check for any failure and > get more diagnosis info. > > Since the test already provides some information which is not collected > when it fails with timeout, > the idea is to collect subprocess I/O (stdout, stderr) by using > ProcessTools.startProcess rather > that OutputAnalyzer.executeProcess. The subprocess I/Os will be > collected while it's running > rather than waiting the subprocess termination. > > A few additional infos have also been added to get more information. > > Note that this "tracing" change should be temporary and will be removed > when a fix for 8130339 has been found. Instead of `ProcessTools.startProcess(prefixName, pb, (l) -> {return true;} );` at line 132 you can do `ProcessTools.startProcess(prefixName, pb, null);`. It will have the same effect. Why is that 2 seconds sleep necessary at line 135? L373 and L384 - better use 'SweeperThread' instead of 'SweepThread' to correspond to the class name. -JB- > > Thanks, > Olivier. > From serguei.spitsyn at oracle.com Thu Jul 30 23:50:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Jul 2015 16:50:54 -0700 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis In-Reply-To: <55BA56F1.8020405@oracle.com> References: <55BA56F1.8020405@oracle.com> Message-ID: <55BAB85E.2050906@oracle.com> Hi Olivier, I agree with the comments from Jaroslav. A couple of minor comments. + if ( exitCode != 0 ) { Unneeded extra spaces + } catch (InterruptedException e) { + Thread.currentThread().interrupt(); + throw new RuntimeException("Parent process interrupted with exception : \n " + e); + } + Why a call to interrupt() is needed? I'd suggest to add a call e.printStackTrace(). Otherwise, it looks good. Thanks, Serguei On 7/30/15 9:55 AM, olivier.lagneau at oracle.com wrote: > Hi, > > Could you please review this fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8131784 > webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ > > We add tracing information to help diagnosing master bug problem > (https://bugs.openjdk.java.net/browse/JDK-8130339), > and we will monitor the quarantined runs to check for any failure and > get more diagnosis info. > > Since the test already provides some information which is not > collected when it fails with timeout, > the idea is to collect subprocess I/O (stdout, stderr) by using > ProcessTools.startProcess rather > that OutputAnalyzer.executeProcess. The subprocess I/Os will be > collected while it's running > rather than waiting the subprocess termination. > > A few additional infos have also been added to get more information. > > Note that this "tracing" change should be temporary and will be > removed when a fix for 8130339 has been found. > > Thanks, > Olivier. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Jul 31 11:55:01 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 31 Jul 2015 13:55:01 +0200 Subject: [PING] Re: RFR 8129976: RunFinalizationTest.java times out frequently In-Reply-To: <559EA52F.7000507@oracle.com> References: <559EA52F.7000507@oracle.com> Message-ID: <55BB6215.2040102@oracle.com> Could someone, please, take a look at this? Thanks, -JB- On 9.7.2015 18:45, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8129976 > Webrev: http://cr.openjdk.java.net/~jbachorik/8129976/webrev.00 > > The test, as it is now, most of the times does not test the desired > functionality (that invoking GC.run_finalization DCMD actually runs > finalization) because the preceding call to System.gc() will finalize > the test object sooner. But without calling System.gc() it is non > predictable when the test object will be eligible for finalization so we > have to call System.gc(). > > In the rare occasions when System.gc() induced finalization does not > finish before invoking GC.run_finalization the test deadlocks because > its locking logic is flawed. > > In order to make this test work I had to: > a\ Switch from '@run testng' to '@run main/othervm' > b\ Run the finalization testing code in shutdown handler - this seems to > prevent the finalization happening prematurely after calling System.gc() > while still making the test object eligible for finalization > c\ Switch from ReentrantLock to a Phaser for synchronization > d\ Make sure that the finalization is not carried out on the default > "Finalizer" thread to rule out finalization due to System.gc() > > After these changes the test seems to be rather stable (ran 1000 > iterations in a tight loop without single failure). > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Fri Jul 31 11:56:53 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 31 Jul 2015 13:56:53 +0200 Subject: [PING] Re: RFR 8129215: com.sun.jmx.mbeanserver.Introspector may provide results inconsistent with the JavaBeans Introspector In-Reply-To: <55844162.1040108@oracle.com> References: <5582F444.1090108@oracle.com> <5582F604.60909@oracle.com> <5582FCEF.3010000@oracle.com> <55833FF1.7020007@oracle.com> <5583E743.1090006@oracle.com> <5583EDB3.9010105@oracle.com> <5583FF1D.80003@oracle.com> <55840097.7040309@oracle.com> <55840573.7000103@oracle.com> <55841E17.2070001@oracle.com> <55844162.1040108@oracle.com> Message-ID: <55BB6285.7090303@oracle.com> On 19.6.2015 18:20, Jaroslav Bachorik wrote: > On 19.6.2015 15:50, Daniel Fuchs wrote: >> Hi guys, >> >> I believe there's a difference between Attribute names, and navigation >> into complex attributes. >> >> At the MBean level attribute names are case sensitive. >> At Attribute level (= within an attribute) I believe it follows >> the Bean patterns (like for instance the mapping of complex >> MXBean attribute types to CompositeData). >> A property of an Attribute (as in MemoryUsage.used) is not itself >> an Attribute - but a bean property. >> >> A careful reading of the JMX 1.4 spec should hopefully make it possible >> to validate that ;-) > > Also, some JCK tests are relying on the Attribute properties being > treated as JavaBean properties. These were, in fact, the ones triggering > this issue when run without j.b.Introspector being available. > > So, if I understand it correctly, with my fix the implementation will be > in agreement with the spec again even when j.b.Introspector is not > available. Could we get this wrapped, please? The change is not introducing any new behaviour - it just makes the SimpleIntrospector (being used when j.b.Introspector is not available) to behave accordingly to the spec. -JB- > > -JB- > >> >> cheers, >> >> -- daniel >> >> On 19/06/15 14:05, Jaroslav Bachorik wrote: >>> On 19.6.2015 13:44, Alan Bateman wrote: >>>> >>>> On 19/06/2015 12:38, Jaroslav Bachorik wrote: >>>>> >>>>> Both the j.b.Introspector.getReadMethod() and the >>>>> SimpleIntrospector.getReadMethod() are used only from >>>>> c.s.j.m.Introspector.elementFromComplex() method and only to resolve >>>>> the getter for a complex attribute. >>>>> >>>>> So, any change in the SimpleIntrospector will not affect the rest of >>>>> the JMX system. >>>>> >>>>> Given this statement in the Monitoring javadocs >>>>> (https://docs.oracle.com/javase/8/docs/api/javax/management/monitor/package-summary.html) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> "If the above rules do not produce a value, and if introspection, as >>>>> if by calling Introspector.getBeanInfo, for the class of v >>>>> (v.getClass()) identifies a property with the name e, then x is the >>>>> result of reading the property value." >>>>> >>>>> I would strongly propose to adjust the SimpleIntrospector to closely >>>>> follow the j.b.Introspector functionality. >>>>> >>>> I added the SimpleIntrospector and also adjusted the above wording in >>>> the monitor package description to make it possible to have JMX in a >>>> compact Profile of Java SE that didn't have java.beans. >>>> >>>> The intention was that the SimpleIntrospector works like the beans >>>> Introspector. So I agree this is the right thing to do but we should >>>> create a bug for the issue that Daniel brings up. >>> >>> I'm not sure there is an issue here. The monitoring api attribute names >>> seem to be governed by different rules than the MBean attribute names. >>> This change relates to the monitoring api only and brings the >>> implementation up to the what is specified in the javadoc. >>> >>> -JB- >>> >>>> >>>> -Alan. >>> >> > From serguei.spitsyn at oracle.com Fri Jul 31 12:56:49 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 Jul 2015 05:56:49 -0700 Subject: [PING] Re: RFR 8129976: RunFinalizationTest.java times out frequently In-Reply-To: <55BB6215.2040102@oracle.com> References: <559EA52F.7000507@oracle.com> <55BB6215.2040102@oracle.com> Message-ID: <55BB7091.1060001@oracle.com> The fix looks good to me. Nice that it does not fail in 1000 runs. Thanks, Serguei On 7/31/15 4:55 AM, Jaroslav Bachorik wrote: > Could someone, please, take a look at this? > > Thanks, > > -JB- > > On 9.7.2015 18:45, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8129976 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8129976/webrev.00 >> >> The test, as it is now, most of the times does not test the desired >> functionality (that invoking GC.run_finalization DCMD actually runs >> finalization) because the preceding call to System.gc() will finalize >> the test object sooner. But without calling System.gc() it is non >> predictable when the test object will be eligible for finalization so we >> have to call System.gc(). >> >> In the rare occasions when System.gc() induced finalization does not >> finish before invoking GC.run_finalization the test deadlocks because >> its locking logic is flawed. >> >> In order to make this test work I had to: >> a\ Switch from '@run testng' to '@run main/othervm' >> b\ Run the finalization testing code in shutdown handler - this seems to >> prevent the finalization happening prematurely after calling System.gc() >> while still making the test object eligible for finalization >> c\ Switch from ReentrantLock to a Phaser for synchronization >> d\ Make sure that the finalization is not carried out on the default >> "Finalizer" thread to rule out finalization due to System.gc() >> >> After these changes the test seems to be rather stable (ran 1000 >> iterations in a tight loop without single failure). >> >> Thanks, >> >> -JB- > From daniel.fuchs at oracle.com Fri Jul 31 13:03:20 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 31 Jul 2015 15:03:20 +0200 Subject: [PING] Re: RFR 8129215: com.sun.jmx.mbeanserver.Introspector may provide results inconsistent with the JavaBeans Introspector In-Reply-To: <55BB6285.7090303@oracle.com> References: <5582F444.1090108@oracle.com> <5582F604.60909@oracle.com> <5582FCEF.3010000@oracle.com> <55833FF1.7020007@oracle.com> <5583E743.1090006@oracle.com> <5583EDB3.9010105@oracle.com> <5583FF1D.80003@oracle.com> <55840097.7040309@oracle.com> <55840573.7000103@oracle.com> <55841E17.2070001@oracle.com> <55844162.1040108@oracle.com> <55BB6285.7090303@oracle.com> Message-ID: <55BB7218.2040003@oracle.com> Hi Jaroslav, Thanks for the ping, I hadn't realized you were waiting :-) Since this is limited to complex composite attribute names I believe it is the right thing. However - it would be good to verify (maybe you already did it?) that it passes the JCK. One small suggestion for the SimpleIntrospectorTest: I find the logic of the checkGetter difficult to follow - I believe it would be easier for future maintainers if that method had a parameter called "nullExpected" rather than "reverse". Otherwise, this looks good! best regards, -- daniel On 31/07/15 13:56, Jaroslav Bachorik wrote: > On 19.6.2015 18:20, Jaroslav Bachorik wrote: >> On 19.6.2015 15:50, Daniel Fuchs wrote: >>> Hi guys, >>> >>> I believe there's a difference between Attribute names, and navigation >>> into complex attributes. >>> >>> At the MBean level attribute names are case sensitive. >>> At Attribute level (= within an attribute) I believe it follows >>> the Bean patterns (like for instance the mapping of complex >>> MXBean attribute types to CompositeData). >>> A property of an Attribute (as in MemoryUsage.used) is not itself >>> an Attribute - but a bean property. >>> >>> A careful reading of the JMX 1.4 spec should hopefully make it possible >>> to validate that ;-) >> >> Also, some JCK tests are relying on the Attribute properties being >> treated as JavaBean properties. These were, in fact, the ones triggering >> this issue when run without j.b.Introspector being available. >> >> So, if I understand it correctly, with my fix the implementation will be >> in agreement with the spec again even when j.b.Introspector is not >> available. > > Could we get this wrapped, please? > The change is not introducing any new behaviour - it just makes the > SimpleIntrospector (being used when j.b.Introspector is not available) > to behave accordingly to the spec. > > -JB- > >> >> -JB- >> >>> >>> cheers, >>> >>> -- daniel >>> >>> On 19/06/15 14:05, Jaroslav Bachorik wrote: >>>> On 19.6.2015 13:44, Alan Bateman wrote: >>>>> >>>>> On 19/06/2015 12:38, Jaroslav Bachorik wrote: >>>>>> >>>>>> Both the j.b.Introspector.getReadMethod() and the >>>>>> SimpleIntrospector.getReadMethod() are used only from >>>>>> c.s.j.m.Introspector.elementFromComplex() method and only to resolve >>>>>> the getter for a complex attribute. >>>>>> >>>>>> So, any change in the SimpleIntrospector will not affect the rest of >>>>>> the JMX system. >>>>>> >>>>>> Given this statement in the Monitoring javadocs >>>>>> (https://docs.oracle.com/javase/8/docs/api/javax/management/monitor/package-summary.html) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> "If the above rules do not produce a value, and if introspection, as >>>>>> if by calling Introspector.getBeanInfo, for the class of v >>>>>> (v.getClass()) identifies a property with the name e, then x is the >>>>>> result of reading the property value." >>>>>> >>>>>> I would strongly propose to adjust the SimpleIntrospector to closely >>>>>> follow the j.b.Introspector functionality. >>>>>> >>>>> I added the SimpleIntrospector and also adjusted the above wording in >>>>> the monitor package description to make it possible to have JMX in a >>>>> compact Profile of Java SE that didn't have java.beans. >>>>> >>>>> The intention was that the SimpleIntrospector works like the beans >>>>> Introspector. So I agree this is the right thing to do but we should >>>>> create a bug for the issue that Daniel brings up. >>>> >>>> I'm not sure there is an issue here. The monitoring api attribute names >>>> seem to be governed by different rules than the MBean attribute names. >>>> This change relates to the monitoring api only and brings the >>>> implementation up to the what is specified in the javadoc. >>>> >>>> -JB- >>>> >>>>> >>>>> -Alan. >>>> >>> >> > From jaroslav.bachorik at oracle.com Fri Jul 31 13:17:56 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 31 Jul 2015 15:17:56 +0200 Subject: [PING] Re: RFR 8129215: com.sun.jmx.mbeanserver.Introspector may provide results inconsistent with the JavaBeans Introspector In-Reply-To: <55BB7218.2040003@oracle.com> References: <5582F444.1090108@oracle.com> <5582F604.60909@oracle.com> <5582FCEF.3010000@oracle.com> <55833FF1.7020007@oracle.com> <5583E743.1090006@oracle.com> <5583EDB3.9010105@oracle.com> <5583FF1D.80003@oracle.com> <55840097.7040309@oracle.com> <55840573.7000103@oracle.com> <55841E17.2070001@oracle.com> <55844162.1040108@oracle.com> <55BB6285.7090303@oracle.com> <55BB7218.2040003@oracle.com> Message-ID: <55BB7584.2050700@oracle.com> On 31.7.2015 15:03, Daniel Fuchs wrote: > Hi Jaroslav, > > Thanks for the ping, I hadn't realized you were waiting :-) > > Since this is limited to complex composite attribute names > I believe it is the right thing. However - it would be good > to verify (maybe you already did it?) that it passes the JCK. actually, JCK tests are failing without this change (one of the comments in the issue) > > One small suggestion for the SimpleIntrospectorTest: I find > the logic of the checkGetter difficult to follow - I believe it > would be easier for future maintainers if that method had a > parameter called "nullExpected" rather than "reverse". ok. Thanks! -JB- > > Otherwise, this looks good! > > best regards, > > -- daniel > > > On 31/07/15 13:56, Jaroslav Bachorik wrote: >> On 19.6.2015 18:20, Jaroslav Bachorik wrote: >>> On 19.6.2015 15:50, Daniel Fuchs wrote: >>>> Hi guys, >>>> >>>> I believe there's a difference between Attribute names, and navigation >>>> into complex attributes. >>>> >>>> At the MBean level attribute names are case sensitive. >>>> At Attribute level (= within an attribute) I believe it follows >>>> the Bean patterns (like for instance the mapping of complex >>>> MXBean attribute types to CompositeData). >>>> A property of an Attribute (as in MemoryUsage.used) is not itself >>>> an Attribute - but a bean property. >>>> >>>> A careful reading of the JMX 1.4 spec should hopefully make it possible >>>> to validate that ;-) >>> >>> Also, some JCK tests are relying on the Attribute properties being >>> treated as JavaBean properties. These were, in fact, the ones triggering >>> this issue when run without j.b.Introspector being available. >>> >>> So, if I understand it correctly, with my fix the implementation will be >>> in agreement with the spec again even when j.b.Introspector is not >>> available. >> >> Could we get this wrapped, please? >> The change is not introducing any new behaviour - it just makes the >> SimpleIntrospector (being used when j.b.Introspector is not available) >> to behave accordingly to the spec. >> >> -JB- >> >>> >>> -JB- >>> >>>> >>>> cheers, >>>> >>>> -- daniel >>>> >>>> On 19/06/15 14:05, Jaroslav Bachorik wrote: >>>>> On 19.6.2015 13:44, Alan Bateman wrote: >>>>>> >>>>>> On 19/06/2015 12:38, Jaroslav Bachorik wrote: >>>>>>> >>>>>>> Both the j.b.Introspector.getReadMethod() and the >>>>>>> SimpleIntrospector.getReadMethod() are used only from >>>>>>> c.s.j.m.Introspector.elementFromComplex() method and only to resolve >>>>>>> the getter for a complex attribute. >>>>>>> >>>>>>> So, any change in the SimpleIntrospector will not affect the rest of >>>>>>> the JMX system. >>>>>>> >>>>>>> Given this statement in the Monitoring javadocs >>>>>>> (https://docs.oracle.com/javase/8/docs/api/javax/management/monitor/package-summary.html) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> "If the above rules do not produce a value, and if introspection, as >>>>>>> if by calling Introspector.getBeanInfo, for the class of v >>>>>>> (v.getClass()) identifies a property with the name e, then x is the >>>>>>> result of reading the property value." >>>>>>> >>>>>>> I would strongly propose to adjust the SimpleIntrospector to closely >>>>>>> follow the j.b.Introspector functionality. >>>>>>> >>>>>> I added the SimpleIntrospector and also adjusted the above wording in >>>>>> the monitor package description to make it possible to have JMX in a >>>>>> compact Profile of Java SE that didn't have java.beans. >>>>>> >>>>>> The intention was that the SimpleIntrospector works like the beans >>>>>> Introspector. So I agree this is the right thing to do but we should >>>>>> create a bug for the issue that Daniel brings up. >>>>> >>>>> I'm not sure there is an issue here. The monitoring api attribute >>>>> names >>>>> seem to be governed by different rules than the MBean attribute names. >>>>> This change relates to the monitoring api only and brings the >>>>> implementation up to the what is specified in the javadoc. >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> -Alan. >>>>> >>>> >>> >> > From olivier.lagneau at oracle.com Fri Jul 31 16:07:55 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Fri, 31 Jul 2015 18:07:55 +0200 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis In-Reply-To: <55BA5B42.8060301@oracle.com> References: <55BA56F1.8020405@oracle.com> <55BA5B42.8060301@oracle.com> Message-ID: <55BB9D5B.2020600@oracle.com> Hi Jaroslav, Thanks for reviewing this fix. Comments inlined. Olivier. On 30/07/2015 19:13, Jaroslav Bachorik wrote: > Hi Olivier, > > On 30.7.2015 18:55, olivier.lagneau at oracle.com wrote: >> Hi, >> >> Could you please review this fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8131784 >> webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ >> >> We add tracing information to help diagnosing master bug problem >> (https://bugs.openjdk.java.net/browse/JDK-8130339), >> and we will monitor the quarantined runs to check for any failure and >> get more diagnosis info. >> >> Since the test already provides some information which is not collected >> when it fails with timeout, >> the idea is to collect subprocess I/O (stdout, stderr) by using >> ProcessTools.startProcess rather >> that OutputAnalyzer.executeProcess. The subprocess I/Os will be >> collected while it's running >> rather than waiting the subprocess termination. >> >> A few additional infos have also been added to get more information. >> >> Note that this "tracing" change should be temporary and will be removed >> when a fix for 8130339 has been found. > > Instead of `ProcessTools.startProcess(prefixName, pb, (l) -> {return > true;} );` at line 132 you can do > `ProcessTools.startProcess(prefixName, pb, null);`. It will have the > same effect. This needs to be casted : "ProcessTools.startProcess(prefixName, pb, (Consumer) null)", but then it's identical to startProcess(prefixName, pb) call available in ProcessTools. I tried that first a few days ago and that did not work (could not find reason), thus explored others possibilities and "(l) -> {return true;}" worked. Thus kept that. Retried today and StartProcess(prefixName, pb) worked ! So moving back to that. > > Why is that 2 seconds sleep necessary at line 135? A few days ago I got intertwined output messages coming from subprocesses (like a serialGC message in the middle of ParallelGC messages). Having this sleep solved these mixed messages. Anyway tried again today without the sleep call lot of times and did not get this mix. Thus suppressing this sleep. > > L373 and L384 - better use 'SweeperThread' instead of 'SweepThread' to > correspond to the class name. Already existing messages where using SweepThread. Kept that spelling (even if unhappy with that). But right It's better using SweeperThread. Changing it. > > -JB- > >> >> Thanks, >> Olivier. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.lagneau at oracle.com Fri Jul 31 16:21:38 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Fri, 31 Jul 2015 18:21:38 +0200 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis In-Reply-To: <55BAB85E.2050906@oracle.com> References: <55BA56F1.8020405@oracle.com> <55BAB85E.2050906@oracle.com> Message-ID: <55BBA092.6060008@oracle.com> Hi Serguey, Thanks for reviewing. Please see comments inlined. On 31/07/2015 01:50, serguei.spitsyn at oracle.com wrote: > Hi Olivier, > > I agree with the comments from Jaroslav. > A couple of minor comments. > + if ( exitCode != 0 ) { > Unneeded extra spaces Ok. fixed. > > > > + } catch (InterruptedException e) { > + Thread.currentThread().interrupt(); > + throw new RuntimeException("Parent process interrupted with > exception : \n " + e); > + } > + > Why a call to interrupt() is needed? Sorry. This is a mistake. Removing it. > I'd suggest to add a call e.printStackTrace(). In case of such failure JTREG/JPRT already prints the stack strace. So currently the output will look like this in case of failure : " java.lang.RuntimeException: Parent process interrupted with exception : java.lang.InterruptedException : at LowMemoryTest.traceTest(LowMemoryTest.java:143) at LowMemoryTest.main(LowMemoryTest.java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:504) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) at java.lang.Thread.run(Thread.java:746) " Which I find more readable. > > Otherwise, it looks good. > > Thanks, > Serguei > > > On 7/30/15 9:55 AM, olivier.lagneau at oracle.com wrote: >> Hi, >> >> Could you please review this fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8131784 >> webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ >> >> We add tracing information to help diagnosing master bug problem >> (https://bugs.openjdk.java.net/browse/JDK-8130339), >> and we will monitor the quarantined runs to check for any failure and >> get more diagnosis info. >> >> Since the test already provides some information which is not >> collected when it fails with timeout, >> the idea is to collect subprocess I/O (stdout, stderr) by using >> ProcessTools.startProcess rather >> that OutputAnalyzer.executeProcess. The subprocess I/Os will be >> collected while it's running >> rather than waiting the subprocess termination. >> >> A few additional infos have also been added to get more information. >> >> Note that this "tracing" change should be temporary and will be >> removed when a fix for 8130339 has been found. >> >> Thanks, >> Olivier. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.lagneau at oracle.com Fri Jul 31 16:44:40 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Fri, 31 Jul 2015 18:44:40 +0200 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis In-Reply-To: <55BA56F1.8020405@oracle.com> References: <55BA56F1.8020405@oracle.com> Message-ID: <55BBA5F8.7090902@oracle.com> Thanks Jaroslav and Serguey for the comments for first pass of review. I have fixed the patch following your comments. Please find the 2nd version here : webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.01/ Thanks, Olivier. On 30/07/2015 18:55, olivier.lagneau at oracle.com wrote: > Hi, > > Could you please review this fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8131784 > webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ > > We add tracing information to help diagnosing master bug problem > (https://bugs.openjdk.java.net/browse/JDK-8130339), > and we will monitor the quarantined runs to check for any failure and > get more diagnosis info. > > Since the test already provides some information which is not > collected when it fails with timeout, > the idea is to collect subprocess I/O (stdout, stderr) by using > ProcessTools.startProcess rather > that OutputAnalyzer.executeProcess. The subprocess I/Os will be > collected while it's running > rather than waiting the subprocess termination. > > A few additional infos have also been added to get more information. > > Note that this "tracing" change should be temporary and will be > removed when a fix for 8130339 has been found. > > Thanks, > Olivier. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jul 31 16:58:09 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 Jul 2015 09:58:09 -0700 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis In-Reply-To: <55BBA092.6060008@oracle.com> References: <55BA56F1.8020405@oracle.com> <55BAB85E.2050906@oracle.com> <55BBA092.6060008@oracle.com> Message-ID: <55BBA921.9010305@oracle.com> Hi Olivier, Ok, reviewed. Thank you for the update! Serguei On 7/31/15 9:21 AM, olivier.lagneau at oracle.com wrote: > Hi Serguey, > > Thanks for reviewing. Please see comments inlined. > > On 31/07/2015 01:50, serguei.spitsyn at oracle.com wrote: >> Hi Olivier, >> >> I agree with the comments from Jaroslav. >> A couple of minor comments. >> + if ( exitCode != 0 ) { >> Unneeded extra spaces > Ok. fixed. >> >> >> >> + } catch (InterruptedException e) { >> + Thread.currentThread().interrupt(); >> + throw new RuntimeException("Parent process interrupted with exception : \n " + e); >> + } >> + >> Why a call to interrupt() is needed? > Sorry. This is a mistake. Removing it. >> I'd suggest to add a call e.printStackTrace(). > In case of such failure JTREG/JPRT already prints the stack strace. > So currently the output will look like this in case of failure : > " > java.lang.RuntimeException: Parent process interrupted with exception : > java.lang.InterruptedException : > at LowMemoryTest.traceTest(LowMemoryTest.java:143) > at LowMemoryTest.main(LowMemoryTest.java:82) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:504) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) > at java.lang.Thread.run(Thread.java:746) > " > > Which I find more readable. > > >> >> Otherwise, it looks good. >> >> Thanks, >> Serguei >> >> >> On 7/30/15 9:55 AM, olivier.lagneau at oracle.com wrote: >>> Hi, >>> >>> Could you please review this fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8131784 >>> webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ >>> >>> We add tracing information to help diagnosing master bug problem >>> (https://bugs.openjdk.java.net/browse/JDK-8130339), >>> and we will monitor the quarantined runs to check for any failure >>> and get more diagnosis info. >>> >>> Since the test already provides some information which is not >>> collected when it fails with timeout, >>> the idea is to collect subprocess I/O (stdout, stderr) by using >>> ProcessTools.startProcess rather >>> that OutputAnalyzer.executeProcess. The subprocess I/Os will be >>> collected while it's running >>> rather than waiting the subprocess termination. >>> >>> A few additional infos have also been added to get more information. >>> >>> Note that this "tracing" change should be temporary and will be >>> removed when a fix for 8130339 has been found. >>> >>> Thanks, >>> Olivier. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jul 31 17:02:53 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 Jul 2015 10:02:53 -0700 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis In-Reply-To: <55BBA5F8.7090902@oracle.com> References: <55BA56F1.8020405@oracle.com> <55BBA5F8.7090902@oracle.com> Message-ID: <55BBAA3D.3040405@oracle.com> Looks good. Thanks, Serguei On 7/31/15 9:44 AM, olivier.lagneau at oracle.com wrote: > Thanks Jaroslav and Serguey for the comments for first pass of review. > > I have fixed the patch following your comments. > > Please find the 2nd version here : > webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.01/ > > Thanks, > Olivier. > > On 30/07/2015 18:55, olivier.lagneau at oracle.com wrote: >> Hi, >> >> Could you please review this fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8131784 >> webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ >> >> We add tracing information to help diagnosing master bug problem >> (https://bugs.openjdk.java.net/browse/JDK-8130339), >> and we will monitor the quarantined runs to check for any failure and >> get more diagnosis info. >> >> Since the test already provides some information which is not >> collected when it fails with timeout, >> the idea is to collect subprocess I/O (stdout, stderr) by using >> ProcessTools.startProcess rather >> that OutputAnalyzer.executeProcess. The subprocess I/Os will be >> collected while it's running >> rather than waiting the subprocess termination. >> >> A few additional infos have also been added to get more information. >> >> Note that this "tracing" change should be temporary and will be >> removed when a fix for 8130339 has been found. >> >> Thanks, >> Olivier. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Jul 31 17:10:07 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 31 Jul 2015 19:10:07 +0200 Subject: RFR: JDK-8131784 : Add tracing info to LowMemoryTest.java to help 8130339 diagnosis In-Reply-To: <55BBA5F8.7090902@oracle.com> References: <55BA56F1.8020405@oracle.com> <55BBA5F8.7090902@oracle.com> Message-ID: <55BBABEF.2080900@oracle.com> Good to go! -JB- On 31.7.2015 18:44, olivier.lagneau at oracle.com wrote: > Thanks Jaroslav and Serguey for the comments for first pass of review. > > I have fixed the patch following your comments. > > Please find the 2nd version here : > webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.01/ > > Thanks, > Olivier. > > On 30/07/2015 18:55, olivier.lagneau at oracle.com wrote: >> Hi, >> >> Could you please review this fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8131784 >> webrev: http://cr.openjdk.java.net/~olagneau/8131784/webrev.00/ >> >> We add tracing information to help diagnosing master bug problem >> (https://bugs.openjdk.java.net/browse/JDK-8130339), >> and we will monitor the quarantined runs to check for any failure and >> get more diagnosis info. >> >> Since the test already provides some information which is not >> collected when it fails with timeout, >> the idea is to collect subprocess I/O (stdout, stderr) by using >> ProcessTools.startProcess rather >> that OutputAnalyzer.executeProcess. The subprocess I/Os will be >> collected while it's running >> rather than waiting the subprocess termination. >> >> A few additional infos have also been added to get more information. >> >> Note that this "tracing" change should be temporary and will be >> removed when a fix for 8130339 has been found. >> >> Thanks, >> Olivier. >> >