From serguei.spitsyn at oracle.com Sat Jun 1 03:59:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 May 2019 20:59:51 -0700 Subject: RFC (csr): 8225142: JVMTI spec incorrectly states that PopFrame can not be called on the current thread Message-ID: <4a2c2db1-74df-2e7f-0e36-69e96965e676@oracle.com> Hi All, Please comment or.and review the following CSR. The CSR: ? https://bugs.openjdk.java.net/browse/JDK-8225142 The bug: ? https://bugs.openjdk.java.net/browse/JDK-8205126 Updated JVMTI spec: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti.html Specdiff: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ Summary: ? The JVMTI PopFrame() spec does not match the implementation. ? It says the? specified thread can not be the current thread. ? The fix aligns: ?? - spec with implementaion ?? - PopFrame spec with ForceEarlyReturn spec Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Jun 1 04:47:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 1 Jun 2019 14:47:51 +1000 Subject: RFC (csr): 8225142: JVMTI spec incorrectly states that PopFrame can not be called on the current thread In-Reply-To: <4a2c2db1-74df-2e7f-0e36-69e96965e676@oracle.com> References: <4a2c2db1-74df-2e7f-0e36-69e96965e676@oracle.com> Message-ID: <2b470401-dcd6-f4b7-6dbc-83c3da907d39@oracle.com> Hi Serguei, Sorry but I'm rather confused - what does it mean to do a "popframe" on the current thread? The whole point of popframe is to suspend a target thread when it is executing a specific method, and then call popframe to "back up" the thread to the point where it will call that method again when resumed. How does that work with the current thread? Thanks, David On 1/06/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: > Hi All, > > Please comment or.and review the following CSR. > > The CSR: > https://bugs.openjdk.java.net/browse/JDK-8225142 > > The bug: > https://bugs.openjdk.java.net/browse/JDK-8205126 > > Updated JVMTI spec: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti.html > > > Specdiff: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ > > > Summary: > ? The JVMTI PopFrame() spec does not match the implementation. > ? It says the? specified thread can not be the current thread. > ? The fix aligns: > ?? - spec with implementaion > ?? - PopFrame spec with ForceEarlyReturn spec > > Thanks, > Serguei From serguei.spitsyn at oracle.com Sat Jun 1 05:09:10 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 May 2019 22:09:10 -0700 Subject: RFC (csr): 8225142: JVMTI spec incorrectly states that PopFrame can not be called on the current thread In-Reply-To: <2b470401-dcd6-f4b7-6dbc-83c3da907d39@oracle.com> References: <4a2c2db1-74df-2e7f-0e36-69e96965e676@oracle.com> <2b470401-dcd6-f4b7-6dbc-83c3da907d39@oracle.com> Message-ID: <4f3975db-013c-04dd-c16d-86584e28ca50@oracle.com> Hi David, Thank you for looking at it! On 5/31/19 9:47 PM, David Holmes wrote: > Hi Serguei, > > Sorry but I'm rather confused - what does it mean to do a "popframe" > on the current thread? I was confused too. We have several JVMTI tests that calls PopFrame in event callbacks. ?For instance (see also: popframe006, popframe007, popframe008): ?? test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010 This test gets a breakpoint event and in the callback: ?- clears the breakpoint ?- enables single stepping ?- calls the PopFrame This seems to be working. > The whole point of popframe is to suspend a target thread when it is > executing a specific method, and then call popframe to "back up" the > thread to the point where it will call that method again when resumed. > How does that work with the current thread? Probably, the most interesting question is: ?How will the target thread continue its execution? As I understand, it will be single stepping. In such a case, the thread is executed in the interp-only mode. Thanks, Serguei > > Thanks, > David > > On 1/06/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >> Hi All, >> >> Please comment or.and review the following CSR. >> >> The CSR: >> https://bugs.openjdk.java.net/browse/JDK-8225142 >> >> The bug: >> https://bugs.openjdk.java.net/browse/JDK-8205126 >> >> Updated JVMTI spec: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti.html >> >> >> >> Specdiff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >> >> >> >> Summary: >> ?? The JVMTI PopFrame() spec does not match the implementation. >> ?? It says the? specified thread can not be the current thread. >> ?? The fix aligns: >> ??? - spec with implementaion >> ??? - PopFrame spec with ForceEarlyReturn spec >> >> Thanks, >> Serguei From david.holmes at oracle.com Sat Jun 1 05:43:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 1 Jun 2019 15:43:35 +1000 Subject: RFC (csr): 8225142: JVMTI spec incorrectly states that PopFrame can not be called on the current thread In-Reply-To: <4f3975db-013c-04dd-c16d-86584e28ca50@oracle.com> References: <4a2c2db1-74df-2e7f-0e36-69e96965e676@oracle.com> <2b470401-dcd6-f4b7-6dbc-83c3da907d39@oracle.com> <4f3975db-013c-04dd-c16d-86584e28ca50@oracle.com> Message-ID: <4cbf4b38-bb6a-7a92-f45c-b5e8921a73a0@oracle.com> On 1/06/2019 3:09 pm, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you for looking at it! > > > On 5/31/19 9:47 PM, David Holmes wrote: >> Hi Serguei, >> >> Sorry but I'm rather confused - what does it mean to do a "popframe" >> on the current thread? > > I was confused too. > We have several JVMTI tests that calls PopFrame in event callbacks. > ?For instance (see also: popframe006, popframe007, popframe008): > ?? test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010 > > This test gets a breakpoint event and in the callback: > ?- clears the breakpoint > ?- enables single stepping > ?- calls the PopFrame > > This seems to be working. Okay that makes sense. I hadn't thought about callbacks executing in the current thread and causing it to back itself up. >> The whole point of popframe is to suspend a target thread when it is >> executing a specific method, and then call popframe to "back up" the >> thread to the point where it will call that method again when resumed. >> How does that work with the current thread? > > Probably, the most interesting question is: > ?How will the target thread continue its execution? > > As I understand, it will be single stepping. I would hope so in the scenario you describe. But presumably the callback could just clear the breakpoint and do a popframe and so execution would continue as before? Cheers, David ------ > In such a case, the thread is executed in the interp-only mode. > > Thanks, > Serguei > >> >> Thanks, >> David >> >> On 1/06/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>> Hi All, >>> >>> Please comment or.and review the following CSR. >>> >>> The CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8225142 >>> >>> The bug: >>> https://bugs.openjdk.java.net/browse/JDK-8205126 >>> >>> Updated JVMTI spec: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti.html >>> >>> >>> >>> Specdiff: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >>> >>> >>> >>> Summary: >>> ?? The JVMTI PopFrame() spec does not match the implementation. >>> ?? It says the? specified thread can not be the current thread. >>> ?? The fix aligns: >>> ??? - spec with implementaion >>> ??? - PopFrame spec with ForceEarlyReturn spec >>> >>> Thanks, >>> Serguei > From serguei.spitsyn at oracle.com Sat Jun 1 06:15:24 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 May 2019 23:15:24 -0700 Subject: RFC (csr): 8225142: JVMTI spec incorrectly states that PopFrame can not be called on the current thread In-Reply-To: <4cbf4b38-bb6a-7a92-f45c-b5e8921a73a0@oracle.com> References: <4a2c2db1-74df-2e7f-0e36-69e96965e676@oracle.com> <2b470401-dcd6-f4b7-6dbc-83c3da907d39@oracle.com> <4f3975db-013c-04dd-c16d-86584e28ca50@oracle.com> <4cbf4b38-bb6a-7a92-f45c-b5e8921a73a0@oracle.com> Message-ID: On 5/31/19 22:43, David Holmes wrote: > On 1/06/2019 3:09 pm, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for looking at it! >> >> >> On 5/31/19 9:47 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> Sorry but I'm rather confused - what does it mean to do a "popframe" >>> on the current thread? >> >> I was confused too. >> We have several JVMTI tests that calls PopFrame in event callbacks. >> ??For instance (see also: popframe006, popframe007, popframe008): >> ??? test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010 >> >> This test gets a breakpoint event and in the callback: >> ??- clears the breakpoint >> ??- enables single stepping >> ??- calls the PopFrame >> >> This seems to be working. > > Okay that makes sense. I hadn't thought about callbacks executing in > the current thread and causing it to back itself up. Not sure, I understand you what you mean by "causing it to back itself" up. The PopFrame will pop the top-most java frame, not the callback frame. The two top-most java frames are marked for deoptimization and the pending_popframe bit is set. >>> The whole point of popframe is to suspend a target thread when it is >>> executing a specific method, and then call popframe to "back up" the >>> thread to the point where it will call that method again when >>> resumed. How does that work with the current thread? >> >> Probably, the most interesting question is: >> ??How will the target thread continue its execution? >> >> As I understand, it will be single stepping. > > I would hope so in the scenario you describe. But presumably the > callback could just clear the breakpoint and do a popframe and so > execution would continue as before? After the event callback returns the execution is continued in the interp-only mode. The actual work is done by the remove_activation_preserving_args. Thanks, Serguei > > Cheers, > David > ------ > >> In such a case, the thread is executed in the interp-only mode. >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> David >>> >>> On 1/06/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>>> Hi All, >>>> >>>> Please comment or.and review the following CSR. >>>> >>>> The CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8225142 >>>> >>>> The bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8205126 >>>> >>>> Updated JVMTI spec: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti.html >>>> >>>> >>>> >>>> Specdiff: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >>>> >>>> >>>> >>>> Summary: >>>> ?? The JVMTI PopFrame() spec does not match the implementation. >>>> ?? It says the? specified thread can not be the current thread. >>>> ?? The fix aligns: >>>> ??? - spec with implementaion >>>> ??? - PopFrame spec with ForceEarlyReturn spec >>>> >>>> Thanks, >>>> Serguei >> From david.holmes at oracle.com Sun Jun 2 12:34:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 2 Jun 2019 22:34:57 +1000 Subject: RFC (csr): 8225142: JVMTI spec incorrectly states that PopFrame can not be called on the current thread In-Reply-To: References: <4a2c2db1-74df-2e7f-0e36-69e96965e676@oracle.com> <2b470401-dcd6-f4b7-6dbc-83c3da907d39@oracle.com> <4f3975db-013c-04dd-c16d-86584e28ca50@oracle.com> <4cbf4b38-bb6a-7a92-f45c-b5e8921a73a0@oracle.com> Message-ID: <4c2ad885-68bd-832f-630e-cf50fa686c68@oracle.com> On 1/06/2019 4:15 pm, serguei.spitsyn at oracle.com wrote: > On 5/31/19 22:43, David Holmes wrote: >> On 1/06/2019 3:09 pm, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for looking at it! >>> >>> >>> On 5/31/19 9:47 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Sorry but I'm rather confused - what does it mean to do a "popframe" >>>> on the current thread? >>> >>> I was confused too. >>> We have several JVMTI tests that calls PopFrame in event callbacks. >>> ??For instance (see also: popframe006, popframe007, popframe008): >>> ??? test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010 >>> >>> This test gets a breakpoint event and in the callback: >>> ??- clears the breakpoint >>> ??- enables single stepping >>> ??- calls the PopFrame >>> >>> This seems to be working. >> >> Okay that makes sense. I hadn't thought about callbacks executing in >> the current thread and causing it to back itself up. > > Not sure, I understand you what you mean by "causing it to back itself" up. > The PopFrame will pop the top-most java frame, not the callback frame. > The two top-most java frames are marked for deoptimization and the > pending_popframe bit is set. That's basically what I meant. The current frame (call it m()) hits the breakpoint and the thread executes the callback which pops the current frame winding the thread back to the point where m() is called. David > > >>>> The whole point of popframe is to suspend a target thread when it is >>>> executing a specific method, and then call popframe to "back up" the >>>> thread to the point where it will call that method again when >>>> resumed. How does that work with the current thread? >>> >>> Probably, the most interesting question is: >>> ??How will the target thread continue its execution? >>> >>> As I understand, it will be single stepping. >> >> I would hope so in the scenario you describe. But presumably the >> callback could just clear the breakpoint and do a popframe and so >> execution would continue as before? > > After the event callback returns the execution is continued in the > interp-only mode. > The actual work is done by the remove_activation_preserving_args. > > Thanks, > Serguei > >> >> Cheers, >> David >> ------ >> >>> In such a case, the thread is executed in the interp-only mode. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 1/06/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>>>> Hi All, >>>>> >>>>> Please comment or.and review the following CSR. >>>>> >>>>> The CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8225142 >>>>> >>>>> The bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8205126 >>>>> >>>>> Updated JVMTI spec: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti.html >>>>> >>>>> >>>>> >>>>> Specdiff: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >>>>> >>>>> >>>>> >>>>> Summary: >>>>> ?? The JVMTI PopFrame() spec does not match the implementation. >>>>> ?? It says the? specified thread can not be the current thread. >>>>> ?? The fix aligns: >>>>> ??? - spec with implementaion >>>>> ??? - PopFrame spec with ForceEarlyReturn spec >>>>> >>>>> Thanks, >>>>> Serguei >>> > From serguei.spitsyn at oracle.com Sun Jun 2 23:13:01 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 2 Jun 2019 16:13:01 -0700 Subject: RFC (csr): 8225142: JVMTI spec incorrectly states that PopFrame can not be called on the current thread In-Reply-To: <4c2ad885-68bd-832f-630e-cf50fa686c68@oracle.com> References: <4a2c2db1-74df-2e7f-0e36-69e96965e676@oracle.com> <2b470401-dcd6-f4b7-6dbc-83c3da907d39@oracle.com> <4f3975db-013c-04dd-c16d-86584e28ca50@oracle.com> <4cbf4b38-bb6a-7a92-f45c-b5e8921a73a0@oracle.com> <4c2ad885-68bd-832f-630e-cf50fa686c68@oracle.com> Message-ID: <2b3c84b4-dd74-ff78-afde-ce30f9c14cad@oracle.com> On 6/2/19 05:34, David Holmes wrote: > On 1/06/2019 4:15 pm, serguei.spitsyn at oracle.com wrote: >> On 5/31/19 22:43, David Holmes wrote: >>> On 1/06/2019 3:09 pm, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for looking at it! >>>> >>>> >>>> On 5/31/19 9:47 PM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Sorry but I'm rather confused - what does it mean to do a >>>>> "popframe" on the current thread? >>>> >>>> I was confused too. >>>> We have several JVMTI tests that calls PopFrame in event callbacks. >>>> ??For instance (see also: popframe006, popframe007, popframe008): >>>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010 >>>> >>>> This test gets a breakpoint event and in the callback: >>>> ??- clears the breakpoint >>>> ??- enables single stepping >>>> ??- calls the PopFrame >>>> >>>> This seems to be working. >>> >>> Okay that makes sense. I hadn't thought about callbacks executing in >>> the current thread and causing it to back itself up. >> >> Not sure, I understand you what you mean by "causing it to back >> itself" up. >> The PopFrame will pop the top-most java frame, not the callback frame. >> The two top-most java frames are marked for deoptimization and the >> pending_popframe bit is set. > > That's basically what I meant. The current frame (call it m()) hits > the breakpoint and the thread executes the callback which pops the > current frame winding the thread back to the point where m() is called. Great! Thanks, Serguei > > David > >> >> >>>>> The whole point of popframe is to suspend a target thread when it >>>>> is executing a specific method, and then call popframe to "back >>>>> up" the thread to the point where it will call that method again >>>>> when resumed. How does that work with the current thread? >>>> >>>> Probably, the most interesting question is: >>>> ??How will the target thread continue its execution? >>>> >>>> As I understand, it will be single stepping. >>> >>> I would hope so in the scenario you describe. But presumably the >>> callback could just clear the breakpoint and do a popframe and so >>> execution would continue as before? >> >> After the event callback returns the execution is continued in the >> interp-only mode. >> The actual work is done by the remove_activation_preserving_args. >> >> Thanks, >> Serguei >> >>> >>> Cheers, >>> David >>> ------ >>> >>>> In such a case, the thread is executed in the interp-only mode. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 1/06/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>>>>> Hi All, >>>>>> >>>>>> Please comment or.and review the following CSR. >>>>>> >>>>>> The CSR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8225142 >>>>>> >>>>>> The bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8205126 >>>>>> >>>>>> Updated JVMTI spec: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti.html >>>>>> >>>>>> >>>>>> >>>>>> Specdiff: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> ?? The JVMTI PopFrame() spec does not match the implementation. >>>>>> ?? It says the? specified thread can not be the current thread. >>>>>> ?? The fix aligns: >>>>>> ??? - spec with implementaion >>>>>> ??? - PopFrame spec with ForceEarlyReturn spec >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >> From serguei.spitsyn at oracle.com Sun Jun 2 23:20:40 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 2 Jun 2019 16:20:40 -0700 Subject: RFR: docs/accessibility: JDK-8220251: fix headings in java.management In-Reply-To: <3693FD02-8AEE-4B3E-B56C-035211DE4B2E@oracle.com> References: <748b5074-ed79-b0e1-6eb0-c3f3c07ef4c1@oracle.com> <3693FD02-8AEE-4B3E-B56C-035211DE4B2E@oracle.com> Message-ID: <5e1221db-dd59-d724-dda5-d07f04b0fb1b@oracle.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Mon Jun 3 22:33:59 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Jun 2019 15:33:59 -0700 Subject: RFR: XXS,doc JDK-8225207: redundant

in Instrumentation.java Message-ID: <4ab767ab-45d9-8e8d-8522-8fe5c5602c4e@oracle.com> Please review a tiny delete-one-line change to fix the last HTML error in the java.instrument module. Note to all:

should only be used at the *beginning* of a paragraph. It is not a terminator or separator. In the context of a javadoc comment, it should not be used before the set of block tags at the end of the comment. No webrev; patch is below. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8225207 $ hg diff -R open diff -r 1cccaaf46c7b src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java --- a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java Mon Jun 03 10:52:18 2019 -0700 +++ b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java Mon Jun 03 15:27:43 2019 -0700 @@ -65,7 +65,7 @@ ? *

? * Once an agent acquires an Instrumentation instance, ? * the agent may call methods on the instance at any time. - *

+ * ? * @apiNote This interface is not intended to be implemented outside of ? * the java.instrument module. ? * From Lance.Andersen at oracle.com Mon Jun 3 22:45:19 2019 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 3 Jun 2019 18:45:19 -0400 Subject: RFR: XXS,doc JDK-8225207: redundant

in Instrumentation.java In-Reply-To: <4ab767ab-45d9-8e8d-8522-8fe5c5602c4e@oracle.com> References: <4ab767ab-45d9-8e8d-8522-8fe5c5602c4e@oracle.com> Message-ID: <6A347751-1420-4546-BA79-DE0BC793E317@oracle.com> +1 -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPhone > On Jun 3, 2019, at 6:33 PM, Jonathan Gibbons wrote: > > Please review a tiny delete-one-line change to fix the last HTML error in the java.instrument module. > > Note to all:

should only be used at the *beginning* of a paragraph. It is not a terminator or separator. > In the context of a javadoc comment, it should not be used before the set of block tags at the end of the comment. > > No webrev; patch is below. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225207 > > $ hg diff -R open > diff -r 1cccaaf46c7b src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > --- a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java Mon Jun 03 10:52:18 2019 -0700 > +++ b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java Mon Jun 03 15:27:43 2019 -0700 > @@ -65,7 +65,7 @@ > *

> * Once an agent acquires an Instrumentation instance, > * the agent may call methods on the instance at any time. > - *

> + * > * @apiNote This interface is not intended to be implemented outside of > * the java.instrument module. > * > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From zanglin5 at jd.com Tue Jun 4 00:41:53 2019 From: zanglin5 at jd.com (=?iso-2022-jp?B?GyRCZ0lOVhsoQg==?=) Date: Tue, 4 Jun 2019 00:41:53 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <5c6c2f4df6844d9ba118262d55990638@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> <3551cf30-8741-2e63-a80e-708f31cf9ebc@oracle.com> <8DC154BA-B292-4638-8AC2-5BAF3FD3A710@jd.com> , <5c6c2f4df6844d9ba118262d55990638@jd.com> Message-ID: <8d59be154c804ee8aeba5afcd150d22d@jd.com> Dear Serguei, Do you think it is reasonable if I implement the parallel, incremental jmap histo together? so that the design can be discussed together. BRs, Lin ________________________________________ From: ?? Sent: Monday, May 20, 2019 11:14:34 PM To: serguei.spitsyn at oracle.com Cc: Hohensee, Paul; JC Beyler; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Dear Serguei, The main reason of using separate file for incremental dump is due to the consideration of parallel incremental dump implementation, so that every heap-iteration thread could dump its own data in separate file, to avoid using file lock. I originally made the design of whole file-support, incremental, parallel dump together, and then divided them into three sub-tasks, trying to make each task easy to discuss and review. In that design, the file= option is for final results, ?incrementalHisto.dump.? is for thread ?local? incremental dumped data. For incremental dump, I agree it is better if we can get rid of incremental-file options and using file=, but I think we need to discuss how to make it adaptable for parallel dump. What do you think? Thanks, Lin From: serguei.spitsyn at oracle.com Sent: Saturday, May 18, 2019 2:42 AM To: ?? Cc: Hohensee, Paul ; JC Beyler ; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear Lin, Before I go to the details below could you, please, explain why do we need a separate file for incremental dump. Should we just record the full dump into file= incrementally? Recording into the full dump file just has to be always incremental. It can be done by chunks if necessary, so I'm open to consider introducing new chunksize option. Do I miss anything here? Thanks, Serguei On 5/17/19 03:18, ?? wrote: Dear Serguei, ? 2019?5?16????1:39?serguei.spitsyn at oracle.com ??? On 5/13/19 23:46, ?? wrote: Dear Serguei, Thanks for your comments. > > - incremental[:], enable the incremental dump of heap, dumped > > data will be saved to, by default it is "IncrementalHisto.dump" > > Q1: Should the be full path or short name? > Is there any default path? What is the path of the > "IncrementalHisto.dump" file? The original design doesn't have the option so the file is hardcoded named "IncrementalHisto.dump" and save to the same path as "file=" specified. Or print to whatever output stream is if "file=" is not set. > The file option is described as: file= dump data to > It does not tell anything about the path. Yes, do you agree that we add a comment in the help info like: file= dump data to , file can be specified with full path. With the new design, I suggest firstly parse , if the value contains folder path, use the specified path, if not, use same path as "file=" value, and if "file=" is not set, use output stream. (The reason I prefer to use same path as "file=" is I assume that users prefer to save all data file under the same folder.) > It needs to be clearly specified. > What statements do you suggest? > > One idea of simplification is to get rid of the default > and to require it to be always specified (non-optional). > > Then we could replace this: > file= dump data to > incremental dump support: > incremental[:] enable incremental dump, data will be dumped > to (default is "IncrementalHisto.dump") > > with this: > file= dump data to > incremental= dump incremental data to I think having a default IncrementalHisto.dump file saved at the same path of the is a way to make incremental easy to use. IMHO, when user use jmap -histo with "file=?, and want to enable inremental histo, the easiest way is just use "-incremental" flag and all data files will be saved under the same folder of . They don?t have to consider the specific filename for incremental additionally. This is the reason I set default value of IncrementalHisto.dump. But I also want the user to have freedom to use different filename and path for incremental results, so I make it optional for incremental file_name. If we can make it non-optional, does it mean that user may have following command: Jmap -histo,file=,incremental: pid It seems a little bit complicated to me, what do you think? > > - chunksize=, size of objects (in KB) will be dumped in one chunk. > > Q2: Should it be chunk of dump, not chunk of objects? The purpose of "chunksize" is to decide how many objects' info are dumped at once. for example use "chunksize=1" on a "Xmx1m", there will be at max 1MB/1KB = 1000 chunks, which indicates that there will be 1000 times of file writing when do "jmap -histo". > I hardly understand the point to know max of objects that can be dumped at once. > It is more important to know how much memory in the file it is going to take. > How much of dump memory will take one object? > Does it vary (does it depend on object types)? Yes, the dump memory for one object varies from size and types. The option?chunksize? is for user to control the proportion of heap that the incremental dump can process at a time. IMO the use scenario is as following: when the JVM have an 180GB max heap size, and jmap histo used with chunksize=1g, it means the incremental dump happens when every 1GB heap is scaned, so it does?t has too much incremenal dump, because the incremental dump takes time and may cause jmap -histo work slower. PS, I think we should support ?g?,?m? and ?k? instead of using ?KB? , do you agree? > > - maxfilesize=, size of the incremental data dump file (in KB), when data size > > is larger than maxfilesize, the file is erased and latest data will be written. > Q3: What is a relation and limitations between chunksize and maxfilesize? > Should the maxfilesize be multiple of the chunksize? > The question Q3 above was not unanswered. > But never mind. Please, see the suggestion below. If the chunksize it large, and there are too much objects of different classes in heap, the actual filesize can be larger than the maxfilesize. But I believe this is raraly happened because the size of one class?s histo info only takes several bytes in the final result, and from the implementation of jmap, it can find out all loaded classes before doing heap iteration, so the different of result only happens on the object quantity. > Q4: The sentence "the file is erased and latest data will be written" is not clear enough. > Why the whole file needs to be erased > Should the incremental file behave like a cyclic buffer? > If so, then only next chunk needs to be erased. > Then the chunks need to be numbered in order, so the earliest one can be found. The "maxfilesize" controls the file size not to be too large, so when the dumped data is larger than "maxfilesize", the file is erased and latest data are written.The reason I erase whole file is that chunk data is accumulative, so the latest data includes the previous statistical ones. And this way may make the file easy to read. I agree that we can add ordered number in chunks, I think it more or less help user to get to know how object distributed in heap. I think maybe it is reasonable to have the incremental file behave like gclog, when maxfilesize is reached, the file is renamed with numbered suffix, and new file is created to use. so there can be IncrementalHisto.dump.0 and IncrementalHisto.dump.1 etc for large heap. what do you think? > I think, it is not a bad idea. > In general, new incremental feature design does not look simple and clear enough. > It feels like another step of simplification is needed. > What about to get rid of the maxfilesize option? > Then each chunk can be recorded to a separate file IncrementalHisto.dump.. > A couple of questions to clarify: > - Do want all chunks or just the latest chunk to be saved? I think usually it is not required to save all chunks. The chunk is incremental, so the new one contains all info that old ones have. But having old chunks may help user to know how object is distributed , because one chunk is a fixed proportion of heap, so the different between to a chunk and it?s predecessor can tell the object distribution of the newly scanned portion of heap. The question is do you think these info is necessary? If not, I agree we can get rid of the maxfilesize. > - If we save all chunks then what is the point to have the full dump recorded as well? IMO, the incremental histo solves two problems: <1> The jmap histo may stuck if heap is large, so it is useful if we can get intermediate result. <2> incremental info may help user know object distribution of some portion of the heap. And I agree that if full dump is successfully gotten, the chunks became less useful. > The advantages of this approach is that there is no need to describe: > - relationship between chunksize and maxfilesize > - recording behavior for multiple chunks in the incremental file > - what chunks have been recorded into the incremental I agree that maxfilesize may not be useful because the histo data of chunks are usually not large. And it sounds good to me that we save chunk data in seperate files named IncrementalHisto.dump.. So the problem is how much chunks do you think we need to save? I think the latest chunk is a must, and maybe the previous 3-5 ones? > But again, this still needs to be clearly specified. > It would be nice to reach a consensus on a design first. Totally agree :) > Thanks, > Serguei Again, Thanks for your comments BRs, Lin Thanks, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Saturday, May 11, 2019 2:17:41 AM To: ??; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear Lin, Sorry for the late reply. I've edited the CSR a little bit to fix some incorrect spots. Now, a couple of spots are not clear to me. > - incremental[:], enable the incremental dump of heap, dumped > data will be saved to, by default it is "IncrementalHisto.dump" Q1: Should the be full path or short name? Is there any default path? What is the path of the "IncrementalHisto.dump" file? > - chunksize=, size of objects (in KB) will be dumped in one chunk. Q2: Should it be chunk of dump, not chunk of objects? > - maxfilesize=, size of the incremental data dump file (in KB), when data size > is larger than maxfilesize, the file is erased and latest data will be written. Q3: What is a relation and limitations between chunksize and maxfilesize? Should the maxfilesize be multiple of the chunksize? Q4: The sentence "the file is erased and latest data will be written" is not clear enough. Why the whole file needs to be erased Should the incremental file behave like a cyclic buffer? If so, then only next chunk needs to be erased. Then the chunks need to be numbered in order, so the earliest one can be found. (I do not want you to accept my suggestions right away. It is just a discussion point. You need to prove that your approach is good and clean enough.) If we resolve the questions (or get into agreement) then I'll update the CSR as needed. Thanks, Serguei On 5/5/19 00:34, ?? wrote: Dear All, I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8222319 May I ask your help to review it? When it is finalized, I will refine the webrev. BRs, Lin Dear Serguei? Thanks a lot for your reviewing. System.err.println(" incremental dump support:"); + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); From this description is not clear at all what does the chunkcount mean. Is it to define how many heap objects are dumped in one chunk? If so, would it better to name it chunksize instead where chunksize is measured in heap objects? Then would it better to use the same units to define the maxfilesize as well? (I'm not insisting on this, just asking.) The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. BRs, Lin From serguei.spitsyn at oracle.com Tue Jun 4 00:55:31 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 3 Jun 2019 17:55:31 -0700 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <8d59be154c804ee8aeba5afcd150d22d@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> <3551cf30-8741-2e63-a80e-708f31cf9ebc@oracle.com> <8DC154BA-B292-4638-8AC2-5BAF3FD3A710@jd.com> <5c6c2f4df6844d9ba118262d55990638@jd.com> <8d59be154c804ee8aeba5afcd150d22d@jd.com> Message-ID: <2d80faeb-ca4c-ffe6-fa3e-59a9aa1f04c6@oracle.com> Dear Lin, Sorry for the delay in reply. I'm not happy with the suggested design at the moment. And I'm out of ideas on how to make it better. It is a good approach to do big work in chunks. However, the overall design has to be clear and simple as much as possible. It feels like more time is needed to make the design solid before pushing any fixes. Thanks, Serguei On 6/3/19 17:41, ?? wrote: > Dear Serguei, > Do you think it is reasonable if I implement the parallel, incremental jmap histo together? so that the design can be discussed together. > > BRs, > Lin > ________________________________________ > From: ?? > Sent: Monday, May 20, 2019 11:14:34 PM > To: serguei.spitsyn at oracle.com > Cc: Hohensee, Paul; JC Beyler; serviceability-dev at openjdk.java.net > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo > > Dear Serguei, > The main reason of using separate file for incremental dump is due to the consideration of parallel incremental dump implementation, so that every heap-iteration thread could dump its own data in separate file, to avoid using file lock. > I originally made the design of whole file-support, incremental, parallel dump together, and then divided them into three sub-tasks, trying to make each task easy to discuss and review. In that design, the file= option is for final results, ?incrementalHisto.dump.? is for thread ?local? incremental dumped data. > For incremental dump, I agree it is better if we can get rid of incremental-file options and using file=, but I think we need to discuss how to make it adaptable for parallel dump. What do you think? > > Thanks, > Lin > > > From: serguei.spitsyn at oracle.com > Sent: Saturday, May 18, 2019 2:42 AM > To: ?? > Cc: Hohensee, Paul ; JC Beyler ; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215623: Add incremental dump for jmap histo > > Dear Lin, > > Before I go to the details below could you, please, explain why do we need a separate file for incremental dump. > Should we just record the full dump into file= incrementally? > Recording into the full dump file just has to be always incremental. > It can be done by chunks if necessary, so I'm open to consider introducing new chunksize option. > > Do I miss anything here? > > Thanks, > Serguei > > On 5/17/19 03:18, ?? wrote: > Dear Serguei, > > > ? 2019?5?16????1:39?serguei.spitsyn at oracle.com ??? > > On 5/13/19 23:46, ?? wrote: > > Dear Serguei, > > Thanks for your comments. > > > > > > - incremental[:], enable the incremental dump of heap, dumped > > > > data will be saved to, by default it is "IncrementalHisto.dump" > > > > > > Q1: Should the be full path or short name? > > > Is there any default path? What is the path of the > > > "IncrementalHisto.dump" file? > > > > The original design doesn't have the option so the file is hardcoded named "IncrementalHisto.dump" and save to the same path as "file=" specified. Or print to whatever output stream is if "file=" is not set. > >> The file option is described as: file= dump data to >> It does not tell anything about the path. > Yes, do you agree that we add a comment in the help info like: > file= dump data to , file can be specified with full path. > > With the new design, I suggest firstly parse , if the value contains folder path, use the specified path, if not, use same path as "file=" value, and if "file=" is not set, use output stream. (The reason I prefer to use same path as "file=" is I assume that users prefer to save all data file under the same folder.) > >> It needs to be clearly specified. >> What statements do you suggest? >> >> One idea of simplification is to get rid of the default >> and to require it to be always specified (non-optional). >> >> Then we could replace this: >> file= dump data to >> incremental dump support: >> incremental[:] enable incremental dump, data will be dumped >> to (default is "IncrementalHisto.dump") >> >> with this: >> file= dump data to >> incremental= dump incremental data to > I think having a default IncrementalHisto.dump file saved at the same path of the is a way to make incremental easy to use. > IMHO, when user use jmap -histo with "file=?, and want to enable inremental histo, the easiest way is just use "-incremental" flag and all data files will be saved under the same folder of . They don?t have to consider the specific filename for incremental additionally. This is the reason I set default value of IncrementalHisto.dump. > > But I also want the user to have freedom to use different filename and path for incremental results, so I make it optional for incremental file_name. > > If we can make it non-optional, does it mean that user may have following command: > Jmap -histo,file=,incremental: pid > It seems a little bit complicated to me, what do you think? > > > > > > > > - chunksize=, size of objects (in KB) will be dumped in one chunk. > > > > > > Q2: Should it be chunk of dump, not chunk of objects? > > > > The purpose of "chunksize" is to decide how many objects' info are dumped at once. for example use "chunksize=1" on a "Xmx1m", there will be at max 1MB/1KB = 1000 chunks, which indicates that there will be 1000 times of file writing when do "jmap -histo". > >> I hardly understand the point to know max of objects that can be dumped at once. >> It is more important to know how much memory in the file it is going to take. >> How much of dump memory will take one object? >> Does it vary (does it depend on object types)? > Yes, the dump memory for one object varies from size and types. > The option?chunksize? is for user to control the proportion of heap that the incremental dump can process at a time. IMO the use scenario is as following: > > when the JVM have an 180GB max heap size, and jmap histo used with chunksize=1g, it means the incremental dump happens when every 1GB heap is scaned, so it does?t has too much incremenal dump, because the incremental dump takes time and may cause jmap -histo work slower. > > PS, I think we should support ?g?,?m? and ?k? instead of using ?KB? , do you agree? > > > > > > - maxfilesize=, size of the incremental data dump file (in KB), when data size > > > > is larger than maxfilesize, the file is erased and latest data will be written. > > > > > Q3: What is a relation and limitations between chunksize and maxfilesize? > > > Should the maxfilesize be multiple of the chunksize? > >> The question Q3 above was not unanswered. >> But never mind. Please, see the suggestion below. > If the chunksize it large, and there are too much objects of different classes in heap, the actual filesize can be larger than the maxfilesize. > But I believe this is raraly happened because the size of one class?s histo info only takes several bytes in the final result, and from the implementation of jmap, > it can find out all loaded classes before doing heap iteration, so the different of result only happens on the object quantity. > > > Q4: The sentence "the file is erased and latest data will be written" > > is not clear enough. > > > Why the whole file needs to be erased > > > Should the incremental file behave like a cyclic buffer? > > > If so, then only next chunk needs to be erased. > > > Then the chunks need to be numbered in order, so the earliest one can be found. > > > > The "maxfilesize" controls the file size not to be too large, so when the dumped data is larger than "maxfilesize", the file is erased and latest data are written.The reason I erase whole file is that chunk data is accumulative, so the latest data includes the previous statistical ones. And this way may make the file easy to read. > > > > I agree that we can add ordered number in chunks, I think it more or less help user to get to know how object distributed in heap. > > > > I think maybe it is reasonable to have the incremental file behave like gclog, when maxfilesize is reached, the file is renamed with numbered suffix, and new file is created to use. so there can be IncrementalHisto.dump.0 and IncrementalHisto.dump.1 etc for large heap. > > > > what do you think? > >> I think, it is not a bad idea. >> In general, new incremental feature design does not look simple and clear enough. >> It feels like another step of simplification is needed. >> What about to get rid of the maxfilesize option? >> Then each chunk can be recorded to a separate file IncrementalHisto.dump.. >> A couple of questions to clarify: > > - Do want all chunks or just the latest chunk to be saved? > > I think usually it is not required to save all chunks. The chunk is incremental, so the new one contains all info that old ones have. > But having old chunks may help user to know how object is distributed , because one chunk is a fixed proportion of heap, so the different between to a chunk and it?s predecessor can tell the object distribution of the newly scanned portion of heap. > The question is do you think these info is necessary? If not, I agree we can get rid of the maxfilesize. > > > - If we save all chunks then what is the point to have the full dump recorded as well? > > IMO, the incremental histo solves two problems: <1> The jmap histo may stuck if heap is large, so it is useful if we can get intermediate result. <2> incremental info may help user know object distribution of some portion of the heap. > And I agree that if full dump is successfully gotten, the chunks became less useful. > > > >> The advantages of this approach is that there is no need to describe: > > - relationship between chunksize and maxfilesize > > - recording behavior for multiple chunks in the incremental file > > - what chunks have been recorded into the incremental > > I agree that maxfilesize may not be useful because the histo data of chunks are usually not large. And it sounds good to me that we save chunk data in seperate files named IncrementalHisto.dump.. > So the problem is how much chunks do you think we need to save? I think the latest chunk is a must, and maybe the previous 3-5 ones? > > >> But again, this still needs to be clearly specified. >> It would be nice to reach a consensus on a design first. > Totally agree :) > >> Thanks, >> Serguei > Again, Thanks for your comments > > BRs, > Lin > > > > Thanks, > > Lin > > ________________________________________ > > From: serguei.spitsyn at oracle.com > > Sent: Saturday, May 11, 2019 2:17:41 AM > > To: ??; Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215623: Add incremental dump for jmap histo > > > > Dear Lin, > > > > Sorry for the late reply. > > I've edited the CSR a little bit to fix some incorrect spots. > > Now, a couple of spots are not clear to me. > > > > > > > - incremental[:], enable the incremental dump of heap, dumped > > > data will be saved to, by default it is "IncrementalHisto.dump" > > > > > > Q1: Should the be full path or short name? > > Is there any default path? What is the path of the > > "IncrementalHisto.dump" file? > > > > > - chunksize=, size of objects (in KB) will be dumped in one chunk. > > > > Q2: Should it be chunk of dump, not chunk of objects? > > > > > - maxfilesize=, size of the incremental data dump file (in KB), > > when data size > > > is larger than maxfilesize, the file is erased and latest data will > > be written. > > > > Q3: What is a relation and limitations between chunksize and maxfilesize? > > Should the maxfilesize be multiple of the chunksize? > > > > Q4: The sentence "the file is erased and latest data will be written" > > is not clear enough. > > Why the whole file needs to be erased > > Should the incremental file behave like a cyclic buffer? > > If so, then only next chunk needs to be erased. > > Then the chunks need to be numbered in order, so the earliest one > > can be found. > > (I do not want you to accept my suggestions right away. It is just > > a discussion point. > > You need to prove that your approach is good and clean enough.) > > > > If we resolve the questions (or get into agreement) then I'll update the > > CSR as needed. > > > > Thanks, > > Serguei > > > > > > On 5/5/19 00:34, ?? wrote: > > Dear All, > > I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8222319 > > May I ask your help to review it? > > When it is finalized, I will refine the webrev. > > > > BRs, > > Lin > > > > Dear Serguei? > > Thanks a lot for your reviewing. > > > > > > > > System.err.println(" incremental dump support:"); > > + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); > > + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); > > > > > > From this description is not clear at all what does the chunkcount mean. > > Is it to define how many heap objects are dumped in one chunk? > > If so, would it better to name it chunksize instead where chunksize is measured in heap objects? > > Then would it better to use the same units to define the maxfilesize as well? > > (I'm not insisting on this, just asking.) > > The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. > > For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and > > when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. > > > > The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. > > Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. > > BRs, > > Lin > > > From serguei.spitsyn at oracle.com Tue Jun 4 00:57:30 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 3 Jun 2019 17:57:30 -0700 Subject: RFR: XXS,doc JDK-8225207: redundant

in Instrumentation.java In-Reply-To: <6A347751-1420-4546-BA79-DE0BC793E317@oracle.com> References: <4ab767ab-45d9-8e8d-8522-8fe5c5602c4e@oracle.com> <6A347751-1420-4546-BA79-DE0BC793E317@oracle.com> Message-ID: <13c3964e-c83f-2c3a-1836-d7ecf54bbc27@oracle.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From zanglin5 at jd.com Tue Jun 4 01:17:35 2019 From: zanglin5 at jd.com (=?iso-2022-jp?B?GyRCZ0lOVhsoQg==?=) Date: Tue, 4 Jun 2019 01:17:35 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <2d80faeb-ca4c-ffe6-fa3e-59a9aa1f04c6@oracle.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> <3551cf30-8741-2e63-a80e-708f31cf9ebc@oracle.com> <8DC154BA-B292-4638-8AC2-5BAF3FD3A710@jd.com> <5c6c2f4df6844d9ba118262d55990638@jd.com> <8d59be154c804ee8aeba5afcd150d22d@jd.com>, <2d80faeb-ca4c-ffe6-fa3e-59a9aa1f04c6@oracle.com> Message-ID: <8f87cbd93c2b4eec8eafd8dd6183b3ec@jd.com> Hi Serguei, How about that we drop all previous design about incremental dump, And let me try to re-design it again, with incremental and parallel solution as a whole. Then we can discuss it until it looks good, and then we discuss how to implement it with several webrevs that are easy to review. I think the target is clear at least - to make jmap -histo easy to work under the scenario of large heap, with two approaches: 1. incremental - get intermediate result, to avoid user get nothing when jmap -histo stuck. 2. parallel - improve the efficiency of jmap -histo for large heap. What do you think? BRs, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Tuesday, June 4, 2019 8:55:31 AM To: ?? Cc: Hohensee, Paul; JC Beyler; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear Lin, Sorry for the delay in reply. I'm not happy with the suggested design at the moment. And I'm out of ideas on how to make it better. It is a good approach to do big work in chunks. However, the overall design has to be clear and simple as much as possible. It feels like more time is needed to make the design solid before pushing any fixes. Thanks, Serguei On 6/3/19 17:41, ?? wrote: > Dear Serguei, > Do you think it is reasonable if I implement the parallel, incremental jmap histo together? so that the design can be discussed together. > > BRs, > Lin > ________________________________________ > From: ?? > Sent: Monday, May 20, 2019 11:14:34 PM > To: serguei.spitsyn at oracle.com > Cc: Hohensee, Paul; JC Beyler; serviceability-dev at openjdk.java.net > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo > > Dear Serguei, > The main reason of using separate file for incremental dump is due to the consideration of parallel incremental dump implementation, so that every heap-iteration thread could dump its own data in separate file, to avoid using file lock. > I originally made the design of whole file-support, incremental, parallel dump together, and then divided them into three sub-tasks, trying to make each task easy to discuss and review. In that design, the file= option is for final results, ?incrementalHisto.dump.? is for thread ?local? incremental dumped data. > For incremental dump, I agree it is better if we can get rid of incremental-file options and using file=, but I think we need to discuss how to make it adaptable for parallel dump. What do you think? > > Thanks, > Lin > > > From: serguei.spitsyn at oracle.com > Sent: Saturday, May 18, 2019 2:42 AM > To: ?? > Cc: Hohensee, Paul ; JC Beyler ; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215623: Add incremental dump for jmap histo > > Dear Lin, > > Before I go to the details below could you, please, explain why do we need a separate file for incremental dump. > Should we just record the full dump into file= incrementally? > Recording into the full dump file just has to be always incremental. > It can be done by chunks if necessary, so I'm open to consider introducing new chunksize option. > > Do I miss anything here? > > Thanks, > Serguei > > On 5/17/19 03:18, ?? wrote: > Dear Serguei, > > > ? 2019?5?16????1:39?serguei.spitsyn at oracle.com ??? > > On 5/13/19 23:46, ?? wrote: > > Dear Serguei, > > Thanks for your comments. > > > > > > - incremental[:], enable the incremental dump of heap, dumped > > > > data will be saved to, by default it is "IncrementalHisto.dump" > > > > > > Q1: Should the be full path or short name? > > > Is there any default path? What is the path of the > > > "IncrementalHisto.dump" file? > > > > The original design doesn't have the option so the file is hardcoded named "IncrementalHisto.dump" and save to the same path as "file=" specified. Or print to whatever output stream is if "file=" is not set. > >> The file option is described as: file= dump data to >> It does not tell anything about the path. > Yes, do you agree that we add a comment in the help info like: > file= dump data to , file can be specified with full path. > > With the new design, I suggest firstly parse , if the value contains folder path, use the specified path, if not, use same path as "file=" value, and if "file=" is not set, use output stream. (The reason I prefer to use same path as "file=" is I assume that users prefer to save all data file under the same folder.) > >> It needs to be clearly specified. >> What statements do you suggest? >> >> One idea of simplification is to get rid of the default >> and to require it to be always specified (non-optional). >> >> Then we could replace this: >> file= dump data to >> incremental dump support: >> incremental[:] enable incremental dump, data will be dumped >> to (default is "IncrementalHisto.dump") >> >> with this: >> file= dump data to >> incremental= dump incremental data to > I think having a default IncrementalHisto.dump file saved at the same path of the is a way to make incremental easy to use. > IMHO, when user use jmap -histo with "file=?, and want to enable inremental histo, the easiest way is just use "-incremental" flag and all data files will be saved under the same folder of . They don?t have to consider the specific filename for incremental additionally. This is the reason I set default value of IncrementalHisto.dump. > > But I also want the user to have freedom to use different filename and path for incremental results, so I make it optional for incremental file_name. > > If we can make it non-optional, does it mean that user may have following command: > Jmap -histo,file=,incremental: pid > It seems a little bit complicated to me, what do you think? > > > > > > > > - chunksize=, size of objects (in KB) will be dumped in one chunk. > > > > > > Q2: Should it be chunk of dump, not chunk of objects? > > > > The purpose of "chunksize" is to decide how many objects' info are dumped at once. for example use "chunksize=1" on a "Xmx1m", there will be at max 1MB/1KB = 1000 chunks, which indicates that there will be 1000 times of file writing when do "jmap -histo". > >> I hardly understand the point to know max of objects that can be dumped at once. >> It is more important to know how much memory in the file it is going to take. >> How much of dump memory will take one object? >> Does it vary (does it depend on object types)? > Yes, the dump memory for one object varies from size and types. > The option?chunksize? is for user to control the proportion of heap that the incremental dump can process at a time. IMO the use scenario is as following: > > when the JVM have an 180GB max heap size, and jmap histo used with chunksize=1g, it means the incremental dump happens when every 1GB heap is scaned, so it does?t has too much incremenal dump, because the incremental dump takes time and may cause jmap -histo work slower. > > PS, I think we should support ?g?,?m? and ?k? instead of using ?KB? , do you agree? > > > > > > - maxfilesize=, size of the incremental data dump file (in KB), when data size > > > > is larger than maxfilesize, the file is erased and latest data will be written. > > > > > Q3: What is a relation and limitations between chunksize and maxfilesize? > > > Should the maxfilesize be multiple of the chunksize? > >> The question Q3 above was not unanswered. >> But never mind. Please, see the suggestion below. > If the chunksize it large, and there are too much objects of different classes in heap, the actual filesize can be larger than the maxfilesize. > But I believe this is raraly happened because the size of one class?s histo info only takes several bytes in the final result, and from the implementation of jmap, > it can find out all loaded classes before doing heap iteration, so the different of result only happens on the object quantity. > > > Q4: The sentence "the file is erased and latest data will be written" > > is not clear enough. > > > Why the whole file needs to be erased > > > Should the incremental file behave like a cyclic buffer? > > > If so, then only next chunk needs to be erased. > > > Then the chunks need to be numbered in order, so the earliest one can be found. > > > > The "maxfilesize" controls the file size not to be too large, so when the dumped data is larger than "maxfilesize", the file is erased and latest data are written.The reason I erase whole file is that chunk data is accumulative, so the latest data includes the previous statistical ones. And this way may make the file easy to read. > > > > I agree that we can add ordered number in chunks, I think it more or less help user to get to know how object distributed in heap. > > > > I think maybe it is reasonable to have the incremental file behave like gclog, when maxfilesize is reached, the file is renamed with numbered suffix, and new file is created to use. so there can be IncrementalHisto.dump.0 and IncrementalHisto.dump.1 etc for large heap. > > > > what do you think? > >> I think, it is not a bad idea. >> In general, new incremental feature design does not look simple and clear enough. >> It feels like another step of simplification is needed. >> What about to get rid of the maxfilesize option? >> Then each chunk can be recorded to a separate file IncrementalHisto.dump.. >> A couple of questions to clarify: > > - Do want all chunks or just the latest chunk to be saved? > > I think usually it is not required to save all chunks. The chunk is incremental, so the new one contains all info that old ones have. > But having old chunks may help user to know how object is distributed , because one chunk is a fixed proportion of heap, so the different between to a chunk and it?s predecessor can tell the object distribution of the newly scanned portion of heap. > The question is do you think these info is necessary? If not, I agree we can get rid of the maxfilesize. > > > - If we save all chunks then what is the point to have the full dump recorded as well? > > IMO, the incremental histo solves two problems: <1> The jmap histo may stuck if heap is large, so it is useful if we can get intermediate result. <2> incremental info may help user know object distribution of some portion of the heap. > And I agree that if full dump is successfully gotten, the chunks became less useful. > > > >> The advantages of this approach is that there is no need to describe: > > - relationship between chunksize and maxfilesize > > - recording behavior for multiple chunks in the incremental file > > - what chunks have been recorded into the incremental > > I agree that maxfilesize may not be useful because the histo data of chunks are usually not large. And it sounds good to me that we save chunk data in seperate files named IncrementalHisto.dump.. > So the problem is how much chunks do you think we need to save? I think the latest chunk is a must, and maybe the previous 3-5 ones? > > >> But again, this still needs to be clearly specified. >> It would be nice to reach a consensus on a design first. > Totally agree :) > >> Thanks, >> Serguei > Again, Thanks for your comments > > BRs, > Lin > > > > Thanks, > > Lin > > ________________________________________ > > From: serguei.spitsyn at oracle.com > > Sent: Saturday, May 11, 2019 2:17:41 AM > > To: ??; Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215623: Add incremental dump for jmap histo > > > > Dear Lin, > > > > Sorry for the late reply. > > I've edited the CSR a little bit to fix some incorrect spots. > > Now, a couple of spots are not clear to me. > > > > > > > - incremental[:], enable the incremental dump of heap, dumped > > > data will be saved to, by default it is "IncrementalHisto.dump" > > > > > > Q1: Should the be full path or short name? > > Is there any default path? What is the path of the > > "IncrementalHisto.dump" file? > > > > > - chunksize=, size of objects (in KB) will be dumped in one chunk. > > > > Q2: Should it be chunk of dump, not chunk of objects? > > > > > - maxfilesize=, size of the incremental data dump file (in KB), > > when data size > > > is larger than maxfilesize, the file is erased and latest data will > > be written. > > > > Q3: What is a relation and limitations between chunksize and maxfilesize? > > Should the maxfilesize be multiple of the chunksize? > > > > Q4: The sentence "the file is erased and latest data will be written" > > is not clear enough. > > Why the whole file needs to be erased > > Should the incremental file behave like a cyclic buffer? > > If so, then only next chunk needs to be erased. > > Then the chunks need to be numbered in order, so the earliest one > > can be found. > > (I do not want you to accept my suggestions right away. It is just > > a discussion point. > > You need to prove that your approach is good and clean enough.) > > > > If we resolve the questions (or get into agreement) then I'll update the > > CSR as needed. > > > > Thanks, > > Serguei > > > > > > On 5/5/19 00:34, ?? wrote: > > Dear All, > > I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8222319 > > May I ask your help to review it? > > When it is finalized, I will refine the webrev. > > > > BRs, > > Lin > > > > Dear Serguei? > > Thanks a lot for your reviewing. > > > > > > > > System.err.println(" incremental dump support:"); > > + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); > > + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); > > > > > > From this description is not clear at all what does the chunkcount mean. > > Is it to define how many heap objects are dumped in one chunk? > > If so, would it better to name it chunksize instead where chunksize is measured in heap objects? > > Then would it better to use the same units to define the maxfilesize as well? > > (I'm not insisting on this, just asking.) > > The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. > > For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and > > when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. > > > > The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. > > Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. > > BRs, > > Lin > > > From jonathan.gibbons at oracle.com Tue Jun 4 21:42:26 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 4 Jun 2019 14:42:26 -0700 Subject: RFR XS,docs JDK-8225309 HTML issues in jdk.jdi module Message-ID: <81e80433-fe86-671d-f09f-9e9d3ad5032a@oracle.com> Please review another small patch for the jdk.jdi module, to fix a missing heading in one file and to adjust a heading in another. No webrev; patch below. That being said, the file src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html barely warrants being its own file, but even what content there is deserves to be fixed. The table caption is oversized, the table has no borders and not not use any CSS to "stripe" the rows. However, that cleanup is out of scope for this accessibility fix for the headings. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8225309 $ hg diff -R open diff -r 4158e6a864d4 src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html --- a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Tue Jun 04 13:47:59 2019 -0700 +++ b/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Tue Jun 04 14:35:34 2019 -0700 @@ -41,6 +41,7 @@ ? ? ?

+

JDI Type Signatures

? ? ? diff -r 4158e6a864d4 src/jdk.jdi/share/classes/module-info.java --- a/src/jdk.jdi/share/classes/module-info.java Tue Jun 04 13:47:59 2019 -0700 +++ b/src/jdk.jdi/share/classes/module-info.java Tue Jun 04 14:35:34 2019 -0700 @@ -46,7 +46,7 @@ ? * This module includes a simple command-line debugger, ? * {@index jdb jdb tool}. ? * - *

Global Exceptions

+ *

Global Exceptions

? *

? * This section documents exceptions which apply to the entire API and are thus ? * not documented on individual methods. From lance.andersen at oracle.com Tue Jun 4 21:45:01 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 4 Jun 2019 17:45:01 -0400 Subject: RFR XS,docs JDK-8225309 HTML issues in jdk.jdi module In-Reply-To: <81e80433-fe86-671d-f09f-9e9d3ad5032a@oracle.com> References: <81e80433-fe86-671d-f09f-9e9d3ad5032a@oracle.com> Message-ID: <7B567EA7-9743-4C62-86B4-CF0E1BDB0865@oracle.com> +1 > On Jun 4, 2019, at 5:42 PM, Jonathan Gibbons wrote: > > Please review another small patch for the jdk.jdi module, to fix a missing heading in one file and to adjust a heading in another. > > No webrev; patch below. > > That being said, the file src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html barely warrants being its own file, but even what content there is deserves to be fixed. The table caption is oversized, the table has no borders and not not use any CSS to "stripe" the rows. However, that cleanup is out of scope for this accessibility fix for the headings. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225309 > > > $ hg diff -R open > diff -r 4158e6a864d4 src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > --- a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Tue Jun 04 13:47:59 2019 -0700 > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Tue Jun 04 14:35:34 2019 -0700 > @@ -41,6 +41,7 @@ > > >

> +

JDI Type Signatures

>
JDI Type Signatures
> > > diff -r 4158e6a864d4 src/jdk.jdi/share/classes/module-info.java > --- a/src/jdk.jdi/share/classes/module-info.java Tue Jun 04 13:47:59 2019 -0700 > +++ b/src/jdk.jdi/share/classes/module-info.java Tue Jun 04 14:35:34 2019 -0700 > @@ -46,7 +46,7 @@ > * This module includes a simple command-line debugger, > * {@index jdb jdb tool}. > * > - *

Global Exceptions

> + *

Global Exceptions

> *

> * This section documents exceptions which apply to the entire API and are thus > * not documented on individual methods. > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From serguei.spitsyn at oracle.com Tue Jun 4 23:30:09 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Jun 2019 16:30:09 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread Message-ID: <36644087-6bf1-e549-f372-041f45058186@oracle.com> Please, review a fix for the JVMTI spec bug: https://bugs.openjdk.java.net/browse/JDK-8205126 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ Related CSR: https://bugs.openjdk.java.net/browse/JDK-8225142 Specdiff: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ Summary: ? The JVMTI PopFrame() spec does not match the implementation. ? It says the? specified thread can not be the current thread. ? The fix aligns: ?? - spec with implementaion ?? - PopFrame spec with ForceEarlyReturn spec Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Jun 4 23:47:34 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 4 Jun 2019 16:47:34 -0700 Subject: RFR: XXS,docs JDK-8225324 Bad HTML in jdk.jfr module-info.java Message-ID: <564ee833-003c-710d-1a16-48b89399b5b6@oracle.com> Please review a fix to remove an unnecessary trailing

from the module-info file for jdk.jfr Patch below. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8225324 $ hg diff -R open diff -r e079a4cfad75 src/jdk.jfr/share/classes/module-info.java --- a/src/jdk.jfr/share/classes/module-info.java Tue Jun 04 15:42:16 2019 -0700 +++ b/src/jdk.jfr/share/classes/module-info.java Tue Jun 04 16:40:53 2019 -0700 @@ -25,7 +25,6 @@ ?/** ? * Defines the API for JDK Flight Recorder. - *

? * ? * @moduleGraph ? * @since 9 From lance.andersen at oracle.com Tue Jun 4 23:49:54 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 4 Jun 2019 19:49:54 -0400 Subject: RFR: XXS,docs JDK-8225324 Bad HTML in jdk.jfr module-info.java In-Reply-To: <564ee833-003c-710d-1a16-48b89399b5b6@oracle.com> References: <564ee833-003c-710d-1a16-48b89399b5b6@oracle.com> Message-ID: <9DC36D21-1FEF-4A5B-964A-69DC6396AE95@oracle.com> +1 > On Jun 4, 2019, at 7:47 PM, Jonathan Gibbons wrote: > > Please review a fix to remove an unnecessary trailing

from the module-info file for jdk.jfr > > Patch below. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225324 > > > $ hg diff -R open > diff -r e079a4cfad75 src/jdk.jfr/share/classes/module-info.java > --- a/src/jdk.jfr/share/classes/module-info.java Tue Jun 04 15:42:16 2019 -0700 > +++ b/src/jdk.jfr/share/classes/module-info.java Tue Jun 04 16:40:53 2019 -0700 > @@ -25,7 +25,6 @@ > > /** > * Defines the API for JDK Flight Recorder. > - *

> * > * @moduleGraph > * @since 9 > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From serguei.spitsyn at oracle.com Wed Jun 5 00:08:35 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Jun 2019 17:08:35 -0700 Subject: RFR XS,docs JDK-8225309 HTML issues in jdk.jdi module In-Reply-To: <81e80433-fe86-671d-f09f-9e9d3ad5032a@oracle.com> References: <81e80433-fe86-671d-f09f-9e9d3ad5032a@oracle.com> Message-ID: Hi Jon, Looks good to me. Thanks, Serguei On 6/4/19 2:42 PM, Jonathan Gibbons wrote: > Please review another small patch for the jdk.jdi module, to fix a > missing heading in one file and to adjust a heading in another. > > No webrev; patch below. > > That being said, the file > src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html barely > warrants being its own file, but even what content there is deserves > to be fixed. The table caption is oversized, the table has no borders > and not not use any CSS to "stripe" the rows. However, that cleanup is > out of scope for this accessibility fix for the headings. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225309 > > > $ hg diff -R open > diff -r 4158e6a864d4 > src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > --- a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > Tue Jun 04 13:47:59 2019 -0700 > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > Tue Jun 04 14:35:34 2019 -0700 > @@ -41,6 +41,7 @@ > ? > ? > ?

> +

JDI Type Signatures

> ?
JDI Type Signatures
> ? > ? > diff -r 4158e6a864d4 src/jdk.jdi/share/classes/module-info.java > --- a/src/jdk.jdi/share/classes/module-info.java Tue Jun 04 13:47:59 > 2019 -0700 > +++ b/src/jdk.jdi/share/classes/module-info.java Tue Jun 04 14:35:34 > 2019 -0700 > @@ -46,7 +46,7 @@ > ? * This module includes a simple command-line debugger, > ? * {@index jdb jdb tool}. > ? * > - *

Global Exceptions

> + *

Global Exceptions

> ? *

> ? * This section documents exceptions which apply to the entire API > and are thus > ? * not documented on individual methods. > From alexey.menkov at oracle.com Wed Jun 5 01:18:12 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 4 Jun 2019 18:18:12 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: <36644087-6bf1-e549-f372-041f45058186@oracle.com> References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> Message-ID: <9c97c6b6-b252-8140-f052-73deade6c313@oracle.com> The fix looks good to me. --alex On 06/04/2019 16:30, serguei.spitsyn at oracle.com wrote: > Please, review a fix for the JVMTI spec bug: > https://bugs.openjdk.java.net/browse/JDK-8205126 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ > > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8225142 > > Specdiff: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ > > > Summary: > ? The JVMTI PopFrame() spec does not match the implementation. > ? It says the? specified thread can not be the current thread. > ? The fix aligns: > ?? - spec with implementaion > ?? - PopFrame spec with ForceEarlyReturn spec > > Thanks, > Serguei From serguei.spitsyn at oracle.com Wed Jun 5 01:18:52 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Jun 2019 18:18:52 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: <9c97c6b6-b252-8140-f052-73deade6c313@oracle.com> References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> <9c97c6b6-b252-8140-f052-73deade6c313@oracle.com> Message-ID: <03c799bc-30b8-eedd-026f-9b4b7359939b@oracle.com> Thanks a lot, Alex! Serguei On 6/4/19 6:18 PM, Alex Menkov wrote: > The fix looks good to me. > > --alex > > On 06/04/2019 16:30, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for the JVMTI spec bug: >> https://bugs.openjdk.java.net/browse/JDK-8205126 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ >> >> >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8225142 >> >> Specdiff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >> >> >> >> Summary: >> ?? The JVMTI PopFrame() spec does not match the implementation. >> ?? It says the? specified thread can not be the current thread. >> ?? The fix aligns: >> ??? - spec with implementaion >> ??? - PopFrame spec with ForceEarlyReturn spec >> >> Thanks, >> Serguei From jcbeyler at google.com Wed Jun 5 01:36:28 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 4 Jun 2019 18:36:28 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: <03c799bc-30b8-eedd-026f-9b4b7359939b@oracle.com> References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> <9c97c6b6-b252-8140-f052-73deade6c313@oracle.com> <03c799bc-30b8-eedd-026f-9b4b7359939b@oracle.com> Message-ID: Hi Serguei, Looks good to me too :) Jc On Tue, Jun 4, 2019 at 6:21 PM wrote: > Thanks a lot, Alex! > Serguei > > On 6/4/19 6:18 PM, Alex Menkov wrote: > > The fix looks good to me. > > > > --alex > > > > On 06/04/2019 16:30, serguei.spitsyn at oracle.com wrote: > >> Please, review a fix for the JVMTI spec bug: > >> https://bugs.openjdk.java.net/browse/JDK-8205126 > >> > >> Webrev: > >> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ > >> > >> > >> > >> Related CSR: > >> https://bugs.openjdk.java.net/browse/JDK-8225142 > >> > >> Specdiff: > >> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ > >> > >> > >> > >> Summary: > >> The JVMTI PopFrame() spec does not match the implementation. > >> It says the specified thread can not be the current thread. > >> The fix aligns: > >> - spec with implementaion > >> - PopFrame spec with ForceEarlyReturn spec > >> > >> Thanks, > >> Serguei > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Jun 5 01:37:05 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 4 Jun 2019 18:37:05 -0700 Subject: RFR: XXS,docs JDK-8225324 Bad HTML in jdk.jfr module-info.java In-Reply-To: <9DC36D21-1FEF-4A5B-964A-69DC6396AE95@oracle.com> References: <564ee833-003c-710d-1a16-48b89399b5b6@oracle.com> <9DC36D21-1FEF-4A5B-964A-69DC6396AE95@oracle.com> Message-ID: Hi Jonathan, Looks good to me too :) Jc On Tue, Jun 4, 2019 at 4:50 PM Lance Andersen wrote: > +1 > > On Jun 4, 2019, at 7:47 PM, Jonathan Gibbons > wrote: > > Please review a fix to remove an unnecessary trailing

from the > module-info file for jdk.jfr > > Patch below. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225324 > > > $ hg diff -R open > diff -r e079a4cfad75 src/jdk.jfr/share/classes/module-info.java > --- a/src/jdk.jfr/share/classes/module-info.java Tue Jun 04 15:42:16 2019 > -0700 > +++ b/src/jdk.jfr/share/classes/module-info.java Tue Jun 04 16:40:53 2019 > -0700 > @@ -25,7 +25,6 @@ > > /** > * Defines the API for JDK Flight Recorder. > - *

> * > * @moduleGraph > * @since 9 > > > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From jcbeyler at google.com Wed Jun 5 01:37:39 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 4 Jun 2019 18:37:39 -0700 Subject: RFR XS,docs JDK-8225309 HTML issues in jdk.jdi module In-Reply-To: References: <81e80433-fe86-671d-f09f-9e9d3ad5032a@oracle.com> Message-ID: Hi Jon, It looks good to me as well (not an official reviewer though :-)), Jc On Tue, Jun 4, 2019 at 5:09 PM wrote: > Hi Jon, > > Looks good to me. > > Thanks, > Serguei > > > On 6/4/19 2:42 PM, Jonathan Gibbons wrote: > > Please review another small patch for the jdk.jdi module, to fix a > > missing heading in one file and to adjust a heading in another. > > > > No webrev; patch below. > > > > That being said, the file > > src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html barely > > warrants being its own file, but even what content there is deserves > > to be fixed. The table caption is oversized, the table has no borders > > and not not use any CSS to "stripe" the rows. However, that cleanup is > > out of scope for this accessibility fix for the headings. > > > > -- Jon > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225309 > > > > > > $ hg diff -R open > > diff -r 4158e6a864d4 > > src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > > --- a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > > Tue Jun 04 13:47:59 2019 -0700 > > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > > Tue Jun 04 14:35:34 2019 -0700 > > @@ -41,6 +41,7 @@ > > > > > >

> > +

JDI Type Signatures

> >
JDI Type Signatures
> > > > > > diff -r 4158e6a864d4 src/jdk.jdi/share/classes/module-info.java > > --- a/src/jdk.jdi/share/classes/module-info.java Tue Jun 04 13:47:59 > > 2019 -0700 > > +++ b/src/jdk.jdi/share/classes/module-info.java Tue Jun 04 14:35:34 > > 2019 -0700 > > @@ -46,7 +46,7 @@ > > * This module includes a simple command-line debugger, > > * {@index jdb jdb tool}. > > * > > - *

Global Exceptions

> > + *

Global Exceptions

> > *

> > * This section documents exceptions which apply to the entire API > > and are thus > > * not documented on individual methods. > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 5 01:40:26 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Jun 2019 18:40:26 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> <9c97c6b6-b252-8140-f052-73deade6c313@oracle.com> <03c799bc-30b8-eedd-026f-9b4b7359939b@oracle.com> Message-ID: <19ddd2ea-5386-e2b0-4a54-1cbc7394dec4@oracle.com> Thanks a lot, Jc! Serguei On 6/4/19 6:36 PM, Jean Christophe Beyler wrote: > Hi Serguei, > > Looks good to me too :) > Jc > > On Tue, Jun 4, 2019 at 6:21 PM > wrote: > > Thanks a lot, Alex! > Serguei > > On 6/4/19 6:18 PM, Alex Menkov wrote: > > The fix looks good to me. > > > > --alex > > > > On 06/04/2019 16:30, serguei.spitsyn at oracle.com > wrote: > >> Please, review a fix for the JVMTI spec bug: > >> https://bugs.openjdk.java.net/browse/JDK-8205126 > >> > >> Webrev: > >> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ > > > >> > >> > >> > >> Related CSR: > >> https://bugs.openjdk.java.net/browse/JDK-8225142 > >> > >> Specdiff: > >> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ > > > >> > >> > >> > >> Summary: > >> ?? The JVMTI PopFrame() spec does not match the implementation. > >> ?? It says the? specified thread can not be the current thread. > >> ?? The fix aligns: > >> ??? - spec with implementaion > >> ??? - PopFrame spec with ForceEarlyReturn spec > >> > >> Thanks, > >> Serguei > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed Jun 5 01:43:27 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 5 Jun 2019 10:43:27 +0900 Subject: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> Message-ID: PING: Could you review them? > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ CSR status is provisional. So I need reviewers both CSR and webrev. Thanks, Yasumasa 2019?5?29?(?) 22:37 Yasumasa Suenaga : > > Hi all, > > Please review this change: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > > In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can connect to > debug server (jsadebugd). However it has not done so since JDK 9 because > jhsdb cannot accept the attach request to debug server. > So I want to introduce new option `--remote` to connect to debug server. > > I created CSR for this issue. So please review it together. > > > Thanks, > > Yasumasa From serguei.spitsyn at oracle.com Wed Jun 5 01:52:23 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Jun 2019 18:52:23 -0700 Subject: RFR (L): 8225325: Add tests for redefining a class' private method during resolution of the bootstrap specifier Message-ID: <86eb2654-5cf6-f107-38ca-bb7b53b1cb6b@oracle.com> Please, review 2 new tests for the test enhancement: ? https://bugs.openjdk.java.net/browse/JDK-8225325 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8225325-jvmti-redef-tests.1/ Summary: ? The tests were originally developed by Lois. ? So, I need to be counted as a reviewer. :) ? Lois already looked at the tests and approved their refactoring. ? These tests were not pushed the following bug was hit: ??? https://bugs.openjdk.java.net/browse/JDK-8191496 ? It looked like that bug was somehow caused by the InMemoryJavaCompiler ? framework that was used for testing. The issue disappeared after the tests ? were re-written to use a modern testing technique where the redefined ? classes are present in separate files instead of Java strings. ? I've just closed the 8191496 as NAI. Thanks, Serguei From jcbeyler at google.com Wed Jun 5 02:15:11 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 4 Jun 2019 19:15:11 -0700 Subject: RFR (L): 8225325: Add tests for redefining a class' private method during resolution of the bootstrap specifier In-Reply-To: <86eb2654-5cf6-f107-38ca-bb7b53b1cb6b@oracle.com> References: <86eb2654-5cf6-f107-38ca-bb7b53b1cb6b@oracle.com> Message-ID: Hi Serguei, The tests look good to me. I would have renamed test_math to testMath but there is precedence with the other tests in jtreg so... Jc On Tue, Jun 4, 2019 at 6:53 PM wrote: > Please, review 2 new tests for the test enhancement: > https://bugs.openjdk.java.net/browse/JDK-8225325 > > Webrev: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8225325-jvmti-redef-tests.1/ > > > Summary: > The tests were originally developed by Lois. > So, I need to be counted as a reviewer. :) > Lois already looked at the tests and approved their refactoring. > > These tests were not pushed the following bug was hit: > https://bugs.openjdk.java.net/browse/JDK-8191496 > > It looked like that bug was somehow caused by the InMemoryJavaCompiler > framework that was used for testing. The issue disappeared after the > tests > were re-written to use a modern testing technique where the redefined > classes are present in separate files instead of Java strings. > > I've just closed the 8191496 as NAI. > > Thanks, > Serguei > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Jun 5 02:34:30 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 4 Jun 2019 19:34:30 -0700 Subject: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> Message-ID: Hi Yasumasa, I'm not an official reviewer but I don't see an issue with the CSR (except that this seems to be bringing a fork in the tools with some handling remote and others not). However, this code is really repetitive and this is not the place to do a big refactor probably but we could do a few nits perhaps: - Instead of every tool calling commonHelp with an additional flag you could divide into commonHelp and commonHelpWithRemote for the tools and they both call the current commonHelp with that boolean; so that when we are looking at the tool code we know what we are getting... So something like: private static boolean commonHelp(String mode, boolean canConnectToRemote) { .. } private static boolean commonHelp(String mode) { return commonHelp(mode, false); } private static boolean commonHelpWithRemote(String mode) { return commonHelp(mode, false); } and that way the tools that change are just going from: - return commonHelp("jmap"); + return commonHelpWithRemote("jmap"); - In the same vein, instead of passing null to the buildAttachArgs; you could make a variable null: - buildAttachArgs(newArgs, pid, exe, core, true); + String noRemote = null; + buildAttachArgs(newArgs, pid, exe, core, noRemote, true); - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html Nit: you have empty lines at l64 and l73 - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html Nit : you have an empty line at l110 - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... All of these are details, I just thought I'd mention them :) Jc On Tue, Jun 4, 2019 at 6:44 PM Yasumasa Suenaga wrote: > PING: Could you review them? > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > > CSR status is provisional. So I need reviewers both CSR and webrev. > > > Thanks, > > Yasumasa > > > 2019?5?29?(?) 22:37 Yasumasa Suenaga : > > > > Hi all, > > > > Please review this change: > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > > > > In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can connect to > > debug server (jsadebugd). However it has not done so since JDK 9 because > > jhsdb cannot accept the attach request to debug server. > > So I want to introduce new option `--remote` to connect to debug server. > > > > I created CSR for this issue. So please review it together. > > > > > > Thanks, > > > > Yasumasa > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed Jun 5 05:06:12 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 5 Jun 2019 14:06:12 +0900 Subject: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> Message-ID: Hi Jc, Thank you for your comment! I updated a webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... I created DebugdUtils for convenience class for attach - detach mechanism of debug server. IMHO it is prefer "detach" to "close" in this case. Thanks, Yasumasa 2019?6?5?(?) 11:34 Jean Christophe Beyler : > > Hi Yasumasa, > > I'm not an official reviewer but I don't see an issue with the CSR (except that this seems to be bringing a fork in the tools with some handling remote and others not). > > However, this code is really repetitive and this is not the place to do a big refactor probably but we could do a few nits perhaps: > - Instead of every tool calling commonHelp with an additional flag you could divide into commonHelp and commonHelpWithRemote for the tools and they both call the current commonHelp with that boolean; so that when we are looking at the tool code we know what we are getting... So something like: > > private static boolean commonHelp(String mode, boolean canConnectToRemote) { > .. > } > > private static boolean commonHelp(String mode) { > return commonHelp(mode, false); > } > > private static boolean commonHelpWithRemote(String mode) { > return commonHelp(mode, false); > } > > and that way the tools that change are just going from: > - return commonHelp("jmap"); > + return commonHelpWithRemote("jmap"); > > - In the same vein, instead of passing null to the buildAttachArgs; you could make a variable null: > > - buildAttachArgs(newArgs, pid, exe, core, true); > + String noRemote = null; > + buildAttachArgs(newArgs, pid, exe, core, noRemote, true); > > > - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html > Nit: you have empty lines at l64 and l73 > > - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html > Nit : you have an empty line at l110 > > - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... > > All of these are details, I just thought I'd mention them :) > Jc > > On Tue, Jun 4, 2019 at 6:44 PM Yasumasa Suenaga wrote: >> >> PING: Could you review them? >> >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 >> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >> >> CSR status is provisional. So I need reviewers both CSR and webrev. >> >> >> Thanks, >> >> Yasumasa >> >> >> 2019?5?29?(?) 22:37 Yasumasa Suenaga : >> > >> > Hi all, >> > >> > Please review this change: >> > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 >> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >> > >> > In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can connect to >> > debug server (jsadebugd). However it has not done so since JDK 9 because >> > jhsdb cannot accept the attach request to debug server. >> > So I want to introduce new option `--remote` to connect to debug server. >> > >> > I created CSR for this issue. So please review it together. >> > >> > >> > Thanks, >> > >> > Yasumasa > > > > -- > > Thanks, > Jc From chris.plummer at oracle.com Wed Jun 5 05:17:44 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 4 Jun 2019 22:17:44 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: <36644087-6bf1-e549-f372-041f45058186@oracle.com> References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> Message-ID: <2998b809-ae51-3392-862e-4cd0c496c9df@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 5 06:22:26 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Jun 2019 23:22:26 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: <2998b809-ae51-3392-862e-4cd0c496c9df@oracle.com> References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> <2998b809-ae51-3392-862e-4cd0c496c9df@oracle.com> Message-ID: <743e8136-fe86-cffb-63d1-078540e3983e@oracle.com> Hi Chris, Thank you a lot for reviewing this! On 6/4/19 22:17, Chris Plummer wrote: > Hi Serguei, > > Although a nit, what I was getting at in the CSR discussion is this > inconsistency: > > 2827???????? The specified thread must be suspended or must be the > current thread. > 2940 ????????? Thread was not the current thread and was not suspended. > > The second line reverses the order of the requirements given in the > first line. While both are correct, it would be nice if they both > presented the requirements in the same order. The line at 2940 used to > read: > > 2940?????????? Thread was not suspended and was not the current thread. > > Which if left unchanged (and also used as the replacement text for > line 2852) then all the lines would consistent. Okay, thanks. Then, there are 6 similar spots in the ForceEarlyReturn functions which also have to be consistent. All of them originally state this: ? "Thread was not the current thread and was not suspended." I hope, the update v2 below makes all the spots consistent. Updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/ Updated JVMTI spec: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti.html Updated specdiff: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti-specdiff Thanks, Serguei > > thanks, > > Chris > > On 6/4/19 4:30 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for the JVMTI spec bug: >> https://bugs.openjdk.java.net/browse/JDK-8205126 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ >> >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8225142 >> >> Specdiff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >> >> >> Summary: >> ? The JVMTI PopFrame() spec does not match the implementation. >> ? It says the? specified thread can not be the current thread. >> ? The fix aligns: >> ?? - spec with implementaion >> ?? - PopFrame spec with ForceEarlyReturn spec >> >> Thanks, >> Serguei > > From david.holmes at oracle.com Wed Jun 5 12:57:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Jun 2019 22:57:07 +1000 Subject: RFR (L): 8225325: Add tests for redefining a class' private method during resolution of the bootstrap specifier In-Reply-To: <86eb2654-5cf6-f107-38ca-bb7b53b1cb6b@oracle.com> References: <86eb2654-5cf6-f107-38ca-bb7b53b1cb6b@oracle.com> Message-ID: <7435ce27-eebe-a432-620d-c0d0fca555fa@oracle.com> Hi Serguei, Lois, Tests looks good. Thanks, David On 5/06/2019 11:52 am, serguei.spitsyn at oracle.com wrote: > Please, review 2 new tests for the test enhancement: > ? https://bugs.openjdk.java.net/browse/JDK-8225325 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8225325-jvmti-redef-tests.1/ > > > > Summary: > ? The tests were originally developed by Lois. > ? So, I need to be counted as a reviewer. :) > ? Lois already looked at the tests and approved their refactoring. > > ? These tests were not pushed the following bug was hit: > ??? https://bugs.openjdk.java.net/browse/JDK-8191496 > > ? It looked like that bug was somehow caused by the InMemoryJavaCompiler > ? framework that was used for testing. The issue disappeared after the > tests > ? were re-written to use a modern testing technique where the redefined > ? classes are present in separate files instead of Java strings. > > ? I've just closed the 8191496 as NAI. > > Thanks, > Serguei > From daniel.daugherty at oracle.com Wed Jun 5 15:12:01 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 5 Jun 2019 11:12:01 -0400 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: <743e8136-fe86-cffb-63d1-078540e3983e@oracle.com> References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> <2998b809-ae51-3392-862e-4cd0c496c9df@oracle.com> <743e8136-fe86-cffb-63d1-078540e3983e@oracle.com> Message-ID: <9e21382d-ce68-ba14-8cde-47f80f8e2a03@oracle.com> On 6/5/19 2:22 AM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > > Thank you a lot for reviewing this! > > > On 6/4/19 22:17, Chris Plummer wrote: >> Hi Serguei, >> >> Although a nit, what I was getting at in the CSR discussion is this >> inconsistency: >> >> 2827???????? The specified thread must be suspended or must be the >> current thread. >> 2940 ????????? Thread was not the current thread and was not suspended. >> >> The second line reverses the order of the requirements given in the >> first line. While both are correct, it would be nice if they both >> presented the requirements in the same order. The line at 2940 used >> to read: >> >> 2940?????????? Thread was not suspended and was not the current thread. >> >> Which if left unchanged (and also used as the replacement text for >> line 2852) then all the lines would consistent. > > Okay, thanks. > > Then, there are 6 similar spots in the ForceEarlyReturn > functions which also have to be consistent. > All of them originally state this: > ? "Thread was not the current thread and was not suspended." > > I hope, the update v2 below makes all the spots consistent. > > Updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/ > src/hotspot/share/prims/jvmti.xml ??? No comments. Thumbs up! Thanks for making the wording consistent. Dan > > > Updated JVMTI spec: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti.html > > > Updated specdiff: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti-specdiff > > > > Thanks, > Serguei > > >> >> thanks, >> >> Chris >> >> On 6/4/19 4:30 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for the JVMTI spec bug: >>> https://bugs.openjdk.java.net/browse/JDK-8205126 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ >>> >>> >>> >>> Related CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8225142 >>> >>> Specdiff: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >>> >>> >>> >>> Summary: >>> ? The JVMTI PopFrame() spec does not match the implementation. >>> ? It says the? specified thread can not be the current thread. >>> ? The fix aligns: >>> ?? - spec with implementaion >>> ?? - PopFrame spec with ForceEarlyReturn spec >>> >>> Thanks, >>> Serguei >> >> > From thomas.stuefe at gmail.com Wed Jun 5 16:50:47 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Jun 2019 18:50:47 +0200 Subject: RFR(T): 8225348: serviceability/dcmd/vm/EventsTest.java failed Message-ID: Hi all, may I have a small review please for this patch: cr: http://cr.openjdk.java.net/~stuefe/webrevs/8225348-eventstest-failed/webrev.00/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8225348 JDK-8224600 introduced a new jcmd, VM.events, and an associated test. In run_selected(CommandExecutor executor), I want to make sure the "Events" log is not printed and therefore scan for "Events" on stdout, but that term is too broad and can be part of normal output, giving a false positive. Fix is to make the pattern matching more strict. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Jun 5 16:59:43 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 5 Jun 2019 09:59:43 -0700 Subject: RFR(T): 8225348: serviceability/dcmd/vm/EventsTest.java failed In-Reply-To: References: Message-ID: Hi Thomas, Looks good to me. I would just nit that your example does not seem to exist in your regex selections :) (e.g. "Classes redefined (0 events):"). but you only check for Classes unloaded for example. Perhaps you could update the example to one of the regex you actually do check for ? Evidently no need of another webrev for that! Jc On Wed, Jun 5, 2019 at 9:52 AM Thomas St?fe wrote: > Hi all, > > may I have a small review please for this patch: > > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8225348-eventstest-failed/webrev.00/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8225348 > > JDK-8224600 introduced a new jcmd, VM.events, and an associated test. > > In run_selected(CommandExecutor executor), I want to make sure the > "Events" log is not printed and therefore scan for "Events" on stdout, but > that term is too broad and can be part of normal output, giving a false > positive. > > Fix is to make the pattern matching more strict. > > Thanks, Thomas > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Jun 5 17:08:45 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Jun 2019 19:08:45 +0200 Subject: RFR(T): 8225348: serviceability/dcmd/vm/EventsTest.java failed In-Reply-To: References: Message-ID: Hi JC, Thank you! I will change the comment as suggested. Cheers, Thomas On Wed, Jun 5, 2019, 18:59 Jean Christophe Beyler wrote: > Hi Thomas, > > Looks good to me. I would just nit that your example does not seem to > exist in your regex selections :) > > (e.g. "Classes redefined (0 events):"). > > but you only check for Classes unloaded for example. Perhaps you could > update the example to one of the regex you actually do check for ? > > Evidently no need of another webrev for that! > Jc > > On Wed, Jun 5, 2019 at 9:52 AM Thomas St?fe > wrote: > >> Hi all, >> >> may I have a small review please for this patch: >> >> cr: >> http://cr.openjdk.java.net/~stuefe/webrevs/8225348-eventstest-failed/webrev.00/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8225348 >> >> JDK-8224600 introduced a new jcmd, VM.events, and an associated test. >> >> In run_selected(CommandExecutor executor), I want to make sure the >> "Events" log is not printed and therefore scan for "Events" on stdout, but >> that term is too broad and can be part of normal output, giving a false >> positive. >> >> Fix is to make the pattern matching more strict. >> >> Thanks, Thomas >> > > > -- > > Thanks, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Jun 5 17:17:31 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Jun 2019 10:17:31 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: <743e8136-fe86-cffb-63d1-078540e3983e@oracle.com> References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> <2998b809-ae51-3392-862e-4cd0c496c9df@oracle.com> <743e8136-fe86-cffb-63d1-078540e3983e@oracle.com> Message-ID: Looks good! thanks, Chris On 6/4/19 11:22 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > > Thank you a lot for reviewing this! > > > On 6/4/19 22:17, Chris Plummer wrote: >> Hi Serguei, >> >> Although a nit, what I was getting at in the CSR discussion is this >> inconsistency: >> >> 2827???????? The specified thread must be suspended or must be the >> current thread. >> 2940 ????????? Thread was not the current thread and was not suspended. >> >> The second line reverses the order of the requirements given in the >> first line. While both are correct, it would be nice if they both >> presented the requirements in the same order. The line at 2940 used >> to read: >> >> 2940?????????? Thread was not suspended and was not the current thread. >> >> Which if left unchanged (and also used as the replacement text for >> line 2852) then all the lines would consistent. > > Okay, thanks. > > Then, there are 6 similar spots in the ForceEarlyReturn > functions which also have to be consistent. > All of them originally state this: > ? "Thread was not the current thread and was not suspended." > > I hope, the update v2 below makes all the spots consistent. > > Updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/ > > > > Updated JVMTI spec: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti.html > > > Updated specdiff: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti-specdiff > > > > Thanks, > Serguei > > >> >> thanks, >> >> Chris >> >> On 6/4/19 4:30 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for the JVMTI spec bug: >>> https://bugs.openjdk.java.net/browse/JDK-8205126 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ >>> >>> >>> >>> Related CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8225142 >>> >>> Specdiff: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >>> >>> >>> >>> Summary: >>> ? The JVMTI PopFrame() spec does not match the implementation. >>> ? It says the? specified thread can not be the current thread. >>> ? The fix aligns: >>> ?? - spec with implementaion >>> ?? - PopFrame spec with ForceEarlyReturn spec >>> >>> Thanks, >>> Serguei >> >> > From chris.plummer at oracle.com Wed Jun 5 17:22:01 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Jun 2019 10:22:01 -0700 Subject: RFR(T): 8225348: serviceability/dcmd/vm/EventsTest.java failed In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Jun 5 17:28:09 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Jun 2019 19:28:09 +0200 Subject: RFR(T): 8225348: serviceability/dcmd/vm/EventsTest.java failed In-Reply-To: References: Message-ID: Thank you Chris. On Wed, Jun 5, 2019, 19:22 Chris Plummer wrote: > Looks good. Thanks for fixing quickly. > > Chris > > On 6/5/19 9:50 AM, Thomas St?fe wrote: > > Hi all, > > may I have a small review please for this patch: > > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8225348-eventstest-failed/webrev.00/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8225348 > > JDK-8224600 introduced a new jcmd, VM.events, and an associated test. > > In run_selected(CommandExecutor executor), I want to make sure the > "Events" log is not printed and therefore scan for "Events" on stdout, but > that term is too broad and can be part of normal output, giving a false > positive. > > Fix is to make the pattern matching more strict. > > Thanks, Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 5 17:59:55 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 5 Jun 2019 10:59:55 -0700 Subject: RFR (L): 8225325: Add tests for redefining a class' private method during resolution of the bootstrap specifier In-Reply-To: <7435ce27-eebe-a432-620d-c0d0fca555fa@oracle.com> References: <86eb2654-5cf6-f107-38ca-bb7b53b1cb6b@oracle.com> <7435ce27-eebe-a432-620d-c0d0fca555fa@oracle.com> Message-ID: Hi David, Thank you a lot! Serguei On 6/5/19 05:57, David Holmes wrote: > Hi Serguei, Lois, > > Tests looks good. > > Thanks, > David > > On 5/06/2019 11:52 am, serguei.spitsyn at oracle.com wrote: >> Please, review 2 new tests for the test enhancement: >> ?? https://bugs.openjdk.java.net/browse/JDK-8225325 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8225325-jvmti-redef-tests.1/ >> >> >> >> Summary: >> ?? The tests were originally developed by Lois. >> ?? So, I need to be counted as a reviewer. :) >> ?? Lois already looked at the tests and approved their refactoring. >> >> ?? These tests were not pushed the following bug was hit: >> ???? https://bugs.openjdk.java.net/browse/JDK-8191496 >> >> ?? It looked like that bug was somehow caused by the >> InMemoryJavaCompiler >> ?? framework that was used for testing. The issue disappeared after >> the tests >> ?? were re-written to use a modern testing technique where the redefined >> ?? classes are present in separate files instead of Java strings. >> >> ?? I've just closed the 8191496 as NAI. >> >> Thanks, >> Serguei >> From serguei.spitsyn at oracle.com Wed Jun 5 18:01:53 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 5 Jun 2019 11:01:53 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: <9e21382d-ce68-ba14-8cde-47f80f8e2a03@oracle.com> References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> <2998b809-ae51-3392-862e-4cd0c496c9df@oracle.com> <743e8136-fe86-cffb-63d1-078540e3983e@oracle.com> <9e21382d-ce68-ba14-8cde-47f80f8e2a03@oracle.com> Message-ID: Thanks a lot, Dan! Serguei On 6/5/19 08:12, Daniel D. Daugherty wrote: > On 6/5/19 2:22 AM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> >> Thank you a lot for reviewing this! >> >> >> On 6/4/19 22:17, Chris Plummer wrote: >>> Hi Serguei, >>> >>> Although a nit, what I was getting at in the CSR discussion is this >>> inconsistency: >>> >>> 2827???????? The specified thread must be suspended or must be the >>> current thread. >>> 2940 ????????? Thread was not the current thread and was not suspended. >>> >>> The second line reverses the order of the requirements given in the >>> first line. While both are correct, it would be nice if they both >>> presented the requirements in the same order. The line at 2940 used >>> to read: >>> >>> 2940?????????? Thread was not suspended and was not the current thread. >>> >>> Which if left unchanged (and also used as the replacement text for >>> line 2852) then all the lines would consistent. >> >> Okay, thanks. >> >> Then, there are 6 similar spots in the ForceEarlyReturn >> functions which also have to be consistent. >> All of them originally state this: >> ? "Thread was not the current thread and was not suspended." >> >> I hope, the update v2 below makes all the spots consistent. >> >> Updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/ >> > > src/hotspot/share/prims/jvmti.xml > ??? No comments. > > Thumbs up! Thanks for making the wording consistent. > > Dan > > >> >> >> Updated JVMTI spec: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti.html >> >> >> Updated specdiff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti-specdiff >> >> >> >> Thanks, >> Serguei >> >> >>> >>> thanks, >>> >>> Chris >>> >>> On 6/4/19 4:30 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review a fix for the JVMTI spec bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8205126 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ >>>> >>>> >>>> >>>> Related CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8225142 >>>> >>>> Specdiff: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >>>> >>>> >>>> >>>> Summary: >>>> ? The JVMTI PopFrame() spec does not match the implementation. >>>> ? It says the? specified thread can not be the current thread. >>>> ? The fix aligns: >>>> ?? - spec with implementaion >>>> ?? - PopFrame spec with ForceEarlyReturn spec >>>> >>>> Thanks, >>>> Serguei >>> >>> >> > From serguei.spitsyn at oracle.com Wed Jun 5 18:03:09 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 5 Jun 2019 11:03:09 -0700 Subject: RFR(XS): 8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread In-Reply-To: References: <36644087-6bf1-e549-f372-041f45058186@oracle.com> <2998b809-ae51-3392-862e-4cd0c496c9df@oracle.com> <743e8136-fe86-cffb-63d1-078540e3983e@oracle.com> Message-ID: <3986909c-8e7b-bc00-3247-a755c5a11e2d@oracle.com> Thank you a lot, Chris! Serguei On 6/5/19 10:17, Chris Plummer wrote: > Looks good! > > thanks, > > Chris > > On 6/4/19 11:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> >> Thank you a lot for reviewing this! >> >> >> On 6/4/19 22:17, Chris Plummer wrote: >>> Hi Serguei, >>> >>> Although a nit, what I was getting at in the CSR discussion is this >>> inconsistency: >>> >>> 2827???????? The specified thread must be suspended or must be the >>> current thread. >>> 2940 ????????? Thread was not the current thread and was not suspended. >>> >>> The second line reverses the order of the requirements given in the >>> first line. While both are correct, it would be nice if they both >>> presented the requirements in the same order. The line at 2940 used >>> to read: >>> >>> 2940?????????? Thread was not suspended and was not the current thread. >>> >>> Which if left unchanged (and also used as the replacement text for >>> line 2852) then all the lines would consistent. >> >> Okay, thanks. >> >> Then, there are 6 similar spots in the ForceEarlyReturn >> functions which also have to be consistent. >> All of them originally state this: >> ? "Thread was not the current thread and was not suspended." >> >> I hope, the update v2 below makes all the spots consistent. >> >> Updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/ >> >> >> >> Updated JVMTI spec: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti.html >> >> >> Updated specdiff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.2/jvmti-specdiff >> >> >> >> Thanks, >> Serguei >> >> >>> >>> thanks, >>> >>> Chris >>> >>> On 6/4/19 4:30 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review a fix for the JVMTI spec bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8205126 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/ >>>> >>>> >>>> >>>> Related CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8225142 >>>> >>>> Specdiff: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ >>>> >>>> >>>> >>>> Summary: >>>> ? The JVMTI PopFrame() spec does not match the implementation. >>>> ? It says the? specified thread can not be the current thread. >>>> ? The fix aligns: >>>> ?? - spec with implementaion >>>> ?? - PopFrame spec with ForceEarlyReturn spec >>>> >>>> Thanks, >>>> Serguei >>> >>> >> > > From daniil.x.titov at oracle.com Thu Jun 6 02:36:10 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 05 Jun 2019 19:36:10 -0700 Subject: RFR: 8206074: nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java is timing out Message-ID: Please review a change that fixes the intermittent failure of the test. The problem here that there is a chance that a single step event had been posted after the step request was created and before it was deleted. The fix solves this by ensuring that vm.resume() is called at the end of the test. Webrev: http://cr.openjdk.java.net/~dtitov/8206074/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8206074 Thanks! --Daniil From chris.plummer at oracle.com Thu Jun 6 02:44:15 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Jun 2019 19:44:15 -0700 Subject: RFR: 8206074: nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java is timing out In-Reply-To: References: Message-ID: Hi Daniil, I understand the general issues that the debugger might delete a request after the event has already been generated but before the debugger has received it. Alan and I recently had a discussion about this and concluded that the debugger must be ready for this, otherwise the debug agent will have suspended threads and the debugger might never do anything to resume them (in fact I suspect I'm seeing this in a certain debugger). However, for the case of this test I would think it would be taking fine grain controlled over the requests and events, and would not delete the single step request until the event has been received and the thread is suspended. It can then delete the request and resume the thread (or all threads if using SUSPEND_ALL). Is there a reason the test is not already doing this? thanks, Chris On 6/5/19 7:36 PM, Daniil Titov wrote: > Please review a change that fixes the intermittent failure of the test. > > The problem here that there is a chance that a single step event had been posted after the step request was created and before it was deleted. > > The fix solves this by ensuring that vm.resume() is called at the end of the test. > > Webrev: http://cr.openjdk.java.net/~dtitov/8206074/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8206074 > > Thanks! > --Daniil > > > From daniil.x.titov at oracle.com Thu Jun 6 03:03:31 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 05 Jun 2019 20:03:31 -0700 Subject: 8206074: nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java is timing out In-Reply-To: References: Message-ID: Hi Chris, > and would not delete the single step request until the event has been received and the thread is suspended. In this test there is no guarantee that this single step event is ever posted. In the most of the cases by the time the step request is created the debuggee is already waiting on line 42 for blocking IO somewhere inside pipe.readlln(). And since the test sends the command to the pipe only after it deletes the step request the debuggee continues without posting the step event. 34 public class crstepreq001t { 35 public static void main(String args[]) { 36 ArgumentHandler argHandler = new ArgumentHandler(args); 37 IOPipe pipe = argHandler.createDebugeeIOPipe(); 38 Thread thr = Thread.currentThread(); 39 40 thr.setName(crstepreq001.DEBUGGEE_THRD); 41 pipe.println(crstepreq001.COMMAND_READY); 42 String cmd = pipe.readln(); 43 if (!cmd.equals(crstepreq001.COMMAND_QUIT)) { 44 System.err.println("TEST BUG: unknown debugger command: " 45 + cmd); 46 System.exit(crstepreq001.JCK_STATUS_BASE + 47 crstepreq001.FAILED); 48 } 49 System.exit(crstepreq001.JCK_STATUS_BASE + 50 crstepreq001.PASSED); 51 } Best regards, --Daniil ?On 6/5/19, 7:44 PM, "Chris Plummer" wrote: Hi Daniil, I understand the general issues that the debugger might delete a request after the event has already been generated but before the debugger has received it. Alan and I recently had a discussion about this and concluded that the debugger must be ready for this, otherwise the debug agent will have suspended threads and the debugger might never do anything to resume them (in fact I suspect I'm seeing this in a certain debugger). However, for the case of this test I would think it would be taking fine grain controlled over the requests and events, and would not delete the single step request until the event has been received and the thread is suspended. It can then delete the request and resume the thread (or all threads if using SUSPEND_ALL). Is there a reason the test is not already doing this? thanks, Chris On 6/5/19 7:36 PM, Daniil Titov wrote: > Please review a change that fixes the intermittent failure of the test. > > The problem here that there is a chance that a single step event had been posted after the step request was created and before it was deleted. > > The fix solves this by ensuring that vm.resume() is called at the end of the test. > > Webrev: http://cr.openjdk.java.net/~dtitov/8206074/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8206074 > > Thanks! > --Daniil > > > From chris.plummer at oracle.com Thu Jun 6 04:18:04 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Jun 2019 21:18:04 -0700 Subject: 8206074: nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java is timing out In-Reply-To: References: Message-ID: <3f06a384-ed0e-c154-ce14-3da6b1ea7155@oracle.com> Ok. Looks like the test is just making sure there are no errors (or the errors are expected) when creating the StepRequest, but doesn't not actually deal with any SingleStep events. Fix looks good. thanks, Chris On 6/5/19 8:03 PM, Daniil Titov wrote: > Hi Chris, > >> and would not delete the single step request until the event has been received and the thread is suspended. > In this test there is no guarantee that this single step event is ever posted. In the most of the cases by the time the step request > is created the debuggee is already waiting on line 42 for blocking IO somewhere inside pipe.readlln(). And since the test sends the command to the pipe > only after it deletes the step request the debuggee continues without posting the step event. > > > 34 public class crstepreq001t { > 35 public static void main(String args[]) { > 36 ArgumentHandler argHandler = new ArgumentHandler(args); > 37 IOPipe pipe = argHandler.createDebugeeIOPipe(); > 38 Thread thr = Thread.currentThread(); > 39 > 40 thr.setName(crstepreq001.DEBUGGEE_THRD); > 41 pipe.println(crstepreq001.COMMAND_READY); > 42 String cmd = pipe.readln(); > 43 if (!cmd.equals(crstepreq001.COMMAND_QUIT)) { > 44 System.err.println("TEST BUG: unknown debugger command: " > 45 + cmd); > 46 System.exit(crstepreq001.JCK_STATUS_BASE + > 47 crstepreq001.FAILED); > 48 } > 49 System.exit(crstepreq001.JCK_STATUS_BASE + > 50 crstepreq001.PASSED); > 51 } > > > > Best regards, > --Daniil > > ?On 6/5/19, 7:44 PM, "Chris Plummer" wrote: > > Hi Daniil, > > I understand the general issues that the debugger might delete a request > after the event has already been generated but before the debugger has > received it. Alan and I recently had a discussion about this and > concluded that the debugger must be ready for this, otherwise the debug > agent will have suspended threads and the debugger might never do > anything to resume them (in fact I suspect I'm seeing this in a certain > debugger). However, for the case of this test I would think it would be > taking fine grain controlled over the requests and events, and would not > delete the single step request until the event has been received and the > thread is suspended. It can then delete the request and resume the > thread (or all threads if using SUSPEND_ALL). Is there a reason the test > is not already doing this? > > thanks, > > Chris > > On 6/5/19 7:36 PM, Daniil Titov wrote: > > Please review a change that fixes the intermittent failure of the test. > > > > The problem here that there is a chance that a single step event had been posted after the step request was created and before it was deleted. > > > > The fix solves this by ensuring that vm.resume() is called at the end of the test. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8206074/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8206074 > > > > Thanks! > > --Daniil > > > > > > > > > > From gary.adams at oracle.com Thu Jun 6 14:46:36 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 06 Jun 2019 10:46:36 -0400 Subject: RFR: 8206074: nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java is timing out In-Reply-To: References: Message-ID: <5CF9274C.3090606@oracle.com> This fix looks good to me. We've plugged a number of edge cases in the tests where the timing of debuggee and debugger processes was not guaranteed during shutdown of the test. The only improvement we could add here is to test if the vm is suspended, but an extra resume does no harm to ensure the debuggee is running to receive the quit message. On 6/5/19, 10:36 PM, Daniil Titov wrote: > Please review a change that fixes the intermittent failure of the test. > > The problem here that there is a chance that a single step event had been posted after the step request was created and before it was deleted. > > The fix solves this by ensuring that vm.resume() is called at the end of the test. > > Webrev: http://cr.openjdk.java.net/~dtitov/8206074/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8206074 > > Thanks! > --Daniil > > > From leonid.mesnik at oracle.com Fri Jun 7 00:36:01 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 6 Jun 2019 17:36:01 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. Message-ID: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> Hi Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8225388 Leonid From daniil.x.titov at oracle.com Fri Jun 7 01:04:58 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 06 Jun 2019 18:04:58 -0700 Subject: 8206074: nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java is timing out In-Reply-To: <5CF9274C.3090606@oracle.com> References: <5CF9274C.3090606@oracle.com> Message-ID: <172EB3CF-9C92-452E-8311-A9606B8AB7A3@oracle.com> Thank you, Gary and Chris, for reviewing this change. Best regards, --Daniil ?On 6/6/19, 7:46 AM, "Gary Adams" wrote: This fix looks good to me. We've plugged a number of edge cases in the tests where the timing of debuggee and debugger processes was not guaranteed during shutdown of the test. The only improvement we could add here is to test if the vm is suspended, but an extra resume does no harm to ensure the debuggee is running to receive the quit message. On 6/5/19, 10:36 PM, Daniil Titov wrote: > Please review a change that fixes the intermittent failure of the test. > > The problem here that there is a chance that a single step event had been posted after the step request was created and before it was deleted. > > The fix solves this by ensuring that vm.resume() is called at the end of the test. > > Webrev: http://cr.openjdk.java.net/~dtitov/8206074/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8206074 > > Thanks! > --Daniil > > > From tobias.hartmann at oracle.com Fri Jun 7 08:07:24 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 7 Jun 2019 10:07:24 +0200 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> Message-ID: <328960e6-67d8-efa7-66b2-128a39d51259@oracle.com> Hi Leonid, this looks good to me! Please remove the extra whitespace at the end of compileBroker.hpp:420 before the ")". No new webrev required. Thanks, Tobias On 07.06.19 02:36, Leonid Mesnik wrote: > Hi > > Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics > command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 > passed. > > webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8225388 > > Leonid > > From serguei.spitsyn at oracle.com Fri Jun 7 08:37:37 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Jun 2019 01:37:37 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> Message-ID: <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Fri Jun 7 14:24:34 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 7 Jun 2019 15:24:34 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners Message-ID: Hi, Please can I request a sponsor and review of this patch for JDK-8225474. A problem that we have seen intermittently with JDI connector stress tests for quite a while that is caused by an non-thread safe HashMap in the connector class. I've created a standalone testcase that reproduces it reliably. http://cr.openjdk.java.net/~aleonard/8225474/webrev.00 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Fri Jun 7 16:10:58 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 7 Jun 2019 09:10:58 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> Message-ID: <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> Hi Currently DCmdArgument is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc. Adding new type DCmdArgument requires adding more specialized methods like template <> void DCmdArgument::parse_value(const char* str, size_t len, TRAPS) { and other to parse and validate any *integer* parameters. See http://hg.openjdk.java.net/jdk/jdk/file/47ee6c00d27c/src/hotspot/share/services/diagnosticArgument.cpp#l112 I think that it is easier to use single jlong for all integer like it is done now rather than adding more types. One might said that it would be better to add size_t type and use it for all non-negative integers. It would be good improvement for all dcmd args parsing. As well as overall improvement of parameters validation. (dcmd often don't throw exception and just return in the case of incorrect arguments). But sees like separate effort for whole dcmd framework. Leonid > On Jun 7, 2019, at 1:37 AM, serguei.spitsyn at oracle.com wrote: > > Hi Leonid, > > It looks good to me. > One minor comment on the src/hotspot/share/services/diagnosticCommand.?pp > + DCmdArgument _granularity; > > I'm curios if using size_t instead of jlong as in other files would be more unified. > > Thanks, > Serguei > > > > On 6/6/19 17:36, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >> >> Leonid >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.field at oracle.com Fri Jun 7 16:42:46 2019 From: robert.field at oracle.com (Robert Field) Date: Fri, 7 Jun 2019 09:42:46 -0700 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: Thanks Andrew! Can I add my support for this.? I imagine this could be the cause of JShell failures in high-concurrency testing (JShell uses JDI, the failures are in connection). This is not a review, as I haven't been on the JPDA team for a LONG time. Just a request that this be prioritized. Thanks, Robert On 6/7/19 7:24 AM, Andrew Leonard wrote: > Hi, > Please can I request a sponsor and review of this patch for > JDK-8225474. A problem that we have seen intermittently with JDI > connector stress tests for quite a while that is caused by an > non-thread safe HashMap in the connector class. I've created a > standalone testcase that reproduces it reliably. > http://cr.openjdk.java.net/~aleonard/8225474/webrev.00 > > Thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jun 7 16:48:33 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Jun 2019 09:48:33 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> Message-ID: <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Fri Jun 7 18:23:35 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 7 Jun 2019 11:23:35 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> Message-ID: I read documentation about CRS on following wiki https://wiki.openjdk.java.net/display/csr . It says that CRS requires if command-line options are changes. However I believe that fix don't change actual behavior of 'granularity' option so no CSR is needed for this small help update. Any advise is welcome. Leonid > On Jun 7, 2019, at 9:48 AM, serguei.spitsyn at oracle.com wrote: > > Okay then. > I wonder now, if a CSR needs to be filed for this change. > > Thanks, > Serguei > > > On 6/7/19 09:10, Leonid Mesnik wrote: >> Hi >> >> Currently DCmdArgument is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc. >> >> Adding new type DCmdArgument requires adding more specialized methods like >> template <> void DCmdArgument::parse_value(const char* str, >> size_t len, TRAPS) { >> >> and other to parse and validate any *integer* parameters. See >> http://hg.openjdk.java.net/jdk/jdk/file/47ee6c00d27c/src/hotspot/share/services/diagnosticArgument.cpp#l112 >> >> I think that it is easier to use single jlong for all integer like it is done now rather than adding more types. >> >> One might said that it would be better to add size_t type and use it for all non-negative integers. It would be good improvement for all dcmd args parsing. As well as overall improvement of parameters validation. (dcmd often don't throw exception and just return in the case of incorrect arguments). But sees like separate effort for whole dcmd framework. >> >> >> Leonid >>> On Jun 7, 2019, at 1:37 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Hi Leonid, >>> >>> It looks good to me. >>> One minor comment on the src/hotspot/share/services/diagnosticCommand.?pp >>> + DCmdArgument _granularity; >>> >>> I'm curios if using size_t instead of jlong as in other files would be more unified. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 6/6/19 17:36, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. >>>> >>>> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >>>> >>>> Leonid >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jun 7 18:29:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Jun 2019 11:29:14 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Jun 7 18:47:06 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 07 Jun 2019 11:47:06 -0700 Subject: RFR: 8222828: vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java failed Message-ID: Please review the change that fixes an intermittent failure of the test when it is run with Graal on. The test starts a debuggee and sets the method entry breakpoint for tc02x004aClass1 class that has only constructor defined. The debuggee starts 3 threads and each of them creates a new instance of tc02x004aClass1 class. The test waits for receiving 3 method entry events (posted when the constructor of tc02x004aClass1 is invoked) during a specific amount of time. The problem here is that with Graal on it takes more time for the test to run and occasionally the test stops listening for events before all method entry events are delivered. The fix ensures that the time the test waits for receiving method entry events is adjusted for test.timeout.factor factor. The fix also makes the test waiting till the debuggee terminates before exiting. Webrev: http://cr.openjdk.java.net/~dtitov/8222828/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8222828 Thanks! -Daniil From jcbeyler at google.com Fri Jun 7 18:55:06 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 7 Jun 2019 11:55:06 -0700 Subject: RFR: 8222828: vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java failed In-Reply-To: References: Message-ID: Hi Daniil, Looks good to me :) Thanks, Jc On Fri, Jun 7, 2019 at 11:47 AM Daniil Titov wrote: > Please review the change that fixes an intermittent failure of the test > when it is run with Graal on. > > The test starts a debuggee and sets the method entry breakpoint for > tc02x004aClass1 class that has only constructor defined. > The debuggee starts 3 threads and each of them creates a new instance of > tc02x004aClass1 class. The test waits for receiving > 3 method entry events (posted when the constructor of tc02x004aClass1 is > invoked) during a specific amount of time. > > The problem here is that with Graal on it takes more time for the test to > run and occasionally the test stops listening for events > before all method entry events are delivered. > > The fix ensures that the time the test waits for receiving method entry > events is adjusted for test.timeout.factor factor. > > The fix also makes the test waiting till the debuggee terminates before > exiting. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222828/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222828 > > Thanks! > -Daniil > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Jun 7 19:03:53 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 7 Jun 2019 15:03:53 -0400 Subject: RFR: 8222828: vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java failed In-Reply-To: References: Message-ID: <53dad8ef-bfec-11d9-fdfb-c8cbb6add819@oracle.com> Looks good to me. Any other graal test timeouts that might be addressed in a similar manner? On 6/7/19 2:47 PM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of the test when it is run with Graal on. > > The test starts a debuggee and sets the method entry breakpoint for tc02x004aClass1 class that has only constructor defined. > The debuggee starts 3 threads and each of them creates a new instance of tc02x004aClass1 class. The test waits for receiving > 3 method entry events (posted when the constructor of tc02x004aClass1 is invoked) during a specific amount of time. > > The problem here is that with Graal on it takes more time for the test to run and occasionally the test stops listening for events > before all method entry events are delivered. > > The fix ensures that the time the test waits for receiving method entry events is adjusted for test.timeout.factor factor. > > The fix also makes the test waiting till the debuggee terminates before exiting. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222828/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222828 > > Thanks! > -Daniil > > From chris.plummer at oracle.com Fri Jun 7 19:31:46 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 7 Jun 2019 12:31:46 -0700 Subject: RFR: 8222828: vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java failed In-Reply-To: References: Message-ID: <042e0969-a95e-3abd-0636-53e82fdd0e37@oracle.com> Looks good. Chris On 6/7/19 11:47 AM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of the test when it is run with Graal on. > > The test starts a debuggee and sets the method entry breakpoint for tc02x004aClass1 class that has only constructor defined. > The debuggee starts 3 threads and each of them creates a new instance of tc02x004aClass1 class. The test waits for receiving > 3 method entry events (posted when the constructor of tc02x004aClass1 is invoked) during a specific amount of time. > > The problem here is that with Graal on it takes more time for the test to run and occasionally the test stops listening for events > before all method entry events are delivered. > > The fix ensures that the time the test waits for receiving method entry events is adjusted for test.timeout.factor factor. > > The fix also makes the test waiting till the debuggee terminates before exiting. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222828/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222828 > > Thanks! > -Daniil > > From leonid.mesnik at oracle.com Fri Jun 7 21:12:53 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 7 Jun 2019 14:12:53 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: <328960e6-67d8-efa7-66b2-128a39d51259@oracle.com> References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <328960e6-67d8-efa7-66b2-128a39d51259@oracle.com> Message-ID: <9C63833C-6547-4047-A031-B41E799090E9@oracle.com> Thank you for review. Leonid > On Jun 7, 2019, at 1:07 AM, Tobias Hartmann wrote: > > Hi Leonid, > > this looks good to me! Please remove the extra whitespace at the end of compileBroker.hpp:420 before > the ")". No new webrev required. > > Thanks, > Tobias > > On 07.06.19 02:36, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics >> command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 >> passed. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >> >> Leonid >> >> From leonid.mesnik at oracle.com Fri Jun 7 21:13:01 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 7 Jun 2019 14:13:01 -0700 Subject: RFR(S): 8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash. In-Reply-To: References: <9a88213f-2147-db63-17da-92a6bf9f4f01@oracle.com> <19256dda-08cc-f999-6472-d95e149655e6@oracle.com> <736EDBE7-C312-4763-B82C-ED543719430C@oracle.com> <964a9d55-5c12-acef-c0c1-48619e552b21@oracle.com> Message-ID: <855919F3-A2F1-4105-A0A6-E4E23B57397F@oracle.com> Thank you for review. Leonid > On Jun 7, 2019, at 11:29 AM, serguei.spitsyn at oracle.com wrote: > > On 6/7/19 11:23, Leonid Mesnik wrote: >> I read documentation about CRS on following wiki https://wiki.openjdk.java.net/display/csr . It says that CRS requires if command-line options are changes. >> However I believe that fix don't change actual behavior of 'granularity' option so no CSR is needed for this small help update. > > I see now. > Agreed, this dos not require a CSR. > > Thanks, > Serguei > > >> >> Any advise is welcome. >> >> Leonid >> >>> On Jun 7, 2019, at 9:48 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Okay then. >>> I wonder now, if a CSR needs to be filed for this change. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/7/19 09:10, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Currently DCmdArgument is used to parse any numeric values in dcmd framework including positive integer values for port, ttl etc. >>>> >>>> Adding new type DCmdArgument requires adding more specialized methods like >>>> template <> void DCmdArgument::parse_value(const char* str, >>>> size_t len, TRAPS) { >>>> >>>> and other to parse and validate any *integer* parameters. See >>>> http://hg.openjdk.java.net/jdk/jdk/file/47ee6c00d27c/src/hotspot/share/services/diagnosticArgument.cpp#l112 >>>> >>>> I think that it is easier to use single jlong for all integer like it is done now rather than adding more types. >>>> >>>> One might said that it would be better to add size_t type and use it for all non-negative integers. It would be good improvement for all dcmd args parsing. As well as overall improvement of parameters validation. (dcmd often don't throw exception and just return in the case of incorrect arguments). But sees like separate effort for whole dcmd framework. >>>> >>>> >>>> Leonid >>>>> On Jun 7, 2019, at 1:37 AM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Hi Leonid, >>>>> >>>>> It looks good to me. >>>>> One minor comment on the src/hotspot/share/services/diagnosticCommand.?pp >>>>> + DCmdArgument _granularity; >>>>> >>>>> I'm curios if using size_t instead of jlong as in other files would be more unified. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 6/6/19 17:36, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Could you please review following fix which verify parameter for Compiler.CodeHeap_Analytics command. So jcmd just exits instead of crashing target VM. Regression test was added, hs-tier1/2 passed. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~lmesnik/8225388/webrev.00/ >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8225388 >>>>>> >>>>>> Leonid >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Jun 7 21:19:24 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 7 Jun 2019 14:19:24 -0700 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: Hi Andrew, The fix looks good in general. And I can be the sponsor. I've tested the fix and got 1 test failure (of 400 runs) on Win-x64 and the log looks the same. java.lang.RuntimeException: Failed to accept connector connection at JdwpConcurrentAttachTest.main(JdwpConcurrentAttachTest.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830) Caused by: java.net.BindException: Address already in use: bind at java.base/sun.nio.ch.Net.bind0(Native Method) at java.base/sun.nio.ch.Net.bind(Net.java:465) at java.base/sun.nio.ch.Net.bind(Net.java:457) at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) at java.base/java.net.ServerSocket.bind(ServerSocket.java:359) at java.base/java.net.ServerSocket.bind(ServerSocket.java:313) at jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:300) at jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:310) at jdk.jdi/com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:117) at jdk.jdi/com.sun.tools.jdi.SocketListeningConnector.startListening(SocketListeningConnector.java:86) at JdwpConcurrentAttachTest.attachTest(JdwpConcurrentAttachTest.java:111) at JdwpConcurrentAttachTest.run(JdwpConcurrentAttachTest.java:93) So looks like the fix doesn't fix the issue completely. --alex On 06/07/2019 07:24, Andrew Leonard wrote: > Hi, > Please can I request a sponsor and review of this patch for JDK-8225474. > A problem that we have seen intermittently with JDI connector stress > tests for quite a while that is caused by an non-thread safe HashMap in > the connector class. I've created a standalone testcase that reproduces > it reliably. > http://cr.openjdk.java.net/~aleonard/8225474/webrev.00 > > Thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From serguei.spitsyn at oracle.com Sat Jun 8 04:53:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Jun 2019 21:53:58 -0700 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Jun 8 09:11:18 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 8 Jun 2019 10:11:18 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: On 08/06/2019 05:53, serguei.spitsyn at oracle.com wrote: > Hi Andrew, > > It looks good to me. > Thank you for your investigation and taking care about this! I think this one needs further analysis as changing listenMap to be a CHM does not make this connector thread safe and doesn't address a number of other places where the map is accessed without synchronization. For example, startListening would need to be changed to use `putIfAbsent`, stopListening would need to use `remove` rather than get + remote. There are several others once you start looking at the sub-classes, e.g. SocketListeningConnector.updateArgumentMapIfRequired. At the API level, JDI does not require connectors to be thread safe. I agree it is desirable for some of the connector implementations to be thread safe, particularly ListeningConnectors as an obvious usage will be for a listener thread to hand off a VirtualMachine to another thread. Andrew - do you have cycles to investigate this further? I'm not opposed to changing the map to be a CHM but I think it needs further work. -Alan From david.holmes at oracle.com Sun Jun 9 13:30:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 9 Jun 2019 23:30:37 +1000 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: <50cf76a1-77f0-7bc9-f5ae-db849f3996e6@oracle.com> +1 from me. What thread-safety should mean here needs to be defined. David On 8/06/2019 7:11 pm, Alan Bateman wrote: > On 08/06/2019 05:53, serguei.spitsyn at oracle.com wrote: >> Hi Andrew, >> >> It looks good to me. >> Thank you for your investigation and taking care about this! > I think this one needs further analysis as changing listenMap to be a > CHM does not make this connector thread safe and doesn't address a > number of other places where the map is accessed without > synchronization. For example, startListening would need to be changed to > use `putIfAbsent`, stopListening would need to use `remove` rather than > get + remote. There are several others once you start looking at the > sub-classes, e.g. SocketListeningConnector.updateArgumentMapIfRequired. > > At the API level, JDI does not require connectors to be thread safe. I > agree it is desirable for some of the connector implementations to be > thread safe, particularly ListeningConnectors as an obvious usage will > be for a listener thread to hand off a VirtualMachine to another thread. > > Andrew - do you have cycles to investigate this further? I'm not opposed > to changing the map to be a CHM but I think it needs further work. > > -Alan From yasuenag at gmail.com Mon Jun 10 02:27:17 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 10 Jun 2019 11:27:17 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> Message-ID: PING: Could you review them? > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > >> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. Thanks, Yasumasa 2019?6?5?(?) 14:06 Yasumasa Suenaga : > > Hi Jc, > > Thank you for your comment! > I updated a webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > > > - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... > > I created DebugdUtils for convenience class for attach - detach > mechanism of debug server. > IMHO it is prefer "detach" to "close" in this case. > > > Thanks, > > Yasumasa > > > 2019?6?5?(?) 11:34 Jean Christophe Beyler : > > > > Hi Yasumasa, > > > > I'm not an official reviewer but I don't see an issue with the CSR (except that this seems to be bringing a fork in the tools with some handling remote and others not). > > > > However, this code is really repetitive and this is not the place to do a big refactor probably but we could do a few nits perhaps: > > - Instead of every tool calling commonHelp with an additional flag you could divide into commonHelp and commonHelpWithRemote for the tools and they both call the current commonHelp with that boolean; so that when we are looking at the tool code we know what we are getting... So something like: > > > > private static boolean commonHelp(String mode, boolean canConnectToRemote) { > > .. > > } > > > > private static boolean commonHelp(String mode) { > > return commonHelp(mode, false); > > } > > > > private static boolean commonHelpWithRemote(String mode) { > > return commonHelp(mode, false); > > } > > > > and that way the tools that change are just going from: > > - return commonHelp("jmap"); > > + return commonHelpWithRemote("jmap"); > > > > - In the same vein, instead of passing null to the buildAttachArgs; you could make a variable null: > > > > - buildAttachArgs(newArgs, pid, exe, core, true); > > + String noRemote = null; > > + buildAttachArgs(newArgs, pid, exe, core, noRemote, true); > > > > > > - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html > > Nit: you have empty lines at l64 and l73 > > > > - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html > > Nit : you have an empty line at l110 > > > > - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... > > > > All of these are details, I just thought I'd mention them :) > > Jc > > > > On Tue, Jun 4, 2019 at 6:44 PM Yasumasa Suenaga wrote: > >> > >> PING: Could you review them? > >> > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > >> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >> > >> CSR status is provisional. So I need reviewers both CSR and webrev. > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >> 2019?5?29?(?) 22:37 Yasumasa Suenaga : > >> > > >> > Hi all, > >> > > >> > Please review this change: > >> > > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > >> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >> > > >> > In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can connect to > >> > debug server (jsadebugd). However it has not done so since JDK 9 because > >> > jhsdb cannot accept the attach request to debug server. > >> > So I want to introduce new option `--remote` to connect to debug server. > >> > > >> > I created CSR for this issue. So please review it together. > >> > > >> > > >> > Thanks, > >> > > >> > Yasumasa > > > > > > > > -- > > > > Thanks, > > Jc From yasuenag at gmail.com Mon Jun 10 02:29:20 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 10 Jun 2019 11:29:20 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> Message-ID: Sorry, new webrev is here: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ Yasumasa 2019?6?10?(?) 11:27 Yasumasa Suenaga : > > PING: Could you review them? > > > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > > >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > > >> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > > It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. > > > Thanks, > > Yasumasa > > > 2019?6?5?(?) 14:06 Yasumasa Suenaga : > > > > Hi Jc, > > > > Thank you for your comment! > > I updated a webrev: > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > > > > > - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... > > > > I created DebugdUtils for convenience class for attach - detach > > mechanism of debug server. > > IMHO it is prefer "detach" to "close" in this case. > > > > > > Thanks, > > > > Yasumasa > > > > > > 2019?6?5?(?) 11:34 Jean Christophe Beyler : > > > > > > Hi Yasumasa, > > > > > > I'm not an official reviewer but I don't see an issue with the CSR (except that this seems to be bringing a fork in the tools with some handling remote and others not). > > > > > > However, this code is really repetitive and this is not the place to do a big refactor probably but we could do a few nits perhaps: > > > - Instead of every tool calling commonHelp with an additional flag you could divide into commonHelp and commonHelpWithRemote for the tools and they both call the current commonHelp with that boolean; so that when we are looking at the tool code we know what we are getting... So something like: > > > > > > private static boolean commonHelp(String mode, boolean canConnectToRemote) { > > > .. > > > } > > > > > > private static boolean commonHelp(String mode) { > > > return commonHelp(mode, false); > > > } > > > > > > private static boolean commonHelpWithRemote(String mode) { > > > return commonHelp(mode, false); > > > } > > > > > > and that way the tools that change are just going from: > > > - return commonHelp("jmap"); > > > + return commonHelpWithRemote("jmap"); > > > > > > - In the same vein, instead of passing null to the buildAttachArgs; you could make a variable null: > > > > > > - buildAttachArgs(newArgs, pid, exe, core, true); > > > + String noRemote = null; > > > + buildAttachArgs(newArgs, pid, exe, core, noRemote, true); > > > > > > > > > - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html > > > Nit: you have empty lines at l64 and l73 > > > > > > - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html > > > Nit : you have an empty line at l110 > > > > > > - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... > > > > > > All of these are details, I just thought I'd mention them :) > > > Jc > > > > > > On Tue, Jun 4, 2019 at 6:44 PM Yasumasa Suenaga wrote: > > >> > > >> PING: Could you review them? > > >> > > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > > >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > > >> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > > >> > > >> CSR status is provisional. So I need reviewers both CSR and webrev. > > >> > > >> > > >> Thanks, > > >> > > >> Yasumasa > > >> > > >> > > >> 2019?5?29?(?) 22:37 Yasumasa Suenaga : > > >> > > > >> > Hi all, > > >> > > > >> > Please review this change: > > >> > > > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 > > >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 > > >> > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > > >> > > > >> > In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can connect to > > >> > debug server (jsadebugd). However it has not done so since JDK 9 because > > >> > jhsdb cannot accept the attach request to debug server. > > >> > So I want to introduce new option `--remote` to connect to debug server. > > >> > > > >> > I created CSR for this issue. So please review it together. > > >> > > > >> > > > >> > Thanks, > > >> > > > >> > Yasumasa > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc From andrew_m_leonard at uk.ibm.com Mon Jun 10 08:30:39 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 10 Jun 2019 09:30:39 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: Thanks for the feedback everyone. Hi Alan, yes I can put some cycles into digging deeper with this one, as you point out there's probably more that needs doing. As Alex found running the new testcase 400 times it failed once still, interestingly during initial startListening() rather than the accept() where it was failing before. On a general issue of "thread-safety", I had a good look through the spec docs and architecture docs and couldn't find any specification of thread-safety(or not), should it be inferred if the docs don't specifically state "thread-safe" that it should be assumed as "not-thread safe"? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alan Bateman To: "serguei.spitsyn at oracle.com" , Andrew Leonard , serviceability-dev at openjdk.java.net Date: 08/06/2019 10:12 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners On 08/06/2019 05:53, serguei.spitsyn at oracle.com wrote: > Hi Andrew, > > It looks good to me. > Thank you for your investigation and taking care about this! I think this one needs further analysis as changing listenMap to be a CHM does not make this connector thread safe and doesn't address a number of other places where the map is accessed without synchronization. For example, startListening would need to be changed to use `putIfAbsent`, stopListening would need to use `remove` rather than get + remote. There are several others once you start looking at the sub-classes, e.g. SocketListeningConnector.updateArgumentMapIfRequired. At the API level, JDI does not require connectors to be thread safe. I agree it is desirable for some of the connector implementations to be thread safe, particularly ListeningConnectors as an obvious usage will be for a listener thread to hand off a VirtualMachine to another thread. Andrew - do you have cycles to investigate this further? I'm not opposed to changing the map to be a CHM but I think it needs further work. -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Mon Jun 10 09:07:01 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 10 Jun 2019 10:07:01 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: Hi Alex, Thanks for trying this out, it's possible this failure is an issue with my testcase, as I repeat the 10 thread test loop 10 times and I have a 30 second timeout which potentially might overrun if a connection takes time to terminate. I could avoid that simply by using different ports for each run, equally it could also be an issue as pointed out by Alan. Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alex Menkov To: Andrew Leonard , serviceability-dev at openjdk.java.net Date: 07/06/2019 22:19 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners Hi Andrew, The fix looks good in general. And I can be the sponsor. I've tested the fix and got 1 test failure (of 400 runs) on Win-x64 and the log looks the same. java.lang.RuntimeException: Failed to accept connector connection at JdwpConcurrentAttachTest.main(JdwpConcurrentAttachTest.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830) Caused by: java.net.BindException: Address already in use: bind at java.base/sun.nio.ch.Net.bind0(Native Method) at java.base/sun.nio.ch.Net.bind(Net.java:465) at java.base/sun.nio.ch.Net.bind(Net.java:457) at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) at java.base/java.net.ServerSocket.bind(ServerSocket.java:359) at java.base/java.net.ServerSocket.bind(ServerSocket.java:313) at jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:300) at jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:310) at jdk.jdi/com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:117) at jdk.jdi/com.sun.tools.jdi.SocketListeningConnector.startListening(SocketListeningConnector.java:86) at JdwpConcurrentAttachTest.attachTest(JdwpConcurrentAttachTest.java:111) at JdwpConcurrentAttachTest.run(JdwpConcurrentAttachTest.java:93) So looks like the fix doesn't fix the issue completely. --alex On 06/07/2019 07:24, Andrew Leonard wrote: > Hi, > Please can I request a sponsor and review of this patch for JDK-8225474. > A problem that we have seen intermittently with JDI connector stress > tests for quite a while that is caused by an non-thread safe HashMap in > the connector class. I've created a standalone testcase that reproduces > it reliably. > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8225474_webrev.00&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oCeyoE4YSIdSTvnXT1XeIp6wDP4UdqGpI35isidNG1M&s=fjbdD-X1whCGO82knPWEkDwXbHh8oO1xnJnncogRPsQ&e= > > Thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Mon Jun 10 15:43:12 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 10 Jun 2019 16:43:12 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: Hi Alan, So I have done some research and analysis, and I have come to some conclusions over the key stop/start/accept methods in GenericListeningConnector: stopListening() { (1) TransportService.ListenKey listener = listenMap.get(args); if (listener == null) { throw new IllegalConnectorArgumentsException("Not listening", new ArrayList<>(args.keySet())); } transportService.stopListening(listener); (2) listenMap.remove(args); } As you state the listenMap.get() should be a straight remove(), hence this method should be changed to this: stopListening() { (1) TransportService.ListenKey listener = listenMap.remove(args); if (listener == null) { throw new IllegalConnectorArgumentsException("Not listening", new ArrayList<>(args.keySet())); } transportService.stopListening(listener); } startListening() { (1) TransportService.ListenKey listener = listenMap.get(args); | if (listener != null) { | throw new IllegalConnectorArgumentsException("Already listening", | new ArrayList<>(args.keySet())); V } (2) listener = transportService.startListening(address); (3) updateArgumentMapIfRequired(args, listener); (4) listenMap.put(args, listener); } (1) This listenMap(get) check and throw is actually purely a simplified upfront check to see if it is already listening, the transportService.startListening() (2) ulitmately will fail if it is already. However, strictly speaking another thread could be in the throws of stopping, where it "removes" the map entry then calls ts.stopListening() (in the updated method), so as it stands this check could pass but ts.startListening() fails as the other thread has not stopped yet...but I actually think that is ok. Ultimately the thread has asked to listen on a port that hasn't finished being used yet. (3) updates the "args" -> "port" in the sub-class for the WildCard listening so that the map entry put (4) is unique to what port is actually listening. The accept() method does not update the map, and I cannot see anything wrong from it's current implementation. So apart from the update to stopListening() and the fix to use ConcurrentHashMap I think it seems fine. The issue with the "bug" was corruption of the HashMap so that the accept() method incorrectly thought the port was not being listened upon and then tried to do another startListening(). Thoughts? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alan Bateman To: "serguei.spitsyn at oracle.com" , Andrew Leonard , serviceability-dev at openjdk.java.net Date: 08/06/2019 10:12 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners On 08/06/2019 05:53, serguei.spitsyn at oracle.com wrote: > Hi Andrew, > > It looks good to me. > Thank you for your investigation and taking care about this! I think this one needs further analysis as changing listenMap to be a CHM does not make this connector thread safe and doesn't address a number of other places where the map is accessed without synchronization. For example, startListening would need to be changed to use `putIfAbsent`, stopListening would need to use `remove` rather than get + remote. There are several others once you start looking at the sub-classes, e.g. SocketListeningConnector.updateArgumentMapIfRequired. At the API level, JDI does not require connectors to be thread safe. I agree it is desirable for some of the connector implementations to be thread safe, particularly ListeningConnectors as an obvious usage will be for a listener thread to hand off a VirtualMachine to another thread. Andrew - do you have cycles to investigate this further? I'm not opposed to changing the map to be a CHM but I think it needs further work. -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Mon Jun 10 16:43:18 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 10 Jun 2019 09:43:18 -0700 Subject: 8222828: vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java failed In-Reply-To: <042e0969-a95e-3abd-0636-53e82fdd0e37@oracle.com> References: <042e0969-a95e-3abd-0636-53e82fdd0e37@oracle.com> Message-ID: Thank you, Chris, JC, and Gary, for reviewing this change! Best regards, Daniil ?On 6/7/19, 12:31 PM, "Chris Plummer" wrote: Looks good. Chris On 6/7/19 11:47 AM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of the test when it is run with Graal on. > > The test starts a debuggee and sets the method entry breakpoint for tc02x004aClass1 class that has only constructor defined. > The debuggee starts 3 threads and each of them creates a new instance of tc02x004aClass1 class. The test waits for receiving > 3 method entry events (posted when the constructor of tc02x004aClass1 is invoked) during a specific amount of time. > > The problem here is that with Graal on it takes more time for the test to run and occasionally the test stops listening for events > before all method entry events are delivered. > > The fix ensures that the time the test waits for receiving method entry events is adjusted for test.timeout.factor factor. > > The fix also makes the test waiting till the debuggee terminates before exiting. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222828/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222828 > > Thanks! > -Daniil > > From robert.field at oracle.com Mon Jun 10 19:25:13 2019 From: robert.field at oracle.com (Robert Field) Date: Mon, 10 Jun 2019 12:25:13 -0700 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: <4fca8b06-0458-f7d8-ac29-6b5c820a6b35@oracle.com> Thanks Andrew! If you want more data points on failure modes, this and the linked issues might be a rich source: https://bugs.openjdk.java.net/browse/JDK-8184445 JShell is built on JDI and these various forms of intermittent attach failures have been a continual pain point. -Robert On 6/10/19 1:30 AM, Andrew Leonard wrote: > Thanks for the feedback everyone. > > Hi Alan, yes I can put some cycles into digging deeper with this one, > as you point out there's probably more that needs doing. > As Alex found running the new testcase 400 times it failed once still, > interestingly during initial startListening() rather than the accept() > where it was failing before. > On a general issue of "thread-safety", I had a good look through the > spec docs and architecture docs and couldn't find any specification of > thread-safety(or not), should it be inferred if the docs don't > specifically state "thread-safe" that it should be assumed as > "not-thread safe"? > > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Alan Bateman > To: "serguei.spitsyn at oracle.com" , Andrew > Leonard , > serviceability-dev at openjdk.java.net > Date: 08/06/2019 10:12 > Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address > already in use" with concurrent listeners > ------------------------------------------------------------------------ > > > > On 08/06/2019 05:53, serguei.spitsyn at oracle.com wrote: > > Hi Andrew, > > > > It looks good to me. > > Thank you for your investigation and taking care about this! > I think this one needs further analysis as changing listenMap to be a > CHM does not make this connector thread safe and doesn't address a > number of other places where the map is accessed without > synchronization. For example, startListening would need to be changed to > use `putIfAbsent`, stopListening would need to use `remove` rather than > get + remote. There are several others once you start looking at the > sub-classes, e.g. SocketListeningConnector.updateArgumentMapIfRequired. > > At the API level, JDI does not require connectors to be thread safe. I > agree it is desirable for some of the connector implementations to be > thread safe, particularly ListeningConnectors as an obvious usage will > be for a listener thread to hand off a VirtualMachine to another thread. > > Andrew - do you have cycles to investigate this further? I'm not opposed > to changing the map to be a CHM but I think it needs further work. > > -Alan > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Jun 10 19:43:41 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 10 Jun 2019 12:43:41 -0700 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: On 06/10/2019 02:07, Andrew Leonard wrote: > Hi Alex, > Thanks for trying this out, it's possible this failure is an issue with > my testcase, as I repeat the 10 thread test loop 10 times and I have a > 30 second timeout which potentially might overrun if a connection takes > time to terminate. I could avoid that simply by using different ports > for each run, equally it could also be an issue as pointed out by Alan. The test uses fixed ports, so it can interfere with other processes. You can use port "0" which automatically selects free port. connector.startListening returns actual port assigned for the connection. > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Alex Menkov > To: Andrew Leonard , > serviceability-dev at openjdk.java.net > Date: 07/06/2019 22:19 > Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address > already in use" with concurrent listeners > ------------------------------------------------------------------------ > > > > Hi Andrew, > > The fix looks good in general. > And I can be the sponsor. > I've tested the fix and got 1 test failure (of 400 runs) on Win-x64 and > the log looks the same. > > java.lang.RuntimeException: Failed to accept connector connection > at JdwpConcurrentAttachTest.main(JdwpConcurrentAttachTest.java:74) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:830) > Caused by: java.net.BindException: Address already in use: bind > at java.base/sun.nio.ch.Net.bind0(Native Method) > at java.base/sun.nio.ch.Net.bind(Net.java:465) > at java.base/sun.nio.ch.Net.bind(Net.java:457) > at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) > at java.base/java.net.ServerSocket.bind(ServerSocket.java:359) > at java.base/java.net.ServerSocket.bind(ServerSocket.java:313) > at > jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:300) > at > jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:310) > at > jdk.jdi/com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:117) > at > jdk.jdi/com.sun.tools.jdi.SocketListeningConnector.startListening(SocketListeningConnector.java:86) > at JdwpConcurrentAttachTest.attachTest(JdwpConcurrentAttachTest.java:111) > at JdwpConcurrentAttachTest.run(JdwpConcurrentAttachTest.java:93) > > So looks like the fix doesn't fix the issue completely. > > --alex > > On 06/07/2019 07:24, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor and review of this patch for JDK-8225474. >> A problem that we have seen intermittently with JDI connector stress >> tests for quite a while that is caused by an non-thread safe HashMap in >> the connector class. I've created a standalone testcase that reproduces >> it reliably. >> http://cr.openjdk.java.net/~aleonard/8225474/webrev.00 >> >> Thanks >> Andrew >> >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> internet email: andrew_m_leonard at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From daniil.x.titov at oracle.com Mon Jun 10 23:55:37 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 10 Jun 2019 16:55:37 -0700 Subject: RFR: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process Message-ID: <95E1F227-198B-4F53-B094-497A1DD653AE@oracle.com> Please review the change that fixes jcmd process name matching on Linux platform. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, sun.tools.ProcessHelper class, introduced in that change, didn't take into account the presence of module whitespace options ( e.g. --patch-module) or the fact that some values of Java options could contain whitespaces. The latter problem is fixed by keeping '\0' as a separator for command line arguments read from /proc/{pid}/cmdline rather than replacing it with a whitespace. The former problem is fixed by making sun.tools.ProcessHelper aware of these module whitespace options (--add-opens, --add-exports,--add-reads, --add-modules, --patch-module,--limit-modules, or --upgrade-module-path) as well as of the case when a source-file mode is used or when --module options is used in "--=" format. Testing: sun/tools/jcmd and serviceability/dcmd/framework tests succeeded in Mach5. jdk_svc, tier1, tier2, and tier3 tests are in progress. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8225543/webrev.01/ [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8225543 [3] https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks! --Daniil From andrew_m_leonard at uk.ibm.com Tue Jun 11 19:36:40 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 11 Jun 2019 20:36:40 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: Thanks Alex, I have changed the testcase to allocate ports which makes better sense: http://cr.openjdk.java.net/~aleonard/8225474/webrev.02/ Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alex Menkov To: Andrew Leonard Cc: serviceability-dev at openjdk.java.net Date: 10/06/2019 20:43 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners On 06/10/2019 02:07, Andrew Leonard wrote: > Hi Alex, > Thanks for trying this out, it's possible this failure is an issue with > my testcase, as I repeat the 10 thread test loop 10 times and I have a > 30 second timeout which potentially might overrun if a connection takes > time to terminate. I could avoid that simply by using different ports > for each run, equally it could also be an issue as pointed out by Alan. The test uses fixed ports, so it can interfere with other processes. You can use port "0" which automatically selects free port. connector.startListening returns actual port assigned for the connection. > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Alex Menkov > To: Andrew Leonard , > serviceability-dev at openjdk.java.net > Date: 07/06/2019 22:19 > Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address > already in use" with concurrent listeners > ------------------------------------------------------------------------ > > > > Hi Andrew, > > The fix looks good in general. > And I can be the sponsor. > I've tested the fix and got 1 test failure (of 400 runs) on Win-x64 and > the log looks the same. > > java.lang.RuntimeException: Failed to accept connector connection > at JdwpConcurrentAttachTest.main(JdwpConcurrentAttachTest.java:74) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:830) > Caused by: java.net.BindException: Address already in use: bind > at java.base/sun.nio.ch.Net.bind0(Native Method) > at java.base/sun.nio.ch.Net.bind(Net.java:465) > at java.base/sun.nio.ch.Net.bind(Net.java:457) > at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) > at java.base/java.net.ServerSocket.bind(ServerSocket.java:359) > at java.base/java.net.ServerSocket.bind(ServerSocket.java:313) > at > jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:300) > at > jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:310) > at > jdk.jdi/com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:117) > at > jdk.jdi/com.sun.tools.jdi.SocketListeningConnector.startListening(SocketListeningConnector.java:86) > at JdwpConcurrentAttachTest.attachTest(JdwpConcurrentAttachTest.java:111) > at JdwpConcurrentAttachTest.run(JdwpConcurrentAttachTest.java:93) > > So looks like the fix doesn't fix the issue completely. > > --alex > > On 06/07/2019 07:24, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor and review of this patch for JDK-8225474. >> A problem that we have seen intermittently with JDI connector stress >> tests for quite a while that is caused by an non-thread safe HashMap in >> the connector class. I've created a standalone testcase that reproduces >> it reliably. >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8225474_webrev.00&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=OaT9vhOgj2gp0DQBwJgmItAjmzP-GsUEkGJAVbN9ZCE&s=EQwT-4TnAIqImG1-KTOT803z1DRjmTTeMtNV-9S9-6M&e= >> >> Thanks >> Andrew >> >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> internet email: andrew_m_leonard at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Tue Jun 11 20:05:40 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 11 Jun 2019 21:05:40 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: <50cf76a1-77f0-7bc9-f5ae-db849f3996e6@oracle.com> References: <50cf76a1-77f0-7bc9-f5ae-db849f3996e6@oracle.com> Message-ID: So good point, what does thread-safety mean here: I've gone back around my change and am now satisfied just changing to use ConcurrentHashMap is sufficient for what is required here. The GenericListenerConnector and it's sub-class are essentially a wrapper class to the underlying TransportService object. It essentially marshalls the listening requests on various addresses/ports through to the transportService. The addr:port uniqueness/clashes is ultimately delegated to the transportService who really knows what ports are allocated, and as long as the GenericListenerConnector only put's listener's into its map upon a thread's successful transportService.startListening() and removes them upon a successful transportService.stopListening(), that should work, hence why I have left stopListening() method as it was (in webrev.02). The real requirement of GenericListenerConnector from a thread-safety aspect is that it safely stores/manages it's map of listeners, which is where the bug was, in that it needed a ConcurrentHashMap. Thus get/puts.. don't corrupt the map. I am thus happy with my webrev.02, which is as .00 but i've updated the testcase to allocate ports using port=0. http://cr.openjdk.java.net/~aleonard/8225474/webrev.02/ I have now run my testcase x200 with no failure. I have also run the suggested jshell tests numerous times all passing: jtreg -concurrency:12 -v1 langtools/test/jdk/jshell So I am quite happy with it as it stands, i've thrashed the startListening concurrency quite hard on xLinux and it now seems robust. I am going to run some stress tests on some other platforms tomorrow, Win64 and Mac if I can. Is one of the JDI SME's able to review this please? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: David Holmes To: Alan Bateman , "serguei.spitsyn at oracle.com" , Andrew Leonard , serviceability-dev at openjdk.java.net Date: 09/06/2019 14:30 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners +1 from me. What thread-safety should mean here needs to be defined. David On 8/06/2019 7:11 pm, Alan Bateman wrote: > On 08/06/2019 05:53, serguei.spitsyn at oracle.com wrote: >> Hi Andrew, >> >> It looks good to me. >> Thank you for your investigation and taking care about this! > I think this one needs further analysis as changing listenMap to be a > CHM does not make this connector thread safe and doesn't address a > number of other places where the map is accessed without > synchronization. For example, startListening would need to be changed to > use `putIfAbsent`, stopListening would need to use `remove` rather than > get + remote. There are several others once you start looking at the > sub-classes, e.g. SocketListeningConnector.updateArgumentMapIfRequired. > > At the API level, JDI does not require connectors to be thread safe. I > agree it is desirable for some of the connector implementations to be > thread safe, particularly ListeningConnectors as an obvious usage will > be for a listener thread to hand off a VirtualMachine to another thread. > > Andrew - do you have cycles to investigate this further? I'm not opposed > to changing the map to be a CHM but I think it needs further work. > > -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 12 09:52:42 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jun 2019 10:52:42 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: <6b036dbf-c40b-fcbc-12f8-0ead37068b7e@oracle.com> On 10/06/2019 09:30, Andrew Leonard wrote: > Thanks for the feedback everyone. > > Hi Alan, yes I can put some cycles into digging deeper with this one, > as you point out there's probably more that needs doing. > As Alex found running the new testcase 400 times it failed once still, > interestingly during initial startListening() rather than the accept() > where it was failing before. > On a general issue of "thread-safety", I had a good look through the > spec docs and architecture docs and couldn't find any specification of > thread-safety(or not), should it be inferred if the docs don't > specifically state "thread-safe" that it should be assumed as > "not-thread safe"? Right, Connectors aren't specified to be thread safe so any test that assumes otherwise is an issue (there may be a second issue here with a test using a fixed TCP port, it sounds like you might be running into both issues). I've no objection to changing GenericListeningConnector to be thread safe. Also no issue with exploring the impact of a spec change too. Although Connectors (and transports) are pluggable, there probably aren't too many implementations outside of the JDK so you might have some scope to go beyond recommending that implementations be thread safe. I've read your other mails where you've done some exploration into startListening/stopListening but I think there is more to do. Minimally I think startListening will need synchronization, alternatively changed to use putIfAbsent and stop the transport listening if it looses the race. There is also an issue with stopListening. It requires looking at the super class too because ConnectorImpl is not thread safe, esp. the defaultArguments which is a separate mutable map to listenMap. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Wed Jun 12 14:48:06 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 12 Jun 2019 15:48:06 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: <6b036dbf-c40b-fcbc-12f8-0ead37068b7e@oracle.com> References: <6b036dbf-c40b-fcbc-12f8-0ead37068b7e@oracle.com> Message-ID: Hi Alan, I've thought about this some more, and you're right there are some edge cases where I think we really need to synchronize the start/stopListening. My initial thought the transportService would manage it, is flawed. For example in the potential situation where dynamic port=0 allocation is used, and the transportService allocates ports, and a current thread using port A calls stopListening(), lets say that gets as far through that method as completing the transportService.stopListening() but not as far as the listenMap.remove(args), and then gets paused. Another thread calls startListening() and the transportService allocates the same port A to it and it completes the listenMap.put(args). The other thread then resumes and calls listenMap.remove(args), then removing the in-use port A of the other thread from the listenMap, thus causing an exception in accept() or stopListening()... and leaving a port in-use... ConnectorImpl manages the defaultArguments map, which is an unaltered insertion-ordered linked map after object contruction. After construction it is purely for default arguments access, so in theory does not need synchronization, but all it would take is a scenario to be added for example to change a "default arg". So I think for safety making it Collections.synchronizedMap(new LinkedHashMap()); I think would make sense. I shall work on a webrev.03 with these updates and perform some tests on xLinux, Win64 and mac64. Thanks again Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alan Bateman To: Andrew Leonard Cc: serviceability-dev at openjdk.java.net Date: 12/06/2019 10:54 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners On 10/06/2019 09:30, Andrew Leonard wrote: Thanks for the feedback everyone. Hi Alan, yes I can put some cycles into digging deeper with this one, as you point out there's probably more that needs doing. As Alex found running the new testcase 400 times it failed once still, interestingly during initial startListening() rather than the accept() where it was failing before. On a general issue of "thread-safety", I had a good look through the spec docs and architecture docs and couldn't find any specification of thread-safety(or not), should it be inferred if the docs don't specifically state "thread-safe" that it should be assumed as "not-thread safe"? Right, Connectors aren't specified to be thread safe so any test that assumes otherwise is an issue (there may be a second issue here with a test using a fixed TCP port, it sounds like you might be running into both issues). I've no objection to changing GenericListeningConnector to be thread safe. Also no issue with exploring the impact of a spec change too. Although Connectors (and transports) are pluggable, there probably aren't too many implementations outside of the JDK so you might have some scope to go beyond recommending that implementations be thread safe. I've read your other mails where you've done some exploration into startListening/stopListening but I think there is more to do. Minimally I think startListening will need synchronization, alternatively changed to use putIfAbsent and stop the transport listening if it looses the race. There is also an issue with stopListening. It requires looking at the super class too because ConnectorImpl is not thread safe, esp. the defaultArguments which is a separate mutable map to listenMap. -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Wed Jun 12 17:50:22 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 12 Jun 2019 10:50:22 -0700 Subject: FW: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process In-Reply-To: <4365A022-0817-46F1-A698-892042494F36@oracle.com> References: <4365A022-0817-46F1-A698-892042494F36@oracle.com> Message-ID: Hi David and Serguei, Could you please have a look at this change? This fix is related with the changes [3] that you reviewed back in February. Mach5 sun/tools/jcmd, serviceability/dcmd/framework, jdk_svc, hotspot_serviceability, tier1, tier2 and tier3 tests passed. Thanks a lot! --Daniil ?On 6/10/19, 4:56 PM, "serviceability-dev on behalf of Daniil Titov" wrote: Please review the change that fixes jcmd process name matching on Linux platform. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, sun.tools.ProcessHelper class, introduced in that change, didn't take into account the presence of module whitespace options ( e.g. --patch-module) or the fact that some values of Java options could contain whitespaces. The latter problem is fixed by keeping '\0' as a separator for command line arguments read from /proc/{pid}/cmdline rather than replacing it with a whitespace. The former problem is fixed by making sun.tools.ProcessHelper aware of these module whitespace options (--add-opens, --add-exports,--add-reads, --add-modules, --patch-module,--limit-modules, or --upgrade-module-path) as well as of the case when a source-file mode is used or when --module options is used in "--=" format. Testing: sun/tools/jcmd and serviceability/dcmd/framework tests succeeded in Mach5. jdk_svc, tier1, tier2, and tier3 tests are in progress. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8225543/webrev.01/ [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8225543 [3] https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks! --Daniil From serguei.spitsyn at oracle.com Wed Jun 12 19:39:34 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Jun 2019 12:39:34 -0700 Subject: FW: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process In-Reply-To: References: <4365A022-0817-46F1-A698-892042494F36@oracle.com> Message-ID: <61915037-dada-3cb8-2c1c-7a81e683e725@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 12 19:52:44 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Jun 2019 12:52:44 -0700 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: Message-ID: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Wed Jun 12 20:21:46 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 12 Jun 2019 13:21:46 -0700 Subject: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process In-Reply-To: <61915037-dada-3cb8-2c1c-7a81e683e725@oracle.com> References: <4365A022-0817-46F1-A698-892042494F36@oracle.com> <61915037-dada-3cb8-2c1c-7a81e683e725@oracle.com> Message-ID: <842F9738-63AC-4C0A-82C9-FA22D8261543@oracle.com> Hi Serguei, >> How these changes are going to work for options "--module=" and "--module-path" >> if there is this check at the beginning of each iteration: >> parts[i].equals("--module") Let me describe in details these cases you mentioned. Case 1: --------- part[i] is "--module" part[i+1] is "myModule/MyClass" Case 2: --------- part[i] is "--module=myModule/MyClass " Case 3: --------- part[i] is "--module-path" part[i+1] is "mods" For case 1 we have the condition on line 94 that is evaluated to TRUE and we return the next part on line 95 (part[i+1]) as a module and class name. For case 2 the condition on line 94 is evaluated to FALSE so we continue to line 99. On line 99 the condition is evaluated to TRUE so on line 100 we return the value part of the option (everything after "--module=") as a module and class name. Please note the condition on line 94 uses equals() while on the line 99 it uses startsWith(). For case 3 the condition on lines 94 and 99 are evaluated to FALSE so we continue to lines 105/106 and isModuleWhiteSpaceOption(parts[i]) on line 106 returns TRUE. As a result, we skip this and the next parts and continue to the beginning of the loop at line 92. 92 for (int i = 1; i < parts.length && mainClass == null; i++) { 93 if (i < parts.length - 1) { 94 if (parts[i].equals("-m") || parts[i].equals("--module") || parts[i].equals("-jar")) { 95 return parts[i + 1]; 96 } 97 } 98 99 if ((parts[i].startsWith("--module="))) { 100 return parts[i].substring("--module=".length()); 101 } 102 103 // If this is a classpath or a module whitespace option then skip the next part 104 // (the classpath or the option value itself) 105 if (parts[i].equals("-cp") || parts[i].equals("-classpath") || parts[i].equals("--class-path") || 106 isModuleWhiteSpaceOption(parts[i])) { 107 i++; 108 continue; 109 } 110 >> Also, this line has unneeded extra "()": >> + if ((parts[i].startsWith("--module="))) { Yes, you are right! Thanks! I will remove it before pushing or in the new version of a webrev if we will come to it. Thank you! -Daniil From: "serguei.spitsyn at oracle.com" Date: Wednesday, June 12, 2019 at 12:39 PM To: Daniil Titov , David Holmes Cc: OpenJDK Serviceability Subject: Re: FW: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process Hi Daniil, I'm confused with the change: for (int i = 1; i < parts.length && mainClass == null; i++) { if (i < parts.length - 1) { if (parts[i].equals("-m") || parts[i].equals("--module") || parts[i].equals("-jar")) { <= ?????? return parts[i + 1]; } } - // If this is a classpath or a module path option then skip the next part - // (the classpath or the module path itself) + + if ((parts[i].startsWith("--module="))) { <= ?????? + return parts[i].substring("--module=".length()); + } + + // If this is a classpath or a module whitespace option then skip the next part + // (the classpath or the option value itself) if (parts[i].equals("-cp") || parts[i].equals("-classpath") || parts[i].equals("--class-path") || - parts[i].equals("-p") || parts[i].equals("--module-path")) { + isModuleWhiteSpaceOption(parts[i])) { . . . + private static boolean isModuleWhiteSpaceOption(String option) { + return option.equals("-p") || + option.equals("--module-path") || How these changes are going to work for options "--module=" and "--module-path" if there is this check at the beginning of each iteration: ? parts[i].equals("--module") ? Also, this line has unneeded extra "()": ? + if ((parts[i].startsWith("--module="))) { Thanks, Serguei On 6/12/19 10:50, Daniil Titov wrote: Hi David and Serguei, Could you please have a look at this change? This fix is related with the changes [3] that you reviewed back in February. Mach5 sun/tools/jcmd, serviceability/dcmd/framework, jdk_svc, hotspot_serviceability, tier1, tier2 and tier3 tests passed. Thanks a lot! --Daniil ?On 6/10/19, 4:56 PM, "serviceability-dev on behalf of Daniil Titov" mailto:serviceability-dev-bounces at openjdk.java.netonbehalfofdaniil.x.titov@oracle.com wrote: Please review the change that fixes jcmd process name matching on Linux platform. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, sun.tools.ProcessHelper class, introduced in that change, didn't take into account the presence of module whitespace options ( e.g. --patch-module) or the fact that some values of Java options could contain whitespaces. The latter problem is fixed by keeping '\0' as a separator for command line arguments read from /proc/{pid}/cmdline rather than replacing it with a whitespace. The former problem is fixed by making sun.tools.ProcessHelper aware of these module whitespace options (--add-opens, --add-exports,--add-reads, --add-modules, --patch-module,--limit-modules, or --upgrade-module-path) as well as of the case when a source-file mode is used or when --module options is used in "--=" format. Testing: sun/tools/jcmd and serviceability/dcmd/framework tests succeeded in Mach5. jdk_svc, tier1, tier2, and tier3 tests are in progress. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8225543/webrev.01/ [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8225543 [3] https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks! --Daniil From serguei.spitsyn at oracle.com Wed Jun 12 20:36:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Jun 2019 13:36:58 -0700 Subject: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process In-Reply-To: <842F9738-63AC-4C0A-82C9-FA22D8261543@oracle.com> References: <4365A022-0817-46F1-A698-892042494F36@oracle.com> <61915037-dada-3cb8-2c1c-7a81e683e725@oracle.com> <842F9738-63AC-4C0A-82C9-FA22D8261543@oracle.com> Message-ID: <6c605c1c-5afe-dfba-d65f-6a9d884d9d86@oracle.com> Hi Daniil, Thank you for the explanation! You are right. I missed that the check at line 94 is for full (not partial) equality. So, the fix looks good to me. Thanks, Serguei On 6/12/19 13:21, Daniil Titov wrote: > Hi Serguei, > > >>> How these changes are going to work for options "--module=" and "--module-path" >>> if there is this check at the beginning of each iteration: >>> parts[i].equals("--module") > Let me describe in details these cases you mentioned. > > Case 1: > --------- > part[i] is "--module" > part[i+1] is "myModule/MyClass" > > Case 2: > --------- > part[i] is "--module=myModule/MyClass " > > Case 3: > --------- > part[i] is "--module-path" > part[i+1] is "mods" > > For case 1 we have the condition on line 94 that is evaluated to TRUE and we return the next part on line 95 (part[i+1]) as a module and class name. > > For case 2 the condition on line 94 is evaluated to FALSE so we continue to line 99. On line 99 the condition is evaluated to TRUE so on line 100 we > return the value part of the option (everything after "--module=") as a module and class name. Please note the condition on line 94 uses > equals() while on the line 99 it uses startsWith(). > > For case 3 the condition on lines 94 and 99 are evaluated to FALSE so we continue to lines 105/106 and isModuleWhiteSpaceOption(parts[i]) on line 106 > returns TRUE. As a result, we skip this and the next parts and continue to the beginning of the loop at line 92. > > > > > > 92 for (int i = 1; i < parts.length && mainClass == null; i++) { > 93 if (i < parts.length - 1) { > 94 if (parts[i].equals("-m") || parts[i].equals("--module") || parts[i].equals("-jar")) { > 95 return parts[i + 1]; > 96 } > 97 } > 98 > 99 if ((parts[i].startsWith("--module="))) { > 100 return parts[i].substring("--module=".length()); > 101 } > 102 > 103 // If this is a classpath or a module whitespace option then skip the next part > 104 // (the classpath or the option value itself) > 105 if (parts[i].equals("-cp") || parts[i].equals("-classpath") || parts[i].equals("--class-path") || > 106 isModuleWhiteSpaceOption(parts[i])) { > 107 i++; > 108 continue; > 109 } > 110 > > >>> Also, this line has unneeded extra "()": >>> + if ((parts[i].startsWith("--module="))) { > Yes, you are right! Thanks! I will remove it before pushing or in the new version of a webrev if we will come to it. > > > Thank you! > -Daniil > > From: "serguei.spitsyn at oracle.com" > Date: Wednesday, June 12, 2019 at 12:39 PM > To: Daniil Titov , David Holmes > Cc: OpenJDK Serviceability > Subject: Re: FW: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process > > Hi Daniil, > > I'm confused with the change: > for (int i = 1; i < parts.length && mainClass == null; i++) { > if (i < parts.length - 1) { > if (parts[i].equals("-m") || parts[i].equals("--module") || parts[i].equals("-jar")) { <= ?????? > return parts[i + 1]; > } > } > - // If this is a classpath or a module path option then skip the next part > - // (the classpath or the module path itself) > + > + if ((parts[i].startsWith("--module="))) { <= ?????? > + return parts[i].substring("--module=".length()); > + } > + > + // If this is a classpath or a module whitespace option then skip the next part > + // (the classpath or the option value itself) > if (parts[i].equals("-cp") || parts[i].equals("-classpath") || parts[i].equals("--class-path") || > - parts[i].equals("-p") || parts[i].equals("--module-path")) { > + isModuleWhiteSpaceOption(parts[i])) { > > . . . > > + private static boolean isModuleWhiteSpaceOption(String option) { > + return option.equals("-p") || > + option.equals("--module-path") || > > How these changes are going to work for options "--module=" and "--module-path" > if there is this check at the beginning of each iteration: > ? parts[i].equals("--module") > ? > > Also, this line has unneeded extra "()": > > + if ((parts[i].startsWith("--module="))) { > > > Thanks, > Serguei > > On 6/12/19 10:50, Daniil Titov wrote: > Hi David and Serguei, > > Could you please have a look at this change? This fix is related with the changes [3] that you reviewed back in February. > > Mach5 sun/tools/jcmd, serviceability/dcmd/framework, jdk_svc, hotspot_serviceability, tier1, tier2 and tier3 tests passed. > > Thanks a lot! > --Daniil > > ?On 6/10/19, 4:56 PM, "serviceability-dev on behalf of Daniil Titov" mailto:serviceability-dev-bounces at openjdk.java.netonbehalfofdaniil.x.titov@oracle.com wrote: > > Please review the change that fixes jcmd process name matching on Linux platform. > > After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, sun.tools.ProcessHelper class, > introduced in that change, didn't take into account the presence of module whitespace options ( e.g. --patch-module) or the > fact that some values of Java options could contain whitespaces. > > The latter problem is fixed by keeping '\0' as a separator for command line arguments read from /proc/{pid}/cmdline rather than > replacing it with a whitespace. The former problem is fixed by making sun.tools.ProcessHelper aware of these module whitespace > options (--add-opens, --add-exports,--add-reads, --add-modules, --patch-module,--limit-modules, or --upgrade-module-path) as well > as of the case when a source-file mode is used or when --module options is used in "--=" format. > > Testing: sun/tools/jcmd and serviceability/dcmd/framework tests succeeded in Mach5. jdk_svc, tier1, tier2, and tier3 tests are in progress. > > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8225543/webrev.01/ > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8225543 > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > Thanks! > --Daniil > > > > > > > > > > From david.holmes at oracle.com Thu Jun 13 05:00:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2019 15:00:21 +1000 Subject: =?UTF-8?Q?Re=3a_Attach_Listener_thread_may_create_multiple=ef=bc=9f?= In-Reply-To: References: Message-ID: <45d3f1d6-0b9f-d25f-63d1-adb00e995256@oracle.com> Hi, Adding serviceability-dev ... On 13/06/2019 1:26 pm, nijiaben wrote: > Hi, All > > > Yesterday our colleague found a strange situation. After executing jstack, I saw multiple Attach Listener threads in the output. I was very confused at the time and felt that it was unlikely that the Attach Listener should theoretically exist only one. > > > So I followed the code of the hotspot, this situation may indeed exist. When we execute jstack operations concurrently on a process, it is likely that multiple Attach Listener threads are created. By default, the Attach Listener is not created when jvm is started. Instead, when we first trigger through the attach mechanism, the Attach Listener thread is created by the Signal Dispatcher thread. This is a bug. Not previously reported as far as I can see. I have filed: https://bugs.openjdk.java.net/browse/JDK-8225690 Cheers, David > > static void signal_thread_entry(JavaThread* thread, TRAPS) { > os::set_priority(thread, NearMaxPriority); > while (true) { > int sig; > { > // FIXME : Currently we have not decieded what should be the status > // for this java thread blocked here. Once we decide about > // that we should fix this. > sig = os::signal_wait(); > } > if (sig == os::sigexitnum_pd()) { > // Terminate the signal thread > return; > } > > switch (sig) { > case SIGBREAK: { > // Check if the signal is a trigger to start the Attach Listener - in that > // case don't print stack traces. > if (!DisableAttachMechanism && AttachListener::is_init_trigger()) { > continue; > } > ... > } > } > > > > > > > > > bool AttachListener::is_init_trigger() { > if (init_at_startup() || is_initialized()) { > return false; // initialized at startup or already initialized > } > char fn[PATH_MAX+1]; > sprintf(fn, ".attach_pid%d", os::current_process_id()); > int ret; > struct stat64 st; > RESTARTABLE(::stat64(fn, &st), ret); > if (ret == -1) { > snprintf(fn, sizeof(fn), "%s/.attach_pid%d", > os::get_temp_directory(), os::current_process_id()); > RESTARTABLE(::stat64(fn, &st), ret); > } > if (ret == 0) { > // simple check to avoid starting the attach mechanism when > // a bogus user creates the file > if (st.st_uid == geteuid()) { > init(); > return true; > } > } > return false; > } > > > > > The Attach Listener thread is created in the AttachListener::init method above, but the _initialized property is used to pre-determine whether the thread needs to be created before the init method is executed, and _initialized is set to true in the attach_listener_thread_entry > > > static void attach_listener_thread_entry(JavaThread* thread, TRAPS) { > os::set_priority(thread, NearMaxPriority); > > thread->record_stack_base_and_size(); > > if (AttachListener::pd_init() != 0) { > return; > } > AttachListener::set_initialized(); > ... > } > > > > > However, if more than one request signal is sent before _initialized=true is set, multiple Attach Listeners may be created because the Signal Dispatcher and Attach Listener threads are executed asynchronously. > > > We can zoom in on this problem by modifying the code in hotspot > > > static void attach_listener_thread_entry(JavaThread* thread, TRAPS) { > os::set_priority(thread, NearMaxPriority); > > thread->record_stack_base_and_size(); > > sleep(15); > > if (AttachListener::pd_init() != 0) { > return; > } > AttachListener::set_initialized(); > ... > } > > > > > When the process is started, keep executing jstack , and you will eventually see that there are a lot of Attach Listener threads. > > > "Attach Listener" #16 daemon prio=9 os_prio=0 tid=0x00007f21a800e000 nid=0x35b8 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Attach Listener" #15 daemon prio=9 os_prio=0 tid=0x00007f21a800c000 nid=0x35a5 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x00007f21a800a000 nid=0x3593 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Attach Listener" #13 daemon prio=9 os_prio=0 tid=0x00007f21a8008000 nid=0x3582 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Attach Listener" #12 daemon prio=9 os_prio=0 tid=0x00007f21a8006800 nid=0x3570 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Attach Listener" #11 daemon prio=9 os_prio=0 tid=0x00007f21a8004800 nid=0x355e runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Attach Listener" #10 daemon prio=9 os_prio=0 tid=0x00007f21a8002800 nid=0x354b runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Attach Listener" #9 daemon prio=9 os_prio=0 tid=0x00007f21a8001000 nid=0x3539 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > ... > > > > > > > In general, the creation of the Attach Listener thread is created by the Signal Dispatcher thread, but the flag that determines whether the Signal Dispatcher can repeatedly create the Attach Listener thread is set in an Attach Listener thread. If the flag is not set in time, There may be cases where multiple Attach Listener threads are created. > > > > May I ask whether this is a known issue or not? > > > Thanks, > > nijiaben @ PerfMa > From david.holmes at oracle.com Thu Jun 13 05:21:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2019 15:21:53 +1000 Subject: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process In-Reply-To: References: <4365A022-0817-46F1-A698-892042494F36@oracle.com> Message-ID: <19456c63-8224-71ed-2266-e50348aa7b88@oracle.com> Hi Daniil, These changes seem quite reasonable. In hindsight splitting the command-line based on spaces was bound to hit problems with arguments containing spaces. :( Thanks for fixing. David On 13/06/2019 3:50 am, Daniil Titov wrote: > Hi David and Serguei, > > Could you please have a look at this change? This fix is related with the changes [3] that you reviewed back in February. > > Mach5 sun/tools/jcmd, serviceability/dcmd/framework, jdk_svc, hotspot_serviceability, tier1, tier2 and tier3 tests passed. > > Thanks a lot! > --Daniil > > ?On 6/10/19, 4:56 PM, "serviceability-dev on behalf of Daniil Titov" wrote: > > Please review the change that fixes jcmd process name matching on Linux platform. > > After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, sun.tools.ProcessHelper class, > introduced in that change, didn't take into account the presence of module whitespace options ( e.g. --patch-module) or the > fact that some values of Java options could contain whitespaces. > > The latter problem is fixed by keeping '\0' as a separator for command line arguments read from /proc/{pid}/cmdline rather than > replacing it with a whitespace. The former problem is fixed by making sun.tools.ProcessHelper aware of these module whitespace > options (--add-opens, --add-exports,--add-reads, --add-modules, --patch-module,--limit-modules, or --upgrade-module-path) as well > as of the case when a source-file mode is used or when --module options is used in "--=" format. > > Testing: sun/tools/jcmd and serviceability/dcmd/framework tests succeeded in Mach5. jdk_svc, tier1, tier2, and tier3 tests are in progress. > > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8225543/webrev.01/ > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8225543 > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > Thanks! > --Daniil > > > > > > From andrew_m_leonard at uk.ibm.com Thu Jun 13 08:55:19 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 13 Jun 2019 09:55:19 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: Thanks Serguei, i'll add those changes to my new webrev I am working on based on Alan's suggestions. It should be ready once i've finished my stress tests later today. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: "serguei.spitsyn at oracle.com" To: Andrew Leonard , Alex Menkov Cc: serviceability-dev at openjdk.java.net Date: 12/06/2019 20:52 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners Hi Andrew, It looks good. Minor comments on the test. There are several places where white spaces are missed around the signs: '=', '<', '+', ',': 58 for(int j=0; j<10; j++) { 62 int numThreads=10; 66 for(int i=0; i Hi Alex, > Thanks for trying this out, it's possible this failure is an issue with > my testcase, as I repeat the 10 thread test loop 10 times and I have a > 30 second timeout which potentially might overrun if a connection takes > time to terminate. I could avoid that simply by using different ports > for each run, equally it could also be an issue as pointed out by Alan. The test uses fixed ports, so it can interfere with other processes. You can use port "0" which automatically selects free port. connector.startListening returns actual port assigned for the connection. > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Alex Menkov > To: Andrew Leonard , > serviceability-dev at openjdk.java.net > Date: 07/06/2019 22:19 > Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address > already in use" with concurrent listeners > ------------------------------------------------------------------------ > > > > Hi Andrew, > > The fix looks good in general. > And I can be the sponsor. > I've tested the fix and got 1 test failure (of 400 runs) on Win-x64 and > the log looks the same. > > java.lang.RuntimeException: Failed to accept connector connection > at JdwpConcurrentAttachTest.main(JdwpConcurrentAttachTest.java:74) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:830) > Caused by: java.net.BindException: Address already in use: bind > at java.base/sun.nio.ch.Net.bind0(Native Method) > at java.base/sun.nio.ch.Net.bind(Net.java:465) > at java.base/sun.nio.ch.Net.bind(Net.java:457) > at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) > at java.base/java.net.ServerSocket.bind(ServerSocket.java:359) > at java.base/java.net.ServerSocket.bind(ServerSocket.java:313) > at > jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:300) > at > jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:310) > at > jdk.jdi/com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:117) > at > jdk.jdi/com.sun.tools.jdi.SocketListeningConnector.startListening(SocketListeningConnector.java:86) > at JdwpConcurrentAttachTest.attachTest(JdwpConcurrentAttachTest.java:111) > at JdwpConcurrentAttachTest.run(JdwpConcurrentAttachTest.java:93) > > So looks like the fix doesn't fix the issue completely. > > --alex > > On 06/07/2019 07:24, Andrew Leonard wrote: >> Hi, >> Please can I request a sponsor and review of this patch for JDK-8225474. >> A problem that we have seen intermittently with JDI connector stress >> tests for quite a while that is caused by an non-thread safe HashMap in >> the connector class. I've created a standalone testcase that reproduces >> it reliably. >> http://cr.openjdk.java.net/~aleonard/8225474/webrev.00 >> >> Thanks >> Andrew >> >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> internet email: andrew_m_leonard at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Thu Jun 13 17:15:45 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 13 Jun 2019 10:15:45 -0700 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: One more minor note for the test: @build HelloWorld JdwpConcurrentAttachTest The test does not use HelloWorld class --alex On 06/12/2019 12:52, serguei.spitsyn at oracle.com wrote: > Hi Andrew, > > It looks good. > > Minor comments on the test. > > There are several places where white spaces are missed around the signs: > '=', '<', '+', ',': > > 58 for(int j=0; j<10; j++) { > > 62 int numThreads=10; > > 66 for(int i=0; i > 67 JdwpConcurrentAttachTest test = new JdwpConcurrentAttachTest(localAddresses[0].getHostAddress(),0); > > 78 > 79 static boolean failure=false; > 80 static Exception failureException=null; > > ?112 log("Listening address = "+actualAddress); > > 123 failureException=e; > > 132 +",address="+ actualAddress > > > > > > On 6/11/19 12:36, Andrew Leonard wrote: >> Thanks Alex, >> I have changed the testcase to allocate ports which makes better >> sense: http://cr.openjdk.java.net/~aleonard/8225474/webrev.02/ >> Cheers >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> >> >> From: Alex Menkov >> To: Andrew Leonard >> Cc: serviceability-dev at openjdk.java.net >> Date: 10/06/2019 20:43 >> Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address >> already in use" with concurrent listeners >> ------------------------------------------------------------------------ >> >> >> >> >> >> On 06/10/2019 02:07, Andrew Leonard wrote: >> > Hi Alex, >> > Thanks for trying this out, it's possible this failure is an issue with >> > my testcase, as I repeat the 10 thread test loop 10 times and I have a >> > 30 second timeout which potentially might overrun if a connection takes >> > time to terminate. I could avoid that simply by using different ports >> > for each run, equally it could also be an issue as pointed out by Alan. >> >> The test uses fixed ports, so it can interfere with other processes. >> You can use port "0" which automatically selects free port. >> connector.startListening returns actual port assigned for the connection. >> >> > Thanks >> > Andrew >> > >> > Andrew Leonard >> > Java Runtimes Development >> > IBM Hursley >> > IBM United Kingdom Ltd >> > internet email: andrew_m_leonard at uk.ibm.com >> > >> > >> > >> > >> > From: Alex Menkov >> > To: Andrew Leonard , >> > serviceability-dev at openjdk.java.net >> > Date: 07/06/2019 22:19 >> > Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address >> > already in use" with concurrent listeners >> > ------------------------------------------------------------------------ >> > >> > >> > >> > Hi Andrew, >> > >> > The fix looks good in general. >> > And I can be the sponsor. >> > I've tested the fix and got 1 test failure (of 400 runs) on Win-x64 and >> > the log looks the same. >> > >> > java.lang.RuntimeException: Failed to accept connector connection >> > at JdwpConcurrentAttachTest.main(JdwpConcurrentAttachTest.java:74) >> > at >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> > Method) >> > at >> > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> > at >> > >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> > at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> > at >> > >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> > at java.base/java.lang.Thread.run(Thread.java:830) >> > Caused by: java.net.BindException: Address already in use: bind >> > at java.base/sun.nio.ch.Net.bind0(Native Method) >> > at java.base/sun.nio.ch.Net.bind(Net.java:465) >> > at java.base/sun.nio.ch.Net.bind(Net.java:457) >> > at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) >> > at java.base/java.net.ServerSocket.bind(ServerSocket.java:359) >> > at java.base/java.net.ServerSocket.bind(ServerSocket.java:313) >> > at >> > >> jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:300) >> > at >> > >> jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:310) >> > at >> > >> jdk.jdi/com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:117) >> > at >> > >> jdk.jdi/com.sun.tools.jdi.SocketListeningConnector.startListening(SocketListeningConnector.java:86) >> > at >> JdwpConcurrentAttachTest.attachTest(JdwpConcurrentAttachTest.java:111) >> > at JdwpConcurrentAttachTest.run(JdwpConcurrentAttachTest.java:93) >> > >> > So looks like the fix doesn't fix the issue completely. >> > >> > --alex >> > >> > On 06/07/2019 07:24, Andrew Leonard wrote: >> >> Hi, >> >> Please can I request a sponsor and review of this patch for >> JDK-8225474. >> >> A problem that we have seen intermittently with JDI connector stress >> >> tests for quite a while that is caused by an non-thread safe >> HashMap ?in >> >> the connector class. I've created a standalone testcase that reproduces >> >> it reliably. >> >> http://cr.openjdk.java.net/~aleonard/8225474/webrev.00 >> >> >> >> Thanks >> >> Andrew >> >> >> >> >> >> Andrew Leonard >> >> Java Runtimes Development >> >> IBM Hursley >> >> IBM United Kingdom Ltd >> >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> >> Unless stated otherwise above: >> >> IBM United Kingdom Limited - Registered in England and Wales with >> ?number >> >> 741598. >> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> ?PO6 3AU >> > >> > >> > >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with >> number >> > 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 3AU >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with >> number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From daniil.x.titov at oracle.com Thu Jun 13 18:24:12 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 13 Jun 2019 11:24:12 -0700 Subject: 8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process In-Reply-To: <19456c63-8224-71ed-2266-e50348aa7b88@oracle.com> References: <4365A022-0817-46F1-A698-892042494F36@oracle.com> <19456c63-8224-71ed-2266-e50348aa7b88@oracle.com> Message-ID: <7E81FD05-0ED1-4EE7-AB96-E35E2FCA55EA@oracle.com> Thank you, David and Serguei, for reviewing this change! Best regards, Daniil ?On 6/12/19, 10:21 PM, "David Holmes" wrote: Hi Daniil, These changes seem quite reasonable. In hindsight splitting the command-line based on spaces was bound to hit problems with arguments containing spaces. :( Thanks for fixing. David On 13/06/2019 3:50 am, Daniil Titov wrote: > Hi David and Serguei, > > Could you please have a look at this change? This fix is related with the changes [3] that you reviewed back in February. > > Mach5 sun/tools/jcmd, serviceability/dcmd/framework, jdk_svc, hotspot_serviceability, tier1, tier2 and tier3 tests passed. > > Thanks a lot! > --Daniil > > ?On 6/10/19, 4:56 PM, "serviceability-dev on behalf of Daniil Titov" wrote: > > Please review the change that fixes jcmd process name matching on Linux platform. > > After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, sun.tools.ProcessHelper class, > introduced in that change, didn't take into account the presence of module whitespace options ( e.g. --patch-module) or the > fact that some values of Java options could contain whitespaces. > > The latter problem is fixed by keeping '\0' as a separator for command line arguments read from /proc/{pid}/cmdline rather than > replacing it with a whitespace. The former problem is fixed by making sun.tools.ProcessHelper aware of these module whitespace > options (--add-opens, --add-exports,--add-reads, --add-modules, --patch-module,--limit-modules, or --upgrade-module-path) as well > as of the case when a source-file mode is used or when --module options is used in "--=" format. > > Testing: sun/tools/jcmd and serviceability/dcmd/framework tests succeeded in Mach5. jdk_svc, tier1, tier2, and tier3 tests are in progress. > > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8225543/webrev.01/ > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8225543 > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > Thanks! > --Daniil > > > > > > From andrew_m_leonard at uk.ibm.com Thu Jun 13 19:18:12 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 13 Jun 2019 20:18:12 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: Thanks Alex, good spot. I have done all the changes now with the latest updates, and have performed some stress tests on xLinux, Win64 and Mac64, all successful. Please can I get reviews and sponsor for webrev.04: http://cr.openjdk.java.net/~aleonard/8225474/webrev.04/ Many Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alex Menkov To: "serguei.spitsyn at oracle.com" , Andrew Leonard Cc: serviceability-dev at openjdk.java.net Date: 13/06/2019 18:15 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners One more minor note for the test: @build HelloWorld JdwpConcurrentAttachTest The test does not use HelloWorld class --alex On 06/12/2019 12:52, serguei.spitsyn at oracle.com wrote: > Hi Andrew, > > It looks good. > > Minor comments on the test. > > There are several places where white spaces are missed around the signs: > '=', '<', '+', ',': > > 58 for(int j=0; j<10; j++) { > > 62 int numThreads=10; > > 66 for(int i=0; i > 67 JdwpConcurrentAttachTest test = new JdwpConcurrentAttachTest(localAddresses[0].getHostAddress(),0); > > 78 > 79 static boolean failure=false; > 80 static Exception failureException=null; > > 112 log("Listening address = "+actualAddress); > > 123 failureException=e; > > 132 +",address="+ actualAddress > > > > > > On 6/11/19 12:36, Andrew Leonard wrote: >> Thanks Alex, >> I have changed the testcase to allocate ports which makes better >> sense: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8225474_webrev.02_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=p--c3Hawio2kCsD0eo4leL8TLWZPtlYui8rmDo0E7So&s=EnJJuj3Yg8BeU7c2Fn6cqEeJGa6C5e4pIWGESAjwfhc&e= >> Cheers >> Andrew >> >> Andrew Leonard >> Java Runtimes Development >> IBM Hursley >> IBM United Kingdom Ltd >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> >> >> From: Alex Menkov >> To: Andrew Leonard >> Cc: serviceability-dev at openjdk.java.net >> Date: 10/06/2019 20:43 >> Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address >> already in use" with concurrent listeners >> ------------------------------------------------------------------------ >> >> >> >> >> >> On 06/10/2019 02:07, Andrew Leonard wrote: >> > Hi Alex, >> > Thanks for trying this out, it's possible this failure is an issue with >> > my testcase, as I repeat the 10 thread test loop 10 times and I have a >> > 30 second timeout which potentially might overrun if a connection takes >> > time to terminate. I could avoid that simply by using different ports >> > for each run, equally it could also be an issue as pointed out by Alan. >> >> The test uses fixed ports, so it can interfere with other processes. >> You can use port "0" which automatically selects free port. >> connector.startListening returns actual port assigned for the connection. >> >> > Thanks >> > Andrew >> > >> > Andrew Leonard >> > Java Runtimes Development >> > IBM Hursley >> > IBM United Kingdom Ltd >> > internet email: andrew_m_leonard at uk.ibm.com >> > >> > >> > >> > >> > From: Alex Menkov >> > To: Andrew Leonard , >> > serviceability-dev at openjdk.java.net >> > Date: 07/06/2019 22:19 >> > Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address >> > already in use" with concurrent listeners >> > ------------------------------------------------------------------------ >> > >> > >> > >> > Hi Andrew, >> > >> > The fix looks good in general. >> > And I can be the sponsor. >> > I've tested the fix and got 1 test failure (of 400 runs) on Win-x64 and >> > the log looks the same. >> > >> > java.lang.RuntimeException: Failed to accept connector connection >> > at JdwpConcurrentAttachTest.main(JdwpConcurrentAttachTest.java:74) >> > at >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> > Method) >> > at >> > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> > at >> > >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> > at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> > at >> > >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> > at java.base/java.lang.Thread.run(Thread.java:830) >> > Caused by: java.net.BindException: Address already in use: bind >> > at java.base/sun.nio.ch.Net.bind0(Native Method) >> > at java.base/sun.nio.ch.Net.bind(Net.java:465) >> > at java.base/sun.nio.ch.Net.bind(Net.java:457) >> > at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) >> > at java.base/java.net.ServerSocket.bind(ServerSocket.java:359) >> > at java.base/java.net.ServerSocket.bind(ServerSocket.java:313) >> > at >> > >> jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:300) >> > at >> > >> jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:310) >> > at >> > >> jdk.jdi/com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:117) >> > at >> > >> jdk.jdi/com.sun.tools.jdi.SocketListeningConnector.startListening(SocketListeningConnector.java:86) >> > at >> JdwpConcurrentAttachTest.attachTest(JdwpConcurrentAttachTest.java:111) >> > at JdwpConcurrentAttachTest.run(JdwpConcurrentAttachTest.java:93) >> > >> > So looks like the fix doesn't fix the issue completely. >> > >> > --alex >> > >> > On 06/07/2019 07:24, Andrew Leonard wrote: >> >> Hi, >> >> Please can I request a sponsor and review of this patch for >> JDK-8225474. >> >> A problem that we have seen intermittently with JDI connector stress >> >> tests for quite a while that is caused by an non-thread safe >> HashMap in >> >> the connector class. I've created a standalone testcase that reproduces >> >> it reliably. >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8225474_webrev.00&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=p--c3Hawio2kCsD0eo4leL8TLWZPtlYui8rmDo0E7So&s=x6HRkbkPCW_es-f8XAsaOkS_l1-2ykSqIiCUIRk24oA&e= >> >> >> >> Thanks >> >> Andrew >> >> >> >> >> >> Andrew Leonard >> >> Java Runtimes Development >> >> IBM Hursley >> >> IBM United Kingdom Ltd >> >> internet email: andrew_m_leonard at uk.ibm.com >> >> >> >> Unless stated otherwise above: >> >> IBM United Kingdom Limited - Registered in England and Wales with >> number >> >> 741598. >> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 3AU >> > >> > >> > >> > >> > Unless stated otherwise above: >> > IBM United Kingdom Limited - Registered in England and Wales with >> number >> > 741598. >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 3AU >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with >> number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri Jun 14 05:49:24 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 14 Jun 2019 14:49:24 +0900 Subject: RFR: 8225636: SA can't handle prelinked libraries Message-ID: Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ I attempted to open the core which is generated by RHEL 6, but it could not . The OS which generated the core is set to enable prelink. According to GDB implementation, load address of prelinked library should be calculated by offset of link_map.l_ld and the address of .dynamic section. Thanks, Yasumasa From Alan.Bateman at oracle.com Fri Jun 14 08:25:32 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Jun 2019 09:25:32 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: On 13/06/2019 20:18, Andrew Leonard wrote: > Thanks Alex, good spot. > I have done all the changes now with the latest updates, and have > performed some stress tests on xLinux, Win64 and Mac64, all successful. > > Please can I get reviews and sponsor for webrev.04: > http://cr.openjdk.java.net/~aleonard/8225474/webrev.04/ Retrofitting code that wasn't developed to be used by multiple concurrent threads to be thread safe takes time and will require a lot of review effort. I don't have time to spend on this now and I suspect this one will need a second reviewer to help with the confidence that you've got everything. Things to check are: - ConnectorImpl::toString iterates over the values in defaultArguments, I assume this will require synchronization - ConnectorImpl.trueString and falseString are initialized lazily without synchronization. It might be okay but a comment to explain why. Ditto for the lazily initialization of the messages field in getString. - All but the "value" field in the Connector.Argument implementations should be final. It might be that the value fields need to volatile (needs more study). - GenericListeningConnector fields should be final. You can also initialize listenMap with new ConcurrentHashMap<>() . - GenericListeningConnector.accept needs further analysis, at least for the case where the debugger hasn't called startListening. There may be more issues, it just needs time to walk through the original implementation. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Fri Jun 14 14:52:07 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 14 Jun 2019 15:52:07 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: In doing the recent changes I applied knowledge of how the ConnectorImpl and its defaultArguments are used to decide on what is necessary from a threading perspective. I also am only considering the "listening" concurrency issue, at this stage, and was not considering making all the jdi classes thread-safe. The defaultArguments is constructed at GenericListenerConnector constructor time, and not changed from there. The whole ConnectorImpl implementation is basically to wrapper a TransportService with a set of "default arguments" set at object construction. This design affects what is necessary from a threading perspective for the Connector instance: - ConnectorImpl::toString iterates over the values in defaultArguments, I assume this will require synchronization => Not necessary as defaultArguments does not change after construction - ConnectorImpl.trueString and falseString are initialized lazily without synchronization. It might be okay but a comment to explain why. Ditto for the lazily initialization of the messages field in getString. => "messages" is an instance variable initialized at constructor time only => true/falseString are static, they probably should be a kin to the "messages", but since they are just "immutable" Strings I don't think it's an issue as-is - All but the "value" field in the Connector.Argument implementations should be final. It might be that the value fields need to volatile (needs more study). => Again I didn't see the essential need for this given the defaultArguments are constructed and not modified, including the "value" field. From the perspective of callers obtaining a copy-of the defaultArguments to set their own values, I saw that then as being a "thread-safety" concern of that calling code. - GenericListeningConnector fields should be final. You can also initialize listenMap with new ConcurrentHashMap<>() . => Isn't this just optimization not relevant to the "bug" in question? - GenericListeningConnector.accept needs further analysis, at least for the case where the debugger hasn't called startListening. => I did think through the accept() method logic, and the compatibility start/stopListening if needed looks fine to me I must agree that retro-fitting thread safety when not design from the start is difficult. So I therefore question the testcase, the spec doesn't state it is thread-safe, so why have we written testcases assuming it? Given the JDWP/JDI spec does it lends itself for a user to naturally assume having multiple threads listening on the SocketListen Connector is a reasonable usecase? How would a debugger font-end UI handle it? I'm not experienced enough with JDI, but my natural thought is it could be reasonable to have a "front-end" listening on multiple TargetVM's and handling them in a multi-threaded manner....? Should we re-target this as a CSR request instead? and re-implement. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alan Bateman To: Andrew Leonard Cc: serviceability-dev at openjdk.java.net Date: 14/06/2019 09:27 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners On 13/06/2019 20:18, Andrew Leonard wrote: Thanks Alex, good spot. I have done all the changes now with the latest updates, and have performed some stress tests on xLinux, Win64 and Mac64, all successful. Please can I get reviews and sponsor for webrev.04: http://cr.openjdk.java.net/~aleonard/8225474/webrev.04/ Retrofitting code that wasn't developed to be used by multiple concurrent threads to be thread safe takes time and will require a lot of review effort. I don't have time to spend on this now and I suspect this one will need a second reviewer to help with the confidence that you've got everything. Things to check are: - ConnectorImpl::toString iterates over the values in defaultArguments, I assume this will require synchronization - ConnectorImpl.trueString and falseString are initialized lazily without synchronization. It might be okay but a comment to explain why. Ditto for the lazily initialization of the messages field in getString. - All but the "value" field in the Connector.Argument implementations should be final. It might be that the value fields need to volatile (needs more study). - GenericListeningConnector fields should be final. You can also initialize listenMap with new ConcurrentHashMap<>() . - GenericListeningConnector.accept needs further analysis, at least for the case where the debugger hasn't called startListening. There may be more issues, it just needs time to walk through the original implementation. -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgu at redhat.com Fri Jun 14 15:50:57 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 14 Jun 2019 11:50:57 -0400 Subject: RFR(S) 8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes Message-ID: <813cfae5-a9d7-0d3d-0eea-191d4900990e@redhat.com> Please review this patch, that adjusts SA to reflect removal of extra header for forwarding pointer. Bug: https://bugs.openjdk.java.net/browse/JDK-8225801 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225801/webrev.00/ Test: hotspot_gc_shenandoah Manual test. Thanks, -Zhengyu From shade at redhat.com Fri Jun 14 15:55:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jun 2019 17:55:53 +0200 Subject: RFR(S) 8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes In-Reply-To: <813cfae5-a9d7-0d3d-0eea-191d4900990e@redhat.com> References: <813cfae5-a9d7-0d3d-0eea-191d4900990e@redhat.com> Message-ID: On 6/14/19 5:50 PM, Zhengyu Gu wrote: > Please review this patch, that adjusts SA to reflect removal of extra header for forwarding pointer. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225801 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225801/webrev.00/ Looks good. This comment is outdated: // Dealing with a raw pointer, offsets forward pointer to find real Oop. -- Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From Alan.Bateman at oracle.com Fri Jun 14 16:06:09 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Jun 2019 17:06:09 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: On 14/06/2019 15:52, Andrew Leonard wrote: > In doing the recent changes I applied knowledge of how the > ConnectorImpl and its defaultArguments are used to decide on what is > necessary from a threading perspective. I also am only considering the > "listening" concurrency issue, at this stage, and was not considering > making all the jdi classes thread-safe. Sure but default arguments exposed in the ListeningConnector API are mutable. It may be that debuggers and other tools aren't changing them but we can't say that the GenericListeningConnector and its implementations are safe for by use by concurrent threads without studying this further. Also the comments about changing fields to final are not optimizations, that are suggestions to allow GenericListeningConnector objects be safely published. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgu at redhat.com Fri Jun 14 16:10:01 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 14 Jun 2019 12:10:01 -0400 Subject: RFR(S) 8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes In-Reply-To: References: <813cfae5-a9d7-0d3d-0eea-191d4900990e@redhat.com> Message-ID: <691de2b8-95ee-15a5-69dc-189e37035a8d@redhat.com> Removed the comment and pushed. Thanks! -Zhengyu On 6/14/19 11:55 AM, Aleksey Shipilev wrote: > On 6/14/19 5:50 PM, Zhengyu Gu wrote: >> Please review this patch, that adjusts SA to reflect removal of extra header for forwarding pointer. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225801 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225801/webrev.00/ > > Looks good. > > This comment is outdated: > // Dealing with a raw pointer, offsets forward pointer to find real Oop. > From rkennke at redhat.com Fri Jun 14 16:58:22 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 14 Jun 2019 18:58:22 +0200 Subject: RFR(S) 8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes In-Reply-To: <813cfae5-a9d7-0d3d-0eea-191d4900990e@redhat.com> References: <813cfae5-a9d7-0d3d-0eea-191d4900990e@redhat.com> Message-ID: <67ACD14D-980B-4DFB-937C-B8A02CBEE502@redhat.com> Oops, totally forgot about that. Should this also go into jdk13 as bugfix? Roman Am 14. Juni 2019 17:50:57 MESZ schrieb Zhengyu Gu : >Please review this patch, that adjusts SA to reflect removal of extra >header for forwarding pointer. > >Bug: https://bugs.openjdk.java.net/browse/JDK-8225801 >Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225801/webrev.00/ > >Test: > hotspot_gc_shenandoah > Manual test. > > >Thanks, > >-Zhengyu -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgu at redhat.com Fri Jun 14 18:00:52 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 14 Jun 2019 14:00:52 -0400 Subject: RFR(S) 8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes In-Reply-To: <67ACD14D-980B-4DFB-937C-B8A02CBEE502@redhat.com> References: <813cfae5-a9d7-0d3d-0eea-191d4900990e@redhat.com> <67ACD14D-980B-4DFB-937C-B8A02CBEE502@redhat.com> Message-ID: <85e06d50-9e25-f363-f416-d22601154baa@redhat.com> On 6/14/19 12:58 PM, Roman Kennke wrote: > Oops, totally forgot about that. Should this also go into jdk13 as bugfix? Yes, I think so. -Zhengyu > > Roman > > > Am 14. Juni 2019 17:50:57 MESZ schrieb Zhengyu Gu : > > Please review this patch, that adjusts SA to reflect removal of extra > header for forwarding pointer. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8225801 > Webrev:http://cr.openjdk.java.net/~zgu/JDK-8225801/webrev.00/ > > Test: > hotspot_gc_shenandoah > Manual test. > > > Thanks, > > -Zhengyu > > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From alexey.menkov at oracle.com Fri Jun 14 18:08:26 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Jun 2019 11:08:26 -0700 Subject: [13] RFR: JDK-8225682: Reference to JNI spec on java.sun.com Message-ID: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> Hi all, Please review small fix for "Java Debug Wire Protocol" page. The change fixes the link and typo ("Inteface" -> "Interface"). jira: https://bugs.openjdk.java.net/browse/JDK-8225682 webrev: http://cr.openjdk.java.net/~amenkov/docs/jdwp-protocol_jni_link/webrev/ --alex From gary.adams at oracle.com Fri Jun 14 18:15:52 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 14 Jun 2019 14:15:52 -0400 Subject: [13] RFR: JDK-8225682: Reference to JNI spec on java.sun.com In-Reply-To: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> References: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> Message-ID: <5D03E458.8050905@oracle.com> And the copyright. Looks good to me. On 6/14/19, 2:08 PM, Alex Menkov wrote: > Hi all, > > Please review small fix for "Java Debug Wire Protocol" page. > The change fixes the link and typo ("Inteface" -> "Interface"). > > jira: https://bugs.openjdk.java.net/browse/JDK-8225682 > webrev: > http://cr.openjdk.java.net/~amenkov/docs/jdwp-protocol_jni_link/webrev/ > > --alex From zgu at redhat.com Fri Jun 14 18:19:02 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 14 Jun 2019 14:19:02 -0400 Subject: RFR(T) 8225804: SA: Remove unused CollectedHeap.oopOffset() method Message-ID: <2b2c4832-718a-aa84-3361-fe67b918a58b@redhat.com> Please review this patch that removes a method that is no longer needed. CollectedHeap.oopOffset() was added for Shenandoah GC to offset extra header for forwarding pointer. Recently, Shenandoah removed the header and folded the forwarding pointer into regular header, so this method is now obsoleted. Bug: https://bugs.openjdk.java.net/browse/JDK-8225804 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225804/webrev.00/ Test: hotspot_serviceability (fastdebug and release) Submit test in progress. Thanks, -Zhengyu From serguei.spitsyn at oracle.com Fri Jun 14 18:30:37 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2019 11:30:37 -0700 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: References: Message-ID: Hi Yasumasa, It looks good to me. The function read_exec_segments is already pretty big and needs a refactoring. The code you are adding deserves to be a separate function, something like read_prog_segm... Thanks, Serguei On 6/13/19 22:49, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ > > I attempted to open the core which is generated by RHEL 6, but it could not . > > The OS which generated the core is set to enable prelink. > According to GDB implementation, load address of prelinked library > should be calculated by offset of link_map.l_ld and the address of > .dynamic section. > > > Thanks, > > Yasumasa From chris.plummer at oracle.com Fri Jun 14 18:40:36 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 14 Jun 2019 11:40:36 -0700 Subject: [13] RFR: JDK-8225682: Reference to JNI spec on java.sun.com In-Reply-To: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> References: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> Message-ID: <15769e76-0bff-4cd8-f2fe-1968f4b1914f@oracle.com> Have you confirmed the link is working? Chris On 6/14/19 11:08 AM, Alex Menkov wrote: > Hi all, > > Please review small fix for "Java Debug Wire Protocol" page. > The change fixes the link and typo ("Inteface" -> "Interface"). > > jira: https://bugs.openjdk.java.net/browse/JDK-8225682 > webrev: > http://cr.openjdk.java.net/~amenkov/docs/jdwp-protocol_jni_link/webrev/ > > --alex From chris.plummer at oracle.com Fri Jun 14 18:48:53 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 14 Jun 2019 11:48:53 -0700 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: References: Message-ID: Hi Yasumasa, I think you should replace the embedded link with more of a textual description of where to look in the gdb source. I'd like to see some short comments. You have a few logical blocks of code that would greatly benefit from just one line saying what they are doing, especially the loop. thanks, Chris On 6/13/19 10:49 PM, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ > > I attempted to open the core which is generated by RHEL 6, but it could not . > > The OS which generated the core is set to enable prelink. > According to GDB implementation, load address of prelinked library > should be calculated by offset of link_map.l_ld and the address of > .dynamic section. > > > Thanks, > > Yasumasa From alexey.menkov at oracle.com Fri Jun 14 19:13:21 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Jun 2019 12:13:21 -0700 Subject: [13] RFR: JDK-8225682: Reference to JNI spec on java.sun.com In-Reply-To: <15769e76-0bff-4cd8-f2fe-1968f4b1914f@oracle.com> References: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> <15769e76-0bff-4cd8-f2fe-1968f4b1914f@oracle.com> Message-ID: <80dc5628-928e-e8e2-eafc-1fc84868dbcf@oracle.com> It works in local build directory, also I checked jdk12 online docs (https://docs.oracle.com/en/java/javase/12/docs/specs/jdwp/jdwp-protocol.html) - relative paths preserve. --alex On 06/14/2019 11:40, Chris Plummer wrote: > Have you confirmed the link is working? > > Chris > > On 6/14/19 11:08 AM, Alex Menkov wrote: >> Hi all, >> >> Please review small fix for "Java Debug Wire Protocol" page. >> The change fixes the link and typo ("Inteface" -> "Interface"). >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8225682 >> webrev: >> http://cr.openjdk.java.net/~amenkov/docs/jdwp-protocol_jni_link/webrev/ >> >> --alex > > From alexey.menkov at oracle.com Fri Jun 14 19:14:34 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Jun 2019 12:14:34 -0700 Subject: [13] RFR: JDK-8225682: Reference to JNI spec on java.sun.com In-Reply-To: <5D03E458.8050905@oracle.com> References: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> <5D03E458.8050905@oracle.com> Message-ID: Thanks Gary, I'll update copyright year before push --alex On 06/14/2019 11:15, Gary Adams wrote: > And the copyright. > > Looks good to me. > > On 6/14/19, 2:08 PM, Alex Menkov wrote: >> Hi all, >> >> Please review small fix for "Java Debug Wire Protocol" page. >> The change fixes the link and typo ("Inteface" -> "Interface"). >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8225682 >> webrev: >> http://cr.openjdk.java.net/~amenkov/docs/jdwp-protocol_jni_link/webrev/ >> >> --alex > From chris.plummer at oracle.com Fri Jun 14 19:30:45 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 14 Jun 2019 12:30:45 -0700 Subject: [13] RFR: JDK-8225682: Reference to JNI spec on java.sun.com In-Reply-To: <80dc5628-928e-e8e2-eafc-1fc84868dbcf@oracle.com> References: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> <15769e76-0bff-4cd8-f2fe-1968f4b1914f@oracle.com> <80dc5628-928e-e8e2-eafc-1fc84868dbcf@oracle.com> Message-ID: <2dd6c9d8-3ce2-2d14-989c-28741e058605@oracle.com> Ok. Looks good then. Chris On 6/14/19 12:13 PM, Alex Menkov wrote: > It works in local build directory, also I checked jdk12 online docs > (https://docs.oracle.com/en/java/javase/12/docs/specs/jdwp/jdwp-protocol.html) > - relative paths preserve. > > --alex > > On 06/14/2019 11:40, Chris Plummer wrote: >> Have you confirmed the link is working? >> >> Chris >> >> On 6/14/19 11:08 AM, Alex Menkov wrote: >>> Hi all, >>> >>> Please review small fix for "Java Debug Wire Protocol" page. >>> The change fixes the link and typo ("Inteface" -> "Interface"). >>> >>> jira: https://bugs.openjdk.java.net/browse/JDK-8225682 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/docs/jdwp-protocol_jni_link/webrev/ >>> >>> --alex >> >> From serguei.spitsyn at oracle.com Fri Jun 14 21:13:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2019 14:13:58 -0700 Subject: [13] RFR: JDK-8225682: Reference to JNI spec on java.sun.com In-Reply-To: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> References: <3ee2482e-2d41-0e2a-c671-b35689967a48@oracle.com> Message-ID: Hi Alex, Looks good. Thanks, Serguei On 6/14/19 11:08 AM, Alex Menkov wrote: > Hi all, > > Please review small fix for "Java Debug Wire Protocol" page. > The change fixes the link and typo ("Inteface" -> "Interface"). > > jira: https://bugs.openjdk.java.net/browse/JDK-8225682 > webrev: > http://cr.openjdk.java.net/~amenkov/docs/jdwp-protocol_jni_link/webrev/ > > --alex From serguei.spitsyn at oracle.com Fri Jun 14 21:18:40 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2019 14:18:40 -0700 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: References: Message-ID: <9ff9901f-cca8-5583-f416-00fa7be73817@oracle.com> I do not see my message below in my serviceability-dev mailbox. Resending to make sure it reaches the target. Thanks, Serguei On 6/14/19 11:30 AM, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > It looks good to me. > > The function read_exec_segments is already pretty big and needs a > refactoring. > The code you are adding deserves to be a separate function, something > like read_prog_segm... > > Thanks, > Serguei > > > On 6/13/19 22:49, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 >> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ >> >> I attempted to open the core which is generated by RHEL 6, but it >> could not . >> >> The OS which generated the core is set to enable prelink. >> According to GDB implementation, load address of prelinked library >> should be calculated by offset of link_map.l_ld and the address of >> .dynamic section. >> >> >> Thanks, >> >> Yasumasa > From serguei.spitsyn at oracle.com Fri Jun 14 23:00:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2019 16:00:36 -0700 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> Message-ID: Hi Yasumasa, I've added myself as a reviewer, so you can finalize it now. The fix looks pretty good to me. One minor suggestion is to use the final field NO_REMOTE instead of null for initialization of the local variable "remote". Also just an observation that there is some room for option processing refactoring. All the jhsdb sub-commands do execute similar loops like this: while((s = sg.next(null, longOpts)) != null) { ??????? . . . ??? } It can be moved into a separate method instead. The longOpts can passed in arguments. It can be something like this: ??? private ArrayList processOptions(final String[] oldArgs, ???????????????????????????????????????????? final String[] longOpts, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean allowEmpty) { ??????? SAGetopt sg = new SAGetopt(oldArgs); ??????? ArrayList newArgs = new ArrayList(); ??????? String pid = null; ??????? String exe = null; ??????? String core = null; ??????? String s = null; ??????? String dumpfile = null; ??????? String remote = NO_REMOTE; ??????? boolean requestHeapdump = false; ??????? while((s = sg.next(null, longOpts)) != null) { ??????????? if (s.equals("exe")) { ??????????????? exe = sg.getOptarg(); ??????????????? continue; ??????????? } ??????????? if (s.equals("core")) { ??????????????? core = sg.getOptarg(); ??????????????? continue; ??????????? } ??????????? if (s.equals("pid")) { ???????????????? pid = sg.getOptarg(); ???????????????? continue; ??????????? } ??????????? if (s.equals("remote")) { ??????????????? remote = sg.getOptarg(); ??????????????? continue; ??????????? } ??????????? if (s.equals("mixed")) { ??????????????? newArgs.add("-m"); ??????????????? continue; ??????????? } ??????????? if (s.equals("locks")) { ??????????????? newArgs.add("-l"); ??????????????? continue; ??????????? } ??????????? if (s.equals("heap")) { ??????????????? newArgs.add("-heap"); ??????????????? continue; ??????????? } ??????????? if (s.equals("binaryheap")) { ??????????????? requestHeapdump = true; ??????????????? continue; ??????????? } ??????????? if (s.equals("dumpfile")) { ??????????????? dumpfile = sg.getOptarg(); ??????????????? continue; ??????????? } ??????????? if (s.equals("histo")) { ??????????????? newArgs.add("-histo"); ??????????????? continue; ??????????? } ??????????? if (s.equals("clstats")) { ??????????????? newArgs.add("-clstats"); ???????????????? continue; ??????????? } ??????????? if (s.equals("finalizerinfo")) { ??????????????? newArgs.add("-finalizerinfo"); ??????????????? continue; ??????????? } ??????????? if (s.equals("flags")) { ??????????????? newArgs.add("-flags"); ??????????????? continue; ??????????? } ??????????? if (s.equals("sysprops")) { ??????????????? newArgs.add("-sysprops"); ??????????????? continue; ??????????? } ??????????? if (s.equals("serverid")) { ??????????????? String serverid = sg.getOptarg(); ??????????????? if (serverid != null) { ??????????????????? newArgs.add(serverid); ??????????????? } ??????????????? continue; ??????????? } ??????? } ??????? if (!requestHeapdump && (dumpfile != null)) { ??????????? throw new IllegalArgumentException("Unexpected argument dumpfile"); ??????? } ??????? if (requestHeapdump) { ??????????? if (dumpfile == null) { ??????????????? newArgs.add("-heap:format=b"); ??????????? } else { ???????????????? newArgs.add("-heap:format=b,file=" + dumpfile); ??????????? } ??????? } ??????? buildAttachArgs(newArgs, pid, exe, core, remote, allowEmpty); ??????? return newArgs; ??? } ??? private static void runCLHSDB(String[] oldArgs) { ??????? String[] longOpts = {"exe=", "core=", "pid="}; ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, true); ??????? CLHSDB.main(newArgs.toArray(new String[newArgs.size()])); ??? } ??? private static void runHSDB(String[] oldArgs) { ??????? String[] longOpts = {"exe=", "core=", "pid="}; ???????? ArrayList newArgs = processOptions(oldArgs, longOpts, true); ???????? HSDB.main(newArgs.toArray(new String[newArgs.size()])); ??? } ??? private static void runJSTACK(String[] oldArgs) { ??????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", "mixed", "locks"}; ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, false); ??????? JStack jstack = new JStack(false, false); ??????? jstack.runWithArgs(newArgs.toArray(new String[newArgs.size()])); ??? } ??? private static void runJMAP(String[] oldArgs) { ??????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", ????????????? "heap", "binaryheap", "dumpfile=", "histo", "clstats", "finalizerinfo"}; ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, false); ??????? JMap.main(newArgs.toArray(new String[newArgs.size()])); ??? } ??? private static void runJINFO(String[] oldArgs) { ??????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", "flags", "sysprops"}; ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, false); ??????? JInfo.main(newArgs.toArray(new String[newArgs.size()])); ??? } ??? private static void runJSNAP(String[] oldArgs) { ??????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", "all"}; ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, false); ??????? JSnap.main(newArgs.toArray(new String[newArgs.size()])); ??? } ??? private static void runDEBUGD(String[] oldArgs) { ??????? // By default SA agent classes prefer Windows process debugger ??????? // to windbg debugger. SA expects special properties to be set ??????? // to choose other debuggers. We will set those here before ??????? // attaching to SA agent. System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", "true"); ??????? String[] longOpts = {"exe=", "core=", "pid=", "serverid="}; ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, false); ??????? // delegate to the actual SA debug server. ??????? sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new String[newArgs.size()])); ??? } Please, let me know what do you think. Thanks, Serguei On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: > Sorry, new webrev is here: > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > > Yasumasa > > 2019?6?10?(?) 11:27 Yasumasa Suenaga : >> PING: Could you review them? >> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. >> >> >> Thanks, >> >> Yasumasa >> >> >> 2019?6?5?(?) 14:06 Yasumasa Suenaga : >>> Hi Jc, >>> >>> Thank you for your comment! >>> I updated a webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>> >>>> - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... >>> I created DebugdUtils for convenience class for attach - detach >>> mechanism of debug server. >>> IMHO it is prefer "detach" to "close" in this case. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> 2019?6?5?(?) 11:34 Jean Christophe Beyler : >>>> Hi Yasumasa, >>>> >>>> I'm not an official reviewer but I don't see an issue with the CSR (except that this seems to be bringing a fork in the tools with some handling remote and others not). >>>> >>>> However, this code is really repetitive and this is not the place to do a big refactor probably but we could do a few nits perhaps: >>>> - Instead of every tool calling commonHelp with an additional flag you could divide into commonHelp and commonHelpWithRemote for the tools and they both call the current commonHelp with that boolean; so that when we are looking at the tool code we know what we are getting... So something like: >>>> >>>> private static boolean commonHelp(String mode, boolean canConnectToRemote) { >>>> .. >>>> } >>>> >>>> private static boolean commonHelp(String mode) { >>>> return commonHelp(mode, false); >>>> } >>>> >>>> private static boolean commonHelpWithRemote(String mode) { >>>> return commonHelp(mode, false); >>>> } >>>> >>>> and that way the tools that change are just going from: >>>> - return commonHelp("jmap"); >>>> + return commonHelpWithRemote("jmap"); >>>> >>>> - In the same vein, instead of passing null to the buildAttachArgs; you could make a variable null: >>>> >>>> - buildAttachArgs(newArgs, pid, exe, core, true); >>>> + String noRemote = null; >>>> + buildAttachArgs(newArgs, pid, exe, core, noRemote, true); >>>> >>>> >>>> - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>>> Nit: you have empty lines at l64 and l73 >>>> >>>> - http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>>> Nit : you have an empty line at l110 >>>> >>>> - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... >>>> >>>> All of these are details, I just thought I'd mention them :) >>>> Jc >>>> >>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa Suenaga wrote: >>>>> PING: Could you review them? >>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>> CSR status is provisional. So I need reviewers both CSR and webrev. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2019?5?29?(?) 22:37 Yasumasa Suenaga : >>>>>> Hi all, >>>>>> >>>>>> Please review this change: >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>> >>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can connect to >>>>>> debug server (jsadebugd). However it has not done so since JDK 9 because >>>>>> jhsdb cannot accept the attach request to debug server. >>>>>> So I want to introduce new option `--remote` to connect to debug server. >>>>>> >>>>>> I created CSR for this issue. So please review it together. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Jun 14 23:56:11 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 14 Jun 2019 16:56:11 -0700 Subject: RFR: 8217348: assert(thread->is_Java_thread()) failed: just checking Message-ID: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> Please review the change that fixes an intermittent issue. The problem here is that a bitwise-AND (&) operator was used in the condition instead of a logical AND operator (&&). As a result pending_thread->is_thread_fully_suspended() is always evaluated regardless of the value of at_safepoint variable. Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 Thanks! --Daniil From serguei.spitsyn at oracle.com Sat Jun 15 00:01:26 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2019 17:01:26 -0700 Subject: RFR: 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> References: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> Message-ID: <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> Hi Daniil, Great discovery! The fix looks good to me. Thanks, Serguei On 6/14/19 4:56 PM, Daniil Titov wrote: > Please review the change that fixes an intermittent issue. > > The problem here is that a bitwise-AND (&) operator was used in the condition instead of a logical AND operator (&&). > As a result pending_thread->is_thread_fully_suspended() is always evaluated regardless of the value of at_safepoint variable. > > Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 > > Thanks! > --Daniil > > From daniil.x.titov at oracle.com Sat Jun 15 00:06:32 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 14 Jun 2019 17:06:32 -0700 Subject: 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> References: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> Message-ID: <95BA7C8F-06D6-45BA-8856-14B5ADF0A596@oracle.com> Hi Serguei, The discovery was made by David Holmes. Thank you, David, a lot! Best regards, Daniil ?On 6/14/19, 5:01 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, Great discovery! The fix looks good to me. Thanks, Serguei On 6/14/19 4:56 PM, Daniil Titov wrote: > Please review the change that fixes an intermittent issue. > > The problem here is that a bitwise-AND (&) operator was used in the condition instead of a logical AND operator (&&). > As a result pending_thread->is_thread_fully_suspended() is always evaluated regardless of the value of at_safepoint variable. > > Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 > > Thanks! > --Daniil > > From alexey.menkov at oracle.com Sat Jun 15 00:14:09 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Jun 2019 17:14:09 -0700 Subject: RFR: 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> References: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> Message-ID: <018297b4-2790-a1fd-09b6-d60655bd1830@oracle.com> +1 --alex On 06/14/2019 17:01, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > Great discovery! > The fix looks good to me. > > Thanks, > Serguei > > > On 6/14/19 4:56 PM, Daniil Titov wrote: >> Please review the change that fixes an intermittent issue. >> >> The problem here is that a bitwise-AND (&) operator was used in the >> condition instead of a logical AND operator (&&). >> As a result pending_thread->is_thread_fully_suspended() is always >> evaluated regardless of the value of at_safepoint variable. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 >> >> Thanks! >> --Daniil >> >> > From serguei.spitsyn at oracle.com Sat Jun 15 00:40:13 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2019 17:40:13 -0700 Subject: 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: <95BA7C8F-06D6-45BA-8856-14B5ADF0A596@oracle.com> References: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> <95BA7C8F-06D6-45BA-8856-14B5ADF0A596@oracle.com> Message-ID: <97a3843a-16a7-51c9-c98c-d665dbbea177@oracle.com> On 6/14/19 5:06 PM, Daniil Titov wrote: > Hi Serguei, > > The discovery was made by David Holmes. Thank you, David, a lot! Sharp eyes! Thanks, Serguei > Best regards, > Daniil > > > > ?On 6/14/19, 5:01 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > Great discovery! > The fix looks good to me. > > Thanks, > Serguei > > > On 6/14/19 4:56 PM, Daniil Titov wrote: > > Please review the change that fixes an intermittent issue. > > > > The problem here is that a bitwise-AND (&) operator was used in the condition instead of a logical AND operator (&&). > > As a result pending_thread->is_thread_fully_suspended() is always evaluated regardless of the value of at_safepoint variable. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 > > > > Thanks! > > --Daniil > > > > > > > > From jcbeyler at google.com Sat Jun 15 00:44:52 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 14 Jun 2019 17:44:52 -0700 Subject: RFR: 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: <018297b4-2790-a1fd-09b6-d60655bd1830@oracle.com> References: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> <018297b4-2790-a1fd-09b6-d60655bd1830@oracle.com> Message-ID: Hi Daniil, Looks good to me to :-) FWIW, it seems like: opto/library_call.cpp: if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) & !C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_null_check)) { could also be fixed, but perhaps that is a different webrev. Thanks! Jc On Fri, Jun 14, 2019 at 5:14 PM Alex Menkov wrote: > +1 > > --alex > > On 06/14/2019 17:01, serguei.spitsyn at oracle.com wrote: > > Hi Daniil, > > > > Great discovery! > > The fix looks good to me. > > > > Thanks, > > Serguei > > > > > > On 6/14/19 4:56 PM, Daniil Titov wrote: > >> Please review the change that fixes an intermittent issue. > >> > >> The problem here is that a bitwise-AND (&) operator was used in the > >> condition instead of a logical AND operator (&&). > >> As a result pending_thread->is_thread_fully_suspended() is always > >> evaluated regardless of the value of at_safepoint variable. > >> > >> Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 > >> > >> Thanks! > >> --Daniil > >> > >> > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Jun 15 01:29:41 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2019 18:29:41 -0700 Subject: RFR: 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: References: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> <018297b4-2790-a1fd-09b6-d60655bd1830@oracle.com> Message-ID: On 6/14/19 5:44 PM, Jean Christophe Beyler wrote: > Hi Daniil, > > Looks good to me to :-) > > FWIW, it seems like: > opto/library_call.cpp: ? ?if (!C->too_many_traps(trap_method, > trap_bci, Deoptimization::Reason_intrinsic) & > ? ? ? ? ? !C->too_many_traps(trap_method, trap_bci, > Deoptimization::Reason_null_check)) { > > could also be fixed, but perhaps that is a different webrev. Thank you for the catch, Jc! I've filed a separate bug: ? https://bugs.openjdk.java.net/browse/JDK-8226198 ?? use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state Thanks, Serguei > > Thanks! > Jc > > On Fri, Jun 14, 2019 at 5:14 PM Alex Menkov > wrote: > > +1 > > --alex > > On 06/14/2019 17:01, serguei.spitsyn at oracle.com > wrote: > > Hi Daniil, > > > > Great discovery! > > The fix looks good to me. > > > > Thanks, > > Serguei > > > > > > On 6/14/19 4:56 PM, Daniil Titov wrote: > >> Please review the change that fixes an intermittent issue. > >> > >> The problem here is that a bitwise-AND (&) operator was used in > the > >> condition instead of a logical AND operator (&&). > >> As a result pending_thread->is_thread_fully_suspended() is always > >> evaluated regardless of the value of at_safepoint variable. > >> > >> Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 > >> > >> Thanks! > >> --Daniil > >> > >> > > > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Sat Jun 15 04:11:54 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 15 Jun 2019 13:11:54 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> Message-ID: <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> Hi Serguei, Thank you for your comment! On 2019/06/15 8:00, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > I've added myself as a reviewer, so you can finalize it now. I moved CSR to Finalized, and added a comment for your question. > The fix looks pretty good to me. > > One minor suggestion is to use the final field NO_REMOTE instead > of null for initialization of the local variable "remote". I will fix that. > Also just an observation that there is some room for option processing > refactoring. Your suggestion handles all options in one parser method. I concern it might be complex for option validation. (e.g. `jmap -heap` is allowed, but `jstack -heap` is not allowed.) IMHO refactoring should be worked on another issue. If you are OK in above, I will upload new webrev. Thanks, Yasumasa > All the jhsdb sub-commands do execute similar loops like this: > while((s = sg.next(null, longOpts)) != null) { > ??????? . . . > ??? } > > It can be moved into a separate method instead. > The longOpts can passed in arguments. > > It can be something like this: > > ??? private ArrayList processOptions(final String[] oldArgs, > ???????????????????????????????????????????? final String[] longOpts, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean allowEmpty) { > ??????? SAGetopt sg = new SAGetopt(oldArgs); > ??????? ArrayList newArgs = new ArrayList(); > > ??????? String pid = null; > ??????? String exe = null; > ??????? String core = null; > ??????? String s = null; > ??????? String dumpfile = null; > ??????? String remote = NO_REMOTE; > ??????? boolean requestHeapdump = false; > > ??????? while((s = sg.next(null, longOpts)) != null) { > ??????????? if (s.equals("exe")) { > ??????????????? exe = sg.getOptarg(); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("core")) { > ??????????????? core = sg.getOptarg(); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("pid")) { > ???????????????? pid = sg.getOptarg(); > ???????????????? continue; > ??????????? } > ??????????? if (s.equals("remote")) { > ??????????????? remote = sg.getOptarg(); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("mixed")) { > ??????????????? newArgs.add("-m"); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("locks")) { > ??????????????? newArgs.add("-l"); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("heap")) { > ??????????????? newArgs.add("-heap"); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("binaryheap")) { > ??????????????? requestHeapdump = true; > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("dumpfile")) { > ??????????????? dumpfile = sg.getOptarg(); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("histo")) { > ??????????????? newArgs.add("-histo"); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("clstats")) { > ??????????????? newArgs.add("-clstats"); > ???????????????? continue; > ??????????? } > ??????????? if (s.equals("finalizerinfo")) { > ??????????????? newArgs.add("-finalizerinfo"); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("flags")) { > ??????????????? newArgs.add("-flags"); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("sysprops")) { > ??????????????? newArgs.add("-sysprops"); > ??????????????? continue; > ??????????? } > ??????????? if (s.equals("serverid")) { > ??????????????? String serverid = sg.getOptarg(); > ??????????????? if (serverid != null) { > ??????????????????? newArgs.add(serverid); > ??????????????? } > ??????????????? continue; > ??????????? } > ??????? } > > ??????? if (!requestHeapdump && (dumpfile != null)) { > ??????????? throw new IllegalArgumentException("Unexpected argument > dumpfile"); > ??????? } > ??????? if (requestHeapdump) { > ??????????? if (dumpfile == null) { > ??????????????? newArgs.add("-heap:format=b"); > ??????????? } else { > ???????????????? newArgs.add("-heap:format=b,file=" + dumpfile); > ??????????? } > ??????? } > ??????? buildAttachArgs(newArgs, pid, exe, core, remote, allowEmpty); > > ??????? return newArgs; > ??? } > > ??? private static void runCLHSDB(String[] oldArgs) { > ??????? String[] longOpts = {"exe=", "core=", "pid="}; > ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, > true); > > ??????? CLHSDB.main(newArgs.toArray(new String[newArgs.size()])); > ??? } > > ??? private static void runHSDB(String[] oldArgs) { > ??????? String[] longOpts = {"exe=", "core=", "pid="}; > ???????? ArrayList newArgs = processOptions(oldArgs, longOpts, > true); > > ???????? HSDB.main(newArgs.toArray(new String[newArgs.size()])); > ??? } > > ??? private static void runJSTACK(String[] oldArgs) { > ??????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", > "mixed", "locks"}; > ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, > false); > > ??????? JStack jstack = new JStack(false, false); > ??????? jstack.runWithArgs(newArgs.toArray(new String[newArgs.size()])); > ??? } > > ??? private static void runJMAP(String[] oldArgs) { > ??????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", > ????????????? "heap", "binaryheap", "dumpfile=", "histo", "clstats", > "finalizerinfo"}; > > ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, > false); > > ??????? JMap.main(newArgs.toArray(new String[newArgs.size()])); > ??? } > > ??? private static void runJINFO(String[] oldArgs) { > ??????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", > "flags", "sysprops"}; > ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, > false); > > ??????? JInfo.main(newArgs.toArray(new String[newArgs.size()])); > ??? } > > ??? private static void runJSNAP(String[] oldArgs) { > ??????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", "all"}; > ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, > false); > ??????? JSnap.main(newArgs.toArray(new String[newArgs.size()])); > ??? } > > ??? private static void runDEBUGD(String[] oldArgs) { > ??????? // By default SA agent classes prefer Windows process debugger > ??????? // to windbg debugger. SA expects special properties to be set > ??????? // to choose other debuggers. We will set those here before > ??????? // attaching to SA agent. > System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", "true"); > > ??????? String[] longOpts = {"exe=", "core=", "pid=", "serverid="}; > ??????? ArrayList newArgs = processOptions(oldArgs, longOpts, > false); > > ??????? // delegate to the actual SA debug server. > ??????? sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new > String[newArgs.size()])); > ??? } > > > Please, let me know what do you think. > > Thanks, > Serguei > > > On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >> Sorry, new webrev is here: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >> >> Yasumasa >> >> 2019?6?10?(?) 11:27 Yasumasa Suenaga: >>> PING: Could you review them? >>> >>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> 2019?6?5?(?) 14:06 Yasumasa Suenaga: >>>> Hi Jc, >>>> >>>> Thank you for your comment! >>>> I updated a webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>> >>>>> - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... >>>> I created DebugdUtils for convenience class for attach - detach >>>> mechanism of debug server. >>>> IMHO it is prefer "detach" to "close" in this case. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> 2019?6?5?(?) 11:34 Jean Christophe Beyler: >>>>> Hi Yasumasa, >>>>> >>>>> I'm not an official reviewer but I don't see an issue with the CSR (except that this seems to be bringing a fork in the tools with some handling remote and others not). >>>>> >>>>> However, this code is really repetitive and this is not the place to do a big refactor probably but we could do a few nits perhaps: >>>>> - Instead of every tool calling commonHelp with an additional flag you could divide into commonHelp and commonHelpWithRemote for the tools and they both call the current commonHelp with that boolean; so that when we are looking at the tool code we know what we are getting... So something like: >>>>> >>>>> private static boolean commonHelp(String mode, boolean canConnectToRemote) { >>>>> .. >>>>> } >>>>> >>>>> private static boolean commonHelp(String mode) { >>>>> return commonHelp(mode, false); >>>>> } >>>>> >>>>> private static boolean commonHelpWithRemote(String mode) { >>>>> return commonHelp(mode, false); >>>>> } >>>>> >>>>> and that way the tools that change are just going from: >>>>> - return commonHelp("jmap"); >>>>> + return commonHelpWithRemote("jmap"); >>>>> >>>>> - In the same vein, instead of passing null to the buildAttachArgs; you could make a variable null: >>>>> >>>>> - buildAttachArgs(newArgs, pid, exe, core, true); >>>>> + String noRemote = null; >>>>> + buildAttachArgs(newArgs, pid, exe, core, noRemote, true); >>>>> >>>>> >>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>>>> Nit: you have empty lines at l64 and l73 >>>>> >>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>>>> Nit : you have an empty line at l110 >>>>> >>>>> - In runTests; if DebugdUtils implemented Closeable, you could just do a try-with-resources instead of the finally clause... >>>>> >>>>> All of these are details, I just thought I'd mention them :) >>>>> Jc >>>>> >>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa Suenaga wrote: >>>>>> PING: Could you review them? >>>>>> >>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>> CSR status is provisional. So I need reviewers both CSR and webrev. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> 2019?5?29?(?) 22:37 Yasumasa Suenaga: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change: >>>>>>> >>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>> >>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can connect to >>>>>>> debug server (jsadebugd). However it has not done so since JDK 9 because >>>>>>> jhsdb cannot accept the attach request to debug server. >>>>>>> So I want to introduce new option `--remote` to connect to debug server. >>>>>>> >>>>>>> I created CSR for this issue. So please review it together. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc > From serguei.spitsyn at oracle.com Sat Jun 15 06:10:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Jun 2019 23:10:14 -0700 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> Message-ID: Hi Yasumasa, On 6/14/19 21:11, Yasumasa Suenaga wrote: > Hi Serguei, > > Thank you for your comment! > > On 2019/06/15 8:00, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> I've added myself as a reviewer, so you can finalize it now. > > I moved CSR to Finalized, and added a comment for your question. Okay, thanks! >> The fix looks pretty good to me. >> >> One minor suggestion is to use the final field NO_REMOTE instead >> of null for initialization of the local variable "remote". > > I will fix that. > > >> Also just an observation that there is some room for option >> processing refactoring. > > Your suggestion handles all options in one parser method. > I concern it might be complex for option validation. > (e.g. `jmap -heap` is allowed, but `jstack -heap` is not allowed.) This concern is not valid as the list allowed options allowed for each jhsdb sub-command is controlled with the longOpts argument. jmap has: ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", ?????????????? "heap", "binaryheap", "dumpfile=", "histo", "clstats", "finalizerinfo"}; but jstack has: ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", "mixed", "locks"}; > IMHO refactoring should be worked on another issue. Agreed. > If you are OK in above, I will upload new webrev. Yes, I'm Okay with it. Thanks, Serguei > Thanks, > > Yasumasa > > >> All the jhsdb sub-commands do execute similar loops like this: >> while((s = sg.next(null, longOpts)) != null) { >> ???????? . . . >> ???? } >> >> It can be moved into a separate method instead. >> The longOpts can passed in arguments. >> >> It can be something like this: >> >> ???? private ArrayList processOptions(final String[] oldArgs, >> ????????????????????????????????????????????? final String[] longOpts, >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean allowEmpty) { >> ???????? SAGetopt sg = new SAGetopt(oldArgs); >> ???????? ArrayList newArgs = new ArrayList(); >> >> ???????? String pid = null; >> ???????? String exe = null; >> ???????? String core = null; >> ???????? String s = null; >> ???????? String dumpfile = null; >> ???????? String remote = NO_REMOTE; >> ???????? boolean requestHeapdump = false; >> >> ???????? while((s = sg.next(null, longOpts)) != null) { >> ???????????? if (s.equals("exe")) { >> ???????????????? exe = sg.getOptarg(); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("core")) { >> ???????????????? core = sg.getOptarg(); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("pid")) { >> ????????????????? pid = sg.getOptarg(); >> ????????????????? continue; >> ???????????? } >> ???????????? if (s.equals("remote")) { >> ???????????????? remote = sg.getOptarg(); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("mixed")) { >> ???????????????? newArgs.add("-m"); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("locks")) { >> ???????????????? newArgs.add("-l"); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("heap")) { >> ???????????????? newArgs.add("-heap"); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("binaryheap")) { >> ???????????????? requestHeapdump = true; >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("dumpfile")) { >> ???????????????? dumpfile = sg.getOptarg(); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("histo")) { >> ???????????????? newArgs.add("-histo"); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("clstats")) { >> ???????????????? newArgs.add("-clstats"); >> ????????????????? continue; >> ???????????? } >> ???????????? if (s.equals("finalizerinfo")) { >> ???????????????? newArgs.add("-finalizerinfo"); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("flags")) { >> ???????????????? newArgs.add("-flags"); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("sysprops")) { >> ???????????????? newArgs.add("-sysprops"); >> ???????????????? continue; >> ???????????? } >> ???????????? if (s.equals("serverid")) { >> ???????????????? String serverid = sg.getOptarg(); >> ???????????????? if (serverid != null) { >> ???????????????????? newArgs.add(serverid); >> ???????????????? } >> ???????????????? continue; >> ???????????? } >> ???????? } >> >> ???????? if (!requestHeapdump && (dumpfile != null)) { >> ???????????? throw new IllegalArgumentException("Unexpected argument >> dumpfile"); >> ???????? } >> ???????? if (requestHeapdump) { >> ???????????? if (dumpfile == null) { >> ???????????????? newArgs.add("-heap:format=b"); >> ???????????? } else { >> ????????????????? newArgs.add("-heap:format=b,file=" + dumpfile); >> ???????????? } >> ???????? } >> ???????? buildAttachArgs(newArgs, pid, exe, core, remote, allowEmpty); >> >> ???????? return newArgs; >> ???? } >> >> ???? private static void runCLHSDB(String[] oldArgs) { >> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >> ???????? ArrayList newArgs = processOptions(oldArgs, >> longOpts, true); >> >> ???????? CLHSDB.main(newArgs.toArray(new String[newArgs.size()])); >> ???? } >> >> ???? private static void runHSDB(String[] oldArgs) { >> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >> ????????? ArrayList newArgs = processOptions(oldArgs, >> longOpts, true); >> >> ????????? HSDB.main(newArgs.toArray(new String[newArgs.size()])); >> ???? } >> >> ???? private static void runJSTACK(String[] oldArgs) { >> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> "mixed", "locks"}; >> ???????? ArrayList newArgs = processOptions(oldArgs, >> longOpts, false); >> >> ???????? JStack jstack = new JStack(false, false); >> ???????? jstack.runWithArgs(newArgs.toArray(new >> String[newArgs.size()])); >> ???? } >> >> ???? private static void runJMAP(String[] oldArgs) { >> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> ?????????????? "heap", "binaryheap", "dumpfile=", "histo", "clstats", >> "finalizerinfo"}; >> >> ???????? ArrayList newArgs = processOptions(oldArgs, >> longOpts, false); >> >> ???????? JMap.main(newArgs.toArray(new String[newArgs.size()])); >> ???? } >> >> ???? private static void runJINFO(String[] oldArgs) { >> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> "flags", "sysprops"}; >> ???????? ArrayList newArgs = processOptions(oldArgs, >> longOpts, false); >> >> ???????? JInfo.main(newArgs.toArray(new String[newArgs.size()])); >> ???? } >> >> ???? private static void runJSNAP(String[] oldArgs) { >> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> "all"}; >> ???????? ArrayList newArgs = processOptions(oldArgs, >> longOpts, false); >> ???????? JSnap.main(newArgs.toArray(new String[newArgs.size()])); >> ???? } >> >> ???? private static void runDEBUGD(String[] oldArgs) { >> ???????? // By default SA agent classes prefer Windows process debugger >> ???????? // to windbg debugger. SA expects special properties to be set >> ???????? // to choose other debuggers. We will set those here before >> ???????? // attaching to SA agent. >> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", >> "true"); >> >> ???????? String[] longOpts = {"exe=", "core=", "pid=", "serverid="}; >> ???????? ArrayList newArgs = processOptions(oldArgs, >> longOpts, false); >> >> ???????? // delegate to the actual SA debug server. >> ???????? sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new >> String[newArgs.size()])); >> ???? } >> >> >> Please, let me know what do you think. >> >> Thanks, >> Serguei >> >> >> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >>> Sorry, new webrev is here: >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>> >>> Yasumasa >>> >>> 2019?6?10?(?) 11:27 Yasumasa Suenaga: >>>> PING: Could you review them? >>>> >>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga: >>>>> Hi Jc, >>>>> >>>>> Thank you for your comment! >>>>> I updated a webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>>> >>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >>>>>> could just do a try-with-resources instead of the finally clause... >>>>> I created DebugdUtils for convenience class for attach - detach >>>>> mechanism of debug server. >>>>> IMHO it is prefer "detach" to "close" in this case. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2019?6?5?(?) 11:34 Jean Christophe Beyler: >>>>>> Hi Yasumasa, >>>>>> >>>>>> I'm not an official reviewer but I don't see an issue with the >>>>>> CSR (except that this seems to be bringing a fork in the tools >>>>>> with some handling remote and others not). >>>>>> >>>>>> However, this code is really repetitive and this is not the place >>>>>> to do a big refactor probably but we could do a few nits perhaps: >>>>>> ??? - Instead of every tool calling commonHelp with an additional >>>>>> flag you could divide into commonHelp and commonHelpWithRemote >>>>>> for the tools and they both call the current commonHelp with that >>>>>> boolean; so that when we are looking at the tool code we know >>>>>> what we are getting... So something like: >>>>>> >>>>>> private static boolean commonHelp(String mode, boolean >>>>>> canConnectToRemote) { >>>>>> ???? .. >>>>>> ? } >>>>>> >>>>>> private static boolean commonHelp(String mode) { >>>>>> ??? return commonHelp(mode, false); >>>>>> } >>>>>> >>>>>> private static boolean commonHelpWithRemote(String mode) { >>>>>> ??? return commonHelp(mode, false); >>>>>> } >>>>>> >>>>>> and that way the tools that change are just going from: >>>>>> -??????? return commonHelp("jmap"); >>>>>> +??????? return commonHelpWithRemote("jmap"); >>>>>> >>>>>> - In the same vein, instead of passing null to the >>>>>> buildAttachArgs; you could? make a variable null: >>>>>> >>>>>> -??????? buildAttachArgs(newArgs, pid, exe, core, true); >>>>>> +??????? String noRemote = null; >>>>>> +??????? buildAttachArgs(newArgs, pid, exe, core, noRemote, true); >>>>>> >>>>>> >>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>>>>> >>>>>> ??? Nit: you have empty lines at l64 and l73 >>>>>> >>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>>>>> >>>>>> ???? Nit : you have an empty line at l110 >>>>>> >>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >>>>>> could just do a try-with-resources instead of the finally clause... >>>>>> >>>>>> All of these are details, I just thought I'd mention them :) >>>>>> Jc >>>>>> >>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa >>>>>> Suenaga? wrote: >>>>>>> PING: Could you review them? >>>>>>> >>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>> CSR status is provisional. So I need reviewers both CSR and webrev. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> 2019?5?29?(?) 22:37 Yasumasa Suenaga: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this change: >>>>>>>> >>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>> >>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can >>>>>>>> connect to >>>>>>>> debug server (jsadebugd). However it has not done so since JDK >>>>>>>> 9 because >>>>>>>> jhsdb cannot accept the attach request to debug server. >>>>>>>> So I want to introduce new option `--remote` to connect to >>>>>>>> debug server. >>>>>>>> >>>>>>>> I created CSR for this issue. So please review it together. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc >> From rkennke at redhat.com Sat Jun 15 11:52:25 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 15 Jun 2019 13:52:25 +0200 Subject: RFR(T) 8225804: SA: Remove unused CollectedHeap.oopOffset() method In-Reply-To: <2b2c4832-718a-aa84-3361-fe67b918a58b@redhat.com> References: <2b2c4832-718a-aa84-3361-fe67b918a58b@redhat.com> Message-ID: Looks good. Thanks, Roman Roman > Please review this patch that removes a method that is no longer needed. > > CollectedHeap.oopOffset() was added for Shenandoah GC to offset extra > header for forwarding pointer. Recently, Shenandoah removed the header > and folded the forwarding pointer into regular header, so this method is > now obsoleted. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225804 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225804/webrev.00/ > > Test: > ? hotspot_serviceability (fastdebug and release) > ? Submit test in progress. > > Thanks, > > -Zhengyu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From david.holmes at oracle.com Sun Jun 16 13:15:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 16 Jun 2019 23:15:06 +1000 Subject: 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: <95BA7C8F-06D6-45BA-8856-14B5ADF0A596@oracle.com> References: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> <95BA7C8F-06D6-45BA-8856-14B5ADF0A596@oracle.com> Message-ID: <3869968e-d72a-558b-cfbc-53c9c26fbda9@oracle.com> On 15/06/2019 10:06 am, Daniil Titov wrote: > Hi Serguei, > > The discovery was made by David Holmes. Thank you, David, a lot! :) Wish I'd spotted it the first time round. Fix looks good. Thanks, David > Best regards, > Daniil > > > > ?On 6/14/19, 5:01 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > Great discovery! > The fix looks good to me. > > Thanks, > Serguei > > > On 6/14/19 4:56 PM, Daniil Titov wrote: > > Please review the change that fixes an intermittent issue. > > > > The problem here is that a bitwise-AND (&) operator was used in the condition instead of a logical AND operator (&&). > > As a result pending_thread->is_thread_fully_suspended() is always evaluated regardless of the value of at_safepoint variable. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 > > > > Thanks! > > --Daniil > > > > > > > > From yasuenag at gmail.com Sun Jun 16 14:22:51 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 16 Jun 2019 23:22:51 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> Message-ID: Hi Serguei, >>> One minor suggestion is to use the final field NO_REMOTE instead >>> of null for initialization of the local variable "remote". I fixed it on new webrev. Could you check again? http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ >> IMHO refactoring should be worked on another issue. > > Agreed. I filed it to JBS: https://bugs.openjdk.java.net/browse/JDK-8226204 Thanks, Yasumasa On 2019/06/15 15:10, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > > On 6/14/19 21:11, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> Thank you for your comment! >> >> On 2019/06/15 8:00, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> I've added myself as a reviewer, so you can finalize it now. >> >> I moved CSR to Finalized, and added a comment for your question. > > Okay, thanks! > > >>> The fix looks pretty good to me. >>> >>> One minor suggestion is to use the final field NO_REMOTE instead >>> of null for initialization of the local variable "remote". >> >> I will fix that. >> >> >>> Also just an observation that there is some room for option >>> processing refactoring. >> >> Your suggestion handles all options in one parser method. >> I concern it might be complex for option validation. >> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not allowed.) > > This concern is not valid as the list allowed options allowed for each > jhsdb sub-command is controlled with the longOpts argument. > > jmap has: > ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", > ?????????????? "heap", "binaryheap", "dumpfile=", "histo", "clstats", > "finalizerinfo"}; > > but jstack has: > ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", > "mixed", "locks"}; > >> IMHO refactoring should be worked on another issue. > > Agreed. > > >> If you are OK in above, I will upload new webrev. > > Yes, I'm Okay with it. > > > Thanks, > Serguei > > >> Thanks, >> >> Yasumasa >> >> >>> All the jhsdb sub-commands do execute similar loops like this: >>> while((s = sg.next(null, longOpts)) != null) { >>> ???????? . . . >>> ???? } >>> >>> It can be moved into a separate method instead. >>> The longOpts can passed in arguments. >>> >>> It can be something like this: >>> >>> ???? private ArrayList processOptions(final String[] oldArgs, >>> ????????????????????????????????????????????? final String[] longOpts, >>> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean allowEmpty) { >>> ???????? SAGetopt sg = new SAGetopt(oldArgs); >>> ???????? ArrayList newArgs = new ArrayList(); >>> >>> ???????? String pid = null; >>> ???????? String exe = null; >>> ???????? String core = null; >>> ???????? String s = null; >>> ???????? String dumpfile = null; >>> ???????? String remote = NO_REMOTE; >>> ???????? boolean requestHeapdump = false; >>> >>> ???????? while((s = sg.next(null, longOpts)) != null) { >>> ???????????? if (s.equals("exe")) { >>> ???????????????? exe = sg.getOptarg(); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("core")) { >>> ???????????????? core = sg.getOptarg(); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("pid")) { >>> ????????????????? pid = sg.getOptarg(); >>> ????????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("remote")) { >>> ???????????????? remote = sg.getOptarg(); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("mixed")) { >>> ???????????????? newArgs.add("-m"); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("locks")) { >>> ???????????????? newArgs.add("-l"); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("heap")) { >>> ???????????????? newArgs.add("-heap"); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("binaryheap")) { >>> ???????????????? requestHeapdump = true; >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("dumpfile")) { >>> ???????????????? dumpfile = sg.getOptarg(); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("histo")) { >>> ???????????????? newArgs.add("-histo"); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("clstats")) { >>> ???????????????? newArgs.add("-clstats"); >>> ????????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("finalizerinfo")) { >>> ???????????????? newArgs.add("-finalizerinfo"); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("flags")) { >>> ???????????????? newArgs.add("-flags"); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("sysprops")) { >>> ???????????????? newArgs.add("-sysprops"); >>> ???????????????? continue; >>> ???????????? } >>> ???????????? if (s.equals("serverid")) { >>> ???????????????? String serverid = sg.getOptarg(); >>> ???????????????? if (serverid != null) { >>> ???????????????????? newArgs.add(serverid); >>> ???????????????? } >>> ???????????????? continue; >>> ???????????? } >>> ???????? } >>> >>> ???????? if (!requestHeapdump && (dumpfile != null)) { >>> ???????????? throw new IllegalArgumentException("Unexpected argument >>> dumpfile"); >>> ???????? } >>> ???????? if (requestHeapdump) { >>> ???????????? if (dumpfile == null) { >>> ???????????????? newArgs.add("-heap:format=b"); >>> ???????????? } else { >>> ????????????????? newArgs.add("-heap:format=b,file=" + dumpfile); >>> ???????????? } >>> ???????? } >>> ???????? buildAttachArgs(newArgs, pid, exe, core, remote, allowEmpty); >>> >>> ???????? return newArgs; >>> ???? } >>> >>> ???? private static void runCLHSDB(String[] oldArgs) { >>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> longOpts, true); >>> >>> ???????? CLHSDB.main(newArgs.toArray(new String[newArgs.size()])); >>> ???? } >>> >>> ???? private static void runHSDB(String[] oldArgs) { >>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>> ????????? ArrayList newArgs = processOptions(oldArgs, >>> longOpts, true); >>> >>> ????????? HSDB.main(newArgs.toArray(new String[newArgs.size()])); >>> ???? } >>> >>> ???? private static void runJSTACK(String[] oldArgs) { >>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>> "mixed", "locks"}; >>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> longOpts, false); >>> >>> ???????? JStack jstack = new JStack(false, false); >>> ???????? jstack.runWithArgs(newArgs.toArray(new >>> String[newArgs.size()])); >>> ???? } >>> >>> ???? private static void runJMAP(String[] oldArgs) { >>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>> ?????????????? "heap", "binaryheap", "dumpfile=", "histo", "clstats", >>> "finalizerinfo"}; >>> >>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> longOpts, false); >>> >>> ???????? JMap.main(newArgs.toArray(new String[newArgs.size()])); >>> ???? } >>> >>> ???? private static void runJINFO(String[] oldArgs) { >>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>> "flags", "sysprops"}; >>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> longOpts, false); >>> >>> ???????? JInfo.main(newArgs.toArray(new String[newArgs.size()])); >>> ???? } >>> >>> ???? private static void runJSNAP(String[] oldArgs) { >>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>> "all"}; >>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> longOpts, false); >>> ???????? JSnap.main(newArgs.toArray(new String[newArgs.size()])); >>> ???? } >>> >>> ???? private static void runDEBUGD(String[] oldArgs) { >>> ???????? // By default SA agent classes prefer Windows process debugger >>> ???????? // to windbg debugger. SA expects special properties to be set >>> ???????? // to choose other debuggers. We will set those here before >>> ???????? // attaching to SA agent. >>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", >>> "true"); >>> >>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "serverid="}; >>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> longOpts, false); >>> >>> ???????? // delegate to the actual SA debug server. >>> ???????? sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new >>> String[newArgs.size()])); >>> ???? } >>> >>> >>> Please, let me know what do you think. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >>>> Sorry, new webrev is here: >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>> >>>> Yasumasa >>>> >>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga: >>>>> PING: Could you review them? >>>>> >>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga: >>>>>> Hi Jc, >>>>>> >>>>>> Thank you for your comment! >>>>>> I updated a webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>>>> >>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >>>>>>> could just do a try-with-resources instead of the finally clause... >>>>>> I created DebugdUtils for convenience class for attach - detach >>>>>> mechanism of debug server. >>>>>> IMHO it is prefer "detach" to "close" in this case. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> 2019?6?5?(?) 11:34 Jean Christophe Beyler: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> I'm not an official reviewer but I don't see an issue with the >>>>>>> CSR (except that this seems to be bringing a fork in the tools >>>>>>> with some handling remote and others not). >>>>>>> >>>>>>> However, this code is really repetitive and this is not the place >>>>>>> to do a big refactor probably but we could do a few nits perhaps: >>>>>>> ??? - Instead of every tool calling commonHelp with an additional >>>>>>> flag you could divide into commonHelp and commonHelpWithRemote >>>>>>> for the tools and they both call the current commonHelp with that >>>>>>> boolean; so that when we are looking at the tool code we know >>>>>>> what we are getting... So something like: >>>>>>> >>>>>>> private static boolean commonHelp(String mode, boolean >>>>>>> canConnectToRemote) { >>>>>>> ???? .. >>>>>>> ? } >>>>>>> >>>>>>> private static boolean commonHelp(String mode) { >>>>>>> ??? return commonHelp(mode, false); >>>>>>> } >>>>>>> >>>>>>> private static boolean commonHelpWithRemote(String mode) { >>>>>>> ??? return commonHelp(mode, false); >>>>>>> } >>>>>>> >>>>>>> and that way the tools that change are just going from: >>>>>>> -??????? return commonHelp("jmap"); >>>>>>> +??????? return commonHelpWithRemote("jmap"); >>>>>>> >>>>>>> - In the same vein, instead of passing null to the >>>>>>> buildAttachArgs; you could? make a variable null: >>>>>>> >>>>>>> -??????? buildAttachArgs(newArgs, pid, exe, core, true); >>>>>>> +??????? String noRemote = null; >>>>>>> +??????? buildAttachArgs(newArgs, pid, exe, core, noRemote, true); >>>>>>> >>>>>>> >>>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>>>>>> >>>>>>> ??? Nit: you have empty lines at l64 and l73 >>>>>>> >>>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>>>>>> >>>>>>> ???? Nit : you have an empty line at l110 >>>>>>> >>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >>>>>>> could just do a try-with-resources instead of the finally clause... >>>>>>> >>>>>>> All of these are details, I just thought I'd mention them :) >>>>>>> Jc >>>>>>> >>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa >>>>>>> Suenaga? wrote: >>>>>>>> PING: Could you review them? >>>>>>>> >>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>> CSR status is provisional. So I need reviewers both CSR and webrev. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> 2019?5?29?(?) 22:37 Yasumasa Suenaga: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this change: >>>>>>>>> >>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>>> >>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can >>>>>>>>> connect to >>>>>>>>> debug server (jsadebugd). However it has not done so since JDK >>>>>>>>> 9 because >>>>>>>>> jhsdb cannot accept the attach request to debug server. >>>>>>>>> So I want to introduce new option `--remote` to connect to >>>>>>>>> debug server. >>>>>>>>> >>>>>>>>> I created CSR for this issue. So please review it together. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thanks, >>>>>>> Jc >>> > From yasuenag at gmail.com Sun Jun 16 14:30:26 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 16 Jun 2019 23:30:26 +0900 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: References: Message-ID: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> Hi Serguei, Chris, Thank you for your comment. I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.01/ I separated a function for handling prelinked library. Also I added some comments for its process. Thanks, Yasumasa On 2019/06/15 3:48, Chris Plummer wrote: > Hi Yasumasa, > > I think you should replace the embedded link with more of a textual > description of where to look in the gdb source. > > I'd like to see some short comments. You have a few logical blocks of > code that would greatly benefit from just one line saying what they are > doing, especially the loop. > > thanks, > > Chris > > On 6/13/19 10:49 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 >> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ >> >> I attempted to open the core which is generated by RHEL 6, but it >> could not . >> >> The OS which generated the core is set to enable prelink. >> According to GDB implementation, load address of prelinked library >> should be calculated by offset of link_map.l_ld and the address of >> .dynamic section. >> >> >> Thanks, >> >> Yasumasa > > From serguei.spitsyn at oracle.com Sun Jun 16 21:44:38 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 16 Jun 2019 14:44:38 -0700 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> Message-ID: Hi Yasumasa, On 6/16/19 07:22, Yasumasa Suenaga wrote: > Hi Serguei, > > >>> One minor suggestion is to use the final field NO_REMOTE instead > >>> of null for initialization of the local variable "remote". > > I fixed it on new webrev. Could you check again? > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ It looks good. Thanks you for the update! > > >> IMHO refactoring should be worked on another issue. > > > > Agreed. > > I filed it to JBS: > ? https://bugs.openjdk.java.net/browse/JDK-8226204 Thank you for filing the enhancement! Thanks. Serguei > Thanks, > > Yasumasa > > > On 2019/06/15 15:10, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> >> On 6/14/19 21:11, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>> Thank you for your comment! >>> >>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> I've added myself as a reviewer, so you can finalize it now. >>> >>> I moved CSR to Finalized, and added a comment for your question. >> >> Okay, thanks! >> >> >>>> The fix looks pretty good to me. >>>> >>>> One minor suggestion is to use the final field NO_REMOTE instead >>>> of null for initialization of the local variable "remote". >>> >>> I will fix that. >>> >>> >>>> Also just an observation that there is some room for option >>>> processing refactoring. >>> >>> Your suggestion handles all options in one parser method. >>> I concern it might be complex for option validation. >>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not allowed.) >> >> This concern is not valid as the list allowed options allowed for each >> jhsdb sub-command is controlled with the longOpts argument. >> >> jmap has: >> ????????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> ??????????????? "heap", "binaryheap", "dumpfile=", "histo", >> "clstats", "finalizerinfo"}; >> >> but jstack has: >> ????????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> "mixed", "locks"}; >> >>> IMHO refactoring should be worked on another issue. >> >> Agreed. >> >> >>> If you are OK in above, I will upload new webrev. >> >> Yes, I'm Okay with it. >> >> >> Thanks, >> Serguei >> >> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> All the jhsdb sub-commands do execute similar loops like this: >>>> while((s = sg.next(null, longOpts)) != null) { >>>> ???????? . . . >>>> ???? } >>>> >>>> It can be moved into a separate method instead. >>>> The longOpts can passed in arguments. >>>> >>>> It can be something like this: >>>> >>>> ???? private ArrayList processOptions(final String[] oldArgs, >>>> ????????????????????????????????????????????? final String[] longOpts, >>>> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean allowEmpty) { >>>> ???????? SAGetopt sg = new SAGetopt(oldArgs); >>>> ???????? ArrayList newArgs = new ArrayList(); >>>> >>>> ???????? String pid = null; >>>> ???????? String exe = null; >>>> ???????? String core = null; >>>> ???????? String s = null; >>>> ???????? String dumpfile = null; >>>> ???????? String remote = NO_REMOTE; >>>> ???????? boolean requestHeapdump = false; >>>> >>>> ???????? while((s = sg.next(null, longOpts)) != null) { >>>> ???????????? if (s.equals("exe")) { >>>> ???????????????? exe = sg.getOptarg(); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("core")) { >>>> ???????????????? core = sg.getOptarg(); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("pid")) { >>>> ????????????????? pid = sg.getOptarg(); >>>> ????????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("remote")) { >>>> ???????????????? remote = sg.getOptarg(); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("mixed")) { >>>> ???????????????? newArgs.add("-m"); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("locks")) { >>>> ???????????????? newArgs.add("-l"); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("heap")) { >>>> ???????????????? newArgs.add("-heap"); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("binaryheap")) { >>>> ???????????????? requestHeapdump = true; >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("dumpfile")) { >>>> ???????????????? dumpfile = sg.getOptarg(); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("histo")) { >>>> ???????????????? newArgs.add("-histo"); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("clstats")) { >>>> ???????????????? newArgs.add("-clstats"); >>>> ????????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("finalizerinfo")) { >>>> ???????????????? newArgs.add("-finalizerinfo"); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("flags")) { >>>> ???????????????? newArgs.add("-flags"); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("sysprops")) { >>>> ???????????????? newArgs.add("-sysprops"); >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????????? if (s.equals("serverid")) { >>>> ???????????????? String serverid = sg.getOptarg(); >>>> ???????????????? if (serverid != null) { >>>> ???????????????????? newArgs.add(serverid); >>>> ???????????????? } >>>> ???????????????? continue; >>>> ???????????? } >>>> ???????? } >>>> >>>> ???????? if (!requestHeapdump && (dumpfile != null)) { >>>> ???????????? throw new IllegalArgumentException("Unexpected >>>> argument dumpfile"); >>>> ???????? } >>>> ???????? if (requestHeapdump) { >>>> ???????????? if (dumpfile == null) { >>>> ???????????????? newArgs.add("-heap:format=b"); >>>> ???????????? } else { >>>> ????????????????? newArgs.add("-heap:format=b,file=" + dumpfile); >>>> ???????????? } >>>> ???????? } >>>> ???????? buildAttachArgs(newArgs, pid, exe, core, remote, allowEmpty); >>>> >>>> ???????? return newArgs; >>>> ???? } >>>> >>>> ???? private static void runCLHSDB(String[] oldArgs) { >>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> longOpts, true); >>>> >>>> ???????? CLHSDB.main(newArgs.toArray(new String[newArgs.size()])); >>>> ???? } >>>> >>>> ???? private static void runHSDB(String[] oldArgs) { >>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>>> ????????? ArrayList newArgs = processOptions(oldArgs, >>>> longOpts, true); >>>> >>>> ????????? HSDB.main(newArgs.toArray(new String[newArgs.size()])); >>>> ???? } >>>> >>>> ???? private static void runJSTACK(String[] oldArgs) { >>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>>> "mixed", "locks"}; >>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> longOpts, false); >>>> >>>> ???????? JStack jstack = new JStack(false, false); >>>> ???????? jstack.runWithArgs(newArgs.toArray(new >>>> String[newArgs.size()])); >>>> ???? } >>>> >>>> ???? private static void runJMAP(String[] oldArgs) { >>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>>> ?????????????? "heap", "binaryheap", "dumpfile=", "histo", >>>> "clstats", "finalizerinfo"}; >>>> >>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> longOpts, false); >>>> >>>> ???????? JMap.main(newArgs.toArray(new String[newArgs.size()])); >>>> ???? } >>>> >>>> ???? private static void runJINFO(String[] oldArgs) { >>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>>> "flags", "sysprops"}; >>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> longOpts, false); >>>> >>>> ???????? JInfo.main(newArgs.toArray(new String[newArgs.size()])); >>>> ???? } >>>> >>>> ???? private static void runJSNAP(String[] oldArgs) { >>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>>> "all"}; >>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> longOpts, false); >>>> ???????? JSnap.main(newArgs.toArray(new String[newArgs.size()])); >>>> ???? } >>>> >>>> ???? private static void runDEBUGD(String[] oldArgs) { >>>> ???????? // By default SA agent classes prefer Windows process >>>> debugger >>>> ???????? // to windbg debugger. SA expects special properties to be >>>> set >>>> ???????? // to choose other debuggers. We will set those here before >>>> ???????? // attaching to SA agent. >>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", >>>> "true"); >>>> >>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "serverid="}; >>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> longOpts, false); >>>> >>>> ???????? // delegate to the actual SA debug server. >>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new >>>> String[newArgs.size()])); >>>> ???? } >>>> >>>> >>>> Please, let me know what do you think. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >>>>> Sorry, new webrev is here: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>>> >>>>> Yasumasa >>>>> >>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga: >>>>>> PING: Could you review them? >>>>>> >>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>>>> >>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga: >>>>>>> Hi Jc, >>>>>>> >>>>>>> Thank you for your comment! >>>>>>> I updated a webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>>>>> >>>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >>>>>>>> could just do a try-with-resources instead of the finally >>>>>>>> clause... >>>>>>> I created DebugdUtils for convenience class for attach - detach >>>>>>> mechanism of debug server. >>>>>>> IMHO it is prefer "detach" to "close" in this case. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> 2019?6?5?(?) 11:34 Jean Christophe Beyler: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> I'm not an official reviewer but I don't see an issue with the >>>>>>>> CSR (except that this seems to be bringing a fork in the tools >>>>>>>> with some handling remote and others not). >>>>>>>> >>>>>>>> However, this code is really repetitive and this is not the >>>>>>>> place to do a big refactor probably but we could do a few nits >>>>>>>> perhaps: >>>>>>>> ??? - Instead of every tool calling commonHelp with an >>>>>>>> additional flag you could divide into commonHelp and >>>>>>>> commonHelpWithRemote for the tools and they both call the >>>>>>>> current commonHelp with that boolean; so that when we are >>>>>>>> looking at the tool code we know what we are getting... So >>>>>>>> something like: >>>>>>>> >>>>>>>> private static boolean commonHelp(String mode, boolean >>>>>>>> canConnectToRemote) { >>>>>>>> ???? .. >>>>>>>> ? } >>>>>>>> >>>>>>>> private static boolean commonHelp(String mode) { >>>>>>>> ??? return commonHelp(mode, false); >>>>>>>> } >>>>>>>> >>>>>>>> private static boolean commonHelpWithRemote(String mode) { >>>>>>>> ??? return commonHelp(mode, false); >>>>>>>> } >>>>>>>> >>>>>>>> and that way the tools that change are just going from: >>>>>>>> -??????? return commonHelp("jmap"); >>>>>>>> +??????? return commonHelpWithRemote("jmap"); >>>>>>>> >>>>>>>> - In the same vein, instead of passing null to the >>>>>>>> buildAttachArgs; you could? make a variable null: >>>>>>>> >>>>>>>> -??????? buildAttachArgs(newArgs, pid, exe, core, true); >>>>>>>> +??????? String noRemote = null; >>>>>>>> +??????? buildAttachArgs(newArgs, pid, exe, core, noRemote, true); >>>>>>>> >>>>>>>> >>>>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>>>>>>> >>>>>>>> ??? Nit: you have empty lines at l64 and l73 >>>>>>>> >>>>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>>>>>>> >>>>>>>> ???? Nit : you have an empty line at l110 >>>>>>>> >>>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >>>>>>>> could just do a try-with-resources instead of the finally >>>>>>>> clause... >>>>>>>> >>>>>>>> All of these are details, I just thought I'd mention them :) >>>>>>>> Jc >>>>>>>> >>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa >>>>>>>> Suenaga? wrote: >>>>>>>>> PING: Could you review them? >>>>>>>>> >>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>>>> >>>>>>>>> CSR status is provisional. So I need reviewers both CSR and >>>>>>>>> webrev. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa Suenaga: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review this change: >>>>>>>>>> >>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can >>>>>>>>>> connect to >>>>>>>>>> debug server (jsadebugd). However it has not done so since >>>>>>>>>> JDK 9 because >>>>>>>>>> jhsdb cannot accept the attach request to debug server. >>>>>>>>>> So I want to introduce new option `--remote` to connect to >>>>>>>>>> debug server. >>>>>>>>>> >>>>>>>>>> I created CSR for this issue. So please review it together. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jc >>>> >> From serguei.spitsyn at oracle.com Sun Jun 16 21:47:33 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 16 Jun 2019 14:47:33 -0700 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> Message-ID: <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> Forgot to tell... This can be pushed only after the CSR is approved. Thanks, Serguei On 6/16/19 14:44, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > > On 6/16/19 07:22, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> >>> One minor suggestion is to use the final field NO_REMOTE instead >> >>> of null for initialization of the local variable "remote". >> >> I fixed it on new webrev. Could you check again? >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ > > > It looks good. > Thanks you for the update! > >> >> >> IMHO refactoring should be worked on another issue. >> > >> > Agreed. >> >> I filed it to JBS: >> ? https://bugs.openjdk.java.net/browse/JDK-8226204 > > Thank you for filing the enhancement! > > Thanks. > Serguei > > >> Thanks, >> >> Yasumasa >> >> >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> Thank you for your comment! >>>> >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> I've added myself as a reviewer, so you can finalize it now. >>>> >>>> I moved CSR to Finalized, and added a comment for your question. >>> >>> Okay, thanks! >>> >>> >>>>> The fix looks pretty good to me. >>>>> >>>>> One minor suggestion is to use the final field NO_REMOTE instead >>>>> of null for initialization of the local variable "remote". >>>> >>>> I will fix that. >>>> >>>> >>>>> Also just an observation that there is some room for option >>>>> processing refactoring. >>>> >>>> Your suggestion handles all options in one parser method. >>>> I concern it might be complex for option validation. >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not allowed.) >>> >>> This concern is not valid as the list allowed options allowed for each >>> jhsdb sub-command is controlled with the longOpts argument. >>> >>> jmap has: >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>> ??????????????? "heap", "binaryheap", "dumpfile=", "histo", >>> "clstats", "finalizerinfo"}; >>> >>> but jstack has: >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>> "mixed", "locks"}; >>> >>>> IMHO refactoring should be worked on another issue. >>> >>> Agreed. >>> >>> >>>> If you are OK in above, I will upload new webrev. >>> >>> Yes, I'm Okay with it. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> All the jhsdb sub-commands do execute similar loops like this: >>>>> while((s = sg.next(null, longOpts)) != null) { >>>>> ???????? . . . >>>>> ???? } >>>>> >>>>> It can be moved into a separate method instead. >>>>> The longOpts can passed in arguments. >>>>> >>>>> It can be something like this: >>>>> >>>>> ???? private ArrayList processOptions(final String[] oldArgs, >>>>> ????????????????????????????????????????????? final String[] >>>>> longOpts, >>>>> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean allowEmpty) { >>>>> ???????? SAGetopt sg = new SAGetopt(oldArgs); >>>>> ???????? ArrayList newArgs = new ArrayList(); >>>>> >>>>> ???????? String pid = null; >>>>> ???????? String exe = null; >>>>> ???????? String core = null; >>>>> ???????? String s = null; >>>>> ???????? String dumpfile = null; >>>>> ???????? String remote = NO_REMOTE; >>>>> ???????? boolean requestHeapdump = false; >>>>> >>>>> ???????? while((s = sg.next(null, longOpts)) != null) { >>>>> ???????????? if (s.equals("exe")) { >>>>> ???????????????? exe = sg.getOptarg(); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("core")) { >>>>> ???????????????? core = sg.getOptarg(); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("pid")) { >>>>> ????????????????? pid = sg.getOptarg(); >>>>> ????????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("remote")) { >>>>> ???????????????? remote = sg.getOptarg(); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("mixed")) { >>>>> ???????????????? newArgs.add("-m"); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("locks")) { >>>>> ???????????????? newArgs.add("-l"); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("heap")) { >>>>> ???????????????? newArgs.add("-heap"); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("binaryheap")) { >>>>> ???????????????? requestHeapdump = true; >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("dumpfile")) { >>>>> ???????????????? dumpfile = sg.getOptarg(); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("histo")) { >>>>> ???????????????? newArgs.add("-histo"); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("clstats")) { >>>>> ???????????????? newArgs.add("-clstats"); >>>>> ????????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("finalizerinfo")) { >>>>> ???????????????? newArgs.add("-finalizerinfo"); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("flags")) { >>>>> ???????????????? newArgs.add("-flags"); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("sysprops")) { >>>>> ???????????????? newArgs.add("-sysprops"); >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????????? if (s.equals("serverid")) { >>>>> ???????????????? String serverid = sg.getOptarg(); >>>>> ???????????????? if (serverid != null) { >>>>> ???????????????????? newArgs.add(serverid); >>>>> ???????????????? } >>>>> ???????????????? continue; >>>>> ???????????? } >>>>> ???????? } >>>>> >>>>> ???????? if (!requestHeapdump && (dumpfile != null)) { >>>>> ???????????? throw new IllegalArgumentException("Unexpected >>>>> argument dumpfile"); >>>>> ???????? } >>>>> ???????? if (requestHeapdump) { >>>>> ???????????? if (dumpfile == null) { >>>>> ???????????????? newArgs.add("-heap:format=b"); >>>>> ???????????? } else { >>>>> ????????????????? newArgs.add("-heap:format=b,file=" + dumpfile); >>>>> ???????????? } >>>>> ???????? } >>>>> ???????? buildAttachArgs(newArgs, pid, exe, core, remote, >>>>> allowEmpty); >>>>> >>>>> ???????? return newArgs; >>>>> ???? } >>>>> >>>>> ???? private static void runCLHSDB(String[] oldArgs) { >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>>> longOpts, true); >>>>> >>>>> ???????? CLHSDB.main(newArgs.toArray(new String[newArgs.size()])); >>>>> ???? } >>>>> >>>>> ???? private static void runHSDB(String[] oldArgs) { >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>>>> ????????? ArrayList newArgs = processOptions(oldArgs, >>>>> longOpts, true); >>>>> >>>>> ????????? HSDB.main(newArgs.toArray(new String[newArgs.size()])); >>>>> ???? } >>>>> >>>>> ???? private static void runJSTACK(String[] oldArgs) { >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>>>> "mixed", "locks"}; >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>>> longOpts, false); >>>>> >>>>> ???????? JStack jstack = new JStack(false, false); >>>>> ???????? jstack.runWithArgs(newArgs.toArray(new >>>>> String[newArgs.size()])); >>>>> ???? } >>>>> >>>>> ???? private static void runJMAP(String[] oldArgs) { >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>>>> ?????????????? "heap", "binaryheap", "dumpfile=", "histo", >>>>> "clstats", "finalizerinfo"}; >>>>> >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>>> longOpts, false); >>>>> >>>>> ???????? JMap.main(newArgs.toArray(new String[newArgs.size()])); >>>>> ???? } >>>>> >>>>> ???? private static void runJINFO(String[] oldArgs) { >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>>>> "flags", "sysprops"}; >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>>> longOpts, false); >>>>> >>>>> ???????? JInfo.main(newArgs.toArray(new String[newArgs.size()])); >>>>> ???? } >>>>> >>>>> ???? private static void runJSNAP(String[] oldArgs) { >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >>>>> "all"}; >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>>> longOpts, false); >>>>> ???????? JSnap.main(newArgs.toArray(new String[newArgs.size()])); >>>>> ???? } >>>>> >>>>> ???? private static void runDEBUGD(String[] oldArgs) { >>>>> ???????? // By default SA agent classes prefer Windows process >>>>> debugger >>>>> ???????? // to windbg debugger. SA expects special properties to >>>>> be set >>>>> ???????? // to choose other debuggers. We will set those here before >>>>> ???????? // attaching to SA agent. >>>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", >>>>> "true"); >>>>> >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "serverid="}; >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>>> longOpts, false); >>>>> >>>>> ???????? // delegate to the actual SA debug server. >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new >>>>> String[newArgs.size()])); >>>>> ???? } >>>>> >>>>> >>>>> Please, let me know what do you think. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >>>>>> Sorry, new webrev is here: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga: >>>>>>> PING: Could you review them? >>>>>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>>>>> >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga: >>>>>>>> Hi Jc, >>>>>>>> >>>>>>>> Thank you for your comment! >>>>>>>> I updated a webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>>>>>> >>>>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >>>>>>>>> could just do a try-with-resources instead of the finally >>>>>>>>> clause... >>>>>>>> I created DebugdUtils for convenience class for attach - detach >>>>>>>> mechanism of debug server. >>>>>>>> IMHO it is prefer "detach" to "close" in this case. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe Beyler: >>>>>>>> >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> I'm not an official reviewer but I don't see an issue with the >>>>>>>>> CSR (except that this seems to be bringing a fork in the tools >>>>>>>>> with some handling remote and others not). >>>>>>>>> >>>>>>>>> However, this code is really repetitive and this is not the >>>>>>>>> place to do a big refactor probably but we could do a few nits >>>>>>>>> perhaps: >>>>>>>>> ??? - Instead of every tool calling commonHelp with an >>>>>>>>> additional flag you could divide into commonHelp and >>>>>>>>> commonHelpWithRemote for the tools and they both call the >>>>>>>>> current commonHelp with that boolean; so that when we are >>>>>>>>> looking at the tool code we know what we are getting... So >>>>>>>>> something like: >>>>>>>>> >>>>>>>>> private static boolean commonHelp(String mode, boolean >>>>>>>>> canConnectToRemote) { >>>>>>>>> ???? .. >>>>>>>>> ? } >>>>>>>>> >>>>>>>>> private static boolean commonHelp(String mode) { >>>>>>>>> ??? return commonHelp(mode, false); >>>>>>>>> } >>>>>>>>> >>>>>>>>> private static boolean commonHelpWithRemote(String mode) { >>>>>>>>> ??? return commonHelp(mode, false); >>>>>>>>> } >>>>>>>>> >>>>>>>>> and that way the tools that change are just going from: >>>>>>>>> -??????? return commonHelp("jmap"); >>>>>>>>> +??????? return commonHelpWithRemote("jmap"); >>>>>>>>> >>>>>>>>> - In the same vein, instead of passing null to the >>>>>>>>> buildAttachArgs; you could? make a variable null: >>>>>>>>> >>>>>>>>> -??????? buildAttachArgs(newArgs, pid, exe, core, true); >>>>>>>>> +??????? String noRemote = null; >>>>>>>>> +??????? buildAttachArgs(newArgs, pid, exe, core, noRemote, >>>>>>>>> true); >>>>>>>>> >>>>>>>>> >>>>>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>>>>>>>> >>>>>>>>> ??? Nit: you have empty lines at l64 and l73 >>>>>>>>> >>>>>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>>>>>>>> >>>>>>>>> ???? Nit : you have an empty line at l110 >>>>>>>>> >>>>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >>>>>>>>> could just do a try-with-resources instead of the finally >>>>>>>>> clause... >>>>>>>>> >>>>>>>>> All of these are details, I just thought I'd mention them :) >>>>>>>>> Jc >>>>>>>>> >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa >>>>>>>>> Suenaga? wrote: >>>>>>>>>> PING: Could you review them? >>>>>>>>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>>>>> >>>>>>>>>> CSR status is provisional. So I need reviewers both CSR and >>>>>>>>>> webrev. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa Suenaga: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review this change: >>>>>>>>>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>>>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can >>>>>>>>>>> connect to >>>>>>>>>>> debug server (jsadebugd). However it has not done so since >>>>>>>>>>> JDK 9 because >>>>>>>>>>> jhsdb cannot accept the attach request to debug server. >>>>>>>>>>> So I want to introduce new option `--remote` to connect to >>>>>>>>>>> debug server. >>>>>>>>>>> >>>>>>>>>>> I created CSR for this issue. So please review it together. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jc >>>>> >>> > From serguei.spitsyn at oracle.com Sun Jun 16 21:53:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 16 Jun 2019 14:53:14 -0700 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> References: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> Message-ID: <19f7df93-045b-8619-1b4c-acfab002a932@oracle.com> Hi Yasumasa, It looks good. Thank you for the update! Thanks, Serguei On 6/16/19 07:30, Yasumasa Suenaga wrote: > Hi Serguei, Chris, > > Thank you for your comment. > I uploaded new webrev. Could you review again? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.01/ > > I separated a function for handling prelinked library. > Also I added some comments for its process. > > > Thanks, > > Yasumasa > > > On 2019/06/15 3:48, Chris Plummer wrote: >> Hi Yasumasa, >> >> I think you should replace the embedded link with more of a textual >> description of where to look in the gdb source. >> >> I'd like to see some short comments. You have a few logical blocks of >> code that would greatly benefit from just one line saying what they >> are doing, especially the loop. >> >> thanks, >> >> Chris >> >> On 6/13/19 10:49 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ >>> >>> I attempted to open the core which is generated by RHEL 6, but it >>> could not . >>> >>> The OS which generated the core is set to enable prelink. >>> According to GDB implementation, load address of prelinked library >>> should be calculated by offset of link_map.l_ld and the address of >>> .dynamic section. >>> >>> >>> Thanks, >>> >>> Yasumasa >> >> From yasuenag at gmail.com Sun Jun 16 22:52:09 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 17 Jun 2019 07:52:09 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> Message-ID: 2019?6?17?(?) 6:47 serguei.spitsyn at oracle.com : > Forgot to tell... > This can be pushed only after the CSR is approved. > Sure! And I will push it when I get second reviewer. BTW should I push this change to jdk/jdk? or push to jdk/jdk13 manually? Thanks, Yasumasa > Thanks, > Serguei > > > On 6/16/19 14:44, serguei.spitsyn at oracle.com wrote: > > Hi Yasumasa, > > > > > > On 6/16/19 07:22, Yasumasa Suenaga wrote: > >> Hi Serguei, > >> > >> >>> One minor suggestion is to use the final field NO_REMOTE instead > >> >>> of null for initialization of the local variable "remote". > >> > >> I fixed it on new webrev. Could you check again? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ > > > > > > It looks good. > > Thanks you for the update! > > > >> > >> >> IMHO refactoring should be worked on another issue. > >> > > >> > Agreed. > >> > >> I filed it to JBS: > >> https://bugs.openjdk.java.net/browse/JDK-8226204 > > > > Thank you for filing the enhancement! > > > > Thanks. > > Serguei > > > > > >> Thanks, > >> > >> Yasumasa > >> > >> > >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com wrote: > >>> Hi Yasumasa, > >>> > >>> > >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: > >>>> Hi Serguei, > >>>> > >>>> Thank you for your comment! > >>>> > >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com wrote: > >>>>> Hi Yasumasa, > >>>>> > >>>>> I've added myself as a reviewer, so you can finalize it now. > >>>> > >>>> I moved CSR to Finalized, and added a comment for your question. > >>> > >>> Okay, thanks! > >>> > >>> > >>>>> The fix looks pretty good to me. > >>>>> > >>>>> One minor suggestion is to use the final field NO_REMOTE instead > >>>>> of null for initialization of the local variable "remote". > >>>> > >>>> I will fix that. > >>>> > >>>> > >>>>> Also just an observation that there is some room for option > >>>>> processing refactoring. > >>>> > >>>> Your suggestion handles all options in one parser method. > >>>> I concern it might be complex for option validation. > >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not allowed.) > >>> > >>> This concern is not valid as the list allowed options allowed for each > >>> jhsdb sub-command is controlled with the longOpts argument. > >>> > >>> jmap has: > >>> String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>> "heap", "binaryheap", "dumpfile=", "histo", > >>> "clstats", "finalizerinfo"}; > >>> > >>> but jstack has: > >>> String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>> "mixed", "locks"}; > >>> > >>>> IMHO refactoring should be worked on another issue. > >>> > >>> Agreed. > >>> > >>> > >>>> If you are OK in above, I will upload new webrev. > >>> > >>> Yes, I'm Okay with it. > >>> > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>>> All the jhsdb sub-commands do execute similar loops like this: > >>>>> while((s = sg.next(null, longOpts)) != null) { > >>>>> . . . > >>>>> } > >>>>> > >>>>> It can be moved into a separate method instead. > >>>>> The longOpts can passed in arguments. > >>>>> > >>>>> It can be something like this: > >>>>> > >>>>> private ArrayList processOptions(final String[] oldArgs, > >>>>> final String[] > >>>>> longOpts, > >>>>> boolean allowEmpty) { > >>>>> SAGetopt sg = new SAGetopt(oldArgs); > >>>>> ArrayList newArgs = new ArrayList(); > >>>>> > >>>>> String pid = null; > >>>>> String exe = null; > >>>>> String core = null; > >>>>> String s = null; > >>>>> String dumpfile = null; > >>>>> String remote = NO_REMOTE; > >>>>> boolean requestHeapdump = false; > >>>>> > >>>>> while((s = sg.next(null, longOpts)) != null) { > >>>>> if (s.equals("exe")) { > >>>>> exe = sg.getOptarg(); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("core")) { > >>>>> core = sg.getOptarg(); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("pid")) { > >>>>> pid = sg.getOptarg(); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("remote")) { > >>>>> remote = sg.getOptarg(); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("mixed")) { > >>>>> newArgs.add("-m"); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("locks")) { > >>>>> newArgs.add("-l"); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("heap")) { > >>>>> newArgs.add("-heap"); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("binaryheap")) { > >>>>> requestHeapdump = true; > >>>>> continue; > >>>>> } > >>>>> if (s.equals("dumpfile")) { > >>>>> dumpfile = sg.getOptarg(); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("histo")) { > >>>>> newArgs.add("-histo"); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("clstats")) { > >>>>> newArgs.add("-clstats"); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("finalizerinfo")) { > >>>>> newArgs.add("-finalizerinfo"); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("flags")) { > >>>>> newArgs.add("-flags"); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("sysprops")) { > >>>>> newArgs.add("-sysprops"); > >>>>> continue; > >>>>> } > >>>>> if (s.equals("serverid")) { > >>>>> String serverid = sg.getOptarg(); > >>>>> if (serverid != null) { > >>>>> newArgs.add(serverid); > >>>>> } > >>>>> continue; > >>>>> } > >>>>> } > >>>>> > >>>>> if (!requestHeapdump && (dumpfile != null)) { > >>>>> throw new IllegalArgumentException("Unexpected > >>>>> argument dumpfile"); > >>>>> } > >>>>> if (requestHeapdump) { > >>>>> if (dumpfile == null) { > >>>>> newArgs.add("-heap:format=b"); > >>>>> } else { > >>>>> newArgs.add("-heap:format=b,file=" + dumpfile); > >>>>> } > >>>>> } > >>>>> buildAttachArgs(newArgs, pid, exe, core, remote, > >>>>> allowEmpty); > >>>>> > >>>>> return newArgs; > >>>>> } > >>>>> > >>>>> private static void runCLHSDB(String[] oldArgs) { > >>>>> String[] longOpts = {"exe=", "core=", "pid="}; > >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, true); > >>>>> > >>>>> CLHSDB.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> } > >>>>> > >>>>> private static void runHSDB(String[] oldArgs) { > >>>>> String[] longOpts = {"exe=", "core=", "pid="}; > >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, true); > >>>>> > >>>>> HSDB.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> } > >>>>> > >>>>> private static void runJSTACK(String[] oldArgs) { > >>>>> String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>>>> "mixed", "locks"}; > >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> > >>>>> JStack jstack = new JStack(false, false); > >>>>> jstack.runWithArgs(newArgs.toArray(new > >>>>> String[newArgs.size()])); > >>>>> } > >>>>> > >>>>> private static void runJMAP(String[] oldArgs) { > >>>>> String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>>>> "heap", "binaryheap", "dumpfile=", "histo", > >>>>> "clstats", "finalizerinfo"}; > >>>>> > >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> > >>>>> JMap.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> } > >>>>> > >>>>> private static void runJINFO(String[] oldArgs) { > >>>>> String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>>>> "flags", "sysprops"}; > >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> > >>>>> JInfo.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> } > >>>>> > >>>>> private static void runJSNAP(String[] oldArgs) { > >>>>> String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>>>> "all"}; > >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> JSnap.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> } > >>>>> > >>>>> private static void runDEBUGD(String[] oldArgs) { > >>>>> // By default SA agent classes prefer Windows process > >>>>> debugger > >>>>> // to windbg debugger. SA expects special properties to > >>>>> be set > >>>>> // to choose other debuggers. We will set those here before > >>>>> // attaching to SA agent. > >>>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", > >>>>> "true"); > >>>>> > >>>>> String[] longOpts = {"exe=", "core=", "pid=", "serverid="}; > >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> > >>>>> // delegate to the actual SA debug server. > >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new > >>>>> String[newArgs.size()])); > >>>>> } > >>>>> > >>>>> > >>>>> Please, let me know what do you think. > >>>>> > >>>>> Thanks, > >>>>> Serguei > >>>>> > >>>>> > >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: > >>>>>> Sorry, new webrev is here: > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > >>>>>> > >>>>>> Yasumasa > >>>>>> > >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga: > >>>>>>> PING: Could you review them? > >>>>>>> > >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>>>>>>> webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>>>>>>> > >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if possible. > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Yasumasa > >>>>>>> > >>>>>>> > >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga: > >>>>>>>> Hi Jc, > >>>>>>>> > >>>>>>>> Thank you for your comment! > >>>>>>>> I updated a webrev: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > >>>>>>>> > >>>>>>>>> - In runTests; if DebugdUtils implemented Closeable, you > >>>>>>>>> could just do a try-with-resources instead of the finally > >>>>>>>>> clause... > >>>>>>>> I created DebugdUtils for convenience class for attach - detach > >>>>>>>> mechanism of debug server. > >>>>>>>> IMHO it is prefer "detach" to "close" in this case. > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe Beyler: > >>>>>>>> > >>>>>>>>> Hi Yasumasa, > >>>>>>>>> > >>>>>>>>> I'm not an official reviewer but I don't see an issue with the > >>>>>>>>> CSR (except that this seems to be bringing a fork in the tools > >>>>>>>>> with some handling remote and others not). > >>>>>>>>> > >>>>>>>>> However, this code is really repetitive and this is not the > >>>>>>>>> place to do a big refactor probably but we could do a few nits > >>>>>>>>> perhaps: > >>>>>>>>> - Instead of every tool calling commonHelp with an > >>>>>>>>> additional flag you could divide into commonHelp and > >>>>>>>>> commonHelpWithRemote for the tools and they both call the > >>>>>>>>> current commonHelp with that boolean; so that when we are > >>>>>>>>> looking at the tool code we know what we are getting... So > >>>>>>>>> something like: > >>>>>>>>> > >>>>>>>>> private static boolean commonHelp(String mode, boolean > >>>>>>>>> canConnectToRemote) { > >>>>>>>>> .. > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> private static boolean commonHelp(String mode) { > >>>>>>>>> return commonHelp(mode, false); > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> private static boolean commonHelpWithRemote(String mode) { > >>>>>>>>> return commonHelp(mode, false); > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> and that way the tools that change are just going from: > >>>>>>>>> - return commonHelp("jmap"); > >>>>>>>>> + return commonHelpWithRemote("jmap"); > >>>>>>>>> > >>>>>>>>> - In the same vein, instead of passing null to the > >>>>>>>>> buildAttachArgs; you could make a variable null: > >>>>>>>>> > >>>>>>>>> - buildAttachArgs(newArgs, pid, exe, core, true); > >>>>>>>>> + String noRemote = null; > >>>>>>>>> + buildAttachArgs(newArgs, pid, exe, core, noRemote, > >>>>>>>>> true); > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> - > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html > >>>>>>>>> > >>>>>>>>> Nit: you have empty lines at l64 and l73 > >>>>>>>>> > >>>>>>>>> - > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html > >>>>>>>>> > >>>>>>>>> Nit : you have an empty line at l110 > >>>>>>>>> > >>>>>>>>> - In runTests; if DebugdUtils implemented Closeable, you > >>>>>>>>> could just do a try-with-resources instead of the finally > >>>>>>>>> clause... > >>>>>>>>> > >>>>>>>>> All of these are details, I just thought I'd mention them :) > >>>>>>>>> Jc > >>>>>>>>> > >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa > >>>>>>>>> Suenaga wrote: > >>>>>>>>>> PING: Could you review them? > >>>>>>>>>> > >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>>>>>>> webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>>>>>>> > >>>>>>>>>> CSR status is provisional. So I need reviewers both CSR and > >>>>>>>>>> webrev. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Yasumasa > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa Suenaga: > >>>>>>>>>>> Hi all, > >>>>>>>>>>> > >>>>>>>>>>> Please review this change: > >>>>>>>>>>> > >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>>>>>>> webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can > >>>>>>>>>>> connect to > >>>>>>>>>>> debug server (jsadebugd). However it has not done so since > >>>>>>>>>>> JDK 9 because > >>>>>>>>>>> jhsdb cannot accept the attach request to debug server. > >>>>>>>>>>> So I want to introduce new option `--remote` to connect to > >>>>>>>>>>> debug server. > >>>>>>>>>>> > >>>>>>>>>>> I created CSR for this issue. So please review it together. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> > >>>>>>>>>>> Yasumasa > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Jc > >>>>> > >>> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Sun Jun 16 22:56:05 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 17 Jun 2019 07:56:05 +0900 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: <19f7df93-045b-8619-1b4c-acfab002a932@oracle.com> References: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> <19f7df93-045b-8619-1b4c-acfab002a932@oracle.com> Message-ID: Thanks Serguei! Yasumasa 2019?6?17?(?) 6:53 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > It looks good. > Thank you for the update! > > Thanks, > Serguei > > > On 6/16/19 07:30, Yasumasa Suenaga wrote: > > Hi Serguei, Chris, > > > > Thank you for your comment. > > I uploaded new webrev. Could you review again? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.01/ > > > > I separated a function for handling prelinked library. > > Also I added some comments for its process. > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2019/06/15 3:48, Chris Plummer wrote: > >> Hi Yasumasa, > >> > >> I think you should replace the embedded link with more of a textual > >> description of where to look in the gdb source. > >> > >> I'd like to see some short comments. You have a few logical blocks of > >> code that would greatly benefit from just one line saying what they > >> are doing, especially the loop. > >> > >> thanks, > >> > >> Chris > >> > >> On 6/13/19 10:49 PM, Yasumasa Suenaga wrote: > >>> Hi all, > >>> > >>> Please review this change: > >>> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 > >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ > >>> > >>> I attempted to open the core which is generated by RHEL 6, but it > >>> could not . > >>> > >>> The OS which generated the core is set to enable prelink. > >>> According to GDB implementation, load address of prelinked library > >>> should be calculated by offset of link_map.l_ld and the address of > >>> .dynamic section. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jun 17 08:06:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Jun 2019 18:06:28 +1000 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> Message-ID: <0f945652-4de0-5d57-66e7-874464c10903@oracle.com> Hi Yasumasa, On 17/06/2019 8:52 am, Yasumasa Suenaga wrote: > 2019?6?17?(?) 6:47 serguei.spitsyn at oracle.com > >: > > Forgot to tell... > This can be pushed only after the CSR is approved. > > > Sure! > And I will push it when I get second reviewer. > > BTW should I push this change to jdk/jdk? or push to jdk/jdk13 manually? JDK 13 has now entered RDP1 so if you want this to go into 13 it will need special approval: http://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process Otherwise push to jdk/jdk and it will be for JDK 14. Cheers, David > > Thanks, > > Yasumasa > > > > Thanks, > Serguei > > > On 6/16/19 14:44, serguei.spitsyn at oracle.com > wrote: > > Hi Yasumasa, > > > > > > On 6/16/19 07:22, Yasumasa Suenaga wrote: > >> Hi Serguei, > >> > >> >>> One minor suggestion is to use the final field NO_REMOTE instead > >> >>> of null for initialization of the local variable "remote". > >> > >> I fixed it on new webrev. Could you check again? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ > > > > > > It looks good. > > Thanks you for the update! > > > >> > >> >> IMHO refactoring should be worked on another issue. > >> > > >> > Agreed. > >> > >> I filed it to JBS: > >> https://bugs.openjdk.java.net/browse/JDK-8226204 > > > > Thank you for filing the enhancement! > > > > Thanks. > > Serguei > > > > > >> Thanks, > >> > >> Yasumasa > >> > >> > >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com > wrote: > >>> Hi Yasumasa, > >>> > >>> > >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: > >>>> Hi Serguei, > >>>> > >>>> Thank you for your comment! > >>>> > >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com > wrote: > >>>>> Hi Yasumasa, > >>>>> > >>>>> I've added myself as a reviewer, so you can finalize it now. > >>>> > >>>> I moved CSR to Finalized, and added a comment for your question. > >>> > >>> Okay, thanks! > >>> > >>> > >>>>> The fix looks pretty good to me. > >>>>> > >>>>> One minor suggestion is to use the final field NO_REMOTE instead > >>>>> of null for initialization of the local variable "remote". > >>>> > >>>> I will fix that. > >>>> > >>>> > >>>>> Also just an observation that there is some room for option > >>>>> processing refactoring. > >>>> > >>>> Your suggestion handles all options in one parser method. > >>>> I concern it might be complex for option validation. > >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not allowed.) > >>> > >>> This concern is not valid as the list allowed options allowed > for each > >>> jhsdb sub-command is controlled with the longOpts argument. > >>> > >>> jmap has: > >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>> ??????????????? "heap", "binaryheap", "dumpfile=", "histo", > >>> "clstats", "finalizerinfo"}; > >>> > >>> but jstack has: > >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>> "mixed", "locks"}; > >>> > >>>> IMHO refactoring should be worked on another issue. > >>> > >>> Agreed. > >>> > >>> > >>>> If you are OK in above, I will upload new webrev. > >>> > >>> Yes, I'm Okay with it. > >>> > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>>> All the jhsdb sub-commands do execute similar loops like this: > >>>>> while((s = sg.next(null, longOpts)) != null) { > >>>>> ???????? . . . > >>>>> ???? } > >>>>> > >>>>> It can be moved into a separate method instead. > >>>>> The longOpts can passed in arguments. > >>>>> > >>>>> It can be something like this: > >>>>> > >>>>> ???? private ArrayList processOptions(final String[] > oldArgs, > >>>>> ????????????????????????????????????????????? final String[] > >>>>> longOpts, > >>>>> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean > allowEmpty) { > >>>>> ???????? SAGetopt sg = new SAGetopt(oldArgs); > >>>>> ???????? ArrayList newArgs = new ArrayList(); > >>>>> > >>>>> ???????? String pid = null; > >>>>> ???????? String exe = null; > >>>>> ???????? String core = null; > >>>>> ???????? String s = null; > >>>>> ???????? String dumpfile = null; > >>>>> ???????? String remote = NO_REMOTE; > >>>>> ???????? boolean requestHeapdump = false; > >>>>> > >>>>> ???????? while((s = sg.next(null, longOpts)) != null) { > >>>>> ???????????? if (s.equals("exe")) { > >>>>> ???????????????? exe = sg.getOptarg(); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("core")) { > >>>>> ???????????????? core = sg.getOptarg(); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("pid")) { > >>>>> ????????????????? pid = sg.getOptarg(); > >>>>> ????????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("remote")) { > >>>>> ???????????????? remote = sg.getOptarg(); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("mixed")) { > >>>>> ???????????????? newArgs.add("-m"); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("locks")) { > >>>>> ???????????????? newArgs.add("-l"); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("heap")) { > >>>>> ???????????????? newArgs.add("-heap"); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("binaryheap")) { > >>>>> ???????????????? requestHeapdump = true; > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("dumpfile")) { > >>>>> ???????????????? dumpfile = sg.getOptarg(); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("histo")) { > >>>>> ???????????????? newArgs.add("-histo"); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("clstats")) { > >>>>> ???????????????? newArgs.add("-clstats"); > >>>>> ????????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("finalizerinfo")) { > >>>>> ???????????????? newArgs.add("-finalizerinfo"); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("flags")) { > >>>>> ???????????????? newArgs.add("-flags"); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("sysprops")) { > >>>>> ???????????????? newArgs.add("-sysprops"); > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????????? if (s.equals("serverid")) { > >>>>> ???????????????? String serverid = sg.getOptarg(); > >>>>> ???????????????? if (serverid != null) { > >>>>> ???????????????????? newArgs.add(serverid); > >>>>> ???????????????? } > >>>>> ???????????????? continue; > >>>>> ???????????? } > >>>>> ???????? } > >>>>> > >>>>> ???????? if (!requestHeapdump && (dumpfile != null)) { > >>>>> ???????????? throw new IllegalArgumentException("Unexpected > >>>>> argument dumpfile"); > >>>>> ???????? } > >>>>> ???????? if (requestHeapdump) { > >>>>> ???????????? if (dumpfile == null) { > >>>>> ???????????????? newArgs.add("-heap:format=b"); > >>>>> ???????????? } else { > >>>>> ????????????????? newArgs.add("-heap:format=b,file=" + dumpfile); > >>>>> ???????????? } > >>>>> ???????? } > >>>>> ???????? buildAttachArgs(newArgs, pid, exe, core, remote, > >>>>> allowEmpty); > >>>>> > >>>>> ???????? return newArgs; > >>>>> ???? } > >>>>> > >>>>> ???? private static void runCLHSDB(String[] oldArgs) { > >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; > >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, true); > >>>>> > >>>>> ???????? CLHSDB.main(newArgs.toArray(new > String[newArgs.size()])); > >>>>> ???? } > >>>>> > >>>>> ???? private static void runHSDB(String[] oldArgs) { > >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; > >>>>> ????????? ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, true); > >>>>> > >>>>> ????????? HSDB.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> ???? } > >>>>> > >>>>> ???? private static void runJSTACK(String[] oldArgs) { > >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", > "remote=", > >>>>> "mixed", "locks"}; > >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> > >>>>> ???????? JStack jstack = new JStack(false, false); > >>>>> ???????? jstack.runWithArgs(newArgs.toArray(new > >>>>> String[newArgs.size()])); > >>>>> ???? } > >>>>> > >>>>> ???? private static void runJMAP(String[] oldArgs) { > >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", > >>>>> ?????????????? "heap", "binaryheap", "dumpfile=", "histo", > >>>>> "clstats", "finalizerinfo"}; > >>>>> > >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> > >>>>> ???????? JMap.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> ???? } > >>>>> > >>>>> ???? private static void runJINFO(String[] oldArgs) { > >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", > "remote=", > >>>>> "flags", "sysprops"}; > >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> > >>>>> ???????? JInfo.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> ???? } > >>>>> > >>>>> ???? private static void runJSNAP(String[] oldArgs) { > >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", > "remote=", > >>>>> "all"}; > >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> ???????? JSnap.main(newArgs.toArray(new String[newArgs.size()])); > >>>>> ???? } > >>>>> > >>>>> ???? private static void runDEBUGD(String[] oldArgs) { > >>>>> ???????? // By default SA agent classes prefer Windows process > >>>>> debugger > >>>>> ???????? // to windbg debugger. SA expects special properties to > >>>>> be set > >>>>> ???????? // to choose other debuggers. We will set those here > before > >>>>> ???????? // attaching to SA agent. > >>>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", > >>>>> "true"); > >>>>> > >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", > "serverid="}; > >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, > >>>>> longOpts, false); > >>>>> > >>>>> ???????? // delegate to the actual SA debug server. > >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new > >>>>> String[newArgs.size()])); > >>>>> ???? } > >>>>> > >>>>> > >>>>> Please, let me know what do you think. > >>>>> > >>>>> Thanks, > >>>>> Serguei > >>>>> > >>>>> > >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: > >>>>>> Sorry, new webrev is here: > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > >>>>>> > >>>>>> Yasumasa > >>>>>> > >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga >: > >>>>>>> PING: Could you review them? > >>>>>>> > >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>>>>>>> > webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>>>>>>> > >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if > possible. > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Yasumasa > >>>>>>> > >>>>>>> > >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga >: > >>>>>>>> Hi Jc, > >>>>>>>> > >>>>>>>> Thank you for your comment! > >>>>>>>> I updated a webrev: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > >>>>>>>> > >>>>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you > >>>>>>>>> could just do a try-with-resources instead of the finally > >>>>>>>>> clause... > >>>>>>>> I created DebugdUtils for convenience class for attach - > detach > >>>>>>>> mechanism of debug server. > >>>>>>>> IMHO it is prefer "detach" to "close" in this case. > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe > Beyler>: > >>>>>>>> > >>>>>>>>> Hi Yasumasa, > >>>>>>>>> > >>>>>>>>> I'm not an official reviewer but I don't see an issue > with the > >>>>>>>>> CSR (except that this seems to be bringing a fork in the > tools > >>>>>>>>> with some handling remote and others not). > >>>>>>>>> > >>>>>>>>> However, this code is really repetitive and this is not the > >>>>>>>>> place to do a big refactor probably but we could do a few > nits > >>>>>>>>> perhaps: > >>>>>>>>> ??? - Instead of every tool calling commonHelp with an > >>>>>>>>> additional flag you could divide into commonHelp and > >>>>>>>>> commonHelpWithRemote for the tools and they both call the > >>>>>>>>> current commonHelp with that boolean; so that when we are > >>>>>>>>> looking at the tool code we know what we are getting... So > >>>>>>>>> something like: > >>>>>>>>> > >>>>>>>>> private static boolean commonHelp(String mode, boolean > >>>>>>>>> canConnectToRemote) { > >>>>>>>>> ???? .. > >>>>>>>>> ? } > >>>>>>>>> > >>>>>>>>> private static boolean commonHelp(String mode) { > >>>>>>>>> ??? return commonHelp(mode, false); > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> private static boolean commonHelpWithRemote(String mode) { > >>>>>>>>> ??? return commonHelp(mode, false); > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> and that way the tools that change are just going from: > >>>>>>>>> -??????? return commonHelp("jmap"); > >>>>>>>>> +??????? return commonHelpWithRemote("jmap"); > >>>>>>>>> > >>>>>>>>> - In the same vein, instead of passing null to the > >>>>>>>>> buildAttachArgs; you could? make a variable null: > >>>>>>>>> > >>>>>>>>> -??????? buildAttachArgs(newArgs, pid, exe, core, true); > >>>>>>>>> +??????? String noRemote = null; > >>>>>>>>> +??????? buildAttachArgs(newArgs, pid, exe, core, noRemote, > >>>>>>>>> true); > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html > > >>>>>>>>> > >>>>>>>>> ??? Nit: you have empty lines at l64 and l73 > >>>>>>>>> > >>>>>>>>> > -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html > > >>>>>>>>> > >>>>>>>>> ???? Nit : you have an empty line at l110 > >>>>>>>>> > >>>>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you > >>>>>>>>> could just do a try-with-resources instead of the finally > >>>>>>>>> clause... > >>>>>>>>> > >>>>>>>>> All of these are details, I just thought I'd mention them :) > >>>>>>>>> Jc > >>>>>>>>> > >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa > >>>>>>>>> Suenaga> > wrote: > >>>>>>>>>> PING: Could you review them? > >>>>>>>>>> > >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>>>>>>> > webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>>>>>>> > >>>>>>>>>> CSR status is provisional. So I need reviewers both CSR and > >>>>>>>>>> webrev. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Yasumasa > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa > Suenaga>: > >>>>>>>>>>> Hi all, > >>>>>>>>>>> > >>>>>>>>>>> Please review this change: > >>>>>>>>>>> > >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>>>>>>> > webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can > >>>>>>>>>>> connect to > >>>>>>>>>>> debug server (jsadebugd). However it has not done so since > >>>>>>>>>>> JDK 9 because > >>>>>>>>>>> jhsdb cannot accept the attach request to debug server. > >>>>>>>>>>> So I want to introduce new option `--remote` to connect to > >>>>>>>>>>> debug server. > >>>>>>>>>>> > >>>>>>>>>>> I created CSR for this issue. So please review it together. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> > >>>>>>>>>>> Yasumasa > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Jc > >>>>> > >>> > > > From yasuenag at gmail.com Mon Jun 17 08:50:26 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 17 Jun 2019 17:50:26 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: <0f945652-4de0-5d57-66e7-874464c10903@oracle.com> References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> <0f945652-4de0-5d57-66e7-874464c10903@oracle.com> Message-ID: <1b56d28c-f0da-3b84-d6e0-5cd2f00501ef@gmail.com> Hi David, 8209790 is filed as a bug. According to [1], I think we can push the fix to jdk/jdk13. Does it correct? I'm not sure which version (13 or 14) should be set on JBS before pushing. (Of course I will push it after the CSR is approved.) Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003051.html On 2019/06/17 17:06, David Holmes wrote: > Hi Yasumasa, > > On 17/06/2019 8:52 am, Yasumasa Suenaga wrote: >> 2019?6?17?(?) 6:47 serguei.spitsyn at oracle.com >: >> >> ??? Forgot to tell... >> ??? This can be pushed only after the CSR is approved. >> >> >> Sure! >> And I will push it when I get second reviewer. >> >> BTW should I push this change to jdk/jdk? or push to jdk/jdk13 manually? > > JDK 13 has now entered RDP1 so if you want this to go into 13 it will need special approval: > > http://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process > > Otherwise push to jdk/jdk and it will be for JDK 14. > > Cheers, > David > >> >> Thanks, >> >> Yasumasa >> >> >> >> ??? Thanks, >> ??? Serguei >> >> >> ??? On 6/16/19 14:44, serguei.spitsyn at oracle.com >> ??? wrote: >> ???? > Hi Yasumasa, >> ???? > >> ???? > >> ???? > On 6/16/19 07:22, Yasumasa Suenaga wrote: >> ???? >> Hi Serguei, >> ???? >> >> ???? >> >>> One minor suggestion is to use the final field NO_REMOTE instead >> ???? >> >>> of null for initialization of the local variable "remote". >> ???? >> >> ???? >> I fixed it on new webrev. Could you check again? >> ???? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ >> ???? > >> ???? > >> ???? > It looks good. >> ???? > Thanks you for the update! >> ???? > >> ???? >> >> ???? >> >> IMHO refactoring should be worked on another issue. >> ???? >> > >> ???? >> > Agreed. >> ???? >> >> ???? >> I filed it to JBS: >> ???? >> https://bugs.openjdk.java.net/browse/JDK-8226204 >> ???? > >> ???? > Thank you for filing the enhancement! >> ???? > >> ???? > Thanks. >> ???? > Serguei >> ???? > >> ???? > >> ???? >> Thanks, >> ???? >> >> ???? >> Yasumasa >> ???? >> >> ???? >> >> ???? >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com >> ??? wrote: >> ???? >>> Hi Yasumasa, >> ???? >>> >> ???? >>> >> ???? >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: >> ???? >>>> Hi Serguei, >> ???? >>>> >> ???? >>>> Thank you for your comment! >> ???? >>>> >> ???? >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com >> ??? wrote: >> ???? >>>>> Hi Yasumasa, >> ???? >>>>> >> ???? >>>>> I've added myself as a reviewer, so you can finalize it now. >> ???? >>>> >> ???? >>>> I moved CSR to Finalized, and added a comment for your question. >> ???? >>> >> ???? >>> Okay, thanks! >> ???? >>> >> ???? >>> >> ???? >>>>> The fix looks pretty good to me. >> ???? >>>>> >> ???? >>>>> One minor suggestion is to use the final field NO_REMOTE instead >> ???? >>>>> of null for initialization of the local variable "remote". >> ???? >>>> >> ???? >>>> I will fix that. >> ???? >>>> >> ???? >>>> >> ???? >>>>> Also just an observation that there is some room for option >> ???? >>>>> processing refactoring. >> ???? >>>> >> ???? >>>> Your suggestion handles all options in one parser method. >> ???? >>>> I concern it might be complex for option validation. >> ???? >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not allowed.) >> ???? >>> >> ???? >>> This concern is not valid as the list allowed options allowed >> ??? for each >> ???? >>> jhsdb sub-command is controlled with the longOpts argument. >> ???? >>> >> ???? >>> jmap has: >> ???? >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> ???? >>> ??????????????? "heap", "binaryheap", "dumpfile=", "histo", >> ???? >>> "clstats", "finalizerinfo"}; >> ???? >>> >> ???? >>> but jstack has: >> ???? >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> ???? >>> "mixed", "locks"}; >> ???? >>> >> ???? >>>> IMHO refactoring should be worked on another issue. >> ???? >>> >> ???? >>> Agreed. >> ???? >>> >> ???? >>> >> ???? >>>> If you are OK in above, I will upload new webrev. >> ???? >>> >> ???? >>> Yes, I'm Okay with it. >> ???? >>> >> ???? >>> >> ???? >>> Thanks, >> ???? >>> Serguei >> ???? >>> >> ???? >>> >> ???? >>>> Thanks, >> ???? >>>> >> ???? >>>> Yasumasa >> ???? >>>> >> ???? >>>> >> ???? >>>>> All the jhsdb sub-commands do execute similar loops like this: >> ???? >>>>> while((s = sg.next(null, longOpts)) != null) { >> ???? >>>>> ???????? . . . >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> It can be moved into a separate method instead. >> ???? >>>>> The longOpts can passed in arguments. >> ???? >>>>> >> ???? >>>>> It can be something like this: >> ???? >>>>> >> ???? >>>>> ???? private ArrayList processOptions(final String[] >> ??? oldArgs, >> ???? >>>>> ????????????????????????????????????????????? final String[] >> ???? >>>>> longOpts, >> ???? >>>>> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean >> ??? allowEmpty) { >> ???? >>>>> ???????? SAGetopt sg = new SAGetopt(oldArgs); >> ???? >>>>> ???????? ArrayList newArgs = new ArrayList(); >> ???? >>>>> >> ???? >>>>> ???????? String pid = null; >> ???? >>>>> ???????? String exe = null; >> ???? >>>>> ???????? String core = null; >> ???? >>>>> ???????? String s = null; >> ???? >>>>> ???????? String dumpfile = null; >> ???? >>>>> ???????? String remote = NO_REMOTE; >> ???? >>>>> ???????? boolean requestHeapdump = false; >> ???? >>>>> >> ???? >>>>> ???????? while((s = sg.next(null, longOpts)) != null) { >> ???? >>>>> ???????????? if (s.equals("exe")) { >> ???? >>>>> ???????????????? exe = sg.getOptarg(); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("core")) { >> ???? >>>>> ???????????????? core = sg.getOptarg(); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("pid")) { >> ???? >>>>> ????????????????? pid = sg.getOptarg(); >> ???? >>>>> ????????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("remote")) { >> ???? >>>>> ???????????????? remote = sg.getOptarg(); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("mixed")) { >> ???? >>>>> ???????????????? newArgs.add("-m"); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("locks")) { >> ???? >>>>> ???????????????? newArgs.add("-l"); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("heap")) { >> ???? >>>>> ???????????????? newArgs.add("-heap"); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("binaryheap")) { >> ???? >>>>> ???????????????? requestHeapdump = true; >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("dumpfile")) { >> ???? >>>>> ???????????????? dumpfile = sg.getOptarg(); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("histo")) { >> ???? >>>>> ???????????????? newArgs.add("-histo"); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("clstats")) { >> ???? >>>>> ???????????????? newArgs.add("-clstats"); >> ???? >>>>> ????????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("finalizerinfo")) { >> ???? >>>>> ???????????????? newArgs.add("-finalizerinfo"); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("flags")) { >> ???? >>>>> ???????????????? newArgs.add("-flags"); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("sysprops")) { >> ???? >>>>> ???????????????? newArgs.add("-sysprops"); >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????????? if (s.equals("serverid")) { >> ???? >>>>> ???????????????? String serverid = sg.getOptarg(); >> ???? >>>>> ???????????????? if (serverid != null) { >> ???? >>>>> ???????????????????? newArgs.add(serverid); >> ???? >>>>> ???????????????? } >> ???? >>>>> ???????????????? continue; >> ???? >>>>> ???????????? } >> ???? >>>>> ???????? } >> ???? >>>>> >> ???? >>>>> ???????? if (!requestHeapdump && (dumpfile != null)) { >> ???? >>>>> ???????????? throw new IllegalArgumentException("Unexpected >> ???? >>>>> argument dumpfile"); >> ???? >>>>> ???????? } >> ???? >>>>> ???????? if (requestHeapdump) { >> ???? >>>>> ???????????? if (dumpfile == null) { >> ???? >>>>> ???????????????? newArgs.add("-heap:format=b"); >> ???? >>>>> ???????????? } else { >> ???? >>>>> ????????????????? newArgs.add("-heap:format=b,file=" + dumpfile); >> ???? >>>>> ???????????? } >> ???? >>>>> ???????? } >> ???? >>>>> ???????? buildAttachArgs(newArgs, pid, exe, core, remote, >> ???? >>>>> allowEmpty); >> ???? >>>>> >> ???? >>>>> ???????? return newArgs; >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> ???? private static void runCLHSDB(String[] oldArgs) { >> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >> ???? >>>>> longOpts, true); >> ???? >>>>> >> ???? >>>>> ???????? CLHSDB.main(newArgs.toArray(new >> ??? String[newArgs.size()])); >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> ???? private static void runHSDB(String[] oldArgs) { >> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >> ???? >>>>> ????????? ArrayList newArgs = processOptions(oldArgs, >> ???? >>>>> longOpts, true); >> ???? >>>>> >> ???? >>>>> ????????? HSDB.main(newArgs.toArray(new String[newArgs.size()])); >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> ???? private static void runJSTACK(String[] oldArgs) { >> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >> ??? "remote=", >> ???? >>>>> "mixed", "locks"}; >> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >> ???? >>>>> longOpts, false); >> ???? >>>>> >> ???? >>>>> ???????? JStack jstack = new JStack(false, false); >> ???? >>>>> ???????? jstack.runWithArgs(newArgs.toArray(new >> ???? >>>>> String[newArgs.size()])); >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> ???? private static void runJMAP(String[] oldArgs) { >> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", "remote=", >> ???? >>>>> ?????????????? "heap", "binaryheap", "dumpfile=", "histo", >> ???? >>>>> "clstats", "finalizerinfo"}; >> ???? >>>>> >> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >> ???? >>>>> longOpts, false); >> ???? >>>>> >> ???? >>>>> ???????? JMap.main(newArgs.toArray(new String[newArgs.size()])); >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> ???? private static void runJINFO(String[] oldArgs) { >> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >> ??? "remote=", >> ???? >>>>> "flags", "sysprops"}; >> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >> ???? >>>>> longOpts, false); >> ???? >>>>> >> ???? >>>>> ???????? JInfo.main(newArgs.toArray(new String[newArgs.size()])); >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> ???? private static void runJSNAP(String[] oldArgs) { >> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >> ??? "remote=", >> ???? >>>>> "all"}; >> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >> ???? >>>>> longOpts, false); >> ???? >>>>> ???????? JSnap.main(newArgs.toArray(new String[newArgs.size()])); >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> ???? private static void runDEBUGD(String[] oldArgs) { >> ???? >>>>> ???????? // By default SA agent classes prefer Windows process >> ???? >>>>> debugger >> ???? >>>>> ???????? // to windbg debugger. SA expects special properties to >> ???? >>>>> be set >> ???? >>>>> ???????? // to choose other debuggers. We will set those here >> ??? before >> ???? >>>>> ???????? // attaching to SA agent. >> ???? >>>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", >> ???? >>>>> "true"); >> ???? >>>>> >> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >> ??? "serverid="}; >> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >> ???? >>>>> longOpts, false); >> ???? >>>>> >> ???? >>>>> ???????? // delegate to the actual SA debug server. >> ???? >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new >> ???? >>>>> String[newArgs.size()])); >> ???? >>>>> ???? } >> ???? >>>>> >> ???? >>>>> >> ???? >>>>> Please, let me know what do you think. >> ???? >>>>> >> ???? >>>>> Thanks, >> ???? >>>>> Serguei >> ???? >>>>> >> ???? >>>>> >> ???? >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >> ???? >>>>>> Sorry, new webrev is here: >> ???? >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >> ???? >>>>>> >> ???? >>>>>> Yasumasa >> ???? >>>>>> >> ???? >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga> ??? >: >> ???? >>>>>>> PING: Could you review them? >> ???? >>>>>>> >> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >> ???? >>>>>>>>>>> >> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >> ???? >>>>>>>>>>> >> ???? >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if >> ??? possible. >> ???? >>>>>>> >> ???? >>>>>>> >> ???? >>>>>>> Thanks, >> ???? >>>>>>> >> ???? >>>>>>> Yasumasa >> ???? >>>>>>> >> ???? >>>>>>> >> ???? >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga> ??? >: >> ???? >>>>>>>> Hi Jc, >> ???? >>>>>>>> >> ???? >>>>>>>> Thank you for your comment! >> ???? >>>>>>>> I updated a webrev: >> ???? >>>>>>>> >> ???? >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >> ???? >>>>>>>> >> ???? >>>>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >> ???? >>>>>>>>> could just do a try-with-resources instead of the finally >> ???? >>>>>>>>> clause... >> ???? >>>>>>>> I created DebugdUtils for convenience class for attach - >> ??? detach >> ???? >>>>>>>> mechanism of debug server. >> ???? >>>>>>>> IMHO it is prefer "detach" to "close" in this case. >> ???? >>>>>>>> >> ???? >>>>>>>> >> ???? >>>>>>>> Thanks, >> ???? >>>>>>>> >> ???? >>>>>>>> Yasumasa >> ???? >>>>>>>> >> ???? >>>>>>>> >> ???? >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe >> ??? Beyler>: >> ???? >>>>>>>> >> ???? >>>>>>>>> Hi Yasumasa, >> ???? >>>>>>>>> >> ???? >>>>>>>>> I'm not an official reviewer but I don't see an issue >> ??? with the >> ???? >>>>>>>>> CSR (except that this seems to be bringing a fork in the >> ??? tools >> ???? >>>>>>>>> with some handling remote and others not). >> ???? >>>>>>>>> >> ???? >>>>>>>>> However, this code is really repetitive and this is not the >> ???? >>>>>>>>> place to do a big refactor probably but we could do a few >> ??? nits >> ???? >>>>>>>>> perhaps: >> ???? >>>>>>>>> ??? - Instead of every tool calling commonHelp with an >> ???? >>>>>>>>> additional flag you could divide into commonHelp and >> ???? >>>>>>>>> commonHelpWithRemote for the tools and they both call the >> ???? >>>>>>>>> current commonHelp with that boolean; so that when we are >> ???? >>>>>>>>> looking at the tool code we know what we are getting... So >> ???? >>>>>>>>> something like: >> ???? >>>>>>>>> >> ???? >>>>>>>>> private static boolean commonHelp(String mode, boolean >> ???? >>>>>>>>> canConnectToRemote) { >> ???? >>>>>>>>> ???? .. >> ???? >>>>>>>>> ? } >> ???? >>>>>>>>> >> ???? >>>>>>>>> private static boolean commonHelp(String mode) { >> ???? >>>>>>>>> ??? return commonHelp(mode, false); >> ???? >>>>>>>>> } >> ???? >>>>>>>>> >> ???? >>>>>>>>> private static boolean commonHelpWithRemote(String mode) { >> ???? >>>>>>>>> ??? return commonHelp(mode, false); >> ???? >>>>>>>>> } >> ???? >>>>>>>>> >> ???? >>>>>>>>> and that way the tools that change are just going from: >> ???? >>>>>>>>> -??????? return commonHelp("jmap"); >> ???? >>>>>>>>> +??????? return commonHelpWithRemote("jmap"); >> ???? >>>>>>>>> >> ???? >>>>>>>>> - In the same vein, instead of passing null to the >> ???? >>>>>>>>> buildAttachArgs; you could? make a variable null: >> ???? >>>>>>>>> >> ???? >>>>>>>>> -??????? buildAttachArgs(newArgs, pid, exe, core, true); >> ???? >>>>>>>>> +??????? String noRemote = null; >> ???? >>>>>>>>> +??????? buildAttachArgs(newArgs, pid, exe, core, noRemote, >> ???? >>>>>>>>> true); >> ???? >>>>>>>>> >> ???? >>>>>>>>> >> ???? >>>>>>>>> >> ??? -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >> >> ???? >>>>>>>>> >> ???? >>>>>>>>> ??? Nit: you have empty lines at l64 and l73 >> ???? >>>>>>>>> >> ???? >>>>>>>>> >> ??? -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >> >> ???? >>>>>>>>> >> ???? >>>>>>>>> ???? Nit : you have an empty line at l110 >> ???? >>>>>>>>> >> ???? >>>>>>>>> ??? - In runTests; if DebugdUtils implemented Closeable, you >> ???? >>>>>>>>> could just do a try-with-resources instead of the finally >> ???? >>>>>>>>> clause... >> ???? >>>>>>>>> >> ???? >>>>>>>>> All of these are details, I just thought I'd mention them :) >> ???? >>>>>>>>> Jc >> ???? >>>>>>>>> >> ???? >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa >> ???? >>>>>>>>> Suenaga> ??? wrote: >> ???? >>>>>>>>>> PING: Could you review them? >> ???? >>>>>>>>>> >> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >> ???? >>>>>>>>>>> >> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>> CSR status is provisional. So I need reviewers both CSR and >> ???? >>>>>>>>>> webrev. >> ???? >>>>>>>>>> >> ???? >>>>>>>>>> >> ???? >>>>>>>>>> Thanks, >> ???? >>>>>>>>>> >> ???? >>>>>>>>>> Yasumasa >> ???? >>>>>>>>>> >> ???? >>>>>>>>>> >> ???? >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa >> ??? Suenaga>: >> ???? >>>>>>>>>>> Hi all, >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>>> Please review this change: >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >> ???? >>>>>>>>>>> >> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can >> ???? >>>>>>>>>>> connect to >> ???? >>>>>>>>>>> debug server (jsadebugd). However it has not done so since >> ???? >>>>>>>>>>> JDK 9 because >> ???? >>>>>>>>>>> jhsdb cannot accept the attach request to debug server. >> ???? >>>>>>>>>>> So I want to introduce new option `--remote` to connect to >> ???? >>>>>>>>>>> debug server. >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>>> I created CSR for this issue. So please review it together. >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>>> Thanks, >> ???? >>>>>>>>>>> >> ???? >>>>>>>>>>> Yasumasa >> ???? >>>>>>>>> >> ???? >>>>>>>>> -- >> ???? >>>>>>>>> >> ???? >>>>>>>>> Thanks, >> ???? >>>>>>>>> Jc >> ???? >>>>> >> ???? >>> >> ???? > >> From andrew_m_leonard at uk.ibm.com Mon Jun 17 10:14:23 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 17 Jun 2019 11:14:23 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: Thanks for the feedback Alan. I think i'm going to have to defer on this issue for the moment, as I dont' have enough experience with JDI usecases to accurately study this at the moment. I think you have also demonstrated my "rustiness" in thread-safety issues, I think I will go and brush up!! Should we create a separate bug to update the spec/doc to clarify the position on JDI Connectors being non-thread-safe, or is the current non-statement the normal stance on this one? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alan Bateman To: Andrew Leonard Cc: serviceability-dev at openjdk.java.net Date: 14/06/2019 17:06 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners On 14/06/2019 15:52, Andrew Leonard wrote: In doing the recent changes I applied knowledge of how the ConnectorImpl and its defaultArguments are used to decide on what is necessary from a threading perspective. I also am only considering the "listening" concurrency issue, at this stage, and was not considering making all the jdi classes thread-safe. Sure but default arguments exposed in the ListeningConnector API are mutable. It may be that debuggers and other tools aren't changing them but we can't say that the GenericListeningConnector and its implementations are safe for by use by concurrent threads without studying this further. Also the comments about changing fields to final are not optimizations, that are suggestions to allow GenericListeningConnector objects be safely published. -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jun 17 12:42:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Jun 2019 22:42:29 +1000 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: <1b56d28c-f0da-3b84-d6e0-5cd2f00501ef@gmail.com> References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> <0f945652-4de0-5d57-66e7-874464c10903@oracle.com> <1b56d28c-f0da-3b84-d6e0-5cd2f00501ef@gmail.com> Message-ID: Hi Yasumasa, On 17/06/2019 6:50 pm, Yasumasa Suenaga wrote: > Hi David, > > 8209790 is filed as a bug. I don't agree this is a "bug" - sorry. For this to be a bug there must be some specification of behaviour that the implementation is violating. Is that the case? To me this is missing functionality which makes it an enhancement. > According to [1], I think we can push the fix to jdk/jdk13. Does it > correct? > > I'm not sure which version (13 or 14) should be set on JBS before pushing. Just to clarify the process here, you don't want to set the "Fix Version" to 13 or 14 in JBS before pushing. That will be set based on the repo you push to. If you push to jdk/jdk it will be 14. If you push to jdk/jdk13 it will be 13. Any fix pushed to jdk/jdk13 will be "automatically" forward-ported to jdk/jdk and thus 14. David ----- > (Of course I will push it after the CSR is approved.) > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003051.html > > > On 2019/06/17 17:06, David Holmes wrote: >> Hi Yasumasa, >> >> On 17/06/2019 8:52 am, Yasumasa Suenaga wrote: >>> 2019?6?17?(?) 6:47 serguei.spitsyn at oracle.com >>> >> >: >>> >>> ??? Forgot to tell... >>> ??? This can be pushed only after the CSR is approved. >>> >>> >>> Sure! >>> And I will push it when I get second reviewer. >>> >>> BTW should I push this change to jdk/jdk? or push to jdk/jdk13 manually? >> >> JDK 13 has now entered RDP1 so if you want this to go into 13 it will >> need special approval: >> >> http://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process >> >> Otherwise push to jdk/jdk and it will be for JDK 14. >> >> Cheers, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> ??? Thanks, >>> ??? Serguei >>> >>> >>> ??? On 6/16/19 14:44, serguei.spitsyn at oracle.com >>> ??? wrote: >>> ???? > Hi Yasumasa, >>> ???? > >>> ???? > >>> ???? > On 6/16/19 07:22, Yasumasa Suenaga wrote: >>> ???? >> Hi Serguei, >>> ???? >> >>> ???? >> >>> One minor suggestion is to use the final field NO_REMOTE >>> instead >>> ???? >> >>> of null for initialization of the local variable "remote". >>> ???? >> >>> ???? >> I fixed it on new webrev. Could you check again? >>> ???? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ >>> ???? > >>> ???? > >>> ???? > It looks good. >>> ???? > Thanks you for the update! >>> ???? > >>> ???? >> >>> ???? >> >> IMHO refactoring should be worked on another issue. >>> ???? >> > >>> ???? >> > Agreed. >>> ???? >> >>> ???? >> I filed it to JBS: >>> ???? >> https://bugs.openjdk.java.net/browse/JDK-8226204 >>> ???? > >>> ???? > Thank you for filing the enhancement! >>> ???? > >>> ???? > Thanks. >>> ???? > Serguei >>> ???? > >>> ???? > >>> ???? >> Thanks, >>> ???? >> >>> ???? >> Yasumasa >>> ???? >> >>> ???? >> >>> ???? >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com >>> ??? wrote: >>> ???? >>> Hi Yasumasa, >>> ???? >>> >>> ???? >>> >>> ???? >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: >>> ???? >>>> Hi Serguei, >>> ???? >>>> >>> ???? >>>> Thank you for your comment! >>> ???? >>>> >>> ???? >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com >>> ??? wrote: >>> ???? >>>>> Hi Yasumasa, >>> ???? >>>>> >>> ???? >>>>> I've added myself as a reviewer, so you can finalize it now. >>> ???? >>>> >>> ???? >>>> I moved CSR to Finalized, and added a comment for your >>> question. >>> ???? >>> >>> ???? >>> Okay, thanks! >>> ???? >>> >>> ???? >>> >>> ???? >>>>> The fix looks pretty good to me. >>> ???? >>>>> >>> ???? >>>>> One minor suggestion is to use the final field NO_REMOTE >>> instead >>> ???? >>>>> of null for initialization of the local variable "remote". >>> ???? >>>> >>> ???? >>>> I will fix that. >>> ???? >>>> >>> ???? >>>> >>> ???? >>>>> Also just an observation that there is some room for option >>> ???? >>>>> processing refactoring. >>> ???? >>>> >>> ???? >>>> Your suggestion handles all options in one parser method. >>> ???? >>>> I concern it might be complex for option validation. >>> ???? >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not >>> allowed.) >>> ???? >>> >>> ???? >>> This concern is not valid as the list allowed options allowed >>> ??? for each >>> ???? >>> jhsdb sub-command is controlled with the longOpts argument. >>> ???? >>> >>> ???? >>> jmap has: >>> ???? >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", >>> "remote=", >>> ???? >>> ??????????????? "heap", "binaryheap", "dumpfile=", "histo", >>> ???? >>> "clstats", "finalizerinfo"}; >>> ???? >>> >>> ???? >>> but jstack has: >>> ???? >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", >>> "remote=", >>> ???? >>> "mixed", "locks"}; >>> ???? >>> >>> ???? >>>> IMHO refactoring should be worked on another issue. >>> ???? >>> >>> ???? >>> Agreed. >>> ???? >>> >>> ???? >>> >>> ???? >>>> If you are OK in above, I will upload new webrev. >>> ???? >>> >>> ???? >>> Yes, I'm Okay with it. >>> ???? >>> >>> ???? >>> >>> ???? >>> Thanks, >>> ???? >>> Serguei >>> ???? >>> >>> ???? >>> >>> ???? >>>> Thanks, >>> ???? >>>> >>> ???? >>>> Yasumasa >>> ???? >>>> >>> ???? >>>> >>> ???? >>>>> All the jhsdb sub-commands do execute similar loops like >>> this: >>> ???? >>>>> while((s = sg.next(null, longOpts)) != null) { >>> ???? >>>>> ???????? . . . >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> It can be moved into a separate method instead. >>> ???? >>>>> The longOpts can passed in arguments. >>> ???? >>>>> >>> ???? >>>>> It can be something like this: >>> ???? >>>>> >>> ???? >>>>> ???? private ArrayList processOptions(final String[] >>> ??? oldArgs, >>> ???? >>>>> ????????????????????????????????????????????? final String[] >>> ???? >>>>> longOpts, >>> ???? >>>>> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean >>> ??? allowEmpty) { >>> ???? >>>>> ???????? SAGetopt sg = new SAGetopt(oldArgs); >>> ???? >>>>> ???????? ArrayList newArgs = new ArrayList(); >>> ???? >>>>> >>> ???? >>>>> ???????? String pid = null; >>> ???? >>>>> ???????? String exe = null; >>> ???? >>>>> ???????? String core = null; >>> ???? >>>>> ???????? String s = null; >>> ???? >>>>> ???????? String dumpfile = null; >>> ???? >>>>> ???????? String remote = NO_REMOTE; >>> ???? >>>>> ???????? boolean requestHeapdump = false; >>> ???? >>>>> >>> ???? >>>>> ???????? while((s = sg.next(null, longOpts)) != null) { >>> ???? >>>>> ???????????? if (s.equals("exe")) { >>> ???? >>>>> ???????????????? exe = sg.getOptarg(); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("core")) { >>> ???? >>>>> ???????????????? core = sg.getOptarg(); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("pid")) { >>> ???? >>>>> ????????????????? pid = sg.getOptarg(); >>> ???? >>>>> ????????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("remote")) { >>> ???? >>>>> ???????????????? remote = sg.getOptarg(); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("mixed")) { >>> ???? >>>>> ???????????????? newArgs.add("-m"); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("locks")) { >>> ???? >>>>> ???????????????? newArgs.add("-l"); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("heap")) { >>> ???? >>>>> ???????????????? newArgs.add("-heap"); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("binaryheap")) { >>> ???? >>>>> ???????????????? requestHeapdump = true; >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("dumpfile")) { >>> ???? >>>>> ???????????????? dumpfile = sg.getOptarg(); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("histo")) { >>> ???? >>>>> ???????????????? newArgs.add("-histo"); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("clstats")) { >>> ???? >>>>> ???????????????? newArgs.add("-clstats"); >>> ???? >>>>> ????????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("finalizerinfo")) { >>> ???? >>>>> ???????????????? newArgs.add("-finalizerinfo"); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("flags")) { >>> ???? >>>>> ???????????????? newArgs.add("-flags"); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("sysprops")) { >>> ???? >>>>> ???????????????? newArgs.add("-sysprops"); >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????????? if (s.equals("serverid")) { >>> ???? >>>>> ???????????????? String serverid = sg.getOptarg(); >>> ???? >>>>> ???????????????? if (serverid != null) { >>> ???? >>>>> ???????????????????? newArgs.add(serverid); >>> ???? >>>>> ???????????????? } >>> ???? >>>>> ???????????????? continue; >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????? } >>> ???? >>>>> >>> ???? >>>>> ???????? if (!requestHeapdump && (dumpfile != null)) { >>> ???? >>>>> ???????????? throw new IllegalArgumentException("Unexpected >>> ???? >>>>> argument dumpfile"); >>> ???? >>>>> ???????? } >>> ???? >>>>> ???????? if (requestHeapdump) { >>> ???? >>>>> ???????????? if (dumpfile == null) { >>> ???? >>>>> ???????????????? newArgs.add("-heap:format=b"); >>> ???? >>>>> ???????????? } else { >>> ???? >>>>> ????????????????? newArgs.add("-heap:format=b,file=" + >>> dumpfile); >>> ???? >>>>> ???????????? } >>> ???? >>>>> ???????? } >>> ???? >>>>> ???????? buildAttachArgs(newArgs, pid, exe, core, remote, >>> ???? >>>>> allowEmpty); >>> ???? >>>>> >>> ???? >>>>> ???????? return newArgs; >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> ???? private static void runCLHSDB(String[] oldArgs) { >>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> ???? >>>>> longOpts, true); >>> ???? >>>>> >>> ???? >>>>> ???????? CLHSDB.main(newArgs.toArray(new >>> ??? String[newArgs.size()])); >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> ???? private static void runHSDB(String[] oldArgs) { >>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>> ???? >>>>> ????????? ArrayList newArgs = processOptions(oldArgs, >>> ???? >>>>> longOpts, true); >>> ???? >>>>> >>> ???? >>>>> ????????? HSDB.main(newArgs.toArray(new >>> String[newArgs.size()])); >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> ???? private static void runJSTACK(String[] oldArgs) { >>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>> ??? "remote=", >>> ???? >>>>> "mixed", "locks"}; >>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> ???? >>>>> longOpts, false); >>> ???? >>>>> >>> ???? >>>>> ???????? JStack jstack = new JStack(false, false); >>> ???? >>>>> ???????? jstack.runWithArgs(newArgs.toArray(new >>> ???? >>>>> String[newArgs.size()])); >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> ???? private static void runJMAP(String[] oldArgs) { >>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>> "remote=", >>> ???? >>>>> ?????????????? "heap", "binaryheap", "dumpfile=", "histo", >>> ???? >>>>> "clstats", "finalizerinfo"}; >>> ???? >>>>> >>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> ???? >>>>> longOpts, false); >>> ???? >>>>> >>> ???? >>>>> ???????? JMap.main(newArgs.toArray(new >>> String[newArgs.size()])); >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> ???? private static void runJINFO(String[] oldArgs) { >>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>> ??? "remote=", >>> ???? >>>>> "flags", "sysprops"}; >>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> ???? >>>>> longOpts, false); >>> ???? >>>>> >>> ???? >>>>> ???????? JInfo.main(newArgs.toArray(new >>> String[newArgs.size()])); >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> ???? private static void runJSNAP(String[] oldArgs) { >>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>> ??? "remote=", >>> ???? >>>>> "all"}; >>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> ???? >>>>> longOpts, false); >>> ???? >>>>> ???????? JSnap.main(newArgs.toArray(new >>> String[newArgs.size()])); >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> ???? private static void runDEBUGD(String[] oldArgs) { >>> ???? >>>>> ???????? // By default SA agent classes prefer Windows >>> process >>> ???? >>>>> debugger >>> ???? >>>>> ???????? // to windbg debugger. SA expects special >>> properties to >>> ???? >>>>> be set >>> ???? >>>>> ???????? // to choose other debuggers. We will set those here >>> ??? before >>> ???? >>>>> ???????? // attaching to SA agent. >>> ???? >>>>> >>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", >>> ???? >>>>> "true"); >>> ???? >>>>> >>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>> ??? "serverid="}; >>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>> ???? >>>>> longOpts, false); >>> ???? >>>>> >>> ???? >>>>> ???????? // delegate to the actual SA debug server. >>> ???? >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new >>> ???? >>>>> String[newArgs.size()])); >>> ???? >>>>> ???? } >>> ???? >>>>> >>> ???? >>>>> >>> ???? >>>>> Please, let me know what do you think. >>> ???? >>>>> >>> ???? >>>>> Thanks, >>> ???? >>>>> Serguei >>> ???? >>>>> >>> ???? >>>>> >>> ???? >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >>> ???? >>>>>> Sorry, new webrev is here: >>> ???? >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>> ???? >>>>>> >>> ???? >>>>>> Yasumasa >>> ???? >>>>>> >>> ???? >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga>> ??? >: >>> ???? >>>>>>> PING: Could you review them? >>> ???? >>>>>>> >>> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>> ???? >>>>>>>>>>> >>> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>> ???? >>>>>>>>>>> >>> ???? >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if >>> ??? possible. >>> ???? >>>>>>> >>> ???? >>>>>>> >>> ???? >>>>>>> Thanks, >>> ???? >>>>>>> >>> ???? >>>>>>> Yasumasa >>> ???? >>>>>>> >>> ???? >>>>>>> >>> ???? >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga>> ??? >: >>> ???? >>>>>>>> Hi Jc, >>> ???? >>>>>>>> >>> ???? >>>>>>>> Thank you for your comment! >>> ???? >>>>>>>> I updated a webrev: >>> ???? >>>>>>>> >>> ???? >>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>> ???? >>>>>>>> >>> ???? >>>>>>>>> ??? - In runTests; if DebugdUtils implemented >>> Closeable, you >>> ???? >>>>>>>>> could just do a try-with-resources instead of the finally >>> ???? >>>>>>>>> clause... >>> ???? >>>>>>>> I created DebugdUtils for convenience class for attach - >>> ??? detach >>> ???? >>>>>>>> mechanism of debug server. >>> ???? >>>>>>>> IMHO it is prefer "detach" to "close" in this case. >>> ???? >>>>>>>> >>> ???? >>>>>>>> >>> ???? >>>>>>>> Thanks, >>> ???? >>>>>>>> >>> ???? >>>>>>>> Yasumasa >>> ???? >>>>>>>> >>> ???? >>>>>>>> >>> ???? >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe >>> ??? Beyler>: >>> ???? >>>>>>>> >>> ???? >>>>>>>>> Hi Yasumasa, >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> I'm not an official reviewer but I don't see an issue >>> ??? with the >>> ???? >>>>>>>>> CSR (except that this seems to be bringing a fork in the >>> ??? tools >>> ???? >>>>>>>>> with some handling remote and others not). >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> However, this code is really repetitive and this is >>> not the >>> ???? >>>>>>>>> place to do a big refactor probably but we could do a few >>> ??? nits >>> ???? >>>>>>>>> perhaps: >>> ???? >>>>>>>>> ??? - Instead of every tool calling commonHelp with an >>> ???? >>>>>>>>> additional flag you could divide into commonHelp and >>> ???? >>>>>>>>> commonHelpWithRemote for the tools and they both call the >>> ???? >>>>>>>>> current commonHelp with that boolean; so that when we are >>> ???? >>>>>>>>> looking at the tool code we know what we are >>> getting... So >>> ???? >>>>>>>>> something like: >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> private static boolean commonHelp(String mode, boolean >>> ???? >>>>>>>>> canConnectToRemote) { >>> ???? >>>>>>>>> ???? .. >>> ???? >>>>>>>>> ? } >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> private static boolean commonHelp(String mode) { >>> ???? >>>>>>>>> ??? return commonHelp(mode, false); >>> ???? >>>>>>>>> } >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> private static boolean commonHelpWithRemote(String >>> mode) { >>> ???? >>>>>>>>> ??? return commonHelp(mode, false); >>> ???? >>>>>>>>> } >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> and that way the tools that change are just going from: >>> ???? >>>>>>>>> -??????? return commonHelp("jmap"); >>> ???? >>>>>>>>> +??????? return commonHelpWithRemote("jmap"); >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> - In the same vein, instead of passing null to the >>> ???? >>>>>>>>> buildAttachArgs; you could? make a variable null: >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> -??????? buildAttachArgs(newArgs, pid, exe, core, true); >>> ???? >>>>>>>>> +??????? String noRemote = null; >>> ???? >>>>>>>>> +??????? buildAttachArgs(newArgs, pid, exe, core, >>> noRemote, >>> ???? >>>>>>>>> true); >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> >>> >>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>> >>> >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> ??? Nit: you have empty lines at l64 and l73 >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> >>> >>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>> >>> >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> ???? Nit : you have an empty line at l110 >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> ??? - In runTests; if DebugdUtils implemented >>> Closeable, you >>> ???? >>>>>>>>> could just do a try-with-resources instead of the finally >>> ???? >>>>>>>>> clause... >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> All of these are details, I just thought I'd mention >>> them :) >>> ???? >>>>>>>>> Jc >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa >>> ???? >>>>>>>>> Suenaga>> > ??? wrote: >>> ???? >>>>>>>>>> PING: Could you review them? >>> ???? >>>>>>>>>> >>> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>> ???? >>>>>>>>>>> >>> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>> CSR status is provisional. So I need reviewers both >>> CSR and >>> ???? >>>>>>>>>> webrev. >>> ???? >>>>>>>>>> >>> ???? >>>>>>>>>> >>> ???? >>>>>>>>>> Thanks, >>> ???? >>>>>>>>>> >>> ???? >>>>>>>>>> Yasumasa >>> ???? >>>>>>>>>> >>> ???? >>>>>>>>>> >>> ???? >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa >>> ??? Suenaga>: >>> ???? >>>>>>>>>>> Hi all, >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>>> Please review this change: >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>> ???? >>>>>>>>>>> >>> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, >>> jinfo) can >>> ???? >>>>>>>>>>> connect to >>> ???? >>>>>>>>>>> debug server (jsadebugd). However it has not done so >>> since >>> ???? >>>>>>>>>>> JDK 9 because >>> ???? >>>>>>>>>>> jhsdb cannot accept the attach request to debug server. >>> ???? >>>>>>>>>>> So I want to introduce new option `--remote` to >>> connect to >>> ???? >>>>>>>>>>> debug server. >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>>> I created CSR for this issue. So please review it >>> together. >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>>> Thanks, >>> ???? >>>>>>>>>>> >>> ???? >>>>>>>>>>> Yasumasa >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> -- >>> ???? >>>>>>>>> >>> ???? >>>>>>>>> Thanks, >>> ???? >>>>>>>>> Jc >>> ???? >>>>> >>> ???? >>> >>> ???? > >>> From yasuenag at gmail.com Mon Jun 17 13:11:51 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 17 Jun 2019 22:11:51 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> <0f945652-4de0-5d57-66e7-874464c10903@oracle.com> <1b56d28c-f0da-3b84-d6e0-5cd2f00501ef@gmail.com> Message-ID: <690ab155-8b8d-9da7-5a9a-426148c0dd9f@gmail.com> Hi David, On 2019/06/17 21:42, David Holmes wrote: > Hi Yasumasa, > > On 17/06/2019 6:50 pm, Yasumasa Suenaga wrote: >> Hi David, >> >> 8209790 is filed as a bug. > > I don't agree this is a "bug" - sorry. For this to be a bug there must > be some specification of behaviour that the implementation is violating. > Is that the case? To me this is missing functionality which makes it an > enhancement. The feature for connecting to remote debug server has been provided JDK 8 or earlier. However it was missed since JDK 9. So I think we can handle it as a "bug". Anyway, I added jdk13-enhancement-request label to JBS. I'm waiting for the approval. >> According to [1], I think we can push the fix to jdk/jdk13. Does it >> correct? >> >> I'm not sure which version (13 or 14) should be set on JBS before >> pushing. > > Just to clarify the process here, you don't want to set the "Fix > Version" to 13 or 14 in JBS before pushing. That will be set based on > the repo you push to. If you push to jdk/jdk it will be 14. If you push > to jdk/jdk13 it will be 13. Any fix pushed to jdk/jdk13 will be > "automatically" forward-ported to jdk/jdk and thus 14. Thanks! I got it. Yasumasa > David > ----- > >> (Of course I will push it after the CSR is approved.) >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003051.html >> >> >> On 2019/06/17 17:06, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 17/06/2019 8:52 am, Yasumasa Suenaga wrote: >>>> 2019?6?17?(?) 6:47 serguei.spitsyn at oracle.com >>>> >>> >: >>>> >>>> ??? Forgot to tell... >>>> ??? This can be pushed only after the CSR is approved. >>>> >>>> >>>> Sure! >>>> And I will push it when I get second reviewer. >>>> >>>> BTW should I push this change to jdk/jdk? or push to jdk/jdk13 >>>> manually? >>> >>> JDK 13 has now entered RDP1 so if you want this to go into 13 it will >>> need special approval: >>> >>> http://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process >>> >>> Otherwise push to jdk/jdk and it will be for JDK 14. >>> >>> Cheers, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> ??? Thanks, >>>> ??? Serguei >>>> >>>> >>>> ??? On 6/16/19 14:44, serguei.spitsyn at oracle.com >>>> ??? wrote: >>>> ???? > Hi Yasumasa, >>>> ???? > >>>> ???? > >>>> ???? > On 6/16/19 07:22, Yasumasa Suenaga wrote: >>>> ???? >> Hi Serguei, >>>> ???? >> >>>> ???? >> >>> One minor suggestion is to use the final field NO_REMOTE >>>> instead >>>> ???? >> >>> of null for initialization of the local variable "remote". >>>> ???? >> >>>> ???? >> I fixed it on new webrev. Could you check again? >>>> ???? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ >>>> ???? > >>>> ???? > >>>> ???? > It looks good. >>>> ???? > Thanks you for the update! >>>> ???? > >>>> ???? >> >>>> ???? >> >> IMHO refactoring should be worked on another issue. >>>> ???? >> > >>>> ???? >> > Agreed. >>>> ???? >> >>>> ???? >> I filed it to JBS: >>>> ???? >> https://bugs.openjdk.java.net/browse/JDK-8226204 >>>> ???? > >>>> ???? > Thank you for filing the enhancement! >>>> ???? > >>>> ???? > Thanks. >>>> ???? > Serguei >>>> ???? > >>>> ???? > >>>> ???? >> Thanks, >>>> ???? >> >>>> ???? >> Yasumasa >>>> ???? >> >>>> ???? >> >>>> ???? >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com >>>> ??? wrote: >>>> ???? >>> Hi Yasumasa, >>>> ???? >>> >>>> ???? >>> >>>> ???? >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: >>>> ???? >>>> Hi Serguei, >>>> ???? >>>> >>>> ???? >>>> Thank you for your comment! >>>> ???? >>>> >>>> ???? >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com >>>> ??? wrote: >>>> ???? >>>>> Hi Yasumasa, >>>> ???? >>>>> >>>> ???? >>>>> I've added myself as a reviewer, so you can finalize it now. >>>> ???? >>>> >>>> ???? >>>> I moved CSR to Finalized, and added a comment for your >>>> question. >>>> ???? >>> >>>> ???? >>> Okay, thanks! >>>> ???? >>> >>>> ???? >>> >>>> ???? >>>>> The fix looks pretty good to me. >>>> ???? >>>>> >>>> ???? >>>>> One minor suggestion is to use the final field NO_REMOTE >>>> instead >>>> ???? >>>>> of null for initialization of the local variable "remote". >>>> ???? >>>> >>>> ???? >>>> I will fix that. >>>> ???? >>>> >>>> ???? >>>> >>>> ???? >>>>> Also just an observation that there is some room for option >>>> ???? >>>>> processing refactoring. >>>> ???? >>>> >>>> ???? >>>> Your suggestion handles all options in one parser method. >>>> ???? >>>> I concern it might be complex for option validation. >>>> ???? >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not >>>> allowed.) >>>> ???? >>> >>>> ???? >>> This concern is not valid as the list allowed options allowed >>>> ??? for each >>>> ???? >>> jhsdb sub-command is controlled with the longOpts argument. >>>> ???? >>> >>>> ???? >>> jmap has: >>>> ???? >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", >>>> "remote=", >>>> ???? >>> ??????????????? "heap", "binaryheap", "dumpfile=", "histo", >>>> ???? >>> "clstats", "finalizerinfo"}; >>>> ???? >>> >>>> ???? >>> but jstack has: >>>> ???? >>> ????????? String[] longOpts = {"exe=", "core=", "pid=", >>>> "remote=", >>>> ???? >>> "mixed", "locks"}; >>>> ???? >>> >>>> ???? >>>> IMHO refactoring should be worked on another issue. >>>> ???? >>> >>>> ???? >>> Agreed. >>>> ???? >>> >>>> ???? >>> >>>> ???? >>>> If you are OK in above, I will upload new webrev. >>>> ???? >>> >>>> ???? >>> Yes, I'm Okay with it. >>>> ???? >>> >>>> ???? >>> >>>> ???? >>> Thanks, >>>> ???? >>> Serguei >>>> ???? >>> >>>> ???? >>> >>>> ???? >>>> Thanks, >>>> ???? >>>> >>>> ???? >>>> Yasumasa >>>> ???? >>>> >>>> ???? >>>> >>>> ???? >>>>> All the jhsdb sub-commands do execute similar loops like >>>> this: >>>> ???? >>>>> while((s = sg.next(null, longOpts)) != null) { >>>> ???? >>>>> ???????? . . . >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> It can be moved into a separate method instead. >>>> ???? >>>>> The longOpts can passed in arguments. >>>> ???? >>>>> >>>> ???? >>>>> It can be something like this: >>>> ???? >>>>> >>>> ???? >>>>> ???? private ArrayList processOptions(final String[] >>>> ??? oldArgs, >>>> ???? >>>>> ????????????????????????????????????????????? final String[] >>>> ???? >>>>> longOpts, >>>> ???? >>>>> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? boolean >>>> ??? allowEmpty) { >>>> ???? >>>>> ???????? SAGetopt sg = new SAGetopt(oldArgs); >>>> ???? >>>>> ???????? ArrayList newArgs = new ArrayList(); >>>> ???? >>>>> >>>> ???? >>>>> ???????? String pid = null; >>>> ???? >>>>> ???????? String exe = null; >>>> ???? >>>>> ???????? String core = null; >>>> ???? >>>>> ???????? String s = null; >>>> ???? >>>>> ???????? String dumpfile = null; >>>> ???? >>>>> ???????? String remote = NO_REMOTE; >>>> ???? >>>>> ???????? boolean requestHeapdump = false; >>>> ???? >>>>> >>>> ???? >>>>> ???????? while((s = sg.next(null, longOpts)) != null) { >>>> ???? >>>>> ???????????? if (s.equals("exe")) { >>>> ???? >>>>> ???????????????? exe = sg.getOptarg(); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("core")) { >>>> ???? >>>>> ???????????????? core = sg.getOptarg(); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("pid")) { >>>> ???? >>>>> ????????????????? pid = sg.getOptarg(); >>>> ???? >>>>> ????????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("remote")) { >>>> ???? >>>>> ???????????????? remote = sg.getOptarg(); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("mixed")) { >>>> ???? >>>>> ???????????????? newArgs.add("-m"); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("locks")) { >>>> ???? >>>>> ???????????????? newArgs.add("-l"); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("heap")) { >>>> ???? >>>>> ???????????????? newArgs.add("-heap"); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("binaryheap")) { >>>> ???? >>>>> ???????????????? requestHeapdump = true; >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("dumpfile")) { >>>> ???? >>>>> ???????????????? dumpfile = sg.getOptarg(); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("histo")) { >>>> ???? >>>>> ???????????????? newArgs.add("-histo"); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("clstats")) { >>>> ???? >>>>> ???????????????? newArgs.add("-clstats"); >>>> ???? >>>>> ????????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("finalizerinfo")) { >>>> ???? >>>>> ???????????????? newArgs.add("-finalizerinfo"); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("flags")) { >>>> ???? >>>>> ???????????????? newArgs.add("-flags"); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("sysprops")) { >>>> ???? >>>>> ???????????????? newArgs.add("-sysprops"); >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????????? if (s.equals("serverid")) { >>>> ???? >>>>> ???????????????? String serverid = sg.getOptarg(); >>>> ???? >>>>> ???????????????? if (serverid != null) { >>>> ???? >>>>> ???????????????????? newArgs.add(serverid); >>>> ???? >>>>> ???????????????? } >>>> ???? >>>>> ???????????????? continue; >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????? } >>>> ???? >>>>> >>>> ???? >>>>> ???????? if (!requestHeapdump && (dumpfile != null)) { >>>> ???? >>>>> ???????????? throw new IllegalArgumentException("Unexpected >>>> ???? >>>>> argument dumpfile"); >>>> ???? >>>>> ???????? } >>>> ???? >>>>> ???????? if (requestHeapdump) { >>>> ???? >>>>> ???????????? if (dumpfile == null) { >>>> ???? >>>>> ???????????????? newArgs.add("-heap:format=b"); >>>> ???? >>>>> ???????????? } else { >>>> ???? >>>>> ????????????????? newArgs.add("-heap:format=b,file=" + >>>> dumpfile); >>>> ???? >>>>> ???????????? } >>>> ???? >>>>> ???????? } >>>> ???? >>>>> ???????? buildAttachArgs(newArgs, pid, exe, core, remote, >>>> ???? >>>>> allowEmpty); >>>> ???? >>>>> >>>> ???? >>>>> ???????? return newArgs; >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> ???? private static void runCLHSDB(String[] oldArgs) { >>>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> ???? >>>>> longOpts, true); >>>> ???? >>>>> >>>> ???? >>>>> ???????? CLHSDB.main(newArgs.toArray(new >>>> ??? String[newArgs.size()])); >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> ???? private static void runHSDB(String[] oldArgs) { >>>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid="}; >>>> ???? >>>>> ????????? ArrayList newArgs = >>>> processOptions(oldArgs, >>>> ???? >>>>> longOpts, true); >>>> ???? >>>>> >>>> ???? >>>>> ????????? HSDB.main(newArgs.toArray(new >>>> String[newArgs.size()])); >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> ???? private static void runJSTACK(String[] oldArgs) { >>>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>>> ??? "remote=", >>>> ???? >>>>> "mixed", "locks"}; >>>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> ???? >>>>> longOpts, false); >>>> ???? >>>>> >>>> ???? >>>>> ???????? JStack jstack = new JStack(false, false); >>>> ???? >>>>> ???????? jstack.runWithArgs(newArgs.toArray(new >>>> ???? >>>>> String[newArgs.size()])); >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> ???? private static void runJMAP(String[] oldArgs) { >>>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>>> "remote=", >>>> ???? >>>>> ?????????????? "heap", "binaryheap", "dumpfile=", "histo", >>>> ???? >>>>> "clstats", "finalizerinfo"}; >>>> ???? >>>>> >>>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> ???? >>>>> longOpts, false); >>>> ???? >>>>> >>>> ???? >>>>> ???????? JMap.main(newArgs.toArray(new >>>> String[newArgs.size()])); >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> ???? private static void runJINFO(String[] oldArgs) { >>>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>>> ??? "remote=", >>>> ???? >>>>> "flags", "sysprops"}; >>>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> ???? >>>>> longOpts, false); >>>> ???? >>>>> >>>> ???? >>>>> ???????? JInfo.main(newArgs.toArray(new >>>> String[newArgs.size()])); >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> ???? private static void runJSNAP(String[] oldArgs) { >>>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>>> ??? "remote=", >>>> ???? >>>>> "all"}; >>>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> ???? >>>>> longOpts, false); >>>> ???? >>>>> ???????? JSnap.main(newArgs.toArray(new >>>> String[newArgs.size()])); >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> ???? private static void runDEBUGD(String[] oldArgs) { >>>> ???? >>>>> ???????? // By default SA agent classes prefer Windows >>>> process >>>> ???? >>>>> debugger >>>> ???? >>>>> ???????? // to windbg debugger. SA expects special >>>> properties to >>>> ???? >>>>> be set >>>> ???? >>>>> ???????? // to choose other debuggers. We will set those >>>> here >>>> ??? before >>>> ???? >>>>> ???????? // attaching to SA agent. >>>> ???? >>>>> >>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", >>>> ???? >>>>> "true"); >>>> ???? >>>>> >>>> ???? >>>>> ???????? String[] longOpts = {"exe=", "core=", "pid=", >>>> ??? "serverid="}; >>>> ???? >>>>> ???????? ArrayList newArgs = processOptions(oldArgs, >>>> ???? >>>>> longOpts, false); >>>> ???? >>>>> >>>> ???? >>>>> ???????? // delegate to the actual SA debug server. >>>> ???? >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new >>>> ???? >>>>> String[newArgs.size()])); >>>> ???? >>>>> ???? } >>>> ???? >>>>> >>>> ???? >>>>> >>>> ???? >>>>> Please, let me know what do you think. >>>> ???? >>>>> >>>> ???? >>>>> Thanks, >>>> ???? >>>>> Serguei >>>> ???? >>>>> >>>> ???? >>>>> >>>> ???? >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >>>> ???? >>>>>> Sorry, new webrev is here: >>>> ???? >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>> ???? >>>>>> >>>> ???? >>>>>> Yasumasa >>>> ???? >>>>>> >>>> ???? >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga>>> ??? >: >>>> ???? >>>>>>> PING: Could you review them? >>>> ???? >>>>>>> >>>> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>> ???? >>>>>>>>>>> >>>> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if >>>> ??? possible. >>>> ???? >>>>>>> >>>> ???? >>>>>>> >>>> ???? >>>>>>> Thanks, >>>> ???? >>>>>>> >>>> ???? >>>>>>> Yasumasa >>>> ???? >>>>>>> >>>> ???? >>>>>>> >>>> ???? >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga>>> ??? >: >>>> ???? >>>>>>>> Hi Jc, >>>> ???? >>>>>>>> >>>> ???? >>>>>>>> Thank you for your comment! >>>> ???? >>>>>>>> I updated a webrev: >>>> ???? >>>>>>>> >>>> ???? >>>>>>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>> ???? >>>>>>>> >>>> ???? >>>>>>>>> ??? - In runTests; if DebugdUtils implemented >>>> Closeable, you >>>> ???? >>>>>>>>> could just do a try-with-resources instead of the >>>> finally >>>> ???? >>>>>>>>> clause... >>>> ???? >>>>>>>> I created DebugdUtils for convenience class for attach - >>>> ??? detach >>>> ???? >>>>>>>> mechanism of debug server. >>>> ???? >>>>>>>> IMHO it is prefer "detach" to "close" in this case. >>>> ???? >>>>>>>> >>>> ???? >>>>>>>> >>>> ???? >>>>>>>> Thanks, >>>> ???? >>>>>>>> >>>> ???? >>>>>>>> Yasumasa >>>> ???? >>>>>>>> >>>> ???? >>>>>>>> >>>> ???? >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe >>>> ??? Beyler>: >>>> ???? >>>>>>>> >>>> ???? >>>>>>>>> Hi Yasumasa, >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> I'm not an official reviewer but I don't see an issue >>>> ??? with the >>>> ???? >>>>>>>>> CSR (except that this seems to be bringing a fork in the >>>> ??? tools >>>> ???? >>>>>>>>> with some handling remote and others not). >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> However, this code is really repetitive and this is >>>> not the >>>> ???? >>>>>>>>> place to do a big refactor probably but we could do a >>>> few >>>> ??? nits >>>> ???? >>>>>>>>> perhaps: >>>> ???? >>>>>>>>> ??? - Instead of every tool calling commonHelp with an >>>> ???? >>>>>>>>> additional flag you could divide into commonHelp and >>>> ???? >>>>>>>>> commonHelpWithRemote for the tools and they both call >>>> the >>>> ???? >>>>>>>>> current commonHelp with that boolean; so that when we >>>> are >>>> ???? >>>>>>>>> looking at the tool code we know what we are >>>> getting... So >>>> ???? >>>>>>>>> something like: >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> private static boolean commonHelp(String mode, boolean >>>> ???? >>>>>>>>> canConnectToRemote) { >>>> ???? >>>>>>>>> ???? .. >>>> ???? >>>>>>>>> ? } >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> private static boolean commonHelp(String mode) { >>>> ???? >>>>>>>>> ??? return commonHelp(mode, false); >>>> ???? >>>>>>>>> } >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> private static boolean commonHelpWithRemote(String >>>> mode) { >>>> ???? >>>>>>>>> ??? return commonHelp(mode, false); >>>> ???? >>>>>>>>> } >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> and that way the tools that change are just going from: >>>> ???? >>>>>>>>> -??????? return commonHelp("jmap"); >>>> ???? >>>>>>>>> +??????? return commonHelpWithRemote("jmap"); >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> - In the same vein, instead of passing null to the >>>> ???? >>>>>>>>> buildAttachArgs; you could? make a variable null: >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> -??????? buildAttachArgs(newArgs, pid, exe, core, true); >>>> ???? >>>>>>>>> +??????? String noRemote = null; >>>> ???? >>>>>>>>> +??????? buildAttachArgs(newArgs, pid, exe, core, >>>> noRemote, >>>> ???? >>>>>>>>> true); >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> >>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>>> >>>> >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> ??? Nit: you have empty lines at l64 and l73 >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> >>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>>> >>>> >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> ???? Nit : you have an empty line at l110 >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> ??? - In runTests; if DebugdUtils implemented >>>> Closeable, you >>>> ???? >>>>>>>>> could just do a try-with-resources instead of the >>>> finally >>>> ???? >>>>>>>>> clause... >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> All of these are details, I just thought I'd mention >>>> them :) >>>> ???? >>>>>>>>> Jc >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa >>>> ???? >>>>>>>>> Suenaga>>> > ??? wrote: >>>> ???? >>>>>>>>>> PING: Could you review them? >>>> ???? >>>>>>>>>> >>>> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>> ???? >>>>>>>>>>> >>>> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>> CSR status is provisional. So I need reviewers both >>>> CSR and >>>> ???? >>>>>>>>>> webrev. >>>> ???? >>>>>>>>>> >>>> ???? >>>>>>>>>> >>>> ???? >>>>>>>>>> Thanks, >>>> ???? >>>>>>>>>> >>>> ???? >>>>>>>>>> Yasumasa >>>> ???? >>>>>>>>>> >>>> ???? >>>>>>>>>> >>>> ???? >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa >>>> ??? Suenaga>: >>>> ???? >>>>>>>>>>> Hi all, >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>>> Please review this change: >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>> ???? >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>> ???? >>>>>>>>>>> >>>> ??? webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, >>>> jinfo) can >>>> ???? >>>>>>>>>>> connect to >>>> ???? >>>>>>>>>>> debug server (jsadebugd). However it has not done >>>> so since >>>> ???? >>>>>>>>>>> JDK 9 because >>>> ???? >>>>>>>>>>> jhsdb cannot accept the attach request to debug >>>> server. >>>> ???? >>>>>>>>>>> So I want to introduce new option `--remote` to >>>> connect to >>>> ???? >>>>>>>>>>> debug server. >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>>> I created CSR for this issue. So please review it >>>> together. >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>>> Thanks, >>>> ???? >>>>>>>>>>> >>>> ???? >>>>>>>>>>> Yasumasa >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> -- >>>> ???? >>>>>>>>> >>>> ???? >>>>>>>>> Thanks, >>>> ???? >>>>>>>>> Jc >>>> ???? >>>>> >>>> ???? >>> >>>> ???? > >>>> From andrew_m_leonard at uk.ibm.com Mon Jun 17 15:12:47 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 17 Jun 2019 16:12:47 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: I'm going to persevere with this a bit more.. but first I need to better understand "safe publication" Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Alan Bateman To: Andrew Leonard Cc: serviceability-dev at openjdk.java.net Date: 14/06/2019 17:06 Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners On 14/06/2019 15:52, Andrew Leonard wrote: In doing the recent changes I applied knowledge of how the ConnectorImpl and its defaultArguments are used to decide on what is necessary from a threading perspective. I also am only considering the "listening" concurrency issue, at this stage, and was not considering making all the jdi classes thread-safe. Sure but default arguments exposed in the ListeningConnector API are mutable. It may be that debuggers and other tools aren't changing them but we can't say that the GenericListeningConnector and its implementations are safe for by use by concurrent threads without studying this further. Also the comments about changing fields to final are not optimizations, that are suggestions to allow GenericListeningConnector objects be safely published. -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jun 17 16:24:55 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Jun 2019 17:24:55 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners In-Reply-To: References: <4e819a09-5bc8-155c-e14f-79943fe0bd6e@oracle.com> Message-ID: <65486ac0-18ad-5c06-cd8f-f959125678f9@oracle.com> On 17/06/2019 11:14, Andrew Leonard wrote: > Thanks for the feedback Alan. I think i'm going to have to defer on > this issue for the moment, as I dont' have enough experience with JDI > usecases to accurately study this at the moment. I think you have also > demonstrated my "rustiness" in thread-safety issues, I think I will go > and brush up!! > > Should we create a separate bug to update the spec/doc to clarify the > position on JDI Connectors being non-thread-safe, or is the current > non-statement the normal stance on this one? It wouldn't do any harm to add something to the javadoc to make it clear that Connectors are not safe for use by multiple concurrent threads and so need appropriate synchronization. There are "Thread safety" sections in several classes and something similar wouldn't look out of place here. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Mon Jun 17 17:06:18 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 17 Jun 2019 10:06:18 -0700 Subject: 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: <3869968e-d72a-558b-cfbc-53c9c26fbda9@oracle.com> References: <22568DAE-30CC-411F-9BC3-5584D29CAFE6@oracle.com> <42e3d5b5-083c-f6b5-06df-2c1c9d41725e@oracle.com> <95BA7C8F-06D6-45BA-8856-14B5ADF0A596@oracle.com> <3869968e-d72a-558b-cfbc-53c9c26fbda9@oracle.com> Message-ID: Thank you, David, Serguei and Alex, for reviewing this change! Best regards, --Daniil ?On 6/16/19, 6:15 AM, "David Holmes" wrote: On 15/06/2019 10:06 am, Daniil Titov wrote: > Hi Serguei, > > The discovery was made by David Holmes. Thank you, David, a lot! :) Wish I'd spotted it the first time round. Fix looks good. Thanks, David > Best regards, > Daniil > > > > ?On 6/14/19, 5:01 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > Great discovery! > The fix looks good to me. > > Thanks, > Serguei > > > On 6/14/19 4:56 PM, Daniil Titov wrote: > > Please review the change that fixes an intermittent issue. > > > > The problem here is that a bitwise-AND (&) operator was used in the condition instead of a logical AND operator (&&). > > As a result pending_thread->is_thread_fully_suspended() is always evaluated regardless of the value of at_safepoint variable. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 > > > > Thanks! > > --Daniil > > > > > > > > From chris.plummer at oracle.com Mon Jun 17 18:33:41 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 17 Jun 2019 11:33:41 -0700 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> References: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> Message-ID: <4065e423-b6e6-74e9-0964-542c3b2cf37b@oracle.com> Looks good other than 1 minor nit. Please remove the blank line at 988. thanks, Chris On 6/16/19 7:30 AM, Yasumasa Suenaga wrote: > Hi Serguei, Chris, > > Thank you for your comment. > I uploaded new webrev. Could you review again? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.01/ > > I separated a function for handling prelinked library. > Also I added some comments for its process. > > > Thanks, > > Yasumasa > > > On 2019/06/15 3:48, Chris Plummer wrote: >> Hi Yasumasa, >> >> I think you should replace the embedded link with more of a textual >> description of where to look in the gdb source. >> >> I'd like to see some short comments. You have a few logical blocks of >> code that would greatly benefit from just one line saying what they >> are doing, especially the loop. >> >> thanks, >> >> Chris >> >> On 6/13/19 10:49 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ >>> >>> I attempted to open the core which is generated by RHEL 6, but it >>> could not . >>> >>> The OS which generated the core is set to enable prelink. >>> According to GDB implementation, load address of prelinked library >>> should be calculated by offset of link_map.l_ld and the address of >>> .dynamic section. >>> >>> >>> Thanks, >>> >>> Yasumasa >> >> From gary.adams at oracle.com Mon Jun 17 19:23:41 2019 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 17 Jun 2019 15:23:41 -0400 Subject: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor Message-ID: <5D07E8BD.4000302@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8224642 I may have a handle on what is going wrong with the TestJcmdSanity test and the bad file descriptor. A change made in April 2019 placed the input stream and reader within the same try with resources block. This has the effect of calling the SocketInputStream close method twice for each command processed. https://bugs.openjdk.java.net/browse/JDK-8222491 http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f The last set of tests in the TestJcmdSanity test attempts to process ~100 VM.version commands in a loop. Since the closes are handled when the objects are collected it may come at an inopportune time. I'm testing the fix below to ensure a second close becomes a noop. It may be better to revisit the earlier change that set up the double close calls. diff --git a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java --- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java +++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java @@ -233,7 +233,7 @@ * InputStream for the socket connection to get target VM */ private class SocketInputStream extends InputStream { - int s; + int s = -1; public SocketInputStream(int s) { this.s = s; @@ -261,7 +261,10 @@ } public void close() throws IOException { + if (s != -1) { VirtualMachineImpl.close(s); + s = -1; + } } } From chris.plummer at oracle.com Mon Jun 17 20:07:13 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 17 Jun 2019 13:07:13 -0700 Subject: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <5D07E8BD.4000302@oracle.com> References: <5D07E8BD.4000302@oracle.com> Message-ID: Yeah, I think if your double close check works, then the proper fix really should be to rework the original implementation of JDK-8222491 so no double close is done. Chris On 6/17/19 12:23 PM, Gary Adams wrote: > https://bugs.openjdk.java.net/browse/JDK-8224642 > > I may have a handle on what is going wrong with the > TestJcmdSanity test and the bad file descriptor. > > A change made in April 2019 placed the input stream and reader > within the same try with resources block. This has the effect of > calling the > SocketInputStream close method twice for each command processed. > > https://bugs.openjdk.java.net/browse/JDK-8222491 > ? http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f > > The last set of tests in the TestJcmdSanity test attempts to process ~100 > VM.version commands in a loop. Since the closes are handled > when the objects are collected it may come at an inopportune time. > > I'm testing the fix below to ensure a second close becomes a noop. > It may be better to revisit the earlier change that set up the double > close calls. > > diff --git > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > --- > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > +++ > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -233,7 +233,7 @@ > ????? * InputStream for the socket connection to get target VM > ????? */ > ???? private class SocketInputStream extends InputStream { > -??????? int s; > +??????? int s = -1; > > ???????? public SocketInputStream(int s) { > ???????????? this.s = s; > @@ -261,7 +261,10 @@ > ???????? } > > ???????? public void close() throws IOException { > +??????????? if (s != -1) { > ???????????? VirtualMachineImpl.close(s); > +??????????????? s = -1; > +??????????? } > ???????? } > ???? } From yasuenag at gmail.com Mon Jun 17 22:36:21 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 18 Jun 2019 07:36:21 +0900 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: <4065e423-b6e6-74e9-0964-542c3b2cf37b@oracle.com> References: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> <4065e423-b6e6-74e9-0964-542c3b2cf37b@oracle.com> Message-ID: On 2019/06/18 3:33, Chris Plummer wrote: > Looks good other than 1 minor nit. Please remove the blank line at 988. I removed it in new webrev. Could you check again? http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.02/ Thanks, Yasumasa > thanks, > > Chris > > On 6/16/19 7:30 AM, Yasumasa Suenaga wrote: >> Hi Serguei, Chris, >> >> Thank you for your comment. >> I uploaded new webrev. Could you review again? >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.01/ >> >> I separated a function for handling prelinked library. >> Also I added some comments for its process. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/06/15 3:48, Chris Plummer wrote: >>> Hi Yasumasa, >>> >>> I think you should replace the embedded link with more of a textual >>> description of where to look in the gdb source. >>> >>> I'd like to see some short comments. You have a few logical blocks of >>> code that would greatly benefit from just one line saying what they >>> are doing, especially the loop. >>> >>> thanks, >>> >>> Chris >>> >>> On 6/13/19 10:49 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 >>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ >>>> >>>> I attempted to open the core which is generated by RHEL 6, but it >>>> could not . >>>> >>>> The OS which generated the core is set to enable prelink. >>>> According to GDB implementation, load address of prelinked library >>>> should be calculated by offset of link_map.l_ld and the address of >>>> .dynamic section. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>> >>> > > From serguei.spitsyn at oracle.com Mon Jun 17 22:49:05 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 17 Jun 2019 15:49:05 -0700 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: References: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> <4065e423-b6e6-74e9-0964-542c3b2cf37b@oracle.com> Message-ID: <4e112604-c487-e271-a8bc-1ed137195d85@oracle.com> Hi Yasumasa, I don't think, this needs another review round. Thanks, Serguei On 6/17/19 15:36, Yasumasa Suenaga wrote: > On 2019/06/18 3:33, Chris Plummer wrote: >> Looks good other than 1 minor nit. Please remove the blank line at 988. > > I removed it in new webrev. Could you check again? > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.02/ > > > Thanks, > > Yasumasa > > >> thanks, >> >> Chris >> >> On 6/16/19 7:30 AM, Yasumasa Suenaga wrote: >>> Hi Serguei, Chris, >>> >>> Thank you for your comment. >>> I uploaded new webrev. Could you review again? >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.01/ >>> >>> I separated a function for handling prelinked library. >>> Also I added some comments for its process. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/06/15 3:48, Chris Plummer wrote: >>>> Hi Yasumasa, >>>> >>>> I think you should replace the embedded link with more of a textual >>>> description of where to look in the gdb source. >>>> >>>> I'd like to see some short comments. You have a few logical blocks >>>> of code that would greatly benefit from just one line saying what >>>> they are doing, especially the loop. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 6/13/19 10:49 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 >>>>> ?? webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ >>>>> >>>>> I attempted to open the core which is generated by RHEL 6, but it >>>>> could not . >>>>> >>>>> The OS which generated the core is set to enable prelink. >>>>> According to GDB implementation, load address of prelinked library >>>>> should be calculated by offset of link_map.l_ld and the address of >>>>> .dynamic section. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>> >>>> >> >> From yasuenag at gmail.com Mon Jun 17 23:07:31 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 18 Jun 2019 08:07:31 +0900 Subject: RFR: 8225636: SA can't handle prelinked libraries In-Reply-To: <4e112604-c487-e271-a8bc-1ed137195d85@oracle.com> References: <8e00ab24-9291-6b82-afb5-00b1d619fc92@gmail.com> <4065e423-b6e6-74e9-0964-542c3b2cf37b@oracle.com> <4e112604-c487-e271-a8bc-1ed137195d85@oracle.com> Message-ID: Thanks Serguei, I will push the fix to jdk/jdk later. Yasumasa 2019?6?18?(?) 7:49 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > I don't think, this needs another review round. > > Thanks, > Serguei > > On 6/17/19 15:36, Yasumasa Suenaga wrote: > > On 2019/06/18 3:33, Chris Plummer wrote: > >> Looks good other than 1 minor nit. Please remove the blank line at 988. > > > > I removed it in new webrev. Could you check again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.02/ > > > > > > Thanks, > > > > Yasumasa > > > > > >> thanks, > >> > >> Chris > >> > >> On 6/16/19 7:30 AM, Yasumasa Suenaga wrote: > >>> Hi Serguei, Chris, > >>> > >>> Thank you for your comment. > >>> I uploaded new webrev. Could you review again? > >>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.01/ > >>> > >>> I separated a function for handling prelinked library. > >>> Also I added some comments for its process. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>> On 2019/06/15 3:48, Chris Plummer wrote: > >>>> Hi Yasumasa, > >>>> > >>>> I think you should replace the embedded link with more of a textual > >>>> description of where to look in the gdb source. > >>>> > >>>> I'd like to see some short comments. You have a few logical blocks > >>>> of code that would greatly benefit from just one line saying what > >>>> they are doing, especially the loop. > >>>> > >>>> thanks, > >>>> > >>>> Chris > >>>> > >>>> On 6/13/19 10:49 PM, Yasumasa Suenaga wrote: > >>>>> Hi all, > >>>>> > >>>>> Please review this change: > >>>>> > >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8225636 > >>>>> webrev: > >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8225636/webrev.00/ > >>>>> > >>>>> I attempted to open the core which is generated by RHEL 6, but it > >>>>> could not . > >>>>> > >>>>> The OS which generated the core is set to enable prelink. > >>>>> According to GDB implementation, load address of prelinked library > >>>>> should be calculated by offset of link_map.l_ld and the address of > >>>>> .dynamic section. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>> > >>>> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Tue Jun 18 10:07:51 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 18 Jun 2019 06:07:51 -0400 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <5D07E8BD.4000302@oracle.com> References: <5D07E8BD.4000302@oracle.com> Message-ID: <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> The workaround below passed 1000 testruns on linux-x64-debug. A more localized fix simply moves the stream reader out of the try with resources, so only one close is applied to the underlying socket. I'll run this test through 1000 testruns today. Looking for a final review for this change. diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java @@ -122,8 +122,8 @@ ???????????? if (line.trim().equals("stop")) { ???????????????? break; ???????????? } -??????????? try (InputStream in = hvm.executeJCmd(line); -???????????????? InputStreamReader isr = new InputStreamReader(in, "UTF-8")) { +??????????? try (InputStream in = hvm.executeJCmd(line)) { +??????????????? InputStreamReader isr = new InputStreamReader(in, "UTF-8"); ???????????????? // read to EOF and just print output ???????????????? char c[] = new char[256]; ???????????????? int n; On 6/17/19 3:23 PM, Gary Adams wrote: > https://bugs.openjdk.java.net/browse/JDK-8224642 > > I may have a handle on what is going wrong with the > TestJcmdSanity test and the bad file descriptor. > > A change made in April 2019 placed the input stream and reader > within the same try with resources block. This has the effect of > calling the > SocketInputStream close method twice for each command processed. > > https://bugs.openjdk.java.net/browse/JDK-8222491 > ? http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f > > The last set of tests in the TestJcmdSanity test attempts to process ~100 > VM.version commands in a loop. Since the closes are handled > when the objects are collected it may come at an inopportune time. > > I'm testing the fix below to ensure a second close becomes a noop. > It may be better to revisit the earlier change that set up the double > close calls. > > diff --git > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > --- > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > +++ > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -233,7 +233,7 @@ > ????? * InputStream for the socket connection to get target VM > ????? */ > ???? private class SocketInputStream extends InputStream { > -??????? int s; > +??????? int s = -1; > > ???????? public SocketInputStream(int s) { > ???????????? this.s = s; > @@ -261,7 +261,10 @@ > ???????? } > > ???????? public void close() throws IOException { > +??????????? if (s != -1) { > ???????????? VirtualMachineImpl.close(s); > +??????????????? s = -1; > +??????????? } > ???????? } > ???? } From ralf.schmelter at sap.com Tue Jun 18 10:34:17 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 18 Jun 2019 10:34:17 +0000 Subject: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: References: <5D07E8BD.4000302@oracle.com> Message-ID: Hi, since InputStream imeplements Closeable, calling close multiple times *must* work: public interface Closeable extends AutoCloseable { /** * Closes this stream and releases any system resources associated * with it. If the stream is already closed then invoking this * method has no effect. * *

As noted in {@link AutoCloseable#close()}, cases where the * close may fail require careful attention. It is strongly advised * to relinquish the underlying resources and to internally * mark the {@code Closeable} as closed, prior to throwing * the {@code IOException}. * * @throws IOException if an I/O error occurs */ public void close() throws IOException; } So the close() method must be fixed in the same way FileInputStream and friends implement close(). Best regards, Ralf From gary.adams at oracle.com Tue Jun 18 11:01:49 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 18 Jun 2019 07:01:49 -0400 Subject: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: References: <5D07E8BD.4000302@oracle.com> Message-ID: So you prefer the fix in VirtualMachineImpl SocketInputStream close() rather than the JCmd try with resources. If we were dealing with output streams, it would be important to apply the flush to the writer. Since these are input streams we just need to guard against the duplicate close for the native resource. On 6/18/19 6:34 AM, Schmelter, Ralf wrote: > Hi, > > since InputStream imeplements Closeable, calling close multiple times *must* work: > > public interface Closeable extends AutoCloseable { > > /** > * Closes this stream and releases any system resources associated > * with it. If the stream is already closed then invoking this > * method has no effect. > * > *

As noted in {@link AutoCloseable#close()}, cases where the > * close may fail require careful attention. It is strongly advised > * to relinquish the underlying resources and to internally > * mark the {@code Closeable} as closed, prior to throwing > * the {@code IOException}. > * > * @throws IOException if an I/O error occurs > */ > public void close() throws IOException; > } > > So the close() method must be fixed in the same way FileInputStream and friends implement close(). > > Best regards, > Ralf From ralf.schmelter at sap.com Tue Jun 18 11:31:15 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 18 Jun 2019 11:31:15 +0000 Subject: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: References: <5D07E8BD.4000302@oracle.com> Message-ID: Hi, > So you prefer the fix in VirtualMachineImpl SocketInputStream close() > rather than the JCmd try with resources. Yes, since the close() method is not spec conform. I think it is better to fix it than to adjust the code using it. Especially if you consider that the current behavior could be used to 'steal' a file descriptor. Best regards, Ralf From ralf.schmelter at sap.com Tue Jun 18 11:56:05 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 18 Jun 2019 11:56:05 +0000 Subject: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: References: <5D07E8BD.4000302@oracle.com> Message-ID: Hi, looking at the source code, all Unix variants use the same unsafe code in the close method of the returned InputStream. On Windows there is already a check, but it is not synchronized. Best regards, Ralf From christoph.langer at sap.com Wed Jun 19 06:36:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Jun 2019 06:36:27 +0000 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> Message-ID: Hi Gary, I think overall it would be better to fix the InputStream to be tolerant to multiple calls to close, as Ralf pointed out. Maybe someone else on some other place runs into this again because he/she relies on the correct implementation of Closeable. However, as a quick fix I can also imagine to do use a single resource like this: try (InputStreamReader isr = new InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { Then we'd also have a single close call per instance. But if you do that, you should at least open a bug to track fixing of the InputStream implementation... Best regards Christoph > -----Original Message----- > From: serviceability-dev On > Behalf Of gary.adams at oracle.com > Sent: Dienstag, 18. Juni 2019 12:08 > To: OpenJDK Serviceability > Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: > Bad file descriptor > > The workaround below passed 1000 testruns on linux-x64-debug. > > A more localized fix simply moves the stream reader out of the > try with resources, so only one close is applied to the underlying > socket. I'll run this test through 1000 testruns today. > > Looking for a final review for this change. > > diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > @@ -122,8 +122,8 @@ > ???????????? if (line.trim().equals("stop")) { > ???????????????? break; > ???????????? } > -??????????? try (InputStream in = hvm.executeJCmd(line); > -???????????????? InputStreamReader isr = new InputStreamReader(in, > "UTF-8")) { > +??????????? try (InputStream in = hvm.executeJCmd(line)) { > +??????????????? InputStreamReader isr = new InputStreamReader(in, "UTF-8"); > ???????????????? // read to EOF and just print output > ???????????????? char c[] = new char[256]; > ???????????????? int n; > > On 6/17/19 3:23 PM, Gary Adams wrote: > > https://bugs.openjdk.java.net/browse/JDK-8224642 > > > > I may have a handle on what is going wrong with the > > TestJcmdSanity test and the bad file descriptor. > > > > A change made in April 2019 placed the input stream and reader > > within the same try with resources block. This has the effect of > > calling the > > SocketInputStream close method twice for each command processed. > > > > https://bugs.openjdk.java.net/browse/JDK-8222491 > > ? http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f > > > > The last set of tests in the TestJcmdSanity test attempts to process ~100 > > VM.version commands in a loop. Since the closes are handled > > when the objects are collected it may come at an inopportune time. > > > > I'm testing the fix below to ensure a second close becomes a noop. > > It may be better to revisit the earlier change that set up the double > > close calls. > > > > diff --git > > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > > --- > > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > > +++ > > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > > @@ -233,7 +233,7 @@ > > ????? * InputStream for the socket connection to get target VM > > ????? */ > > ???? private class SocketInputStream extends InputStream { > > -??????? int s; > > +??????? int s = -1; > > > > ???????? public SocketInputStream(int s) { > > ???????????? this.s = s; > > @@ -261,7 +261,10 @@ > > ???????? } > > > > ???????? public void close() throws IOException { > > +??????????? if (s != -1) { > > ???????????? VirtualMachineImpl.close(s); > > +??????????????? s = -1; > > +??????????? } > > ???????? } > > ???? } From gary.adams at oracle.com Wed Jun 19 11:58:53 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 19 Jun 2019 07:58:53 -0400 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> Message-ID: <5D0A237D.9020106@oracle.com> I think everyone is in agreement now that preventing the double close is the best way to handle this failure. If there are no further comments, I'll push the attached patch on Thurs morning to the jdk/jdk repos. I'll also close JDK-8223361 as a duplicate. On 6/19/19, 2:36 AM, Langer, Christoph wrote: > Hi Gary, > > I think overall it would be better to fix the InputStream to be tolerant to multiple calls to close, as Ralf pointed out. Maybe someone else on some other place runs into this again because he/she relies on the correct implementation of Closeable. > > However, as a quick fix I can also imagine to do use a single resource like this: > > try (InputStreamReader isr = new InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { > > Then we'd also have a single close call per instance. > > But if you do that, you should at least open a bug to track fixing of the InputStream implementation... > > Best regards > Christoph > >> -----Original Message----- >> From: serviceability-dev On >> Behalf Of gary.adams at oracle.com >> Sent: Dienstag, 18. Juni 2019 12:08 >> To: OpenJDK Serviceability >> Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: >> Bad file descriptor >> >> The workaround below passed 1000 testruns on linux-x64-debug. >> >> A more localized fix simply moves the stream reader out of the >> try with resources, so only one close is applied to the underlying >> socket. I'll run this test through 1000 testruns today. >> >> Looking for a final review for this change. >> >> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >> @@ -122,8 +122,8 @@ >> if (line.trim().equals("stop")) { >> break; >> } >> - try (InputStream in = hvm.executeJCmd(line); >> - InputStreamReader isr = new InputStreamReader(in, >> "UTF-8")) { >> + try (InputStream in = hvm.executeJCmd(line)) { >> + InputStreamReader isr = new InputStreamReader(in, "UTF-8"); >> // read to EOF and just print output >> char c[] = new char[256]; >> int n; >> >> On 6/17/19 3:23 PM, Gary Adams wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8224642 >>> >>> I may have a handle on what is going wrong with the >>> TestJcmdSanity test and the bad file descriptor. >>> >>> A change made in April 2019 placed the input stream and reader >>> within the same try with resources block. This has the effect of >>> calling the >>> SocketInputStream close method twice for each command processed. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8222491 >>> http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f >>> >>> The last set of tests in the TestJcmdSanity test attempts to process ~100 >>> VM.version commands in a loop. Since the closes are handled >>> when the objects are collected it may come at an inopportune time. >>> >>> I'm testing the fix below to ensure a second close becomes a noop. >>> It may be better to revisit the earlier change that set up the double >>> close calls. >>> >>> diff --git >>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> --- >>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> +++ >>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> @@ -233,7 +233,7 @@ >>> * InputStream for the socket connection to get target VM >>> */ >>> private class SocketInputStream extends InputStream { >>> - int s; >>> + int s = -1; >>> >>> public SocketInputStream(int s) { >>> this.s = s; >>> @@ -261,7 +261,10 @@ >>> } >>> >>> public void close() throws IOException { >>> + if (s != -1) { >>> VirtualMachineImpl.close(s); >>> + s = -1; >>> + } >>> } >>> } -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8224642.patch URL: From christoph.langer at sap.com Wed Jun 19 12:14:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Jun 2019 12:14:44 +0000 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <5D0A237D.9020106@oracle.com> References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> <5D0A237D.9020106@oracle.com> Message-ID: Hi Gary, looks good overall. I however think the block should also be synchronized to avoid issues when multiple threads attempt to close the stream. Cheers Christoph > -----Original Message----- > From: Gary Adams > Sent: Mittwoch, 19. Juni 2019 13:59 > To: Langer, Christoph > Cc: OpenJDK Serviceability ; > Schmelter, Ralf > Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java > fails: Bad file descriptor > > I think everyone is in agreement now that preventing the double close > is the best way to handle this failure. If there are no further comments, > I'll push the attached patch on Thurs morning to the jdk/jdk repos. > > I'll also close JDK-8223361 as a duplicate. > > On 6/19/19, 2:36 AM, Langer, Christoph wrote: > > Hi Gary, > > > > I think overall it would be better to fix the InputStream to be tolerant to > multiple calls to close, as Ralf pointed out. Maybe someone else on some > other place runs into this again because he/she relies on the correct > implementation of Closeable. > > > > However, as a quick fix I can also imagine to do use a single resource like > this: > > > > try (InputStreamReader isr = new > InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { > > > > Then we'd also have a single close call per instance. > > > > But if you do that, you should at least open a bug to track fixing of the > InputStream implementation... > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: serviceability-dev > On > >> Behalf Of gary.adams at oracle.com > >> Sent: Dienstag, 18. Juni 2019 12:08 > >> To: OpenJDK Serviceability > >> Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: > >> Bad file descriptor > >> > >> The workaround below passed 1000 testruns on linux-x64-debug. > >> > >> A more localized fix simply moves the stream reader out of the > >> try with resources, so only one close is applied to the underlying > >> socket. I'll run this test through 1000 testruns today. > >> > >> Looking for a final review for this change. > >> > >> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >> @@ -122,8 +122,8 @@ > >> if (line.trim().equals("stop")) { > >> break; > >> } > >> - try (InputStream in = hvm.executeJCmd(line); > >> - InputStreamReader isr = new InputStreamReader(in, > >> "UTF-8")) { > >> + try (InputStream in = hvm.executeJCmd(line)) { > >> + InputStreamReader isr = new InputStreamReader(in, "UTF-8"); > >> // read to EOF and just print output > >> char c[] = new char[256]; > >> int n; > >> > >> On 6/17/19 3:23 PM, Gary Adams wrote: > >>> https://bugs.openjdk.java.net/browse/JDK-8224642 > >>> > >>> I may have a handle on what is going wrong with the > >>> TestJcmdSanity test and the bad file descriptor. > >>> > >>> A change made in April 2019 placed the input stream and reader > >>> within the same try with resources block. This has the effect of > >>> calling the > >>> SocketInputStream close method twice for each command processed. > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8222491 > >>> http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f > >>> > >>> The last set of tests in the TestJcmdSanity test attempts to process ~100 > >>> VM.version commands in a loop. Since the closes are handled > >>> when the objects are collected it may come at an inopportune time. > >>> > >>> I'm testing the fix below to ensure a second close becomes a noop. > >>> It may be better to revisit the earlier change that set up the double > >>> close calls. > >>> > >>> diff --git > >>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>> > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>> --- > >>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>> +++ > >>> > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>> @@ -233,7 +233,7 @@ > >>> * InputStream for the socket connection to get target VM > >>> */ > >>> private class SocketInputStream extends InputStream { > >>> - int s; > >>> + int s = -1; > >>> > >>> public SocketInputStream(int s) { > >>> this.s = s; > >>> @@ -261,7 +261,10 @@ > >>> } > >>> > >>> public void close() throws IOException { > >>> + if (s != -1) { > >>> VirtualMachineImpl.close(s); > >>> + s = -1; > >>> + } > >>> } > >>> } From gary.adams at oracle.com Wed Jun 19 14:31:43 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 19 Jun 2019 10:31:43 -0400 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> <5D0A237D.9020106@oracle.com> Message-ID: <5D0A474F.5090605@oracle.com> That would be consistent with the windows detach() synchronization. Updated patch is attached. On 6/19/19, 8:14 AM, Langer, Christoph wrote: > Hi Gary, > > looks good overall. I however think the block should also be synchronized to avoid issues when multiple threads attempt to close the stream. > > Cheers > Christoph > >> -----Original Message----- >> From: Gary Adams >> Sent: Mittwoch, 19. Juni 2019 13:59 >> To: Langer, Christoph >> Cc: OpenJDK Serviceability; >> Schmelter, Ralf >> Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java >> fails: Bad file descriptor >> >> I think everyone is in agreement now that preventing the double close >> is the best way to handle this failure. If there are no further comments, >> I'll push the attached patch on Thurs morning to the jdk/jdk repos. >> >> I'll also close JDK-8223361 as a duplicate. >> >> On 6/19/19, 2:36 AM, Langer, Christoph wrote: >>> Hi Gary, >>> >>> I think overall it would be better to fix the InputStream to be tolerant to >> multiple calls to close, as Ralf pointed out. Maybe someone else on some >> other place runs into this again because he/she relies on the correct >> implementation of Closeable. >>> However, as a quick fix I can also imagine to do use a single resource like >> this: >>> try (InputStreamReader isr = new >> InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { >>> Then we'd also have a single close call per instance. >>> >>> But if you do that, you should at least open a bug to track fixing of the >> InputStream implementation... >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: serviceability-dev >> On >>>> Behalf Of gary.adams at oracle.com >>>> Sent: Dienstag, 18. Juni 2019 12:08 >>>> To: OpenJDK Serviceability >>>> Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: >>>> Bad file descriptor >>>> >>>> The workaround below passed 1000 testruns on linux-x64-debug. >>>> >>>> A more localized fix simply moves the stream reader out of the >>>> try with resources, so only one close is applied to the underlying >>>> socket. I'll run this test through 1000 testruns today. >>>> >>>> Looking for a final review for this change. >>>> >>>> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>> @@ -122,8 +122,8 @@ >>>> if (line.trim().equals("stop")) { >>>> break; >>>> } >>>> - try (InputStream in = hvm.executeJCmd(line); >>>> - InputStreamReader isr = new InputStreamReader(in, >>>> "UTF-8")) { >>>> + try (InputStream in = hvm.executeJCmd(line)) { >>>> + InputStreamReader isr = new InputStreamReader(in, "UTF-8"); >>>> // read to EOF and just print output >>>> char c[] = new char[256]; >>>> int n; >>>> >>>> On 6/17/19 3:23 PM, Gary Adams wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8224642 >>>>> >>>>> I may have a handle on what is going wrong with the >>>>> TestJcmdSanity test and the bad file descriptor. >>>>> >>>>> A change made in April 2019 placed the input stream and reader >>>>> within the same try with resources block. This has the effect of >>>>> calling the >>>>> SocketInputStream close method twice for each command processed. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8222491 >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f >>>>> >>>>> The last set of tests in the TestJcmdSanity test attempts to process ~100 >>>>> VM.version commands in a loop. Since the closes are handled >>>>> when the objects are collected it may come at an inopportune time. >>>>> >>>>> I'm testing the fix below to ensure a second close becomes a noop. >>>>> It may be better to revisit the earlier change that set up the double >>>>> close calls. >>>>> >>>>> diff --git >>>>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> >> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >>>>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> +++ >>>>> >> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> @@ -233,7 +233,7 @@ >>>>> * InputStream for the socket connection to get target VM >>>>> */ >>>>> private class SocketInputStream extends InputStream { >>>>> - int s; >>>>> + int s = -1; >>>>> >>>>> public SocketInputStream(int s) { >>>>> this.s = s; >>>>> @@ -261,7 +261,10 @@ >>>>> } >>>>> >>>>> public void close() throws IOException { >>>>> + if (s != -1) { >>>>> VirtualMachineImpl.close(s); >>>>> + s = -1; >>>>> + } >>>>> } >>>>> } -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8224642.patch URL: From nijiaben at perfma.com Wed Jun 19 16:26:29 2019 From: nijiaben at perfma.com (=?utf-8?B?bmlqaWFiZW4=?=) Date: Thu, 20 Jun 2019 00:26:29 +0800 Subject: A Bug about the JVM Attach mechanism Message-ID: Hi, All, There is a bug that has been discovered for a long time, but it has not been fixed. We usually use some shell scripts to clean up the /tmp directory. When we have executed a similar jstack command based on the attach mechanism, it will generate a .java_pidXXX socket file in the /tmp directory. Once this file is clean up, and then will not be attached anymore. The main reason is that once the Attach Listener thread is created, the file of ?/tmp/.java_pidXXX? will be created and the markup initialization is complete. If .java_pidXXX is cleaned up, it will not be created anymore and cannot be attached. bool AttachListener::is_init_trigger() { if (init_at_startup() || is_initialized()) { // initialized at startup or already initialized return false; } char fn[PATH_MAX+1]; sprintf(fn, ".attach_pid%d", os::current_process_id()); int ret; struct stat64 st; RESTARTABLE(::stat64(fn, &st), ret); if (ret == -1) { snprintf(fn, sizeof(fn), "%s/.attach_pid%d", os::get_temp_directory(), os::current_process_id()); RESTARTABLE(::stat64(fn, &st), ret); } if (ret == 0) { if (st.st_uid == geteuid()) { init(); // will create Attach Listener Thread return true; } } return false; } This bug has a big impact on troubleshooting some problems. Can it be fixed as soon as possible? Thanks, nijiaben @ PerfMa -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Jun 19 16:46:06 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 19 Jun 2019 09:46:06 -0700 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <5D0A474F.5090605@oracle.com> References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> <5D0A237D.9020106@oracle.com> <5D0A474F.5090605@oracle.com> Message-ID: <5ddacc51-97c0-4ed8-5952-f9fc9028aac1@oracle.com> Hi Gary, Is there a reason you've chosen an int flag rather than a boolean? Other than that the changes look fine. thanks, Chris On 6/19/19 7:31 AM, Gary Adams wrote: > That would be consistent with the windows detach() synchronization. > > Updated patch is attached. > > On 6/19/19, 8:14 AM, Langer, Christoph wrote: >> Hi Gary, >> >> looks good overall. I however think the block should also be >> synchronized to avoid issues when multiple threads attempt to close >> the stream. >> >> Cheers >> Christoph >> >>> -----Original Message----- >>> From: Gary Adams >>> Sent: Mittwoch, 19. Juni 2019 13:59 >>> To: Langer, Christoph >>> Cc: OpenJDK Serviceability; >>> Schmelter, Ralf >>> Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java >>> fails: Bad file descriptor >>> >>> I think everyone is in agreement now that preventing the double close >>> is the best way to handle this failure. If there are no further >>> comments, >>> I'll push the attached patch on Thurs morning to the jdk/jdk repos. >>> >>> I'll also close JDK-8223361 as a duplicate. >>> >>> On 6/19/19, 2:36 AM, Langer, Christoph wrote: >>>> Hi Gary, >>>> >>>> I think overall it would be better to fix the InputStream to be >>>> tolerant to >>> multiple calls to close, as Ralf pointed out. Maybe someone else on >>> some >>> other place runs into this again because he/she relies on the correct >>> implementation of Closeable. >>>> However, as a quick fix I can also imagine to do use a single >>>> resource like >>> this: >>>> try (InputStreamReader isr = new >>> InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { >>>> Then we'd also have a single close call per instance. >>>> >>>> But if you do that, you should at least open a bug to track fixing >>>> of the >>> InputStream implementation... >>>> Best regards >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: serviceability-dev >>> On >>>>> Behalf Of gary.adams at oracle.com >>>>> Sent: Dienstag, 18. Juni 2019 12:08 >>>>> To: OpenJDK Serviceability >>>>> Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java >>>>> fails: >>>>> Bad file descriptor >>>>> >>>>> The workaround below passed 1000 testruns on linux-x64-debug. >>>>> >>>>> A more localized fix simply moves the stream reader out of the >>>>> try with resources, so only one close is applied to the underlying >>>>> socket. I'll run this test through 1000 testruns today. >>>>> >>>>> Looking for a final review for this change. >>>>> >>>>> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>> @@ -122,8 +122,8 @@ >>>>> ??????????????? if (line.trim().equals("stop")) { >>>>> ??????????????????? break; >>>>> ??????????????? } >>>>> -??????????? try (InputStream in = hvm.executeJCmd(line); >>>>> -???????????????? InputStreamReader isr = new InputStreamReader(in, >>>>> "UTF-8")) { >>>>> +??????????? try (InputStream in = hvm.executeJCmd(line)) { >>>>> +??????????????? InputStreamReader isr = new InputStreamReader(in, >>>>> "UTF-8"); >>>>> ??????????????????? // read to EOF and just print output >>>>> ??????????????????? char c[] = new char[256]; >>>>> ??????????????????? int n; >>>>> >>>>> On 6/17/19 3:23 PM, Gary Adams wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8224642 >>>>>> >>>>>> I may have a handle on what is going wrong with the >>>>>> TestJcmdSanity test and the bad file descriptor. >>>>>> >>>>>> A change made in April 2019 placed the input stream and reader >>>>>> within the same try with resources block. This has the effect of >>>>>> calling the >>>>>> SocketInputStream close method twice for each command processed. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8222491 >>>>>> ??? http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f >>>>>> >>>>>> The last set of tests in the TestJcmdSanity test attempts to >>>>>> process ~100 >>>>>> VM.version commands in a loop. Since the closes are handled >>>>>> when the objects are collected it may come at an inopportune time. >>>>>> >>>>>> I'm testing the fix below to ensure a second close becomes a noop. >>>>>> It may be better to revisit the earlier change that set up the >>>>>> double >>>>>> close calls. >>>>>> >>>>>> diff --git >>>>>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> >>>>>> >>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>>>>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> >>>>>> +++ >>>>>> >>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> @@ -233,7 +233,7 @@ >>>>>> ??????? * InputStream for the socket connection to get target VM >>>>>> ??????? */ >>>>>> ?????? private class SocketInputStream extends InputStream { >>>>>> -??????? int s; >>>>>> +??????? int s = -1; >>>>>> >>>>>> ?????????? public SocketInputStream(int s) { >>>>>> ?????????????? this.s = s; >>>>>> @@ -261,7 +261,10 @@ >>>>>> ?????????? } >>>>>> >>>>>> ?????????? public void close() throws IOException { >>>>>> +??????????? if (s != -1) { >>>>>> ?????????????? VirtualMachineImpl.close(s); >>>>>> +??????????????? s = -1; >>>>>> +??????????? } >>>>>> ?????????? } >>>>>> ?????? } > From gary.adams at oracle.com Wed Jun 19 16:49:38 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 19 Jun 2019 12:49:38 -0400 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <5ddacc51-97c0-4ed8-5952-f9fc9028aac1@oracle.com> References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> <5D0A237D.9020106@oracle.com> <5D0A474F.5090605@oracle.com> <5ddacc51-97c0-4ed8-5952-f9fc9028aac1@oracle.com> Message-ID: <5D0A67A2.3040804@oracle.com> It is not a new flag. It is the socket fd. This aligns with the hPipe used in the windows impl. On 6/19/19, 12:46 PM, Chris Plummer wrote: > Hi Gary, > > Is there a reason you've chosen an int flag rather than a boolean? > Other than that the changes look fine. > > thanks, > > Chris > > On 6/19/19 7:31 AM, Gary Adams wrote: >> That would be consistent with the windows detach() synchronization. >> >> Updated patch is attached. >> >> On 6/19/19, 8:14 AM, Langer, Christoph wrote: >>> Hi Gary, >>> >>> looks good overall. I however think the block should also be >>> synchronized to avoid issues when multiple threads attempt to close >>> the stream. >>> >>> Cheers >>> Christoph >>> >>>> -----Original Message----- >>>> From: Gary Adams >>>> Sent: Mittwoch, 19. Juni 2019 13:59 >>>> To: Langer, Christoph >>>> Cc: OpenJDK Serviceability; >>>> Schmelter, Ralf >>>> Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java >>>> fails: Bad file descriptor >>>> >>>> I think everyone is in agreement now that preventing the double close >>>> is the best way to handle this failure. If there are no further >>>> comments, >>>> I'll push the attached patch on Thurs morning to the jdk/jdk repos. >>>> >>>> I'll also close JDK-8223361 as a duplicate. >>>> >>>> On 6/19/19, 2:36 AM, Langer, Christoph wrote: >>>>> Hi Gary, >>>>> >>>>> I think overall it would be better to fix the InputStream to be >>>>> tolerant to >>>> multiple calls to close, as Ralf pointed out. Maybe someone else on >>>> some >>>> other place runs into this again because he/she relies on the correct >>>> implementation of Closeable. >>>>> However, as a quick fix I can also imagine to do use a single >>>>> resource like >>>> this: >>>>> try (InputStreamReader isr = new >>>> InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { >>>>> Then we'd also have a single close call per instance. >>>>> >>>>> But if you do that, you should at least open a bug to track fixing >>>>> of the >>>> InputStream implementation... >>>>> Best regards >>>>> Christoph >>>>> >>>>>> -----Original Message----- >>>>>> From: >>>>>> serviceability-dev >>>> On >>>>>> Behalf Of gary.adams at oracle.com >>>>>> Sent: Dienstag, 18. Juni 2019 12:08 >>>>>> To: OpenJDK Serviceability >>>>>> Subject: RFR: JDK-8224642: Test >>>>>> sun/tools/jcmd/TestJcmdSanity.java fails: >>>>>> Bad file descriptor >>>>>> >>>>>> The workaround below passed 1000 testruns on linux-x64-debug. >>>>>> >>>>>> A more localized fix simply moves the stream reader out of the >>>>>> try with resources, so only one close is applied to the underlying >>>>>> socket. I'll run this test through 1000 testruns today. >>>>>> >>>>>> Looking for a final review for this change. >>>>>> >>>>>> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>> @@ -122,8 +122,8 @@ >>>>>> if (line.trim().equals("stop")) { >>>>>> break; >>>>>> } >>>>>> - try (InputStream in = hvm.executeJCmd(line); >>>>>> - InputStreamReader isr = new InputStreamReader(in, >>>>>> "UTF-8")) { >>>>>> + try (InputStream in = hvm.executeJCmd(line)) { >>>>>> + InputStreamReader isr = new >>>>>> InputStreamReader(in, "UTF-8"); >>>>>> // read to EOF and just print output >>>>>> char c[] = new char[256]; >>>>>> int n; >>>>>> >>>>>> On 6/17/19 3:23 PM, Gary Adams wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8224642 >>>>>>> >>>>>>> I may have a handle on what is going wrong with the >>>>>>> TestJcmdSanity test and the bad file descriptor. >>>>>>> >>>>>>> A change made in April 2019 placed the input stream and reader >>>>>>> within the same try with resources block. This has the effect of >>>>>>> calling the >>>>>>> SocketInputStream close method twice for each command processed. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222491 >>>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f >>>>>>> >>>>>>> The last set of tests in the TestJcmdSanity test attempts to >>>>>>> process ~100 >>>>>>> VM.version commands in a loop. Since the closes are handled >>>>>>> when the objects are collected it may come at an inopportune time. >>>>>>> >>>>>>> I'm testing the fix below to ensure a second close becomes a noop. >>>>>>> It may be better to revisit the earlier change that set up the >>>>>>> double >>>>>>> close calls. >>>>>>> >>>>>>> diff --git >>>>>>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>> >>>>>>> >>>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>> >>>>>>> --- >>>>>>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>> >>>>>>> +++ >>>>>>> >>>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>> >>>>>>> @@ -233,7 +233,7 @@ >>>>>>> * InputStream for the socket connection to get target VM >>>>>>> */ >>>>>>> private class SocketInputStream extends InputStream { >>>>>>> - int s; >>>>>>> + int s = -1; >>>>>>> >>>>>>> public SocketInputStream(int s) { >>>>>>> this.s = s; >>>>>>> @@ -261,7 +261,10 @@ >>>>>>> } >>>>>>> >>>>>>> public void close() throws IOException { >>>>>>> + if (s != -1) { >>>>>>> VirtualMachineImpl.close(s); >>>>>>> + s = -1; >>>>>>> + } >>>>>>> } >>>>>>> } >> > From chris.plummer at oracle.com Wed Jun 19 17:24:49 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 19 Jun 2019 10:24:49 -0700 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <5D0A67A2.3040804@oracle.com> References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> <5D0A237D.9020106@oracle.com> <5D0A474F.5090605@oracle.com> <5ddacc51-97c0-4ed8-5952-f9fc9028aac1@oracle.com> <5D0A67A2.3040804@oracle.com> Message-ID: <6f015437-8f04-ca83-1a27-da97acde298f@oracle.com> ok On 6/19/19 9:49 AM, Gary Adams wrote: > It is not a new flag. > It is the socket fd. > This aligns with the hPipe used in the windows impl. > > On 6/19/19, 12:46 PM, Chris Plummer wrote: >> Hi Gary, >> >> Is there a reason you've chosen an int flag rather than a boolean? >> Other than that the changes look fine. >> >> thanks, >> >> Chris >> >> On 6/19/19 7:31 AM, Gary Adams wrote: >>> That would be consistent with the windows detach() synchronization. >>> >>> Updated patch is attached. >>> >>> On 6/19/19, 8:14 AM, Langer, Christoph wrote: >>>> Hi Gary, >>>> >>>> looks good overall. I however think the block should also be >>>> synchronized to avoid issues when multiple threads attempt to close >>>> the stream. >>>> >>>> Cheers >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: Gary Adams >>>>> Sent: Mittwoch, 19. Juni 2019 13:59 >>>>> To: Langer, Christoph >>>>> Cc: OpenJDK Serviceability; >>>>> Schmelter, Ralf >>>>> Subject: Re: RFR: JDK-8224642: Test >>>>> sun/tools/jcmd/TestJcmdSanity.java >>>>> fails: Bad file descriptor >>>>> >>>>> I think everyone is in agreement now that preventing the double close >>>>> is the best way to handle this failure. If there are no further >>>>> comments, >>>>> I'll push the attached patch on Thurs morning to the jdk/jdk repos. >>>>> >>>>> I'll also close JDK-8223361 as a duplicate. >>>>> >>>>> On 6/19/19, 2:36 AM, Langer, Christoph wrote: >>>>>> Hi Gary, >>>>>> >>>>>> I think overall it would be better to fix the InputStream to be >>>>>> tolerant to >>>>> multiple calls to close, as Ralf pointed out. Maybe someone else >>>>> on some >>>>> other place runs into this again because he/she relies on the correct >>>>> implementation of Closeable. >>>>>> However, as a quick fix I can also imagine to do use a single >>>>>> resource like >>>>> this: >>>>>> try (InputStreamReader isr = new >>>>> InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { >>>>>> Then we'd also have a single close call per instance. >>>>>> >>>>>> But if you do that, you should at least open a bug to track >>>>>> fixing of the >>>>> InputStream implementation... >>>>>> Best regards >>>>>> Christoph >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: >>>>>>> serviceability-dev >>>>> On >>>>>>> Behalf Of gary.adams at oracle.com >>>>>>> Sent: Dienstag, 18. Juni 2019 12:08 >>>>>>> To: OpenJDK Serviceability >>>>>>> Subject: RFR: JDK-8224642: Test >>>>>>> sun/tools/jcmd/TestJcmdSanity.java fails: >>>>>>> Bad file descriptor >>>>>>> >>>>>>> The workaround below passed 1000 testruns on linux-x64-debug. >>>>>>> >>>>>>> A more localized fix simply moves the stream reader out of the >>>>>>> try with resources, so only one close is applied to the underlying >>>>>>> socket. I'll run this test through 1000 testruns today. >>>>>>> >>>>>>> Looking for a final review for this change. >>>>>>> >>>>>>> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>>> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>>> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>>> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>>> @@ -122,8 +122,8 @@ >>>>>>> ??????????????? if (line.trim().equals("stop")) { >>>>>>> ??????????????????? break; >>>>>>> ??????????????? } >>>>>>> -??????????? try (InputStream in = hvm.executeJCmd(line); >>>>>>> -???????????????? InputStreamReader isr = new InputStreamReader(in, >>>>>>> "UTF-8")) { >>>>>>> +??????????? try (InputStream in = hvm.executeJCmd(line)) { >>>>>>> +??????????????? InputStreamReader isr = new >>>>>>> InputStreamReader(in, "UTF-8"); >>>>>>> ??????????????????? // read to EOF and just print output >>>>>>> ??????????????????? char c[] = new char[256]; >>>>>>> ??????????????????? int n; >>>>>>> >>>>>>> On 6/17/19 3:23 PM, Gary Adams wrote: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8224642 >>>>>>>> >>>>>>>> I may have a handle on what is going wrong with the >>>>>>>> TestJcmdSanity test and the bad file descriptor. >>>>>>>> >>>>>>>> A change made in April 2019 placed the input stream and reader >>>>>>>> within the same try with resources block. This has the effect of >>>>>>>> calling the >>>>>>>> SocketInputStream close method twice for each command processed. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222491 >>>>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f >>>>>>>> >>>>>>>> The last set of tests in the TestJcmdSanity test attempts to >>>>>>>> process ~100 >>>>>>>> VM.version commands in a loop. Since the closes are handled >>>>>>>> when the objects are collected it may come at an inopportune time. >>>>>>>> >>>>>>>> I'm testing the fix below to ensure a second close becomes a noop. >>>>>>>> It may be better to revisit the earlier change that set up the >>>>>>>> double >>>>>>>> close calls. >>>>>>>> >>>>>>>> diff --git >>>>>>>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>>> >>>>>>>> >>>>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> >>>>>>>> --- >>>>>>>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>>> >>>>>>>> +++ >>>>>>>> >>>>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> >>>>>>>> @@ -233,7 +233,7 @@ >>>>>>>> ??????? * InputStream for the socket connection to get target VM >>>>>>>> ??????? */ >>>>>>>> ?????? private class SocketInputStream extends InputStream { >>>>>>>> -??????? int s; >>>>>>>> +??????? int s = -1; >>>>>>>> >>>>>>>> ?????????? public SocketInputStream(int s) { >>>>>>>> ?????????????? this.s = s; >>>>>>>> @@ -261,7 +261,10 @@ >>>>>>>> ?????????? } >>>>>>>> >>>>>>>> ?????????? public void close() throws IOException { >>>>>>>> +??????????? if (s != -1) { >>>>>>>> ?????????????? VirtualMachineImpl.close(s); >>>>>>>> +??????????????? s = -1; >>>>>>>> +??????????? } >>>>>>>> ?????????? } >>>>>>>> ?????? } >>> >> > From andrew_m_leonard at uk.ibm.com Wed Jun 19 17:29:08 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 19 Jun 2019 18:29:08 +0100 Subject: RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners Message-ID: Alan and other reviewers please?, Firstly apologies for the long post, but I wanted to be thorough. Following previous comments I have reviewed my understanding of concurrency and "safe publishing" in the JMM, and I have a fairly clear understanding now. I have reworked my fix to the issue associated with concurrent JDI connector listeners after thoroughly reviewing and walking through the sun.tools.jdi Connector implementation and also reading the spec javadoc. My Goal: To make JDI Connector and associated listening/attaching APIs "thread-safe", for the purpose of supporting a debugger use case where multiple listening/attaching "threads" are used. >From the review I determined the following key components are already thread-safe: - VirtualMachineImpl - VirtualMachineManagerImpl The components that needed some work were: - ConnectorImpl and all its sub-classes - A Minor fix to SocketTransportService My new patch is available for review here: http://cr.openjdk.java.net/~aleonard/8225474/webrev.05/ Tests run successfully: - new JdwpConcurrentAttachTest.java which performs a multi-threaded stress test of the start/stopListening process where the "bug" occurs - jtreg -jdk:$PRODUCT_HOME -concurrency:12 -v1 -timeoutfactor:20 langtools/jdk/jshell - jtreg -jdk:$PRODUCT_HOME -timeoutfactor:20 -v1 jdk/com/sun/jdi (2 tests failed that failed before for unrelated reasons) The following summarizes the key changes and why: ConnectorImpl: final Map defaultArguments = new LinkedHashMap<>(); ==> Made "final" so that Connector object defaultArguments is safely published to other threads after construction defaultArguments(): + synchronized(defaultArguments) { Collection values = defaultArguments.values(); ==> Synchronize on defaultArguments before iterating over values to return a "copy" to debugger addString/Boolean/Integer/SelectedArgument: + synchronized(defaultArguments) { defaultArguments.put(name, ==> synchronize on defaultArguments for updates toString: + synchronized(defaultArguments) { Iterator iter = defaultArguments().values().iterator(); ==> synchronize on defaultArguments prior to values iteration, and to create a "happens-before" relationship + synchronized(this) { if (messages == null) { messages = ResourceBundle.getBundle("com.sun.tools.jdi.resources.jdi"); } + } ==> Protect messages construction ArgumentImpl private final String name; private final String label; private final String description; private volatile String value; private final boolean mustSpecify; ==> final all except value which is volatile, so that Argument can be safely published to other threads after construction ==> value is "volatile" as this can be set by debuggers, so must set volatile to ensure if passed to other thread a "happens-before" is ensured BooleanArgumentImpl + synchronized(ConnectorImpl.class) { if(trueString == null) { trueString = getString("true"); falseString = getString("false"); } + } ==> synchronized on ConnectorImpl.class object to ensure lock for initializing the static fields GenericListeningConnector: final Map, TransportService.ListenKey> listenMap; final TransportService transportService; final Transport transport; ==> "final" these to ensure "safe publication" to other threads after Connector construction private GenericListeningConnector(TransportService ts, boolean addAddressArgument, + Transport tsp) ==> Added Transport param to constructor so that sub-classes can pass in their desired Transport and then allow transport to be "final" for "safe publication". Previously transport was being constructed "twice" wastefully. listenMap = new ConcurrentHashMap, TransportService.ListenKey>(10); ==> Make listenMap a ConcurrentHashMap so that it is "thread-safe" for access/updates public synchronized String startListening/stopListening(.. ==> Made start & stop listening "synchronized" so that management of listenMap entry and transportService state are locked&synchronized GenericAttachingConnector: final TransportService transportService; final Transport transport; ==> Made "final" so that Connector can be safely published private GenericAttachingConnector(TransportService ts, boolean addAddressArgument, + Transport tsp) ==> Added Transport param to constructor so that sub-classes can pass in their desired Transport and then allow transport to be "final" for "safe publication". Previously transport was being constructed "twice" wastefully. ProcessAttachingConnector: - com.sun.tools.attach.VirtualMachine vm; final Transport transport; ==> Removed "unused" vm field ==> Made transport final to allow "safe publication" public Transport transport() { - if (transport == null) { - return new Transport() { - public String name() { - return "local"; - } - }; - } return transport; ==> Removed creation by this method, as transport is always constructed in constructor and is now final. This now matches transport() method in all the other connector impls SocketAttaching/ListeningConnector: public SocketAttaching/ListeningConnector() { - super(new SocketTransportService()); + super(new SocketTransportService(), new Transport() { + public String name() { + return "dt_socket"; // for compatibility reasons + } + }); ==> Construct Transport() during super constructor where transport is now "final" to ensure "safe publication", and avoids wasteful double construction that was happening before. SocketTransportService: static class SocketListenKey extends ListenKey { final ServerSocket ss; ==> Made "final" so that ListenKey returned by startListening() is safe for publication, eg.if one thread starts listening and passes to another thread to accept connection... Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Wed Jun 19 19:20:49 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 19 Jun 2019 19:20:49 +0000 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: Message-ID: The simple solution is probably not delete those files. :) If this is a long known bug, did you actually open a bug report with any of the OpenJDK contributor organizations and what?s the number? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: serviceability-dev im Auftrag von nijiaben Gesendet: Mittwoch, Juni 19, 2019 7:12 PM An: serviceability-dev; jdk8u-dev; hotspot-runtime-dev Betreff: A Bug about the JVM Attach mechanism Hi, All, There is a bug that has been discovered for a long time, but it has not been fixed. We usually use some shell scripts to clean up the /tmp directory. When we have executed a similar jstack command based on the attach mechanism, it will generate a .java_pidXXX socket file in the /tmp directory. Once this file is clean up, and then will not be attached anymore. The main reason is that once the Attach Listener thread is created, the file of ?/tmp/.java_pidXXX? will be created and the markup initialization is complete. If .java_pidXXX is cleaned up, it will not be created anymore and cannot be attached. bool AttachListener::is_init_trigger() { if (init_at_startup() || is_initialized()) { // initialized at startup or already initialized return false; } char fn[PATH_MAX+1]; sprintf(fn, ".attach_pid%d", os::current_process_id()); int ret; struct stat64 st; RESTARTABLE(::stat64(fn, &st), ret); if (ret == -1) { snprintf(fn, sizeof(fn), "%s/.attach_pid%d", os::get_temp_directory(), os::current_process_id()); RESTARTABLE(::stat64(fn, &st), ret); } if (ret == 0) { if (st.st_uid == geteuid()) { init(); // will create Attach Listener Thread return true; } } return false; } This bug has a big impact on troubleshooting some problems. Can it be fixed as soon as possible? Thanks, nijiaben @ PerfMa -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jun 19 21:56:24 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Jun 2019 21:56:24 +0000 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <5D0A474F.5090605@oracle.com> References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> <5D0A237D.9020106@oracle.com> <5D0A474F.5090605@oracle.com> Message-ID: Hi Gary, this is better. The detach method already uses synchronization in each platform implementation. I think this improved close behavior should be implemented in all platform implementations of VirtualMachineImpl. That is aix, linux, macosx, solaris and windows. For Windows, it's the PipedInputStream::close method (line 173) which should also have the better implementation. As for fix target: I think you should push it to JDK13 still - it is a P3 bug which is within criteria for RDP1. Thanks Christoph > -----Original Message----- > From: Gary Adams > Sent: Mittwoch, 19. Juni 2019 16:32 > To: Langer, Christoph > Cc: OpenJDK Serviceability ; > Schmelter, Ralf > Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java > fails: Bad file descriptor > > That would be consistent with the windows detach() synchronization. > > Updated patch is attached. > > On 6/19/19, 8:14 AM, Langer, Christoph wrote: > > Hi Gary, > > > > looks good overall. I however think the block should also be synchronized > to avoid issues when multiple threads attempt to close the stream. > > > > Cheers > > Christoph > > > >> -----Original Message----- > >> From: Gary Adams > >> Sent: Mittwoch, 19. Juni 2019 13:59 > >> To: Langer, Christoph > >> Cc: OpenJDK Serviceability; > >> Schmelter, Ralf > >> Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java > >> fails: Bad file descriptor > >> > >> I think everyone is in agreement now that preventing the double close > >> is the best way to handle this failure. If there are no further comments, > >> I'll push the attached patch on Thurs morning to the jdk/jdk repos. > >> > >> I'll also close JDK-8223361 as a duplicate. > >> > >> On 6/19/19, 2:36 AM, Langer, Christoph wrote: > >>> Hi Gary, > >>> > >>> I think overall it would be better to fix the InputStream to be tolerant to > >> multiple calls to close, as Ralf pointed out. Maybe someone else on some > >> other place runs into this again because he/she relies on the correct > >> implementation of Closeable. > >>> However, as a quick fix I can also imagine to do use a single resource like > >> this: > >>> try (InputStreamReader isr = new > >> InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { > >>> Then we'd also have a single close call per instance. > >>> > >>> But if you do that, you should at least open a bug to track fixing of the > >> InputStream implementation... > >>> Best regards > >>> Christoph > >>> > >>>> -----Original Message----- > >>>> From: serviceability-dev bounces at openjdk.java.net> > >> On > >>>> Behalf Of gary.adams at oracle.com > >>>> Sent: Dienstag, 18. Juni 2019 12:08 > >>>> To: OpenJDK Serviceability > >>>> Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java > fails: > >>>> Bad file descriptor > >>>> > >>>> The workaround below passed 1000 testruns on linux-x64-debug. > >>>> > >>>> A more localized fix simply moves the stream reader out of the > >>>> try with resources, so only one close is applied to the underlying > >>>> socket. I'll run this test through 1000 testruns today. > >>>> > >>>> Looking for a final review for this change. > >>>> > >>>> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >>>> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >>>> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >>>> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >>>> @@ -122,8 +122,8 @@ > >>>> if (line.trim().equals("stop")) { > >>>> break; > >>>> } > >>>> - try (InputStream in = hvm.executeJCmd(line); > >>>> - InputStreamReader isr = new InputStreamReader(in, > >>>> "UTF-8")) { > >>>> + try (InputStream in = hvm.executeJCmd(line)) { > >>>> + InputStreamReader isr = new InputStreamReader(in, "UTF- > 8"); > >>>> // read to EOF and just print output > >>>> char c[] = new char[256]; > >>>> int n; > >>>> > >>>> On 6/17/19 3:23 PM, Gary Adams wrote: > >>>>> https://bugs.openjdk.java.net/browse/JDK-8224642 > >>>>> > >>>>> I may have a handle on what is going wrong with the > >>>>> TestJcmdSanity test and the bad file descriptor. > >>>>> > >>>>> A change made in April 2019 placed the input stream and reader > >>>>> within the same try with resources block. This has the effect of > >>>>> calling the > >>>>> SocketInputStream close method twice for each command processed. > >>>>> > >>>>> https://bugs.openjdk.java.net/browse/JDK-8222491 > >>>>> http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f > >>>>> > >>>>> The last set of tests in the TestJcmdSanity test attempts to process > ~100 > >>>>> VM.version commands in a loop. Since the closes are handled > >>>>> when the objects are collected it may come at an inopportune time. > >>>>> > >>>>> I'm testing the fix below to ensure a second close becomes a noop. > >>>>> It may be better to revisit the earlier change that set up the double > >>>>> close calls. > >>>>> > >>>>> diff --git > >>>>> > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>>>> > >> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>>>> --- > >>>>> > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>>>> +++ > >>>>> > >> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>>>> @@ -233,7 +233,7 @@ > >>>>> * InputStream for the socket connection to get target VM > >>>>> */ > >>>>> private class SocketInputStream extends InputStream { > >>>>> - int s; > >>>>> + int s = -1; > >>>>> > >>>>> public SocketInputStream(int s) { > >>>>> this.s = s; > >>>>> @@ -261,7 +261,10 @@ > >>>>> } > >>>>> > >>>>> public void close() throws IOException { > >>>>> + if (s != -1) { > >>>>> VirtualMachineImpl.close(s); > >>>>> + s = -1; > >>>>> + } > >>>>> } > >>>>> } From serguei.spitsyn at oracle.com Thu Jun 20 01:09:54 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 19 Jun 2019 18:09:54 -0700 Subject: 13 RFR (S): 8223736: Message-ID: Please review a fix for test bug: ? https://bugs.openjdk.java.net/browse/JDK-8223736 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ Summary: ?It seems that waiting for 0.5 sec for a MonitorContendedEnter event in the ?increment() method sometime is not enough (especially when the JFR is enabled). ?The fix implement an approach to ensure the event has posted before the worker ?thread goes to the next iteration. ?Also, another check is added to diagnose if any of two worker threads ?(tc04t001Thread) has been interrupted by timeout. ?In fact, we have many other tests which miss this kind of check and diagnostics. ?We may want to consider fixing other cases if we encounter this eventually happens. Testing: ?A mach5 test submission is in progress. Thanks, Serguei From serguei.spitsyn at oracle.com Thu Jun 20 01:59:22 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 19 Jun 2019 18:59:22 -0700 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: Message-ID: Sorry, forgot the? bug title to add to the email subject. Thanks, Serguei On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: > Please review a fix for test bug: > ? https://bugs.openjdk.java.net/browse/JDK-8223736 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ > > > Summary: > ?It seems that waiting for 0.5 sec for a MonitorContendedEnter event > in the > ?increment() method sometime is not enough (especially when the JFR is > enabled). > ?The fix implement an approach to ensure the event has posted before > the worker > ?thread goes to the next iteration. > ?Also, another check is added to diagnose if any of two worker threads > ?(tc04t001Thread) has been interrupted by timeout. > ?In fact, we have many other tests which miss this kind of check and > diagnostics. > ?We may want to consider fixing other cases if we encounter this > eventually happens. > > Testing: > ?A mach5 test submission is in progress. > > Thanks, > Serguei > From david.holmes at oracle.com Thu Jun 20 03:36:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Jun 2019 20:36:28 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: Message-ID: Hi, On 19/06/2019 2:26 am, nijiaben wrote: > Hi, All, > > There is a bug that has been discovered for a long time, but it has not > been fixed. Can you provide a bug number for this? > We usually use some shell scripts to clean up the /tmp directory. > When we have executed a similar jstack command based on the attach > mechanism, > it will generate a .java_pidXXX socket file in the /tmp directory. > Once this file is clean up, and then will not be attached anymore. > > The main reason is that once the Attach Listener thread is created, > the file of? ?/tmp/.java_pidXXX? will be created and the markup > initialization is complete. > If .java_pidXXX is cleaned up, it will not be created anymore and cannot > be attached. Once we have attached and created the attach thread we don't need to perform that initialization handshake because the attach thread exists and will process any subsequent commands. David ----- > > bool AttachListener::is_init_trigger() { > if (init_at_startup() || is_initialized()) { // initialized at startup > or already initialized > return false; > } > char fn[PATH_MAX+1]; > sprintf(fn, ".attach_pid%d", os::current_process_id()); > int ret; > struct stat64 st; > RESTARTABLE(::stat64(fn, &st), ret); > if (ret == -1) { > snprintf(fn, sizeof(fn), "%s/.attach_pid%d", > os::get_temp_directory(), os::current_process_id()); > RESTARTABLE(::stat64(fn, &st), ret); > } > if (ret == 0) { > if (st.st_uid == geteuid()) { > init(); // will create Attach Listener Thread > return true; > } > } > return false; > } > > This bug has a big impact on troubleshooting some problems. > Can it be fixed as soon as possible? > > Thanks, > > nijiaben @ PerfMa > From daniil.x.titov at oracle.com Thu Jun 20 04:02:40 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 19 Jun 2019 21:02:40 -0700 Subject: RFR: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout Message-ID: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> Please review the change that fixes an intermittent failure of serviceability/dcmd/framework/* tests on Linux platform. The problem here is that get_namespace_pid() method, that is called by mmap_attach_shared () that in turn is called by PerfMemory::attach(), tries to read the namespace pid information from /proc//status file. However, it doesn't check that the error indicator associated with stream is set that results in the endless loop (lines 664-677) if the process terminates after /proc//status was opened (line 659) and checked for null (line 661). 658 snprintf(fname, sizeof(fname), "/proc/%d/status", vmid); 659 FILE *fp = fopen(fname, "r"); 660 661 if (fp) { 662 int pid, nspid; 663 int ret; 664 while (!feof(fp)) { 665 ret = fscanf(fp, "NSpid: %d %d", &pid, &nspid); 666 if (ret == 1) { 667 break; 668 } 669 if (ret == 2) { 670 retpid = nspid; 671 break; 672 } 673 for (;;) { 674 int ch = fgetc(fp); 675 if (ch == EOF || ch == (int)'\n') break; 676 } 677 } 678 fclose(fp); 679 } The fix adds the check for the error indicator to ensure that the "while" loop terminates properly if the file no longer exists. Issues [3] and [4] have the same cause and will be closed as duplicates of this issue. Testing: Mach5 hotspot_serviceability tests succeeded, tier1,tier2, and tier3 tests are in progress. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8220175/webrev.01/ [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8220175 [3] https://bugs.openjdk.java.net/browse/JDK-8223600 [4] https://bugs.openjdk.java.net/browse/JDK-8217351 Thanks! -Daniil From nijiaben at perfma.com Thu Jun 20 04:10:57 2019 From: nijiaben at perfma.com (=?utf-8?B?bmlqaWFiZW4=?=) Date: Thu, 20 Jun 2019 12:10:57 +0800 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: Message-ID: Hi, > Can you provide a bug number for this? I'm sorry, I made you misunderstand what I meant. I mean, I knew this problem before, but I didn't submit it to the JDK Bug System. > Once we have attached and created the attach thread we don't need to > perform that initialization handshake because the attach thread exists > and will process any subsequent commands. I know this mechanism, can we provide means of recovery to avoid unavailability caused by accidental deletion? Thanks, nijiaben @ PerfMa ------------------ Original ------------------ From: "David Holmes"; Date: Thu, Jun 20, 2019 11:36 AM To: "nijiaben"; "serviceability-dev"; "jdk8u-dev"; "hotspot-runtime-dev"; Subject: Re: A Bug about the JVM Attach mechanism Hi, On 19/06/2019 2:26 am, nijiaben wrote: > Hi, All, > > There is a bug that has been discovered for a long time, but it has not > been fixed. Can you provide a bug number for this? > We usually use some shell scripts to clean up the /tmp directory. > When we have executed a similar jstack command based on the attach > mechanism, > it will generate a .java_pidXXX socket file in the /tmp directory. > Once this file is clean up, and then will not be attached anymore. > > The main reason is that once the Attach Listener thread is created, > the file of ?/tmp/.java_pidXXX? will be created and the markup > initialization is complete. > If .java_pidXXX is cleaned up, it will not be created anymore and cannot > be attached. Once we have attached and created the attach thread we don't need to perform that initialization handshake because the attach thread exists and will process any subsequent commands. David ----- > > bool AttachListener::is_init_trigger() { > if (init_at_startup() || is_initialized()) { // initialized at startup > or already initialized > return false; > } > char fn[PATH_MAX+1]; > sprintf(fn, ".attach_pid%d", os::current_process_id()); > int ret; > struct stat64 st; > RESTARTABLE(::stat64(fn, &st), ret); > if (ret == -1) { > snprintf(fn, sizeof(fn), "%s/.attach_pid%d", > os::get_temp_directory(), os::current_process_id()); > RESTARTABLE(::stat64(fn, &st), ret); > } > if (ret == 0) { > if (st.st_uid == geteuid()) { > init(); // will create Attach Listener Thread > return true; > } > } > return false; > } > > This bug has a big impact on troubleshooting some problems. > Can it be fixed as soon as possible? > > Thanks, > > nijiaben @ PerfMa > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jun 20 04:12:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Jun 2019 21:12:51 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: Message-ID: <312f6e05-db04-95b3-a21f-5f545466c9d6@oracle.com> On 19/06/2019 2:10 pm, nijiaben wrote: > Hi, > > > Can you provide a bug number for this? > > I'm sorry, I made you misunderstand what I meant. > I mean, I knew this problem before, but I didn't submit it to the JDK > Bug System. Okay. > > Once we have attached and created the attach thread we don't need to > >?perform that initialization handshake because the attach thread exists > >?and will process any subsequent commands. > > I know this mechanism, can we provide means of recovery to avoid > unavailability caused by accidental deletion? Sorry I'm still not clear how deletion causes any problem after the attach thread has been started ?? David ----- > Thanks, > > nijiaben @ PerfMa > > ------------------?Original?------------------ > *From: *?"David Holmes"; > *Date: *?Thu, Jun 20, 2019 11:36 AM > *To: *?"nijiaben"; > "serviceability-dev"; > "jdk8u-dev"; > "hotspot-runtime-dev"; > *Subject: *?Re: A Bug about the JVM Attach mechanism > Hi, > > On 19/06/2019 2:26 am, nijiaben wrote: > > Hi, All, > > > > There is a bug that has been discovered for a long time, but it has not > > been fixed. > > Can you provide a bug number for this? > > > We usually use some shell scripts to clean up the /tmp directory. > > When we have executed a similar jstack command based on the attach > > mechanism, > > it will generate a .java_pidXXX socket file in the /tmp directory. > > Once this file is clean up, and then will not be attached anymore. > > > > The main reason is that once the Attach Listener thread is created, > > the file of? ?/tmp/.java_pidXXX? will be created and the markup > > initialization is complete. > > If .java_pidXXX is cleaned up, it will not be created anymore and cannot > > be attached. > > Once we have attached and created the attach thread we don't need to > perform that initialization handshake because the attach thread exists > and will process any subsequent commands. > > David > ----- > > > > > > bool AttachListener::is_init_trigger() { > > if (init_at_startup() || is_initialized()) { // initialized at startup > > or already initialized > > return false; > > } > > char fn[PATH_MAX+1]; > > sprintf(fn, ".attach_pid%d", os::current_process_id()); > > int ret; > > struct stat64 st; > > RESTARTABLE(::stat64(fn, &st), ret); > > if (ret == -1) { > > snprintf(fn, sizeof(fn), "%s/.attach_pid%d", > > os::get_temp_directory(), os::current_process_id()); > > RESTARTABLE(::stat64(fn, &st), ret); > > } > > if (ret == 0) { > > if (st.st_uid == geteuid()) { > > init(); // will create Attach Listener Thread > > return true; > > } > > } > > return false; > > } > > > > This bug has a big impact on troubleshooting some problems. > > Can it be fixed as soon as possible? > > > > Thanks, > > > > nijiaben @ PerfMa > > From chris.plummer at oracle.com Thu Jun 20 04:13:13 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 19 Jun 2019 21:13:13 -0700 Subject: RFR: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout In-Reply-To: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> References: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> Message-ID: <83f80d7c-4477-8b52-b3e3-16554ec9c161@oracle.com> Hi Daniil, I think your fix is good, although I wonder about the robustness of this function given that the status file can change while it is reading it. I wonder if it can return a false negative because it never saw the matching line. This could happen if a line gets deleted, causing the matching line to suddenly be earlier in the file, possibly before the current location being read. Anyway, that's not really related to the current issue or fix, but if you think it might be an issue maybe a bug should be filed for it. thanks, Chris On 6/19/19 9:02 PM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of serviceability/dcmd/framework/* tests on Linux platform. > > The problem here is that get_namespace_pid() method, that is called by mmap_attach_shared () that in turn is called by PerfMemory::attach(), > tries to read the namespace pid information from /proc//status file. However, it doesn't check that the error indicator associated with > stream is set that results in the endless loop (lines 664-677) if the process terminates after /proc//status was opened (line 659) > and checked for null (line 661). > > 658 snprintf(fname, sizeof(fname), "/proc/%d/status", vmid); > 659 FILE *fp = fopen(fname, "r"); > 660 > 661 if (fp) { > 662 int pid, nspid; > 663 int ret; > 664 while (!feof(fp)) { > 665 ret = fscanf(fp, "NSpid: %d %d", &pid, &nspid); > 666 if (ret == 1) { > 667 break; > 668 } > 669 if (ret == 2) { > 670 retpid = nspid; > 671 break; > 672 } > 673 for (;;) { > 674 int ch = fgetc(fp); > 675 if (ch == EOF || ch == (int)'\n') break; > 676 } > 677 } > 678 fclose(fp); > 679 } > > The fix adds the check for the error indicator to ensure that the "while" loop terminates properly if the file no longer exists. > > Issues [3] and [4] have the same cause and will be closed as duplicates of this issue. > > Testing: Mach5 hotspot_serviceability tests succeeded, tier1,tier2, and tier3 tests are in progress. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8220175/webrev.01/ > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8220175 > [3] https://bugs.openjdk.java.net/browse/JDK-8223600 > [4] https://bugs.openjdk.java.net/browse/JDK-8217351 > > Thanks! > -Daniil > > From Alan.Bateman at oracle.com Thu Jun 20 06:54:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Jun 2019 07:54:05 +0100 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: Message-ID: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> On 20/06/2019 05:10, nijiaben wrote: > : > I know this mechanism, can we provide means of recovery to avoid unavailability caused by accidental deletion? > Are you concerned about tmpreaper or cron jobs that periodically cleanup /tmp? There may indeed be an issue for applications that run for weeks or months. If someone is using jmap, jcmd or other tools using the attach API then it will trigger the attach listener to start. When they come back in a few weeks then the .java_pid file may have been removed so they cannot attach. Is this what what you are pointing out? -Alan From rednaxelafx at gmail.com Thu Jun 20 07:06:29 2019 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 20 Jun 2019 00:06:29 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> Message-ID: (Speaking on behalf of my own experience) Yes Alan, you're right on. I'm fairly sure that's the symptom that Nijiaben is asking about here. - Kris On Wed, Jun 19, 2019 at 11:54 PM Alan Bateman wrote: > On 20/06/2019 05:10, nijiaben wrote: > > : > > I know this mechanism, can we provide means of recovery to avoid > unavailability caused by accidental deletion? > > > Are you concerned about tmpreaper or cron jobs that periodically cleanup > /tmp? There may indeed be an issue for applications that run for weeks > or months. If someone is using jmap, jcmd or other tools using the > attach API then it will trigger the attach listener to start. When they > come back in a few weeks then the .java_pid file may have been > removed so they cannot attach. Is this what what you are pointing out? > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Thu Jun 20 07:41:51 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 20 Jun 2019 00:41:51 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <312f6e05-db04-95b3-a21f-5f545466c9d6@oracle.com> References: <312f6e05-db04-95b3-a21f-5f545466c9d6@oracle.com> Message-ID: <3F0386B8-6CFB-4688-A6D3-85B2F6B93435@oracle.com> I think it is https://bugs.openjdk.java.net/browse/JDK-8225193 The jcmd failed to attach if /tmp/.java_pid* is removed. It doesn't find file which is used as listener socket and send signal to start attach listener. (It suppose that listener is not started yet). While target VM expect that listener is started already and just dump stack trace into stdout. See code http://hg.openjdk.java.net/jdk/jdk/file/eaf0a8de3450/src/hotspot/share/runtime/os.cpp#l362 http://hg.openjdk.java.net/jdk/jdk/file/eaf0a8de3450/src/hotspot/share/services/attachListener.hpp#l74 The listener is initialized only once when thread is started and still left "initialized" even socket is removed. The only workaround is not to remove this file. Leonid > On Jun 19, 2019, at 9:12 PM, David Holmes wrote: > > On 19/06/2019 2:10 pm, nijiaben wrote: >> Hi, >> > Can you provide a bug number for this? >> I'm sorry, I made you misunderstand what I meant. >> I mean, I knew this problem before, but I didn't submit it to the JDK Bug System. > > Okay. > >> > Once we have attached and created the attach thread we don't need to >> > perform that initialization handshake because the attach thread exists >> > and will process any subsequent commands. >> I know this mechanism, can we provide means of recovery to avoid unavailability caused by accidental deletion? > > Sorry I'm still not clear how deletion causes any problem after the attach thread has been started ?? > > David > ----- > >> Thanks, >> nijiaben @ PerfMa >> ------------------ Original ------------------ >> *From: * "David Holmes"; >> *Date: * Thu, Jun 20, 2019 11:36 AM >> *To: * "nijiaben"; "serviceability-dev"; "jdk8u-dev"; "hotspot-runtime-dev"; >> *Subject: * Re: A Bug about the JVM Attach mechanism >> Hi, >> On 19/06/2019 2:26 am, nijiaben wrote: >> > Hi, All, >> > >> > There is a bug that has been discovered for a long time, but it has not >> > been fixed. >> Can you provide a bug number for this? >> > We usually use some shell scripts to clean up the /tmp directory. >> > When we have executed a similar jstack command based on the attach >> > mechanism, >> > it will generate a .java_pidXXX socket file in the /tmp directory. >> > Once this file is clean up, and then will not be attached anymore. >> > >> > The main reason is that once the Attach Listener thread is created, >> > the file of ?/tmp/.java_pidXXX? will be created and the markup >> > initialization is complete. >> > If .java_pidXXX is cleaned up, it will not be created anymore and cannot >> > be attached. >> Once we have attached and created the attach thread we don't need to >> perform that initialization handshake because the attach thread exists >> and will process any subsequent commands. >> David >> ----- >> > >> > bool AttachListener::is_init_trigger() { >> > if (init_at_startup() || is_initialized()) { // initialized at startup >> > or already initialized >> > return false; >> > } >> > char fn[PATH_MAX+1]; >> > sprintf(fn, ".attach_pid%d", os::current_process_id()); >> > int ret; >> > struct stat64 st; >> > RESTARTABLE(::stat64(fn, &st), ret); >> > if (ret == -1) { >> > snprintf(fn, sizeof(fn), "%s/.attach_pid%d", >> > os::get_temp_directory(), os::current_process_id()); >> > RESTARTABLE(::stat64(fn, &st), ret); >> > } >> > if (ret == 0) { >> > if (st.st_uid == geteuid()) { >> > init(); // will create Attach Listener Thread >> > return true; >> > } >> > } >> > return false; >> > } >> > >> > This bug has a big impact on troubleshooting some problems. >> > Can it be fixed as soon as possible? >> > >> > Thanks, >> > >> > nijiaben @ PerfMa >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Thu Jun 20 08:36:10 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Thu, 20 Jun 2019 11:36:10 +0300 Subject: Slow class loading when running JVM in debug mode Message-ID: <0ae9a535-4fc7-93e3-ebc5-0a1d2ad9b5e9@jetbrains.com> Hi everyone! we have detected that a process started with the debug agent (even when debugger is not actually attached) may run significantly slower than without the agent, see: https://youtrack.jetbrains.com/issue/JBR-1611 We all thought that without the debugger attached there should not be a difference. Is that something well known? Should we file a bug? Thanks, Egor -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From gary.adams at oracle.com Thu Jun 20 09:56:06 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 20 Jun 2019 05:56:06 -0400 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> <5D0A237D.9020106@oracle.com> <5D0A474F.5090605@oracle.com> Message-ID: <11294c71-f3a6-cf91-8c9d-a7071182e83f@oracle.com> During testing the failure was only observed in a questionable test on linux-x64-debug builds. I question whether P3 was a correct assessment when the bug was filed. The only reason this encounter caused a problem with the double close is the test was looping and getting the same file descriptor and the second close came while new socket was being allocated. I have no issue with delivering this fix into jdk/jdk, but if it is needed in jdk13, I'll have to hand it off to someone else to complete. On 6/19/19 5:56 PM, Langer, Christoph wrote: > Hi Gary, > > this is better. The detach method already uses synchronization in each platform implementation. > > I think this improved close behavior should be implemented in all platform implementations of VirtualMachineImpl. That is aix, linux, macosx, solaris and windows. For Windows, it's the PipedInputStream::close method (line 173) which should also have the better implementation. > > As for fix target: I think you should push it to JDK13 still - it is a P3 bug which is within criteria for RDP1. > > Thanks > Christoph > >> -----Original Message----- >> From: Gary Adams >> Sent: Mittwoch, 19. Juni 2019 16:32 >> To: Langer, Christoph >> Cc: OpenJDK Serviceability ; >> Schmelter, Ralf >> Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java >> fails: Bad file descriptor >> >> That would be consistent with the windows detach() synchronization. >> >> Updated patch is attached. >> >> On 6/19/19, 8:14 AM, Langer, Christoph wrote: >>> Hi Gary, >>> >>> looks good overall. I however think the block should also be synchronized >> to avoid issues when multiple threads attempt to close the stream. >>> Cheers >>> Christoph >>> >>>> -----Original Message----- >>>> From: Gary Adams >>>> Sent: Mittwoch, 19. Juni 2019 13:59 >>>> To: Langer, Christoph >>>> Cc: OpenJDK Serviceability; >>>> Schmelter, Ralf >>>> Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java >>>> fails: Bad file descriptor >>>> >>>> I think everyone is in agreement now that preventing the double close >>>> is the best way to handle this failure. If there are no further comments, >>>> I'll push the attached patch on Thurs morning to the jdk/jdk repos. >>>> >>>> I'll also close JDK-8223361 as a duplicate. >>>> >>>> On 6/19/19, 2:36 AM, Langer, Christoph wrote: >>>>> Hi Gary, >>>>> >>>>> I think overall it would be better to fix the InputStream to be tolerant to >>>> multiple calls to close, as Ralf pointed out. Maybe someone else on some >>>> other place runs into this again because he/she relies on the correct >>>> implementation of Closeable. >>>>> However, as a quick fix I can also imagine to do use a single resource like >>>> this: >>>>> try (InputStreamReader isr = new >>>> InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { >>>>> Then we'd also have a single close call per instance. >>>>> >>>>> But if you do that, you should at least open a bug to track fixing of the >>>> InputStream implementation... >>>>> Best regards >>>>> Christoph >>>>> >>>>>> -----Original Message----- >>>>>> From: serviceability-dev> bounces at openjdk.java.net> >>>> On >>>>>> Behalf Of gary.adams at oracle.com >>>>>> Sent: Dienstag, 18. Juni 2019 12:08 >>>>>> To: OpenJDK Serviceability >>>>>> Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java >> fails: >>>>>> Bad file descriptor >>>>>> >>>>>> The workaround below passed 1000 testruns on linux-x64-debug. >>>>>> >>>>>> A more localized fix simply moves the stream reader out of the >>>>>> try with resources, so only one close is applied to the underlying >>>>>> socket. I'll run this test through 1000 testruns today. >>>>>> >>>>>> Looking for a final review for this change. >>>>>> >>>>>> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java >>>>>> @@ -122,8 +122,8 @@ >>>>>> if (line.trim().equals("stop")) { >>>>>> break; >>>>>> } >>>>>> - try (InputStream in = hvm.executeJCmd(line); >>>>>> - InputStreamReader isr = new InputStreamReader(in, >>>>>> "UTF-8")) { >>>>>> + try (InputStream in = hvm.executeJCmd(line)) { >>>>>> + InputStreamReader isr = new InputStreamReader(in, "UTF- >> 8"); >>>>>> // read to EOF and just print output >>>>>> char c[] = new char[256]; >>>>>> int n; >>>>>> >>>>>> On 6/17/19 3:23 PM, Gary Adams wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8224642 >>>>>>> >>>>>>> I may have a handle on what is going wrong with the >>>>>>> TestJcmdSanity test and the bad file descriptor. >>>>>>> >>>>>>> A change made in April 2019 placed the input stream and reader >>>>>>> within the same try with resources block. This has the effect of >>>>>>> calling the >>>>>>> SocketInputStream close method twice for each command processed. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222491 >>>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f >>>>>>> >>>>>>> The last set of tests in the TestJcmdSanity test attempts to process >> ~100 >>>>>>> VM.version commands in a loop. Since the closes are handled >>>>>>> when the objects are collected it may come at an inopportune time. >>>>>>> >>>>>>> I'm testing the fix below to ensure a second close becomes a noop. >>>>>>> It may be better to revisit the earlier change that set up the double >>>>>>> close calls. >>>>>>> >>>>>>> diff --git >>>>>>> >> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>> --- >>>>>>> >> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>> +++ >>>>>>> >>>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>> @@ -233,7 +233,7 @@ >>>>>>> * InputStream for the socket connection to get target VM >>>>>>> */ >>>>>>> private class SocketInputStream extends InputStream { >>>>>>> - int s; >>>>>>> + int s = -1; >>>>>>> >>>>>>> public SocketInputStream(int s) { >>>>>>> this.s = s; >>>>>>> @@ -261,7 +261,10 @@ >>>>>>> } >>>>>>> >>>>>>> public void close() throws IOException { >>>>>>> + if (s != -1) { >>>>>>> VirtualMachineImpl.close(s); >>>>>>> + s = -1; >>>>>>> + } >>>>>>> } >>>>>>> } From christoph.langer at sap.com Thu Jun 20 10:28:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Jun 2019 10:28:35 +0000 Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor In-Reply-To: <11294c71-f3a6-cf91-8c9d-a7071182e83f@oracle.com> References: <5D07E8BD.4000302@oracle.com> <4979e6e0-0245-1c19-2b98-393b8994b766@oracle.com> <5D0A237D.9020106@oracle.com> <5D0A474F.5090605@oracle.com> <11294c71-f3a6-cf91-8c9d-a7071182e83f@oracle.com> Message-ID: Ok, then jdk/jdk is fine for me. In case this turns out to be more important, I guess it could be backported to an update release. > -----Original Message----- > From: gary.adams at oracle.com > Sent: Donnerstag, 20. Juni 2019 11:56 > To: Langer, Christoph > Cc: OpenJDK Serviceability ; > Schmelter, Ralf > Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java > fails: Bad file descriptor > > During testing the failure was only observed in a questionable > test on linux-x64-debug builds. I question whether P3 was a > correct assessment when the bug was filed. The only reason > this encounter caused a problem with the double close is the test > was looping and getting the same file descriptor and the second close > came while new socket was being allocated. > > I have no issue with delivering this fix into jdk/jdk, > but if it is needed in jdk13, I'll have to hand it off to > someone else to complete. > > On 6/19/19 5:56 PM, Langer, Christoph wrote: > > Hi Gary, > > > > this is better. The detach method already uses synchronization in each > platform implementation. > > > > I think this improved close behavior should be implemented in all platform > implementations of VirtualMachineImpl. That is aix, linux, macosx, solaris and > windows. For Windows, it's the PipedInputStream::close method (line 173) > which should also have the better implementation. > > > > As for fix target: I think you should push it to JDK13 still - it is a P3 bug which > is within criteria for RDP1. > > > > Thanks > > Christoph > > > >> -----Original Message----- > >> From: Gary Adams > >> Sent: Mittwoch, 19. Juni 2019 16:32 > >> To: Langer, Christoph > >> Cc: OpenJDK Serviceability ; > >> Schmelter, Ralf > >> Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java > >> fails: Bad file descriptor > >> > >> That would be consistent with the windows detach() synchronization. > >> > >> Updated patch is attached. > >> > >> On 6/19/19, 8:14 AM, Langer, Christoph wrote: > >>> Hi Gary, > >>> > >>> looks good overall. I however think the block should also be > synchronized > >> to avoid issues when multiple threads attempt to close the stream. > >>> Cheers > >>> Christoph > >>> > >>>> -----Original Message----- > >>>> From: Gary Adams > >>>> Sent: Mittwoch, 19. Juni 2019 13:59 > >>>> To: Langer, Christoph > >>>> Cc: OpenJDK Serviceability; > >>>> Schmelter, Ralf > >>>> Subject: Re: RFR: JDK-8224642: Test > sun/tools/jcmd/TestJcmdSanity.java > >>>> fails: Bad file descriptor > >>>> > >>>> I think everyone is in agreement now that preventing the double close > >>>> is the best way to handle this failure. If there are no further comments, > >>>> I'll push the attached patch on Thurs morning to the jdk/jdk repos. > >>>> > >>>> I'll also close JDK-8223361 as a duplicate. > >>>> > >>>> On 6/19/19, 2:36 AM, Langer, Christoph wrote: > >>>>> Hi Gary, > >>>>> > >>>>> I think overall it would be better to fix the InputStream to be tolerant > to > >>>> multiple calls to close, as Ralf pointed out. Maybe someone else on > some > >>>> other place runs into this again because he/she relies on the correct > >>>> implementation of Closeable. > >>>>> However, as a quick fix I can also imagine to do use a single resource > like > >>>> this: > >>>>> try (InputStreamReader isr = new > >>>> InputStreamReader(hvm.executeJCmd(line), "UTF-8")) { > >>>>> Then we'd also have a single close call per instance. > >>>>> > >>>>> But if you do that, you should at least open a bug to track fixing of the > >>>> InputStream implementation... > >>>>> Best regards > >>>>> Christoph > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: serviceability-dev >> bounces at openjdk.java.net> > >>>> On > >>>>>> Behalf Of gary.adams at oracle.com > >>>>>> Sent: Dienstag, 18. Juni 2019 12:08 > >>>>>> To: OpenJDK Serviceability > >>>>>> Subject: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java > >> fails: > >>>>>> Bad file descriptor > >>>>>> > >>>>>> The workaround below passed 1000 testruns on linux-x64-debug. > >>>>>> > >>>>>> A more localized fix simply moves the stream reader out of the > >>>>>> try with resources, so only one close is applied to the underlying > >>>>>> socket. I'll run this test through 1000 testruns today. > >>>>>> > >>>>>> Looking for a final review for this change. > >>>>>> > >>>>>> diff --git a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >>>>>> b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >>>>>> --- a/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >>>>>> +++ b/src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java > >>>>>> @@ -122,8 +122,8 @@ > >>>>>> if (line.trim().equals("stop")) { > >>>>>> break; > >>>>>> } > >>>>>> - try (InputStream in = hvm.executeJCmd(line); > >>>>>> - InputStreamReader isr = new InputStreamReader(in, > >>>>>> "UTF-8")) { > >>>>>> + try (InputStream in = hvm.executeJCmd(line)) { > >>>>>> + InputStreamReader isr = new InputStreamReader(in, "UTF- > >> 8"); > >>>>>> // read to EOF and just print output > >>>>>> char c[] = new char[256]; > >>>>>> int n; > >>>>>> > >>>>>> On 6/17/19 3:23 PM, Gary Adams wrote: > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8224642 > >>>>>>> > >>>>>>> I may have a handle on what is going wrong with the > >>>>>>> TestJcmdSanity test and the bad file descriptor. > >>>>>>> > >>>>>>> A change made in April 2019 placed the input stream and reader > >>>>>>> within the same try with resources block. This has the effect of > >>>>>>> calling the > >>>>>>> SocketInputStream close method twice for each command > processed. > >>>>>>> > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222491 > >>>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f > >>>>>>> > >>>>>>> The last set of tests in the TestJcmdSanity test attempts to process > >> ~100 > >>>>>>> VM.version commands in a loop. Since the closes are handled > >>>>>>> when the objects are collected it may come at an inopportune > time. > >>>>>>> > >>>>>>> I'm testing the fix below to ensure a second close becomes a noop. > >>>>>>> It may be better to revisit the earlier change that set up the double > >>>>>>> close calls. > >>>>>>> > >>>>>>> diff --git > >>>>>>> > >> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>>> > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>>>>>> --- > >>>>>>> > >> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>>>>>> +++ > >>>>>>> > >>>> > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>>>>>> @@ -233,7 +233,7 @@ > >>>>>>> * InputStream for the socket connection to get target VM > >>>>>>> */ > >>>>>>> private class SocketInputStream extends InputStream { > >>>>>>> - int s; > >>>>>>> + int s = -1; > >>>>>>> > >>>>>>> public SocketInputStream(int s) { > >>>>>>> this.s = s; > >>>>>>> @@ -261,7 +261,10 @@ > >>>>>>> } > >>>>>>> > >>>>>>> public void close() throws IOException { > >>>>>>> + if (s != -1) { > >>>>>>> VirtualMachineImpl.close(s); > >>>>>>> + s = -1; > >>>>>>> + } > >>>>>>> } > >>>>>>> } From nijiaben at perfma.com Thu Jun 20 10:37:56 2019 From: nijiaben at perfma.com (=?utf-8?B?bmlqaWFiZW4=?=) Date: Thu, 20 Jun 2019 18:37:56 +0800 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> Message-ID: Yes Alan, I mean this ------------------ Original ------------------ From: "Alan Bateman"; Date: Thu, Jun 20, 2019 02:54 PM To: "nijiaben"; "David Holmes"; "serviceability-dev"; "jdk8u-dev"; "hotspot-runtime-dev"; Subject: Re: A Bug about the JVM Attach mechanism On 20/06/2019 05:10, nijiaben wrote: > : > I know this mechanism, can we provide means of recovery to avoid unavailability caused by accidental deletion? > Are you concerned about tmpreaper or cron jobs that periodically cleanup /tmp? There may indeed be an issue for applications that run for weeks or months. If someone is using jmap, jcmd or other tools using the attach API then it will trigger the attach listener to start. When they come back in a few weeks then the .java_pid file may have been removed so they cannot attach. Is this what what you are pointing out? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From aazores at redhat.com Thu Jun 20 13:43:03 2019 From: aazores at redhat.com (Andrew Azores) Date: Thu, 20 Jun 2019 09:43:03 -0400 Subject: OperatingSystemMXBean unaware of container memory limits Message-ID: Hi all, Apologies if this is not the most appropriate list, in which case please direct me where to go. I've noticed a surprising result from the com.sun.management.OperatingSystemMXBean implementation when running in a containerized (specifically, using Docker on Linux) environment. The bean appears to be container-aware for processors, in that running with Docker option `--cpus 1.0` for example, on a multicore system, will cause both java.lang.Runtime#availableProcessors and java.lang.management.OperatingSystemMXBean#getAvailableProcessors / com.sun.management.OperatingSystemMXBean#getAvailableProcessors to return 1. However, the Docker option `--memory 100M` (or any other limit value) is not reflected in the value returned by com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize, and instead the returned value is still the total physical memory of the host machine - of which only a small portion may actually be available to the "Operating System" of the JVM. Similarly for the methods regarding free physical memory, total swap, and free swap. I have attached a patch which adds a small reproducer to the existing MemoryAwareness test. This seems like a bug to me, since if the imposed container limit on processors as a resource is included as part of the "Operating System" resource reporting, then surely memory resources should be reported the same way. As I said, I found the current behaviour quite surprising. -- Andrew Azores Software Engineer, OpenJDK Team Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk-osmxbean-container-memory-test-01.patch Type: text/x-patch Size: 5408 bytes Desc: not available URL: From bob.vandette at oracle.com Thu Jun 20 14:16:00 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 20 Jun 2019 10:16:00 -0400 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: References: Message-ID: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> Hi Andrew, I am aware of the limitations of the OperatingSystemMXBean and was hoping to address these limitations during the implementation of https://bugs.openjdk.java.net/browse/JDK-8199944 . It would be helpful if you feel this is important to add some votes to this issue. Bob. > On Jun 20, 2019, at 9:43 AM, Andrew Azores wrote: > > Hi all, > > Apologies if this is not the most appropriate list, in which case > please direct me where to go. > > I've noticed a surprising result from the > com.sun.management.OperatingSystemMXBean implementation when running in > a containerized (specifically, using Docker on Linux) environment. The > bean appears to be container-aware for processors, in that running with > Docker option `--cpus 1.0` for example, on a multicore system, will > cause both java.lang.Runtime#availableProcessors and > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to > return 1. However, the Docker option `--memory 100M` (or any other > limit value) is not reflected in the value returned by > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize, > and instead the returned value is still the total physical memory of > the host machine - of which only a small portion may actually be > available to the "Operating System" of the JVM. Similarly for the > methods regarding free physical memory, total swap, and free swap. > > I have attached a patch which adds a small reproducer to the existing > MemoryAwareness test. > > This seems like a bug to me, since if the imposed container limit on > processors as a resource is included as part of the "Operating System" > resource reporting, then surely memory resources should be reported the > same way. As I said, I found the current behaviour quite surprising. > > -- > Andrew Azores > Software Engineer, OpenJDK Team > Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Thu Jun 20 14:49:53 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Thu, 20 Jun 2019 17:49:53 +0300 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: <057e627a-f488-0a30-d9e1-147627237383@oracle.com> References: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> <01902cdd-a0e8-4a6a-dc50-175cc00a2e3a@jetbrains.com> <057e627a-f488-0a30-d9e1-147627237383@oracle.com> Message-ID: <6c45bf9c-007c-dc6a-bf1a-6d7bf9ab5d50@jetbrains.com> Hi David, any news on https://bugs.openjdk.java.net/browse/JDK-8212117? I do not see any activity on this :( Thanks, Egor On 09-Apr-19 15:53, David Holmes wrote: > On 9/04/2019 7:36 pm, Egor Ushakov wrote: >> Hi David, >> >> you're right! The fix for JDK-8212117 should help here as well. >> After that fix we may want to revisit ValueContainer.findType >> implementors, currently they all (except for ArrayTypeImpl) >> delegates to ReferenceTypeImpl.findType (which ends up in >> classloader.visibleClasses). > > ArrayTypeImpl inherits findType from ReferenceTypeImpl. > > The issue is only the non-public findComponentType method. > >> Someone should clarify the difference between >> classLoader.visibleClasses and allClasses filtered by the classLoader >> instance then. > > That would be good, I just don't know if there is anyone who would > know (as opposed to trying to figure it out). > >> In my opinion fixing JDK-8212117 is risky and requires heavy testing, >> do you think it may be fixed any time soon? > > Yes it's under way but the person doing it is away this week. > > Thanks, > David > >> Thanks, >> Egor >> >> On 09-Apr-19 08:15, David Holmes wrote: >>> Hi Egor, >>> >>> I want to re-emphasise that once JDK-8212117 is fixed then this bug >>> should also be fixed. >>> >>> On 5/04/2019 8:30 pm, Egor Ushakov wrote: >>>> Hi David, thanks for your comments! >>>> >>>> I'm not sure how findComponentType worked in the current state: >>>> >>>> Type findComponentType(String signature) throws >>>> ClassNotLoadedException { >>>> 93 byte tag = (byte)signature.charAt(0); >>>> 94 if (PacketStream.isObjectTag(tag)) { >>>> 95 // It's a reference type >>>> 96 JNITypeParser parser = new JNITypeParser(componentSignature()); >>>> 97 List list = vm.classesByName(parser.typeName()); >>>> 98 Iterator iter = list.iterator(); >>>> 99 while (iter.hasNext()) { >>>> 100 ReferenceType type = iter.next(); >>>> 101 ClassLoaderReference cl = type.classLoader(); >>>> 102 if ((cl == null)? >>>> 103 (classLoader() == null) : >>>> 104 (cl.equals(classLoader()))) { >>>> 105 return type; >>>> 106 } >>>> 107 } >>>> 108 // Component class has not yet been loaded >>>> 109 throw new ClassNotLoadedException(componentTypeName()); >>>> 110 } else { >>>> 111 // It's a primitive type >>>> 112 return vm.primitiveTypeMirror(tag); >>>> 113 } >>>> ? 114???? } >>>> >>>> >>>> the method receives signature string but uses it only for object >>>> checking, then inside it does the search by componentSignature() >>>> instead... >>>> Most probably the method is always called passing >>>> componentSignature() string as a parameter anyway. >>>> >>>> Regarding the fix: >>>> the only thing I'm trying to change here is where the requested >>>> type name is looked at - loader.visibleClasses (this is where >>>> findType ends up) instead of vm.classesByName. >>>> This is how it works in all other implementors of >>>> com.sun.tools.jdi.ValueContainer.findType. >>> >>> Yes but I'm trying to determine why the difference exists - if we >>> already had loader.findType then why go to the bother of writing >>> findComponentType that way instead of just using findType? My >>> concern is that (ignoring the bug with not-initialized classes) the >>> set of classes returned by loader.visibleClasses may be different to >>> that which can be found via vm.classesByName. >>> >>> I'm not convinced we have adequate test coverage in this area. >>> >>>> ArrayTypeImpl.type() is unused, so I'm not sure how it was supposed >>>> to be used and where. >>> >>> Tracking the relationships between classes/interfaces here is quite >>> tricky and it had appeared to me that ArrayTypeImpl.type() could end >>> up getting used. But I've re-scanned the code and that seems not to >>> be the case. For good measure I changed it to always throw an >>> exception and re-ran all the JDI tests (though as I said coverage >>> seems limited) with no problems. >>> >>> If this is truly unused then we should delete it to avoid future >>> confusion - a separate RFE would be fine for that. >>> >>> Thanks, >>> David >>> >>>> I've run all jdi tests and see no regression, probably >>>> ClassNotLoadedException is never thrown in this case. >>>> >>>> Removed the test from the ProblemList in the new cr: >>>> http://cr.openjdk.java.net/~eushakov/8221503/webrev.01/ >>>> >>>> On 05-Apr-19 07:58, David Holmes wrote: >>>>> Hi Egor, >>>>> >>>>> This doesn't seem right to me sorry ... >>>>> >>>>> On 2/04/2019 7:42 pm, Egor Ushakov wrote: >>>>>> Please review the fix >>>>>> >>>>>> this test started to fail after the fix of >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146986 >>>>>> previously any call to ClassLoaderReference.visibleClasses as a >>>>>> side effect cached the results in >>>>>> VirtualMachineImpl.typesBySignature >>>>>> and made them available to any VirtualMachine.classesByName call. >>>>>> This is somewhat not consistent for unprepared classes, I >>>>>> reported that, check >>>>>> Bug 26148990 : JDI - VirtualMachine.allClasses does not return >>>>>> loaded but uninitialized class, >>>>> >>>>> That issue is now a duplicate of this core-libs issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8212117 >>>>> >>>>> which is in the process of being fixed. Once it is fixed then this >>>>> workaround would no longer be needed. >>>>> >>>>> That said I'm not at all clear how the proposed workaround >>>>> actually works-around the underlying issue. >>>>> >>>>>> but it seems that it allowed the ArrayTypeImpl.componentType to >>>>>> work even if the type was not prepared, >>>>>> check how ArrayTypeImpl#findComponentType uses vm.classesByName. >>>>>> It seems that ArrayTypeImpl#findComponentType should simply call >>>>>> findType for component signature. >>>>>> Just how the unused com.sun.tools.jdi.ArrayTypeImpl#type method >>>>>> works, not sure why it was dropped... >>>>> >>>>> The package-private: >>>>> >>>>> Type type() throws ClassNotLoadedException { >>>>> ??? return findType(elementSignature()); >>>>> } >>>>> >>>>> seems to have always existed but never been used as the >>>>> implementation for the public componentType() method (previously >>>>> elementType()). In fact the two methods appear to have different >>>>> requirements with regards to what they should be returning. AFAICS: >>>>> >>>>> - ArrayTypeImpl.type() returns the actual array type >>>>> - ArrayTypeImpl.componentType() returns the actual ultimate >>>>> component type >>>>> >>>>> i.e if I understand correctly, given double[][][] then >>>>> - ArrayTypeImpl.type() == double[][] >>>>> - ArrayTypeImpl.componentType() == double >>>>> >>>>> so implementing them both the same way can't possibly be correct! >>>>> >>>>>> bugid https://bugs.openjdk.java.net/browse/JDK-8221503 >>>>>> cr http://cr.openjdk.java.net/~eushakov/8221503/webrev.00/ >>>>>> >>>>>> Thanks! >>>>>> >>>>> >>>>> You'd also need to update the ProblemList so the test gets >>>>> re-enabled. >>>>> >>>>> diff -r 532e88de77eb test/hotspot/jtreg/ProblemList.txt >>>>> --- a/test/hotspot/jtreg/ProblemList.txt >>>>> +++ b/test/hotspot/jtreg/ProblemList.txt >>>>> @@ -161,8 +161,6 @@ >>>>> >>>>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>>>> 8065773 generic-all >>>>> >>>>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>>>> 8065773 generic-all >>>>> >>>>> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all >>>>> - >>>>> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >>>>> generic-all >>>>> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >>>>> generic-all >>>>> ?vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 >>>>> generic-all >>>>> >>>>> It also appears to me that the exception message of the >>>>> ClassNotLoadedException will be different now. Have you re-run all >>>>> the JDI tests? >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> -- >>>>>> Egor Ushakov >>>>>> Software Developer >>>>>> JetBrains >>>>>> http://www.jetbrains.com >>>>>> The Drive to Develop >>>>>> >>>> >>>> -- >>>> Egor Ushakov >>>> Software Developer >>>> JetBrains >>>> http://www.jetbrains.com >>>> The Drive to Develop >>>> >> -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From Alan.Bateman at oracle.com Thu Jun 20 15:49:04 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Jun 2019 16:49:04 +0100 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: <6c45bf9c-007c-dc6a-bf1a-6d7bf9ab5d50@jetbrains.com> References: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> <01902cdd-a0e8-4a6a-dc50-175cc00a2e3a@jetbrains.com> <057e627a-f488-0a30-d9e1-147627237383@oracle.com> <6c45bf9c-007c-dc6a-bf1a-6d7bf9ab5d50@jetbrains.com> Message-ID: <16d42ee3-99e3-e9d3-55cb-ebb41ffac565@oracle.com> On 20/06/2019 15:49, Egor Ushakov wrote: > Hi David, > > any news on https://bugs.openjdk.java.net/browse/JDK-8212117? > I do not see any activity on this :( cc'ing Brent as he has picked up this issue. I think we want to fix this and David has a patch in one of the linked issues. As it's changing long standing behavior in a sublte way then it will likely need a compatibility knob, the details of which need to be worked out before the CSR can be submitted. -Alan From serguei.spitsyn at oracle.com Thu Jun 20 19:13:12 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2019 12:13:12 -0700 Subject: RFR: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout In-Reply-To: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> References: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> Message-ID: <5ddcfc80-96db-202a-2d23-823441705156@oracle.com> Hi Daniil, It looks good to me. Thanks, Serguei On 6/19/19 21:02, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of serviceability/dcmd/framework/* tests on Linux platform. > > The problem here is that get_namespace_pid() method, that is called by mmap_attach_shared () that in turn is called by PerfMemory::attach(), > tries to read the namespace pid information from /proc//status file. However, it doesn't check that the error indicator associated with > stream is set that results in the endless loop (lines 664-677) if the process terminates after /proc//status was opened (line 659) > and checked for null (line 661). > > 658 snprintf(fname, sizeof(fname), "/proc/%d/status", vmid); > 659 FILE *fp = fopen(fname, "r"); > 660 > 661 if (fp) { > 662 int pid, nspid; > 663 int ret; > 664 while (!feof(fp)) { > 665 ret = fscanf(fp, "NSpid: %d %d", &pid, &nspid); > 666 if (ret == 1) { > 667 break; > 668 } > 669 if (ret == 2) { > 670 retpid = nspid; > 671 break; > 672 } > 673 for (;;) { > 674 int ch = fgetc(fp); > 675 if (ch == EOF || ch == (int)'\n') break; > 676 } > 677 } > 678 fclose(fp); > 679 } > > The fix adds the check for the error indicator to ensure that the "while" loop terminates properly if the file no longer exists. > > Issues [3] and [4] have the same cause and will be closed as duplicates of this issue. > > Testing: Mach5 hotspot_serviceability tests succeeded, tier1,tier2, and tier3 tests are in progress. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8220175/webrev.01/ > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8220175 > [3] https://bugs.openjdk.java.net/browse/JDK-8223600 > [4] https://bugs.openjdk.java.net/browse/JDK-8217351 > > Thanks! > -Daniil > > From volker.simonis at gmail.com Thu Jun 20 20:31:58 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Jun 2019 23:31:58 +0300 Subject: Slow class loading when running JVM in debug mode In-Reply-To: <0ae9a535-4fc7-93e3-ebc5-0a1d2ad9b5e9@jetbrains.com> References: <0ae9a535-4fc7-93e3-ebc5-0a1d2ad9b5e9@jetbrains.com> Message-ID: Hi Egor, yes, I?d say this is something well known. The reason for this is that a debugging agent will request some JVMTI capabilities like "can_access_local_variables" which can only be requested at JVM startup. However, once these capabilities have been taken, certain kinds of optimizations like for example Escape Analysis, can?t be done anymore which results in a performance degradation even if you don?t ever attach a debugger. We?ve always enabled debugging in our commercial SAP JVM and called it ?Debugging on Demand? but usually didn?t observed any performance slowdown of more than 3-5% at most. We?ve started contributing some of the improvements we?ve done to make this possible to the OpenJDK. I?ve not looked into your concrete class loading use case. Maybe it?s possible to improve that. First you have to check by which JVMTI capability it is triggered and if that capability is really necessary for debugging and can only be requested at startup. If the answer is yes, you can still check if it?s not possible to improve the implementation of that capability in order to get a better runtime behavior. Regards, Volker Egor Ushakov schrieb am Do. 20. Juni 2019 um 11:36: > Hi everyone! > > we have detected that a process started with the debug agent (even when > debugger is not actually attached) may run significantly slower than > without the agent, see: > https://youtrack.jetbrains.com/issue/JBR-1611 > We all thought that without the debugger attached there should not be a > difference. > Is that something well known? Should we file a bug? > > Thanks, > Egor > > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jun 20 20:49:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Jun 2019 13:49:25 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> Message-ID: Sorry it took me a while to understand the specifics of the problem. :) David On 20/06/2019 3:37 am, nijiaben wrote: > Yes Alan, I mean this > ------------------?Original?------------------ > *From: *?"Alan Bateman"; > *Date: *?Thu, Jun 20, 2019 02:54 PM > *To: *?"nijiaben"; "David > Holmes"; > "serviceability-dev"; > "jdk8u-dev"; > "hotspot-runtime-dev"; > *Subject: *?Re: A Bug about the JVM Attach mechanism > On 20/06/2019 05:10, nijiaben wrote: > > : > > I know this mechanism, can we provide means of recovery to avoid > unavailability caused by accidental deletion? > > > Are you concerned about tmpreaper or cron jobs that periodically cleanup > /tmp? There may indeed be an issue for applications that run for weeks > or months. If someone is using jmap, jcmd or other tools using the > attach API then it will trigger the attach listener to start. When they > come back in a few weeks then the .java_pid file may have been > removed so they cannot attach. Is this what what you are pointing out? > > -Alan From chris.plummer at oracle.com Thu Jun 20 21:42:39 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Jun 2019 14:42:39 -0700 Subject: Slow class loading when running JVM in debug mode In-Reply-To: References: <0ae9a535-4fc7-93e3-ebc5-0a1d2ad9b5e9@jetbrains.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jun 20 21:56:55 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2019 14:56:55 -0700 Subject: RFR (S): 8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: Message-ID: <90edcd66-d365-bf08-18cc-026d82e92bc0@oracle.com> PING ... On 6/19/19 18:59, serguei.spitsyn at oracle.com wrote: > Sorry, forgot the? bug title to add to the email subject. > > Thanks, > Serguei > > On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >> Please review a fix for test bug: >> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >> >> >> Summary: >> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter event >> in the >> ?increment() method sometime is not enough (especially when the JFR >> is enabled). >> ?The fix implement an approach to ensure the event has posted before >> the worker >> ?thread goes to the next iteration. >> ?Also, another check is added to diagnose if any of two worker threads >> ?(tc04t001Thread) has been interrupted by timeout. >> ?In fact, we have many other tests which miss this kind of check and >> diagnostics. >> ?We may want to consider fixing other cases if we encounter this >> eventually happens. >> >> Testing: >> ?A mach5 test submission is in progress. >> >> Thanks, >> Serguei >> > From chris.plummer at oracle.com Thu Jun 20 23:04:37 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Jun 2019 16:04:37 -0700 Subject: RFR (S): 8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: <90edcd66-d365-bf08-18cc-026d82e92bc0@oracle.com> References: <90edcd66-d365-bf08-18cc-026d82e92bc0@oracle.com> Message-ID: Looks good. Chris On 6/20/19 2:56 PM, serguei.spitsyn at oracle.com wrote: > PING ... > > > On 6/19/19 18:59, serguei.spitsyn at oracle.com wrote: >> Sorry, forgot the? bug title to add to the email subject. >> >> Thanks, >> Serguei >> >> On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >>> Please review a fix for test bug: >>> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >>> >>> >>> Summary: >>> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter event >>> in the >>> ?increment() method sometime is not enough (especially when the JFR >>> is enabled). >>> ?The fix implement an approach to ensure the event has posted before >>> the worker >>> ?thread goes to the next iteration. >>> ?Also, another check is added to diagnose if any of two worker threads >>> ?(tc04t001Thread) has been interrupted by timeout. >>> ?In fact, we have many other tests which miss this kind of check and >>> diagnostics. >>> ?We may want to consider fixing other cases if we encounter this >>> eventually happens. >>> >>> Testing: >>> ?A mach5 test submission is in progress. >>> >>> Thanks, >>> Serguei >>> >> > From daniel.daugherty at oracle.com Thu Jun 20 23:17:36 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 20 Jun 2019 19:17:36 -0400 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: Message-ID: <5ed5df60-6e7c-6929-71df-cbe4c54f02f4@oracle.com> On 6/19/19 9:59 PM, serguei.spitsyn at oracle.com wrote: > Sorry, forgot the? bug title to add to the email subject. > > Thanks, > Serguei > > On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >> Please review a fix for test bug: >> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001.java ??? L164: ??????????? if (enterEventsCount() == lastEnterEventsCount + 1) { ??????? I wonder if '==' should be '>=' to more resilient against ??????? multiple events. I tried to figure out the flow control ??????? for the event posting, but I couldn't figure it out with ??????? a quick look. ??? L170: ??????? if (enterEventsCount() != lastEnterEventsCount + 1) { ??????? Similarly I wonder if this should be: ????????????????? if (enterEventsCount() == lastEnterEventsCount) { ??????? to simply detect that the count hasn't changed. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp ??? No comments. Thumbs up. My concerns above may not be correct depending on how the test really works. Your call. Dan >> >> Summary: >> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter event >> in the >> ?increment() method sometime is not enough (especially when the JFR >> is enabled). >> ?The fix implement an approach to ensure the event has posted before >> the worker >> ?thread goes to the next iteration. >> ?Also, another check is added to diagnose if any of two worker threads >> ?(tc04t001Thread) has been interrupted by timeout. >> ?In fact, we have many other tests which miss this kind of check and >> diagnostics. >> ?We may want to consider fixing other cases if we encounter this >> eventually happens. >> >> Testing: >> ?A mach5 test submission is in progress. >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Thu Jun 20 23:20:55 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2019 16:20:55 -0700 Subject: RFR (S): 8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: <90edcd66-d365-bf08-18cc-026d82e92bc0@oracle.com> Message-ID: Thanks a lot, Chris! Serguei On 6/20/19 16:04, Chris Plummer wrote: > Looks good. > > Chris > > On 6/20/19 2:56 PM, serguei.spitsyn at oracle.com wrote: >> PING ... >> >> >> On 6/19/19 18:59, serguei.spitsyn at oracle.com wrote: >>> Sorry, forgot the? bug title to add to the email subject. >>> >>> Thanks, >>> Serguei >>> >>> On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >>>> Please review a fix for test bug: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >>>> >>>> >>>> Summary: >>>> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter >>>> event in the >>>> ?increment() method sometime is not enough (especially when the JFR >>>> is enabled). >>>> ?The fix implement an approach to ensure the event has posted >>>> before the worker >>>> ?thread goes to the next iteration. >>>> ?Also, another check is added to diagnose if any of two worker threads >>>> ?(tc04t001Thread) has been interrupted by timeout. >>>> ?In fact, we have many other tests which miss this kind of check >>>> and diagnostics. >>>> ?We may want to consider fixing other cases if we encounter this >>>> eventually happens. >>>> >>>> Testing: >>>> ?A mach5 test submission is in progress. >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > > From alexey.menkov at oracle.com Thu Jun 20 23:30:49 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 20 Jun 2019 16:30:49 -0700 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: Message-ID: <76b5fdcb-0caa-070f-8a39-55d7454f9a41@oracle.com> Hi Serguei, Main idea looks good. I'd simplify threads[i].join/threads[i].done logic with CountDownLatch (note also exception message ("Thread-" + i + " was interrupted by timeout!") is not correct): in tc04t001 class add final static CountDownLatch threadsDoneSignal = new CountDownLatch(THREADS_LIMIT); replace cycle of threads[i].join / threads[i].done check with if (!threadsDoneSignal.await(timeout, TimeUnit.MILLISECONDS)) { throw new RuntimeException("Threads timeout"); } at the end of tc04t001Thread.run replace done = true; with tc04t001.threadsDoneSignal.countDown(); --alex On 06/19/2019 18:59, serguei.spitsyn at oracle.com wrote: > Sorry, forgot the? bug title to add to the email subject. > > Thanks, > Serguei > > On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >> Please review a fix for test bug: >> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >> >> >> Summary: >> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter event >> in the >> ?increment() method sometime is not enough (especially when the JFR is >> enabled). >> ?The fix implement an approach to ensure the event has posted before >> the worker >> ?thread goes to the next iteration. >> ?Also, another check is added to diagnose if any of two worker threads >> ?(tc04t001Thread) has been interrupted by timeout. >> ?In fact, we have many other tests which miss this kind of check and >> diagnostics. >> ?We may want to consider fixing other cases if we encounter this >> eventually happens. >> >> Testing: >> ?A mach5 test submission is in progress. >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Thu Jun 20 23:32:05 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2019 16:32:05 -0700 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: <5ed5df60-6e7c-6929-71df-cbe4c54f02f4@oracle.com> References: <5ed5df60-6e7c-6929-71df-cbe4c54f02f4@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jun 20 23:59:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2019 16:59:21 -0700 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: <76b5fdcb-0caa-070f-8a39-55d7454f9a41@oracle.com> References: <76b5fdcb-0caa-070f-8a39-55d7454f9a41@oracle.com> Message-ID: Hi Alex, Thank you a lot for review! On 6/20/19 16:30, Alex Menkov wrote: > Hi Serguei, > > Main idea looks good. > > I'd simplify threads[i].join/threads[i].done logic with CountDownLatch > (note also exception message ("Thread-" + i + " was interrupted by > timeout!") is not correct): > > in tc04t001 class add > ? final static CountDownLatch threadsDoneSignal = new > CountDownLatch(THREADS_LIMIT); > > replace cycle of threads[i].join / threads[i].done check with > ? if (!threadsDoneSignal.await(timeout, TimeUnit.MILLISECONDS)) { > ??? throw new RuntimeException("Threads timeout"); > ? } > at the end of tc04t001Thread.run > replace > ? done = true; > with > ? tc04t001.threadsDoneSignal.countDown(); Okay, thanks! I've made this change. The updated webrev is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.2/ It also includes the changes suggested by Dan. Thanks, Serguei > > --alex > > On 06/19/2019 18:59, serguei.spitsyn at oracle.com wrote: >> Sorry, forgot the? bug title to add to the email subject. >> >> Thanks, >> Serguei >> >> On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >>> Please review a fix for test bug: >>> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >>> >>> >>> Summary: >>> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter event >>> in the >>> ?increment() method sometime is not enough (especially when the JFR >>> is enabled). >>> ?The fix implement an approach to ensure the event has posted before >>> the worker >>> ?thread goes to the next iteration. >>> ?Also, another check is added to diagnose if any of two worker threads >>> ?(tc04t001Thread) has been interrupted by timeout. >>> ?In fact, we have many other tests which miss this kind of check and >>> diagnostics. >>> ?We may want to consider fixing other cases if we encounter this >>> eventually happens. >>> >>> Testing: >>> ?A mach5 test submission is in progress. >>> >>> Thanks, >>> Serguei >>> >> From alexey.menkov at oracle.com Fri Jun 21 00:22:31 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 20 Jun 2019 17:22:31 -0700 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: <76b5fdcb-0caa-070f-8a39-55d7454f9a41@oracle.com> Message-ID: LGTM --alex On 06/20/2019 16:59, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Thank you a lot for review! > > > > On 6/20/19 16:30, Alex Menkov wrote: >> Hi Serguei, >> >> Main idea looks good. >> >> I'd simplify threads[i].join/threads[i].done logic with CountDownLatch >> (note also exception message ("Thread-" + i + " was interrupted by >> timeout!") is not correct): >> >> in tc04t001 class add >> ? final static CountDownLatch threadsDoneSignal = new >> CountDownLatch(THREADS_LIMIT); >> >> replace cycle of threads[i].join / threads[i].done check with >> ? if (!threadsDoneSignal.await(timeout, TimeUnit.MILLISECONDS)) { >> ??? throw new RuntimeException("Threads timeout"); >> ? } >> at the end of tc04t001Thread.run >> replace >> ? done = true; >> with >> ? tc04t001.threadsDoneSignal.countDown(); > > Okay, thanks! > I've made this change. > > The updated webrev is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.2/ > > > It also includes the changes suggested by Dan. > > Thanks, > Serguei > >> >> --alex >> >> On 06/19/2019 18:59, serguei.spitsyn at oracle.com wrote: >>> Sorry, forgot the? bug title to add to the email subject. >>> >>> Thanks, >>> Serguei >>> >>> On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >>>> Please review a fix for test bug: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >>>> >>>> >>>> Summary: >>>> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter event >>>> in the >>>> ?increment() method sometime is not enough (especially when the JFR >>>> is enabled). >>>> ?The fix implement an approach to ensure the event has posted before >>>> the worker >>>> ?thread goes to the next iteration. >>>> ?Also, another check is added to diagnose if any of two worker threads >>>> ?(tc04t001Thread) has been interrupted by timeout. >>>> ?In fact, we have many other tests which miss this kind of check and >>>> diagnostics. >>>> ?We may want to consider fixing other cases if we encounter this >>>> eventually happens. >>>> >>>> Testing: >>>> ?A mach5 test submission is in progress. >>>> >>>> Thanks, >>>> Serguei >>>> >>> > From serguei.spitsyn at oracle.com Fri Jun 21 00:23:31 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2019 17:23:31 -0700 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: <76b5fdcb-0caa-070f-8a39-55d7454f9a41@oracle.com> Message-ID: Thanks! Serguei On 6/20/19 17:22, Alex Menkov wrote: > LGTM > > --alex > > On 06/20/2019 16:59, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Thank you a lot for review! >> >> >> >> On 6/20/19 16:30, Alex Menkov wrote: >>> Hi Serguei, >>> >>> Main idea looks good. >>> >>> I'd simplify threads[i].join/threads[i].done logic with CountDownLatch >>> (note also exception message ("Thread-" + i + " was interrupted by >>> timeout!") is not correct): >>> >>> in tc04t001 class add >>> ? final static CountDownLatch threadsDoneSignal = new >>> CountDownLatch(THREADS_LIMIT); >>> >>> replace cycle of threads[i].join / threads[i].done check with >>> ? if (!threadsDoneSignal.await(timeout, TimeUnit.MILLISECONDS)) { >>> ??? throw new RuntimeException("Threads timeout"); >>> ? } >>> at the end of tc04t001Thread.run >>> replace >>> ? done = true; >>> with >>> ? tc04t001.threadsDoneSignal.countDown(); >> >> Okay, thanks! >> I've made this change. >> >> The updated webrev is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.2/ >> >> >> It also includes the changes suggested by Dan. >> >> Thanks, >> Serguei >> >>> >>> --alex >>> >>> On 06/19/2019 18:59, serguei.spitsyn at oracle.com wrote: >>>> Sorry, forgot the? bug title to add to the email subject. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please review a fix for test bug: >>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >>>>> >>>>> >>>>> Summary: >>>>> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter >>>>> event in the >>>>> ?increment() method sometime is not enough (especially when the >>>>> JFR is enabled). >>>>> ?The fix implement an approach to ensure the event has posted >>>>> before the worker >>>>> ?thread goes to the next iteration. >>>>> ?Also, another check is added to diagnose if any of two worker >>>>> threads >>>>> ?(tc04t001Thread) has been interrupted by timeout. >>>>> ?In fact, we have many other tests which miss this kind of check >>>>> and diagnostics. >>>>> ?We may want to consider fixing other cases if we encounter this >>>>> eventually happens. >>>>> >>>>> Testing: >>>>> ?A mach5 test submission is in progress. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >> From daniel.daugherty at oracle.com Fri Jun 21 00:36:58 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 20 Jun 2019 20:36:58 -0400 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: <76b5fdcb-0caa-070f-8a39-55d7454f9a41@oracle.com> Message-ID: <6cc082a7-5aa0-133f-af17-3971e8d0b129@oracle.com> On 6/20/19 7:59 PM, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Thank you a lot for review! > > > > On 6/20/19 16:30, Alex Menkov wrote: >> Hi Serguei, >> >> Main idea looks good. >> >> I'd simplify threads[i].join/threads[i].done logic with CountDownLatch >> (note also exception message ("Thread-" + i + " was interrupted by >> timeout!") is not correct): >> >> in tc04t001 class add >> ? final static CountDownLatch threadsDoneSignal = new >> CountDownLatch(THREADS_LIMIT); >> >> replace cycle of threads[i].join / threads[i].done check with >> ? if (!threadsDoneSignal.await(timeout, TimeUnit.MILLISECONDS)) { >> ??? throw new RuntimeException("Threads timeout"); >> ? } >> at the end of tc04t001Thread.run >> replace >> ? done = true; >> with >> ? tc04t001.threadsDoneSignal.countDown(); > > Okay, thanks! > I've made this change. > > The updated webrev is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.2/ > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001.java ? ? L165: ??????? System.out.println("Thread-" + i + ": increment event: " + (lastEnterEventsCount + 1)); ??????? nit - trailing space at the end of this line (jcheck) ??????? Do you want "(lastEnterEventsCount + 1)" or do you ??????? want "enterEventsCount()" here? test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp ??? No comments. Thumbs up. No need for a new webrev if you choose to change the message above. Dan > > It also includes the changes suggested by Dan. > > Thanks, > Serguei > >> >> --alex >> >> On 06/19/2019 18:59, serguei.spitsyn at oracle.com wrote: >>> Sorry, forgot the? bug title to add to the email subject. >>> >>> Thanks, >>> Serguei >>> >>> On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >>>> Please review a fix for test bug: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >>>> >>>> >>>> Summary: >>>> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter >>>> event in the >>>> ?increment() method sometime is not enough (especially when the JFR >>>> is enabled). >>>> ?The fix implement an approach to ensure the event has posted >>>> before the worker >>>> ?thread goes to the next iteration. >>>> ?Also, another check is added to diagnose if any of two worker threads >>>> ?(tc04t001Thread) has been interrupted by timeout. >>>> ?In fact, we have many other tests which miss this kind of check >>>> and diagnostics. >>>> ?We may want to consider fixing other cases if we encounter this >>>> eventually happens. >>>> >>>> Testing: >>>> ?A mach5 test submission is in progress. >>>> >>>> Thanks, >>>> Serguei >>>> >>> > > From serguei.spitsyn at oracle.com Fri Jun 21 00:47:48 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2019 17:47:48 -0700 Subject: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events In-Reply-To: <6cc082a7-5aa0-133f-af17-3971e8d0b129@oracle.com> References: <76b5fdcb-0caa-070f-8a39-55d7454f9a41@oracle.com> <6cc082a7-5aa0-133f-af17-3971e8d0b129@oracle.com> Message-ID: On 6/20/19 17:36, Daniel D. Daugherty wrote: > On 6/20/19 7:59 PM, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Thank you a lot for review! >> >> >> >> On 6/20/19 16:30, Alex Menkov wrote: >>> Hi Serguei, >>> >>> Main idea looks good. >>> >>> I'd simplify threads[i].join/threads[i].done logic with CountDownLatch >>> (note also exception message ("Thread-" + i + " was interrupted by >>> timeout!") is not correct): >>> >>> in tc04t001 class add >>> ? final static CountDownLatch threadsDoneSignal = new >>> CountDownLatch(THREADS_LIMIT); >>> >>> replace cycle of threads[i].join / threads[i].done check with >>> ? if (!threadsDoneSignal.await(timeout, TimeUnit.MILLISECONDS)) { >>> ??? throw new RuntimeException("Threads timeout"); >>> ? } >>> at the end of tc04t001Thread.run >>> replace >>> ? done = true; >>> with >>> ? tc04t001.threadsDoneSignal.countDown(); >> >> Okay, thanks! >> I've made this change. >> >> The updated webrev is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.2/ >> > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001.java > > ? ? L165: ??????? System.out.println("Thread-" + i + ": increment > event: " + (lastEnterEventsCount + 1)); > ??????? nit - trailing space at the end of this line (jcheck) > > ??????? Do you want "(lastEnterEventsCount + 1)" or do you > ??????? want "enterEventsCount()" here? It has to be the same. But I'll change it to enterEventsCount() to follow the suggested fix logic. Thanks! Serguei: > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp > > ??? No comments. > > Thumbs up. No need for a new webrev if you choose to change > the message above. > > Dan > >> >> It also includes the changes suggested by Dan. >> >> Thanks, >> Serguei >> >>> >>> --alex >>> >>> On 06/19/2019 18:59, serguei.spitsyn at oracle.com wrote: >>>> Sorry, forgot the? bug title to add to the email subject. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 6/19/19 6:09 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please review a fix for test bug: >>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223736 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223736-mon-events-test.1/ >>>>> >>>>> >>>>> Summary: >>>>> ?It seems that waiting for 0.5 sec for a MonitorContendedEnter >>>>> event in the >>>>> ?increment() method sometime is not enough (especially when the >>>>> JFR is enabled). >>>>> ?The fix implement an approach to ensure the event has posted >>>>> before the worker >>>>> ?thread goes to the next iteration. >>>>> ?Also, another check is added to diagnose if any of two worker >>>>> threads >>>>> ?(tc04t001Thread) has been interrupted by timeout. >>>>> ?In fact, we have many other tests which miss this kind of check >>>>> and diagnostics. >>>>> ?We may want to consider fixing other cases if we encounter this >>>>> eventually happens. >>>>> >>>>> Testing: >>>>> ?A mach5 test submission is in progress. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >> >> > From daniil.x.titov at oracle.com Fri Jun 21 01:42:45 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 20 Jun 2019 18:42:45 -0700 Subject: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout In-Reply-To: <83f80d7c-4477-8b52-b3e3-16554ec9c161@oracle.com> References: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> <83f80d7c-4477-8b52-b3e3-16554ec9c161@oracle.com> Message-ID: Thank you, Chris and Serguei, for reviewing this change. I did more testing with a test program on Linux that repeats get_namespace_pid() method and reads from the real file ( the copy of /proc//status). I paused the program after the first several lines ( but not "NSpid:" line) where processed and deleted all lines in the status file before " NSpid: ..." line in order to this line became the first in the edited file. After that the program continues in the while loop but it seems as the original file content was already buffered and the program just continues over the original unedited lines and successfully found the match. Best regards, Daniil ?On 6/19/19, 9:13 PM, "Chris Plummer" wrote: Hi Daniil, I think your fix is good, although I wonder about the robustness of this function given that the status file can change while it is reading it. I wonder if it can return a false negative because it never saw the matching line. This could happen if a line gets deleted, causing the matching line to suddenly be earlier in the file, possibly before the current location being read. Anyway, that's not really related to the current issue or fix, but if you think it might be an issue maybe a bug should be filed for it. thanks, Chris On 6/19/19 9:02 PM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of serviceability/dcmd/framework/* tests on Linux platform. > > The problem here is that get_namespace_pid() method, that is called by mmap_attach_shared () that in turn is called by PerfMemory::attach(), > tries to read the namespace pid information from /proc//status file. However, it doesn't check that the error indicator associated with > stream is set that results in the endless loop (lines 664-677) if the process terminates after /proc//status was opened (line 659) > and checked for null (line 661). > > 658 snprintf(fname, sizeof(fname), "/proc/%d/status", vmid); > 659 FILE *fp = fopen(fname, "r"); > 660 > 661 if (fp) { > 662 int pid, nspid; > 663 int ret; > 664 while (!feof(fp)) { > 665 ret = fscanf(fp, "NSpid: %d %d", &pid, &nspid); > 666 if (ret == 1) { > 667 break; > 668 } > 669 if (ret == 2) { > 670 retpid = nspid; > 671 break; > 672 } > 673 for (;;) { > 674 int ch = fgetc(fp); > 675 if (ch == EOF || ch == (int)'\n') break; > 676 } > 677 } > 678 fclose(fp); > 679 } > > The fix adds the check for the error indicator to ensure that the "while" loop terminates properly if the file no longer exists. > > Issues [3] and [4] have the same cause and will be closed as duplicates of this issue. > > Testing: Mach5 hotspot_serviceability tests succeeded, tier1,tier2, and tier3 tests are in progress. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8220175/webrev.01/ > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8220175 > [3] https://bugs.openjdk.java.net/browse/JDK-8223600 > [4] https://bugs.openjdk.java.net/browse/JDK-8217351 > > Thanks! > -Daniil > > From chris.plummer at oracle.com Fri Jun 21 02:39:06 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Jun 2019 19:39:06 -0700 Subject: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout In-Reply-To: References: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> <83f80d7c-4477-8b52-b3e3-16554ec9c161@oracle.com> Message-ID: Thanks for looking into this. Chris On 6/20/19 6:42 PM, Daniil Titov wrote: > Thank you, Chris and Serguei, for reviewing this change. > > I did more testing with a test program on Linux that repeats get_namespace_pid() method and reads from the real file ( the copy of /proc//status). > I paused the program after the first several lines ( but not "NSpid:" line) where processed and deleted all lines in the status file before " NSpid: ..." line in order > to this line became the first in the edited file. After that the program continues in the while loop but it seems as the original file content was > already buffered and the program just continues over the original unedited lines and successfully found the match. > > Best regards, > Daniil > > ?On 6/19/19, 9:13 PM, "Chris Plummer" wrote: > > Hi Daniil, > > I think your fix is good, although I wonder about the robustness of this > function given that the status file can change while it is reading it. I > wonder if it can return a false negative because it never saw the > matching line. This could happen if a line gets deleted, causing the > matching line to suddenly be earlier in the file, possibly before the > current location being read. Anyway, that's not really related to the > current issue or fix, but if you think it might be an issue maybe a bug > should be filed for it. > > thanks, > > Chris > > On 6/19/19 9:02 PM, Daniil Titov wrote: > > Please review the change that fixes an intermittent failure of serviceability/dcmd/framework/* tests on Linux platform. > > > > The problem here is that get_namespace_pid() method, that is called by mmap_attach_shared () that in turn is called by PerfMemory::attach(), > > tries to read the namespace pid information from /proc//status file. However, it doesn't check that the error indicator associated with > > stream is set that results in the endless loop (lines 664-677) if the process terminates after /proc//status was opened (line 659) > > and checked for null (line 661). > > > > 658 snprintf(fname, sizeof(fname), "/proc/%d/status", vmid); > > 659 FILE *fp = fopen(fname, "r"); > > 660 > > 661 if (fp) { > > 662 int pid, nspid; > > 663 int ret; > > 664 while (!feof(fp)) { > > 665 ret = fscanf(fp, "NSpid: %d %d", &pid, &nspid); > > 666 if (ret == 1) { > > 667 break; > > 668 } > > 669 if (ret == 2) { > > 670 retpid = nspid; > > 671 break; > > 672 } > > 673 for (;;) { > > 674 int ch = fgetc(fp); > > 675 if (ch == EOF || ch == (int)'\n') break; > > 676 } > > 677 } > > 678 fclose(fp); > > 679 } > > > > The fix adds the check for the error indicator to ensure that the "while" loop terminates properly if the file no longer exists. > > > > Issues [3] and [4] have the same cause and will be closed as duplicates of this issue. > > > > Testing: Mach5 hotspot_serviceability tests succeeded, tier1,tier2, and tier3 tests are in progress. > > > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8220175/webrev.01/ > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8220175 > > [3] https://bugs.openjdk.java.net/browse/JDK-8223600 > > [4] https://bugs.openjdk.java.net/browse/JDK-8217351 > > > > Thanks! > > -Daniil > > > > > > > > From serguei.spitsyn at oracle.com Fri Jun 21 05:24:26 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Jun 2019 22:24:26 -0700 Subject: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed Message-ID: <19c92bb0-0cb3-0626-6609-0c3f938d22a2@oracle.com> An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Fri Jun 21 08:22:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 Jun 2019 10:22:18 +0200 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> Message-ID: Hi Bob, On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: > Hi Andrew, > > I am aware of the limitations of the OperatingSystemMXBean and was > hoping to address these limitations during the implementation of > https://bugs.openjdk.java.net/browse/JDK-8199944. > > It would be helpful if you feel this is important to add some votes > to this issue. It seems strange that the getAvailableProcessors() returns the container limit, while the memory limits are for the physical host. If anything, shouldn't they agree (both physical host or both container limits)? When I briefly looked into it initially it seems to be a side-effect of what is being used by the JDK code implementation-wise. IIRC getAvailableProcessors() uses a runtime call. Memory reporting has it's own logic[1], thus not reporting the container limit. This seems weird from a consistency perspective. Thoughts? If I understand you correctly, you are arguing that container reporting should go into its own MX bean. On the other hand, CPU reporting for the OS MX bean is container aware already. That makes me believe we should rather make this consistent before evaluating a new MX bean. Thanks, Severin [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 > Bob. > > > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > > wrote: > > > > Hi all, > > > > Apologies if this is not the most appropriate list, in which case > > please direct me where to go. > > > > I've noticed a surprising result from the > > com.sun.management.OperatingSystemMXBean implementation when > > running in > > a containerized (specifically, using Docker on Linux) environment. > > The > > bean appears to be container-aware for processors, in that running > > with > > Docker option `--cpus 1.0` for example, on a multicore system, will > > cause both java.lang.Runtime#availableProcessors and > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to > > return 1. However, the Docker option `--memory 100M` (or any other > > limit value) is not reflected in the value returned by > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize > > , > > and instead the returned value is still the total physical memory > > of > > the host machine - of which only a small portion may actually be > > available to the "Operating System" of the JVM. Similarly for the > > methods regarding free physical memory, total swap, and free swap. > > > > I have attached a patch which adds a small reproducer to the > > existing > > MemoryAwareness test. > > > > This seems like a bug to me, since if the imposed container limit > > on > > processors as a resource is included as part of the "Operating > > System" > > resource reporting, then surely memory resources should be reported > > the > > same way. As I said, I found the current behaviour quite > > surprising. > > > > -- > > Andrew Azores > > Software Engineer, OpenJDK Team > > Red Hat > > > > From neugens.limasoftware at gmail.com Fri Jun 21 10:06:18 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 21 Jun 2019 12:06:18 +0200 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> Message-ID: The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data. I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think. Bob, do you have some design ideas to share regarding the new interface? I think this may be an interesting project to pick up, even for students wanting to write a thesis, as it seems time is a limiting factor here for you to work on that? Cheers, Mario On Fri 21. Jun 2019 at 10:53, Severin Gehwolf wrote: > Hi Bob, > > On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: > > Hi Andrew, > > > > I am aware of the limitations of the OperatingSystemMXBean and was > > hoping to address these limitations during the implementation of > > https://bugs.openjdk.java.net/browse/JDK-8199944. > > > > It would be helpful if you feel this is important to add some votes > > to this issue. > > It seems strange that the getAvailableProcessors() returns the > container limit, while the memory limits are for the physical host. If > anything, shouldn't they agree (both physical host or both container > limits)? > > When I briefly looked into it initially it seems to be a side-effect of > what is being used by the JDK code implementation-wise. IIRC > getAvailableProcessors() uses a runtime call. Memory reporting has it's > own logic[1], thus not reporting the container limit. > > This seems weird from a consistency perspective. Thoughts? > > If I understand you correctly, you are arguing that container reporting > should go into its own MX bean. On the other hand, CPU reporting for > the OS MX bean is container aware already. That makes me believe we > should rather make this consistent before evaluating a new MX bean. > > Thanks, > Severin > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 > > > > Bob. > > > > > > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > > > wrote: > > > > > > Hi all, > > > > > > Apologies if this is not the most appropriate list, in which case > > > please direct me where to go. > > > > > > I've noticed a surprising result from the > > > com.sun.management.OperatingSystemMXBean implementation when > > > running in > > > a containerized (specifically, using Docker on Linux) environment. > > > The > > > bean appears to be container-aware for processors, in that running > > > with > > > Docker option `--cpus 1.0` for example, on a multicore system, will > > > cause both java.lang.Runtime#availableProcessors and > > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / > > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to > > > return 1. However, the Docker option `--memory 100M` (or any other > > > limit value) is not reflected in the value returned by > > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize > > > , > > > and instead the returned value is still the total physical memory > > > of > > > the host machine - of which only a small portion may actually be > > > available to the "Operating System" of the JVM. Similarly for the > > > methods regarding free physical memory, total swap, and free swap. > > > > > > I have attached a patch which adds a small reproducer to the > > > existing > > > MemoryAwareness test. > > > > > > This seems like a bug to me, since if the imposed container limit > > > on > > > processors as a resource is included as part of the "Operating > > > System" > > > resource reporting, then surely memory resources should be reported > > > the > > > same way. As I said, I found the current behaviour quite > > > surprising. > > > > > > -- > > > Andrew Azores > > > Software Engineer, OpenJDK Team > > > Red Hat > > > > > > > > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Fri Jun 21 10:06:32 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Fri, 21 Jun 2019 13:06:32 +0300 Subject: Slow class loading when running JVM in debug mode In-Reply-To: References: <0ae9a535-4fc7-93e3-ebc5-0a1d2ad9b5e9@jetbrains.com> Message-ID: <074598ed-c337-a0cd-7c78-10e587de8431@jetbrains.com> Will have a look, thanks for advices! On 21-Jun-19 00:42, Chris Plummer wrote: > With respect to the specific issue brought up in > https://youtrack.jetbrains.com/issue/JBR-1611: > > "If we look into the code, we'll see that whenever a new class is > loaded and an event about it is delivered, when a garbage collection > has occurred, classTrack_processUnloads iterates over all loaded > classes to see if any of them have been unloaded. This leads to > O(classCount * gcCount) performance, which in case of frequent GCs > (and they are frequent, especially the minor ones) is close to > O(classCount^2). In IDEA, we have quite a lot of classes, especially > counting all lambdas, so this results in quite significant overhead." > > The debug agent calls JVMTI GetLoadedClasses() during initialization > to get a cache of all prepared classes. It keeps that cache up-to-date > by getting JVMTI CLASS_PREPARE events. When there is a gc, the debug > agent basically throws away the cache and creates a new one by calling > GetLoadedClasses() again. It also compares the old and new caches to > determine which classes where unloaded, and generates JDWP > CLASS_UNLOAD events for them (if there is a debugger attached that > wants them). > > It might be possible to defer initialization of the loaded classes > cache (and any maintenance of it) until there is a debugger attached. > I'm not sure if the only reason for the cache is for delivery of > CLASS_UNLOAD events, but at first glance that appears to be the case. > > Chris > > On 6/20/19 1:31 PM, Volker Simonis wrote: >> Hi Egor, >> >> yes, I?d say this is something well known. The reason for this is >> that a debugging agent will request some JVMTI capabilities like >> "can_access_local_variables"?which can only be requested at JVM >> startup. However, once these capabilities have been taken, certain >> kinds of optimizations like for example Escape Analysis, can?t be >> done anymore which results in a performance degradation even if you >> don?t ever attach a debugger. >> >> We?ve always enabled debugging in our commercial SAP JVM and called >> it ?Debugging on Demand? but usually didn?t observed any performance >> slowdown of more than 3-5% at most. We?ve started contributing some >> of the improvements we?ve done to make this possible to the OpenJDK. >> >> I?ve not looked into your concrete class loading use case. Maybe it?s >> possible to improve that. First you have to check by which JVMTI >> capability it is triggered and if that capability is really necessary >> for debugging and can only be requested at startup. If the answer is >> yes, you can still check if it?s not possible to improve the >> implementation of that capability in order to get a better runtime >> behavior. >> >> Regards, >> Volker >> >> >> Egor Ushakov > > schrieb am Do. 20. Juni 2019 um >> 11:36: >> >> Hi everyone! >> >> we have detected that a process started with the debug agent >> (even when >> debugger is not actually attached) may run significantly slower than >> without the agent, see: >> https://youtrack.jetbrains.com/issue/JBR-1611 >> We all thought that without the debugger attached there should >> not be a >> difference. >> Is that something well known? Should we file a bug? >> >> Thanks, >> Egor >> >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop >> > -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Fri Jun 21 11:23:03 2019 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Fri, 21 Jun 2019 07:23:03 -0400 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> Message-ID: <3FB508A6-3513-4DB6-96C2-E986A7DD3CB5@gmail.com> Hi Mario, I don?t believe the MBean returns the wrong information. Is it not that the calls by-pass the container? Would it not be more appropriate to add a container aware mean? From a tooling perspective it?s a mistake to completely seal the JVM away from the hardware as it makes certain diagnostics more difficult to perform. Kind regards, Kirk > On Jun 21, 2019, at 6:06 AM, Mario Torre wrote: > > The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data. > > I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think. > > Bob, do you have some design ideas to share regarding the new interface? I think this may be an interesting project to pick up, even for students wanting to write a thesis, as it seems time is a limiting factor here for you to work on that? > > Cheers, > Mario > > On Fri 21. Jun 2019 at 10:53, Severin Gehwolf > wrote: > Hi Bob, > > On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: > > Hi Andrew, > > > > I am aware of the limitations of the OperatingSystemMXBean and was > > hoping to address these limitations during the implementation of > > https://bugs.openjdk.java.net/browse/JDK-8199944 . > > > > It would be helpful if you feel this is important to add some votes > > to this issue. > > It seems strange that the getAvailableProcessors() returns the > container limit, while the memory limits are for the physical host. If > anything, shouldn't they agree (both physical host or both container > limits)? > > When I briefly looked into it initially it seems to be a side-effect of > what is being used by the JDK code implementation-wise. IIRC > getAvailableProcessors() uses a runtime call. Memory reporting has it's > own logic[1], thus not reporting the container limit. > > This seems weird from a consistency perspective. Thoughts? > > If I understand you correctly, you are arguing that container reporting > should go into its own MX bean. On the other hand, CPU reporting for > the OS MX bean is container aware already. That makes me believe we > should rather make this consistent before evaluating a new MX bean. > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 > > > > Bob. > > > > > > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > > > > wrote: > > > > > > Hi all, > > > > > > Apologies if this is not the most appropriate list, in which case > > > please direct me where to go. > > > > > > I've noticed a surprising result from the > > > com.sun.management.OperatingSystemMXBean implementation when > > > running in > > > a containerized (specifically, using Docker on Linux) environment. > > > The > > > bean appears to be container-aware for processors, in that running > > > with > > > Docker option `--cpus 1.0` for example, on a multicore system, will > > > cause both java.lang.Runtime#availableProcessors and > > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / > > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to > > > return 1. However, the Docker option `--memory 100M` (or any other > > > limit value) is not reflected in the value returned by > > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize > > > , > > > and instead the returned value is still the total physical memory > > > of > > > the host machine - of which only a small portion may actually be > > > available to the "Operating System" of the JVM. Similarly for the > > > methods regarding free physical memory, total swap, and free swap. > > > > > > I have attached a patch which adds a small reproducer to the > > > existing > > > MemoryAwareness test. > > > > > > This seems like a bug to me, since if the imposed container limit > > > on > > > processors as a resource is included as part of the "Operating > > > System" > > > resource reporting, then surely memory resources should be reported > > > the > > > same way. As I said, I found the current behaviour quite > > > surprising. > > > > > > -- > > > Andrew Azores > > > Software Engineer, OpenJDK Team > > > Red Hat > > > > > > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri Jun 21 12:12:12 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 21 Jun 2019 21:12:12 +0900 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> Message-ID: Hi, Can we fix this issue like this webrev? http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/ I could reproduce this issue with ConcAttachTest.java in it on my laptop. (Fedora 30 x64 on Hyper-V guest: Core i3-8145U x 2vcpu) If we need to fix based on current implementation, I think we need to use atomic operation. But if we can refactor around here, we might be able to another approach - e.g. using monitors/mutexes Thanks, Yasumasa On 2019/06/21 5:49, David Holmes wrote: > Sorry it took me a while to understand the specifics of the problem. :) > > David > > On 20/06/2019 3:37 am, nijiaben wrote: >> Yes Alan, I mean this >> ------------------?Original?------------------ >> *From: *?"Alan Bateman"; >> *Date: *?Thu, Jun 20, 2019 02:54 PM >> *To: *?"nijiaben"; "David >> Holmes"; >> "serviceability-dev"; >> "jdk8u-dev"; >> "hotspot-runtime-dev"; >> *Subject: *?Re: A Bug about the JVM Attach mechanism >> On 20/06/2019 05:10, nijiaben wrote: >> > : >> > I know this mechanism, can we provide means of recovery to avoid >> unavailability caused by accidental deletion? >> > >> Are you concerned about tmpreaper or cron jobs that periodically cleanup >> /tmp? There may indeed be an issue for applications that run for weeks >> or months. If someone is using jmap, jcmd or other tools using the >> attach API then it will trigger the attach listener to start. When they >> come back in a few weeks then the .java_pid file may have been >> removed so they cannot attach. Is this what what you are pointing out? >> >> -Alan From neugens.limasoftware at gmail.com Fri Jun 21 12:27:43 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 21 Jun 2019 14:27:43 +0200 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: <3FB508A6-3513-4DB6-96C2-E986A7DD3CB5@gmail.com> References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> <3FB508A6-3513-4DB6-96C2-E986A7DD3CB5@gmail.com> Message-ID: Hi Kirk, I think I understand what you mean, however then the OS Bean should be consistent regarding CPU information as well. I think I remember why this was fixed the way it is now was because of incorrect behavior during GC configuration, or something along those lines, so I guess we would need two APIs after all to give tooling a way to sneak into the actual hardware properties. I would guess, however, that from the point of view of a containerised VM its OS is the container not the bare metal (or virtualized metal perhaps), so tooling would need to check specifically for a separate bean. That could be indicated via a property in the OS Bean (if it?s not the case already). Nevertheless, I think consistency in the OS Bean should be achieved. Cheers, Mario On Fri 21. Jun 2019 at 13:23, Kirk Pepperdine wrote: > Hi Mario, > > I don?t believe the MBean returns the wrong information. Is it not that > the calls by-pass the container? Would it not be more appropriate to add a > container aware mean? From a tooling perspective it?s a mistake to > completely seal the JVM away from the hardware as it makes certain > diagnostics more difficult to perform. > > Kind regards, > Kirk > > > On Jun 21, 2019, at 6:06 AM, Mario Torre > wrote: > > The way I understood the bug report is a two fold approach, i.e. fix the > os bean and *possibly* add a container one or extend it to add more data. > > I agree with you and Andrew that the current OS Bean returns wrong > information, this should be fixed in any case I think. > > Bob, do you have some design ideas to share regarding the new interface? I > think this may be an interesting project to pick up, even for students > wanting to write a thesis, as it seems time is a limiting factor here for > you to work on that? > > Cheers, > Mario > > On Fri 21. Jun 2019 at 10:53, Severin Gehwolf wrote: > >> Hi Bob, >> >> On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >> > Hi Andrew, >> > >> > I am aware of the limitations of the OperatingSystemMXBean and was >> > hoping to address these limitations during the implementation of >> > https://bugs.openjdk.java.net/browse/JDK-8199944. >> > >> > It would be helpful if you feel this is important to add some votes >> > to this issue. >> >> It seems strange that the getAvailableProcessors() returns the >> container limit, while the memory limits are for the physical host. If >> anything, shouldn't they agree (both physical host or both container >> limits)? >> >> When I briefly looked into it initially it seems to be a side-effect of >> what is being used by the JDK code implementation-wise. IIRC >> getAvailableProcessors() uses a runtime call. Memory reporting has it's >> own logic[1], thus not reporting the container limit. >> >> This seems weird from a consistency perspective. Thoughts? >> >> If I understand you correctly, you are arguing that container reporting >> should go into its own MX bean. On the other hand, CPU reporting for >> the OS MX bean is container aware already. That makes me believe we >> should rather make this consistent before evaluating a new MX bean. >> >> Thanks, >> Severin >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 >> >> >> > Bob. >> > >> > >> > > On Jun 20, 2019, at 9:43 AM, Andrew Azores >> > > wrote: >> > > >> > > Hi all, >> > > >> > > Apologies if this is not the most appropriate list, in which case >> > > please direct me where to go. >> > > >> > > I've noticed a surprising result from the >> > > com.sun.management.OperatingSystemMXBean implementation when >> > > running in >> > > a containerized (specifically, using Docker on Linux) environment. >> > > The >> > > bean appears to be container-aware for processors, in that running >> > > with >> > > Docker option `--cpus 1.0` for example, on a multicore system, will >> > > cause both java.lang.Runtime#availableProcessors and >> > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / >> > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to >> > > return 1. However, the Docker option `--memory 100M` (or any other >> > > limit value) is not reflected in the value returned by >> > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize >> > > , >> > > and instead the returned value is still the total physical memory >> > > of >> > > the host machine - of which only a small portion may actually be >> > > available to the "Operating System" of the JVM. Similarly for the >> > > methods regarding free physical memory, total swap, and free swap. >> > > >> > > I have attached a patch which adds a small reproducer to the >> > > existing >> > > MemoryAwareness test. >> > > >> > > This seems like a bug to me, since if the imposed container limit >> > > on >> > > processors as a resource is included as part of the "Operating >> > > System" >> > > resource reporting, then surely memory resources should be reported >> > > the >> > > same way. As I said, I found the current behaviour quite >> > > surprising. >> > > >> > > -- >> > > Andrew Azores >> > > Software Engineer, OpenJDK Team >> > > Red Hat >> > > >> > >> > >> >> -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.vandette at oracle.com Fri Jun 21 12:40:33 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 21 Jun 2019 08:40:33 -0400 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> <3FB508A6-3513-4DB6-96C2-E986A7DD3CB5@gmail.com> Message-ID: <958CE880-05D1-41FA-B4C8-337F5A63984E@oracle.com> I agree with you Mario. When I originally designed the jdk.internal.platform.Metrics API, I was considering providing both a Host and Container Metrics implementation. The problem is that the primary goal of containers is to provide isolation (hiding access to the host) and it would be very difficult to provide reliable forms of both metrics from within a container. The Linux kernel does leak some host metric information but not everything. This is why I decided to focus on the container configuration and metric data. If Host metrics are of interest you can always just run Java outside of a container. Bob. > On Jun 21, 2019, at 8:27 AM, Mario Torre wrote: > > Hi Kirk, > > I think I understand what you mean, however then the OS Bean should be consistent regarding CPU information as well. > > I think I remember why this was fixed the way it is now was because of incorrect behavior during GC configuration, or something along those lines, so I guess we would need two APIs after all to give tooling a way to sneak into the actual hardware properties. > > I would guess, however, that from the point of view of a containerised VM its OS is the container not the bare metal (or virtualized metal perhaps), so tooling would need to check specifically for a separate bean. > > That could be indicated via a property in the OS Bean (if it?s not the case already). > > Nevertheless, I think consistency in the OS Bean should be achieved. > > Cheers, > Mario > > On Fri 21. Jun 2019 at 13:23, Kirk Pepperdine > wrote: > Hi Mario, > > I don?t believe the MBean returns the wrong information. Is it not that the calls by-pass the container? Would it not be more appropriate to add a container aware mean? From a tooling perspective it?s a mistake to completely seal the JVM away from the hardware as it makes certain diagnostics more difficult to perform. > > Kind regards, > Kirk > > >> On Jun 21, 2019, at 6:06 AM, Mario Torre > wrote: >> >> The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data. >> >> I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think. >> >> Bob, do you have some design ideas to share regarding the new interface? I think this may be an interesting project to pick up, even for students wanting to write a thesis, as it seems time is a limiting factor here for you to work on that? >> >> Cheers, >> Mario >> >> On Fri 21. Jun 2019 at 10:53, Severin Gehwolf > wrote: >> Hi Bob, >> >> On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >> > Hi Andrew, >> > >> > I am aware of the limitations of the OperatingSystemMXBean and was >> > hoping to address these limitations during the implementation of >> > https://bugs.openjdk.java.net/browse/JDK-8199944 . >> > >> > It would be helpful if you feel this is important to add some votes >> > to this issue. >> >> It seems strange that the getAvailableProcessors() returns the >> container limit, while the memory limits are for the physical host. If >> anything, shouldn't they agree (both physical host or both container >> limits)? >> >> When I briefly looked into it initially it seems to be a side-effect of >> what is being used by the JDK code implementation-wise. IIRC >> getAvailableProcessors() uses a runtime call. Memory reporting has it's >> own logic[1], thus not reporting the container limit. >> >> This seems weird from a consistency perspective. Thoughts? >> >> If I understand you correctly, you are arguing that container reporting >> should go into its own MX bean. On the other hand, CPU reporting for >> the OS MX bean is container aware already. That makes me believe we >> should rather make this consistent before evaluating a new MX bean. >> >> Thanks, >> Severin >> >> [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 >> >> >> > Bob. >> > >> > >> > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > >> > > wrote: >> > > >> > > Hi all, >> > > >> > > Apologies if this is not the most appropriate list, in which case >> > > please direct me where to go. >> > > >> > > I've noticed a surprising result from the >> > > com.sun.management.OperatingSystemMXBean implementation when >> > > running in >> > > a containerized (specifically, using Docker on Linux) environment. >> > > The >> > > bean appears to be container-aware for processors, in that running >> > > with >> > > Docker option `--cpus 1.0` for example, on a multicore system, will >> > > cause both java.lang.Runtime#availableProcessors and >> > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / >> > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to >> > > return 1. However, the Docker option `--memory 100M` (or any other >> > > limit value) is not reflected in the value returned by >> > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize >> > > , >> > > and instead the returned value is still the total physical memory >> > > of >> > > the host machine - of which only a small portion may actually be >> > > available to the "Operating System" of the JVM. Similarly for the >> > > methods regarding free physical memory, total swap, and free swap. >> > > >> > > I have attached a patch which adds a small reproducer to the >> > > existing >> > > MemoryAwareness test. >> > > >> > > This seems like a bug to me, since if the imposed container limit >> > > on >> > > processors as a resource is included as part of the "Operating >> > > System" >> > > resource reporting, then surely memory resources should be reported >> > > the >> > > same way. As I said, I found the current behaviour quite >> > > surprising. >> > > >> > > -- >> > > Andrew Azores >> > > Software Engineer, OpenJDK Team >> > > Red Hat >> > > >> > >> > >> >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >> Proud GNU Classpath developer: http://www.classpath.org/ >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.vandette at oracle.com Fri Jun 21 12:50:22 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 21 Jun 2019 08:50:22 -0400 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> Message-ID: <908D2DEC-6ED9-45FC-8443-29897A64195F@oracle.com> > On Jun 21, 2019, at 6:06 AM, Mario Torre wrote: > > The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data. Correct. We could file a separate bug to just correct the OS Bean but I was hoping to add access to the new Container Metrics information at the same time. > > I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think. Yes. > > Bob, do you have some design ideas to share regarding the new interface? I think this may be an interesting project to pick up, even for students wanting to write a thesis, as it seems time is a limiting factor here for you to work on that? Fixing the existing OS Mbean is pretty straight forward. Just have each method call the new Metrics API, check for error returns in case this API is not supported on this platform and if success, return result, otherwise call existing logic. Adding new OS access or a new Container Mbean is a bit more involved. Since this is a public API, we?d need to take a look at at least one more OS (possibly Windows) and decide which of the Metrics we want to expose. I focused on Linux since this is the primary OS used in container runtimes (even on Windows). Once you have the list of Metrics and Configuration data, Add a new Container MBean modeled after the accessors in the Metrics API. jdk/open/src/java.base/share/classes/jdk/internal/platform/Metrics.java You?d need to ensure proper javadocs are available and jtreg tests would need to be written to validate the new APIs. Bob. > > Cheers, > Mario > > On Fri 21. Jun 2019 at 10:53, Severin Gehwolf wrote: > Hi Bob, > > On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: > > Hi Andrew, > > > > I am aware of the limitations of the OperatingSystemMXBean and was > > hoping to address these limitations during the implementation of > > https://bugs.openjdk.java.net/browse/JDK-8199944. > > > > It would be helpful if you feel this is important to add some votes > > to this issue. > > It seems strange that the getAvailableProcessors() returns the > container limit, while the memory limits are for the physical host. If > anything, shouldn't they agree (both physical host or both container > limits)? > > When I briefly looked into it initially it seems to be a side-effect of > what is being used by the JDK code implementation-wise. IIRC > getAvailableProcessors() uses a runtime call. Memory reporting has it's > own logic[1], thus not reporting the container limit. > > This seems weird from a consistency perspective. Thoughts? > > If I understand you correctly, you are arguing that container reporting > should go into its own MX bean. On the other hand, CPU reporting for > the OS MX bean is container aware already. That makes me believe we > should rather make this consistent before evaluating a new MX bean. > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 > > > > Bob. > > > > > > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > > > wrote: > > > > > > Hi all, > > > > > > Apologies if this is not the most appropriate list, in which case > > > please direct me where to go. > > > > > > I've noticed a surprising result from the > > > com.sun.management.OperatingSystemMXBean implementation when > > > running in > > > a containerized (specifically, using Docker on Linux) environment. > > > The > > > bean appears to be container-aware for processors, in that running > > > with > > > Docker option `--cpus 1.0` for example, on a multicore system, will > > > cause both java.lang.Runtime#availableProcessors and > > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / > > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to > > > return 1. However, the Docker option `--memory 100M` (or any other > > > limit value) is not reflected in the value returned by > > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize > > > , > > > and instead the returned value is still the total physical memory > > > of > > > the host machine - of which only a small portion may actually be > > > available to the "Operating System" of the JVM. Similarly for the > > > methods regarding free physical memory, total swap, and free swap. > > > > > > I have attached a patch which adds a small reproducer to the > > > existing > > > MemoryAwareness test. > > > > > > This seems like a bug to me, since if the imposed container limit > > > on > > > processors as a resource is included as part of the "Operating > > > System" > > > resource reporting, then surely memory resources should be reported > > > the > > > same way. As I said, I found the current behaviour quite > > > surprising. > > > > > > -- > > > Andrew Azores > > > Software Engineer, OpenJDK Team > > > Red Hat > > > > > > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From bob.vandette at oracle.com Fri Jun 21 12:56:19 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 21 Jun 2019 08:56:19 -0400 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> Message-ID: <047C7E8F-AC76-47DB-844E-CC82FAF1BFA8@oracle.com> > On Jun 21, 2019, at 4:22 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >> Hi Andrew, >> >> I am aware of the limitations of the OperatingSystemMXBean and was >> hoping to address these limitations during the implementation of >> https://bugs.openjdk.java.net/browse/JDK-8199944. >> >> It would be helpful if you feel this is important to add some votes >> to this issue. > > It seems strange that the getAvailableProcessors() returns the > container limit, while the memory limits are for the physical host. If > anything, shouldn't they agree (both physical host or both container > limits)? > > When I briefly looked into it initially it seems to be a side-effect of > what is being used by the JDK code implementation-wise. IIRC > getAvailableProcessors() uses a runtime call. Memory reporting has it's > own logic[1], thus not reporting the container limit. > > This seems weird from a consistency perspective. Thoughts? > > If I understand you correctly, you are arguing that container reporting > should go into its own MX bean. On the other hand, CPU reporting for > the OS MX bean is container aware already. That makes me believe we > should rather make this consistent before evaluating a new MX bean. You make a good point. I?ll split the enhancement and add a bug to fix the current MX Bean since this is pretty easy to do. Bob. > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 > > >> Bob. >> >> >>> On Jun 20, 2019, at 9:43 AM, Andrew Azores >>> wrote: >>> >>> Hi all, >>> >>> Apologies if this is not the most appropriate list, in which case >>> please direct me where to go. >>> >>> I've noticed a surprising result from the >>> com.sun.management.OperatingSystemMXBean implementation when >>> running in >>> a containerized (specifically, using Docker on Linux) environment. >>> The >>> bean appears to be container-aware for processors, in that running >>> with >>> Docker option `--cpus 1.0` for example, on a multicore system, will >>> cause both java.lang.Runtime#availableProcessors and >>> java.lang.management.OperatingSystemMXBean#getAvailableProcessors / >>> com.sun.management.OperatingSystemMXBean#getAvailableProcessors to >>> return 1. However, the Docker option `--memory 100M` (or any other >>> limit value) is not reflected in the value returned by >>> com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize >>> , >>> and instead the returned value is still the total physical memory >>> of >>> the host machine - of which only a small portion may actually be >>> available to the "Operating System" of the JVM. Similarly for the >>> methods regarding free physical memory, total swap, and free swap. >>> >>> I have attached a patch which adds a small reproducer to the >>> existing >>> MemoryAwareness test. >>> >>> This seems like a bug to me, since if the imposed container limit >>> on >>> processors as a resource is included as part of the "Operating >>> System" >>> resource reporting, then surely memory resources should be reported >>> the >>> same way. As I said, I found the current behaviour quite >>> surprising. >>> >>> -- >>> Andrew Azores >>> Software Engineer, OpenJDK Team >>> Red Hat >>> >> >> > From sgehwolf at redhat.com Fri Jun 21 13:08:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 Jun 2019 15:08:12 +0200 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: <047C7E8F-AC76-47DB-844E-CC82FAF1BFA8@oracle.com> References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> <047C7E8F-AC76-47DB-844E-CC82FAF1BFA8@oracle.com> Message-ID: <4f12e62d2693cd329bf29651a1cad2a2e485189b.camel@redhat.com> Hi Bob, On Fri, 2019-06-21 at 08:56 -0400, Bob Vandette wrote: > > On Jun 21, 2019, at 4:22 AM, Severin Gehwolf wrote: > > > > Hi Bob, > > > > On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: > > > Hi Andrew, > > > > > > I am aware of the limitations of the OperatingSystemMXBean and was > > > hoping to address these limitations during the implementation of > > > https://bugs.openjdk.java.net/browse/JDK-8199944. > > > > > > It would be helpful if you feel this is important to add some votes > > > to this issue. > > > > It seems strange that the getAvailableProcessors() returns the > > container limit, while the memory limits are for the physical host. If > > anything, shouldn't they agree (both physical host or both container > > limits)? > > > > When I briefly looked into it initially it seems to be a side-effect of > > what is being used by the JDK code implementation-wise. IIRC > > getAvailableProcessors() uses a runtime call. Memory reporting has it's > > own logic[1], thus not reporting the container limit. > > > > This seems weird from a consistency perspective. Thoughts? > > > > If I understand you correctly, you are arguing that container reporting > > should go into its own MX bean. On the other hand, CPU reporting for > > the OS MX bean is container aware already. That makes me believe we > > should rather make this consistent before evaluating a new MX bean. > > You make a good point. I?ll split the enhancement and add a bug to fix the > current MX Bean since this is pretty easy to do. Sounds great! Please let me know once the OS MX bean bug has been created. I'll then assign it to myself and help Andrew through the process of getting it fixed. Thanks, Severin > Bob. > > > Thanks, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 > > > > > > > Bob. > > > > > > > > > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > > > > wrote: > > > > > > > > Hi all, > > > > > > > > Apologies if this is not the most appropriate list, in which case > > > > please direct me where to go. > > > > > > > > I've noticed a surprising result from the > > > > com.sun.management.OperatingSystemMXBean implementation when > > > > running in > > > > a containerized (specifically, using Docker on Linux) environment. > > > > The > > > > bean appears to be container-aware for processors, in that running > > > > with > > > > Docker option `--cpus 1.0` for example, on a multicore system, will > > > > cause both java.lang.Runtime#availableProcessors and > > > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / > > > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to > > > > return 1. However, the Docker option `--memory 100M` (or any other > > > > limit value) is not reflected in the value returned by > > > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize > > > > , > > > > and instead the returned value is still the total physical memory > > > > of > > > > the host machine - of which only a small portion may actually be > > > > available to the "Operating System" of the JVM. Similarly for the > > > > methods regarding free physical memory, total swap, and free swap. > > > > > > > > I have attached a patch which adds a small reproducer to the > > > > existing > > > > MemoryAwareness test. > > > > > > > > This seems like a bug to me, since if the imposed container limit > > > > on > > > > processors as a resource is included as part of the "Operating > > > > System" > > > > resource reporting, then surely memory resources should be reported > > > > the > > > > same way. As I said, I found the current behaviour quite > > > > surprising. > > > > > > > > -- > > > > Andrew Azores > > > > Software Engineer, OpenJDK Team > > > > Red Hat > > > > From daniel.daugherty at oracle.com Fri Jun 21 13:44:56 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 21 Jun 2019 09:44:56 -0400 Subject: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed In-Reply-To: <19c92bb0-0cb3-0626-6609-0c3f938d22a2@oracle.com> References: <19c92bb0-0cb3-0626-6609-0c3f938d22a2@oracle.com> Message-ID: On 6/21/19 1:24 AM, serguei.spitsyn at oracle.com wrote: > Please, review the test bug fix for: > https://bugs.openjdk.java.net/browse/JDK-8224555 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8224555-mon-events2-test.1/ test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001.java ??? L99: ??????????? for (int j = 0; j < 1000; j++) { ??????? Why a literal '1000' this time? You could use "timeout / 20" ??????? based on: ??????? L120: ??????? timeout = argHandler.getWaitTime() * 60 * 1000; ??????? That seems to be what all the other timeout logic is based on. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/tc02t001.cpp ??? No comments. Thumbs up. I don't need a new webrev if you decide to make the minor change above. Dan > > > Summary: > ? The test sleeps for 1 sec in hope to get a contention on the monitor > tc02t001Thread.M. > ? It seems, this is not enough when the JFR is enabled. > ? The fix uses a better approach to ensure events are really happen. > ? This approach is similar to the on in the fix of 8223736 (just > reviewed). > > ? Also, the class line number sensitive tc02t001Thread is moved to the > beginning of > ? the file to make it independent from the rest of the file. > > > Testing: > ? A mach5 submission is in progress. > > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Jun 21 13:51:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Jun 2019 06:51:44 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> Message-ID: <5c156c6b-bc47-97d5-2c61-5b4f44e098c0@oracle.com> Hi Yasumasa, On 21/06/2019 5:12 am, Yasumasa Suenaga wrote: > Hi, > > Can we fix this issue like this webrev? > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/ I'm not clear how this addresses the issue with deleting the file? The file still has to exist IIUC for the mechanism to work. This seems more suited to fixing the "multiple attach threads" problem. David > I could reproduce this issue with ConcAttachTest.java in it > on my laptop. > (Fedora 30 x64 on Hyper-V guest: Core i3-8145U x 2vcpu) > > If we need to fix based on current implementation, I think > we need to use atomic operation. > But if we can refactor around here, we might be able to another approach > - e.g. using monitors/mutexes > > > Thanks, > > Yasumasa > > > On 2019/06/21 5:49, David Holmes wrote: >> Sorry it took me a while to understand the specifics of the problem. :) >> >> David >> >> On 20/06/2019 3:37 am, nijiaben wrote: >>> Yes Alan, I mean this >>> ------------------?Original?------------------ >>> *From: *?"Alan Bateman"; >>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>> *To: *?"nijiaben"; "David >>> Holmes"; >>> "serviceability-dev"; >>> "jdk8u-dev"; >>> "hotspot-runtime-dev"; >>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>> On 20/06/2019 05:10, nijiaben wrote: >>> ? > : >>> ? > I know this mechanism, can we provide means of recovery to avoid >>> unavailability caused by accidental deletion? >>> ? > >>> Are you concerned about tmpreaper or cron jobs that periodically cleanup >>> /tmp? There may indeed be an issue for applications that run for weeks >>> or months. If someone is using jmap, jcmd or other tools using the >>> attach API then it will trigger the attach listener to start. When they >>> come back in a few weeks then the .java_pid file may have been >>> removed so they cannot attach. Is this what what you are pointing out? >>> >>> -Alan From bob.vandette at oracle.com Fri Jun 21 13:53:07 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 21 Jun 2019 09:53:07 -0400 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: <4f12e62d2693cd329bf29651a1cad2a2e485189b.camel@redhat.com> References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> <047C7E8F-AC76-47DB-844E-CC82FAF1BFA8@oracle.com> <4f12e62d2693cd329bf29651a1cad2a2e485189b.camel@redhat.com> Message-ID: Here you go. https://bugs.openjdk.java.net/browse/JDK-8226575 Thanks, Bob. > On Jun 21, 2019, at 9:08 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Fri, 2019-06-21 at 08:56 -0400, Bob Vandette wrote: >>> On Jun 21, 2019, at 4:22 AM, Severin Gehwolf wrote: >>> >>> Hi Bob, >>> >>> On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >>>> Hi Andrew, >>>> >>>> I am aware of the limitations of the OperatingSystemMXBean and was >>>> hoping to address these limitations during the implementation of >>>> https://bugs.openjdk.java.net/browse/JDK-8199944. >>>> >>>> It would be helpful if you feel this is important to add some votes >>>> to this issue. >>> >>> It seems strange that the getAvailableProcessors() returns the >>> container limit, while the memory limits are for the physical host. If >>> anything, shouldn't they agree (both physical host or both container >>> limits)? >>> >>> When I briefly looked into it initially it seems to be a side-effect of >>> what is being used by the JDK code implementation-wise. IIRC >>> getAvailableProcessors() uses a runtime call. Memory reporting has it's >>> own logic[1], thus not reporting the container limit. >>> >>> This seems weird from a consistency perspective. Thoughts? >>> >>> If I understand you correctly, you are arguing that container reporting >>> should go into its own MX bean. On the other hand, CPU reporting for >>> the OS MX bean is container aware already. That makes me believe we >>> should rather make this consistent before evaluating a new MX bean. >> >> You make a good point. I?ll split the enhancement and add a bug to fix the >> current MX Bean since this is pretty easy to do. > > Sounds great! Please let me know once the OS MX bean bug has been > created. I'll then assign it to myself and help Andrew through the > process of getting it fixed. > > Thanks, > Severin > >> Bob. >> >>> Thanks, >>> Severin >>> >>> [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 >>> >>> >>>> Bob. >>>> >>>> >>>>> On Jun 20, 2019, at 9:43 AM, Andrew Azores >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Apologies if this is not the most appropriate list, in which case >>>>> please direct me where to go. >>>>> >>>>> I've noticed a surprising result from the >>>>> com.sun.management.OperatingSystemMXBean implementation when >>>>> running in >>>>> a containerized (specifically, using Docker on Linux) environment. >>>>> The >>>>> bean appears to be container-aware for processors, in that running >>>>> with >>>>> Docker option `--cpus 1.0` for example, on a multicore system, will >>>>> cause both java.lang.Runtime#availableProcessors and >>>>> java.lang.management.OperatingSystemMXBean#getAvailableProcessors / >>>>> com.sun.management.OperatingSystemMXBean#getAvailableProcessors to >>>>> return 1. However, the Docker option `--memory 100M` (or any other >>>>> limit value) is not reflected in the value returned by >>>>> com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize >>>>> , >>>>> and instead the returned value is still the total physical memory >>>>> of >>>>> the host machine - of which only a small portion may actually be >>>>> available to the "Operating System" of the JVM. Similarly for the >>>>> methods regarding free physical memory, total swap, and free swap. >>>>> >>>>> I have attached a patch which adds a small reproducer to the >>>>> existing >>>>> MemoryAwareness test. >>>>> >>>>> This seems like a bug to me, since if the imposed container limit >>>>> on >>>>> processors as a resource is included as part of the "Operating >>>>> System" >>>>> resource reporting, then surely memory resources should be reported >>>>> the >>>>> same way. As I said, I found the current behaviour quite >>>>> surprising. >>>>> >>>>> -- >>>>> Andrew Azores >>>>> Software Engineer, OpenJDK Team >>>>> Red Hat >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri Jun 21 14:16:36 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 21 Jun 2019 23:16:36 +0900 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <5c156c6b-bc47-97d5-2c61-5b4f44e098c0@oracle.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5c156c6b-bc47-97d5-2c61-5b4f44e098c0@oracle.com> Message-ID: On 2019/06/21 22:51, David Holmes wrote: > Hi Yasumasa, > > On 21/06/2019 5:12 am, Yasumasa Suenaga wrote: >> Hi, >> >> Can we fix this issue like this webrev? >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/ > > I'm not clear how this addresses the issue with deleting the file? The > file still has to exist IIUC for the mechanism to work. > > This seems more suited to fixing the "multiple attach threads" problem. Yes, my proposal focuses to "multiple attach threads". I shared my patch because it might help the work for this issue. This patch would guard multithread-issue in Attach Listener. So unix domain socket file will create just once. Yasumasa > David > >> I could reproduce this issue with ConcAttachTest.java in it >> on my laptop. >> (Fedora 30 x64 on Hyper-V guest: Core i3-8145U x 2vcpu) >> >> If we need to fix based on current implementation, I think >> we need to use atomic operation. >> But if we can refactor around here, we might be able to another >> approach - e.g. using monitors/mutexes >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/06/21 5:49, David Holmes wrote: >>> Sorry it took me a while to understand the specifics of the problem. :) >>> >>> David >>> >>> On 20/06/2019 3:37 am, nijiaben wrote: >>>> Yes Alan, I mean this >>>> ------------------?Original?------------------ >>>> *From: *?"Alan Bateman"; >>>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>>> *To: *?"nijiaben"; "David >>>> Holmes"; >>>> "serviceability-dev"; >>>> "jdk8u-dev"; >>>> "hotspot-runtime-dev"; >>>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>>> On 20/06/2019 05:10, nijiaben wrote: >>>> ? > : >>>> ? > I know this mechanism, can we provide means of recovery to avoid >>>> unavailability caused by accidental deletion? >>>> ? > >>>> Are you concerned about tmpreaper or cron jobs that periodically >>>> cleanup >>>> /tmp? There may indeed be an issue for applications that run for weeks >>>> or months. If someone is using jmap, jcmd or other tools using the >>>> attach API then it will trigger the attach listener to start. When they >>>> come back in a few weeks then the .java_pid file may have been >>>> removed so they cannot attach. Is this what what you are pointing out? >>>> >>>> -Alan From neugens.limasoftware at gmail.com Fri Jun 21 14:46:36 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 21 Jun 2019 16:46:36 +0200 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> <047C7E8F-AC76-47DB-844E-CC82FAF1BFA8@oracle.com> <4f12e62d2693cd329bf29651a1cad2a2e485189b.camel@redhat.com> Message-ID: Thanks! Cheers, Mario On Fri 21. Jun 2019 at 15:54, Bob Vandette wrote: > Here you go. > > https://bugs.openjdk.java.net/browse/JDK-8226575 > > Thanks, > Bob. > > On Jun 21, 2019, at 9:08 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Fri, 2019-06-21 at 08:56 -0400, Bob Vandette wrote: > > On Jun 21, 2019, at 4:22 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: > > Hi Andrew, > > I am aware of the limitations of the OperatingSystemMXBean and was > hoping to address these limitations during the implementation of > https://bugs.openjdk.java.net/browse/JDK-8199944. > > It would be helpful if you feel this is important to add some votes > to this issue. > > > It seems strange that the getAvailableProcessors() returns the > container limit, while the memory limits are for the physical host. If > anything, shouldn't they agree (both physical host or both container > limits)? > > When I briefly looked into it initially it seems to be a side-effect of > what is being used by the JDK code implementation-wise. IIRC > getAvailableProcessors() uses a runtime call. Memory reporting has it's > own logic[1], thus not reporting the container limit. > > This seems weird from a consistency perspective. Thoughts? > > If I understand you correctly, you are arguing that container reporting > should go into its own MX bean. On the other hand, CPU reporting for > the OS MX bean is container aware already. That makes me believe we > should rather make this consistent before evaluating a new MX bean. > > > You make a good point. I?ll split the enhancement and add a bug to fix the > current MX Bean since this is pretty easy to do. > > > Sounds great! Please let me know once the OS MX bean bug has been > created. I'll then assign it to myself and help Andrew through the > process of getting it fixed. > > Thanks, > Severin > > Bob. > > Thanks, > Severin > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 > > > Bob. > > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > wrote: > > Hi all, > > Apologies if this is not the most appropriate list, in which case > please direct me where to go. > > I've noticed a surprising result from the > com.sun.management.OperatingSystemMXBean implementation when > running in > a containerized (specifically, using Docker on Linux) environment. > The > bean appears to be container-aware for processors, in that running > with > Docker option `--cpus 1.0` for example, on a multicore system, will > cause both java.lang.Runtime#availableProcessors and > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to > return 1. However, the Docker option `--memory 100M` (or any other > limit value) is not reflected in the value returned by > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize > , > and instead the returned value is still the total physical memory > of > the host machine - of which only a small portion may actually be > available to the "Operating System" of the JVM. Similarly for the > methods regarding free physical memory, total swap, and free swap. > > I have attached a patch which adds a small reproducer to the > existing > MemoryAwareness test. > > This seems like a bug to me, since if the imposed container limit > on > processors as a resource is included as part of the "Operating > System" > resource reporting, then surely memory resources should be reported > the > same way. As I said, I found the current behaviour quite > surprising. > > -- > Andrew Azores > Software Engineer, OpenJDK Team > Red Hat > > > > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Fri Jun 21 14:55:33 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 21 Jun 2019 16:55:33 +0200 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> Message-ID: As far as I know, cron jobs that cleanup /tmp typically remove files that have not been modified for a while. On Fedora for example, there is a systemd timer that triggers once per day and executes systemd-tmpfiles which manages volatile and temporary files and directories. The configuration for /tmp is the following: # Clear tmp directories separately, to make them easier to override q /tmp 1777 root root 10d q /var/tmp 1777 root root 30d The age field (10 days for /tmp) has the following meaning: ?????? The age of a file system entry is determined from its last modification timestamp (mtime), its last access timestamp (atime), and (except for directories) its last status change ?????? timestamp (ctime). Any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field. So the solution could be for attach thread (if it is already started) to update mtime or ctime of the .java_pid socket file periodically so cleanup job would leave it alone. What do you think? Regards, Peter On 6/20/19 10:49 PM, David Holmes wrote: > Sorry it took me a while to understand the specifics of the problem. :) > > David > > On 20/06/2019 3:37 am, nijiaben wrote: >> Yes Alan, I mean this >> ------------------?Original?------------------ >> *From: *?"Alan Bateman"; >> *Date: *?Thu, Jun 20, 2019 02:54 PM >> *To: *?"nijiaben"; "David >> Holmes"; >> "serviceability-dev"; >> "jdk8u-dev"; >> "hotspot-runtime-dev"; >> *Subject: *?Re: A Bug about the JVM Attach mechanism >> On 20/06/2019 05:10, nijiaben wrote: >> ?> : >> ?> I know this mechanism, can we provide means of recovery to avoid >> unavailability caused by accidental deletion? >> ?> >> Are you concerned about tmpreaper or cron jobs that periodically cleanup >> /tmp? There may indeed be an issue for applications that run for weeks >> or months. If someone is using jmap, jcmd or other tools using the >> attach API then it will trigger the attach listener to start. When they >> come back in a few weeks then the .java_pid file may have been >> removed so they cannot attach. Is this what what you are pointing out? >> >> -Alan From david.holmes at oracle.com Fri Jun 21 15:57:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Jun 2019 08:57:54 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> Message-ID: <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> Hi Peter, On 21/06/2019 7:55 am, Peter Levart wrote: > As far as I know, cron jobs that cleanup /tmp typically remove files > that have not been modified for a while. > > On Fedora for example, there is a systemd timer that triggers once per > day and executes systemd-tmpfiles which manages volatile and temporary > files and directories. The configuration for /tmp is the following: > > # Clear tmp directories separately, to make them easier to override > q /tmp 1777 root root 10d > q /var/tmp 1777 root root 30d > > The age field (10 days for /tmp) has the following meaning: > > ?????? The age of a file system entry is determined from its last > modification timestamp (mtime), its last access timestamp (atime), and > (except for directories) its last status change > ?????? timestamp (ctime). Any of these three (or two) values will > prevent cleanup if it is more recent than the current time minus the age > field. > > So the solution could be for attach thread (if it is already started) to > update mtime or ctime of the .java_pid socket file periodically so > cleanup job would leave it alone. > > What do you think? I'm not keen on having the attach listener thread periodically wakeup just to do this. Can we not change permissions to protect the file form external deletion and ensure the VM cleans it up itself? David > Regards, Peter > > > On 6/20/19 10:49 PM, David Holmes wrote: >> Sorry it took me a while to understand the specifics of the problem. :) >> >> David >> >> On 20/06/2019 3:37 am, nijiaben wrote: >>> Yes Alan, I mean this >>> ------------------?Original?------------------ >>> *From: *?"Alan Bateman"; >>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>> *To: *?"nijiaben"; "David >>> Holmes"; >>> "serviceability-dev"; >>> "jdk8u-dev"; >>> "hotspot-runtime-dev"; >>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>> On 20/06/2019 05:10, nijiaben wrote: >>> ?> : >>> ?> I know this mechanism, can we provide means of recovery to avoid >>> unavailability caused by accidental deletion? >>> ?> >>> Are you concerned about tmpreaper or cron jobs that periodically cleanup >>> /tmp? There may indeed be an issue for applications that run for weeks >>> or months. If someone is using jmap, jcmd or other tools using the >>> attach API then it will trigger the attach listener to start. When they >>> come back in a few weeks then the .java_pid file may have been >>> removed so they cannot attach. Is this what what you are pointing out? >>> >>> -Alan > From gary.adams at oracle.com Fri Jun 21 17:03:35 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 21 Jun 2019 13:03:35 -0400 Subject: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout In-Reply-To: References: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> <83f80d7c-4477-8b52-b3e3-16554ec9c161@oracle.com> Message-ID: <5D0D0DE7.2040101@oracle.com> Any chance this will also fix JDK-8226367 ? On 6/20/19, 10:39 PM, Chris Plummer wrote: > Thanks for looking into this. > > Chris > > On 6/20/19 6:42 PM, Daniil Titov wrote: >> Thank you, Chris and Serguei, for reviewing this change. >> >> I did more testing with a test program on Linux that repeats >> get_namespace_pid() method and reads from the real file ( the copy of >> /proc//status). >> I paused the program after the first several lines ( but not "NSpid:" >> line) where processed and deleted all lines in the status file >> before " NSpid: ..." line in order >> to this line became the first in the edited file. After that the >> program continues in the while loop but it seems as the original file >> content was >> already buffered and the program just continues over the original >> unedited lines and successfully found the match. >> >> Best regards, >> Daniil >> >> ?On 6/19/19, 9:13 PM, "Chris Plummer" wrote: >> >> Hi Daniil, >> I think your fix is good, although I wonder about the >> robustness of this >> function given that the status file can change while it is >> reading it. I >> wonder if it can return a false negative because it never saw the >> matching line. This could happen if a line gets deleted, causing >> the >> matching line to suddenly be earlier in the file, possibly >> before the >> current location being read. Anyway, that's not really related >> to the >> current issue or fix, but if you think it might be an issue >> maybe a bug >> should be filed for it. >> thanks, >> Chris >> On 6/19/19 9:02 PM, Daniil Titov wrote: >> > Please review the change that fixes an intermittent failure of >> serviceability/dcmd/framework/* tests on Linux platform. >> > >> > The problem here is that get_namespace_pid() method, that is called >> by mmap_attach_shared () that in turn is called by PerfMemory::attach(), >> > tries to read the namespace pid information from /proc//status >> file. However, it doesn't check that the error indicator associated with >> > stream is set that results in the endless loop (lines 664-677) if >> the process terminates after /proc//status was opened (line 659) >> > and checked for null (line 661). >> > >> > 658 snprintf(fname, sizeof(fname), "/proc/%d/status", vmid); >> > 659 FILE *fp = fopen(fname, "r"); >> > 660 >> > 661 if (fp) { >> > 662 int pid, nspid; >> > 663 int ret; >> > 664 while (!feof(fp)) { >> > 665 ret = fscanf(fp, "NSpid: %d %d", &pid, &nspid); >> > 666 if (ret == 1) { >> > 667 break; >> > 668 } >> > 669 if (ret == 2) { >> > 670 retpid = nspid; >> > 671 break; >> > 672 } >> > 673 for (;;) { >> > 674 int ch = fgetc(fp); >> > 675 if (ch == EOF || ch == (int)'\n') break; >> > 676 } >> > 677 } >> > 678 fclose(fp); >> > 679 } >> > >> > The fix adds the check for the error indicator to ensure that the >> "while" loop terminates properly if the file no longer exists. >> > >> > Issues [3] and [4] have the same cause and will be closed as >> duplicates of this issue. >> > >> > Testing: Mach5 hotspot_serviceability tests succeeded, tier1,tier2, >> and tier3 tests are in progress. >> > >> > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8220175/webrev.01/ >> > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8220175 >> > [3] https://bugs.openjdk.java.net/browse/JDK-8223600 >> > [4] https://bugs.openjdk.java.net/browse/JDK-8217351 >> > >> > Thanks! >> > -Daniil >> > >> > >> >> > > From daniil.x.titov at oracle.com Fri Jun 21 17:40:12 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 21 Jun 2019 10:40:12 -0700 Subject: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout In-Reply-To: <5D0D0DE7.2040101@oracle.com> References: <2BB785CB-48D3-41C3-8AE5-4AAC74963940@oracle.com> <83f80d7c-4477-8b52-b3e3-16554ec9c161@oracle.com> <5D0D0DE7.2040101@oracle.com> Message-ID: <261E0455-0477-4588-A28B-E8E3E0734EF0@oracle.com> I don't think so, the stack trace for JDK-8226367 shows the different problem. Best regards, Daniil ?On 6/21/19, 10:02 AM, "Gary Adams" wrote: Any chance this will also fix JDK-8226367 ? On 6/20/19, 10:39 PM, Chris Plummer wrote: > Thanks for looking into this. > > Chris > > On 6/20/19 6:42 PM, Daniil Titov wrote: >> Thank you, Chris and Serguei, for reviewing this change. >> >> I did more testing with a test program on Linux that repeats >> get_namespace_pid() method and reads from the real file ( the copy of >> /proc//status). >> I paused the program after the first several lines ( but not "NSpid:" >> line) where processed and deleted all lines in the status file >> before " NSpid: ..." line in order >> to this line became the first in the edited file. After that the >> program continues in the while loop but it seems as the original file >> content was >> already buffered and the program just continues over the original >> unedited lines and successfully found the match. >> >> Best regards, >> Daniil >> >> ?On 6/19/19, 9:13 PM, "Chris Plummer" wrote: >> >> Hi Daniil, >> I think your fix is good, although I wonder about the >> robustness of this >> function given that the status file can change while it is >> reading it. I >> wonder if it can return a false negative because it never saw the >> matching line. This could happen if a line gets deleted, causing >> the >> matching line to suddenly be earlier in the file, possibly >> before the >> current location being read. Anyway, that's not really related >> to the >> current issue or fix, but if you think it might be an issue >> maybe a bug >> should be filed for it. >> thanks, >> Chris >> On 6/19/19 9:02 PM, Daniil Titov wrote: >> > Please review the change that fixes an intermittent failure of >> serviceability/dcmd/framework/* tests on Linux platform. >> > >> > The problem here is that get_namespace_pid() method, that is called >> by mmap_attach_shared () that in turn is called by PerfMemory::attach(), >> > tries to read the namespace pid information from /proc//status >> file. However, it doesn't check that the error indicator associated with >> > stream is set that results in the endless loop (lines 664-677) if >> the process terminates after /proc//status was opened (line 659) >> > and checked for null (line 661). >> > >> > 658 snprintf(fname, sizeof(fname), "/proc/%d/status", vmid); >> > 659 FILE *fp = fopen(fname, "r"); >> > 660 >> > 661 if (fp) { >> > 662 int pid, nspid; >> > 663 int ret; >> > 664 while (!feof(fp)) { >> > 665 ret = fscanf(fp, "NSpid: %d %d", &pid, &nspid); >> > 666 if (ret == 1) { >> > 667 break; >> > 668 } >> > 669 if (ret == 2) { >> > 670 retpid = nspid; >> > 671 break; >> > 672 } >> > 673 for (;;) { >> > 674 int ch = fgetc(fp); >> > 675 if (ch == EOF || ch == (int)'\n') break; >> > 676 } >> > 677 } >> > 678 fclose(fp); >> > 679 } >> > >> > The fix adds the check for the error indicator to ensure that the >> "while" loop terminates properly if the file no longer exists. >> > >> > Issues [3] and [4] have the same cause and will be closed as >> duplicates of this issue. >> > >> > Testing: Mach5 hotspot_serviceability tests succeeded, tier1,tier2, >> and tier3 tests are in progress. >> > >> > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8220175/webrev.01/ >> > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8220175 >> > [3] https://bugs.openjdk.java.net/browse/JDK-8223600 >> > [4] https://bugs.openjdk.java.net/browse/JDK-8217351 >> > >> > Thanks! >> > -Daniil >> > >> > >> >> > > From serguei.spitsyn at oracle.com Fri Jun 21 18:38:52 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Jun 2019 11:38:52 -0700 Subject: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed In-Reply-To: References: <19c92bb0-0cb3-0626-6609-0c3f938d22a2@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Jun 21 18:38:51 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Jun 2019 11:38:51 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> Message-ID: <9b8e47f5-c6f5-3380-3f55-e1c6522d868f@oracle.com> On 6/21/19 8:57 AM, David Holmes wrote: > Hi Peter, > > On 21/06/2019 7:55 am, Peter Levart wrote: >> As far as I know, cron jobs that cleanup /tmp typically remove files >> that have not been modified for a while. >> >> On Fedora for example, there is a systemd timer that triggers once >> per day and executes systemd-tmpfiles which manages volatile and >> temporary files and directories. The configuration for /tmp is the >> following: >> >> # Clear tmp directories separately, to make them easier to override >> q /tmp 1777 root root 10d >> q /var/tmp 1777 root root 30d >> >> The age field (10 days for /tmp) has the following meaning: >> >> ??????? The age of a file system entry is determined from its last >> modification timestamp (mtime), its last access timestamp (atime), >> and (except for directories) its last status change >> ??????? timestamp (ctime). Any of these three (or two) values will >> prevent cleanup if it is more recent than the current time minus the >> age field. >> >> So the solution could be for attach thread (if it is already started) >> to update mtime or ctime of the .java_pid socket file >> periodically so cleanup job would leave it alone. >> >> What do you think? > > I'm not keen on having the attach listener thread periodically wakeup > just to do this. Can we not change permissions to protect the file > form external deletion and ensure the VM cleans it up itself? I think the JVM has a mechanism for cleaning up stale java_pid files on startup (deleting those for which there is currently no java process running). We need to make sure that changing permissions does not break that. Rather than? having the JVM update mtime on the file, perhaps the onus should be on the sys admin that is running scripts to clean up these files in the first place. The scripts could first update mtime on an java_pid files for which there is a java process still running. Chris > > David > >> Regards, Peter >> >> >> On 6/20/19 10:49 PM, David Holmes wrote: >>> Sorry it took me a while to understand the specifics of the problem. :) >>> >>> David >>> >>> On 20/06/2019 3:37 am, nijiaben wrote: >>>> Yes Alan, I mean this >>>> ------------------?Original?------------------ >>>> *From: *?"Alan Bateman"; >>>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>>> *To: *?"nijiaben"; "David >>>> Holmes"; >>>> "serviceability-dev"; >>>> "jdk8u-dev"; >>>> "hotspot-runtime-dev"; >>>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>>> On 20/06/2019 05:10, nijiaben wrote: >>>> ?> : >>>> ?> I know this mechanism, can we provide means of recovery to avoid >>>> unavailability caused by accidental deletion? >>>> ?> >>>> Are you concerned about tmpreaper or cron jobs that periodically >>>> cleanup >>>> /tmp? There may indeed be an issue for applications that run for weeks >>>> or months. If someone is using jmap, jcmd or other tools using the >>>> attach API then it will trigger the attach listener to start. When >>>> they >>>> come back in a few weeks then the .java_pid file may have been >>>> removed so they cannot attach. Is this what what you are pointing out? >>>> >>>> -Alan >> From chris.plummer at oracle.com Fri Jun 21 18:50:40 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Jun 2019 11:50:40 -0700 Subject: Slow class loading when running JVM in debug mode In-Reply-To: <074598ed-c337-a0cd-7c78-10e587de8431@jetbrains.com> References: <0ae9a535-4fc7-93e3-ebc5-0a1d2ad9b5e9@jetbrains.com> <074598ed-c337-a0cd-7c78-10e587de8431@jetbrains.com> Message-ID: An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Fri Jun 21 18:57:13 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 21 Jun 2019 20:57:13 +0200 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> Message-ID: <751a9c56-5d71-ec0b-66c9-ea7fb60b066c@gmail.com> Hi David, On 6/21/19 5:57 PM, David Holmes wrote: > Hi Peter, > > On 21/06/2019 7:55 am, Peter Levart wrote: >> As far as I know, cron jobs that cleanup /tmp typically remove files >> that have not been modified for a while. >> >> On Fedora for example, there is a systemd timer that triggers once >> per day and executes systemd-tmpfiles which manages volatile and >> temporary files and directories. The configuration for /tmp is the >> following: >> >> # Clear tmp directories separately, to make them easier to override >> q /tmp 1777 root root 10d >> q /var/tmp 1777 root root 30d >> >> The age field (10 days for /tmp) has the following meaning: >> >> ??????? The age of a file system entry is determined from its last >> modification timestamp (mtime), its last access timestamp (atime), >> and (except for directories) its last status change >> ??????? timestamp (ctime). Any of these three (or two) values will >> prevent cleanup if it is more recent than the current time minus the >> age field. >> >> So the solution could be for attach thread (if it is already started) >> to update mtime or ctime of the .java_pid socket file >> periodically so cleanup job would leave it alone. >> >> What do you think? > > I'm not keen on having the attach listener thread periodically wakeup > just to do this. The required frequency would be very low. Once a day would be more than enough. cron jobs are usually set-up to remove files that have not been touched for several days. > Can we not change permissions to protect the file form external > deletion and ensure the VM cleans it up itself? If VM crashes, the file is not deleted and it would be wrong if it persisted forever (or until reboot) because of permissions. Besides, I don't think there is a (portable, POSIX) permission that would prevent removing the file since cron job executes as root to be able to remove files created by several users. /tmp directory normally has "sticky" bit set, meaning that anybody can create files in it (ugo+w permission), but only owner of the file or owner of the dir or root can delete the file. cron jobs that remove /tmp files are set-up for the following reason: Processes usually clean-up after themselves but this is not guaranteed if they terminate with a crash or unhandleable signal (such as KILL). Regards, Peter > > David > >> Regards, Peter >> >> >> On 6/20/19 10:49 PM, David Holmes wrote: >>> Sorry it took me a while to understand the specifics of the problem. :) >>> >>> David >>> >>> On 20/06/2019 3:37 am, nijiaben wrote: >>>> Yes Alan, I mean this >>>> ------------------?Original?------------------ >>>> *From: *?"Alan Bateman"; >>>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>>> *To: *?"nijiaben"; "David >>>> Holmes"; >>>> "serviceability-dev"; >>>> "jdk8u-dev"; >>>> "hotspot-runtime-dev"; >>>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>>> On 20/06/2019 05:10, nijiaben wrote: >>>> ?> : >>>> ?> I know this mechanism, can we provide means of recovery to avoid >>>> unavailability caused by accidental deletion? >>>> ?> >>>> Are you concerned about tmpreaper or cron jobs that periodically >>>> cleanup >>>> /tmp? There may indeed be an issue for applications that run for weeks >>>> or months. If someone is using jmap, jcmd or other tools using the >>>> attach API then it will trigger the attach listener to start. When >>>> they >>>> come back in a few weeks then the .java_pid file may have been >>>> removed so they cannot attach. Is this what what you are pointing out? >>>> >>>> -Alan >> From jonathan.gibbons at oracle.com Fri Jun 21 18:58:40 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 21 Jun 2019 11:58:40 -0700 Subject: RFR XS,docs,13 JDK-8226593 Fix HTML in com/sun/jdi/doc-files/signature.html Message-ID: Please review a fix for an accessibility issue reported by Axe in src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html The issue is a conflict between an explicit `

...`
`? specified in the file and the automatic `
` added by javadoc.? The fix is just to remove the `
` element. JBS: https://bugs.openjdk.java.net/browse/JDK-8226593 -- Jon $ hg diff -R open diff -r 97c75e545302 src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html --- a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Fri Jun 21 11:41:29 2019 -0700 +++ b/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Fri Jun 21 11:52:35 2019 -0700 @@ -40,7 +40,6 @@ ? ? ? -
?

JDI Type Signatures

?
JDI Type Signatures
? @@ -74,6 +73,5 @@ ?has the following type signature: ?
??? (ILjava/lang/String;[I)J
 ?
- ? ? From lance.andersen at oracle.com Fri Jun 21 19:02:50 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 21 Jun 2019 15:02:50 -0400 Subject: RFR XS,docs,13 JDK-8226593 Fix HTML in com/sun/jdi/doc-files/signature.html In-Reply-To: References: Message-ID: +1 > On Jun 21, 2019, at 2:58 PM, Jonathan Gibbons wrote: > > Please review a fix for an accessibility issue reported by Axe in > src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > > The issue is a conflict between an explicit `
...`
` specified in the file and the automatic `
` added by javadoc. The fix is just to remove the `
` element. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226593 > > -- Jon > > > $ hg diff -R open > diff -r 97c75e545302 src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > --- a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Fri Jun 21 11:41:29 2019 -0700 > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html Fri Jun 21 11:52:35 2019 -0700 > @@ -40,7 +40,6 @@ > > > > -
>

JDI Type Signatures

>
JDI Type Signatures
> > @@ -74,6 +73,5 @@ > has the following type signature: >
    (ILjava/lang/String;[I)J
>  
> - > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From serguei.spitsyn at oracle.com Fri Jun 21 19:09:34 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Jun 2019 12:09:34 -0700 Subject: RFR XS,docs,13 JDK-8226593 Fix HTML in com/sun/jdi/doc-files/signature.html In-Reply-To: References: Message-ID: Hi Jon, It looks good to me. Thanks, Serguei On 6/21/19 11:58, Jonathan Gibbons wrote: > Please review a fix for an accessibility issue reported by Axe in > src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > > The issue is a conflict between an explicit `
role="main">...`
`? specified in the file and the automatic > `
` added by javadoc.? The fix is just to remove the `
` > element. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226593 > > -- Jon > > > $ hg diff -R open > diff -r 97c75e545302 > src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > --- a/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > Fri Jun 21 11:41:29 2019 -0700 > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > Fri Jun 21 11:52:35 2019 -0700 > @@ -40,7 +40,6 @@ > ? > ? > ? > -
> ?

JDI Type Signatures

> ?
JDI Type Signatures
> ? > @@ -74,6 +73,5 @@ > ?has the following type signature: > ?
??? (ILjava/lang/String;[I)J
> ?
> - > ? > ? > From peter.levart at gmail.com Fri Jun 21 19:14:17 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 21 Jun 2019 21:14:17 +0200 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <9b8e47f5-c6f5-3380-3f55-e1c6522d868f@oracle.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> <9b8e47f5-c6f5-3380-3f55-e1c6522d868f@oracle.com> Message-ID: <728be8d8-2d9c-520d-a6e4-dd17d39de32b@gmail.com> On 6/21/19 8:38 PM, Chris Plummer wrote: > On 6/21/19 8:57 AM, David Holmes wrote: >> Hi Peter, >> >> On 21/06/2019 7:55 am, Peter Levart wrote: >>> As far as I know, cron jobs that cleanup /tmp typically remove files >>> that have not been modified for a while. >>> >>> On Fedora for example, there is a systemd timer that triggers once >>> per day and executes systemd-tmpfiles which manages volatile and >>> temporary files and directories. The configuration for /tmp is the >>> following: >>> >>> # Clear tmp directories separately, to make them easier to override >>> q /tmp 1777 root root 10d >>> q /var/tmp 1777 root root 30d >>> >>> The age field (10 days for /tmp) has the following meaning: >>> >>> ??????? The age of a file system entry is determined from its last >>> modification timestamp (mtime), its last access timestamp (atime), >>> and (except for directories) its last status change >>> ??????? timestamp (ctime). Any of these three (or two) values will >>> prevent cleanup if it is more recent than the current time minus the >>> age field. >>> >>> So the solution could be for attach thread (if it is already >>> started) to update mtime or ctime of the .java_pid socket file >>> periodically so cleanup job would leave it alone. >>> >>> What do you think? >> >> I'm not keen on having the attach listener thread periodically wakeup >> just to do this. Can we not change permissions to protect the file >> form external deletion and ensure the VM cleans it up itself? > I think the JVM has a mechanism for cleaning up stale java_pid files > on startup (deleting those for which there is currently no java > process running). We need to make sure that changing permissions does > not break that. > > Rather than? having the JVM update mtime on the file, perhaps the onus > should be on the sys admin that is running scripts to clean up these > files in the first place. The scripts could first update mtime on an > java_pid files for which there is a java process still running. Problem is that those scripts are usually already set-up by default. OTOH it is relatively easy to create exceptions for files with a particular pattern. If /tmp/.java_pid* files are already managed by java launcher at every execution, then they need not be managed by a cron job. So there exists a workaround. It would only be more convenient if it was not needed. Regards, Peter > > Chris >> >> David >> >>> Regards, Peter >>> >>> >>> On 6/20/19 10:49 PM, David Holmes wrote: >>>> Sorry it took me a while to understand the specifics of the >>>> problem. :) >>>> >>>> David >>>> >>>> On 20/06/2019 3:37 am, nijiaben wrote: >>>>> Yes Alan, I mean this >>>>> ------------------?Original?------------------ >>>>> *From: *?"Alan Bateman"; >>>>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>>>> *To: *?"nijiaben"; "David >>>>> Holmes"; >>>>> "serviceability-dev"; >>>>> "jdk8u-dev"; >>>>> "hotspot-runtime-dev"; >>>>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>>>> On 20/06/2019 05:10, nijiaben wrote: >>>>> ?> : >>>>> ?> I know this mechanism, can we provide means of recovery to >>>>> avoid unavailability caused by accidental deletion? >>>>> ?> >>>>> Are you concerned about tmpreaper or cron jobs that periodically >>>>> cleanup >>>>> /tmp? There may indeed be an issue for applications that run for >>>>> weeks >>>>> or months. If someone is using jmap, jcmd or other tools using the >>>>> attach API then it will trigger the attach listener to start. When >>>>> they >>>>> come back in a few weeks then the .java_pid file may have been >>>>> removed so they cannot attach. Is this what what you are pointing >>>>> out? >>>>> >>>>> -Alan >>> > > From poonam.bajaj at oracle.com Fri Jun 21 19:21:15 2019 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Fri, 21 Jun 2019 12:21:15 -0700 Subject: RFR 8215523: Request for clarification in unexpected OU decrease with CMS GC Message-ID: <64c5a88a-a39d-fedb-7738-998bca61b6a7@oracle.com> Hello, Please review the changes for the fix of: Bug 8215523 : jstat reports incorrect values for OU for CMS GC Webrev: http://cr.openjdk.java.net/~poonam/8215523/webrev.00/ Problem: With CMS, at certain points, 'OU' (Old usage) values reported in the jstat output increase first and then drop down. This is wrong because the 'old usage' drops down without any old generation collection. Cause: For the 'used' values of different memory spaces, jstat uses a periodic task to read these values and update the corresponding jstat counters. For CMS generation, there is a sampler that periodically updates the 'used' counter: ?class GenerationUsedHelper : public PerfLongSampleHelper { 103 private: 104 Generation* _gen; 105 106 public: 107 GenerationUsedHelper(Generation* g) : _gen(g) { } 108 109 inline jlong take_sample() { 110 return _gen->used(); 111 } 112 }; The above used() call in turn makes a call to CompactibleFreeListSpace::used(). 376 size_t CompactibleFreeListSpace::used() const { 377 return capacity() - free(); 378 } 379 380 size_t CompactibleFreeListSpace::free() const { 381 // "MT-safe, but not MT-precise"(TM), if you will: i.e. 382 // if you do this while the structures are in flux you 383 // may get an approximate answer only; for instance 384 // because there is concurrent allocation either 385 // directly by mutators or for promotion during a GC. 386 // It's "MT-safe", however, in the sense that you are guaranteed 387 // not to crash and burn, for instance, because of walking 388 // pointers that could disappear as you were walking them. 389 // The approximation is because the various components 390 // that are read below are not read atomically (and 391 // further the computation of totalSizeInIndexedFreeLists() 392 // is itself a non-atomic computation. The normal use of 393 // this is during a resize operation at the end of GC 394 // and at that time you are guaranteed to get the 395 // correct actual value. However, for instance, this is 396 // also read completely asynchronously by the "perf-sampler" 397 // that supports jvmstat, and you are apt to see the values 398 // flicker in such cases. 399 assert(_dictionary != NULL, "No _dictionary?"); 400 return (_dictionary->total_chunk_size(DEBUG_ONLY(freelistLock())) + 401 totalSizeInIndexedFreeLists() + 402 _smallLinearAllocBlock._word_size) * HeapWordSize; 403 } As stated above in the code comments, free() can return an imprecise approximate value when allocations are happening in the CompactibleFreeListSpace at the same time, e.g. during direct allocations or promotions. Solution: For CMS, maintain an internal variable for the space usage. This internal variable gets updated only at points where the CMS space usage computation is guaranteed to be accurate. jstat and other memory usage monitoring tools get access to this stable value of used space. Testing: jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2,hs-tier3 Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Fri Jun 21 20:25:42 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 21 Jun 2019 13:25:42 -0700 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: <16d42ee3-99e3-e9d3-55cb-ebb41ffac565@oracle.com> References: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> <01902cdd-a0e8-4a6a-dc50-175cc00a2e3a@jetbrains.com> <057e627a-f488-0a30-d9e1-147627237383@oracle.com> <6c45bf9c-007c-dc6a-bf1a-6d7bf9ab5d50@jetbrains.com> <16d42ee3-99e3-e9d3-55cb-ebb41ffac565@oracle.com> Message-ID: <313efc27-c2d7-89b8-75b8-1ac7632edf64@oracle.com> Hi, Egor On 6/20/19 8:49 AM, Alan Bateman wrote: > On 20/06/2019 15:49, Egor Ushakov wrote: >> >> any news on https://bugs.openjdk.java.net/browse/JDK-8212117? >> I do not see any activity on this :( > > cc'ing Brent as he has picked up this issue. I think we want to fix this > and David has a patch in one of the linked issues. As it's changing long > standing behavior in a sublte way then it will likely need a > compatibility knob, the details of which need to be worked out before > the CSR can be submitted. > Myself (and others) have been looking into this as time has allowed. Some additional inconsistencies have been uncovered that should also be investigated. However, I think in the near term, we can proceed with a more focused fix to address 8212117 in particular. -Brent From poonam.bajaj at oracle.com Fri Jun 21 20:30:05 2019 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Fri, 21 Jun 2019 13:30:05 -0700 Subject: RFR 8215523: jstat reports incorrect values for OU for CMS GC In-Reply-To: <64c5a88a-a39d-fedb-7738-998bca61b6a7@oracle.com> References: <64c5a88a-a39d-fedb-7738-998bca61b6a7@oracle.com> Message-ID: <4bb04022-9460-3956-cf86-447bafab0bf4@oracle.com> Updating the subject line with the updated bug synopsis. And also, much thanks to Thomas Schatzl for his remarkable help in tweaking and refining this fix. regards, Poonam On 6/21/19 12:21 PM, Poonam Parhar wrote: > Hello, > > Please review the changes for the fix of: > > Bug 8215523 : jstat > reports incorrect values for OU for CMS GC > Webrev: http://cr.openjdk.java.net/~poonam/8215523/webrev.00/ > > Problem: > With CMS, at certain points, 'OU' (Old usage) values reported in the > jstat output increase first and then drop down. This is wrong because > the 'old usage' drops down without any old generation collection. > > Cause: > For the 'used' values of different memory spaces, jstat uses a > periodic task to read these values and update the corresponding jstat > counters. > > For CMS generation, there is a sampler that periodically updates the > 'used' counter: > > ?class GenerationUsedHelper : public PerfLongSampleHelper { > 103 private: > 104 Generation* _gen; > 105 > 106 public: > 107 GenerationUsedHelper(Generation* g) : _gen(g) { } > 108 > 109 inline jlong take_sample() { > 110 return _gen->used(); > 111 } > 112 }; > > The above used() call in turn makes a call to > CompactibleFreeListSpace::used(). > > 376 size_t CompactibleFreeListSpace::used() const { > 377 return capacity() - free(); > 378 } > 379 > 380 size_t CompactibleFreeListSpace::free() const { > 381 // "MT-safe, but not MT-precise"(TM), if you will: i.e. > 382 // if you do this while the structures are in flux you > 383 // may get an approximate answer only; for instance > 384 // because there is concurrent allocation either > 385 // directly by mutators or for promotion during a GC. > 386 // It's "MT-safe", however, in the sense that you are guaranteed > 387 // not to crash and burn, for instance, because of walking > 388 // pointers that could disappear as you were walking them. > 389 // The approximation is because the various components > 390 // that are read below are not read atomically (and > 391 // further the computation of totalSizeInIndexedFreeLists() > 392 // is itself a non-atomic computation. The normal use of > 393 // this is during a resize operation at the end of GC > 394 // and at that time you are guaranteed to get the > 395 // correct actual value. However, for instance, this is > 396 // also read completely asynchronously by the "perf-sampler" > 397 // that supports jvmstat, and you are apt to see the values > 398 // flicker in such cases. > 399 assert(_dictionary != NULL, "No _dictionary?"); > 400 return (_dictionary->total_chunk_size(DEBUG_ONLY(freelistLock())) + > 401 totalSizeInIndexedFreeLists() + > 402 _smallLinearAllocBlock._word_size) * HeapWordSize; > 403 } > > As stated above in the code comments, free() can return an imprecise > approximate value when allocations are happening in the > CompactibleFreeListSpace at the same time, e.g. during direct > allocations or promotions. > > Solution: > For CMS, maintain an internal variable for the space usage. This > internal variable gets updated only at points where the CMS space > usage computation is guaranteed to be accurate. jstat and other memory > usage monitoring tools get access to this stable value of used space. > > Testing: jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2,hs-tier3 > > Thanks, > Poonam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Jun 21 20:31:19 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Jun 2019 13:31:19 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <728be8d8-2d9c-520d-a6e4-dd17d39de32b@gmail.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> <9b8e47f5-c6f5-3380-3f55-e1c6522d868f@oracle.com> <728be8d8-2d9c-520d-a6e4-dd17d39de32b@gmail.com> Message-ID: <2a5bdf4f-e79c-202a-f09d-5c3a5ef5fa39@oracle.com> On 6/21/19 12:14 PM, Peter Levart wrote: > On 6/21/19 8:38 PM, Chris Plummer wrote: >> On 6/21/19 8:57 AM, David Holmes wrote: >>> Hi Peter, >>> >>> On 21/06/2019 7:55 am, Peter Levart wrote: >>>> As far as I know, cron jobs that cleanup /tmp typically remove >>>> files that have not been modified for a while. >>>> >>>> On Fedora for example, there is a systemd timer that triggers once >>>> per day and executes systemd-tmpfiles which manages volatile and >>>> temporary files and directories. The configuration for /tmp is the >>>> following: >>>> >>>> # Clear tmp directories separately, to make them easier to override >>>> q /tmp 1777 root root 10d >>>> q /var/tmp 1777 root root 30d >>>> >>>> The age field (10 days for /tmp) has the following meaning: >>>> >>>> ??????? The age of a file system entry is determined from its last >>>> modification timestamp (mtime), its last access timestamp (atime), >>>> and (except for directories) its last status change >>>> ??????? timestamp (ctime). Any of these three (or two) values will >>>> prevent cleanup if it is more recent than the current time minus >>>> the age field. >>>> >>>> So the solution could be for attach thread (if it is already >>>> started) to update mtime or ctime of the .java_pid socket file >>>> periodically so cleanup job would leave it alone. >>>> >>>> What do you think? >>> >>> I'm not keen on having the attach listener thread periodically >>> wakeup just to do this. Can we not change permissions to protect the >>> file form external deletion and ensure the VM cleans it up itself? >> I think the JVM has a mechanism for cleaning up stale java_pid files >> on startup (deleting those for which there is currently no java >> process running). We need to make sure that changing permissions does >> not break that. >> >> Rather than? having the JVM update mtime on the file, perhaps the >> onus should be on the sys admin that is running scripts to clean up >> these files in the first place. The scripts could first update mtime >> on an java_pid files for which there is a java process still running. > > Problem is that those scripts are usually already set-up by default. > > OTOH it is relatively easy to create exceptions for files with a > particular pattern. If /tmp/.java_pid* files are already managed by > java launcher at every execution, then they need not be managed by a > cron job. So there exists a workaround. It would only be more > convenient if it was not needed. I'm starting to second guess my thinking that there is any such .java_pid removal support. I thought I saw it once, but can't find it now. All I can find is that AttachListener::vm_start() will remove any stale .java_pid file in place for the current pid. And judging by the large collection of .java_pid files on my linux dev box, I doubt there is any removal. What I might have been remembering is perfdata file removal. In /tmp/hsperfdata_/ I'm only seeing perfdata files for existing java processes. Chris > > Regards, Peter > >> >> Chris >>> >>> David >>> >>>> Regards, Peter >>>> >>>> >>>> On 6/20/19 10:49 PM, David Holmes wrote: >>>>> Sorry it took me a while to understand the specifics of the >>>>> problem. :) >>>>> >>>>> David >>>>> >>>>> On 20/06/2019 3:37 am, nijiaben wrote: >>>>>> Yes Alan, I mean this >>>>>> ------------------?Original?------------------ >>>>>> *From: *?"Alan Bateman"; >>>>>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>>>>> *To: *?"nijiaben"; "David >>>>>> Holmes"; >>>>>> "serviceability-dev"; >>>>>> "jdk8u-dev"; >>>>>> "hotspot-runtime-dev"; >>>>>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>>>>> On 20/06/2019 05:10, nijiaben wrote: >>>>>> ?> : >>>>>> ?> I know this mechanism, can we provide means of recovery to >>>>>> avoid unavailability caused by accidental deletion? >>>>>> ?> >>>>>> Are you concerned about tmpreaper or cron jobs that periodically >>>>>> cleanup >>>>>> /tmp? There may indeed be an issue for applications that run for >>>>>> weeks >>>>>> or months. If someone is using jmap, jcmd or other tools using the >>>>>> attach API then it will trigger the attach listener to start. >>>>>> When they >>>>>> come back in a few weeks then the .java_pid file may have been >>>>>> removed so they cannot attach. Is this what what you are pointing >>>>>> out? >>>>>> >>>>>> -Alan >>>> >> >> > From serguei.spitsyn at oracle.com Fri Jun 21 23:48:27 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Jun 2019 16:48:27 -0700 Subject: (13) RFR (S): 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events Message-ID: <38f01ff0-46f6-adf6-cdbb-014373ce4140@oracle.com> An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Sat Jun 22 00:34:54 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 21 Jun 2019 17:34:54 -0700 Subject: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed In-Reply-To: References: <19c92bb0-0cb3-0626-6609-0c3f938d22a2@oracle.com> Message-ID: Looks good to me too. --alex On 06/21/2019 11:38, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > > On 6/21/19 06:44, Daniel D. Daugherty wrote: >> On 6/21/19 1:24 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the test bug fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8224555 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8224555-mon-events2-test.1/ >> >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001.java >> ??? L99: ??????????? for (int j = 0; j < 1000; j++) { >> ??????? Why a literal '1000' this time? You could use "timeout / 20" >> ??????? based on: >> >> ??????? L120: ??????? timeout = argHandler.getWaitTime() * 60 * 1000; >> >> ??????? That seems to be what all the other timeout logic is based on. > > Good suggestion, thanks. > Taken. > > >> >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/tc02t001.cpp >> ??? No comments. >> >> Thumbs up. I don't need a new webrev if you decide to make the >> minor change above. > > Thanks you for review, Dan! > Serguei > > >> >> Dan >> >>> >>> >>> Summary: >>> ? The test sleeps for 1 sec in hope to get a contention on the >>> monitor tc02t001Thread.M. >>> ? It seems, this is not enough when the JFR is enabled. >>> ? The fix uses a better approach to ensure events are really happen. >>> ? This approach is similar to the on in the fix of 8223736 (just >>> reviewed). >>> >>> ? Also, the class line number sensitive tc02t001Thread is moved to >>> the beginning of >>> ? the file to make it independent from the rest of the file. >>> >>> >>> Testing: >>> ? A mach5 submission is in progress. >>> >>> >>> Thanks, >>> Serguei >> > From alexey.menkov at oracle.com Sat Jun 22 00:51:03 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 21 Jun 2019 17:51:03 -0700 Subject: (13) RFR (S): 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events In-Reply-To: <38f01ff0-46f6-adf6-cdbb-014373ce4140@oracle.com> References: <38f01ff0-46f6-adf6-cdbb-014373ce4140@oracle.com> Message-ID: <9647b2e4-e38f-38ef-230a-69da22e19e1f@oracle.com> LGTM --alex On 06/21/2019 16:48, serguei.spitsyn at oracle.com wrote: > Please, review a test bug fix for: > https://bugs.openjdk.java.net/browse/JDK-8226595 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226595-mon-events-correction.1/ > > > Summary: > ? The recent fix of https://bugs.openjdk.java.net/browse/JDK-8223736 > introduced another issue. > ? Now, there is a whole in synchronization in updating the static field > 'lastEnterEventsCount' > ? in the method run(). > ? Additionally, this update does a cleanup of the commented out > debugging code. > > ? Thanks a lot to Alex for filing this new bug and it's analysis! > > > Testing: > ? A mach5 submission is in progress. > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Sat Jun 22 00:52:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Jun 2019 17:52:58 -0700 Subject: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed In-Reply-To: References: <19c92bb0-0cb3-0626-6609-0c3f938d22a2@oracle.com> Message-ID: <08f5314d-eeb5-caae-2c4f-eda9eedfc4f9@oracle.com> Thanks a lot! Serguei On 6/21/19 17:34, Alex Menkov wrote: > Looks good to me too. > > --alex > > On 06/21/2019 11:38, serguei.spitsyn at oracle.com wrote: >> Hi Dan, >> >> >> On 6/21/19 06:44, Daniel D. Daugherty wrote: >>> On 6/21/19 1:24 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the test bug fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8224555 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8224555-mon-events2-test.1/ >>>> >>> >>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001.java >>> >>> ??? L99: ??????????? for (int j = 0; j < 1000; j++) { >>> ??????? Why a literal '1000' this time? You could use "timeout / 20" >>> ??????? based on: >>> >>> ??????? L120: ??????? timeout = argHandler.getWaitTime() * 60 * 1000; >>> >>> ??????? That seems to be what all the other timeout logic is based on. >> >> Good suggestion, thanks. >> Taken. >> >> >>> >>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/tc02t001.cpp >>> >>> ??? No comments. >>> >>> Thumbs up. I don't need a new webrev if you decide to make the >>> minor change above. >> >> Thanks you for review, Dan! >> Serguei >> >> >>> >>> Dan >>> >>>> >>>> >>>> Summary: >>>> ? The test sleeps for 1 sec in hope to get a contention on the >>>> monitor tc02t001Thread.M. >>>> ? It seems, this is not enough when the JFR is enabled. >>>> ? The fix uses a better approach to ensure events are really happen. >>>> ? This approach is similar to the on in the fix of 8223736 (just >>>> reviewed). >>>> >>>> ? Also, the class line number sensitive tc02t001Thread is moved to >>>> the beginning of >>>> ? the file to make it independent from the rest of the file. >>>> >>>> >>>> Testing: >>>> ? A mach5 submission is in progress. >>>> >>>> >>>> Thanks, >>>> Serguei >>> >> From serguei.spitsyn at oracle.com Sat Jun 22 00:53:42 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Jun 2019 17:53:42 -0700 Subject: (13) RFR (S): 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events In-Reply-To: <9647b2e4-e38f-38ef-230a-69da22e19e1f@oracle.com> References: <38f01ff0-46f6-adf6-cdbb-014373ce4140@oracle.com> <9647b2e4-e38f-38ef-230a-69da22e19e1f@oracle.com> Message-ID: <46c34ac5-f431-d12e-491a-4b7731f48658@oracle.com> Thanks, Alex! Serguei On 6/21/19 17:51, Alex Menkov wrote: > LGTM > > --alex > > On 06/21/2019 16:48, serguei.spitsyn at oracle.com wrote: >> Please, review a test bug fix for: >> https://bugs.openjdk.java.net/browse/JDK-8226595 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226595-mon-events-correction.1/ >> >> >> >> Summary: >> ?? The recent fix of https://bugs.openjdk.java.net/browse/JDK-8223736 >> introduced another issue. >> ?? Now, there is a whole in synchronization in updating the static >> field 'lastEnterEventsCount' >> ?? in the method run(). >> ?? Additionally, this update does a cleanup of the commented out >> debugging code. >> >> ?? Thanks a lot to Alex for filing this new bug and it's analysis! >> >> >> Testing: >> ?? A mach5 submission is in progress. >> >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Sat Jun 22 00:59:50 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 21 Jun 2019 17:59:50 -0700 Subject: RFR 8215523: jstat reports incorrect values for OU for CMS GC In-Reply-To: <4bb04022-9460-3956-cf86-447bafab0bf4@oracle.com> References: <64c5a88a-a39d-fedb-7738-998bca61b6a7@oracle.com> <4bb04022-9460-3956-cf86-447bafab0bf4@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Jun 22 01:07:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Jun 2019 18:07:39 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <751a9c56-5d71-ec0b-66c9-ea7fb60b066c@gmail.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> <751a9c56-5d71-ec0b-66c9-ea7fb60b066c@gmail.com> Message-ID: <9fdfb385-9cad-d2c2-c50e-7cc43932a108@oracle.com> On 21/06/2019 11:57 am, Peter Levart wrote: > Hi David, > > On 6/21/19 5:57 PM, David Holmes wrote: >> Hi Peter, >> >> On 21/06/2019 7:55 am, Peter Levart wrote: >>> As far as I know, cron jobs that cleanup /tmp typically remove files >>> that have not been modified for a while. >>> >>> On Fedora for example, there is a systemd timer that triggers once >>> per day and executes systemd-tmpfiles which manages volatile and >>> temporary files and directories. The configuration for /tmp is the >>> following: >>> >>> # Clear tmp directories separately, to make them easier to override >>> q /tmp 1777 root root 10d >>> q /var/tmp 1777 root root 30d >>> >>> The age field (10 days for /tmp) has the following meaning: >>> >>> ??????? The age of a file system entry is determined from its last >>> modification timestamp (mtime), its last access timestamp (atime), >>> and (except for directories) its last status change >>> ??????? timestamp (ctime). Any of these three (or two) values will >>> prevent cleanup if it is more recent than the current time minus the >>> age field. >>> >>> So the solution could be for attach thread (if it is already started) >>> to update mtime or ctime of the .java_pid socket file >>> periodically so cleanup job would leave it alone. >>> >>> What do you think? >> >> I'm not keen on having the attach listener thread periodically wakeup >> just to do this. > > The required frequency would be very low. Once a day would be more than > enough. cron jobs are usually set-up to remove files that have not been > touched for several days. I would have thought it more prudent to remove files for which the owning process no longer exists. :( Cheers, David ----- >> Can we not change permissions to protect the file form external >> deletion and ensure the VM cleans it up itself? > > If VM crashes, the file is not deleted and it would be wrong if it > persisted forever (or until reboot) because of permissions. Besides, I > don't think there is a (portable, POSIX) permission that would prevent > removing the file since cron job executes as root to be able to remove > files created by several users. /tmp directory normally has "sticky" bit > set, meaning that anybody can create files in it (ugo+w permission), but > only owner of the file or owner of the dir or root can delete the file. > > cron jobs that remove /tmp files are set-up for the following reason: > Processes usually clean-up after themselves but this is not guaranteed > if they terminate with a crash or unhandleable signal (such as KILL). > > Regards, Peter > >> >> David >> >>> Regards, Peter >>> >>> >>> On 6/20/19 10:49 PM, David Holmes wrote: >>>> Sorry it took me a while to understand the specifics of the problem. :) >>>> >>>> David >>>> >>>> On 20/06/2019 3:37 am, nijiaben wrote: >>>>> Yes Alan, I mean this >>>>> ------------------?Original?------------------ >>>>> *From: *?"Alan Bateman"; >>>>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>>>> *To: *?"nijiaben"; "David >>>>> Holmes"; >>>>> "serviceability-dev"; >>>>> "jdk8u-dev"; >>>>> "hotspot-runtime-dev"; >>>>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>>>> On 20/06/2019 05:10, nijiaben wrote: >>>>> ?> : >>>>> ?> I know this mechanism, can we provide means of recovery to avoid >>>>> unavailability caused by accidental deletion? >>>>> ?> >>>>> Are you concerned about tmpreaper or cron jobs that periodically >>>>> cleanup >>>>> /tmp? There may indeed be an issue for applications that run for weeks >>>>> or months. If someone is using jmap, jcmd or other tools using the >>>>> attach API then it will trigger the attach listener to start. When >>>>> they >>>>> come back in a few weeks then the .java_pid file may have been >>>>> removed so they cannot attach. Is this what what you are pointing out? >>>>> >>>>> -Alan >>> > From peter.levart at gmail.com Sat Jun 22 07:33:50 2019 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Jun 2019 09:33:50 +0200 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <9fdfb385-9cad-d2c2-c50e-7cc43932a108@oracle.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> <751a9c56-5d71-ec0b-66c9-ea7fb60b066c@gmail.com> <9fdfb385-9cad-d2c2-c50e-7cc43932a108@oracle.com> Message-ID: <776ced13-fe95-95b4-87fb-8600cf4d8228@gmail.com> On 6/22/19 3:07 AM, David Holmes wrote: >>>> So the solution could be for attach thread (if it is already >>>> started) to update mtime or ctime of the .java_pid socket file >>>> periodically so cleanup job would leave it alone. >>>> >>>> What do you think? >>> >>> I'm not keen on having the attach listener thread periodically >>> wakeup just to do this. >> >> The required frequency would be very low. Once a day would be more >> than enough. cron jobs are usually set-up to remove files that have >> not been touched for several days. > > I would have thought it more prudent to remove files for which the > owning process no longer exists. :( I don't know if there is a way to reliably associate a file with an "owning" process. Sure /tmp/.java_pid has the process ID encoded in its name, but that is java specific and a generic cron job knows nothing about that pattern by default. If the process still has the file open, there is a way to detect that and "tmpwatch" for example has an option --fuser that skips open files. There are other tools for managing temporary files that can't do that (systemd-tmpfiles for example) and only use file's timestamps to determine if the file is still "alive" or not... Regards, Peter > > Cheers, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Sat Jun 22 07:52:18 2019 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Jun 2019 09:52:18 +0200 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <776ced13-fe95-95b4-87fb-8600cf4d8228@gmail.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5331710d-67c8-7d17-1723-52ecf2b4b255@oracle.com> <751a9c56-5d71-ec0b-66c9-ea7fb60b066c@gmail.com> <9fdfb385-9cad-d2c2-c50e-7cc43932a108@oracle.com> <776ced13-fe95-95b4-87fb-8600cf4d8228@gmail.com> Message-ID: <1cf535b7-507b-f2e8-d075-bdeb426e6e7e@gmail.com> Here's? a thread that describes why systemd-tmpfiles doesn't implement the --fuser option that tmpwatch does: https://lists.freedesktop.org/archives/systemd-devel/2015-April/031339.html The authors say the following: /In almost all cases the atime checks we do should be fully sufficient// //though. Do you have a case where they aren't?// // //(Note that we do compare all unix sockets we find with /proc/net/unix// //though, which is relatively efficient still. Also, as unix sockets// //which are actively used do not get their atime bumped this is kinda a// //necessity to cover them nicely.)/ ...meaning that /tmp/.java_pid which are UNIX sockets shouldn't be deleted by systemd-tmpfiles while still in use. Users of tmpwatch OTOH should enable the --fuser option. Is this enough for you,? Nijiaben? Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Sat Jun 22 13:01:00 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 22 Jun 2019 09:01:00 -0400 Subject: (13) RFR (S): 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events In-Reply-To: <38f01ff0-46f6-adf6-cdbb-014373ce4140@oracle.com> References: <38f01ff0-46f6-adf6-cdbb-014373ce4140@oracle.com> Message-ID: On 6/21/19 7:48 PM, serguei.spitsyn at oracle.com wrote: > Please, review a test bug fix for: > https://bugs.openjdk.java.net/browse/JDK-8226595 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226595-mon-events-correction.1/ test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001.java ??? No comments. Thumbs up. Dan > > > Summary: > ? The recent fix of https://bugs.openjdk.java.net/browse/JDK-8223736 > introduced another issue. > ? Now, there is a whole in synchronization in updating the static > field 'lastEnterEventsCount' > ? in the method run(). > ? Additionally, this update does a cleanup of the commented out > debugging code. > > ? Thanks a lot to Alex for filing this new bug and it's analysis! > > > Testing: > ? A mach5 submission is in progress. > > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Jun 22 21:34:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 22 Jun 2019 14:34:36 -0700 Subject: (13) RFR (S): 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events In-Reply-To: References: <38f01ff0-46f6-adf6-cdbb-014373ce4140@oracle.com> Message-ID: <751674c0-95bf-10f7-739c-d0869d325e0b@oracle.com> Thanks you a lot, Dan! Serguei On 6/22/19 06:01, Daniel D. Daugherty wrote: > On 6/21/19 7:48 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a test bug fix for: >> https://bugs.openjdk.java.net/browse/JDK-8226595 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226595-mon-events-correction.1/ > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001.java > ??? No comments. > > Thumbs up. > > Dan > > >> >> >> Summary: >> ? The recent fix of https://bugs.openjdk.java.net/browse/JDK-8223736 >> introduced another issue. >> ? Now, there is a whole in synchronization in updating the static >> field 'lastEnterEventsCount' >> ? in the method run(). >> ? Additionally, this update does a cleanup of the commented out >> debugging code. >> >> ? Thanks a lot to Alex for filing this new bug and it's analysis! >> >> >> Testing: >> ? A mach5 submission is in progress. >> >> >> Thanks, >> Serguei > From kirk.pepperdine at gmail.com Sun Jun 23 05:49:39 2019 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Sat, 22 Jun 2019 22:49:39 -0700 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: <958CE880-05D1-41FA-B4C8-337F5A63984E@oracle.com> References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> <3FB508A6-3513-4DB6-96C2-E986A7DD3CB5@gmail.com> <958CE880-05D1-41FA-B4C8-337F5A63984E@oracle.com> Message-ID: <11F4016B-690C-45EE-AA6C-D82C9A53A014@gmail.com> Hi Bob, 100% isolate reduces visibility and from a diagnostic perspective there are a number of issues that can only be seen if you have access to the host information. Also one of the things that gets forgotten is how this change will affect or break tooling. I would suggest a better solution would be to introduce a new MXBean that was ?container aware?. Kind regards, Kikr Pepperdine > On Jun 21, 2019, at 5:40 AM, Bob Vandette wrote: > > I agree with you Mario. When I originally designed the jdk.internal.platform.Metrics > API, I was considering providing both a Host and Container Metrics implementation. > The problem is that the primary goal of containers is to provide isolation (hiding access to > the host) and it would be very difficult to provide reliable forms of both metrics from within > a container. The Linux kernel does leak some host metric information but not everything. > This is why I decided to focus on the container configuration and metric data. If Host > metrics are of interest you can always just run Java outside of a container. > > Bob. > >> On Jun 21, 2019, at 8:27 AM, Mario Torre > wrote: >> >> Hi Kirk, >> >> I think I understand what you mean, however then the OS Bean should be consistent regarding CPU information as well. >> >> I think I remember why this was fixed the way it is now was because of incorrect behavior during GC configuration, or something along those lines, so I guess we would need two APIs after all to give tooling a way to sneak into the actual hardware properties. >> >> I would guess, however, that from the point of view of a containerised VM its OS is the container not the bare metal (or virtualized metal perhaps), so tooling would need to check specifically for a separate bean. >> >> That could be indicated via a property in the OS Bean (if it?s not the case already). >> >> Nevertheless, I think consistency in the OS Bean should be achieved. >> >> Cheers, >> Mario >> >> On Fri 21. Jun 2019 at 13:23, Kirk Pepperdine > wrote: >> Hi Mario, >> >> I don?t believe the MBean returns the wrong information. Is it not that the calls by-pass the container? Would it not be more appropriate to add a container aware mean? From a tooling perspective it?s a mistake to completely seal the JVM away from the hardware as it makes certain diagnostics more difficult to perform. >> >> Kind regards, >> Kirk >> >> >>> On Jun 21, 2019, at 6:06 AM, Mario Torre > wrote: >>> >>> The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data. >>> >>> I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think. >>> >>> Bob, do you have some design ideas to share regarding the new interface? I think this may be an interesting project to pick up, even for students wanting to write a thesis, as it seems time is a limiting factor here for you to work on that? >>> >>> Cheers, >>> Mario >>> >>> On Fri 21. Jun 2019 at 10:53, Severin Gehwolf > wrote: >>> Hi Bob, >>> >>> On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >>> > Hi Andrew, >>> > >>> > I am aware of the limitations of the OperatingSystemMXBean and was >>> > hoping to address these limitations during the implementation of >>> > https://bugs.openjdk.java.net/browse/JDK-8199944 . >>> > >>> > It would be helpful if you feel this is important to add some votes >>> > to this issue. >>> >>> It seems strange that the getAvailableProcessors() returns the >>> container limit, while the memory limits are for the physical host. If >>> anything, shouldn't they agree (both physical host or both container >>> limits)? >>> >>> When I briefly looked into it initially it seems to be a side-effect of >>> what is being used by the JDK code implementation-wise. IIRC >>> getAvailableProcessors() uses a runtime call. Memory reporting has it's >>> own logic[1], thus not reporting the container limit. >>> >>> This seems weird from a consistency perspective. Thoughts? >>> >>> If I understand you correctly, you are arguing that container reporting >>> should go into its own MX bean. On the other hand, CPU reporting for >>> the OS MX bean is container aware already. That makes me believe we >>> should rather make this consistent before evaluating a new MX bean. >>> >>> Thanks, >>> Severin >>> >>> [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 >>> >>> >>> > Bob. >>> > >>> > >>> > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > >>> > > wrote: >>> > > >>> > > Hi all, >>> > > >>> > > Apologies if this is not the most appropriate list, in which case >>> > > please direct me where to go. >>> > > >>> > > I've noticed a surprising result from the >>> > > com.sun.management.OperatingSystemMXBean implementation when >>> > > running in >>> > > a containerized (specifically, using Docker on Linux) environment. >>> > > The >>> > > bean appears to be container-aware for processors, in that running >>> > > with >>> > > Docker option `--cpus 1.0` for example, on a multicore system, will >>> > > cause both java.lang.Runtime#availableProcessors and >>> > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / >>> > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to >>> > > return 1. However, the Docker option `--memory 100M` (or any other >>> > > limit value) is not reflected in the value returned by >>> > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize >>> > > , >>> > > and instead the returned value is still the total physical memory >>> > > of >>> > > the host machine - of which only a small portion may actually be >>> > > available to the "Operating System" of the JVM. Similarly for the >>> > > methods regarding free physical memory, total swap, and free swap. >>> > > >>> > > I have attached a patch which adds a small reproducer to the >>> > > existing >>> > > MemoryAwareness test. >>> > > >>> > > This seems like a bug to me, since if the imposed container limit >>> > > on >>> > > processors as a resource is included as part of the "Operating >>> > > System" >>> > > resource reporting, then surely memory resources should be reported >>> > > the >>> > > same way. As I said, I found the current behaviour quite >>> > > surprising. >>> > > >>> > > -- >>> > > Andrew Azores >>> > > Software Engineer, OpenJDK Team >>> > > Red Hat >>> > > >>> > >>> > >>> >>> -- >>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >>> >>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >>> Proud GNU Classpath developer: http://www.classpath.org/ >>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >>> >>> Please, support open standards: >>> http://endsoftpatents.org/ >> >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >> Proud GNU Classpath developer: http://www.classpath.org/ >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Sun Jun 23 05:54:48 2019 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Sat, 22 Jun 2019 22:54:48 -0700 Subject: OperatingSystemMXBean unaware of container memory limits In-Reply-To: References: <1C482800-2521-4325-BCBD-579F9BEA5425@oracle.com> <3FB508A6-3513-4DB6-96C2-E986A7DD3CB5@gmail.com> Message-ID: <8A24A29A-4D4E-4283-BE48-34F6CC7DED90@gmail.com> Hi Mario, I completely agree, the OS Bean should be consistent with the memory. That said I favor introducing new MXBeans to achieve the desired effects. If there is no container than the container MXBean could simply not be instantiated. I?m looking for more visibility especially for the purposes of supporting diagnostic tooling. If visibility is shut down it?s just makes it that much harder to perform any reasonable level of high level diagnostics. Kind regards, Kirk > On Jun 21, 2019, at 5:27 AM, Mario Torre wrote: > > Hi Kirk, > > I think I understand what you mean, however then the OS Bean should be consistent regarding CPU information as well. > > I think I remember why this was fixed the way it is now was because of incorrect behavior during GC configuration, or something along those lines, so I guess we would need two APIs after all to give tooling a way to sneak into the actual hardware properties. > > I would guess, however, that from the point of view of a containerised VM its OS is the container not the bare metal (or virtualized metal perhaps), so tooling would need to check specifically for a separate bean. > > That could be indicated via a property in the OS Bean (if it?s not the case already). > > Nevertheless, I think consistency in the OS Bean should be achieved. > > Cheers, > Mario > > On Fri 21. Jun 2019 at 13:23, Kirk Pepperdine > wrote: > Hi Mario, > > I don?t believe the MBean returns the wrong information. Is it not that the calls by-pass the container? Would it not be more appropriate to add a container aware mean? From a tooling perspective it?s a mistake to completely seal the JVM away from the hardware as it makes certain diagnostics more difficult to perform. > > Kind regards, > Kirk > > >> On Jun 21, 2019, at 6:06 AM, Mario Torre > wrote: >> >> The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data. >> >> I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think. >> >> Bob, do you have some design ideas to share regarding the new interface? I think this may be an interesting project to pick up, even for students wanting to write a thesis, as it seems time is a limiting factor here for you to work on that? >> >> Cheers, >> Mario >> >> On Fri 21. Jun 2019 at 10:53, Severin Gehwolf > wrote: >> Hi Bob, >> >> On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >> > Hi Andrew, >> > >> > I am aware of the limitations of the OperatingSystemMXBean and was >> > hoping to address these limitations during the implementation of >> > https://bugs.openjdk.java.net/browse/JDK-8199944 . >> > >> > It would be helpful if you feel this is important to add some votes >> > to this issue. >> >> It seems strange that the getAvailableProcessors() returns the >> container limit, while the memory limits are for the physical host. If >> anything, shouldn't they agree (both physical host or both container >> limits)? >> >> When I briefly looked into it initially it seems to be a side-effect of >> what is being used by the JDK code implementation-wise. IIRC >> getAvailableProcessors() uses a runtime call. Memory reporting has it's >> own logic[1], thus not reporting the container limit. >> >> This seems weird from a consistency perspective. Thoughts? >> >> If I understand you correctly, you are arguing that container reporting >> should go into its own MX bean. On the other hand, CPU reporting for >> the OS MX bean is container aware already. That makes me believe we >> should rather make this consistent before evaluating a new MX bean. >> >> Thanks, >> Severin >> >> [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 >> >> >> > Bob. >> > >> > >> > > On Jun 20, 2019, at 9:43 AM, Andrew Azores > >> > > wrote: >> > > >> > > Hi all, >> > > >> > > Apologies if this is not the most appropriate list, in which case >> > > please direct me where to go. >> > > >> > > I've noticed a surprising result from the >> > > com.sun.management.OperatingSystemMXBean implementation when >> > > running in >> > > a containerized (specifically, using Docker on Linux) environment. >> > > The >> > > bean appears to be container-aware for processors, in that running >> > > with >> > > Docker option `--cpus 1.0` for example, on a multicore system, will >> > > cause both java.lang.Runtime#availableProcessors and >> > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors / >> > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to >> > > return 1. However, the Docker option `--memory 100M` (or any other >> > > limit value) is not reflected in the value returned by >> > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize >> > > , >> > > and instead the returned value is still the total physical memory >> > > of >> > > the host machine - of which only a small portion may actually be >> > > available to the "Operating System" of the JVM. Similarly for the >> > > methods regarding free physical memory, total swap, and free swap. >> > > >> > > I have attached a patch which adds a small reproducer to the >> > > existing >> > > MemoryAwareness test. >> > > >> > > This seems like a bug to me, since if the imposed container limit >> > > on >> > > processors as a resource is included as part of the "Operating >> > > System" >> > > resource reporting, then surely memory resources should be reported >> > > the >> > > same way. As I said, I found the current behaviour quite >> > > surprising. >> > > >> > > -- >> > > Andrew Azores >> > > Software Engineer, OpenJDK Team >> > > Red Hat >> > > >> > >> > >> >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens >> Proud GNU Classpath developer: http://www.classpath.org/ >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Jun 24 23:28:11 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 24 Jun 2019 16:28:11 -0700 Subject: (13) RFR: 8225679: reference to http://java.sun.com/products/JavaManagement/download.html Message-ID: <10b44901-871d-f2fa-2fb9-b0a592acb3a8@oracle.com> Hi all, please review small doc fix for jdk13 jira: https://bugs.openjdk.java.net/browse/JDK-8225679 webrev: http://cr.openjdk.java.net/~amenkov/docs/jmx_optional/webrev/ https://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-java-plat-419418.html is the only page I found which has a link to download JMX ref. implementation (and it includes jmx optional components) --alex From yasuenag at gmail.com Tue Jun 25 07:47:46 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 25 Jun 2019 16:47:46 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: <690ab155-8b8d-9da7-5a9a-426148c0dd9f@gmail.com> References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> <0f945652-4de0-5d57-66e7-874464c10903@oracle.com> <1b56d28c-f0da-3b84-d6e0-5cd2f00501ef@gmail.com> <690ab155-8b8d-9da7-5a9a-426148c0dd9f@gmail.com> Message-ID: Hi, This enhancement has been retargeted to 14, and the CSR has been approved. I uploaded a webrev for 14. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.03/ It includes the fix to rename `--remote` to `--connect` that is suggested in CSR. It passed tests on submit repo. Thanks, Yasumasa 2019?6?17?(?) 22:11 Yasumasa Suenaga : > > Hi David, > > On 2019/06/17 21:42, David Holmes wrote: > > Hi Yasumasa, > > > > On 17/06/2019 6:50 pm, Yasumasa Suenaga wrote: > >> Hi David, > >> > >> 8209790 is filed as a bug. > > > > I don't agree this is a "bug" - sorry. For this to be a bug there must > > be some specification of behaviour that the implementation is violating. > > Is that the case? To me this is missing functionality which makes it an > > enhancement. > > The feature for connecting to remote debug server has been provided JDK > 8 or earlier. However it was missed since JDK 9. So I think we can > handle it as a "bug". > Anyway, I added jdk13-enhancement-request label to JBS. I'm waiting for > the approval. > > > >> According to [1], I think we can push the fix to jdk/jdk13. Does it > >> correct? > >> > >> I'm not sure which version (13 or 14) should be set on JBS before > >> pushing. > > > > Just to clarify the process here, you don't want to set the "Fix > > Version" to 13 or 14 in JBS before pushing. That will be set based on > > the repo you push to. If you push to jdk/jdk it will be 14. If you push > > to jdk/jdk13 it will be 13. Any fix pushed to jdk/jdk13 will be > > "automatically" forward-ported to jdk/jdk and thus 14. > > Thanks! I got it. > > > Yasumasa > > > > David > > ----- > > > >> (Of course I will push it after the CSR is approved.) > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003051.html > >> > >> > >> On 2019/06/17 17:06, David Holmes wrote: > >>> Hi Yasumasa, > >>> > >>> On 17/06/2019 8:52 am, Yasumasa Suenaga wrote: > >>>> 2019?6?17?(?) 6:47 serguei.spitsyn at oracle.com > >>>> >>>> >: > >>>> > >>>> Forgot to tell... > >>>> This can be pushed only after the CSR is approved. > >>>> > >>>> > >>>> Sure! > >>>> And I will push it when I get second reviewer. > >>>> > >>>> BTW should I push this change to jdk/jdk? or push to jdk/jdk13 > >>>> manually? > >>> > >>> JDK 13 has now entered RDP1 so if you want this to go into 13 it will > >>> need special approval: > >>> > >>> http://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process > >>> > >>> Otherwise push to jdk/jdk and it will be for JDK 14. > >>> > >>> Cheers, > >>> David > >>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> Serguei > >>>> > >>>> > >>>> On 6/16/19 14:44, serguei.spitsyn at oracle.com > >>>> wrote: > >>>> > Hi Yasumasa, > >>>> > > >>>> > > >>>> > On 6/16/19 07:22, Yasumasa Suenaga wrote: > >>>> >> Hi Serguei, > >>>> >> > >>>> >> >>> One minor suggestion is to use the final field NO_REMOTE > >>>> instead > >>>> >> >>> of null for initialization of the local variable "remote". > >>>> >> > >>>> >> I fixed it on new webrev. Could you check again? > >>>> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ > >>>> > > >>>> > > >>>> > It looks good. > >>>> > Thanks you for the update! > >>>> > > >>>> >> > >>>> >> >> IMHO refactoring should be worked on another issue. > >>>> >> > > >>>> >> > Agreed. > >>>> >> > >>>> >> I filed it to JBS: > >>>> >> https://bugs.openjdk.java.net/browse/JDK-8226204 > >>>> > > >>>> > Thank you for filing the enhancement! > >>>> > > >>>> > Thanks. > >>>> > Serguei > >>>> > > >>>> > > >>>> >> Thanks, > >>>> >> > >>>> >> Yasumasa > >>>> >> > >>>> >> > >>>> >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com > >>>> wrote: > >>>> >>> Hi Yasumasa, > >>>> >>> > >>>> >>> > >>>> >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: > >>>> >>>> Hi Serguei, > >>>> >>>> > >>>> >>>> Thank you for your comment! > >>>> >>>> > >>>> >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com > >>>> wrote: > >>>> >>>>> Hi Yasumasa, > >>>> >>>>> > >>>> >>>>> I've added myself as a reviewer, so you can finalize it now. > >>>> >>>> > >>>> >>>> I moved CSR to Finalized, and added a comment for your > >>>> question. > >>>> >>> > >>>> >>> Okay, thanks! > >>>> >>> > >>>> >>> > >>>> >>>>> The fix looks pretty good to me. > >>>> >>>>> > >>>> >>>>> One minor suggestion is to use the final field NO_REMOTE > >>>> instead > >>>> >>>>> of null for initialization of the local variable "remote". > >>>> >>>> > >>>> >>>> I will fix that. > >>>> >>>> > >>>> >>>> > >>>> >>>>> Also just an observation that there is some room for option > >>>> >>>>> processing refactoring. > >>>> >>>> > >>>> >>>> Your suggestion handles all options in one parser method. > >>>> >>>> I concern it might be complex for option validation. > >>>> >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not > >>>> allowed.) > >>>> >>> > >>>> >>> This concern is not valid as the list allowed options allowed > >>>> for each > >>>> >>> jhsdb sub-command is controlled with the longOpts argument. > >>>> >>> > >>>> >>> jmap has: > >>>> >>> String[] longOpts = {"exe=", "core=", "pid=", > >>>> "remote=", > >>>> >>> "heap", "binaryheap", "dumpfile=", "histo", > >>>> >>> "clstats", "finalizerinfo"}; > >>>> >>> > >>>> >>> but jstack has: > >>>> >>> String[] longOpts = {"exe=", "core=", "pid=", > >>>> "remote=", > >>>> >>> "mixed", "locks"}; > >>>> >>> > >>>> >>>> IMHO refactoring should be worked on another issue. > >>>> >>> > >>>> >>> Agreed. > >>>> >>> > >>>> >>> > >>>> >>>> If you are OK in above, I will upload new webrev. > >>>> >>> > >>>> >>> Yes, I'm Okay with it. > >>>> >>> > >>>> >>> > >>>> >>> Thanks, > >>>> >>> Serguei > >>>> >>> > >>>> >>> > >>>> >>>> Thanks, > >>>> >>>> > >>>> >>>> Yasumasa > >>>> >>>> > >>>> >>>> > >>>> >>>>> All the jhsdb sub-commands do execute similar loops like > >>>> this: > >>>> >>>>> while((s = sg.next(null, longOpts)) != null) { > >>>> >>>>> . . . > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> It can be moved into a separate method instead. > >>>> >>>>> The longOpts can passed in arguments. > >>>> >>>>> > >>>> >>>>> It can be something like this: > >>>> >>>>> > >>>> >>>>> private ArrayList processOptions(final String[] > >>>> oldArgs, > >>>> >>>>> final String[] > >>>> >>>>> longOpts, > >>>> >>>>> boolean > >>>> allowEmpty) { > >>>> >>>>> SAGetopt sg = new SAGetopt(oldArgs); > >>>> >>>>> ArrayList newArgs = new ArrayList(); > >>>> >>>>> > >>>> >>>>> String pid = null; > >>>> >>>>> String exe = null; > >>>> >>>>> String core = null; > >>>> >>>>> String s = null; > >>>> >>>>> String dumpfile = null; > >>>> >>>>> String remote = NO_REMOTE; > >>>> >>>>> boolean requestHeapdump = false; > >>>> >>>>> > >>>> >>>>> while((s = sg.next(null, longOpts)) != null) { > >>>> >>>>> if (s.equals("exe")) { > >>>> >>>>> exe = sg.getOptarg(); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("core")) { > >>>> >>>>> core = sg.getOptarg(); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("pid")) { > >>>> >>>>> pid = sg.getOptarg(); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("remote")) { > >>>> >>>>> remote = sg.getOptarg(); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("mixed")) { > >>>> >>>>> newArgs.add("-m"); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("locks")) { > >>>> >>>>> newArgs.add("-l"); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("heap")) { > >>>> >>>>> newArgs.add("-heap"); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("binaryheap")) { > >>>> >>>>> requestHeapdump = true; > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("dumpfile")) { > >>>> >>>>> dumpfile = sg.getOptarg(); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("histo")) { > >>>> >>>>> newArgs.add("-histo"); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("clstats")) { > >>>> >>>>> newArgs.add("-clstats"); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("finalizerinfo")) { > >>>> >>>>> newArgs.add("-finalizerinfo"); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("flags")) { > >>>> >>>>> newArgs.add("-flags"); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("sysprops")) { > >>>> >>>>> newArgs.add("-sysprops"); > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> if (s.equals("serverid")) { > >>>> >>>>> String serverid = sg.getOptarg(); > >>>> >>>>> if (serverid != null) { > >>>> >>>>> newArgs.add(serverid); > >>>> >>>>> } > >>>> >>>>> continue; > >>>> >>>>> } > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> if (!requestHeapdump && (dumpfile != null)) { > >>>> >>>>> throw new IllegalArgumentException("Unexpected > >>>> >>>>> argument dumpfile"); > >>>> >>>>> } > >>>> >>>>> if (requestHeapdump) { > >>>> >>>>> if (dumpfile == null) { > >>>> >>>>> newArgs.add("-heap:format=b"); > >>>> >>>>> } else { > >>>> >>>>> newArgs.add("-heap:format=b,file=" + > >>>> dumpfile); > >>>> >>>>> } > >>>> >>>>> } > >>>> >>>>> buildAttachArgs(newArgs, pid, exe, core, remote, > >>>> >>>>> allowEmpty); > >>>> >>>>> > >>>> >>>>> return newArgs; > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> private static void runCLHSDB(String[] oldArgs) { > >>>> >>>>> String[] longOpts = {"exe=", "core=", "pid="}; > >>>> >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>> >>>>> longOpts, true); > >>>> >>>>> > >>>> >>>>> CLHSDB.main(newArgs.toArray(new > >>>> String[newArgs.size()])); > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> private static void runHSDB(String[] oldArgs) { > >>>> >>>>> String[] longOpts = {"exe=", "core=", "pid="}; > >>>> >>>>> ArrayList newArgs = > >>>> processOptions(oldArgs, > >>>> >>>>> longOpts, true); > >>>> >>>>> > >>>> >>>>> HSDB.main(newArgs.toArray(new > >>>> String[newArgs.size()])); > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> private static void runJSTACK(String[] oldArgs) { > >>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>> "remote=", > >>>> >>>>> "mixed", "locks"}; > >>>> >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>> >>>>> longOpts, false); > >>>> >>>>> > >>>> >>>>> JStack jstack = new JStack(false, false); > >>>> >>>>> jstack.runWithArgs(newArgs.toArray(new > >>>> >>>>> String[newArgs.size()])); > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> private static void runJMAP(String[] oldArgs) { > >>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>> "remote=", > >>>> >>>>> "heap", "binaryheap", "dumpfile=", "histo", > >>>> >>>>> "clstats", "finalizerinfo"}; > >>>> >>>>> > >>>> >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>> >>>>> longOpts, false); > >>>> >>>>> > >>>> >>>>> JMap.main(newArgs.toArray(new > >>>> String[newArgs.size()])); > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> private static void runJINFO(String[] oldArgs) { > >>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>> "remote=", > >>>> >>>>> "flags", "sysprops"}; > >>>> >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>> >>>>> longOpts, false); > >>>> >>>>> > >>>> >>>>> JInfo.main(newArgs.toArray(new > >>>> String[newArgs.size()])); > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> private static void runJSNAP(String[] oldArgs) { > >>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>> "remote=", > >>>> >>>>> "all"}; > >>>> >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>> >>>>> longOpts, false); > >>>> >>>>> JSnap.main(newArgs.toArray(new > >>>> String[newArgs.size()])); > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> private static void runDEBUGD(String[] oldArgs) { > >>>> >>>>> // By default SA agent classes prefer Windows > >>>> process > >>>> >>>>> debugger > >>>> >>>>> // to windbg debugger. SA expects special > >>>> properties to > >>>> >>>>> be set > >>>> >>>>> // to choose other debuggers. We will set those > >>>> here > >>>> before > >>>> >>>>> // attaching to SA agent. > >>>> >>>>> > >>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", > >>>> >>>>> "true"); > >>>> >>>>> > >>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>> "serverid="}; > >>>> >>>>> ArrayList newArgs = processOptions(oldArgs, > >>>> >>>>> longOpts, false); > >>>> >>>>> > >>>> >>>>> // delegate to the actual SA debug server. > >>>> >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new > >>>> >>>>> String[newArgs.size()])); > >>>> >>>>> } > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> Please, let me know what do you think. > >>>> >>>>> > >>>> >>>>> Thanks, > >>>> >>>>> Serguei > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: > >>>> >>>>>> Sorry, new webrev is here: > >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > >>>> >>>>>> > >>>> >>>>>> Yasumasa > >>>> >>>>>> > >>>> >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga >>>> >: > >>>> >>>>>>> PING: Could you review them? > >>>> >>>>>>> > >>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>> >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>> >>>>>>>>>>> > >>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>> >>>>>>>>>>> > >>>> >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if > >>>> possible. > >>>> >>>>>>> > >>>> >>>>>>> > >>>> >>>>>>> Thanks, > >>>> >>>>>>> > >>>> >>>>>>> Yasumasa > >>>> >>>>>>> > >>>> >>>>>>> > >>>> >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga >>>> >: > >>>> >>>>>>>> Hi Jc, > >>>> >>>>>>>> > >>>> >>>>>>>> Thank you for your comment! > >>>> >>>>>>>> I updated a webrev: > >>>> >>>>>>>> > >>>> >>>>>>>> > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > >>>> >>>>>>>> > >>>> >>>>>>>>> - In runTests; if DebugdUtils implemented > >>>> Closeable, you > >>>> >>>>>>>>> could just do a try-with-resources instead of the > >>>> finally > >>>> >>>>>>>>> clause... > >>>> >>>>>>>> I created DebugdUtils for convenience class for attach - > >>>> detach > >>>> >>>>>>>> mechanism of debug server. > >>>> >>>>>>>> IMHO it is prefer "detach" to "close" in this case. > >>>> >>>>>>>> > >>>> >>>>>>>> > >>>> >>>>>>>> Thanks, > >>>> >>>>>>>> > >>>> >>>>>>>> Yasumasa > >>>> >>>>>>>> > >>>> >>>>>>>> > >>>> >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe > >>>> Beyler>: > >>>> >>>>>>>> > >>>> >>>>>>>>> Hi Yasumasa, > >>>> >>>>>>>>> > >>>> >>>>>>>>> I'm not an official reviewer but I don't see an issue > >>>> with the > >>>> >>>>>>>>> CSR (except that this seems to be bringing a fork in the > >>>> tools > >>>> >>>>>>>>> with some handling remote and others not). > >>>> >>>>>>>>> > >>>> >>>>>>>>> However, this code is really repetitive and this is > >>>> not the > >>>> >>>>>>>>> place to do a big refactor probably but we could do a > >>>> few > >>>> nits > >>>> >>>>>>>>> perhaps: > >>>> >>>>>>>>> - Instead of every tool calling commonHelp with an > >>>> >>>>>>>>> additional flag you could divide into commonHelp and > >>>> >>>>>>>>> commonHelpWithRemote for the tools and they both call > >>>> the > >>>> >>>>>>>>> current commonHelp with that boolean; so that when we > >>>> are > >>>> >>>>>>>>> looking at the tool code we know what we are > >>>> getting... So > >>>> >>>>>>>>> something like: > >>>> >>>>>>>>> > >>>> >>>>>>>>> private static boolean commonHelp(String mode, boolean > >>>> >>>>>>>>> canConnectToRemote) { > >>>> >>>>>>>>> .. > >>>> >>>>>>>>> } > >>>> >>>>>>>>> > >>>> >>>>>>>>> private static boolean commonHelp(String mode) { > >>>> >>>>>>>>> return commonHelp(mode, false); > >>>> >>>>>>>>> } > >>>> >>>>>>>>> > >>>> >>>>>>>>> private static boolean commonHelpWithRemote(String > >>>> mode) { > >>>> >>>>>>>>> return commonHelp(mode, false); > >>>> >>>>>>>>> } > >>>> >>>>>>>>> > >>>> >>>>>>>>> and that way the tools that change are just going from: > >>>> >>>>>>>>> - return commonHelp("jmap"); > >>>> >>>>>>>>> + return commonHelpWithRemote("jmap"); > >>>> >>>>>>>>> > >>>> >>>>>>>>> - In the same vein, instead of passing null to the > >>>> >>>>>>>>> buildAttachArgs; you could make a variable null: > >>>> >>>>>>>>> > >>>> >>>>>>>>> - buildAttachArgs(newArgs, pid, exe, core, true); > >>>> >>>>>>>>> + String noRemote = null; > >>>> >>>>>>>>> + buildAttachArgs(newArgs, pid, exe, core, > >>>> noRemote, > >>>> >>>>>>>>> true); > >>>> >>>>>>>>> > >>>> >>>>>>>>> > >>>> >>>>>>>>> > >>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html > >>>> > >>>> > >>>> >>>>>>>>> > >>>> >>>>>>>>> Nit: you have empty lines at l64 and l73 > >>>> >>>>>>>>> > >>>> >>>>>>>>> > >>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html > >>>> > >>>> > >>>> >>>>>>>>> > >>>> >>>>>>>>> Nit : you have an empty line at l110 > >>>> >>>>>>>>> > >>>> >>>>>>>>> - In runTests; if DebugdUtils implemented > >>>> Closeable, you > >>>> >>>>>>>>> could just do a try-with-resources instead of the > >>>> finally > >>>> >>>>>>>>> clause... > >>>> >>>>>>>>> > >>>> >>>>>>>>> All of these are details, I just thought I'd mention > >>>> them :) > >>>> >>>>>>>>> Jc > >>>> >>>>>>>>> > >>>> >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa > >>>> >>>>>>>>> Suenaga >>>> > wrote: > >>>> >>>>>>>>>> PING: Could you review them? > >>>> >>>>>>>>>> > >>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>> >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>> >>>>>>>>>>> > >>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>> CSR status is provisional. So I need reviewers both > >>>> CSR and > >>>> >>>>>>>>>> webrev. > >>>> >>>>>>>>>> > >>>> >>>>>>>>>> > >>>> >>>>>>>>>> Thanks, > >>>> >>>>>>>>>> > >>>> >>>>>>>>>> Yasumasa > >>>> >>>>>>>>>> > >>>> >>>>>>>>>> > >>>> >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa > >>>> Suenaga>: > >>>> >>>>>>>>>>> Hi all, > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>>> Please review this change: > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>> >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>> >>>>>>>>>>> > >>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, > >>>> jinfo) can > >>>> >>>>>>>>>>> connect to > >>>> >>>>>>>>>>> debug server (jsadebugd). However it has not done > >>>> so since > >>>> >>>>>>>>>>> JDK 9 because > >>>> >>>>>>>>>>> jhsdb cannot accept the attach request to debug > >>>> server. > >>>> >>>>>>>>>>> So I want to introduce new option `--remote` to > >>>> connect to > >>>> >>>>>>>>>>> debug server. > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>>> I created CSR for this issue. So please review it > >>>> together. > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>>> Thanks, > >>>> >>>>>>>>>>> > >>>> >>>>>>>>>>> Yasumasa > >>>> >>>>>>>>> > >>>> >>>>>>>>> -- > >>>> >>>>>>>>> > >>>> >>>>>>>>> Thanks, > >>>> >>>>>>>>> Jc > >>>> >>>>> > >>>> >>> > >>>> > > >>>> From serguei.spitsyn at oracle.com Tue Jun 25 08:35:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 25 Jun 2019 01:35:51 -0700 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> <0f945652-4de0-5d57-66e7-874464c10903@oracle.com> <1b56d28c-f0da-3b84-d6e0-5cd2f00501ef@gmail.com> <690ab155-8b8d-9da7-5a9a-426148c0dd9f@gmail.com> Message-ID: <8097ffdc-4c2f-a214-0798-262595116a74@oracle.com> Hi Yasumasa, The fix looks good to me. Thanks, Serguei On 6/25/19 00:47, Yasumasa Suenaga wrote: > Hi, > > This enhancement has been retargeted to 14, and the CSR has been approved. > I uploaded a webrev for 14. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.03/ > > It includes the fix to rename `--remote` to `--connect` that is > suggested in CSR. > It passed tests on submit repo. > > > Thanks, > > Yasumasa > > > 2019?6?17?(?) 22:11 Yasumasa Suenaga : >> Hi David, >> >> On 2019/06/17 21:42, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 17/06/2019 6:50 pm, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> 8209790 is filed as a bug. >>> I don't agree this is a "bug" - sorry. For this to be a bug there must >>> be some specification of behaviour that the implementation is violating. >>> Is that the case? To me this is missing functionality which makes it an >>> enhancement. >> The feature for connecting to remote debug server has been provided JDK >> 8 or earlier. However it was missed since JDK 9. So I think we can >> handle it as a "bug". >> Anyway, I added jdk13-enhancement-request label to JBS. I'm waiting for >> the approval. >> >> >>>> According to [1], I think we can push the fix to jdk/jdk13. Does it >>>> correct? >>>> >>>> I'm not sure which version (13 or 14) should be set on JBS before >>>> pushing. >>> Just to clarify the process here, you don't want to set the "Fix >>> Version" to 13 or 14 in JBS before pushing. That will be set based on >>> the repo you push to. If you push to jdk/jdk it will be 14. If you push >>> to jdk/jdk13 it will be 13. Any fix pushed to jdk/jdk13 will be >>> "automatically" forward-ported to jdk/jdk and thus 14. >> Thanks! I got it. >> >> >> Yasumasa >> >> >>> David >>> ----- >>> >>>> (Of course I will push it after the CSR is approved.) >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003051.html >>>> >>>> >>>> On 2019/06/17 17:06, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 17/06/2019 8:52 am, Yasumasa Suenaga wrote: >>>>>> 2019?6?17?(?) 6:47 serguei.spitsyn at oracle.com >>>>>> >>>>> >: >>>>>> >>>>>> Forgot to tell... >>>>>> This can be pushed only after the CSR is approved. >>>>>> >>>>>> >>>>>> Sure! >>>>>> And I will push it when I get second reviewer. >>>>>> >>>>>> BTW should I push this change to jdk/jdk? or push to jdk/jdk13 >>>>>> manually? >>>>> JDK 13 has now entered RDP1 so if you want this to go into 13 it will >>>>> need special approval: >>>>> >>>>> http://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process >>>>> >>>>> Otherwise push to jdk/jdk and it will be for JDK 14. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 6/16/19 14:44, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>> > Hi Yasumasa, >>>>>> > >>>>>> > >>>>>> > On 6/16/19 07:22, Yasumasa Suenaga wrote: >>>>>> >> Hi Serguei, >>>>>> >> >>>>>> >> >>> One minor suggestion is to use the final field NO_REMOTE >>>>>> instead >>>>>> >> >>> of null for initialization of the local variable "remote". >>>>>> >> >>>>>> >> I fixed it on new webrev. Could you check again? >>>>>> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ >>>>>> > >>>>>> > >>>>>> > It looks good. >>>>>> > Thanks you for the update! >>>>>> > >>>>>> >> >>>>>> >> >> IMHO refactoring should be worked on another issue. >>>>>> >> > >>>>>> >> > Agreed. >>>>>> >> >>>>>> >> I filed it to JBS: >>>>>> >> https://bugs.openjdk.java.net/browse/JDK-8226204 >>>>>> > >>>>>> > Thank you for filing the enhancement! >>>>>> > >>>>>> > Thanks. >>>>>> > Serguei >>>>>> > >>>>>> > >>>>>> >> Thanks, >>>>>> >> >>>>>> >> Yasumasa >>>>>> >> >>>>>> >> >>>>>> >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>> >>> Hi Yasumasa, >>>>>> >>> >>>>>> >>> >>>>>> >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: >>>>>> >>>> Hi Serguei, >>>>>> >>>> >>>>>> >>>> Thank you for your comment! >>>>>> >>>> >>>>>> >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>> >>>>> Hi Yasumasa, >>>>>> >>>>> >>>>>> >>>>> I've added myself as a reviewer, so you can finalize it now. >>>>>> >>>> >>>>>> >>>> I moved CSR to Finalized, and added a comment for your >>>>>> question. >>>>>> >>> >>>>>> >>> Okay, thanks! >>>>>> >>> >>>>>> >>> >>>>>> >>>>> The fix looks pretty good to me. >>>>>> >>>>> >>>>>> >>>>> One minor suggestion is to use the final field NO_REMOTE >>>>>> instead >>>>>> >>>>> of null for initialization of the local variable "remote". >>>>>> >>>> >>>>>> >>>> I will fix that. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>> Also just an observation that there is some room for option >>>>>> >>>>> processing refactoring. >>>>>> >>>> >>>>>> >>>> Your suggestion handles all options in one parser method. >>>>>> >>>> I concern it might be complex for option validation. >>>>>> >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not >>>>>> allowed.) >>>>>> >>> >>>>>> >>> This concern is not valid as the list allowed options allowed >>>>>> for each >>>>>> >>> jhsdb sub-command is controlled with the longOpts argument. >>>>>> >>> >>>>>> >>> jmap has: >>>>>> >>> String[] longOpts = {"exe=", "core=", "pid=", >>>>>> "remote=", >>>>>> >>> "heap", "binaryheap", "dumpfile=", "histo", >>>>>> >>> "clstats", "finalizerinfo"}; >>>>>> >>> >>>>>> >>> but jstack has: >>>>>> >>> String[] longOpts = {"exe=", "core=", "pid=", >>>>>> "remote=", >>>>>> >>> "mixed", "locks"}; >>>>>> >>> >>>>>> >>>> IMHO refactoring should be worked on another issue. >>>>>> >>> >>>>>> >>> Agreed. >>>>>> >>> >>>>>> >>> >>>>>> >>>> If you are OK in above, I will upload new webrev. >>>>>> >>> >>>>>> >>> Yes, I'm Okay with it. >>>>>> >>> >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> Serguei >>>>>> >>> >>>>>> >>> >>>>>> >>>> Thanks, >>>>>> >>>> >>>>>> >>>> Yasumasa >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>> All the jhsdb sub-commands do execute similar loops like >>>>>> this: >>>>>> >>>>> while((s = sg.next(null, longOpts)) != null) { >>>>>> >>>>> . . . >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> It can be moved into a separate method instead. >>>>>> >>>>> The longOpts can passed in arguments. >>>>>> >>>>> >>>>>> >>>>> It can be something like this: >>>>>> >>>>> >>>>>> >>>>> private ArrayList processOptions(final String[] >>>>>> oldArgs, >>>>>> >>>>> final String[] >>>>>> >>>>> longOpts, >>>>>> >>>>> boolean >>>>>> allowEmpty) { >>>>>> >>>>> SAGetopt sg = new SAGetopt(oldArgs); >>>>>> >>>>> ArrayList newArgs = new ArrayList(); >>>>>> >>>>> >>>>>> >>>>> String pid = null; >>>>>> >>>>> String exe = null; >>>>>> >>>>> String core = null; >>>>>> >>>>> String s = null; >>>>>> >>>>> String dumpfile = null; >>>>>> >>>>> String remote = NO_REMOTE; >>>>>> >>>>> boolean requestHeapdump = false; >>>>>> >>>>> >>>>>> >>>>> while((s = sg.next(null, longOpts)) != null) { >>>>>> >>>>> if (s.equals("exe")) { >>>>>> >>>>> exe = sg.getOptarg(); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("core")) { >>>>>> >>>>> core = sg.getOptarg(); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("pid")) { >>>>>> >>>>> pid = sg.getOptarg(); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("remote")) { >>>>>> >>>>> remote = sg.getOptarg(); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("mixed")) { >>>>>> >>>>> newArgs.add("-m"); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("locks")) { >>>>>> >>>>> newArgs.add("-l"); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("heap")) { >>>>>> >>>>> newArgs.add("-heap"); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("binaryheap")) { >>>>>> >>>>> requestHeapdump = true; >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("dumpfile")) { >>>>>> >>>>> dumpfile = sg.getOptarg(); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("histo")) { >>>>>> >>>>> newArgs.add("-histo"); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("clstats")) { >>>>>> >>>>> newArgs.add("-clstats"); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("finalizerinfo")) { >>>>>> >>>>> newArgs.add("-finalizerinfo"); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("flags")) { >>>>>> >>>>> newArgs.add("-flags"); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("sysprops")) { >>>>>> >>>>> newArgs.add("-sysprops"); >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> if (s.equals("serverid")) { >>>>>> >>>>> String serverid = sg.getOptarg(); >>>>>> >>>>> if (serverid != null) { >>>>>> >>>>> newArgs.add(serverid); >>>>>> >>>>> } >>>>>> >>>>> continue; >>>>>> >>>>> } >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> if (!requestHeapdump && (dumpfile != null)) { >>>>>> >>>>> throw new IllegalArgumentException("Unexpected >>>>>> >>>>> argument dumpfile"); >>>>>> >>>>> } >>>>>> >>>>> if (requestHeapdump) { >>>>>> >>>>> if (dumpfile == null) { >>>>>> >>>>> newArgs.add("-heap:format=b"); >>>>>> >>>>> } else { >>>>>> >>>>> newArgs.add("-heap:format=b,file=" + >>>>>> dumpfile); >>>>>> >>>>> } >>>>>> >>>>> } >>>>>> >>>>> buildAttachArgs(newArgs, pid, exe, core, remote, >>>>>> >>>>> allowEmpty); >>>>>> >>>>> >>>>>> >>>>> return newArgs; >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> private static void runCLHSDB(String[] oldArgs) { >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid="}; >>>>>> >>>>> ArrayList newArgs = processOptions(oldArgs, >>>>>> >>>>> longOpts, true); >>>>>> >>>>> >>>>>> >>>>> CLHSDB.main(newArgs.toArray(new >>>>>> String[newArgs.size()])); >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> private static void runHSDB(String[] oldArgs) { >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid="}; >>>>>> >>>>> ArrayList newArgs = >>>>>> processOptions(oldArgs, >>>>>> >>>>> longOpts, true); >>>>>> >>>>> >>>>>> >>>>> HSDB.main(newArgs.toArray(new >>>>>> String[newArgs.size()])); >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> private static void runJSTACK(String[] oldArgs) { >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", >>>>>> "remote=", >>>>>> >>>>> "mixed", "locks"}; >>>>>> >>>>> ArrayList newArgs = processOptions(oldArgs, >>>>>> >>>>> longOpts, false); >>>>>> >>>>> >>>>>> >>>>> JStack jstack = new JStack(false, false); >>>>>> >>>>> jstack.runWithArgs(newArgs.toArray(new >>>>>> >>>>> String[newArgs.size()])); >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> private static void runJMAP(String[] oldArgs) { >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", >>>>>> "remote=", >>>>>> >>>>> "heap", "binaryheap", "dumpfile=", "histo", >>>>>> >>>>> "clstats", "finalizerinfo"}; >>>>>> >>>>> >>>>>> >>>>> ArrayList newArgs = processOptions(oldArgs, >>>>>> >>>>> longOpts, false); >>>>>> >>>>> >>>>>> >>>>> JMap.main(newArgs.toArray(new >>>>>> String[newArgs.size()])); >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> private static void runJINFO(String[] oldArgs) { >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", >>>>>> "remote=", >>>>>> >>>>> "flags", "sysprops"}; >>>>>> >>>>> ArrayList newArgs = processOptions(oldArgs, >>>>>> >>>>> longOpts, false); >>>>>> >>>>> >>>>>> >>>>> JInfo.main(newArgs.toArray(new >>>>>> String[newArgs.size()])); >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> private static void runJSNAP(String[] oldArgs) { >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", >>>>>> "remote=", >>>>>> >>>>> "all"}; >>>>>> >>>>> ArrayList newArgs = processOptions(oldArgs, >>>>>> >>>>> longOpts, false); >>>>>> >>>>> JSnap.main(newArgs.toArray(new >>>>>> String[newArgs.size()])); >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> private static void runDEBUGD(String[] oldArgs) { >>>>>> >>>>> // By default SA agent classes prefer Windows >>>>>> process >>>>>> >>>>> debugger >>>>>> >>>>> // to windbg debugger. SA expects special >>>>>> properties to >>>>>> >>>>> be set >>>>>> >>>>> // to choose other debuggers. We will set those >>>>>> here >>>>>> before >>>>>> >>>>> // attaching to SA agent. >>>>>> >>>>> >>>>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", >>>>>> >>>>> "true"); >>>>>> >>>>> >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", >>>>>> "serverid="}; >>>>>> >>>>> ArrayList newArgs = processOptions(oldArgs, >>>>>> >>>>> longOpts, false); >>>>>> >>>>> >>>>>> >>>>> // delegate to the actual SA debug server. >>>>>> >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new >>>>>> >>>>> String[newArgs.size()])); >>>>>> >>>>> } >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Please, let me know what do you think. >>>>>> >>>>> >>>>>> >>>>> Thanks, >>>>>> >>>>> Serguei >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>> Sorry, new webrev is here: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>>>> >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga>>>>> >: >>>>>> >>>>>>> PING: Could you review them? >>>>>> >>>>>>> >>>>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>> >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>> >>>>>>>>>>> >>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>> >>>>>>>>>>> >>>>>> >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP 1 if >>>>>> possible. >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> Thanks, >>>>>> >>>>>>> >>>>>> >>>>>>> Yasumasa >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga>>>>> >: >>>>>> >>>>>>>> Hi Jc, >>>>>> >>>>>>>> >>>>>> >>>>>>>> Thank you for your comment! >>>>>> >>>>>>>> I updated a webrev: >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ >>>>>> >>>>>>>> >>>>>> >>>>>>>>> - In runTests; if DebugdUtils implemented >>>>>> Closeable, you >>>>>> >>>>>>>>> could just do a try-with-resources instead of the >>>>>> finally >>>>>> >>>>>>>>> clause... >>>>>> >>>>>>>> I created DebugdUtils for convenience class for attach - >>>>>> detach >>>>>> >>>>>>>> mechanism of debug server. >>>>>> >>>>>>>> IMHO it is prefer "detach" to "close" in this case. >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> Thanks, >>>>>> >>>>>>>> >>>>>> >>>>>>>> Yasumasa >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe >>>>>> Beyler>: >>>>>> >>>>>>>> >>>>>> >>>>>>>>> Hi Yasumasa, >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> I'm not an official reviewer but I don't see an issue >>>>>> with the >>>>>> >>>>>>>>> CSR (except that this seems to be bringing a fork in the >>>>>> tools >>>>>> >>>>>>>>> with some handling remote and others not). >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> However, this code is really repetitive and this is >>>>>> not the >>>>>> >>>>>>>>> place to do a big refactor probably but we could do a >>>>>> few >>>>>> nits >>>>>> >>>>>>>>> perhaps: >>>>>> >>>>>>>>> - Instead of every tool calling commonHelp with an >>>>>> >>>>>>>>> additional flag you could divide into commonHelp and >>>>>> >>>>>>>>> commonHelpWithRemote for the tools and they both call >>>>>> the >>>>>> >>>>>>>>> current commonHelp with that boolean; so that when we >>>>>> are >>>>>> >>>>>>>>> looking at the tool code we know what we are >>>>>> getting... So >>>>>> >>>>>>>>> something like: >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> private static boolean commonHelp(String mode, boolean >>>>>> >>>>>>>>> canConnectToRemote) { >>>>>> >>>>>>>>> .. >>>>>> >>>>>>>>> } >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> private static boolean commonHelp(String mode) { >>>>>> >>>>>>>>> return commonHelp(mode, false); >>>>>> >>>>>>>>> } >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> private static boolean commonHelpWithRemote(String >>>>>> mode) { >>>>>> >>>>>>>>> return commonHelp(mode, false); >>>>>> >>>>>>>>> } >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> and that way the tools that change are just going from: >>>>>> >>>>>>>>> - return commonHelp("jmap"); >>>>>> >>>>>>>>> + return commonHelpWithRemote("jmap"); >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> - In the same vein, instead of passing null to the >>>>>> >>>>>>>>> buildAttachArgs; you could make a variable null: >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> - buildAttachArgs(newArgs, pid, exe, core, true); >>>>>> >>>>>>>>> + String noRemote = null; >>>>>> >>>>>>>>> + buildAttachArgs(newArgs, pid, exe, core, >>>>>> noRemote, >>>>>> >>>>>>>>> true); >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html >>>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> Nit: you have empty lines at l64 and l73 >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> -http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html >>>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> Nit : you have an empty line at l110 >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> - In runTests; if DebugdUtils implemented >>>>>> Closeable, you >>>>>> >>>>>>>>> could just do a try-with-resources instead of the >>>>>> finally >>>>>> >>>>>>>>> clause... >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> All of these are details, I just thought I'd mention >>>>>> them :) >>>>>> >>>>>>>>> Jc >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa >>>>>> >>>>>>>>> Suenaga>>>>> > wrote: >>>>>> >>>>>>>>>> PING: Could you review them? >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>> >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>> >>>>>>>>>>> >>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>> CSR status is provisional. So I need reviewers both >>>>>> CSR and >>>>>> >>>>>>>>>> webrev. >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> Thanks, >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> Yasumasa >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa >>>>>> Suenaga>: >>>>>> >>>>>>>>>>> Hi all, >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> Please review this change: >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8209790 >>>>>> >>>>>>>>>>> CSR:https://bugs.openjdk.java.net/browse/JDK-8224979 >>>>>> >>>>>>>>>>> >>>>>> webrev:http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, >>>>>> jinfo) can >>>>>> >>>>>>>>>>> connect to >>>>>> >>>>>>>>>>> debug server (jsadebugd). However it has not done >>>>>> so since >>>>>> >>>>>>>>>>> JDK 9 because >>>>>> >>>>>>>>>>> jhsdb cannot accept the attach request to debug >>>>>> server. >>>>>> >>>>>>>>>>> So I want to introduce new option `--remote` to >>>>>> connect to >>>>>> >>>>>>>>>>> debug server. >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> I created CSR for this issue. So please review it >>>>>> together. >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> Thanks, >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> Yasumasa >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> -- >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> Thanks, >>>>>> >>>>>>>>> Jc >>>>>> >>>>> >>>>>> >>> >>>>>> > >>>>>> From serguei.spitsyn at oracle.com Tue Jun 25 18:36:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 25 Jun 2019 11:36:58 -0700 Subject: (13) RFR: 8225679: reference to http://java.sun.com/products/JavaManagement/download.html In-Reply-To: <10b44901-871d-f2fa-2fb9-b0a592acb3a8@oracle.com> References: <10b44901-871d-f2fa-2fb9-b0a592acb3a8@oracle.com> Message-ID: <32707dd4-d7be-28bc-2d1f-c38adb15121f@oracle.com> Hi Alex, It looks good to me. Thank you for taking care about it! Thanks, Serguei On 6/24/19 4:28 PM, Alex Menkov wrote: > Hi all, > > please review small doc fix for jdk13 > jira: https://bugs.openjdk.java.net/browse/JDK-8225679 > webrev: http://cr.openjdk.java.net/~amenkov/docs/jmx_optional/webrev/ > > https://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-java-plat-419418.html > > is the only page I found which has a link to download JMX ref. > implementation (and it includes jmx optional components) > > --alex From yasuenag at gmail.com Tue Jun 25 23:35:57 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 26 Jun 2019 08:35:57 +0900 Subject: PING: RFR: 8209790: SA tools not providing option to connect to debug server In-Reply-To: <8097ffdc-4c2f-a214-0798-262595116a74@oracle.com> References: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> <352276fb-3c18-6b34-b7ef-0698780cf254@gmail.com> <806acd67-6cd4-a629-30f3-45da59c346fd@oracle.com> <0f945652-4de0-5d57-66e7-874464c10903@oracle.com> <1b56d28c-f0da-3b84-d6e0-5cd2f00501ef@gmail.com> <690ab155-8b8d-9da7-5a9a-426148c0dd9f@gmail.com> <8097ffdc-4c2f-a214-0798-262595116a74@oracle.com> Message-ID: Thanks, Serguei! Yasumasa 2019?6?25?(?) 17:35 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > The fix looks good to me. > > Thanks, > Serguei > > > On 6/25/19 00:47, Yasumasa Suenaga wrote: > > Hi, > > > > This enhancement has been retargeted to 14, and the CSR has been > approved. > > I uploaded a webrev for 14. Could you review it? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.03/ > > > > It includes the fix to rename `--remote` to `--connect` that is > > suggested in CSR. > > It passed tests on submit repo. > > > > > > Thanks, > > > > Yasumasa > > > > > > 2019?6?17?(?) 22:11 Yasumasa Suenaga : > >> Hi David, > >> > >> On 2019/06/17 21:42, David Holmes wrote: > >>> Hi Yasumasa, > >>> > >>> On 17/06/2019 6:50 pm, Yasumasa Suenaga wrote: > >>>> Hi David, > >>>> > >>>> 8209790 is filed as a bug. > >>> I don't agree this is a "bug" - sorry. For this to be a bug there must > >>> be some specification of behaviour that the implementation is > violating. > >>> Is that the case? To me this is missing functionality which makes it an > >>> enhancement. > >> The feature for connecting to remote debug server has been provided JDK > >> 8 or earlier. However it was missed since JDK 9. So I think we can > >> handle it as a "bug". > >> Anyway, I added jdk13-enhancement-request label to JBS. I'm waiting for > >> the approval. > >> > >> > >>>> According to [1], I think we can push the fix to jdk/jdk13. Does it > >>>> correct? > >>>> > >>>> I'm not sure which version (13 or 14) should be set on JBS before > >>>> pushing. > >>> Just to clarify the process here, you don't want to set the "Fix > >>> Version" to 13 or 14 in JBS before pushing. That will be set based on > >>> the repo you push to. If you push to jdk/jdk it will be 14. If you push > >>> to jdk/jdk13 it will be 13. Any fix pushed to jdk/jdk13 will be > >>> "automatically" forward-ported to jdk/jdk and thus 14. > >> Thanks! I got it. > >> > >> > >> Yasumasa > >> > >> > >>> David > >>> ----- > >>> > >>>> (Of course I will push it after the CSR is approved.) > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>> [1] > http://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003051.html > >>>> > >>>> > >>>> On 2019/06/17 17:06, David Holmes wrote: > >>>>> Hi Yasumasa, > >>>>> > >>>>> On 17/06/2019 8:52 am, Yasumasa Suenaga wrote: > >>>>>> 2019?6?17?(?) 6:47 serguei.spitsyn at oracle.com > >>>>>> >>>>>> >: > >>>>>> > >>>>>> Forgot to tell... > >>>>>> This can be pushed only after the CSR is approved. > >>>>>> > >>>>>> > >>>>>> Sure! > >>>>>> And I will push it when I get second reviewer. > >>>>>> > >>>>>> BTW should I push this change to jdk/jdk? or push to jdk/jdk13 > >>>>>> manually? > >>>>> JDK 13 has now entered RDP1 so if you want this to go into 13 it will > >>>>> need special approval: > >>>>> > >>>>> http://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process > >>>>> > >>>>> Otherwise push to jdk/jdk and it will be for JDK 14. > >>>>> > >>>>> Cheers, > >>>>> David > >>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Yasumasa > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 6/16/19 14:44, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> > Hi Yasumasa, > >>>>>> > > >>>>>> > > >>>>>> > On 6/16/19 07:22, Yasumasa Suenaga wrote: > >>>>>> >> Hi Serguei, > >>>>>> >> > >>>>>> >> >>> One minor suggestion is to use the final field > NO_REMOTE > >>>>>> instead > >>>>>> >> >>> of null for initialization of the local variable > "remote". > >>>>>> >> > >>>>>> >> I fixed it on new webrev. Could you check again? > >>>>>> >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.02/ > >>>>>> > > >>>>>> > > >>>>>> > It looks good. > >>>>>> > Thanks you for the update! > >>>>>> > > >>>>>> >> > >>>>>> >> >> IMHO refactoring should be worked on another issue. > >>>>>> >> > > >>>>>> >> > Agreed. > >>>>>> >> > >>>>>> >> I filed it to JBS: > >>>>>> >> https://bugs.openjdk.java.net/browse/JDK-8226204 > >>>>>> > > >>>>>> > Thank you for filing the enhancement! > >>>>>> > > >>>>>> > Thanks. > >>>>>> > Serguei > >>>>>> > > >>>>>> > > >>>>>> >> Thanks, > >>>>>> >> > >>>>>> >> Yasumasa > >>>>>> >> > >>>>>> >> > >>>>>> >> On 2019/06/15 15:10, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> >>> Hi Yasumasa, > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> On 6/14/19 21:11, Yasumasa Suenaga wrote: > >>>>>> >>>> Hi Serguei, > >>>>>> >>>> > >>>>>> >>>> Thank you for your comment! > >>>>>> >>>> > >>>>>> >>>> On 2019/06/15 8:00, serguei.spitsyn at oracle.com > >>>>>> wrote: > >>>>>> >>>>> Hi Yasumasa, > >>>>>> >>>>> > >>>>>> >>>>> I've added myself as a reviewer, so you can finalize it > now. > >>>>>> >>>> > >>>>>> >>>> I moved CSR to Finalized, and added a comment for your > >>>>>> question. > >>>>>> >>> > >>>>>> >>> Okay, thanks! > >>>>>> >>> > >>>>>> >>> > >>>>>> >>>>> The fix looks pretty good to me. > >>>>>> >>>>> > >>>>>> >>>>> One minor suggestion is to use the final field NO_REMOTE > >>>>>> instead > >>>>>> >>>>> of null for initialization of the local variable > "remote". > >>>>>> >>>> > >>>>>> >>>> I will fix that. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>> Also just an observation that there is some room for > option > >>>>>> >>>>> processing refactoring. > >>>>>> >>>> > >>>>>> >>>> Your suggestion handles all options in one parser method. > >>>>>> >>>> I concern it might be complex for option validation. > >>>>>> >>>> (e.g. `jmap -heap` is allowed, but `jstack -heap` is not > >>>>>> allowed.) > >>>>>> >>> > >>>>>> >>> This concern is not valid as the list allowed options > allowed > >>>>>> for each > >>>>>> >>> jhsdb sub-command is controlled with the longOpts > argument. > >>>>>> >>> > >>>>>> >>> jmap has: > >>>>>> >>> String[] longOpts = {"exe=", "core=", "pid=", > >>>>>> "remote=", > >>>>>> >>> "heap", "binaryheap", "dumpfile=", > "histo", > >>>>>> >>> "clstats", "finalizerinfo"}; > >>>>>> >>> > >>>>>> >>> but jstack has: > >>>>>> >>> String[] longOpts = {"exe=", "core=", "pid=", > >>>>>> "remote=", > >>>>>> >>> "mixed", "locks"}; > >>>>>> >>> > >>>>>> >>>> IMHO refactoring should be worked on another issue. > >>>>>> >>> > >>>>>> >>> Agreed. > >>>>>> >>> > >>>>>> >>> > >>>>>> >>>> If you are OK in above, I will upload new webrev. > >>>>>> >>> > >>>>>> >>> Yes, I'm Okay with it. > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> Thanks, > >>>>>> >>> Serguei > >>>>>> >>> > >>>>>> >>> > >>>>>> >>>> Thanks, > >>>>>> >>>> > >>>>>> >>>> Yasumasa > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>> All the jhsdb sub-commands do execute similar loops like > >>>>>> this: > >>>>>> >>>>> while((s = sg.next(null, longOpts)) != null) { > >>>>>> >>>>> . . . > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> It can be moved into a separate method instead. > >>>>>> >>>>> The longOpts can passed in arguments. > >>>>>> >>>>> > >>>>>> >>>>> It can be something like this: > >>>>>> >>>>> > >>>>>> >>>>> private ArrayList processOptions(final > String[] > >>>>>> oldArgs, > >>>>>> >>>>> final > String[] > >>>>>> >>>>> longOpts, > >>>>>> >>>>> boolean > >>>>>> allowEmpty) { > >>>>>> >>>>> SAGetopt sg = new SAGetopt(oldArgs); > >>>>>> >>>>> ArrayList newArgs = new ArrayList(); > >>>>>> >>>>> > >>>>>> >>>>> String pid = null; > >>>>>> >>>>> String exe = null; > >>>>>> >>>>> String core = null; > >>>>>> >>>>> String s = null; > >>>>>> >>>>> String dumpfile = null; > >>>>>> >>>>> String remote = NO_REMOTE; > >>>>>> >>>>> boolean requestHeapdump = false; > >>>>>> >>>>> > >>>>>> >>>>> while((s = sg.next(null, longOpts)) != null) { > >>>>>> >>>>> if (s.equals("exe")) { > >>>>>> >>>>> exe = sg.getOptarg(); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("core")) { > >>>>>> >>>>> core = sg.getOptarg(); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("pid")) { > >>>>>> >>>>> pid = sg.getOptarg(); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("remote")) { > >>>>>> >>>>> remote = sg.getOptarg(); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("mixed")) { > >>>>>> >>>>> newArgs.add("-m"); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("locks")) { > >>>>>> >>>>> newArgs.add("-l"); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("heap")) { > >>>>>> >>>>> newArgs.add("-heap"); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("binaryheap")) { > >>>>>> >>>>> requestHeapdump = true; > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("dumpfile")) { > >>>>>> >>>>> dumpfile = sg.getOptarg(); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("histo")) { > >>>>>> >>>>> newArgs.add("-histo"); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("clstats")) { > >>>>>> >>>>> newArgs.add("-clstats"); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("finalizerinfo")) { > >>>>>> >>>>> newArgs.add("-finalizerinfo"); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("flags")) { > >>>>>> >>>>> newArgs.add("-flags"); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("sysprops")) { > >>>>>> >>>>> newArgs.add("-sysprops"); > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> if (s.equals("serverid")) { > >>>>>> >>>>> String serverid = sg.getOptarg(); > >>>>>> >>>>> if (serverid != null) { > >>>>>> >>>>> newArgs.add(serverid); > >>>>>> >>>>> } > >>>>>> >>>>> continue; > >>>>>> >>>>> } > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> if (!requestHeapdump && (dumpfile != null)) { > >>>>>> >>>>> throw new > IllegalArgumentException("Unexpected > >>>>>> >>>>> argument dumpfile"); > >>>>>> >>>>> } > >>>>>> >>>>> if (requestHeapdump) { > >>>>>> >>>>> if (dumpfile == null) { > >>>>>> >>>>> newArgs.add("-heap:format=b"); > >>>>>> >>>>> } else { > >>>>>> >>>>> newArgs.add("-heap:format=b,file=" + > >>>>>> dumpfile); > >>>>>> >>>>> } > >>>>>> >>>>> } > >>>>>> >>>>> buildAttachArgs(newArgs, pid, exe, core, > remote, > >>>>>> >>>>> allowEmpty); > >>>>>> >>>>> > >>>>>> >>>>> return newArgs; > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> private static void runCLHSDB(String[] oldArgs) { > >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid="}; > >>>>>> >>>>> ArrayList newArgs = > processOptions(oldArgs, > >>>>>> >>>>> longOpts, true); > >>>>>> >>>>> > >>>>>> >>>>> CLHSDB.main(newArgs.toArray(new > >>>>>> String[newArgs.size()])); > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> private static void runHSDB(String[] oldArgs) { > >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid="}; > >>>>>> >>>>> ArrayList newArgs = > >>>>>> processOptions(oldArgs, > >>>>>> >>>>> longOpts, true); > >>>>>> >>>>> > >>>>>> >>>>> HSDB.main(newArgs.toArray(new > >>>>>> String[newArgs.size()])); > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> private static void runJSTACK(String[] oldArgs) { > >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>>>> "remote=", > >>>>>> >>>>> "mixed", "locks"}; > >>>>>> >>>>> ArrayList newArgs = > processOptions(oldArgs, > >>>>>> >>>>> longOpts, false); > >>>>>> >>>>> > >>>>>> >>>>> JStack jstack = new JStack(false, false); > >>>>>> >>>>> jstack.runWithArgs(newArgs.toArray(new > >>>>>> >>>>> String[newArgs.size()])); > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> private static void runJMAP(String[] oldArgs) { > >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>>>> "remote=", > >>>>>> >>>>> "heap", "binaryheap", "dumpfile=", > "histo", > >>>>>> >>>>> "clstats", "finalizerinfo"}; > >>>>>> >>>>> > >>>>>> >>>>> ArrayList newArgs = > processOptions(oldArgs, > >>>>>> >>>>> longOpts, false); > >>>>>> >>>>> > >>>>>> >>>>> JMap.main(newArgs.toArray(new > >>>>>> String[newArgs.size()])); > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> private static void runJINFO(String[] oldArgs) { > >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>>>> "remote=", > >>>>>> >>>>> "flags", "sysprops"}; > >>>>>> >>>>> ArrayList newArgs = > processOptions(oldArgs, > >>>>>> >>>>> longOpts, false); > >>>>>> >>>>> > >>>>>> >>>>> JInfo.main(newArgs.toArray(new > >>>>>> String[newArgs.size()])); > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> private static void runJSNAP(String[] oldArgs) { > >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>>>> "remote=", > >>>>>> >>>>> "all"}; > >>>>>> >>>>> ArrayList newArgs = > processOptions(oldArgs, > >>>>>> >>>>> longOpts, false); > >>>>>> >>>>> JSnap.main(newArgs.toArray(new > >>>>>> String[newArgs.size()])); > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> private static void runDEBUGD(String[] oldArgs) { > >>>>>> >>>>> // By default SA agent classes prefer Windows > >>>>>> process > >>>>>> >>>>> debugger > >>>>>> >>>>> // to windbg debugger. SA expects special > >>>>>> properties to > >>>>>> >>>>> be set > >>>>>> >>>>> // to choose other debuggers. We will set those > >>>>>> here > >>>>>> before > >>>>>> >>>>> // attaching to SA agent. > >>>>>> >>>>> > >>>>>> System.setProperty("sun.jvm.hotspot.debugger.useWindbgDebugger", > >>>>>> >>>>> "true"); > >>>>>> >>>>> > >>>>>> >>>>> String[] longOpts = {"exe=", "core=", "pid=", > >>>>>> "serverid="}; > >>>>>> >>>>> ArrayList newArgs = > processOptions(oldArgs, > >>>>>> >>>>> longOpts, false); > >>>>>> >>>>> > >>>>>> >>>>> // delegate to the actual SA debug server. > >>>>>> >>>>> sun.jvm.hotspot.DebugServer.main(newArgs.toArray(new > >>>>>> >>>>> String[newArgs.size()])); > >>>>>> >>>>> } > >>>>>> >>>>> > >>>>>> >>>>> > >>>>>> >>>>> Please, let me know what do you think. > >>>>>> >>>>> > >>>>>> >>>>> Thanks, > >>>>>> >>>>> Serguei > >>>>>> >>>>> > >>>>>> >>>>> > >>>>>> >>>>> On 6/9/19 7:29 PM, Yasumasa Suenaga wrote: > >>>>>> >>>>>> Sorry, new webrev is here: > >>>>>> >>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > >>>>>> >>>>>> > >>>>>> >>>>>> Yasumasa > >>>>>> >>>>>> > >>>>>> >>>>>> 2019?6?10?(?) 11:27 Yasumasa Suenaga< > yasuenag at gmail.com > >>>>>> >: > >>>>>> >>>>>>> PING: Could you review them? > >>>>>> >>>>>>> > >>>>>> >>>>>>>>>>> JBS: > https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>> >>>>>>>>>>> CSR: > https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>> >>>>>>>>>>> > >>>>>> webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>> It is P3 bug, but I want to fix it before JDK 13 RDP > 1 if > >>>>>> possible. > >>>>>> >>>>>>> > >>>>>> >>>>>>> > >>>>>> >>>>>>> Thanks, > >>>>>> >>>>>>> > >>>>>> >>>>>>> Yasumasa > >>>>>> >>>>>>> > >>>>>> >>>>>>> > >>>>>> >>>>>>> 2019?6?5?(?) 14:06 Yasumasa Suenaga< > yasuenag at gmail.com > >>>>>> >: > >>>>>> >>>>>>>> Hi Jc, > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> Thank you for your comment! > >>>>>> >>>>>>>> I updated a webrev: > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.01/ > >>>>>> >>>>>>>> > >>>>>> >>>>>>>>> - In runTests; if DebugdUtils implemented > >>>>>> Closeable, you > >>>>>> >>>>>>>>> could just do a try-with-resources instead of the > >>>>>> finally > >>>>>> >>>>>>>>> clause... > >>>>>> >>>>>>>> I created DebugdUtils for convenience class for > attach - > >>>>>> detach > >>>>>> >>>>>>>> mechanism of debug server. > >>>>>> >>>>>>>> IMHO it is prefer "detach" to "close" in this case. > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> Thanks, > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> Yasumasa > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> 2019?6?5?(?) 11:34 Jean Christophe > >>>>>> Beyler>: > >>>>>> >>>>>>>> > >>>>>> >>>>>>>>> Hi Yasumasa, > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> I'm not an official reviewer but I don't see an > issue > >>>>>> with the > >>>>>> >>>>>>>>> CSR (except that this seems to be bringing a fork > in the > >>>>>> tools > >>>>>> >>>>>>>>> with some handling remote and others not). > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> However, this code is really repetitive and this is > >>>>>> not the > >>>>>> >>>>>>>>> place to do a big refactor probably but we could do > a > >>>>>> few > >>>>>> nits > >>>>>> >>>>>>>>> perhaps: > >>>>>> >>>>>>>>> - Instead of every tool calling commonHelp with > an > >>>>>> >>>>>>>>> additional flag you could divide into commonHelp and > >>>>>> >>>>>>>>> commonHelpWithRemote for the tools and they both > call > >>>>>> the > >>>>>> >>>>>>>>> current commonHelp with that boolean; so that when > we > >>>>>> are > >>>>>> >>>>>>>>> looking at the tool code we know what we are > >>>>>> getting... So > >>>>>> >>>>>>>>> something like: > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> private static boolean commonHelp(String mode, > boolean > >>>>>> >>>>>>>>> canConnectToRemote) { > >>>>>> >>>>>>>>> .. > >>>>>> >>>>>>>>> } > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> private static boolean commonHelp(String mode) { > >>>>>> >>>>>>>>> return commonHelp(mode, false); > >>>>>> >>>>>>>>> } > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> private static boolean commonHelpWithRemote(String > >>>>>> mode) { > >>>>>> >>>>>>>>> return commonHelp(mode, false); > >>>>>> >>>>>>>>> } > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> and that way the tools that change are just going > from: > >>>>>> >>>>>>>>> - return commonHelp("jmap"); > >>>>>> >>>>>>>>> + return commonHelpWithRemote("jmap"); > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> - In the same vein, instead of passing null to the > >>>>>> >>>>>>>>> buildAttachArgs; you could make a variable null: > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> - buildAttachArgs(newArgs, pid, exe, core, > true); > >>>>>> >>>>>>>>> + String noRemote = null; > >>>>>> >>>>>>>>> + buildAttachArgs(newArgs, pid, exe, core, > >>>>>> noRemote, > >>>>>> >>>>>>>>> true); > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> > >>>>>> - > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java.html > >>>>>> > >>>>>> > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> Nit: you have empty lines at l64 and l73 > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> > >>>>>> - > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java.html > >>>>>> > >>>>>> > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> Nit : you have an empty line at l110 > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> - In runTests; if DebugdUtils implemented > >>>>>> Closeable, you > >>>>>> >>>>>>>>> could just do a try-with-resources instead of the > >>>>>> finally > >>>>>> >>>>>>>>> clause... > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> All of these are details, I just thought I'd mention > >>>>>> them :) > >>>>>> >>>>>>>>> Jc > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> On Tue, Jun 4, 2019 at 6:44 PM Yasumasa > >>>>>> >>>>>>>>> Suenaga >>>>>> > wrote: > >>>>>> >>>>>>>>>> PING: Could you review them? > >>>>>> >>>>>>>>>> > >>>>>> >>>>>>>>>>> JBS: > https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>> >>>>>>>>>>> CSR: > https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>> >>>>>>>>>>> > >>>>>> webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>> CSR status is provisional. So I need reviewers both > >>>>>> CSR and > >>>>>> >>>>>>>>>> webrev. > >>>>>> >>>>>>>>>> > >>>>>> >>>>>>>>>> > >>>>>> >>>>>>>>>> Thanks, > >>>>>> >>>>>>>>>> > >>>>>> >>>>>>>>>> Yasumasa > >>>>>> >>>>>>>>>> > >>>>>> >>>>>>>>>> > >>>>>> >>>>>>>>>> 2019?5?29?(?) 22:37 Yasumasa > >>>>>> Suenaga>: > >>>>>> >>>>>>>>>>> Hi all, > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>>> Please review this change: > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>>> JBS: > https://bugs.openjdk.java.net/browse/JDK-8209790 > >>>>>> >>>>>>>>>>> CSR: > https://bugs.openjdk.java.net/browse/JDK-8224979 > >>>>>> >>>>>>>>>>> > >>>>>> webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>>> In JDK 8 or earlier, some tools (jstack, jmap, > >>>>>> jinfo) can > >>>>>> >>>>>>>>>>> connect to > >>>>>> >>>>>>>>>>> debug server (jsadebugd). However it has not done > >>>>>> so since > >>>>>> >>>>>>>>>>> JDK 9 because > >>>>>> >>>>>>>>>>> jhsdb cannot accept the attach request to debug > >>>>>> server. > >>>>>> >>>>>>>>>>> So I want to introduce new option `--remote` to > >>>>>> connect to > >>>>>> >>>>>>>>>>> debug server. > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>>> I created CSR for this issue. So please review it > >>>>>> together. > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>>> Thanks, > >>>>>> >>>>>>>>>>> > >>>>>> >>>>>>>>>>> Yasumasa > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> -- > >>>>>> >>>>>>>>> > >>>>>> >>>>>>>>> Thanks, > >>>>>> >>>>>>>>> Jc > >>>>>> >>>>> > >>>>>> >>> > >>>>>> > > >>>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.schmelter at sap.com Wed Jun 26 08:52:20 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Wed, 26 Jun 2019 08:52:20 +0000 Subject: RFR (S) 8226608: Hide the onjcmd option from the help output Message-ID: This change hides the onjcmd option of the JDWP agent and ensures that the corresponding VM.start_java_debugging jcmd is not listed via the help command. Both are still working though. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8226608/webrev.0/ bugreport: https://bugs.openjdk.java.net/browse/JDK-8226608 Best regards, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 26 09:26:27 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Jun 2019 02:26:27 -0700 Subject: RFR (S) 8226608: Hide the onjcmd option from the help output In-Reply-To: References: Message-ID: <10dae5de-148b-3eea-768b-ab92ac6e959d@oracle.com> An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jun 26 09:32:54 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 09:32:54 +0000 Subject: RFR (S) 8226608: Hide the onjcmd option from the help output In-Reply-To: References: Message-ID: Hi Ralf, thanks for doing this, it looks good. The copyright year in debugInit.c needs to be adjusted still and the change needs to go to the jdk13 repository. I can assist you when you're going to push this. Best regards Christoph From: serviceability-dev On Behalf Of Schmelter, Ralf Sent: Mittwoch, 26. Juni 2019 10:52 To: OpenJDK Serviceability Subject: [CAUTION] RFR (S) 8226608: Hide the onjcmd option from the help output This change hides the onjcmd option of the JDWP agent and ensures that the corresponding VM.start_java_debugging jcmd is not listed via the help command. Both are still working though. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8226608/webrev.0/ bugreport: https://bugs.openjdk.java.net/browse/JDK-8226608 Best regards, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed Jun 26 14:34:49 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 26 Jun 2019 23:34:49 +0900 Subject: A Bug about the JVM Attach mechanism In-Reply-To: References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5c156c6b-bc47-97d5-2c61-5b4f44e098c0@oracle.com> Message-ID: <0f9097aa-c489-353a-2805-af9909a746d2@gmail.com> Hi, >> I'm not clear how this addresses the issue with deleting the file? The >> file still has to exist IIUC for the mechanism to work. >> >> This seems more suited to fixing the "multiple attach threads" problem. How about this change? http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal.2/ I think it can fix both JDK-8225690 and JDK-8225193. This webrev implements for Linux only. If we work further based on this, we need to implement AttachListener::check_socket_file() for each OS's implementation. Thanks, Yasumasa On 2019/06/21 23:16, Yasumasa Suenaga wrote: > On 2019/06/21 22:51, David Holmes wrote: >> Hi Yasumasa, >> >> On 21/06/2019 5:12 am, Yasumasa Suenaga wrote: >>> Hi, >>> >>> Can we fix this issue like this webrev? >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/ >> >> I'm not clear how this addresses the issue with deleting the file? The >> file still has to exist IIUC for the mechanism to work. >> >> This seems more suited to fixing the "multiple attach threads" problem. > > Yes, my proposal focuses to "multiple attach threads". > I shared my patch because it might help the work for this issue. > > This patch would guard multithread-issue in Attach Listener. > So unix domain socket file will create just once. > > > Yasumasa > > >> David >> >>> I could reproduce this issue with ConcAttachTest.java in it >>> on my laptop. >>> (Fedora 30 x64 on Hyper-V guest: Core i3-8145U x 2vcpu) >>> >>> If we need to fix based on current implementation, I think >>> we need to use atomic operation. >>> But if we can refactor around here, we might be able to another >>> approach - e.g. using monitors/mutexes >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/06/21 5:49, David Holmes wrote: >>>> Sorry it took me a while to understand the specifics of the problem. :) >>>> >>>> David >>>> >>>> On 20/06/2019 3:37 am, nijiaben wrote: >>>>> Yes Alan, I mean this >>>>> ------------------?Original?------------------ >>>>> *From: *?"Alan Bateman"; >>>>> *Date: *?Thu, Jun 20, 2019 02:54 PM >>>>> *To: *?"nijiaben"; "David >>>>> Holmes"; >>>>> "serviceability-dev"; >>>>> "jdk8u-dev"; >>>>> "hotspot-runtime-dev"; >>>>> *Subject: *?Re: A Bug about the JVM Attach mechanism >>>>> On 20/06/2019 05:10, nijiaben wrote: >>>>> ? > : >>>>> ? > I know this mechanism, can we provide means of recovery to avoid >>>>> unavailability caused by accidental deletion? >>>>> ? > >>>>> Are you concerned about tmpreaper or cron jobs that periodically >>>>> cleanup >>>>> /tmp? There may indeed be an issue for applications that run for weeks >>>>> or months. If someone is using jmap, jcmd or other tools using the >>>>> attach API then it will trigger the attach listener to start. When >>>>> they >>>>> come back in a few weeks then the .java_pid file may have been >>>>> removed so they cannot attach. Is this what what you are pointing out? >>>>> >>>>> -Alan From coleen.phillimore at oracle.com Wed Jun 26 15:02:51 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 11:02:51 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary Message-ID: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> Summary: Remove jvmtiExport::gc_epilogue after full GCs See bug for more information. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8225437 Tested with hs-tier1-3. Thanks, Coleen From david.holmes at oracle.com Wed Jun 26 15:44:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Jun 2019 11:44:42 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> Message-ID: <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Hi Coleen, That seems okay so far, but there seem to be changes missing from ./share/prims/jvmtiImpl.hpp Thanks, David On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: > Summary: Remove jvmtiExport::gc_epilogue after full GCs > > See bug for more information. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8225437 > > Tested with hs-tier1-3. > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jun 26 17:47:49 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 13:47:49 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Message-ID: On 6/26/19 11:44 AM, David Holmes wrote: > Hi Coleen, > > That seems okay so far, but there seem to be changes missing from > > ./share/prims/jvmtiImpl.hpp Good find.? Also a missing one from jvmtiExport.hpp. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev thanks! Coleen > > Thanks, > David > > On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >> Summary: Remove jvmtiExport::gc_epilogue after full GCs >> >> See bug for more information. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >> >> Tested with hs-tier1-3. >> >> Thanks, >> Coleen From serguei.spitsyn at oracle.com Wed Jun 26 18:03:57 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Jun 2019 11:03:57 -0700 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Message-ID: Hi Coleen, It looks good. Thanks, Serguei On 6/26/19 10:47, coleen.phillimore at oracle.com wrote: > > > On 6/26/19 11:44 AM, David Holmes wrote: >> Hi Coleen, >> >> That seems okay so far, but there seem to be changes missing from >> >> ./share/prims/jvmtiImpl.hpp > > Good find.? Also a missing one from jvmtiExport.hpp. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev > > thanks! > Coleen >> >> Thanks, >> David >> >> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>> >>> See bug for more information. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>> >>> Tested with hs-tier1-3. >>> >>> Thanks, >>> Coleen > From david.holmes at oracle.com Wed Jun 26 18:14:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Jun 2019 14:14:13 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Message-ID: <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> Hi Coleen, v2 looks complete. Thanks, David On 26/06/2019 1:47 pm, coleen.phillimore at oracle.com wrote: > > > On 6/26/19 11:44 AM, David Holmes wrote: >> Hi Coleen, >> >> That seems okay so far, but there seem to be changes missing from >> >> ./share/prims/jvmtiImpl.hpp > > Good find.? Also a missing one from jvmtiExport.hpp. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev > > thanks! > Coleen >> >> Thanks, >> David >> >> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>> >>> See bug for more information. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>> >>> Tested with hs-tier1-3. >>> >>> Thanks, >>> Coleen > From serguei.spitsyn at oracle.com Wed Jun 26 18:40:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Jun 2019 11:40:51 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <0f9097aa-c489-353a-2805-af9909a746d2@gmail.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5c156c6b-bc47-97d5-2c61-5b4f44e098c0@oracle.com> <0f9097aa-c489-353a-2805-af9909a746d2@gmail.com> Message-ID: <16bd3c94-4891-b145-b9d6-1a96b7cc0318@oracle.com> An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Jun 26 18:41:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 14:41:21 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Message-ID: <89cf6834-dccd-a16c-096b-95a64c3ef155@oracle.com> Thanks Serguei! Coleen On 6/26/19 2:03 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > It looks good. > > Thanks, > Serguei > > > On 6/26/19 10:47, coleen.phillimore at oracle.com wrote: >> >> >> On 6/26/19 11:44 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> That seems okay so far, but there seem to be changes missing from >>> >>> ./share/prims/jvmtiImpl.hpp >> >> Good find.? Also a missing one from jvmtiExport.hpp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev >> >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>>> >>>> See bug for more information. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>>> >>>> Tested with hs-tier1-3. >>>> >>>> Thanks, >>>> Coleen >> > From coleen.phillimore at oracle.com Wed Jun 26 18:41:46 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 14:41:46 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> Message-ID: <646a612a-9ef3-3265-4675-bb5f33596153@oracle.com> Thanks David! Coleen On 6/26/19 2:14 PM, David Holmes wrote: > Hi Coleen, > > v2 looks complete. > > Thanks, > David > > On 26/06/2019 1:47 pm, coleen.phillimore at oracle.com wrote: >> >> >> On 6/26/19 11:44 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> That seems okay so far, but there seem to be changes missing from >>> >>> ./share/prims/jvmtiImpl.hpp >> >> Good find.? Also a missing one from jvmtiExport.hpp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev >> >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>>> >>>> See bug for more information. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>>> >>>> Tested with hs-tier1-3. >>>> >>>> Thanks, >>>> Coleen >> From dean.long at oracle.com Wed Jun 26 18:50:20 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 26 Jun 2019 11:50:20 -0700 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> Message-ID: I don't see it removed from the .hpp files. dl On 6/26/19 8:02 AM, coleen.phillimore at oracle.com wrote: > Summary: Remove jvmtiExport::gc_epilogue after full GCs > > See bug for more information. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8225437 > > Tested with hs-tier1-3. > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jun 26 19:37:16 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 15:37:16 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> Message-ID: <7584cd71-5a40-736c-17e8-5578c0711c78@oracle.com> Hi Dean, thank you for reviewing.? I removed the declarations from the .hpp files in this webrev: open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev thanks, Coleen On 6/26/19 2:50 PM, dean.long at oracle.com wrote: > I don't see it removed from the .hpp files. > > dl > > On 6/26/19 8:02 AM, coleen.phillimore at oracle.com wrote: >> Summary: Remove jvmtiExport::gc_epilogue after full GCs >> >> See bug for more information. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >> >> Tested with hs-tier1-3. >> >> Thanks, >> Coleen > From serguei.spitsyn at oracle.com Wed Jun 26 21:10:56 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Jun 2019 14:10:56 -0700 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <0f9097aa-c489-353a-2805-af9909a746d2@gmail.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5c156c6b-bc47-97d5-2c61-5b4f44e098c0@oracle.com> <0f9097aa-c489-353a-2805-af9909a746d2@gmail.com> Message-ID: <6a84a869-4831-c133-c6a6-21f8fd11889f@oracle.com> An HTML attachment was scrubbed... URL: From dean.long at oracle.com Wed Jun 26 21:48:35 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 26 Jun 2019 14:48:35 -0700 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> Message-ID: <2edada21-df15-09ce-62c9-22fd43314b8e@oracle.com> +1 dl On 6/26/19 11:14 AM, David Holmes wrote: > Hi Coleen, > > v2 looks complete. > > Thanks, > David > > On 26/06/2019 1:47 pm, coleen.phillimore at oracle.com wrote: >> >> >> On 6/26/19 11:44 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> That seems okay so far, but there seem to be changes missing from >>> >>> ./share/prims/jvmtiImpl.hpp >> >> Good find.? Also a missing one from jvmtiExport.hpp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev >> >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>>> >>>> See bug for more information. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>>> >>>> Tested with hs-tier1-3. >>>> >>>> Thanks, >>>> Coleen >> From coleen.phillimore at oracle.com Wed Jun 26 22:35:47 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 18:35:47 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <2edada21-df15-09ce-62c9-22fd43314b8e@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> <2edada21-df15-09ce-62c9-22fd43314b8e@oracle.com> Message-ID: Thanks Dean! Coleen On 6/26/19 5:48 PM, dean.long at oracle.com wrote: > +1 > > dl > > On 6/26/19 11:14 AM, David Holmes wrote: >> Hi Coleen, >> >> v2 looks complete. >> >> Thanks, >> David >> >> On 26/06/2019 1:47 pm, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 6/26/19 11:44 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> That seems okay so far, but there seem to be changes missing from >>>> >>>> ./share/prims/jvmtiImpl.hpp >>> >>> Good find.? Also a missing one from jvmtiExport.hpp. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev >>> >>> thanks! >>> Coleen >>>> >>>> Thanks, >>>> David >>>> >>>> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>>>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>>>> >>>>> See bug for more information. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>>>> >>>>> Tested with hs-tier1-3. >>>>> >>>>> Thanks, >>>>> Coleen >>> > From yasuenag at gmail.com Thu Jun 27 01:41:06 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 27 Jun 2019 10:41:06 +0900 Subject: A Bug about the JVM Attach mechanism In-Reply-To: <6a84a869-4831-c133-c6a6-21f8fd11889f@oracle.com> References: <0f16a2f0-d0b5-0948-c7d4-c1357446f473@oracle.com> <5c156c6b-bc47-97d5-2c61-5b4f44e098c0@oracle.com> <0f9097aa-c489-353a-2805-af9909a746d2@gmail.com> <6a84a869-4831-c133-c6a6-21f8fd11889f@oracle.com> Message-ID: Hi Serguei, Thank you for your comment. I uploaded new webrev which includes the fix. http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal.3/ Also I added TODO for other Un*x OSes. If the change for Linux is OK, I will copy it to others. (I do not have them, so I depend on submit repo.) This webrev has passed test/hotspot/jtreg/serviceability/attach and test/jdk/com/sun/tools/attach jtreg tests on Linux x64. Thanks, Yasumasa 2019?6?27?(?) 6:10 serguei.spitsyn at oracle.com : > > Hi Yasumasa, > > I'm reviewing it. > > Just a quick comment. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal.2/src/hotspot/os/linux/attachListener_linux.cpp.udiff.html > > + // reads a request from the given connected socket > + static LinuxAttachOperation* read_request(int s); > + > + static bool _atexit_registered; > + > + public: > + enum { > + ATTACH_PROTOCOL_VER = 1 // protocol version > + }; > + enum { > + ATTACH_ERROR_BADVERSION = 101 // error codes > + }; > + > static void set_path(char* path) { > if (path == NULL) { > + _path[0] = '\0'; > _has_path = false; > } else { > strncpy(_path, path, UNIX_PATH_MAX); > _path[UNIX_PATH_MAX-1] = '\0'; > _has_path = true; > } > } > > static void set_listener(int s) { _listener = s; } > > - // reads a request from the given connected socket > - static LinuxAttachOperation* read_request(int s); > - > - public: > - enum { > - ATTACH_PROTOCOL_VER = 1 // protocol version > - }; > - enum { > - ATTACH_ERROR_BADVERSION = 101 // error codes > - }; > - > > > You moved public definitions of enums up in the code. > All the declarations below that were private before became public now. > Not sure, if it was your intention > > Also, the Copyright comment in this file needs an update. > > Thanks, > Serguei > > > > On 6/26/19 07:34, Yasumasa Suenaga wrote: > > Hi, > > >> I'm not clear how this addresses the issue with deleting the file? The > >> file still has to exist IIUC for the mechanism to work. > >> > >> This seems more suited to fixing the "multiple attach threads" problem. > > How about this change? > http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal.2/ > > I think it can fix both JDK-8225690 and JDK-8225193. > > This webrev implements for Linux only. > If we work further based on this, we need to implement AttachListener::check_socket_file() for each OS's implementation. > > > Thanks, > > Yasumasa > > > On 2019/06/21 23:16, Yasumasa Suenaga wrote: > > On 2019/06/21 22:51, David Holmes wrote: > > Hi Yasumasa, > > On 21/06/2019 5:12 am, Yasumasa Suenaga wrote: > > Hi, > > Can we fix this issue like this webrev? > http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/ > > > I'm not clear how this addresses the issue with deleting the file? The file still has to exist IIUC for the mechanism to work. > > This seems more suited to fixing the "multiple attach threads" problem. > > > Yes, my proposal focuses to "multiple attach threads". > I shared my patch because it might help the work for this issue. > > This patch would guard multithread-issue in Attach Listener. > So unix domain socket file will create just once. > > > Yasumasa > > > David > > I could reproduce this issue with ConcAttachTest.java in it > on my laptop. > (Fedora 30 x64 on Hyper-V guest: Core i3-8145U x 2vcpu) > > If we need to fix based on current implementation, I think > we need to use atomic operation. > But if we can refactor around here, we might be able to another approach - e.g. using monitors/mutexes > > > Thanks, > > Yasumasa > > > On 2019/06/21 5:49, David Holmes wrote: > > Sorry it took me a while to understand the specifics of the problem. :) > > David > > On 20/06/2019 3:37 am, nijiaben wrote: > > Yes Alan, I mean this > ------------------?Original?------------------ > *From: *?"Alan Bateman"; > *Date: *?Thu, Jun 20, 2019 02:54 PM > *To: *?"nijiaben"; "David > Holmes"; > "serviceability-dev"; > "jdk8u-dev"; > "hotspot-runtime-dev"; > *Subject: *?Re: A Bug about the JVM Attach mechanism > On 20/06/2019 05:10, nijiaben wrote: > > : > > I know this mechanism, can we provide means of recovery to avoid > unavailability caused by accidental deletion? > > > Are you concerned about tmpreaper or cron jobs that periodically cleanup > /tmp? There may indeed be an issue for applications that run for weeks > or months. If someone is using jmap, jcmd or other tools using the > attach API then it will trigger the attach listener to start. When they > come back in a few weeks then the .java_pid file may have been > removed so they cannot attach. Is this what what you are pointing out? > > -Alan > > From christoph.langer at sap.com Fri Jun 28 10:08:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 28 Jun 2019 10:08:13 +0000 Subject: RFR CSR (S): 8226940: Adjust permission for delayed starting of debugging Message-ID: Hi, may I please get a review for the CSR to adjust the permission for delayed starting of debugging. The change itself has been reviewed already but a CSR had not been created yet. We were waiting for approval of CSR JDK-8223456 about the overall "delayed starting of debugging" feature. This adjustment would be targeted for JDK13. CSR: https://bugs.openjdk.java.net/browse/JDK-8226940 Bug: https://bugs.openjdk.java.net/browse/JDK-8224673 Review Thread: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028210.html Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From poonam.bajaj at oracle.com Fri Jun 28 14:19:33 2019 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Fri, 28 Jun 2019 07:19:33 -0700 Subject: RFR 8215523: jstat reports incorrect values for OU for CMS GC In-Reply-To: References: <64c5a88a-a39d-fedb-7738-998bca61b6a7@oracle.com> <4bb04022-9460-3956-cf86-447bafab0bf4@oracle.com> Message-ID: <93c477a9-bb9c-f20c-36f4-b70ef85b6ebf@oracle.com> Hello, Thomas Schatzl pointed out that the recalculate_used_stable() call in collect_in_background() may not be necessary. Testing the changes after removing that call confirmed that. Here's the updated webrev: http://cr.openjdk.java.net/~poonam/8215523/webrev.01/ Thanks, Poonam On 6/21/19 5:59 PM, serguei.spitsyn at oracle.com wrote: > Hi Poonam, > > The fix looks Okay from the Serviceability point of view. > > Thanks, > Serguei > > > On 6/21/19 13:30, Poonam Parhar wrote: >> Updating the subject line with the updated bug synopsis. >> >> And also, much thanks to Thomas Schatzl for his remarkable help in >> tweaking and refining this fix. >> >> regards, >> Poonam >> >> On 6/21/19 12:21 PM, Poonam Parhar wrote: >>> Hello, >>> >>> Please review the changes for the fix of: >>> >>> Bug 8215523 : >>> jstat reports incorrect values for OU for CMS GC >>> Webrev: http://cr.openjdk.java.net/~poonam/8215523/webrev.00/ >>> >>> Problem: >>> With CMS, at certain points, 'OU' (Old usage) values reported in the >>> jstat output increase first and then drop down. This is wrong >>> because the 'old usage' drops down without any old generation >>> collection. >>> >>> Cause: >>> For the 'used' values of different memory spaces, jstat uses a >>> periodic task to read these values and update the corresponding >>> jstat counters. >>> >>> For CMS generation, there is a sampler that periodically updates the >>> 'used' counter: >>> >>> ?class GenerationUsedHelper : public PerfLongSampleHelper { >>> 103 private: >>> 104 Generation* _gen; >>> 105 >>> 106 public: >>> 107 GenerationUsedHelper(Generation* g) : _gen(g) { } >>> 108 >>> 109 inline jlong take_sample() { >>> 110 return _gen->used(); >>> 111 } >>> 112 }; >>> >>> The above used() call in turn makes a call to >>> CompactibleFreeListSpace::used(). >>> >>> 376 size_t CompactibleFreeListSpace::used() const { >>> 377 return capacity() - free(); >>> 378 } >>> 379 >>> 380 size_t CompactibleFreeListSpace::free() const { >>> 381 // "MT-safe, but not MT-precise"(TM), if you will: i.e. >>> 382 // if you do this while the structures are in flux you >>> 383 // may get an approximate answer only; for instance >>> 384 // because there is concurrent allocation either >>> 385 // directly by mutators or for promotion during a GC. >>> 386 // It's "MT-safe", however, in the sense that you are guaranteed >>> 387 // not to crash and burn, for instance, because of walking >>> 388 // pointers that could disappear as you were walking them. >>> 389 // The approximation is because the various components >>> 390 // that are read below are not read atomically (and >>> 391 // further the computation of totalSizeInIndexedFreeLists() >>> 392 // is itself a non-atomic computation. The normal use of >>> 393 // this is during a resize operation at the end of GC >>> 394 // and at that time you are guaranteed to get the >>> 395 // correct actual value. However, for instance, this is >>> 396 // also read completely asynchronously by the "perf-sampler" >>> 397 // that supports jvmstat, and you are apt to see the values >>> 398 // flicker in such cases. >>> 399 assert(_dictionary != NULL, "No _dictionary?"); >>> 400 return (_dictionary->total_chunk_size(DEBUG_ONLY(freelistLock())) + >>> 401 totalSizeInIndexedFreeLists() + >>> 402 _smallLinearAllocBlock._word_size) * HeapWordSize; >>> 403 } >>> >>> As stated above in the code comments, free() can return an imprecise >>> approximate value when allocations are happening in the >>> CompactibleFreeListSpace at the same time, e.g. during direct >>> allocations or promotions. >>> >>> Solution: >>> For CMS, maintain an internal variable for the space usage. This >>> internal variable gets updated only at points where the CMS space >>> usage computation is guaranteed to be accurate. jstat and other >>> memory usage monitoring tools get access to this stable value of >>> used space. >>> >>> Testing: jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2,hs-tier3 >>> >>> Thanks, >>> Poonam >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Fri Jun 28 16:32:06 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 28 Jun 2019 18:32:06 +0200 Subject: RFR 8215523: jstat reports incorrect values for OU for CMS GC In-Reply-To: <4bb04022-9460-3956-cf86-447bafab0bf4@oracle.com> References: <64c5a88a-a39d-fedb-7738-998bca61b6a7@oracle.com> <4bb04022-9460-3956-cf86-447bafab0bf4@oracle.com> Message-ID: <826ea1ecf7c1b38bd90f15e0a5def29153c4af58.camel@redhat.com> Hi Poonam, One nit caught my eye: On Fri, 2019-06-21 at 13:30 -0700, Poonam Parhar wrote: > Please review the changes for the fix of: > > > > Bug 8215523: jstat reports incorrect values for OU for CMS GC > > Webrev: http://cr.openjdk.java.net/~poonam/8215523/webrev.00/ http://cr.openjdk.java.net/%7Epoonam/8215523/webrev.00/src/hotspot/share/gc/cms/compactibleFreeListSpace.hpp.sdiff.html Line 419 the comment mentions "... required for jhat and other ...". jhat no longer exists. Do you mean jstat? Thanks, Severin From poonam.bajaj at oracle.com Fri Jun 28 17:11:05 2019 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Fri, 28 Jun 2019 10:11:05 -0700 Subject: RFR 8215523: jstat reports incorrect values for OU for CMS GC In-Reply-To: <826ea1ecf7c1b38bd90f15e0a5def29153c4af58.camel@redhat.com> References: <64c5a88a-a39d-fedb-7738-998bca61b6a7@oracle.com> <4bb04022-9460-3956-cf86-447bafab0bf4@oracle.com> <826ea1ecf7c1b38bd90f15e0a5def29153c4af58.camel@redhat.com> Message-ID: <90b4621f-b7cf-deb4-2084-a0338e825420@oracle.com> Hello Severin, Thanks for catching that. Yes, I meant jstat. I will correct that. regards, Poonam On 6/28/19 9:32 AM, Severin Gehwolf wrote: > Hi Poonam, > > One nit caught my eye: > > On Fri, 2019-06-21 at 13:30 -0700, Poonam Parhar wrote: >> Please review the changes for the fix of: >>> Bug 8215523: jstat reports incorrect values for OU for CMS GC >>> Webrev: http://cr.openjdk.java.net/~poonam/8215523/webrev.00/ > http://cr.openjdk.java.net/%7Epoonam/8215523/webrev.00/src/hotspot/share/gc/cms/compactibleFreeListSpace.hpp.sdiff.html > > Line 419 the comment mentions "... required for jhat and other ...". > jhat no longer exists. Do you mean jstat? > > Thanks, > Severin > From thomas.schatzl at oracle.com Fri Jun 28 17:21:52 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 28 Jun 2019 19:21:52 +0200 Subject: RFR 8215523: jstat reports incorrect values for OU for CMS GC In-Reply-To: <93c477a9-bb9c-f20c-36f4-b70ef85b6ebf@oracle.com> References: <64c5a88a-a39d-fedb-7738-998bca61b6a7@oracle.com> <4bb04022-9460-3956-cf86-447bafab0bf4@oracle.com> <93c477a9-bb9c-f20c-36f4-b70ef85b6ebf@oracle.com> Message-ID: Hi, On Fri, 2019-06-28 at 07:19 -0700, Poonam Parhar wrote: > Hello, > > Thomas Schatzl pointed out that the recalculate_used_stable() call > in collect_in_background() may not be necessary. Testing the changes > after removing that call confirmed that. Here's the updated webrev: > http://cr.openjdk.java.net/~poonam/8215523/webrev.01/ looks good. Thomas :) From serguei.spitsyn at oracle.com Fri Jun 28 17:27:44 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 10:27:44 -0700 Subject: RFR CSR (S): 8226940: Adjust permission for delayed starting of debugging In-Reply-To: References: Message-ID: <08b85460-fee5-7f13-a3fa-ef7d5713a581@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jun 28 18:06:25 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 11:06:25 -0700 Subject: (13) CSR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) Message-ID: Please, review a test bug fix for: ? https://bugs.openjdk.java.net/browse/JDK-8226917 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ Summary: ? One more fragment in the native agent was overlooked and is not needed anymore ? after the fix of JDK-8223736 which implemented more reliable sync approach. ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because ? the sleep timeout changed to be shorter. Now, the thread holding the monitor ? is able to notice the enterEventsCount was increased by the MonitorContendedEnter ? event callback and finish before the callback attempts to interrupt it with the ? JVMTI InterruptThread. Testing: ? A mach5 submission is in progress. Thanks, Serguei From serguei.spitsyn at oracle.com Fri Jun 28 18:09:09 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 11:09:09 -0700 Subject: (13) CSR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) In-Reply-To: References: Message-ID: I've used CSR instead of RFR in the subject. So, please, ignore this. I'll resend it with the correct subject line. Thanks, Serguei On 6/28/19 11:06, serguei.spitsyn at oracle.com wrote: > Please, review a test bug fix for: > ? https://bugs.openjdk.java.net/browse/JDK-8226917 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ > > > > Summary: > ? One more fragment in the native agent was overlooked and is not > needed anymore > ? after the fix of JDK-8223736 which implemented more reliable sync > approach. > ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because > ? the sleep timeout changed to be shorter. Now, the thread holding the > monitor > ? is able to notice the enterEventsCount was increased by the > MonitorContendedEnter > ? event callback and finish before the callback attempts to interrupt > it with the > ? JVMTI InterruptThread. > > > Testing: > ? A mach5 submission is in progress. > > Thanks, > Serguei From serguei.spitsyn at oracle.com Fri Jun 28 18:09:56 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 11:09:56 -0700 Subject: (13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) Message-ID: Please, review a test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8226917 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ Summary: ? One more fragment in the native agent was overlooked and is not needed anymore ? after the fix of JDK-8223736 which implemented more reliable sync approach. ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because ? the sleep timeout changed to be shorter. Now, the thread holding the monitor ? is able to notice the enterEventsCount was increased by the MonitorContendedEnter ? event callback and finish before the callback attempts to interrupt it with the ? JVMTI InterruptThread. Testing: ? A mach5 submission is in progress. Thanks, Serguei From gary.adams at oracle.com Fri Jun 28 18:58:11 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 28 Jun 2019 14:58:11 -0400 Subject: (13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) In-Reply-To: References: Message-ID: <82f405a5-fc72-f3c3-d5e7-37aef1127d35@oracle.com> Looks good to me. On 6/28/19 2:09 PM, serguei.spitsyn at oracle.com wrote: > Please, review a test bug fix for: > https://bugs.openjdk.java.net/browse/JDK-8226917 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ > > > > Summary: > ? One more fragment in the native agent was overlooked and is not > needed anymore > ? after the fix of JDK-8223736 which implemented more reliable sync > approach. > ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because > ? the sleep timeout changed to be shorter. Now, the thread holding the > monitor > ? is able to notice the enterEventsCount was increased by the > MonitorContendedEnter > ? event callback and finish before the callback attempts to interrupt > it with the > ? JVMTI InterruptThread. > > > Testing: > ? A mach5 submission is in progress. > > Thanks, > Serguei From david.holmes at oracle.com Fri Jun 28 19:04:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Jun 2019 15:04:10 -0400 Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx In-Reply-To: References: Message-ID: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com> Hi Matthias, Dropped build-dev and added serviceability-dev as this is a servicability test. On 28/06/2019 7:43 am, Baesken, Matthias wrote: > Hello please review this small fix for a compile issue on OSX . > Today I compiled jdk/jdk on a machine with XCode 10.2 . It worked pretty well . > However this small issue showed up . > > > In file included from /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33: > /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: error: > comparison of two values with different enumeration types in switch statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') [-Werror,-Wenum-compare-switch] > > > And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT is from a different enumeration type and should be replaced with the value from the correct enumeration type . > > Bug / webrev : > > https://bugs.openjdk.java.net/browse/JDK-8226943 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/ The fix seems reasonable but the issue indicates a further problem with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit the default clause and failed the test. That suggests the test doesn't actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place. Cheers, David > > Thanks, Matthias > From gary.adams at oracle.com Fri Jun 28 19:16:45 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 28 Jun 2019 15:16:45 -0400 Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx In-Reply-To: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com> References: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com> Message-ID: <4bddba5d-cf94-4c38-48f6-835d76bfdea6@oracle.com> I believe you will find in the generate jvmti.h header file that both enumerations had assigned value of 3. That could explain why a less type strict version of the compiler would not have complained. On 6/28/19 3:04 PM, David Holmes wrote: > Hi Matthias, > > Dropped build-dev and added serviceability-dev as this is a > servicability test. > > On 28/06/2019 7:43 am, Baesken, Matthias wrote: >> Hello please review this? small fix for a compile issue? on OSX . >> Today I? compiled?? jdk/jdk?? on a machine? with?? XCode 10.2? . It >> worked pretty well . >> However this small issue showed up . >> >> >> In file included from >> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33: >> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: >> error: >> comparison of two values with different enumeration types in switch >> statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') >> [-Werror,-Wenum-compare-switch] >> >> >> And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT?? is >> from a different? enumeration type? and should be replaced? with the >> value? from the correct enumeration type?? . >> >> Bug / webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8226943 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/ > > The fix seems reasonable but the issue indicates a further problem > with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but > was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit > the default clause and failed the test. That suggests the test doesn't > actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place. > > Cheers, > David > >> >> Thanks, Matthias >> From christoph.langer at sap.com Fri Jun 28 19:31:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 28 Jun 2019 19:31:16 +0000 Subject: RFR CSR (S): 8226940: Adjust permission for delayed starting of debugging In-Reply-To: <08b85460-fee5-7f13-a3fa-ef7d5713a581@oracle.com> References: <08b85460-fee5-7f13-a3fa-ef7d5713a581@oracle.com> Message-ID: Thanks, Serguei. From: serguei.spitsyn at oracle.com Sent: Freitag, 28. Juni 2019 19:28 To: Langer, Christoph ; OpenJDK Serviceability Subject: Re: RFR CSR (S): 8226940: Adjust permission for delayed starting of debugging Hi Christoph, It looks good, reviewed. Thanks, Serguei On 6/28/19 03:08, Langer, Christoph wrote: Hi, may I please get a review for the CSR to adjust the permission for delayed starting of debugging. The change itself has been reviewed already but a CSR had not been created yet. We were waiting for approval of CSR JDK-8223456 about the overall ?delayed starting of debugging? feature. This adjustment would be targeted for JDK13. CSR: https://bugs.openjdk.java.net/browse/JDK-8226940 Bug: https://bugs.openjdk.java.net/browse/JDK-8224673 Review Thread: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028210.html Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Jun 28 19:33:24 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 28 Jun 2019 15:33:24 -0400 Subject: (13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) In-Reply-To: References: Message-ID: <26d2dfc5-5b89-6e3b-7502-5608c6169abf@oracle.com> On 6/28/19 2:09 PM, serguei.spitsyn at oracle.com wrote: > Please, review a test bug fix for: > https://bugs.openjdk.java.net/browse/JDK-8226917 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp ??? old L129: ??????? if (!NSK_JVMTI_VERIFY(jvmti->GetObjectMonitorUsage(obj, &usageInfo))) { ??? old L131: ??????? } else if (usageInfo.owner != NULL) { ??? old L132: ??????????? if (!NSK_JVMTI_VERIFY(jvmti->InterruptThread(usageInfo.owner))) ??????? This construct in the old code is racy anyway. Just because the ??????? GetObjectMonitorUsage() returns information that the object is ??????? locked by the owner field does not mean that the owner thread ??????? hasn't exited the lock (and left the building) by the time the ??????? the InterruptThread() call is made. I suspect they were trying ??????? to get the owner thread out of the sleep, but they never should ??????? have checked the result of that call. ??????? Looks good. Thumbs up. Dan > > > Summary: > ? One more fragment in the native agent was overlooked and is not > needed anymore > ? after the fix of JDK-8223736 which implemented more reliable sync > approach. > ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because > ? the sleep timeout changed to be shorter. Now, the thread holding the > monitor > ? is able to notice the enterEventsCount was increased by the > MonitorContendedEnter > ? event callback and finish before the callback attempts to interrupt > it with the > ? JVMTI InterruptThread. > > > Testing: > ? A mach5 submission is in progress. > > Thanks, > Serguei From matthias.baesken at sap.com Fri Jun 28 19:41:56 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Jun 2019 19:41:56 +0000 Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx In-Reply-To: <4bddba5d-cf94-4c38-48f6-835d76bfdea6@oracle.com> References: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com>, <4bddba5d-cf94-4c38-48f6-835d76bfdea6@oracle.com> Message-ID: <542721AE-5E8E-476A-B7AE-945809D3A09A@sap.com> Hi Gary and David, yes it is value 3 in both cases, I noticed that in the jvmti XML . Best regards, Matthias Von meinem iPhone gesendet > Am 28.06.2019 um 21:17 schrieb "gary.adams at oracle.com" : > > I believe you will find in the generate jvmti.h header file > that both enumerations had assigned value of 3. > That could explain why a less type strict version of the > compiler would not have complained. > >> On 6/28/19 3:04 PM, David Holmes wrote: >> Hi Matthias, >> >> Dropped build-dev and added serviceability-dev as this is a servicability test. >> >>> On 28/06/2019 7:43 am, Baesken, Matthias wrote: >>> Hello please review this small fix for a compile issue on OSX . >>> Today I compiled jdk/jdk on a machine with XCode 10.2 . It worked pretty well . >>> However this small issue showed up . >>> >>> >>> In file included from /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33: >>> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: error: >>> comparison of two values with different enumeration types in switch statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') [-Werror,-Wenum-compare-switch] >>> >>> >>> And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT is from a different enumeration type and should be replaced with the value from the correct enumeration type . >>> >>> Bug / webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8226943 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/ >> >> The fix seems reasonable but the issue indicates a further problem with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit the default clause and failed the test. That suggests the test doesn't actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place. >> >> Cheers, >> David >> >>> >>> Thanks, Matthias >>> > From daniil.x.titov at oracle.com Fri Jun 28 22:31:57 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 28 Jun 2019 15:31:57 -0700 Subject: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) Message-ID: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> Please review the change that improves performance of ThreadMXBean MXBean methods returning the information for specific threads. The change introduces the thread table that uses ConcurrentHashTable to store one-to-one the mapping between the thread ids and JavaThread objects and replaces the linear search over the thread list in ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the lookup in the thread table. Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 Thanks! Best regards, Daniil From serguei.spitsyn at oracle.com Fri Jun 28 22:48:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 15:48:58 -0700 Subject: (13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) In-Reply-To: <82f405a5-fc72-f3c3-d5e7-37aef1127d35@oracle.com> References: <82f405a5-fc72-f3c3-d5e7-37aef1127d35@oracle.com> Message-ID: Thank you a lot, Gary! Serguei On 6/28/19 11:58 AM, gary.adams at oracle.com wrote: > Looks good to me. > > On 6/28/19 2:09 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a test bug fix for: >> https://bugs.openjdk.java.net/browse/JDK-8226917 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ >> >> >> >> Summary: >> ? One more fragment in the native agent was overlooked and is not >> needed anymore >> ? after the fix of JDK-8223736 which implemented more reliable sync >> approach. >> ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because >> ? the sleep timeout changed to be shorter. Now, the thread holding >> the monitor >> ? is able to notice the enterEventsCount was increased by the >> MonitorContendedEnter >> ? event callback and finish before the callback attempts to interrupt >> it with the >> ? JVMTI InterruptThread. >> >> >> Testing: >> ? A mach5 submission is in progress. >> >> Thanks, >> Serguei > From serguei.spitsyn at oracle.com Fri Jun 28 22:52:19 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 15:52:19 -0700 Subject: (13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) In-Reply-To: <26d2dfc5-5b89-6e3b-7502-5608c6169abf@oracle.com> References: <26d2dfc5-5b89-6e3b-7502-5608c6169abf@oracle.com> Message-ID: <3107dbd1-53ed-480a-885a-17b211553002@oracle.com> On 6/28/19 12:33 PM, Daniel D. Daugherty wrote: > On 6/28/19 2:09 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a test bug fix for: >> https://bugs.openjdk.java.net/browse/JDK-8226917 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ >> > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp > > ??? old L129: ??????? if > (!NSK_JVMTI_VERIFY(jvmti->GetObjectMonitorUsage(obj, &usageInfo))) { > ??? old L131: ??????? } else if (usageInfo.owner != NULL) { > ??? old L132: ??????????? if > (!NSK_JVMTI_VERIFY(jvmti->InterruptThread(usageInfo.owner))) > ??????? This construct in the old code is racy anyway. Just because the > ??????? GetObjectMonitorUsage() returns information that the object is > ??????? locked by the owner field does not mean that the owner thread > ??????? hasn't exited the lock (and left the building) by the time the > ??????? the InterruptThread() call is made. I suspect they were trying > ??????? to get the owner thread out of the sleep, but they never should > ??????? have checked the result of that call. Yes, they wanted to get the owner thread out of the sleep. And it is racy. There was pretty big timeout before to make it more reliable. Thanks, Serguei > > ??????? Looks good. > > Thumbs up. > Thanks a lot, Dan! Serguei > Dan > > >> >> >> Summary: >> ? One more fragment in the native agent was overlooked and is not >> needed anymore >> ? after the fix of JDK-8223736 which implemented more reliable sync >> approach. >> ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because >> ? the sleep timeout changed to be shorter. Now, the thread holding >> the monitor >> ? is able to notice the enterEventsCount was increased by the >> MonitorContendedEnter >> ? event callback and finish before the callback attempts to interrupt >> it with the >> ? JVMTI InterruptThread. >> >> >> Testing: >> ? A mach5 submission is in progress. >> >> Thanks, >> Serguei > From alexey.menkov at oracle.com Fri Jun 28 22:56:04 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 28 Jun 2019 15:56:04 -0700 Subject: (13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) In-Reply-To: <82f405a5-fc72-f3c3-d5e7-37aef1127d35@oracle.com> References: <82f405a5-fc72-f3c3-d5e7-37aef1127d35@oracle.com> Message-ID: <38e1296a-2a6a-448b-b25d-ac19f2aa6bfe@oracle.com> +1 --alex On 06/28/2019 11:58, gary.adams at oracle.com wrote: > Looks good to me. > > On 6/28/19 2:09 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a test bug fix for: >> https://bugs.openjdk.java.net/browse/JDK-8226917 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ >> >> >> >> Summary: >> ? One more fragment in the native agent was overlooked and is not >> needed anymore >> ? after the fix of JDK-8223736 which implemented more reliable sync >> approach. >> ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because >> ? the sleep timeout changed to be shorter. Now, the thread holding the >> monitor >> ? is able to notice the enterEventsCount was increased by the >> MonitorContendedEnter >> ? event callback and finish before the callback attempts to interrupt >> it with the >> ? JVMTI InterruptThread. >> >> >> Testing: >> ? A mach5 submission is in progress. >> >> Thanks, >> Serguei > From serguei.spitsyn at oracle.com Fri Jun 28 22:57:39 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 15:57:39 -0700 Subject: (13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE) In-Reply-To: <38e1296a-2a6a-448b-b25d-ac19f2aa6bfe@oracle.com> References: <82f405a5-fc72-f3c3-d5e7-37aef1127d35@oracle.com> <38e1296a-2a6a-448b-b25d-ac19f2aa6bfe@oracle.com> Message-ID: <94cdf165-416d-16ec-a678-a03859254036@oracle.com> Thanks a lot, Alex! Serguei On 6/28/19 3:56 PM, Alex Menkov wrote: > +1 > > --alex > > On 06/28/2019 11:58, gary.adams at oracle.com wrote: >> Looks good to me. >> >> On 6/28/19 2:09 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a test bug fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8226917 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ >>> >>> >>> >>> Summary: >>> ? One more fragment in the native agent was overlooked and is not >>> needed anymore >>> ? after the fix of JDK-8223736 which implemented more reliable sync >>> approach. >>> ? The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen >>> because >>> ? the sleep timeout changed to be shorter. Now, the thread holding >>> the monitor >>> ? is able to notice the enterEventsCount was increased by the >>> MonitorContendedEnter >>> ? event callback and finish before the callback attempts to >>> interrupt it with the >>> ? JVMTI InterruptThread. >>> >>> >>> Testing: >>> ? A mach5 submission is in progress. >>> >>> Thanks, >>> Serguei >> From serguei.spitsyn at oracle.com Sat Jun 29 01:55:28 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 18:55:28 -0700 Subject: (13) RFR (S): 8226603: accessibility issues in specs/jvmti.html Message-ID: Please, review a fix for: ? https://bugs.openjdk.java.net/browse/JDK-8226603 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226603-jvmti-a11y.1/ Summary: ? The change fixes the a11y issues reported by the Axe tool. Testing: ? Alex checked that the Axe tool reports noting with the updated jvmti.html. ? Also, the DocCheck reported the following heading errors for the original jvmti.html: % grep heading report0/accessibility.log 0/jvmti.html:30: headings omitted 0/jvmti.html:27: Note: This is the previous heading 0/jvmti.html:880: headings omitted 0/jvmti.html:879: Note: This is the previous heading 0/jvmti.html:5308: headings omitted 0/jvmti.html:5253: Note: This is the previous heading 0/jvmti.html:7700: headings omitted 0/jvmti.html:7607: Note: This is the previous heading 0/jvmti.html:19857: headings omitted 0/jvmti.html:19797: Note: This is the previous heading 0/jvmti.html:23821: headings omitted 0/jvmti.html:23593: Note: This is the previous heading 0/jvmti.html:24546: headings omitted 0/jvmti.html:24416: Note: This is the previous heading 0/jvmti.html:25404: headings omitted 0/jvmti.html:25362: Note: This is the previous heading 0/jvmti.html:30724: headings omitted 0/jvmti.html:30723: Note: This is the previous heading Now all these errors are gone. Thanks, Serguei From serguei.spitsyn at oracle.com Sat Jun 29 02:05:43 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 19:05:43 -0700 Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx In-Reply-To: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com> References: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com> Message-ID: Hi Matthias, The fix is good. It worked before because both JVMTI_REFERENCE_ARRAY_ELEMENT and JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT have the same value 3 as Gary noticed. I'd suggest to fix it in 13 as it is the test fix. I've added labels 'testbug' and 'noreg-self'. Thanks, Serguei On 6/28/19 12:04 PM, David Holmes wrote: > Hi Matthias, > > Dropped build-dev and added serviceability-dev as this is a > servicability test. > > On 28/06/2019 7:43 am, Baesken, Matthias wrote: >> Hello please review this? small fix for a compile issue? on OSX . >> Today I? compiled?? jdk/jdk?? on a machine? with?? XCode 10.2? . It >> worked pretty well . >> However this small issue showed up . >> >> >> In file included from >> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33: >> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: >> error: >> comparison of two values with different enumeration types in switch >> statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') >> [-Werror,-Wenum-compare-switch] >> >> >> And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT?? is >> from a different? enumeration type? and should be replaced? with the >> value? from the correct enumeration type?? . >> >> Bug / webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8226943 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/ > > The fix seems reasonable but the issue indicates a further problem > with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but > was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit > the default clause and failed the test. That suggests the test doesn't > actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place. > > Cheers, > David > >> >> Thanks, Matthias >> From serguei.spitsyn at oracle.com Sat Jun 29 02:56:04 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 19:56:04 -0700 Subject: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> Message-ID: <2d6dede1-aa79-99ce-a823-773fa2e19827@oracle.com> Hi Daniil, I have several quick comments. The indent in the hotspot c/c++ files has to be 2, not 4. https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/src/hotspot/share/runtime/threadSMR.cpp.frames.html 614 JavaThread* ThreadsList::find_JavaThread_from_java_tid(jlong java_tid) const { 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); 616 if (java_thread == NULL && java_tid == PMIMORDIAL_JAVA_TID) { 617 // ThreadsSMRSupport::add_thread() is not called for the primordial 618 // thread. Thus, we find this thread with a linear search and add it 619 // to the thread table. 620 for (uint i = 0; i < length(); i++) { 621 JavaThread* thread = thread_at(i); 622 if (is_valid_java_thread(java_tid,thread)) { 623 ThreadTable::add_thread(java_tid, thread); 624 return thread; 625 } 626 } 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { 628 return java_thread; 629 } 630 return NULL; 631 } 632 bool ThreadsList::is_valid_java_thread(jlong java_tid, JavaThread* java_thread) { 633 oop tobj = java_thread->threadObj(); 634 // Ignore the thread if it hasn't run yet, has exited 635 // or is starting to exit. 636 return (tobj != NULL && !java_thread->is_exiting() && 637 java_tid == java_lang_Thread::thread_id(tobj)); 638 } 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); I'd suggest to rename find_thread() tofind_thread_by_tid(). A space is missed after the comma: 622 if (is_valid_java_thread(java_tid,thread)) { An empty line is needed before L632. The name 'is_valid_java_thread' looks wrong (or confusing) to me. Something like 'is_alive_java_thread_with_tid()' would be better. It'd better to list parameters in the opposite order. The call to is_valid_java_thread() is confusing: ?? 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { Why would the call ThreadTable::find_thread(java_tid) return a JavaThread with an unmatched java_tid? Thanks, Serguei On 6/28/19 3:31 PM, Daniil Titov wrote: > Please review the change that improves performance of ThreadMXBean MXBean methods returning the > information for specific threads. The change introduces the thread table that uses ConcurrentHashTable > to store one-to-one the mapping between the thread ids and JavaThread objects and replaces the linear > search over the thread list in ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the lookup > in the thread table. > > Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. > > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > Thanks! > > Best regards, > Daniil > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Jun 29 04:39:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 29 Jun 2019 14:39:59 +1000 Subject: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> Message-ID: Hi Daniil, The definition and use of this hashtable (yet another hashtable implementation!) will need careful examination. We have to be concerned about the cost of maintaining it when it may never even be queried. You would need to look at footprint cost and performance impact. Unfortunately I'm just about to board a plane and will be out for the next few days. I will try to look at this asap next week, but we will need a lot more data on it. Thanks, David On 28/06/2019 6:31 pm, Daniil Titov wrote: > Please review the change that improves performance of ThreadMXBean MXBean methods returning the > information for specific threads. The change introduces the thread table that uses ConcurrentHashTable > to store one-to-one the mapping between the thread ids and JavaThread objects and replaces the linear > search over the thread list in ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the lookup > in the thread table. > > Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. > > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > Thanks! > > Best regards, > Daniil > > > From david.holmes at oracle.com Sat Jun 29 04:44:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 29 Jun 2019 14:44:03 +1000 Subject: (13) RFR (S): 8226603: accessibility issues in specs/jvmti.html In-Reply-To: References: Message-ID: <3dfcf2d1-825b-ff6a-1025-768b4935a386@oracle.com> Hi Serguei, Looks good and trivial. Thanks, David On 28/06/2019 9:55 pm, serguei.spitsyn at oracle.com wrote: > Please, review a fix for: > ? https://bugs.openjdk.java.net/browse/JDK-8226603 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226603-jvmti-a11y.1/ > > > Summary: > ? The change fixes the a11y issues reported by the Axe tool. > > > Testing: > ? Alex checked that the Axe tool reports noting with the updated > jvmti.html. > ? Also, the DocCheck reported the following heading errors for the > original jvmti.html: > > % grep heading report0/accessibility.log > 0/jvmti.html:30: headings omitted > 0/jvmti.html:27: Note: This is the previous heading > 0/jvmti.html:880: headings omitted > 0/jvmti.html:879: Note: This is the previous heading > 0/jvmti.html:5308: headings omitted > 0/jvmti.html:5253: Note: This is the previous heading > 0/jvmti.html:7700: headings omitted > 0/jvmti.html:7607: Note: This is the previous heading > 0/jvmti.html:19857: headings omitted > 0/jvmti.html:19797: Note: This is the previous heading > 0/jvmti.html:23821: headings omitted > 0/jvmti.html:23593: Note: This is the previous heading > 0/jvmti.html:24546: headings omitted > 0/jvmti.html:24416: Note: This is the previous heading > 0/jvmti.html:25404: headings omitted > 0/jvmti.html:25362: Note: This is the previous heading > 0/jvmti.html:30724: headings omitted > 0/jvmti.html:30723: Note: This is the previous heading > > Now all these errors are gone. > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Sat Jun 29 04:58:27 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 21:58:27 -0700 Subject: (13) RFR (S): 8226603: accessibility issues in specs/jvmti.html In-Reply-To: <3dfcf2d1-825b-ff6a-1025-768b4935a386@oracle.com> References: <3dfcf2d1-825b-ff6a-1025-768b4935a386@oracle.com> Message-ID: <34dccbb1-369a-8c16-4ade-7acca5982595@oracle.com> Thanks a lot, David! Serguei On 6/28/19 21:44, David Holmes wrote: > Hi Serguei, > > Looks good and trivial. > > Thanks, > David > > On 28/06/2019 9:55 pm, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for: >> ?? https://bugs.openjdk.java.net/browse/JDK-8226603 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226603-jvmti-a11y.1/ >> >> >> Summary: >> ?? The change fixes the a11y issues reported by the Axe tool. >> >> >> Testing: >> ?? Alex checked that the Axe tool reports noting with the updated >> jvmti.html. >> ?? Also, the DocCheck reported the following heading errors for the >> original jvmti.html: >> >> % grep heading report0/accessibility.log >> 0/jvmti.html:30: headings omitted >> 0/jvmti.html:27: Note: This is the previous heading >> 0/jvmti.html:880: headings omitted >> 0/jvmti.html:879: Note: This is the previous heading >> 0/jvmti.html:5308: headings omitted >> 0/jvmti.html:5253: Note: This is the previous heading >> 0/jvmti.html:7700: headings omitted >> 0/jvmti.html:7607: Note: This is the previous heading >> 0/jvmti.html:19857: headings omitted >> 0/jvmti.html:19797: Note: This is the previous heading >> 0/jvmti.html:23821: headings omitted >> 0/jvmti.html:23593: Note: This is the previous heading >> 0/jvmti.html:24546: headings omitted >> 0/jvmti.html:24416: Note: This is the previous heading >> 0/jvmti.html:25404: headings omitted >> 0/jvmti.html:25362: Note: This is the previous heading >> 0/jvmti.html:30724: headings omitted >> 0/jvmti.html:30723: Note: This is the previous heading >> >> Now all these errors are gone. >> >> Thanks, >> Serguei >> From daniil.x.titov at oracle.com Sat Jun 29 16:06:57 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Sat, 29 Jun 2019 09:06:57 -0700 Subject: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: <2d6dede1-aa79-99ce-a823-773fa2e19827@oracle.com> References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> <2d6dede1-aa79-99ce-a823-773fa2e19827@oracle.com> Message-ID: <6E7B043A-4647-4931-977C-1854CA7EBEC1@oracle.com> Hi Serguei and David, Serguei is right, ThreadTable::find_thread(java_tid) cannot return a JavaThread with an unmatched java_tid. Please find a new version of the fix that includes the changes Serguei suggested. Regarding the concern about the maintaining the thread table when it may never even be queried, one of the options could be to add ThreadTable ::isEnabled flag, set it to "false" by default, and wrap the calls to the thread table in ThreadsSMRSupport add_thread() and remove_thread() methods to check this flag. When ThreadsList::find_JavaThread_from_java_tid() is called for the first time it could check if ThreadTable ::isEnabled Is on and if not then set it on and populate the thread table with all existing threads from the thread list. Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 Thanks! --Daniil From: Organization: Oracle Corporation Date: Friday, June 28, 2019 at 7:56 PM To: Daniil Titov , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" Subject: Re: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) Hi Daniil, I have several quick comments. The indent in the hotspot c/c++ files has to be 2, not 4. https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/src/hotspot/share/runtime/threadSMR.cpp.frames.html 614 JavaThread* ThreadsList::find_JavaThread_from_java_tid(jlong java_tid) const { 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); 616 if (java_thread == NULL && java_tid == PMIMORDIAL_JAVA_TID) { 617 // ThreadsSMRSupport::add_thread() is not called for the primordial 618 // thread. Thus, we find this thread with a linear search and add it 619 // to the thread table. 620 for (uint i = 0; i < length(); i++) { 621 JavaThread* thread = thread_at(i); 622 if (is_valid_java_thread(java_tid,thread)) { 623 ThreadTable::add_thread(java_tid, thread); 624 return thread; 625 } 626 } 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { 628 return java_thread; 629 } 630 return NULL; 631 } 632 bool ThreadsList::is_valid_java_thread(jlong java_tid, JavaThread* java_thread) { 633 oop tobj = java_thread->threadObj(); 634 // Ignore the thread if it hasn't run yet, has exited 635 // or is starting to exit. 636 return (tobj != NULL && !java_thread->is_exiting() && 637 java_tid == java_lang_Thread::thread_id(tobj)); 638 } 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); I'd suggest to rename find_thread() to find_thread_by_tid(). A space is missed after the comma: ? 622 if (is_valid_java_thread(java_tid,thread)) { An empty line is needed before L632. The name 'is_valid_java_thread' looks wrong (or confusing) to me. Something like 'is_alive_java_thread_with_tid()' would be better. It'd better to list parameters in the opposite order. The call to is_valid_java_thread() is confusing: ?? 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { Why would the call ThreadTable::find_thread(java_tid) return a JavaThread with an unmatched java_tid? ? Thanks, Serguei On 6/28/19, 9:40 PM, "David Holmes" wrote: Hi Daniil, The definition and use of this hashtable (yet another hashtable implementation!) will need careful examination. We have to be concerned about the cost of maintaining it when it may never even be queried. You would need to look at footprint cost and performance impact. Unfortunately I'm just about to board a plane and will be out for the next few days. I will try to look at this asap next week, but we will need a lot more data on it. Thanks, David On 6/28/19 3:31 PM, Daniil Titov wrote: Please review the change that improves performance of ThreadMXBean MXBean methods returning the information for specific threads. The change introduces the thread table that uses ConcurrentHashTable to store one-to-one the mapping between the thread ids and JavaThread objects and replaces the linear search over the thread list in ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the lookup in the thread table. Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 Thanks! Best regards, Daniil From gil at azul.com Sun Jun 30 07:20:21 2019 From: gil at azul.com (Gil Tene) Date: Sun, 30 Jun 2019 07:20:21 +0000 Subject: JFR thread sampling mechanism Message-ID: I would like to discuss a potential improvement to the JFR thread sampling mechanism, and would like to see if the change we'd propose has already been considered in the past. I believe that the current thread sampling mechanism (mostly via hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp) can be summarized as: A control thread wakes up periodically (e.g. 100 times per second) and in each period chooses a number (e.g. 5) threads to sample (by rotating through the overall list of threads) only if they are "in java", and a number (e.g. 1) threads (by separately rotating through the overall list of threads) to sample "only if it is in native". For each thread targeted to sample, the control thread suspends the target thread (e.g. for linux this is done by preparing a suspend request a sending a SIGUSR2 to make the thread deal with it), takes a stacktrace of the suspended thread, adds the stacktrace to JfrStackTraceRepository, and resumes the thread (e.g. on linux resumption involves setting up a resume request and again sending a SIGUSR2 to the thread to get it to handle it and resume). We've been contemplating a change to make thread sampling use Posix timers instead, such that each thread would use a separate timer, and threads would receive signals based on their CPU consumption (the timer, e.g. created with timer_create(2), would be clocked by the thread CPU time of their associated threads, and signal their threads when that CPU time reaches a level [of e.g. 10 msec]). The signal handler will then perform the stacktrace sampling locally on the thread, and deliver the stacktrace to JfrStackTraceRepository (either directly or by enqueing through an intermediary). There are multiple potential benefits that may arise from switching to such a scheme, including significant reduction of sampling cost, improvement of density and focus of samples (fewer lost samples, ensuring that enough activity in a given thread will end up leading to a sample for that thread, etc.), and, potentially, an ability to (with additional changes) better account for time spent "outside of java" in e.g. native and runtime code. Has this (using thread-cpu-time-based posix timer sampling) been considered before? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From david.holmes at oracle.com Sun Jun 30 07:28:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 30 Jun 2019 17:28:59 +1000 Subject: JFR thread sampling mechanism In-Reply-To: References: Message-ID: Hi Gil, Redirecting to the hotspot-jfr-dev alias. Cheers, David On 30/06/2019 5:20 pm, Gil Tene wrote: > I would like to discuss a potential improvement to the JFR thread > sampling mechanism, and would like to see if the change we'd > propose has already been considered in the past. > > I believe that the current thread sampling mechanism (mostly via > hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp) can be > summarized as: A control thread wakes up periodically (e.g. 100 > times per second) and in each period chooses a number (e.g. 5) > threads to sample (by rotating through the overall list of threads) > only if they are "in java", and a number (e.g. 1) threads (by > separately rotating through the overall list of threads) to sample > "only if it is in native". For each thread targeted to sample, the > control thread suspends the target thread (e.g. for linux this is > done by preparing a suspend request a sending a SIGUSR2 to > make the thread deal with it), takes a stacktrace of the suspended > thread, adds the stacktrace to JfrStackTraceRepository, and > resumes the thread (e.g. on linux resumption involves setting up > a resume request and again sending a SIGUSR2 to the thread to > get it to handle it and resume). > > We've been contemplating a change to make thread sampling use > Posix timers instead, such that each thread would use a separate > timer, and threads would receive signals based on their CPU > consumption (the timer, e.g. created with timer_create(2), would > be clocked by the thread CPU time of their associated threads, > and signal their threads when that CPU time reaches a level > [of e.g. 10 msec]). The signal handler will then perform the > stacktrace sampling locally on the thread, and deliver the > stacktrace to JfrStackTraceRepository (either directly or by > enqueing through an intermediary). > > There are multiple potential benefits that may arise from switching > to such a scheme, including significant reduction of sampling cost, > improvement of density and focus of samples (fewer lost samples, > ensuring that enough activity in a given thread will end up leading > to a sample for that thread, etc.), and, potentially, an ability to > (with additional changes) better account for time spent "outside > of java" in e.g. native and runtime code. > > Has this (using thread-cpu-time-based posix timer sampling) been > considered before? > From kirk.pepperdine at gmail.com Sun Jun 30 22:08:18 2019 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 1 Jul 2019 00:08:18 +0200 Subject: JFR thread sampling mechanism In-Reply-To: References: Message-ID: <2E7CA8A6-ACBA-4AFD-80EF-C278F8A239B4@gmail.com> Hi Gil, I would support an improvement in sampling as there is an obvious bias which allows me to write benchmarks where JFR completely misses things it should find. That said, I?m not sure that waking a thread up every 10ms is a great idea as it is very disruptive to Linux thread scheduling. I?d very much like to experiment with lower sampling rates. Kind regards, Kirk > On Jun 30, 2019, at 9:20 AM, Gil Tene wrote: > > I would like to discuss a potential improvement to the JFR thread > sampling mechanism, and would like to see if the change we'd > propose has already been considered in the past. > > I believe that the current thread sampling mechanism (mostly via > hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp) can be > summarized as: A control thread wakes up periodically (e.g. 100 > times per second) and in each period chooses a number (e.g. 5) > threads to sample (by rotating through the overall list of threads) > only if they are "in java", and a number (e.g. 1) threads (by > separately rotating through the overall list of threads) to sample > "only if it is in native". For each thread targeted to sample, the > control thread suspends the target thread (e.g. for linux this is > done by preparing a suspend request a sending a SIGUSR2 to > make the thread deal with it), takes a stacktrace of the suspended > thread, adds the stacktrace to JfrStackTraceRepository, and > resumes the thread (e.g. on linux resumption involves setting up > a resume request and again sending a SIGUSR2 to the thread to > get it to handle it and resume). > > We've been contemplating a change to make thread sampling use > Posix timers instead, such that each thread would use a separate > timer, and threads would receive signals based on their CPU > consumption (the timer, e.g. created with timer_create(2), would > be clocked by the thread CPU time of their associated threads, > and signal their threads when that CPU time reaches a level > [of e.g. 10 msec]). The signal handler will then perform the > stacktrace sampling locally on the thread, and deliver the > stacktrace to JfrStackTraceRepository (either directly or by > enqueing through an intermediary). > > There are multiple potential benefits that may arise from switching > to such a scheme, including significant reduction of sampling cost, > improvement of density and focus of samples (fewer lost samples, > ensuring that enough activity in a given thread will end up leading > to a sample for that thread, etc.), and, potentially, an ability to > (with additional changes) better account for time spent "outside > of java" in e.g. native and runtime code. > > Has this (using thread-cpu-time-based posix timer sampling) been > considered before? >
JDI Type Signatures