From sharath.ballal at oracle.com Mon Jan 1 09:32:51 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 1 Jan 2018 01:32:51 -0800 (PST) Subject: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java fails in OpenJDK build In-Reply-To: References: Message-ID: <54e88b0c-8a65-4ae9-8fdc-088e10c540c3@default> Thanks for the review David. Could I have another review pls ? Thanks, Sharath -----Original Message----- From: David Holmes Sent: Friday, December 29, 2017 6:08 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java fails in OpenJDK build Looks good. Thanks, David On 28/12/2017 2:24 PM, Sharath Ballal wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193506 > > Webrev: http://cr.openjdk.java.net/~sballal/8193506/webrev.00/ > > I tested the changes in an open only workspace.? Also the test ran > successfully in JPRT and Mach5. > > Thanks, > > Sharath > From sharath.ballal at oracle.com Mon Jan 1 09:33:00 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 1 Jan 2018 01:33:00 -0800 (PST) Subject: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output In-Reply-To: <17f1071d-9110-e559-4aad-986f85364f9e@oracle.com> References: <25f0e0eb-fa15-430e-a2a4-c293cf441f94@default> <60cbf7cd-31f3-4d21-b357-c9d33488ec30@default> <17f1071d-9110-e559-4aad-986f85364f9e@oracle.com> Message-ID: Thanks for the review David. Could I have another review pls ? Thanks, Sharath -----Original Message----- From: David Holmes Sent: Friday, December 29, 2017 6:10 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output Seems reasonable. Thanks, David On 28/12/2017 3:09 PM, Sharath Ballal wrote: > (Resending as I got a failure notice) > > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194058 > > Webrev: http://cr.openjdk.java.net/~sballal/8194058/webrev.00/ > > Test ran successfully in JPRT and Mach5. > > Thanks, > > Sharath > From christoph.langer at sap.com Tue Jan 2 06:41:04 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Jan 2018 06:41:04 +0000 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> Message-ID: Hi Egor, David and Serguei, I had a look at this, too. I would think this really calls out for a ?public default int compareTo(Location other) {?}? in Location.java which uses the implementation out of LocationImpl.java. That way, all the suggested improvements for MirrorImpl.java can be done as well. And other implementers of Location, such as IntelliJ?s GeneratedLocation.java, would still build and won?t be necessarily wrong but could probably gradually remove their compareTo methods. As for checking for the same VM within Location comparison, e.g. by using the equals() method, I guess this can be added. At least it should not add a notable cost. But I suggest to do it with a separate change, in case it turns out to be not a good idea and one needs to revert it. @Egor: Would you mind to create an updated Webrev with an interface default method? Best regards Christoph From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Egor Ushakov Sent: Montag, 25. Dezember 2017 12:30 To: serguei.spitsyn at oracle.com; David Holmes ; serviceability-dev at openjdk.java.net Subject: Re: RFR: cleanup - removed unneeded casts in jdi Thanks for your comments! I'll try to provide more details: We have our own Location implementaion in IDEA code: GeneratedLocation.java which is not intended to be used inside the jdi, but mostly to mock Location in our own APIs like PositionManager.java Unfortunately some implementations keep the provided Location objects (both LocationImpl and ours) in collections (maybe sorted) so we have to prevent cast exceptions from compareTo somehow. Hope it helps. Egor On 24-Dec-17 03:32, serguei.spitsyn at oracle.com wrote: Hi David, Thank you for the explanations! I've got your points. On 12/23/17 15:32, David Holmes wrote: Hi Serguei, On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com wrote: Hi Egor and David, Egor, The fix looks good in general. I've filed bug: https://bugs.openjdk.java.net/browse/JDK-8194143 remove unneeded casts in LocationImpl and MirrorImpl classes On 12/22/17 13:06, David Holmes wrote: Hi Egor, On 23/12/2017 1:32 AM, Egor Ushakov wrote: Hi all, could you please review and sponsor this small cleanup removing unneeded casts in jdi LocationImpl and MirrorImpl. They were preventing creating custom Location and Mirror implementations used for tests and IDEA debugger impl. http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java ! public int compareTo(Location object) { - LocationImpl other = (LocationImpl)object; The existing code is somewhat suspect as the Location interface implements Comparable but it does not specify what it means to compare two Locations! That's a bug in itself. Not sure, if it is really needed as it is abstract. We could say: An implementation of the Location is expected to specify it. That makes it impossible to compare different implementations of the Location interface. The functionality has to be specified by the interface. We probably never needed to compare them before. But such comparison can be needed for an IDE that has a deal with different JDI implementations. LocationImpl has decided how to compare two LocaltionImp's (but doesn't even check they are in the same VirtualMachine!). Nice catch! Interesting... Should comparing of locations from different mirrors be a no-op? Not sure if it would be right to throw a VMMismatchException in such cases. Not sure - without knowing why we need to compare Locations it's hard to say. Ok. Can we generalize that to accommodate other Location implementations?Your change allows for this to happen, but it will only work as expected if the other Location implementations use the same comparison basis as LocationImpl - which is unspecified. It is not clear, what you mean here. What are the other Location implementations? The ones that Egor is implementing and the reason for this bug report. It is not clear to me why do they need their own Location implementation. A JDI implementation normally has one base implementation of the Location. What would be a need to have multiple? Egor indicated it was for use in testing and the IDEA debugger. It's apparent they have their own implementation of Location, but these instances have to interact with the default LocationImpl implementations - else this bug report would not be needed. Will need to look at it more closely after NY. I'm going to vacation in a couple of hours until the Jan 3-rd. Will probably have a limited internet access there. I wish you, guys, happy Xmas and New Year and nice Holidays! Thanks, Serguei Cheers, David And different JDI implementations are not supposed to interact with each other, are they? src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java Change looks good. It would also seem that now this change is made that this: 37 protected VirtualMachineImpl vm; 38 39 MirrorImpl(VirtualMachine aVm) { 40 super(); 41 42 // Yes, its a bit of a hack. But by doing it this 43 // way, this is the only place we have to change 44 // typing to substitute a new impl. 45 vm = (VirtualMachineImpl)aVm; might reduce to: 37 protected VirtualMachine vm; 38 39 MirrorImpl(VirtualMachine aVm) { 40 super(); 41 vm = aVm; if we no longer depend on it being VirtualMachineImpl ... and neither do subclasses. Good suggestion. Thanks, Serguei David ----- I do not have rights to create JDK bug report directly, please create it if it is needed for the procedure. Thanks! -- 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 Tue Jan 2 07:31:06 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Jan 2018 17:31:06 +1000 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> Message-ID: Hi Christoph, On 2/01/2018 4:41 PM, Langer, Christoph wrote: > Hi Egor, David and Serguei, > > I had a look at this, too. I would think this really calls out for a > ?public default int compareTo(Location other) {?}? in Location.java I think this could run into the "overloads instead of overrides" problem that Brian describes here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050060.html ... unsure. But this would need a CSR request any way so hopefully any issues with doing this would be caught there. I'm very wary of adding default methods, though this may be such a little used interface that it's not really an issue. Cheers, David > which uses the implementation out of LocationImpl.java. That way, all > the suggested improvements for MirrorImpl.java can be done as well. And > other implementers of Location, such as IntelliJ?s > GeneratedLocation.java, would still build and won?t be necessarily wrong > but could probably gradually remove their compareTo methods. > > As for checking for the same VM within Location comparison, e.g. by > using the equals() method, I guess this can be added. At least it should > not add a notable cost. But I suggest to do it with a separate change, > in case it turns out to be not a good idea and one needs to revert it. > > @Egor: Would you mind to create an updated Webrev with an interface > default method? > > Best regards > > Christoph > > *From:*serviceability-dev > [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of *Egor > Ushakov > *Sent:* Montag, 25. Dezember 2017 12:30 > *To:* serguei.spitsyn at oracle.com; David Holmes > ; serviceability-dev at openjdk.java.net > *Subject:* Re: RFR: cleanup - removed unneeded casts in jdi > > Thanks for your comments! > > I'll try to provide more details: > We have our own Location implementaion in IDEA code: > GeneratedLocation.java > > which is not intended to be used inside the jdi, but mostly to mock > Location in our own APIs like PositionManager.java > > Unfortunately some implementations keep the provided Location objects > (both LocationImpl and ours) in collections (maybe sorted) so we have to > prevent cast exceptions from compareTo somehow. > Hope it helps. > > Egor > > On 24-Dec-17 03:32, serguei.spitsyn at oracle.com > wrote: > > Hi David, > > Thank you for the explanations! > I've got your points. > > > On 12/23/17 15:32, David Holmes wrote: > > Hi Serguei, > > On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com > wrote: > > Hi Egor and David, > > > Egor, > > The fix looks good in general. > I've filed bug: > https://bugs.openjdk.java.net/browse/JDK-8194143 > ???? remove unneeded casts in LocationImpl and MirrorImpl > classes > > > On 12/22/17 13:06, David Holmes wrote: > > Hi Egor, > > On 23/12/2017 1:32 AM, Egor Ushakov wrote: > > Hi all, > > could you please review and sponsor this small > cleanup removing unneeded casts in jdi LocationImpl > and MirrorImpl. > They were preventing creating custom Location and > Mirror implementations used for tests and IDEA > debugger impl. > http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ > > > src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java > > > !???? public int compareTo(Location object) { > -??????? LocationImpl other = (LocationImpl)object; > > The existing code is somewhat suspect as the Location > interface implements Comparable but it does not specify > what it means to compare two Locations! That's a bug in > itself. > > > Not sure, if it is really needed as it is abstract. > We could say: An implementation of the Location is expected > to specify it. > > > That makes it impossible to compare different implementations of > the Location interface. The functionality has to be specified by > the interface. > > > We probably never needed to compare them before. > But such comparison can be needed for an IDE that has a deal with > different JDI implementations. > > > > LocationImpl has decided how to compare two > LocaltionImp's (but doesn't even check they are in the > same VirtualMachine!). > > > Nice catch! > Interesting... > Should comparing of locations from different mirrors be a > no-op? > Not sure if it would be right to throw a VMMismatchException > in such cases. > > > Not sure - without knowing why we need to compare Locations it's > hard to say. > > > Ok. > > > > Can we generalize that to accommodate other Location > implementations?Your change allows for this to happen, > but it will only work as expected if the other Location > implementations use the same comparison basis as > LocationImpl - which is unspecified. > > > It is not clear, what you mean here. > What are the other Location implementations? > > > The ones that Egor is implementing and the reason for this bug > report. > > > It is not clear to me why do they need their own Location > implementation. > > > > A JDI implementation normally has one base implementation of > the Location. > What would be a need to have multiple? > > > Egor indicated it was for use in testing and the IDEA debugger. > It's apparent they have their own implementation of Location, > but these instances have to interact with the default > LocationImpl implementations - else this bug report would not be > needed. > > > Will need to look at it more closely after NY. > I'm going to vacation in a couple of hours until the Jan 3-rd. > Will probably have a limited internet access there. > > I wish you, guys, happy Xmas and New Year and nice Holidays! > > Thanks, > Serguei > > > > > Cheers, > David > > > And different JDI implementations are not supposed to > interact with each other, are they? > > > > src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java > > Change looks good. It would also seem that now this > change is made that this: > > ? 37???? protected VirtualMachineImpl vm; > ? 38 > ? 39???? MirrorImpl(VirtualMachine aVm) { > ? 40???????? super(); > ? 41 > ? 42???????? // Yes, its a bit of a hack. But by doing > it this > ? 43???????? // way, this is the only place we have to > change > ? 44???????? // typing to substitute a new impl. > ? 45???????? vm = (VirtualMachineImpl)aVm; > > might reduce to: > > ? 37???? protected VirtualMachine vm; > ? 38 > ? 39???? MirrorImpl(VirtualMachine aVm) { > ? 40???????? super(); > ? 41???????? vm = aVm; > > if we no longer depend on it being VirtualMachineImpl > ... and neither do subclasses. > > > Good suggestion. > > > Thanks, > Serguei > > > > David > ----- > > > I do not have rights to create JDK bug report > directly, please create it if it is needed for the > procedure. > > Thanks! > > > > -- > > Egor Ushakov > > Software Developer > > JetBrains > > http://www.jetbrains.com > > The Drive to Develop > From christoph.langer at sap.com Tue Jan 2 08:21:25 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Jan 2018 08:21:25 +0000 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> Message-ID: <85e0911a375147feb43eb499db0442b6@sap.com> Hi David, thanks for pointing this out. I see what you mean. However, you were the one who brought up the point that rather the Location interface should specify the means to compare two Locations :) And that would be an interface default method - or would there be another way? I guess, as there are no generics involved, the overloading instead of overriding thing should at least be more obvious for other implementers of the Location interface. But, for sure, I'm leaving the decision whether the default interface is the right thing here or not to better language and jdi experts than I am. Egor's original proposal should work well, too, and is definitely less obtrusive. BTW: your suggested change in MirrorImpl to go from "protected VirtualMachineImpl vm;" to "protected VirtualMachine vm;" would not really work out as VirtualMachineImpl extends MirrorImpl and in there VirtualMachineImpl is definitely needed. It's really a bit weird... Best regards Christoph -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 2. Januar 2018 08:31 To: Langer, Christoph ; Egor Ushakov ; serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net Subject: Re: RFR: cleanup - removed unneeded casts in jdi Hi Christoph, On 2/01/2018 4:41 PM, Langer, Christoph wrote: > Hi Egor, David and Serguei, > > I had a look at this, too. I would think this really calls out for a > ?public default int compareTo(Location other) {?}? in Location.java I think this could run into the "overloads instead of overrides" problem that Brian describes here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050060.html ... unsure. But this would need a CSR request any way so hopefully any issues with doing this would be caught there. I'm very wary of adding default methods, though this may be such a little used interface that it's not really an issue. Cheers, David > which uses the implementation out of LocationImpl.java. That way, all > the suggested improvements for MirrorImpl.java can be done as well. And > other implementers of Location, such as IntelliJ?s > GeneratedLocation.java, would still build and won?t be necessarily wrong > but could probably gradually remove their compareTo methods. > > As for checking for the same VM within Location comparison, e.g. by > using the equals() method, I guess this can be added. At least it should > not add a notable cost. But I suggest to do it with a separate change, > in case it turns out to be not a good idea and one needs to revert it. > > @Egor: Would you mind to create an updated Webrev with an interface > default method? > > Best regards > > Christoph > > *From:*serviceability-dev > [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of *Egor > Ushakov > *Sent:* Montag, 25. Dezember 2017 12:30 > *To:* serguei.spitsyn at oracle.com; David Holmes > ; serviceability-dev at openjdk.java.net > *Subject:* Re: RFR: cleanup - removed unneeded casts in jdi > > Thanks for your comments! > > I'll try to provide more details: > We have our own Location implementaion in IDEA code: > GeneratedLocation.java > > which is not intended to be used inside the jdi, but mostly to mock > Location in our own APIs like PositionManager.java > > Unfortunately some implementations keep the provided Location objects > (both LocationImpl and ours) in collections (maybe sorted) so we have to > prevent cast exceptions from compareTo somehow. > Hope it helps. > > Egor > > On 24-Dec-17 03:32, serguei.spitsyn at oracle.com > wrote: > > Hi David, > > Thank you for the explanations! > I've got your points. > > > On 12/23/17 15:32, David Holmes wrote: > > Hi Serguei, > > On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com > wrote: > > Hi Egor and David, > > > Egor, > > The fix looks good in general. > I've filed bug: > https://bugs.openjdk.java.net/browse/JDK-8194143 > ???? remove unneeded casts in LocationImpl and MirrorImpl > classes > > > On 12/22/17 13:06, David Holmes wrote: > > Hi Egor, > > On 23/12/2017 1:32 AM, Egor Ushakov wrote: > > Hi all, > > could you please review and sponsor this small > cleanup removing unneeded casts in jdi LocationImpl > and MirrorImpl. > They were preventing creating custom Location and > Mirror implementations used for tests and IDEA > debugger impl. > http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ > > > src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java > > > !???? public int compareTo(Location object) { > -??????? LocationImpl other = (LocationImpl)object; > > The existing code is somewhat suspect as the Location > interface implements Comparable but it does not specify > what it means to compare two Locations! That's a bug in > itself. > > > Not sure, if it is really needed as it is abstract. > We could say: An implementation of the Location is expected > to specify it. > > > That makes it impossible to compare different implementations of > the Location interface. The functionality has to be specified by > the interface. > > > We probably never needed to compare them before. > But such comparison can be needed for an IDE that has a deal with > different JDI implementations. > > > > LocationImpl has decided how to compare two > LocaltionImp's (but doesn't even check they are in the > same VirtualMachine!). > > > Nice catch! > Interesting... > Should comparing of locations from different mirrors be a > no-op? > Not sure if it would be right to throw a VMMismatchException > in such cases. > > > Not sure - without knowing why we need to compare Locations it's > hard to say. > > > Ok. > > > > Can we generalize that to accommodate other Location > implementations?Your change allows for this to happen, > but it will only work as expected if the other Location > implementations use the same comparison basis as > LocationImpl - which is unspecified. > > > It is not clear, what you mean here. > What are the other Location implementations? > > > The ones that Egor is implementing and the reason for this bug > report. > > > It is not clear to me why do they need their own Location > implementation. > > > > A JDI implementation normally has one base implementation of > the Location. > What would be a need to have multiple? > > > Egor indicated it was for use in testing and the IDEA debugger. > It's apparent they have their own implementation of Location, > but these instances have to interact with the default > LocationImpl implementations - else this bug report would not be > needed. > > > Will need to look at it more closely after NY. > I'm going to vacation in a couple of hours until the Jan 3-rd. > Will probably have a limited internet access there. > > I wish you, guys, happy Xmas and New Year and nice Holidays! > > Thanks, > Serguei > > > > > Cheers, > David > > > And different JDI implementations are not supposed to > interact with each other, are they? > > > > src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java > > Change looks good. It would also seem that now this > change is made that this: > > ? 37???? protected VirtualMachineImpl vm; > ? 38 > ? 39???? MirrorImpl(VirtualMachine aVm) { > ? 40???????? super(); > ? 41 > ? 42???????? // Yes, its a bit of a hack. But by doing > it this > ? 43???????? // way, this is the only place we have to > change > ? 44???????? // typing to substitute a new impl. > ? 45???????? vm = (VirtualMachineImpl)aVm; > > might reduce to: > > ? 37???? protected VirtualMachine vm; > ? 38 > ? 39???? MirrorImpl(VirtualMachine aVm) { > ? 40???????? super(); > ? 41???????? vm = aVm; > > if we no longer depend on it being VirtualMachineImpl > ... and neither do subclasses. > > > Good suggestion. > > > Thanks, > Serguei > > > > David > ----- > > > I do not have rights to create JDK bug report > directly, please create it if it is needed for the > procedure. > > Thanks! > > > > -- > > Egor Ushakov > > Software Developer > > JetBrains > > http://www.jetbrains.com > > The Drive to Develop > From david.holmes at oracle.com Tue Jan 2 09:17:24 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Jan 2018 19:17:24 +1000 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <85e0911a375147feb43eb499db0442b6@sap.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> <85e0911a375147feb43eb499db0442b6@sap.com> Message-ID: <0dda82e0-79e9-259f-b792-ab78d7d09178@oracle.com> On 2/01/2018 6:21 PM, Langer, Christoph wrote: > Hi David, > > thanks for pointing this out. I see what you mean. > > However, you were the one who brought up the point that rather the Location interface should specify the means to compare two Locations :) All I meant by that is that Location should _specify_ what it means to compare two Locations. Any interface (or class for that matter) that implements Comparable should provide an overriding specification for compareTo. > And that would be an interface default method - or would there be another way? I guess, as there are no generics involved, the overloading instead of overriding thing should at least be more obvious for other implementers of the Location interface. But, for sure, I'm leaving the decision whether the default interface is the right thing here or not to better language and jdi experts than I am. Egor's original proposal should work well, too, and is definitely less obtrusive. Yeah I'm going to punt on this one too. :) > BTW: your suggested change in MirrorImpl to go from "protected VirtualMachineImpl vm;" to "protected VirtualMachine vm;" would not really work out as VirtualMachineImpl extends MirrorImpl and in there VirtualMachineImpl is definitely needed. It's really a bit weird... Thanks for checking. Despite the use of interfaces and classes this stuff doesn't really seem to be that amenable to supporting alternative implementations of the interfaces. Cheers, David > Best regards > Christoph > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 2. Januar 2018 08:31 > To: Langer, Christoph ; Egor Ushakov ; serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net > Subject: Re: RFR: cleanup - removed unneeded casts in jdi > > Hi Christoph, > > On 2/01/2018 4:41 PM, Langer, Christoph wrote: >> Hi Egor, David and Serguei, >> >> I had a look at this, too. I would think this really calls out for a >> ?public default int compareTo(Location other) {?}? in Location.java > > I think this could run into the "overloads instead of overrides" problem > that Brian describes here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050060.html > > ... unsure. But this would need a CSR request any way so hopefully any > issues with doing this would be caught there. > > I'm very wary of adding default methods, though this may be such a > little used interface that it's not really an issue. > > Cheers, > David > >> which uses the implementation out of LocationImpl.java. That way, all >> the suggested improvements for MirrorImpl.java can be done as well. And >> other implementers of Location, such as IntelliJ?s >> GeneratedLocation.java, would still build and won?t be necessarily wrong >> but could probably gradually remove their compareTo methods. >> >> As for checking for the same VM within Location comparison, e.g. by >> using the equals() method, I guess this can be added. At least it should >> not add a notable cost. But I suggest to do it with a separate change, >> in case it turns out to be not a good idea and one needs to revert it. >> >> @Egor: Would you mind to create an updated Webrev with an interface >> default method? >> >> Best regards >> >> Christoph >> >> *From:*serviceability-dev >> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of *Egor >> Ushakov >> *Sent:* Montag, 25. Dezember 2017 12:30 >> *To:* serguei.spitsyn at oracle.com; David Holmes >> ; serviceability-dev at openjdk.java.net >> *Subject:* Re: RFR: cleanup - removed unneeded casts in jdi >> >> Thanks for your comments! >> >> I'll try to provide more details: >> We have our own Location implementaion in IDEA code: >> GeneratedLocation.java >> >> which is not intended to be used inside the jdi, but mostly to mock >> Location in our own APIs like PositionManager.java >> >> Unfortunately some implementations keep the provided Location objects >> (both LocationImpl and ours) in collections (maybe sorted) so we have to >> prevent cast exceptions from compareTo somehow. >> Hope it helps. >> >> Egor >> >> On 24-Dec-17 03:32, serguei.spitsyn at oracle.com >> wrote: >> >> Hi David, >> >> Thank you for the explanations! >> I've got your points. >> >> >> On 12/23/17 15:32, David Holmes wrote: >> >> Hi Serguei, >> >> On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com >> wrote: >> >> Hi Egor and David, >> >> >> Egor, >> >> The fix looks good in general. >> I've filed bug: >> https://bugs.openjdk.java.net/browse/JDK-8194143 >> ???? remove unneeded casts in LocationImpl and MirrorImpl >> classes >> >> >> On 12/22/17 13:06, David Holmes wrote: >> >> Hi Egor, >> >> On 23/12/2017 1:32 AM, Egor Ushakov wrote: >> >> Hi all, >> >> could you please review and sponsor this small >> cleanup removing unneeded casts in jdi LocationImpl >> and MirrorImpl. >> They were preventing creating custom Location and >> Mirror implementations used for tests and IDEA >> debugger impl. >> http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >> >> >> src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java >> >> >> !???? public int compareTo(Location object) { >> -??????? LocationImpl other = (LocationImpl)object; >> >> The existing code is somewhat suspect as the Location >> interface implements Comparable but it does not specify >> what it means to compare two Locations! That's a bug in >> itself. >> >> >> Not sure, if it is really needed as it is abstract. >> We could say: An implementation of the Location is expected >> to specify it. >> >> >> That makes it impossible to compare different implementations of >> the Location interface. The functionality has to be specified by >> the interface. >> >> >> We probably never needed to compare them before. >> But such comparison can be needed for an IDE that has a deal with >> different JDI implementations. >> >> >> >> LocationImpl has decided how to compare two >> LocaltionImp's (but doesn't even check they are in the >> same VirtualMachine!). >> >> >> Nice catch! >> Interesting... >> Should comparing of locations from different mirrors be a >> no-op? >> Not sure if it would be right to throw a VMMismatchException >> in such cases. >> >> >> Not sure - without knowing why we need to compare Locations it's >> hard to say. >> >> >> Ok. >> >> >> >> Can we generalize that to accommodate other Location >> implementations?Your change allows for this to happen, >> but it will only work as expected if the other Location >> implementations use the same comparison basis as >> LocationImpl - which is unspecified. >> >> >> It is not clear, what you mean here. >> What are the other Location implementations? >> >> >> The ones that Egor is implementing and the reason for this bug >> report. >> >> >> It is not clear to me why do they need their own Location >> implementation. >> >> >> >> A JDI implementation normally has one base implementation of >> the Location. >> What would be a need to have multiple? >> >> >> Egor indicated it was for use in testing and the IDEA debugger. >> It's apparent they have their own implementation of Location, >> but these instances have to interact with the default >> LocationImpl implementations - else this bug report would not be >> needed. >> >> >> Will need to look at it more closely after NY. >> I'm going to vacation in a couple of hours until the Jan 3-rd. >> Will probably have a limited internet access there. >> >> I wish you, guys, happy Xmas and New Year and nice Holidays! >> >> Thanks, >> Serguei >> >> >> >> >> Cheers, >> David >> >> >> And different JDI implementations are not supposed to >> interact with each other, are they? >> >> >> >> src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java >> >> Change looks good. It would also seem that now this >> change is made that this: >> >> ? 37???? protected VirtualMachineImpl vm; >> ? 38 >> ? 39???? MirrorImpl(VirtualMachine aVm) { >> ? 40???????? super(); >> ? 41 >> ? 42???????? // Yes, its a bit of a hack. But by doing >> it this >> ? 43???????? // way, this is the only place we have to >> change >> ? 44???????? // typing to substitute a new impl. >> ? 45???????? vm = (VirtualMachineImpl)aVm; >> >> might reduce to: >> >> ? 37???? protected VirtualMachine vm; >> ? 38 >> ? 39???? MirrorImpl(VirtualMachine aVm) { >> ? 40???????? super(); >> ? 41???????? vm = aVm; >> >> if we no longer depend on it being VirtualMachineImpl >> ... and neither do subclasses. >> >> >> Good suggestion. >> >> >> Thanks, >> Serguei >> >> >> >> David >> ----- >> >> >> I do not have rights to create JDK bug report >> directly, please create it if it is needed for the >> procedure. >> >> Thanks! >> >> >> >> -- >> >> Egor Ushakov >> >> Software Developer >> >> JetBrains >> >> http://www.jetbrains.com >> >> The Drive to Develop >> From Alan.Bateman at oracle.com Tue Jan 2 17:48:00 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Jan 2018 17:48:00 +0000 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> Message-ID: <8142ca87-32fd-10e4-c5df-b177cc9f6e13@oracle.com> On 22/12/2017 21:06, David Holmes wrote: > : > > The existing code is somewhat suspect as the Location interface > implements Comparable but it does not specify what it means to compare > two Locations! That's a bug in itself. LocationImpl has decided how to > compare two LocaltionImp's (but doesn't even check they are in the > same VirtualMachine!). Can we generalize that to accommodate other > Location implementations? Your change allows for this to happen, but > it will only work as expected if the other Location implementations > use the same comparison basis as LocationImpl - which is unspecified. I'm also wondering about the change to validateMirrors and this assertion in the Mirror API: "Any method on a Mirror that takes a Mirror as an parameter directly or indirectly (e.g., as a element in a List) will throw VMMismatchException if the mirrors are from different virtual machines." There is an assumption in the implementation that two Mirror objects to the same VM will be the same implementation type. -Alan From chris.plummer at oracle.com Tue Jan 2 17:52:49 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Jan 2018 09:52:49 -0800 Subject: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output In-Reply-To: References: <25f0e0eb-fa15-430e-a2a4-c293cf441f94@default> <60cbf7cd-31f3-4d21-b357-c9d33488ec30@default> <17f1071d-9110-e559-4aad-986f85364f9e@oracle.com> Message-ID: +1 Chris On 1/1/18 1:33 AM, Sharath Ballal wrote: > Thanks for the review David. > Could I have another review pls ? > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Friday, December 29, 2017 6:10 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output > > Seems reasonable. > > Thanks, > David > > On 28/12/2017 3:09 PM, Sharath Ballal wrote: >> (Resending as I got a failure notice) >> >> Hello, >> >> Requesting reviews for: >> >> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194058 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8194058/webrev.00/ >> >> Test ran successfully in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From chris.plummer at oracle.com Tue Jan 2 18:00:13 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Jan 2018 10:00:13 -0800 Subject: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java fails in OpenJDK build In-Reply-To: <54e88b0c-8a65-4ae9-8fdc-088e10c540c3@default> References: <54e88b0c-8a65-4ae9-8fdc-088e10c540c3@default> Message-ID: +1 Chris On 1/1/18 1:32 AM, Sharath Ballal wrote: > Thanks for the review David. > Could I have another review pls ? > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Friday, December 29, 2017 6:08 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java fails in OpenJDK build > > Looks good. > > Thanks, > David > > On 28/12/2017 2:24 PM, Sharath Ballal wrote: >> Hello, >> >> Requesting reviews for: >> >> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193506 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8193506/webrev.00/ >> >> I tested the changes in an open only workspace.? Also the test ran >> successfully in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From sharath.ballal at oracle.com Wed Jan 3 05:48:40 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 2 Jan 2018 21:48:40 -0800 (PST) Subject: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output In-Reply-To: References: <25f0e0eb-fa15-430e-a2a4-c293cf441f94@default> <60cbf7cd-31f3-4d21-b357-c9d33488ec30@default> <17f1071d-9110-e559-4aad-986f85364f9e@oracle.com> Message-ID: Thank You Chris. Thanks, Sharath -----Original Message----- From: Chris Plummer Sent: Tuesday, January 02, 2018 11:23 PM To: Sharath Ballal; David Holmes; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output +1 Chris On 1/1/18 1:33 AM, Sharath Ballal wrote: > Thanks for the review David. > Could I have another review pls ? > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Friday, December 29, 2017 6:10 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output > > Seems reasonable. > > Thanks, > David > > On 28/12/2017 3:09 PM, Sharath Ballal wrote: >> (Resending as I got a failure notice) >> >> Hello, >> >> Requesting reviews for: >> >> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194058 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8194058/webrev.00/ >> >> Test ran successfully in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From sharath.ballal at oracle.com Wed Jan 3 05:48:49 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 2 Jan 2018 21:48:49 -0800 (PST) Subject: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java fails in OpenJDK build In-Reply-To: References: <54e88b0c-8a65-4ae9-8fdc-088e10c540c3@default> Message-ID: <7e35b324-d15e-458c-80f4-ef81e26a0e08@default> Thank You Chris. Thanks, Sharath -----Original Message----- From: Chris Plummer Sent: Tuesday, January 02, 2018 11:30 PM To: Sharath Ballal; David Holmes; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java fails in OpenJDK build +1 Chris On 1/1/18 1:32 AM, Sharath Ballal wrote: > Thanks for the review David. > Could I have another review pls ? > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Friday, December 29, 2017 6:08 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java > fails in OpenJDK build > > Looks good. > > Thanks, > David > > On 28/12/2017 2:24 PM, Sharath Ballal wrote: >> Hello, >> >> Requesting reviews for: >> >> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193506 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8193506/webrev.00/ >> >> I tested the changes in an open only workspace. Also the test ran >> successfully in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From amit.sapre at oracle.com Wed Jan 3 12:24:13 2018 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 3 Jan 2018 04:24:13 -0800 (PST) Subject: RFR : JDK-8175542 - JMX: Not enough JDP packets received In-Reply-To: <2b05b6b7-e731-7bf0-83b9-cdb2a4252d84@oracle.com> References: <2b05b6b7-e731-7bf0-83b9-cdb2a4252d84@oracle.com> Message-ID: <892d6f86-fa15-4da4-9318-101d87253751@default> Thanks Harsha for the inputs. I made changes in this webrev : http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8175542/webrev.01/ Thanks, Amit From: Harsha Wardhana B Sent: Wednesday, December 13, 2017 5:32 PM To: serviceability-dev at openjdk.java.net Subject: Re: RFR : JDK-8175542 - JMX: Not enough JDP packets received Hi Amit, Increasing the timeout 'TIME_OUT_FACTOR' will increase both socket and test-case timeout. The test passed as can be seen from the log, but because of the race-condition: hasTestLivedLongEnough() checked before shouldContinue(), the test was declared failed because of time-out. One possible fix would be to change line 80 to, if (shouldContinue() && hasTestLivedLongEnough()) Thanks Harsha On Wednesday 13 December 2017 11:03 AM, Amit Sapre wrote: Hello, Please review the timeout fix for this bug. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8175542 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Easapre/webrev/2017/JDK-8175542/webrev.00/"http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8175542/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Jan 4 15:54:01 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 4 Jan 2018 10:54:01 -0500 Subject: RFR: 6640188: Methods com.sun.tools.attach.VirtualMachine.load... don't throw NullPointerException Message-ID: <8ff58da4-5e03-7e8a-9415-cfcb67c5e51c@oracle.com> Here's a simple fix to add explicit checks for the loadAgentXXX methods to ensure NPE is thrown when null arguments are passed. Several other management methods have similar provider not null checks, they just were not present for agent path and library methods. This should remove the spec ambiguity with AgentLoadException which was being thrown. ? Issue: https://bugs.openjdk.java.net/browse/JDK-6640188 ? Webrev: http://cr.openjdk.java.net/~gadams/6640188/ From serguei.spitsyn at oracle.com Thu Jan 4 20:13:53 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 4 Jan 2018 12:13:53 -0800 Subject: RFR: 6640188: Methods com.sun.tools.attach.VirtualMachine.load... don't throw NullPointerException In-Reply-To: <8ff58da4-5e03-7e8a-9415-cfcb67c5e51c@oracle.com> References: <8ff58da4-5e03-7e8a-9415-cfcb67c5e51c@oracle.com> Message-ID: <7836ad63-abae-15d0-f5c7-d9f1fc74f624@oracle.com> Hi Gary, The fix looks good. I agree, the other null checks are already covered in the VirtualMachine.java. Thanks, Serguei On 1/4/18 07:54, gary.adams at oracle.com wrote: > Here's a simple fix to add explicit checks for the loadAgentXXX > methods to > ensure NPE is thrown when null arguments are passed. Several other > management > methods have similar provider not null checks, they just were not > present for > agent path and library methods. This should remove the spec ambiguity > with > AgentLoadException which was being thrown. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-6640188 > ? Webrev: http://cr.openjdk.java.net/~gadams/6640188/ From jini.george at oracle.com Fri Jan 5 08:41:06 2018 From: jini.george at oracle.com (Jini George) Date: Fri, 5 Jan 2018 14:11:06 +0530 Subject: RFR: JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands Message-ID: Hello, I would like to request reviews for: Id: https://bugs.openjdk.java.net/browse/JDK-8193352 Webrev: http://cr.openjdk.java.net/~jgeorge/8193352/webrev.00/index.html This is a test case for the clhsdb 'thread' and 'threads' commands. This also includes a minor fix for the incorrect printing of the text 'Couldn't find thread -a' when the 'thread -a' command is specified. Thanks, Jini. From serguei.spitsyn at oracle.com Fri Jan 5 19:56:38 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 5 Jan 2018 11:56:38 -0800 Subject: RFR: JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands In-Reply-To: References: Message-ID: Hi Jini, This looks good to me. Thanks, Serguei On 1/5/18 00:41, Jini George wrote: > Hello, > > I would like to request reviews for: > > Id: https://bugs.openjdk.java.net/browse/JDK-8193352 > Webrev: http://cr.openjdk.java.net/~jgeorge/8193352/webrev.00/index.html > > This is a test case for the clhsdb 'thread' and 'threads' commands. > This also includes a minor fix for the incorrect printing of the text > 'Couldn't find thread -a' when the 'thread -a' command is specified. > > Thanks, > Jini. From sharath.ballal at oracle.com Mon Jan 8 05:30:05 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 7 Jan 2018 21:30:05 -0800 (PST) Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> Message-ID: Thanks David. I have made the changes. New webrev is http://cr.openjdk.java.net/~sballal/8194067/webrev.01/ Thanks, Sharath -----Original Message----- From: David Holmes Sent: Friday, December 29, 2017 6:13 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings When I reported this one I thought about how to best fix it. What you propose is a simple fix, but may potentially allow other errors to go unnoticed. I was wondering whether there was a simple way to filter the stderr content to exclude VM Warnings, but still check for other unexpected content? Thanks, David On 28/12/2017 3:29 PM, Sharath Ballal wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 > > Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ > > The tests ran successfully in JPRT and Mach5. > > Thanks, > > Sharath > From jini.george at oracle.com Mon Jan 8 06:00:32 2018 From: jini.george at oracle.com (Jini George) Date: Mon, 8 Jan 2018 11:30:32 +0530 Subject: RFR: JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands In-Reply-To: References: Message-ID: <9316a882-a7a1-0e70-4db1-e55d28931ea2@oracle.com> Thanks much, Serguei. Could I please get one more review for this ? Thanks, Jini. On 1/6/2018 1:26 AM, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > This looks good to me. > > Thanks, > Serguei > > > On 1/5/18 00:41, Jini George wrote: >> Hello, >> >> I would like to request reviews for: >> >> Id: https://bugs.openjdk.java.net/browse/JDK-8193352 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8193352/webrev.00/index.html >> >> This is a test case for the clhsdb 'thread' and 'threads' commands. >> This also includes a minor fix for the incorrect printing of the text >> 'Couldn't find thread -a' when the 'thread -a' command is specified. >> >> Thanks, >> Jini. > From david.holmes at oracle.com Mon Jan 8 11:40:52 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Jan 2018 21:40:52 +1000 Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> Message-ID: <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> Hi Sharath, On 8/01/2018 3:30 PM, Sharath Ballal wrote: > Thanks David. I have made the changes. > New webrev is http://cr.openjdk.java.net/~sballal/8194067/webrev.01/ That looks quite good - only issue is that the regex won't work for an OpenJDK build as it produces: OpenJDK 64-Bit Server VM warning: ... rather than Java HotSpot(TM) 64-Bit Server VM warning: ... Maybe "VM warning:" will suffice for the match? Thanks, David ----- > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Friday, December 29, 2017 6:13 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings > > When I reported this one I thought about how to best fix it. What you propose is a simple fix, but may potentially allow other errors to go unnoticed. I was wondering whether there was a simple way to filter the stderr content to exclude VM Warnings, but still check for other unexpected content? > > Thanks, > David > > On 28/12/2017 3:29 PM, Sharath Ballal wrote: >> Hello, >> >> Requesting reviews for: >> >> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ >> >> The tests ran successfully in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From alexey.menkov at oracle.com Mon Jan 8 18:59:02 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 8 Jan 2018 10:59:02 -0800 Subject: DOC RFR: 8187448: 360 doc issues in jdwp-protocol.html In-Reply-To: References: Message-ID: <3b10ca7e-23a9-6de1-dd2b-2124bdf7d661@oracle.com> Hi Daniil, AbstractTypeListNode.java: - writer.println("
"); + writer.println("
"); border, cellpadding, cellspacing, width are also unsupported in HTML5 It's unclear why tidy doesn't report them. Could you try to run W3 validator (https://validator.w3.org/) --alex On 12/22/2017 09:39, Daniil Titov wrote: > Please review a fix for the doc bug. > > The fix does the following: > 1. Removes empty
    elements. > 2. Adds an outer
      element to the index section . > 3. Removes obsolete in HTML5 ?summary? attribute in
elements. > 4. Removes empty

elements. > 5. Replaces not supported in HTML5 ?bgcolor? attribute for element with ?style="background-color?? attribute. > 6. Removes

element in ConstantSetNode (there is no outer
element in this case) > 7. Adds required by accessibility audits ?lang? attribute for element. > > Testing: > 1. Built the docs target and looked at the resulting jdwp-protocol.html. > 2. Tested that is passes validation with tidy > 3. Tested it passes accessibility audits with Accessibility Developer Tool (Chrome) > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 > Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.01 > > Thanks, > Daniil > > > > > > From serguei.spitsyn at oracle.com Mon Jan 8 19:52:29 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Jan 2018 11:52:29 -0800 Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> Message-ID: <82f169d6-eba2-5753-46dc-4e05ce032c95@oracle.com> Hi Sharath, It looks good modulo David's comment. Thanks, Serguei On 1/8/18 03:40, David Holmes wrote: > Hi Sharath, > > On 8/01/2018 3:30 PM, Sharath Ballal wrote: >> Thanks David.? I have made the changes. >> New webrev is http://cr.openjdk.java.net/~sballal/8194067/webrev.01/ > > That looks quite good - only issue is that the regex won't work for an > OpenJDK build as it produces: > > OpenJDK 64-Bit Server VM warning: ... > > rather than > > Java HotSpot(TM) 64-Bit Server VM warning: ... > > Maybe "VM warning:" will suffice for the match? > > Thanks, > David > ----- > >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: David Holmes >> Sent: Friday, December 29, 2017 6:13 AM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* >> tests can't tolerate unrelated warnings >> >> When I reported this one I thought about how to best fix it. What you >> propose is a simple fix, but may potentially allow other errors to go >> unnoticed. I was wondering whether there was a simple way to filter >> the stderr content to exclude VM Warnings, but still check for other >> unexpected content? >> >> Thanks, >> David >> >> On 28/12/2017 3:29 PM, Sharath Ballal wrote: >>> Hello, >>> >>> Requesting reviews for: >>> >>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ >>> >>> The tests ran successfully in JPRT and Mach5. >>> >>> Thanks, >>> >>> Sharath >>> From daniil.x.titov at oracle.com Tue Jan 9 02:49:46 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 08 Jan 2018 18:49:46 -0800 Subject: DOC RFR: 8187448: 360 doc issues in jdwp-protocol.html In-Reply-To: <886258E2-19A4-4B3E-8E26-4F8E4C6866DF@oracle.com> References: <886258E2-19A4-4B3E-8E26-4F8E4C6866DF@oracle.com> Message-ID: Thank you, Alex! Please review a new version of the patch that fixes these W3 validator issues. In addition to the previous changes the fix does: 1. Replaces cellpadding, cellspacing, border and width attributes for table, td and th elements with internal CSS 2. Replaces elements with id attribute on the nearest container element. Testing: 1. Built the docs target and looked at the resulting jdwp-protocol.html. 2. Tested that it passes validation with tidy 3. Tested that it passes validation with W3 validator (https://validator.w3.org/) 4. Tested that it passes accessibility audits with Accessibility Developer Tool (Chrome) Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.02 New jdwp-protocol.html : http://cr.openjdk.java.net/~dtitov/8187448/doc/new/jdwp-protocol.html Old jdwp-protocol.html: http://cr.openjdk.java.net/~dtitov/8187448/doc/old/jdwp-protocol.html Best regards, Daniil On 1/8/18, 11:06 AM, "serviceability-dev on behalf of Alex Menkov" wrote: Hi Daniil, AbstractTypeListNode.java: - writer.println("
"); + writer.println("
"); border, cellpadding, cellspacing, width are also unsupported in HTML5 It's unclear why tidy doesn't report them. Could you try to run W3 validator (https://validator.w3.org/) --alex On 12/22/2017 09:39, Daniil Titov wrote: > Please review a fix for the doc bug. > > The fix does the following: > 1. Removes empty
    elements. > 2. Adds an outer
      element to the index section . > 3. Removes obsolete in HTML5 ?summary? attribute in
elements. > 4. Removes empty

elements. > 5. Replaces not supported in HTML5 ?bgcolor? attribute for element with ?style="background-color?? attribute. > 6. Removes

element in ConstantSetNode (there is no outer
element in this case) > 7. Adds required by accessibility audits ?lang? attribute for element. > > Testing: > 1. Built the docs target and looked at the resulting jdwp-protocol.html. > 2. Tested that is passes validation with tidy > 3. Tested it passes accessibility audits with Accessibility Developer Tool (Chrome) > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 > Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.01 > > Thanks, > Daniil > > > > > > From serguei.spitsyn at oracle.com Tue Jan 9 03:11:21 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Jan 2018 19:11:21 -0800 Subject: DOC RFR: 8187448: 360 doc issues in jdwp-protocol.html In-Reply-To: References: <886258E2-19A4-4B3E-8E26-4F8E4C6866DF@oracle.com> Message-ID: <5dd20267-084a-6e93-2871-029c4b6363f3@oracle.com> Hi Daniil, It looks good to me. Thank you for fixing these extra issues! Thanks, Serguei On 1/8/18 18:49, Daniil Titov wrote: > Thank you, Alex! > > Please review a new version of the patch that fixes these W3 validator issues. > > In addition to the previous changes the fix does: > 1. Replaces cellpadding, cellspacing, border and width attributes for table, td and th elements with internal CSS > 2. Replaces elements with id attribute on the nearest container element. > > Testing: > 1. Built the docs target and looked at the resulting jdwp-protocol.html. > 2. Tested that it passes validation with tidy > 3. Tested that it passes validation with W3 validator (https://validator.w3.org/) > 4. Tested that it passes accessibility audits with Accessibility Developer Tool (Chrome) > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 > Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.02 > New jdwp-protocol.html : http://cr.openjdk.java.net/~dtitov/8187448/doc/new/jdwp-protocol.html > Old jdwp-protocol.html: http://cr.openjdk.java.net/~dtitov/8187448/doc/old/jdwp-protocol.html > > > Best regards, > Daniil > > On 1/8/18, 11:06 AM, "serviceability-dev on behalf of Alex Menkov" wrote: > > Hi Daniil, > > AbstractTypeListNode.java: > > - writer.println("
cellspacing=0 width=\"90%\" summary=\"\">"); > + writer.println("
cellspacing=0 width=\"90%\">"); > > border, cellpadding, cellspacing, width are also unsupported in HTML5 > It's unclear why tidy doesn't report them. > Could you try to run W3 validator (https://validator.w3.org/) > > --alex > > > On 12/22/2017 09:39, Daniil Titov wrote: > > Please review a fix for the doc bug. > > > > The fix does the following: > > 1. Removes empty
    elements. > > 2. Adds an outer
      element to the index section . > > 3. Removes obsolete in HTML5 ?summary? attribute in
elements. > > 4. Removes empty

elements. > > 5. Replaces not supported in HTML5 ?bgcolor? attribute for element with ?style="background-color?? attribute. > > 6. Removes

element in ConstantSetNode (there is no outer
element in this case) > > 7. Adds required by accessibility audits ?lang? attribute for element. > > > > Testing: > > 1. Built the docs target and looked at the resulting jdwp-protocol.html. > > 2. Tested that is passes validation with tidy > > 3. Tested it passes accessibility audits with Accessibility Developer Tool (Chrome) > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 > > Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.01 > > > > Thanks, > > Daniil > > > > > > > > > > > > > > > > From jini.george at oracle.com Tue Jan 9 08:32:48 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 9 Jan 2018 14:02:48 +0530 Subject: RFR: JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands In-Reply-To: <9316a882-a7a1-0e70-4db1-e55d28931ea2@oracle.com> References: <9316a882-a7a1-0e70-4db1-e55d28931ea2@oracle.com> Message-ID: <9c324b8d-5efa-e1bb-451c-3877c3242440@oracle.com> Have an updated webrev with the copyright year modified to 2018. Thanks, Jini. On 1/8/2018 11:30 AM, Jini George wrote: > Thanks much, Serguei. Could I please get one more review for this ? > > Thanks, > Jini. > > On 1/6/2018 1:26 AM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> This looks good to me. >> >> Thanks, >> Serguei >> >> >> On 1/5/18 00:41, Jini George wrote: >>> Hello, >>> >>> I would like to request reviews for: >>> >>> Id: https://bugs.openjdk.java.net/browse/JDK-8193352 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8193352/webrev.00/index.html >>> >>> This is a test case for the clhsdb 'thread' and 'threads' commands. >>> This also includes a minor fix for the incorrect printing of the text >>> 'Couldn't find thread -a' when the 'thread -a' command is specified. >>> >>> Thanks, >>> Jini. >> From sharath.ballal at oracle.com Tue Jan 9 08:39:54 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 9 Jan 2018 00:39:54 -0800 (PST) Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> Message-ID: <656c8d0c-2b97-4a27-9793-775b6c4d724a@default> Thanks for the comments David. I have made the changes. Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.02/ Thanks, Sharath -----Original Message----- From: David Holmes Sent: Monday, January 08, 2018 5:11 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings Hi Sharath, On 8/01/2018 3:30 PM, Sharath Ballal wrote: > Thanks David. I have made the changes. > New webrev is http://cr.openjdk.java.net/~sballal/8194067/webrev.01/ That looks quite good - only issue is that the regex won't work for an OpenJDK build as it produces: OpenJDK 64-Bit Server VM warning: ... rather than Java HotSpot(TM) 64-Bit Server VM warning: ... Maybe "VM warning:" will suffice for the match? Thanks, David ----- > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Friday, December 29, 2017 6:13 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* > tests can't tolerate unrelated warnings > > When I reported this one I thought about how to best fix it. What you propose is a simple fix, but may potentially allow other errors to go unnoticed. I was wondering whether there was a simple way to filter the stderr content to exclude VM Warnings, but still check for other unexpected content? > > Thanks, > David > > On 28/12/2017 3:29 PM, Sharath Ballal wrote: >> Hello, >> >> Requesting reviews for: >> >> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ >> >> The tests ran successfully in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From sharath.ballal at oracle.com Tue Jan 9 08:42:37 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 9 Jan 2018 00:42:37 -0800 (PST) Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: <82f169d6-eba2-5753-46dc-4e05ce032c95@oracle.com> References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> <82f169d6-eba2-5753-46dc-4e05ce032c95@oracle.com> Message-ID: Thanks for the review Serguei. Thanks, Sharath -----Original Message----- From: Serguei Spitsyn Sent: Tuesday, January 09, 2018 1:22 AM To: David Holmes; Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings Hi Sharath, It looks good modulo David's comment. Thanks, Serguei On 1/8/18 03:40, David Holmes wrote: > Hi Sharath, > > On 8/01/2018 3:30 PM, Sharath Ballal wrote: >> Thanks David.? I have made the changes. >> New webrev is http://cr.openjdk.java.net/~sballal/8194067/webrev.01/ > > That looks quite good - only issue is that the regex won't work for an > OpenJDK build as it produces: > > OpenJDK 64-Bit Server VM warning: ... > > rather than > > Java HotSpot(TM) 64-Bit Server VM warning: ... > > Maybe "VM warning:" will suffice for the match? > > Thanks, > David > ----- > >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: David Holmes >> Sent: Friday, December 29, 2017 6:13 AM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* >> tests can't tolerate unrelated warnings >> >> When I reported this one I thought about how to best fix it. What you >> propose is a simple fix, but may potentially allow other errors to go >> unnoticed. I was wondering whether there was a simple way to filter >> the stderr content to exclude VM Warnings, but still check for other >> unexpected content? >> >> Thanks, >> David >> >> On 28/12/2017 3:29 PM, Sharath Ballal wrote: >>> Hello, >>> >>> Requesting reviews for: >>> >>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ >>> >>> The tests ran successfully in JPRT and Mach5. >>> >>> Thanks, >>> >>> Sharath >>> From david.holmes at oracle.com Tue Jan 9 09:18:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Jan 2018 19:18:01 +1000 Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: <656c8d0c-2b97-4a27-9793-775b6c4d724a@default> References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> <656c8d0c-2b97-4a27-9793-775b6c4d724a@default> Message-ID: <335b07cf-e3a4-6efb-018d-2a942252ab29@oracle.com> Looks good! Thanks, David On 9/01/2018 6:39 PM, Sharath Ballal wrote: > Thanks for the comments David. I have made the changes. > > Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.02/ > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Monday, January 08, 2018 5:11 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings > > Hi Sharath, > > On 8/01/2018 3:30 PM, Sharath Ballal wrote: >> Thanks David. I have made the changes. >> New webrev is http://cr.openjdk.java.net/~sballal/8194067/webrev.01/ > > That looks quite good - only issue is that the regex won't work for an OpenJDK build as it produces: > > OpenJDK 64-Bit Server VM warning: ... > > rather than > > Java HotSpot(TM) 64-Bit Server VM warning: ... > > Maybe "VM warning:" will suffice for the match? > > Thanks, > David > ----- > >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: David Holmes >> Sent: Friday, December 29, 2017 6:13 AM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* >> tests can't tolerate unrelated warnings >> >> When I reported this one I thought about how to best fix it. What you propose is a simple fix, but may potentially allow other errors to go unnoticed. I was wondering whether there was a simple way to filter the stderr content to exclude VM Warnings, but still check for other unexpected content? >> >> Thanks, >> David >> >> On 28/12/2017 3:29 PM, Sharath Ballal wrote: >>> Hello, >>> >>> Requesting reviews for: >>> >>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ >>> >>> The tests ran successfully in JPRT and Mach5. >>> >>> Thanks, >>> >>> Sharath >>> From sharath.ballal at oracle.com Tue Jan 9 09:18:59 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 9 Jan 2018 01:18:59 -0800 (PST) Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: <335b07cf-e3a4-6efb-018d-2a942252ab29@oracle.com> References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> <656c8d0c-2b97-4a27-9793-775b6c4d724a@default> <335b07cf-e3a4-6efb-018d-2a942252ab29@oracle.com> Message-ID: <8640f89c-c079-4eb9-bde6-6f3de05a3c12@default> Thanks David. Thanks, Sharath -----Original Message----- From: David Holmes Sent: Tuesday, January 09, 2018 2:48 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings Looks good! Thanks, David On 9/01/2018 6:39 PM, Sharath Ballal wrote: > Thanks for the comments David. I have made the changes. > > Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.02/ > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Monday, January 08, 2018 5:11 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* > tests can't tolerate unrelated warnings > > Hi Sharath, > > On 8/01/2018 3:30 PM, Sharath Ballal wrote: >> Thanks David. I have made the changes. >> New webrev is http://cr.openjdk.java.net/~sballal/8194067/webrev.01/ > > That looks quite good - only issue is that the regex won't work for an OpenJDK build as it produces: > > OpenJDK 64-Bit Server VM warning: ... > > rather than > > Java HotSpot(TM) 64-Bit Server VM warning: ... > > Maybe "VM warning:" will suffice for the match? > > Thanks, > David > ----- > >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: David Holmes >> Sent: Friday, December 29, 2017 6:13 AM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* >> tests can't tolerate unrelated warnings >> >> When I reported this one I thought about how to best fix it. What you propose is a simple fix, but may potentially allow other errors to go unnoticed. I was wondering whether there was a simple way to filter the stderr content to exclude VM Warnings, but still check for other unexpected content? >> >> Thanks, >> David >> >> On 28/12/2017 3:29 PM, Sharath Ballal wrote: >>> Hello, >>> >>> Requesting reviews for: >>> >>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ >>> >>> The tests ran successfully in JPRT and Mach5. >>> >>> Thanks, >>> >>> Sharath >>> From alexey.menkov at oracle.com Tue Jan 9 17:43:59 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 9 Jan 2018 09:43:59 -0800 Subject: DOC RFR: 8187448: 360 doc issues in jdwp-protocol.html In-Reply-To: <5dd20267-084a-6e93-2871-029c4b6363f3@oracle.com> References: <886258E2-19A4-4B3E-8E26-4F8E4C6866DF@oracle.com> <5dd20267-084a-6e93-2871-029c4b6363f3@oracle.com> Message-ID: <2268e300-2546-6892-1f11-877bdaa29095@oracle.com> +1 --alex On 01/08/2018 19:11, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > It looks good to me. > Thank you for fixing these extra issues! > > Thanks, > Serguei > > > On 1/8/18 18:49, Daniil Titov wrote: >> Thank you, Alex! >> >> Please review a new version of the patch that fixes these W3 validator >> issues. >> >> In addition to the previous changes the fix does: >> 1. Replaces cellpadding, cellspacing, border and width attributes for >> table, td and th elements with internal CSS >> 2. Replaces elements with id attribute on the nearest >> container element. >> Testing: >> ???? 1. Built the docs target and looked at the resulting >> jdwp-protocol.html. >> ???? 2. Tested that it passes validation with tidy >> ???? 3. Tested that it passes validation with W3 validator >> (https://validator.w3.org/) >> ???? 4. Tested that it passes accessibility audits with Accessibility >> Developer Tool (Chrome) >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 >> Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.02 >> New jdwp-protocol.html : >> http://cr.openjdk.java.net/~dtitov/8187448/doc/new/jdwp-protocol.html >> Old jdwp-protocol.html: >> http://cr.openjdk.java.net/~dtitov/8187448/doc/old/jdwp-protocol.html >> >> >> Best regards, >> Daniil >> >> On 1/8/18, 11:06 AM, "serviceability-dev on behalf of Alex Menkov" >> > alexey.menkov at oracle.com> wrote: >> >> ???? Hi Daniil, >> ???? AbstractTypeListNode.java: >> ???? -??????????? writer.println("
> ???? cellspacing=0 width=\"90%\" summary=\"\">"); >> ???? +??????????? writer.println("
> ???? cellspacing=0 width=\"90%\">"); >> ???? border, cellpadding, cellspacing, width are also unsupported in >> HTML5 >> ???? It's unclear why tidy doesn't report them. >> ???? Could you try to run W3 validator (https://validator.w3.org/) >> ???? --alex >> ???? On 12/22/2017 09:39, Daniil Titov wrote: >> ???? >????? Please review a fix for the doc bug. >> ???? > >> ???? >????? The fix does the following: >> ???? >????????? 1. Removes empty
    elements. >> ???? >????????? 2. Adds an outer
      element to the index section . >> ???? >????????? 3. Removes obsolete in HTML5 ?summary? attribute in >>
elements. >> ???? >????????? 4. Removes empty

elements. >> ???? >????????? 5. Replaces not supported in HTML5 ?bgcolor? attribute >> for element with ?style="background-color?? attribute. >> ???? >????????? 6. Removes

element in? ConstantSetNode? (there is >> no outer
element in this case) >> ???? >????????? 7. Adds required by accessibility audits ?lang? >> attribute for element. >> ???? > >> ???? >????? Testing: >> ???? >???????????? 1. Built the docs target and looked at the >> resulting jdwp-protocol.html. >> ???? >???????????? 2. Tested that is passes validation with tidy >> ???? >???????????? 3. Tested it passes accessibility audits with >> Accessibility Developer Tool (Chrome) >> ???? > >> ???? > >> ???? >????? Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 >> ???? >????? Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.01 >> ???? > >> ???? >????? Thanks, >> ???? >????? Daniil >> ???? > >> ???? > >> ???? > >> ???? > >> ???? > >> ???? > >> >> > From serguei.spitsyn at oracle.com Tue Jan 9 17:59:31 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Jan 2018 09:59:31 -0800 Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: <335b07cf-e3a4-6efb-018d-2a942252ab29@oracle.com> References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> <1feedf22-523f-194e-3b14-b2c00f58e419@oracle.com> <656c8d0c-2b97-4a27-9793-775b6c4d724a@default> <335b07cf-e3a4-6efb-018d-2a942252ab29@oracle.com> Message-ID: <15c74984-fdc2-bc0c-66ec-3fb7c0e04ac6@oracle.com> +1 Thanks, Serguei On 1/9/18 01:18, David Holmes wrote: > Looks good! > > Thanks, > David > > On 9/01/2018 6:39 PM, Sharath Ballal wrote: >> Thanks for the comments David.? I have made the changes. >> >> Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.02/ >> >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: David Holmes >> Sent: Monday, January 08, 2018 5:11 PM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* >> tests can't tolerate unrelated warnings >> >> Hi Sharath, >> >> On 8/01/2018 3:30 PM, Sharath Ballal wrote: >>> Thanks David.? I have made the changes. >>> New webrev is http://cr.openjdk.java.net/~sballal/8194067/webrev.01/ >> >> That looks quite good - only issue is that the regex won't work for >> an OpenJDK build as it produces: >> >> OpenJDK 64-Bit Server VM warning: ... >> >> rather than >> >> Java HotSpot(TM) 64-Bit Server VM warning: ... >> >> Maybe "VM warning:" will suffice for the match? >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> Sharath >>> >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Friday, December 29, 2017 6:13 AM >>> To: Sharath Ballal; serviceability-dev at openjdk.java.net >>> Subject: Re: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* >>> tests can't tolerate unrelated warnings >>> >>> When I reported this one I thought about how to best fix it. What >>> you propose is a simple fix, but may potentially allow other errors >>> to go unnoticed. I was wondering whether there was a simple way to >>> filter the stderr content to exclude VM Warnings, but still check >>> for other unexpected content? >>> >>> Thanks, >>> David >>> >>> On 28/12/2017 3:29 PM, Sharath Ballal wrote: >>>> Hello, >>>> >>>> Requesting reviews for: >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 >>>> >>>> Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ >>>> >>>> The tests ran successfully in JPRT and Mach5. >>>> >>>> Thanks, >>>> >>>> Sharath >>>> From sharath.ballal at oracle.com Wed Jan 10 12:15:40 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 10 Jan 2018 04:15:40 -0800 (PST) Subject: RFR: JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands In-Reply-To: <9c324b8d-5efa-e1bb-451c-3877c3242440@oracle.com> References: <9316a882-a7a1-0e70-4db1-e55d28931ea2@oracle.com> <9c324b8d-5efa-e1bb-451c-3877c3242440@oracle.com> Message-ID: <760a162f-d363-4d68-8280-bb8c8dd61f36@default> Looks Good Jini. Thanks, Sharath -----Original Message----- From: Jini George Sent: Tuesday, January 09, 2018 2:03 PM To: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands Have an updated webrev with the copyright year modified to 2018. Thanks, Jini. On 1/8/2018 11:30 AM, Jini George wrote: > Thanks much, Serguei. Could I please get one more review for this ? > > Thanks, > Jini. > > On 1/6/2018 1:26 AM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> This looks good to me. >> >> Thanks, >> Serguei >> >> >> On 1/5/18 00:41, Jini George wrote: >>> Hello, >>> >>> I would like to request reviews for: >>> >>> Id: https://bugs.openjdk.java.net/browse/JDK-8193352 >>> Webrev: >>> http://cr.openjdk.java.net/~jgeorge/8193352/webrev.00/index.html >>> >>> This is a test case for the clhsdb 'thread' and 'threads' commands. >>> This also includes a minor fix for the incorrect printing of the >>> text 'Couldn't find thread -a' when the 'thread -a' command is specified. >>> >>> Thanks, >>> Jini. >> From yasuenag at gmail.com Wed Jan 10 13:07:58 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 10 Jan 2018 22:07:58 +0900 Subject: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> Message-ID: <6167b355-5743-9e68-ff84-9e229abfd132@gmail.com> PING: Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ Yasumasa On 2017/12/31 13:33, Yasumasa Suenaga wrote: > Hi David, > > >> How did you submit to mach5 ??? > > I'm using Submit Repo for testing: > ? https://wiki.openjdk.java.net/display/Build/Submit+Repo > > >> Anyway the failure is with: > > Thanks! > I've fixed them in new webrev: > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ > > This webrev has passed Mach 5 tier 1 tests in Submit Repo: > ? http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171231-0202-8291 > > > Yasumasa > > > On 2017/12/30 10:31, David Holmes wrote: >> Hi Yasumasa, >> >> Not a review ... >> >> On 29/12/2017 11:16 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> G1HeapRegionTable#getByAddress() returns incorrect HeapRegion which contains incorrect address. We can see it in Stack Memory window on HSDB. Some oop addresses are shown as Free Region (attached image). >>> >>> G1HeapRegion#getByAddress() should create HeapRegion instance from the address in _biased_base array. >>> >>> I uploaded webrev. Could you review it? >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ >>> >>> I've tested this change with test/hotspot/jtreg/serviceability/sa, it works fine. >>> But I received some failure from Mach 5. I also tested this change via submit repos. >>> >>> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 >>> >>> I cannot access this URL. Could you share the result? >> >> How did you submit to mach5 ??? >> >> Anyway the failure is with: >> >> test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java >> >> On linux and OS X: >> >> ??stderr: [Exception in thread "main" java.lang.NullPointerException >> ?????at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >> ?????at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >> >> On Solaris sparcv9: >> >> ??stderr: [Exception in thread "main" java.lang.RuntimeException: Address of HeapRegion does not match.: expected 0x00000007afb00000 to equal 0x00000007afc00000 >> ?????at jdk.test.lib.Asserts.fail(Asserts.java:594) >> ?????at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> ?????at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >> ?????at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >> ] >> >> David >> ----- >> >>> Also I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa From jini.george at oracle.com Thu Jan 11 06:12:26 2018 From: jini.george at oracle.com (Jini George) Date: Thu, 11 Jan 2018 11:42:26 +0530 Subject: RFR: JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands In-Reply-To: <760a162f-d363-4d68-8280-bb8c8dd61f36@default> References: <9316a882-a7a1-0e70-4db1-e55d28931ea2@oracle.com> <9c324b8d-5efa-e1bb-451c-3877c3242440@oracle.com> <760a162f-d363-4d68-8280-bb8c8dd61f36@default> Message-ID: Thanks much, Sharath. - Jini. On 1/10/2018 5:45 PM, Sharath Ballal wrote: > Looks Good Jini. > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Tuesday, January 09, 2018 2:03 PM > To: serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > > Have an updated webrev with the copyright year modified to 2018. > > Thanks, > Jini. > > On 1/8/2018 11:30 AM, Jini George wrote: >> Thanks much, Serguei. Could I please get one more review for this ? >> >> Thanks, >> Jini. >> >> On 1/6/2018 1:26 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> This looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/5/18 00:41, Jini George wrote: >>>> Hello, >>>> >>>> I would like to request reviews for: >>>> >>>> Id: https://bugs.openjdk.java.net/browse/JDK-8193352 >>>> Webrev: >>>> http://cr.openjdk.java.net/~jgeorge/8193352/webrev.00/index.html >>>> >>>> This is a test case for the clhsdb 'thread' and 'threads' commands. >>>> This also includes a minor fix for the incorrect printing of the >>>> text 'Couldn't find thread -a' when the 'thread -a' command is specified. >>>> >>>> Thanks, >>>> Jini. >>> From amit.sapre at oracle.com Thu Jan 11 06:24:23 2018 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 10 Jan 2018 22:24:23 -0800 (PST) Subject: RFR : JDK-8175542 - JMX: Not enough JDP packets received In-Reply-To: <892d6f86-fa15-4da4-9318-101d87253751@default> References: <2b05b6b7-e731-7bf0-83b9-cdb2a4252d84@oracle.com> <892d6f86-fa15-4da4-9318-101d87253751@default> Message-ID: <6b1a939e-badf-477c-8a5f-253476022de0@default> Hello, Ping. Can somebody review this code changes ? Thanks, Amit From: Amit Sapre Sent: Wednesday, January 03, 2018 5:54 PM To: Harsha wardhana B; serviceability-dev at openjdk.java.net Subject: RE: RFR : JDK-8175542 - JMX: Not enough JDP packets received Thanks Harsha for the inputs. I made changes in this webrev : http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8175542/webrev.01/ Thanks, Amit From: Harsha Wardhana B Sent: Wednesday, December 13, 2017 5:32 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR : JDK-8175542 - JMX: Not enough JDP packets received Hi Amit, Increasing the timeout 'TIME_OUT_FACTOR' will increase both socket and test-case timeout. The test passed as can be seen from the log, but because of the race-condition: hasTestLivedLongEnough() checked before shouldContinue(), the test was declared failed because of time-out. One possible fix would be to change line 80 to, if (shouldContinue() && hasTestLivedLongEnough()) Thanks Harsha On Wednesday 13 December 2017 11:03 AM, Amit Sapre wrote: Hello, Please review the timeout fix for this bug. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8175542 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Easapre/webrev/2017/JDK-8175542/webrev.00/"http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8175542/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jan 11 07:09:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jan 2018 17:09:08 +1000 Subject: RFR : JDK-8175542 - JMX: Not enough JDP packets received In-Reply-To: <6b1a939e-badf-477c-8a5f-253476022de0@default> References: <2b05b6b7-e731-7bf0-83b9-cdb2a4252d84@oracle.com> <892d6f86-fa15-4da4-9318-101d87253751@default> <6b1a939e-badf-477c-8a5f-253476022de0@default> Message-ID: <3f620dba-b724-a80d-9f1f-3f5f045a0686@oracle.com> Hi Amit, Harsha, On 11/01/2018 4:24 PM, Amit Sapre wrote: > Hello, > > Ping. Can somebody review this code changes ? I took a look. If I understand correctly the way the test works is that it sets up a socket timeout of "timeout" - to be applied to the receive() call - and then allows 20% on top of that value for the overall execution time (between the recording of the start time and the check of hasTestLivedLongEnough()). The problem we see is that if the receive() and related processing takes us past the end deadline then we report a timeout, even though we actually managed to complete the test logic successfully. The fix simply checks for success before checking for the overall timeout - that seems reasonable. The only concern I'd have - and there's no way to completely mitigate this - is that if the logging+connection+creation+receive combined take a ridiculously long time (but within the overall jtreg timeout) then we won't notice as long as the receive+packet-processing completes okay. Two things I'd do in the future (if this starts timing out again) before changing the overall timeout-factor would be to try: a) recording the start time just before the loop, instead of before the logging and the socket connection and Datagram creation**; and/or b) changing the timeout overhead allowance from 20% to, say, 30%. ** this has the same problem of hiding unexpected delays in the logging+connection etc. But the proposed fix seems adequate for now. Thanks, David > Thanks, > > Amit > > *From:*Amit Sapre > *Sent:* Wednesday, January 03, 2018 5:54 PM > *To:* Harsha wardhana B; serviceability-dev at openjdk.java.net > *Subject:* RE: RFR : JDK-8175542 - JMX: Not enough JDP packets received > > Thanks Harsha for the inputs. > > I made changes in this webrev : > http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8175542/webrev.01/ > > Thanks, > > Amit > > *From:*Harsha Wardhana B > *Sent:* Wednesday, December 13, 2017 5:32 PM > *To:* serviceability-dev at openjdk.java.net > > *Subject:* Re: RFR : JDK-8175542 - JMX: Not enough JDP packets received > > Hi Amit, > > Increasing the timeout 'TIME_OUT_FACTOR' will increase both socket and > test-case timeout. The test passed as can be seen from the log, but > because of the race-condition: hasTestLivedLongEnough() checked before > shouldContinue(), the test was declared failed because of time-out. > > One possible fix would be to change line 80 to, > > ??? ??????????? if (shouldContinue() && hasTestLivedLongEnough()) > > Thanks > > Harsha > > On Wednesday 13 December 2017 11:03 AM, Amit Sapre wrote: > > Hello, > > Please review the timeout fix for this bug. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8175542 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8175542/webrev.00/ > > Thanks, > > Amit > From gary.adams at oracle.com Thu Jan 11 16:28:36 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 11 Jan 2018 11:28:36 -0500 Subject: RFR: JDK-8031482: Some jcmd commands generate output with \n as a line separator instead of \r\n on Windows Message-ID: <5A5790B4.6060700@oracle.com> Here's a simple fix to the split pattern when output lines are using mixed line separators in the same outputstream . e.g. split("\r\n|\n") Issue: https://bugs.openjdk.java.net/browse/JDK-8031482 Webrev: http://cr.openjdk.java.net/~gadams/JDK-8031482 testing in progress ... From chris.plummer at oracle.com Thu Jan 11 16:40:31 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 11 Jan 2018 08:40:31 -0800 Subject: RFR: JDK-8031482: Some jcmd commands generate output with \n as a line separator instead of \r\n on Windows In-Reply-To: <5A5790B4.6060700@oracle.com> References: <5A5790B4.6060700@oracle.com> Message-ID: <247fec64-068c-55c8-b9a2-072ebc8d8ab6@oracle.com> Hi Gary, I'm sure that fixes the problem, although there's no longer any platform abstraction of what a newline is. Theoretically there could be a platform for which it won't work, but I'm not so sure we really care about theoreticals here, since it is just for testing purposes and solves the issue on the platforms we know of. So thumbs up. Chris On 1/11/18 8:28 AM, Gary Adams wrote: > Here's a simple fix to the split pattern when output lines are using > mixed line > separators in the same outputstream . e.g. split("\r\n|\n") > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8031482 > ? Webrev: http://cr.openjdk.java.net/~gadams/JDK-8031482 > > testing in progress ... From gary.adams at oracle.com Thu Jan 11 17:04:19 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 11 Jan 2018 12:04:19 -0500 Subject: RFR: JDK-8031482: Some jcmd commands generate output with \n as a line separator instead of \r\n on Windows In-Reply-To: <247fec64-068c-55c8-b9a2-072ebc8d8ab6@oracle.com> References: <5A5790B4.6060700@oracle.com> <247fec64-068c-55c8-b9a2-072ebc8d8ab6@oracle.com> Message-ID: <5A579913.2030701@oracle.com> Webrev url correction ... On 1/11/18, 11:40 AM, Chris Plummer wrote: > Hi Gary, > > I'm sure that fixes the problem, although there's no longer any > platform abstraction of what a newline is. Theoretically there could > be a platform for which it won't work, but I'm not so sure we really > care about theoreticals here, since it is just for testing purposes > and solves the issue on the platforms we know of. So thumbs up. > > Chris > > On 1/11/18 8:28 AM, Gary Adams wrote: >> Here's a simple fix to the split pattern when output lines are using >> mixed line >> separators in the same outputstream . e.g. split("\r\n|\n") >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8031482 >> Webrev: http://cr.openjdk.java.net/~gadams/8031482 >> >> testing in progress ... > > > From serguei.spitsyn at oracle.com Thu Jan 11 17:12:11 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 11 Jan 2018 09:12:11 -0800 Subject: RFR: JDK-8031482: Some jcmd commands generate output with \n as a line separator instead of \r\n on Windows In-Reply-To: <5A579913.2030701@oracle.com> References: <5A5790B4.6060700@oracle.com> <247fec64-068c-55c8-b9a2-072ebc8d8ab6@oracle.com> <5A579913.2030701@oracle.com> Message-ID: <80660941-0698-6860-570c-73acfbb3f3b6@oracle.com> Hi Gary, Looks Okay to me. Thanks, Serguei On 1/11/18 09:04, Gary Adams wrote: > Webrev url correction ... > > On 1/11/18, 11:40 AM, Chris Plummer wrote: >> Hi Gary, >> >> I'm sure that fixes the problem, although there's no longer any >> platform abstraction of what a newline is. Theoretically there could >> be a platform for which it won't work, but I'm not so sure we really >> care about theoreticals here, since it is just for testing purposes >> and solves the issue on the platforms we know of. So thumbs up. >> >> Chris >> >> On 1/11/18 8:28 AM, Gary Adams wrote: >>> Here's a simple fix to the split pattern when output lines are using >>> mixed line >>> separators in the same outputstream . e.g. split("\r\n|\n") >>> >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8031482 >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8031482 >>> >>> testing in progress ... >> >> >> > From harsha.wardhana.b at oracle.com Thu Jan 11 17:22:39 2018 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 11 Jan 2018 22:52:39 +0530 Subject: RFR : JDK-8175542 - JMX: Not enough JDP packets received In-Reply-To: <892d6f86-fa15-4da4-9318-101d87253751@default> References: <2b05b6b7-e731-7bf0-83b9-cdb2a4252d84@oracle.com> <892d6f86-fa15-4da4-9318-101d87253751@default> Message-ID: <1dab98ca-e966-a756-fd18-e1f49c1f59cd@oracle.com> Hi Amit, Looks okay to me. Thanks Harsha On Wednesday 03 January 2018 05:54 PM, Amit Sapre wrote: > > Thanks Harsha for the inputs. > > I made changes in this webrev : > http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8175542/webrev.01/ > > > Thanks, > > Amit > > *From:*Harsha Wardhana B > *Sent:* Wednesday, December 13, 2017 5:32 PM > *To:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR : JDK-8175542 - JMX: Not enough JDP packets received > > Hi Amit, > > Increasing the timeout 'TIME_OUT_FACTOR' will increase both socket and > test-case timeout. The test passed as can be seen from the log, but > because of the race-condition: hasTestLivedLongEnough() checked before > shouldContinue(), the test was declared failed because of time-out. > > One possible fix would be to change line 80 to, > > ??? ??????????? if (shouldContinue() && hasTestLivedLongEnough()) > > Thanks > > Harsha > > On Wednesday 13 December 2017 11:03 AM, Amit Sapre wrote: > > Hello, > > Please review the timeout fix for this bug. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8175542 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8175542/webrev.00/ > > > Thanks, > > Amit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.vandette at oracle.com Thu Jan 11 18:41:40 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 11 Jan 2018 13:41:40 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers Message-ID: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8193710 Webrev: http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ Summary: This changeset enables the ability to use jcmd and jps running on a Host to list the java processes that are running in docker (cgroup based) containers. I?ve tested this change by examining processes running as root on both host and in docker containers as well as under my userid using ?jps and jcmd -l?. I?ve also tested the getFile functions with a small example program that I wrote. From what I can tell, these two getFile functions are not used in the JDK sources and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! I?d really like to remove these two methods. 140 candidate = new File(f.getName(), name); < References: <5A5790B4.6060700@oracle.com> Message-ID: <8e9abeff-5d46-be7f-99b0-f082f1c18574@oracle.com> Hi Gary, On 12/01/2018 2:28 AM, Gary Adams wrote: > Here's a simple fix to the split pattern when output lines are using > mixed line separators in the same outputstream . e.g. split("\r\n|\n") This is rather crude. I'd prefer to see reuse of existing library classes that already handle all the supported versions of newlines. BufferedReader does that. private List asLines(String buffer) { return new BufferedReader(new StringReader(buffer)).lines().collect(Collectors.toList()); } Going forward we could stream-ify outputAnalyzer further. :) Cheers, David ----- import java.util.stream.Collectors; import java.util.List; import java.io.BufferedReader; import java.io.StringReader; public class Lines { public static void main(String[] args) { List l = asLines("Line1\nLine2\r\nLine3\rLine4"); for (String s : l) { System.out.println(s); } } static private List asLines(String buffer) { return new BufferedReader(new StringReader(buffer)).lines().collect(Collectors.toList()); } } > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8031482 > ? Webrev: http://cr.openjdk.java.net/~gadams/JDK-8031482 > > testing in progress ... From alexey.menkov at oracle.com Fri Jan 12 01:21:59 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 11 Jan 2018 17:21:59 -0800 Subject: JDK-8187447: 2081 doc issues in jvmti.html Message-ID: Hi, Please review a fix for doc issue. jira: https://bugs.openjdk.java.net/browse/JDK-8187447 webrev: http://cr.openjdk.java.net/~amenkov/8187447/webrev/ old jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti_0.html new jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti.html specdiff reports no changes: http://cr.openjdk.java.net/~amenkov/8187447/specdiff/diff.html The fix: - converts jvmti.html from HTML4 to HTML5; - fixes all errors and almost all warnings reported by tidy and W3C HTML Validator: - empty

; - unsupported attributes (align, border, width, cellpadding, cellspacing, noshade, size, bgcolor, type); -

without nested
; - with "name" attribute; - table with column with no cells beginning in it (all cells have colspan=2); - adds "lang" attribute for (accessibility issue). The only remaining warning (reported by W3C HTML Validator) is Warning: Documents should not use about:legacy-compat, except if generated by legacy systems that can't output the standard doctype. This is expected as the DOCTYPE legacy string (http://w3c.github.io/html/single-page.html#doctype-legacy-string) was added to HTML5 standard to handle issue with XLST which cannot produce standard doctype. --alex From daniil.x.titov at oracle.com Fri Jan 12 01:45:12 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 11 Jan 2018 17:45:12 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function Message-ID: Hello, Please review the following fix that adds a jtreg test for GetOwnedMonitorStackDepthInfo JVMTI function. Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 The tests ran successfully with Mach5. Best regards, Daniil From david.holmes at oracle.com Fri Jan 12 02:44:04 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jan 2018 12:44:04 +1000 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> References: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> Message-ID: Hi Bob, Some initial discussion and commentary. I'm a bit concerned by how much accommodating docker penalises code that is not using containers. On 12/01/2018 4:41 AM, Bob Vandette wrote: > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8193710 > > Webrev: > > http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ > > Summary: > > This changeset enables the ability to use jcmd and jps running on a Host to > list the java processes that are running in docker (cgroup based) containers. Can you clarify this for me please. I assume we are still only listing processes for the current user - correct? So the issue is if I am running mutiple JVMs and also running a Docker process that itself contains JVMs then jps outside of Docker won't show the JVMs that are inside Docker. And presumably the opposite is also true? If we change jps to find all JVMs on the host for the current user, whether in a container or not (and whether jps is run from in a container or not?) are the process id's that get returned directly useable from where jps was run? > I?ve tested this change by examining processes running as root on both host and in > docker containers as well as under my userid using ?jps and jcmd -l?. > I?ve also tested the getFile functions with a small example program that I wrote. > From what I can tell, these two getFile functions are not used in the JDK sources > and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! > I?d really like to remove these two methods. If they are not used by anything then by all means drop them. > 140 candidate = new File(f.getName(), name); < > Here are some implementation details that I?ve added added to one of the Unix > specific source files (src/java.base/unix/classes/jdk/internal/vm/VMSupportImpl.java) I have an issue with this. This is not "unix" (ie anything other than windows) support code, it is Linux support code. I'm also unclear why this needs to be lifted out of the PerfMemory subsystem. And if you're going to mess with the jdk.internal module then I think core-libs folk will want to know before hand. Other comments ... src/hotspot/os/linux/perfMemory_linux.cpp I'm concerned about the MAXPATHLEN stack buffers and the extra overhead being added to the normal non-container path. We've had issues in the past where a newly added stack buffer caused StackOverflowError. We don't need a 4K buffer because os::get_temp_directory() just returns "/tmp" and we're dealing with all Linux code here. I don't like making assumptions like this but ... #define TMP_BUFFER_LEN (4 + 21) static char* get_user_tmp_dir(const char* user, int vmid, int nspid) { char buffer[TMP_BUFFER_LEN]; char* tmpdir = os::get_temp_directory(); assert(strlen(tmpdir) == 4, "No longer using /tmp - update buffer size"); if (nspid != -1) { jio_snprintf(buffer, TMP_BUFFER_LEN, "/proc/%d/root%s", vmid, tmpdir); tmpdir = buffer; } ... 657 char fname[64]; Maximum length of "/proc/%d/status" is 23. Thanks, David From bob.vandette at oracle.com Fri Jan 12 13:59:16 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 12 Jan 2018 08:59:16 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: References: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> Message-ID: <9FEEDEC9-2BF5-4CEC-A6D4-E11273573204@oracle.com> > On Jan 11, 2018, at 9:44 PM, David Holmes wrote: > > Hi Bob, > > Some initial discussion and commentary. I'm a bit concerned by how much accommodating docker penalises code that is not using containers. True but querying the number of Java processes is at least not in a performance critical area. > > On 12/01/2018 4:41 AM, Bob Vandette wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8193710 >> Webrev: >> http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ >> Summary: >> This changeset enables the ability to use jcmd and jps running on a Host to >> list the java processes that are running in docker (cgroup based) containers. > > Can you clarify this for me please. I assume we are still only listing processes for the current user - correct? No, it will report any Java processes that the current user has permission to see (hsperfdata* files are readable). If you run as root, you see all processes. > So the issue is if I am running mutiple JVMs and also running a Docker process that itself contains JVMs then jps outside of Docker won't show the JVMs that are inside Docker. Yes, this is what is being fixed. > And presumably the opposite is also true? > Yes, this is also true but is not being fixed by this change. I am only fixing the case where you run jps on a host and want to see all java processes running (in and out of containers). > If we change jps to find all JVMs on the host for the current user, whether in a container or not (and whether jps is run from in a container or not?) are the process id's that get returned directly useable from where jps was run? Given the above constraints, yes. The results jps can passed to jcmd to query things like VM.version > >> I?ve tested this change by examining processes running as root on both host and in >> docker containers as well as under my userid using ?jps and jcmd -l?. >> I?ve also tested the getFile functions with a small example program that I wrote. >> From what I can tell, these two getFile functions are not used in the JDK sources >> and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! >> I?d really like to remove these two methods. > > If they are not used by anything then by all means drop them. I saw some Javadocs on the web documenting these methods leading me to believe that we would need to deprecate these even though they are internal APIs. I?ll ask core-libs. http://openjdk.java.net/groups/serviceability/jvmstat/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.html#getFile(int) > >> 140 candidate = new File(f.getName(), name); <> Here are some implementation details that I?ve added added to one of the Unix >> specific source files (src/java.base/unix/classes/jdk/internal/vm/VMSupportImpl.java) > > I have an issue with this. This is not "unix" (ie anything other than windows) support code, it is Linux support code. I'm also unclear why this needs to be lifted out of the PerfMemory subsystem. You are correct, I?ll move this into a linux specific directory. I factored these functions in order to isolate the cgroup specific functionality in an OS specific tree. > > And if you're going to mess with the jdk.internal module then I think core-libs folk will want to know before hand. Will do. > > Other comments ... > > src/hotspot/os/linux/perfMemory_linux.cpp > > I'm concerned about the MAXPATHLEN stack buffers and the extra overhead being added to the normal non-container path. I believe the impacted paths are only used when attaching to the VM and should not impact normal startup. > We've had issues in the past where a newly added stack buffer caused StackOverflowError. We don't need a 4K buffer because os::get_temp_directory() just returns "/tmp" and we're dealing with all Linux code here. I don't like making assumptions like this but ... > > #define TMP_BUFFER_LEN (4 + 21) > static char* get_user_tmp_dir(const char* user, int vmid, int nspid) { > char buffer[TMP_BUFFER_LEN]; > char* tmpdir = os::get_temp_directory(); > assert(strlen(tmpdir) == 4, "No longer using /tmp - update buffer size"); > if (nspid != -1) { > jio_snprintf(buffer, TMP_BUFFER_LEN, "/proc/%d/root%s", vmid, tmpdir); > tmpdir = buffer; > } > ... > > > 657 char fname[64]; > > Maximum length of "/proc/%d/status" is 23. Ok, I?ll reduce the buffer sizes I use. Thanks, Bob. > > Thanks, > David From bob.vandette at oracle.com Fri Jan 12 15:02:28 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 12 Jan 2018 10:02:28 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: <9FEEDEC9-2BF5-4CEC-A6D4-E11273573204@oracle.com> References: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> <9FEEDEC9-2BF5-4CEC-A6D4-E11273573204@oracle.com> Message-ID: <88DDE9EA-91B7-4249-B45B-27C8D550DD8C@oracle.com> Looping in core-libs. The following fix alters the module-info for java.base. Can someone from the core-libs comment on these changes? I?d also like to remove the two PerfDataFile.getFile methods? Since these are in jdk.internal.jvmstat, can I just pull them or do they need to go through deprecation/CSR? Thanks, Bob. > On Jan 12, 2018, at 8:59 AM, Bob Vandette wrote: > > > >> On Jan 11, 2018, at 9:44 PM, David Holmes wrote: >> >> Hi Bob, >> >> Some initial discussion and commentary. I'm a bit concerned by how much accommodating docker penalises code that is not using containers. > > True but querying the number of Java processes is at least not in a performance critical area. > >> >> On 12/01/2018 4:41 AM, Bob Vandette wrote: >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8193710 >>> Webrev: >>> http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ >>> Summary: >>> This changeset enables the ability to use jcmd and jps running on a Host to >>> list the java processes that are running in docker (cgroup based) containers. >> >> Can you clarify this for me please. I assume we are still only listing processes for the current user - correct? > > No, it will report any Java processes that the current user has permission to see (hsperfdata* files are readable). > If you run as root, you see all processes. > >> So the issue is if I am running mutiple JVMs and also running a Docker process that itself contains JVMs then jps outside of Docker won't show the JVMs that are inside Docker. > > Yes, this is what is being fixed. > >> And presumably the opposite is also true? >> > > Yes, this is also true but is not being fixed by this change. I am only fixing the case where you run jps on a host and > want to see all java processes running (in and out of containers). > > >> If we change jps to find all JVMs on the host for the current user, whether in a container or not (and whether jps is run from in a container or not?) are the process id's that get returned directly useable from where jps was run? > > Given the above constraints, yes. > > The results jps can passed to jcmd to query things like VM.version > >> >>> I?ve tested this change by examining processes running as root on both host and in >>> docker containers as well as under my userid using ?jps and jcmd -l?. >>> I?ve also tested the getFile functions with a small example program that I wrote. >>> From what I can tell, these two getFile functions are not used in the JDK sources >>> and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! >>> I?d really like to remove these two methods. >> >> If they are not used by anything then by all means drop them. > I saw some Javadocs on the web documenting these methods leading me to believe that we would need > to deprecate these even though they are internal APIs. I?ll ask core-libs. > > http://openjdk.java.net/groups/serviceability/jvmstat/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.html#getFile(int) > >> >>> 140 candidate = new File(f.getName(), name); <>> Here are some implementation details that I?ve added added to one of the Unix >>> specific source files (src/java.base/unix/classes/jdk/internal/vm/VMSupportImpl.java) >> >> I have an issue with this. This is not "unix" (ie anything other than windows) support code, it is Linux support code. I'm also unclear why this needs to be lifted out of the PerfMemory subsystem. > You are correct, I?ll move this into a linux specific directory. I factored these functions in order to isolate the cgroup specific functionality > in an OS specific tree. > >> >> And if you're going to mess with the jdk.internal module then I think core-libs folk will want to know before hand. > > Will do. > >> >> Other comments ... >> >> src/hotspot/os/linux/perfMemory_linux.cpp >> >> I'm concerned about the MAXPATHLEN stack buffers and the extra overhead being added to the normal non-container path. > > I believe the impacted paths are only used when attaching to the VM and should not impact normal startup. > >> We've had issues in the past where a newly added stack buffer caused StackOverflowError. We don't need a 4K buffer because os::get_temp_directory() just returns "/tmp" and we're dealing with all Linux code here. I don't like making assumptions like this but ... >> >> #define TMP_BUFFER_LEN (4 + 21) >> static char* get_user_tmp_dir(const char* user, int vmid, int nspid) { >> char buffer[TMP_BUFFER_LEN]; >> char* tmpdir = os::get_temp_directory(); >> assert(strlen(tmpdir) == 4, "No longer using /tmp - update buffer size"); >> if (nspid != -1) { >> jio_snprintf(buffer, TMP_BUFFER_LEN, "/proc/%d/root%s", vmid, tmpdir); >> tmpdir = buffer; >> } >> ... >> >> >> 657 char fname[64]; >> >> Maximum length of "/proc/%d/status" is 23. > > Ok, I?ll reduce the buffer sizes I use. > > Thanks, > Bob. > > >> >> Thanks, >> David > From chris.plummer at oracle.com Fri Jan 12 20:24:48 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 12 Jan 2018 12:24:48 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: References: Message-ID: <258417af-b866-1927-b408-7bfbaee5ee31@oracle.com> Hi Daniil, Looks good. Thanks for adding this. Chris On 1/11/18 5:45 PM, Daniil Titov wrote: > Hello, > > Please review the following fix that adds a jtreg test for GetOwnedMonitorStackDepthInfo JVMTI function. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 > > > The tests ran successfully with Mach5. > > Best regards, > Daniil > > From serguei.spitsyn at oracle.com Fri Jan 12 22:25:58 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Jan 2018 14:25:58 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: References: Message-ID: Hi Daniil, It is pretty good in general. Thank you for taking care about it! Some comments though. The test case is too trivial. I'd suggest to extend it to have at least a couple of locks in the returned array. One way to do it would be to add a instance synchronized method and invoke it from the synchronized statement of the tested Thread. Then the verifyOwnedMonitors() can be invoked from this method. A couple of comments on the native agent. 72 // JNI_OnLoad has not been called yet, so can't possibly be an instance of TEST_CLASS. Could you, please, rewrite this comment? Maybe just tell that there probably was an error in loading the TEST_CLASS. What about moving the FindClass(env, TEST_CLASS) to the verifyOwnedMonitors() function? It will make the testClass variable local. 200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: stackDepthInfo[0].stack_depth should be 1.\n"); 207 fprintf(stderr, "VerifyOwnedMonitors: FAIL: monitorCount should be 1.\n"); It'd better to rephrase the messages above to tell about actual values vs expected. It normally simplifies the analysis of failures as there is no need to find what values were printed before and that they are exactly what needed for comparison. Thanks, Serguei On 1/11/18 17:45, Daniil Titov wrote: > Hello, > > Please review the following fix that adds a jtreg test for GetOwnedMonitorStackDepthInfo JVMTI function. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 > > > The tests ran successfully with Mach5. > > Best regards, > Daniil > > From chris.plummer at oracle.com Fri Jan 12 22:31:21 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 12 Jan 2018 14:31:21 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: References: Message-ID: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> Hi Serguei, On 1/12/18 2:25 PM, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > It is pretty good in general. > Thank you for taking care about it! > > Some comments though. > > The test case is too trivial. > I'd suggest to extend it to have at least a couple of locks in the > returned array. > One way to do it would be to add a instance synchronized method and > invoke it from the synchronized statement of the tested Thread. > Then the verifyOwnedMonitors() can be invoked from this method. > > A couple of comments on the native agent. > > 72???????? // JNI_OnLoad has not been called yet, so can't possibly be > an instance of TEST_CLASS. > > Could you, please, rewrite this comment? > Maybe just tell that there probably was an error in loading the > TEST_CLASS. This was copied from my comment in GetOwnedMonitorInfoTest, which I assume this test was based on. > What about moving the FindClass(env, TEST_CLASS) to the > verifyOwnedMonitors() function? > It will make the testClass variable local. > Also from GetOwnedMonitorInfoTest. This is code I reworked in that test recently to fix 8191229. These two tests should be kept consistent. Chris > ?200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: > stackDepthInfo[0].stack_depth should be 1.\n"); > > ?207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: monitorCount > should be 1.\n"); > > > It'd better to rephrase the messages above to tell about actual values > vs expected. > It normally simplifies the analysis of failures as there is no need to > find > what values were printed before and that they are exactly what needed > for comparison. > > Thanks, > Serguei > > > > On 1/11/18 17:45, Daniil Titov wrote: >> Hello, >> >> Please review the following fix that adds a jtreg test for >> GetOwnedMonitorStackDepthInfo JVMTI function. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >> >> >> The tests ran successfully with Mach5. >> >> Best regards, >> Daniil >> >> > From serguei.spitsyn at oracle.com Fri Jan 12 22:52:55 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Jan 2018 14:52:55 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> References: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> Message-ID: Hi Chris, On 1/12/18 14:31, Chris Plummer wrote: > Hi Serguei, > > On 1/12/18 2:25 PM, serguei.spitsyn at oracle.com wrote: >> Hi Daniil, >> >> It is pretty good in general. >> Thank you for taking care about it! >> >> Some comments though. >> >> The test case is too trivial. >> I'd suggest to extend it to have at least a couple of locks in the >> returned array. >> One way to do it would be to add a instance synchronized method and >> invoke it from the synchronized statement of the tested Thread. >> Then the verifyOwnedMonitors() can be invoked from this method. >> >> A couple of comments on the native agent. >> >> 72???????? // JNI_OnLoad has not been called yet, so can't possibly >> be an instance of TEST_CLASS. >> >> Could you, please, rewrite this comment? >> Maybe just tell that there probably was an error in loading the >> TEST_CLASS. > This was copied from my comment in GetOwnedMonitorInfoTest, which I > assume this test was based on. Yes, I also assumed it was copied from the GetOwnedMonitorInfoTest. The comment looks incorrect and creates some confusion. >> What about moving the FindClass(env, TEST_CLASS) to the >> verifyOwnedMonitors() function? >> It will make the testClass variable local. >> > Also from GetOwnedMonitorInfoTest. This is code I reworked in that > test recently to fix 8191229. Yes, I remember. > These two tests should be kept consistent. I still think, making it a part of the verifyOwnedMonitors() would simplify the test. Why do we need the testClass to be volatile and global if it is used only in the context of verification? It generates less questions if it is local. We could attempt to fix the GetOwnedMonitorInfoTest as well if we want this kind of consistency. Thanks, Serguei > Chris >> ?200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: >> stackDepthInfo[0].stack_depth should be 1.\n"); >> >> ?207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: monitorCount >> should be 1.\n"); >> >> >> It'd better to rephrase the messages above to tell about actual >> values vs expected. >> It normally simplifies the analysis of failures as there is no need >> to find >> what values were printed before and that they are exactly what needed >> for comparison. >> >> Thanks, >> Serguei >> >> >> >> On 1/11/18 17:45, Daniil Titov wrote: >>> Hello, >>> >>> Please review the following fix that adds a jtreg test for >>> GetOwnedMonitorStackDepthInfo JVMTI function. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>> >>> >>> The tests ran successfully with Mach5. >>> >>> Best regards, >>> Daniil >>> >>> >> > > From chris.plummer at oracle.com Fri Jan 12 23:07:21 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 12 Jan 2018 15:07:21 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: References: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> Message-ID: <92faac6a-072c-147a-cba5-8cb6f44f1e98@oracle.com> On 1/12/18 2:52 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > > On 1/12/18 14:31, Chris Plummer wrote: >> Hi Serguei, >> >> On 1/12/18 2:25 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Daniil, >>> >>> It is pretty good in general. >>> Thank you for taking care about it! >>> >>> Some comments though. >>> >>> The test case is too trivial. >>> I'd suggest to extend it to have at least a couple of locks in the >>> returned array. >>> One way to do it would be to add a instance synchronized method and >>> invoke it from the synchronized statement of the tested Thread. >>> Then the verifyOwnedMonitors() can be invoked from this method. >>> >>> A couple of comments on the native agent. >>> >>> 72???????? // JNI_OnLoad has not been called yet, so can't possibly >>> be an instance of TEST_CLASS. >>> >>> Could you, please, rewrite this comment? >>> Maybe just tell that there probably was an error in loading the >>> TEST_CLASS. >> This was copied from my comment in GetOwnedMonitorInfoTest, which I >> assume this test was based on. > > Yes, I also assumed it was copied from the GetOwnedMonitorInfoTest. > The comment looks incorrect and creates some confusion. How is it incorrect? If testClass is NULL, that does imply that JNI_OnLoad has not been called yet, which itself implies that the object cannot be an instance of TEST_CLASS. > > >>> What about moving the FindClass(env, TEST_CLASS) to the >>> verifyOwnedMonitors() function? >>> It will make the testClass variable local. >>> >> Also from GetOwnedMonitorInfoTest. This is code I reworked in that >> test recently to fix 8191229. > > Yes, I remember. > >> These two tests should be kept consistent. > > I still think, making it a part of the verifyOwnedMonitors() would > simplify the test. > Why do we need the testClass to be volatile and global if it is used > only in the context of verification? > It generates less questions if it is local. > We could attempt to fix the GetOwnedMonitorInfoTest as well if we want > this kind of consistency. I think in this test you could make looking up testClass local to verifyOwnedMonitors() since calling it is under our control.? In GetOwnedMonitorInfoTest, there is no place to safely make it local, because we need testClass during a JVMTI callback, and we can't always correctly look up TEST_CLASS in the callback. That's why the lookup was moved as part of 8191229 into JNI_OnLoad. thanks, Chris > > Thanks, > Serguei > > >> Chris >>> ?200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>> stackDepthInfo[0].stack_depth should be 1.\n"); >>> >>> ?207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>> monitorCount should be 1.\n"); >>> >>> >>> It'd better to rephrase the messages above to tell about actual >>> values vs expected. >>> It normally simplifies the analysis of failures as there is no need >>> to find >>> what values were printed before and that they are exactly what >>> needed for comparison. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 1/11/18 17:45, Daniil Titov wrote: >>>> Hello, >>>> >>>> Please review the following fix that adds a jtreg test for >>>> GetOwnedMonitorStackDepthInfo JVMTI function. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>>> >>>> >>>> The tests ran successfully with Mach5. >>>> >>>> Best regards, >>>> Daniil >>>> >>>> >>> >> >> > From daniil.x.titov at oracle.com Fri Jan 12 23:08:18 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 12 Jan 2018 15:08:18 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: References: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> Message-ID: <52F370D6-D8ED-46E5-97A4-70705C00CDAE@oracle.com> Thank you, Chris and Serguei! I will extend the test as suggested and send an updated patch for review. Best regards, Daniil On 1/12/18, 2:52 PM, "serguei.spitsyn at oracle.com" wrote: Hi Chris, On 1/12/18 14:31, Chris Plummer wrote: > Hi Serguei, > > On 1/12/18 2:25 PM, serguei.spitsyn at oracle.com wrote: >> Hi Daniil, >> >> It is pretty good in general. >> Thank you for taking care about it! >> >> Some comments though. >> >> The test case is too trivial. >> I'd suggest to extend it to have at least a couple of locks in the >> returned array. >> One way to do it would be to add a instance synchronized method and >> invoke it from the synchronized statement of the tested Thread. >> Then the verifyOwnedMonitors() can be invoked from this method. >> >> A couple of comments on the native agent. >> >> 72 // JNI_OnLoad has not been called yet, so can't possibly >> be an instance of TEST_CLASS. >> >> Could you, please, rewrite this comment? >> Maybe just tell that there probably was an error in loading the >> TEST_CLASS. > This was copied from my comment in GetOwnedMonitorInfoTest, which I > assume this test was based on. Yes, I also assumed it was copied from the GetOwnedMonitorInfoTest. The comment looks incorrect and creates some confusion. >> What about moving the FindClass(env, TEST_CLASS) to the >> verifyOwnedMonitors() function? >> It will make the testClass variable local. >> > Also from GetOwnedMonitorInfoTest. This is code I reworked in that > test recently to fix 8191229. Yes, I remember. > These two tests should be kept consistent. I still think, making it a part of the verifyOwnedMonitors() would simplify the test. Why do we need the testClass to be volatile and global if it is used only in the context of verification? It generates less questions if it is local. We could attempt to fix the GetOwnedMonitorInfoTest as well if we want this kind of consistency. Thanks, Serguei > Chris >> 200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: >> stackDepthInfo[0].stack_depth should be 1.\n"); >> >> 207 fprintf(stderr, "VerifyOwnedMonitors: FAIL: monitorCount >> should be 1.\n"); >> >> >> It'd better to rephrase the messages above to tell about actual >> values vs expected. >> It normally simplifies the analysis of failures as there is no need >> to find >> what values were printed before and that they are exactly what needed >> for comparison. >> >> Thanks, >> Serguei >> >> >> >> On 1/11/18 17:45, Daniil Titov wrote: >>> Hello, >>> >>> Please review the following fix that adds a jtreg test for >>> GetOwnedMonitorStackDepthInfo JVMTI function. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>> >>> >>> The tests ran successfully with Mach5. >>> >>> Best regards, >>> Daniil >>> >>> >> > > From serguei.spitsyn at oracle.com Fri Jan 12 23:14:52 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Jan 2018 15:14:52 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <92faac6a-072c-147a-cba5-8cb6f44f1e98@oracle.com> References: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> <92faac6a-072c-147a-cba5-8cb6f44f1e98@oracle.com> Message-ID: <5f90ba66-fc95-2ac8-615d-6eaa9cf79cd5@oracle.com> On 1/12/18 15:07, Chris Plummer wrote: > On 1/12/18 2:52 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> >> On 1/12/18 14:31, Chris Plummer wrote: >>> Hi Serguei, >>> >>> On 1/12/18 2:25 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Daniil, >>>> >>>> It is pretty good in general. >>>> Thank you for taking care about it! >>>> >>>> Some comments though. >>>> >>>> The test case is too trivial. >>>> I'd suggest to extend it to have at least a couple of locks in the >>>> returned array. >>>> One way to do it would be to add a instance synchronized method and >>>> invoke it from the synchronized statement of the tested Thread. >>>> Then the verifyOwnedMonitors() can be invoked from this method. >>>> >>>> A couple of comments on the native agent. >>>> >>>> 72???????? // JNI_OnLoad has not been called yet, so can't possibly >>>> be an instance of TEST_CLASS. >>>> >>>> Could you, please, rewrite this comment? >>>> Maybe just tell that there probably was an error in loading the >>>> TEST_CLASS. >>> This was copied from my comment in GetOwnedMonitorInfoTest, which I >>> assume this test was based on. >> >> Yes, I also assumed it was copied from the GetOwnedMonitorInfoTest. >> The comment looks incorrect and creates some confusion. > How is it incorrect? If testClass is NULL, that does imply that > JNI_OnLoad has not been called yet, which itself implies that the > object cannot be an instance of TEST_CLASS. It contradicts with the JNI_OnLoad code: 100 testClass = (*env)->FindClass(env, TEST_CLASS); 101 if (testClass != NULL) { 102 testClass = (*env)->NewGlobalRef(env, testClass); 103 } 104 if (testClass == NULL) { 105 fprintf(stderr, "Error: Could not load class %s!\n", TEST_CLASS); 106 return JNI_ERR; 107 } >>>> What about moving the FindClass(env, TEST_CLASS) to the >>>> verifyOwnedMonitors() function? >>>> It will make the testClass variable local. >>>> >>> Also from GetOwnedMonitorInfoTest. This is code I reworked in that >>> test recently to fix 8191229. >> >> Yes, I remember. >> >>> These two tests should be kept consistent. >> >> I still think, making it a part of the verifyOwnedMonitors() would >> simplify the test. >> Why do we need the testClass to be volatile and global if it is used >> only in the context of verification? >> It generates less questions if it is local. >> We could attempt to fix the GetOwnedMonitorInfoTest as well if we >> want this kind of consistency. > I think in this test you could make looking up testClass local to > verifyOwnedMonitors() since calling it is under our control.? In > GetOwnedMonitorInfoTest, there is no place to safely make it local, > because we need testClass during a JVMTI callback, and we can't always > correctly look up TEST_CLASS in the callback. That's why the lookup > was moved as part of 8191229 into JNI_OnLoad. Good explanation, thanks! So, we do not need a consistency with the GetOwnedMonitorInfoTest in such a case. Thanks, Serguei > thanks, > > Chris >> >> Thanks, >> Serguei >> >> >>> Chris >>>> ?200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>>> stackDepthInfo[0].stack_depth should be 1.\n"); >>>> >>>> ?207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>>> monitorCount should be 1.\n"); >>>> >>>> >>>> It'd better to rephrase the messages above to tell about actual >>>> values vs expected. >>>> It normally simplifies the analysis of failures as there is no need >>>> to find >>>> what values were printed before and that they are exactly what >>>> needed for comparison. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 1/11/18 17:45, Daniil Titov wrote: >>>>> Hello, >>>>> >>>>> Please review the following fix that adds a jtreg test for >>>>> GetOwnedMonitorStackDepthInfo JVMTI function. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>>>> >>>>> >>>>> The tests ran successfully with Mach5. >>>>> >>>>> Best regards, >>>>> Daniil >>>>> >>>>> >>>> >>> >>> >> > > From serguei.spitsyn at oracle.com Fri Jan 12 23:17:38 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Jan 2018 15:17:38 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <5f90ba66-fc95-2ac8-615d-6eaa9cf79cd5@oracle.com> References: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> <92faac6a-072c-147a-cba5-8cb6f44f1e98@oracle.com> <5f90ba66-fc95-2ac8-615d-6eaa9cf79cd5@oracle.com> Message-ID: <033e7bbc-15ed-1c6e-39a7-23a8aa3c6b1f@oracle.com> On 1/12/18 15:14, serguei.spitsyn at oracle.com wrote: > On 1/12/18 15:07, Chris Plummer wrote: >> On 1/12/18 2:52 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> >>> On 1/12/18 14:31, Chris Plummer wrote: >>>> Hi Serguei, >>>> >>>> On 1/12/18 2:25 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Daniil, >>>>> >>>>> It is pretty good in general. >>>>> Thank you for taking care about it! >>>>> >>>>> Some comments though. >>>>> >>>>> The test case is too trivial. >>>>> I'd suggest to extend it to have at least a couple of locks in the >>>>> returned array. >>>>> One way to do it would be to add a instance synchronized method and >>>>> invoke it from the synchronized statement of the tested Thread. >>>>> Then the verifyOwnedMonitors() can be invoked from this method. >>>>> >>>>> A couple of comments on the native agent. >>>>> >>>>> 72???????? // JNI_OnLoad has not been called yet, so can't >>>>> possibly be an instance of TEST_CLASS. >>>>> >>>>> Could you, please, rewrite this comment? >>>>> Maybe just tell that there probably was an error in loading the >>>>> TEST_CLASS. >>>> This was copied from my comment in GetOwnedMonitorInfoTest, which I >>>> assume this test was based on. >>> >>> Yes, I also assumed it was copied from the GetOwnedMonitorInfoTest. >>> The comment looks incorrect and creates some confusion. >> How is it incorrect? If testClass is NULL, that does imply that >> JNI_OnLoad has not been called yet, which itself implies that the >> object cannot be an instance of TEST_CLASS. > > It contradicts with the JNI_OnLoad code: > > ?100???? testClass = (*env)->FindClass(env, TEST_CLASS); > ?101???? if (testClass != NULL) { > ?102?????? testClass = (*env)->NewGlobalRef(env, testClass); > ?103???? } > ?104???? if (testClass == NULL) { > ?105???????? fprintf(stderr, "Error: Could not load class %s!\n", > TEST_CLASS); > ?106???????? return JNI_ERR; > ?107???? } I forgot to tell that this comment is not needed if the fragment above is moved to the verifyOwnedMonitors(). Thanks, Serguei >>>>> What about moving the FindClass(env, TEST_CLASS) to the >>>>> verifyOwnedMonitors() function? >>>>> It will make the testClass variable local. >>>>> >>>> Also from GetOwnedMonitorInfoTest. This is code I reworked in that >>>> test recently to fix 8191229. >>> >>> Yes, I remember. >>> >>>> These two tests should be kept consistent. >>> >>> I still think, making it a part of the verifyOwnedMonitors() would >>> simplify the test. >>> Why do we need the testClass to be volatile and global if it is used >>> only in the context of verification? >>> It generates less questions if it is local. >>> We could attempt to fix the GetOwnedMonitorInfoTest as well if we >>> want this kind of consistency. >> I think in this test you could make looking up testClass local to >> verifyOwnedMonitors() since calling it is under our control. In >> GetOwnedMonitorInfoTest, there is no place to safely make it local, >> because we need testClass during a JVMTI callback, and we can't >> always correctly look up TEST_CLASS in the callback. That's why the >> lookup was moved as part of 8191229 into JNI_OnLoad. > > Good explanation, thanks! > So, we do not need a consistency with the GetOwnedMonitorInfoTest in > such a case. > > Thanks, > Serguei > >> thanks, >> >> Chris >>> >>> Thanks, >>> Serguei >>> >>> >>>> Chris >>>>> ?200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>>>> stackDepthInfo[0].stack_depth should be 1.\n"); >>>>> >>>>> ?207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>>>> monitorCount should be 1.\n"); >>>>> >>>>> >>>>> It'd better to rephrase the messages above to tell about actual >>>>> values vs expected. >>>>> It normally simplifies the analysis of failures as there is no >>>>> need to find >>>>> what values were printed before and that they are exactly what >>>>> needed for comparison. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 1/11/18 17:45, Daniil Titov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following fix that adds a jtreg test for >>>>>> GetOwnedMonitorStackDepthInfo JVMTI function. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>>>>> >>>>>> >>>>>> The tests ran successfully with Mach5. >>>>>> >>>>>> Best regards, >>>>>> Daniil >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From chris.plummer at oracle.com Fri Jan 12 23:42:06 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 12 Jan 2018 15:42:06 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <5f90ba66-fc95-2ac8-615d-6eaa9cf79cd5@oracle.com> References: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> <92faac6a-072c-147a-cba5-8cb6f44f1e98@oracle.com> <5f90ba66-fc95-2ac8-615d-6eaa9cf79cd5@oracle.com> Message-ID: <7d65c727-813a-cc74-c865-9fcd01ea9033@oracle.com> On 1/12/18 3:14 PM, serguei.spitsyn at oracle.com wrote: > On 1/12/18 15:07, Chris Plummer wrote: >> On 1/12/18 2:52 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> >>> On 1/12/18 14:31, Chris Plummer wrote: >>>> Hi Serguei, >>>> >>>> On 1/12/18 2:25 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Daniil, >>>>> >>>>> It is pretty good in general. >>>>> Thank you for taking care about it! >>>>> >>>>> Some comments though. >>>>> >>>>> The test case is too trivial. >>>>> I'd suggest to extend it to have at least a couple of locks in the >>>>> returned array. >>>>> One way to do it would be to add a instance synchronized method and >>>>> invoke it from the synchronized statement of the tested Thread. >>>>> Then the verifyOwnedMonitors() can be invoked from this method. >>>>> >>>>> A couple of comments on the native agent. >>>>> >>>>> 72???????? // JNI_OnLoad has not been called yet, so can't >>>>> possibly be an instance of TEST_CLASS. >>>>> >>>>> Could you, please, rewrite this comment? >>>>> Maybe just tell that there probably was an error in loading the >>>>> TEST_CLASS. >>>> This was copied from my comment in GetOwnedMonitorInfoTest, which I >>>> assume this test was based on. >>> >>> Yes, I also assumed it was copied from the GetOwnedMonitorInfoTest. >>> The comment looks incorrect and creates some confusion. >> How is it incorrect? If testClass is NULL, that does imply that >> JNI_OnLoad has not been called yet, which itself implies that the >> object cannot be an instance of TEST_CLASS. > > It contradicts with the JNI_OnLoad code: > > ?100???? testClass = (*env)->FindClass(env, TEST_CLASS); > ?101???? if (testClass != NULL) { > ?102?????? testClass = (*env)->NewGlobalRef(env, testClass); > ?103???? } > ?104???? if (testClass == NULL) { > ?105???????? fprintf(stderr, "Error: Could not load class %s!\n", > TEST_CLASS); > ?106???????? return JNI_ERR; > ?107???? } > I think your point is that possibly testClass could be NULL if JNI_OnLoad was called but failed. I think that is a minor detail, and the test will exit when that happens. thanks, Chris > >>>>> What about moving the FindClass(env, TEST_CLASS) to the >>>>> verifyOwnedMonitors() function? >>>>> It will make the testClass variable local. >>>>> >>>> Also from GetOwnedMonitorInfoTest. This is code I reworked in that >>>> test recently to fix 8191229. >>> >>> Yes, I remember. >>> >>>> These two tests should be kept consistent. >>> >>> I still think, making it a part of the verifyOwnedMonitors() would >>> simplify the test. >>> Why do we need the testClass to be volatile and global if it is used >>> only in the context of verification? >>> It generates less questions if it is local. >>> We could attempt to fix the GetOwnedMonitorInfoTest as well if we >>> want this kind of consistency. >> I think in this test you could make looking up testClass local to >> verifyOwnedMonitors() since calling it is under our control. In >> GetOwnedMonitorInfoTest, there is no place to safely make it local, >> because we need testClass during a JVMTI callback, and we can't >> always correctly look up TEST_CLASS in the callback. That's why the >> lookup was moved as part of 8191229 into JNI_OnLoad. > > Good explanation, thanks! > So, we do not need a consistency with the GetOwnedMonitorInfoTest in > such a case. > > Thanks, > Serguei > >> thanks, >> >> Chris >>> >>> Thanks, >>> Serguei >>> >>> >>>> Chris >>>>> ?200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>>>> stackDepthInfo[0].stack_depth should be 1.\n"); >>>>> >>>>> ?207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>>>> monitorCount should be 1.\n"); >>>>> >>>>> >>>>> It'd better to rephrase the messages above to tell about actual >>>>> values vs expected. >>>>> It normally simplifies the analysis of failures as there is no >>>>> need to find >>>>> what values were printed before and that they are exactly what >>>>> needed for comparison. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 1/11/18 17:45, Daniil Titov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following fix that adds a jtreg test for >>>>>> GetOwnedMonitorStackDepthInfo JVMTI function. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>>>>> >>>>>> >>>>>> The tests ran successfully with Mach5. >>>>>> >>>>>> Best regards, >>>>>> Daniil >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From serguei.spitsyn at oracle.com Sat Jan 13 00:52:52 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Jan 2018 16:52:52 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <7d65c727-813a-cc74-c865-9fcd01ea9033@oracle.com> References: <874a559f-e552-3b4b-de42-a2b194487150@oracle.com> <92faac6a-072c-147a-cba5-8cb6f44f1e98@oracle.com> <5f90ba66-fc95-2ac8-615d-6eaa9cf79cd5@oracle.com> <7d65c727-813a-cc74-c865-9fcd01ea9033@oracle.com> Message-ID: On 1/12/18 15:42, Chris Plummer wrote: > On 1/12/18 3:14 PM, serguei.spitsyn at oracle.com wrote: >> On 1/12/18 15:07, Chris Plummer wrote: >>> On 1/12/18 2:52 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Chris, >>>> >>>> >>>> On 1/12/18 14:31, Chris Plummer wrote: >>>>> Hi Serguei, >>>>> >>>>> On 1/12/18 2:25 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Daniil, >>>>>> >>>>>> It is pretty good in general. >>>>>> Thank you for taking care about it! >>>>>> >>>>>> Some comments though. >>>>>> >>>>>> The test case is too trivial. >>>>>> I'd suggest to extend it to have at least a couple of locks in >>>>>> the returned array. >>>>>> One way to do it would be to add a instance synchronized method and >>>>>> invoke it from the synchronized statement of the tested Thread. >>>>>> Then the verifyOwnedMonitors() can be invoked from this method. >>>>>> >>>>>> A couple of comments on the native agent. >>>>>> >>>>>> 72???????? // JNI_OnLoad has not been called yet, so can't >>>>>> possibly be an instance of TEST_CLASS. >>>>>> >>>>>> Could you, please, rewrite this comment? >>>>>> Maybe just tell that there probably was an error in loading the >>>>>> TEST_CLASS. >>>>> This was copied from my comment in GetOwnedMonitorInfoTest, which >>>>> I assume this test was based on. >>>> >>>> Yes, I also assumed it was copied from the GetOwnedMonitorInfoTest. >>>> The comment looks incorrect and creates some confusion. >>> How is it incorrect? If testClass is NULL, that does imply that >>> JNI_OnLoad has not been called yet, which itself implies that the >>> object cannot be an instance of TEST_CLASS. >> >> It contradicts with the JNI_OnLoad code: >> >> ?100???? testClass = (*env)->FindClass(env, TEST_CLASS); >> ?101???? if (testClass != NULL) { >> ?102?????? testClass = (*env)->NewGlobalRef(env, testClass); >> ?103???? } >> ?104???? if (testClass == NULL) { >> ?105???????? fprintf(stderr, "Error: Could not load class %s!\n", >> TEST_CLASS); >> ?106???????? return JNI_ERR; >> ?107???? } >> > I think your point is that possibly testClass could be NULL if > JNI_OnLoad was called but failed. Right. > I think that is a minor detail, and the test will exit when that happens. The reader needs to make this conclusion to understand the comment. But I see your point, thanks. Thanks, Serguei > thanks, > > Chris >> >>>>>> What about moving the FindClass(env, TEST_CLASS) to the >>>>>> verifyOwnedMonitors() function? >>>>>> It will make the testClass variable local. >>>>>> >>>>> Also from GetOwnedMonitorInfoTest. This is code I reworked in that >>>>> test recently to fix 8191229. >>>> >>>> Yes, I remember. >>>> >>>>> These two tests should be kept consistent. >>>> >>>> I still think, making it a part of the verifyOwnedMonitors() would >>>> simplify the test. >>>> Why do we need the testClass to be volatile and global if it is >>>> used only in the context of verification? >>>> It generates less questions if it is local. >>>> We could attempt to fix the GetOwnedMonitorInfoTest as well if we >>>> want this kind of consistency. >>> I think in this test you could make looking up testClass local to >>> verifyOwnedMonitors() since calling it is under our control. In >>> GetOwnedMonitorInfoTest, there is no place to safely make it local, >>> because we need testClass during a JVMTI callback, and we can't >>> always correctly look up TEST_CLASS in the callback. That's why the >>> lookup was moved as part of 8191229 into JNI_OnLoad. >> >> Good explanation, thanks! >> So, we do not need a consistency with the GetOwnedMonitorInfoTest in >> such a case. >> >> Thanks, >> Serguei >> >>> thanks, >>> >>> Chris >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> Chris >>>>>> ?200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>>>>> stackDepthInfo[0].stack_depth should be 1.\n"); >>>>>> >>>>>> ?207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>>>>> monitorCount should be 1.\n"); >>>>>> >>>>>> >>>>>> It'd better to rephrase the messages above to tell about actual >>>>>> values vs expected. >>>>>> It normally simplifies the analysis of failures as there is no >>>>>> need to find >>>>>> what values were printed before and that they are exactly what >>>>>> needed for comparison. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 1/11/18 17:45, Daniil Titov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the following fix that adds a jtreg test for >>>>>>> GetOwnedMonitorStackDepthInfo JVMTI function. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>>>>>> >>>>>>> >>>>>>> The tests ran successfully with Mach5. >>>>>>> >>>>>>> Best regards, >>>>>>> Daniil >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From alexey.menkov at oracle.com Sat Jan 13 01:05:19 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 12 Jan 2018 17:05:19 -0800 Subject: JDK-8187447: 2081 doc issues in jvmti.html In-Reply-To: References: Message-ID: <416839f1-4307-ec13-9bf2-b19734cb64b4@oracle.com> Updated the fix after offline discussion with Serguei: http://cr.openjdk.java.net/~amenkov/8187447/webrev.01/ changes: rollback replacement

with in jvmti.xml, handle the case by transform in jvmti.xsl Resulting jvmti.html is exactly the same. --alex On 01/11/2018 17:21, Alex Menkov wrote: > Hi, > > Please review a fix for doc issue. > > jira: https://bugs.openjdk.java.net/browse/JDK-8187447 > webrev: http://cr.openjdk.java.net/~amenkov/8187447/webrev/ > > old jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti_0.html > new jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti.html > > specdiff reports no changes: > http://cr.openjdk.java.net/~amenkov/8187447/specdiff/diff.html > > The fix: > - converts jvmti.html from HTML4 to HTML5; > - fixes all errors and almost all warnings reported by tidy and W3C HTML > Validator: > ? - empty

; > ? - unsupported attributes (align, border, width, cellpadding, > cellspacing, noshade, size, bgcolor, type); > ? -

without nested
; > ? - with "name" attribute; > ? - table with column with no cells beginning in it (all cells have > colspan=2); > - adds "lang" attribute for (accessibility issue). > > The only remaining warning (reported by W3C HTML Validator) is > ? Warning: Documents should not use about:legacy-compat, except if > generated by legacy systems that can't output the standard html> doctype. > This is expected as the DOCTYPE legacy string > (http://w3c.github.io/html/single-page.html#doctype-legacy-string) was > added to HTML5 standard to handle issue with XLST which cannot produce > standard doctype. > > --alex From serguei.spitsyn at oracle.com Sat Jan 13 01:06:29 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Jan 2018 17:06:29 -0800 Subject: JDK-8187447: 2081 doc issues in jvmti.html In-Reply-To: References: Message-ID: <6db7e23e-24c2-5911-f138-d0cc4efbccc9@oracle.com> Hi Alex, The fix is pretty impressive. Thank you for taking care about all these html issues! I'd like to ask about one thing. The renaming of the

element into in the jvmti.xml is not that necessary but is very intrusive as it impacts too many places. Could you, please, keep these elements as they are for now? Thanks, Serguei On 1/11/18 17:21, Alex Menkov wrote: > Hi, > > Please review a fix for doc issue. > > jira: https://bugs.openjdk.java.net/browse/JDK-8187447 > webrev: http://cr.openjdk.java.net/~amenkov/8187447/webrev/ > > old jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti_0.html > new jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti.html > > specdiff reports no changes: > http://cr.openjdk.java.net/~amenkov/8187447/specdiff/diff.html > > The fix: > - converts jvmti.html from HTML4 to HTML5; > - fixes all errors and almost all warnings reported by tidy and W3C > HTML Validator: > ? - empty

; > ? - unsupported attributes (align, border, width, cellpadding, > cellspacing, noshade, size, bgcolor, type); > ? -

without nested
; > ? - with "name" attribute; > ? - table with column with no cells beginning in it (all cells have > colspan=2); > - adds "lang" attribute for (accessibility issue). > > The only remaining warning (reported by W3C HTML Validator) is > ? Warning: Documents should not use about:legacy-compat, except if > generated by legacy systems that can't output the standard html> doctype. > This is expected as the DOCTYPE legacy string > (http://w3c.github.io/html/single-page.html#doctype-legacy-string) was > added to HTML5 standard to handle issue with XLST which cannot produce > standard doctype. > > --alex From serguei.spitsyn at oracle.com Sat Jan 13 01:10:42 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Jan 2018 17:10:42 -0800 Subject: JDK-8187447: 2081 doc issues in jvmti.html In-Reply-To: <416839f1-4307-ec13-9bf2-b19734cb64b4@oracle.com> References: <416839f1-4307-ec13-9bf2-b19734cb64b4@oracle.com> Message-ID: <29106d3d-f59c-5e66-86d1-1fff6b579e00@oracle.com> Thanks, Alex! Serguei On 1/12/18 17:05, Alex Menkov wrote: > Updated the fix after offline discussion with Serguei: > http://cr.openjdk.java.net/~amenkov/8187447/webrev.01/ > > changes: > rollback replacement

with in jvmti.xml, > handle the case by transform in jvmti.xsl > > Resulting jvmti.html is exactly the same. > > --alex > > On 01/11/2018 17:21, Alex Menkov wrote: >> Hi, >> >> Please review a fix for doc issue. >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8187447 >> webrev: http://cr.openjdk.java.net/~amenkov/8187447/webrev/ >> >> old jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti_0.html >> new jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti.html >> >> specdiff reports no changes: >> http://cr.openjdk.java.net/~amenkov/8187447/specdiff/diff.html >> >> The fix: >> - converts jvmti.html from HTML4 to HTML5; >> - fixes all errors and almost all warnings reported by tidy and W3C >> HTML Validator: >> ?? - empty

; >> ?? - unsupported attributes (align, border, width, cellpadding, >> cellspacing, noshade, size, bgcolor, type); >> ?? -

without nested
; >> ?? - with "name" attribute; >> ?? - table with column with no cells beginning in it (all cells have >> colspan=2); >> - adds "lang" attribute for (accessibility issue). >> >> The only remaining warning (reported by W3C HTML Validator) is >> ?? Warning: Documents should not use about:legacy-compat, except if >> generated by legacy systems that can't output the standard > html> doctype. >> This is expected as the DOCTYPE legacy string >> (http://w3c.github.io/html/single-page.html#doctype-legacy-string) >> was added to HTML5 standard to handle issue with XLST which cannot >> produce standard doctype. >> >> --alex From gary.adams at oracle.com Sat Jan 13 13:05:29 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Sat, 13 Jan 2018 08:05:29 -0500 Subject: RFR: JDK-8031482: Some jcmd commands generate output with \n as a line separator instead of \r\n on Windows In-Reply-To: <5A5790B4.6060700@oracle.com> References: <5A5790B4.6060700@oracle.com> Message-ID: Webrev updated with buffered reader lines() suggested by David. ? http://cr.openjdk.java.net/~gadams/8031482/webrev.01/ On 1/11/18 11:28 AM, Gary Adams wrote: > Here's a simple fix to the split pattern when output lines are using > mixed line > separators in the same outputstream . e.g. split("\r\n|\n") > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8031482 > ? Webrev: http://cr.openjdk.java.net/~gadams/JDK-8031482 > > testing in progress ... From david.holmes at oracle.com Sat Jan 13 22:47:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 14 Jan 2018 08:47:12 +1000 Subject: RFR: JDK-8031482: Some jcmd commands generate output with \n as a line separator instead of \r\n on Windows In-Reply-To: References: <5A5790B4.6060700@oracle.com> Message-ID: <5f78bf04-fb86-dc44-ccc7-f5886c9aaad8@oracle.com> Looks good - thanks. I'll sponsor for you. David On 13/01/2018 11:05 PM, gary.adams at oracle.com wrote: > Webrev updated with buffered reader lines() suggested by David. > > ? http://cr.openjdk.java.net/~gadams/8031482/webrev.01/ > > On 1/11/18 11:28 AM, Gary Adams wrote: >> Here's a simple fix to the split pattern when output lines are using >> mixed line >> separators in the same outputstream . e.g. split("\r\n|\n") >> >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8031482 >> ? Webrev: http://cr.openjdk.java.net/~gadams/JDK-8031482 >> >> testing in progress ... > > From david.holmes at oracle.com Sat Jan 13 23:02:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 14 Jan 2018 09:02:19 +1000 Subject: RFR: JDK-8031482: Some jcmd commands generate output with \n as a line separator instead of \r\n on Windows In-Reply-To: <5f78bf04-fb86-dc44-ccc7-f5886c9aaad8@oracle.com> References: <5A5790B4.6060700@oracle.com> <5f78bf04-fb86-dc44-ccc7-f5886c9aaad8@oracle.com> Message-ID: <702307ca-09b3-ad1a-5e57-d5d2e89429b0@oracle.com> Opps sorry one more thing: /** * Get the contents of the output buffer (stdout and stderr) as list of strings. * Output will be split by system property 'line.separator'. the doc comment needs to be updated e.g: * Output will be split at new-lines as recognized by java.io.BufferedReader.readLine() Thanks, David On 14/01/2018 8:47 AM, David Holmes wrote: > Looks good - thanks. I'll sponsor for you. > > David > > On 13/01/2018 11:05 PM, gary.adams at oracle.com wrote: >> Webrev updated with buffered reader lines() suggested by David. >> >> ?? http://cr.openjdk.java.net/~gadams/8031482/webrev.01/ >> >> On 1/11/18 11:28 AM, Gary Adams wrote: >>> Here's a simple fix to the split pattern when output lines are using >>> mixed line >>> separators in the same outputstream . e.g. split("\r\n|\n") >>> >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8031482 >>> ? Webrev: http://cr.openjdk.java.net/~gadams/JDK-8031482 >>> >>> testing in progress ... >> >> From amit.sapre at oracle.com Mon Jan 15 05:50:47 2018 From: amit.sapre at oracle.com (Amit Sapre) Date: Sun, 14 Jan 2018 21:50:47 -0800 (PST) Subject: RFR : JDK-8175542 - JMX: Not enough JDP packets received In-Reply-To: <3f620dba-b724-a80d-9f1f-3f5f045a0686@oracle.com> References: <2b05b6b7-e731-7bf0-83b9-cdb2a4252d84@oracle.com> <892d6f86-fa15-4da4-9318-101d87253751@default> <6b1a939e-badf-477c-8a5f-253476022de0@default> <3f620dba-b724-a80d-9f1f-3f5f045a0686@oracle.com> Message-ID: Thanks Harsha & David for the review. I agree that this fix may not address all the other scenarios which you mentioned. Thanks for bringing it. This fix is an attempt for making sure that tests reports pass if desired number of packets are received. David, I will added all your suggestions to this bug for further reference, in case we hit another timeout issue. Thanks, Amit > -----Original Message----- > From: David Holmes > Sent: Thursday, January 11, 2018 12:39 PM > To: Amit Sapre; Harsha wardhana B; serviceability-dev at openjdk.java.net > Subject: Re: RFR : JDK-8175542 - JMX: Not enough JDP packets received > > Hi Amit, Harsha, > > On 11/01/2018 4:24 PM, Amit Sapre wrote: > > Hello, > > > > Ping. Can somebody review this code changes ? > > I took a look. If I understand correctly the way the test works is that it sets up > a socket timeout of "timeout" - to be applied to the > receive() call - and then allows 20% on top of that value for the overall > execution time (between the recording of the start time and the check of > hasTestLivedLongEnough()). The problem we see is that if the > receive() and related processing takes us past the end deadline then we > report a timeout, even though we actually managed to complete the test > logic successfully. The fix simply checks for success before checking for the > overall timeout - that seems reasonable. > > The only concern I'd have - and there's no way to completely mitigate this - is > that if the logging+connection+creation+receive combined take a ridiculously > long time (but within the overall jtreg timeout) then we won't notice as long > as the receive+packet-processing completes okay. > > Two things I'd do in the future (if this starts timing out again) before changing > the overall timeout-factor would be to try: > > a) recording the start time just before the loop, instead of before the logging > and the socket connection and Datagram creation**; and/or > > b) changing the timeout overhead allowance from 20% to, say, 30%. > > ** this has the same problem of hiding unexpected delays in the > logging+connection etc. > > But the proposed fix seems adequate for now. > > Thanks, > David > > > Thanks, > > > > Amit > > > > *From:*Amit Sapre > > *Sent:* Wednesday, January 03, 2018 5:54 PM > > *To:* Harsha wardhana B; serviceability-dev at openjdk.java.net > > *Subject:* RE: RFR : JDK-8175542 - JMX: Not enough JDP packets > > received > > > > Thanks Harsha for the inputs. > > > > I made changes in this webrev : > > http://cr.openjdk.java.net/~asapre/webrev/2018/JDK- > 8175542/webrev.01/ > > > > Thanks, > > > > Amit > > > > *From:*Harsha Wardhana B > > *Sent:* Wednesday, December 13, 2017 5:32 PM > > *To:* serviceability-dev at openjdk.java.net > > > > *Subject:* Re: RFR : JDK-8175542 - JMX: Not enough JDP packets > > received > > > > Hi Amit, > > > > Increasing the timeout 'TIME_OUT_FACTOR' will increase both socket and > > test-case timeout. The test passed as can be seen from the log, but > > because of the race-condition: hasTestLivedLongEnough() checked before > > shouldContinue(), the test was declared failed because of time-out. > > > > One possible fix would be to change line 80 to, > > > > ??? ??????????? if (shouldContinue() && hasTestLivedLongEnough()) > > > > Thanks > > > > Harsha > > > > On Wednesday 13 December 2017 11:03 AM, Amit Sapre wrote: > > > > Hello, > > > > Please review the timeout fix for this bug. > > > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8175542 > > > > Webrev : > > > > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > 8175542/webrev.00/ > > 8175542/webrev.0 > > 0/> > > > > Thanks, > > > > Amit > > From serguei.spitsyn at oracle.com Mon Jan 15 09:00:32 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 15 Jan 2018 01:00:32 -0800 Subject: JDK-8187447: 2081 doc issues in jvmti.html In-Reply-To: <416839f1-4307-ec13-9bf2-b19734cb64b4@oracle.com> References: <416839f1-4307-ec13-9bf2-b19734cb64b4@oracle.com> Message-ID: <600e5039-b538-9b4c-ea51-83dafc25ba65@oracle.com> Alex, Looks great! Thank you for the update! Serguei On 1/12/18 17:05, Alex Menkov wrote: > Updated the fix after offline discussion with Serguei: > http://cr.openjdk.java.net/~amenkov/8187447/webrev.01/ > > changes: > rollback replacement

with in jvmti.xml, > handle the case by transform in jvmti.xsl > > Resulting jvmti.html is exactly the same. > > --alex > > On 01/11/2018 17:21, Alex Menkov wrote: >> Hi, >> >> Please review a fix for doc issue. >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8187447 >> webrev: http://cr.openjdk.java.net/~amenkov/8187447/webrev/ >> >> old jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti_0.html >> new jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti.html >> >> specdiff reports no changes: >> http://cr.openjdk.java.net/~amenkov/8187447/specdiff/diff.html >> >> The fix: >> - converts jvmti.html from HTML4 to HTML5; >> - fixes all errors and almost all warnings reported by tidy and W3C >> HTML Validator: >> ?? - empty

; >> ?? - unsupported attributes (align, border, width, cellpadding, >> cellspacing, noshade, size, bgcolor, type); >> ?? -

without nested
; >> ?? - with "name" attribute; >> ?? - table with column with no cells beginning in it (all cells have >> colspan=2); >> - adds "lang" attribute for (accessibility issue). >> >> The only remaining warning (reported by W3C HTML Validator) is >> ?? Warning: Documents should not use about:legacy-compat, except if >> generated by legacy systems that can't output the standard > html> doctype. >> This is expected as the DOCTYPE legacy string >> (http://w3c.github.io/html/single-page.html#doctype-legacy-string) >> was added to HTML5 standard to handle issue with XLST which cannot >> produce standard doctype. >> >> --alex From egor.ushakov at jetbrains.com Mon Jan 15 09:07:37 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Mon, 15 Jan 2018 12:07:37 +0300 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <0dda82e0-79e9-259f-b792-ab78d7d09178@oracle.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> <85e0911a375147feb43eb499db0442b6@sap.com> <0dda82e0-79e9-259f-b792-ab78d7d09178@oracle.com> Message-ID: <1b8d581d-c8af-1ead-6bcf-32b5fde110fb@jetbrains.com> Guys, thank you all for your comments! I'm a little bit lost now, how do we proceed? On 02-Jan-18 12:17, David Holmes wrote: > On 2/01/2018 6:21 PM, Langer, Christoph wrote: >> Hi David, >> >> thanks for pointing this out. I see what you mean. >> >> However, you were the one who brought up the point that rather the >> Location interface should specify the means to compare two Locations :) > > All I meant by that is that Location should _specify_ what it means to > compare two Locations. Any interface (or class for that matter) that > implements Comparable should provide an overriding specification for > compareTo. > >> And that would be an interface default method - or would there be >> another way? I guess, as there are no generics involved, the >> overloading instead of overriding thing should at least be more >> obvious for other implementers of the Location interface. But, for >> sure, I'm leaving the decision whether the default interface is the >> right thing here or not to better language and jdi experts than I >> am.? Egor's original proposal should work well, too, and is >> definitely less obtrusive. > > Yeah I'm going to punt on this one too. :) > >> BTW: your suggested change in MirrorImpl to go from "protected >> VirtualMachineImpl vm;" to "protected VirtualMachine vm;" would not >> really work out as VirtualMachineImpl extends MirrorImpl and in there >> VirtualMachineImpl is definitely needed. It's really a bit weird... > > Thanks for checking. Despite the use of interfaces and classes this > stuff doesn't really seem to be that amenable to supporting > alternative implementations of the interfaces. > > Cheers, > David > >> Best regards >> Christoph >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 2. Januar 2018 08:31 >> To: Langer, Christoph ; Egor Ushakov >> ; serguei.spitsyn at oracle.com; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR: cleanup - removed unneeded casts in jdi >> >> Hi Christoph, >> >> On 2/01/2018 4:41 PM, Langer, Christoph wrote: >>> Hi Egor, David and Serguei, >>> >>> I had a look at this, too. I would think this really calls out for a >>> ?public default int compareTo(Location other) {?}? in Location.java >> >> I think this could run into the "overloads instead of overrides" problem >> that Brian describes here: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050060.html >> >> >> ... unsure. But this would need a CSR request any way so hopefully any >> issues with doing this would be caught there. >> >> I'm very wary of adding default methods, though this may be such a >> little used interface that it's not really an issue. >> >> Cheers, >> David >> >>> which uses the implementation out of LocationImpl.java. That way, all >>> the suggested improvements for MirrorImpl.java can be done as well. And >>> other implementers of Location, such as IntelliJ?s >>> GeneratedLocation.java, would still build and won?t be necessarily >>> wrong >>> but could probably gradually remove their compareTo methods. >>> >>> As for checking for the same VM within Location comparison, e.g. by >>> using the equals() method, I guess this can be added. At least it >>> should >>> not add a notable cost. But I suggest to do it with a separate change, >>> in case it turns out to be not a good idea and one needs to revert it. >>> >>> @Egor: Would you mind to create an updated Webrev with an interface >>> default method? >>> >>> Best regards >>> >>> Christoph >>> >>> *From:*serviceability-dev >>> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of >>> *Egor >>> Ushakov >>> *Sent:* Montag, 25. Dezember 2017 12:30 >>> *To:* serguei.spitsyn at oracle.com; David Holmes >>> ; serviceability-dev at openjdk.java.net >>> *Subject:* Re: RFR: cleanup - removed unneeded casts in jdi >>> >>> Thanks for your comments! >>> >>> I'll try to provide more details: >>> We have our own Location implementaion in IDEA code: >>> GeneratedLocation.java >>> >>> >>> which is not intended to be used inside the jdi, but mostly to mock >>> Location in our own APIs like PositionManager.java >>> >>> >>> Unfortunately some implementations keep the provided Location objects >>> (both LocationImpl and ours) in collections (maybe sorted) so we >>> have to >>> prevent cast exceptions from compareTo somehow. >>> Hope it helps. >>> >>> Egor >>> >>> On 24-Dec-17 03:32, serguei.spitsyn at oracle.com >>> wrote: >>> >>> ???? Hi David, >>> >>> ???? Thank you for the explanations! >>> ???? I've got your points. >>> >>> >>> ???? On 12/23/17 15:32, David Holmes wrote: >>> >>> ???????? Hi Serguei, >>> >>> ???????? On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com >>> ???????? wrote: >>> >>> ???????????? Hi Egor and David, >>> >>> >>> ???????????? Egor, >>> >>> ???????????? The fix looks good in general. >>> ???????????? I've filed bug: >>> ???????????? https://bugs.openjdk.java.net/browse/JDK-8194143 >>> ????????????? ???? remove unneeded casts in LocationImpl and MirrorImpl >>> ???????????? classes >>> >>> >>> ???????????? On 12/22/17 13:06, David Holmes wrote: >>> >>> ???????????????? Hi Egor, >>> >>> ???????????????? On 23/12/2017 1:32 AM, Egor Ushakov wrote: >>> >>> ???????????????????? Hi all, >>> >>> ???????????????????? could you please review and sponsor this small >>> ???????????????????? cleanup removing unneeded casts in jdi >>> LocationImpl >>> ???????????????????? and MirrorImpl. >>> ???????????????????? They were preventing creating custom Location and >>> ???????????????????? Mirror implementations used for tests and IDEA >>> ???????????????????? debugger impl. >>> http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>> >>> >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java >>> >>> >>> ???????????????? !???? public int compareTo(Location object) { >>> ???????????????? -??????? LocationImpl other = (LocationImpl)object; >>> >>> ???????????????? The existing code is somewhat suspect as the Location >>> ???????????????? interface implements Comparable but it does not >>> specify >>> ???????????????? what it means to compare two Locations! That's a >>> bug in >>> ???????????????? itself. >>> >>> >>> ???????????? Not sure, if it is really needed as it is abstract. >>> ???????????? We could say: An implementation of the Location is >>> expected >>> ???????????? to specify it. >>> >>> >>> ???????? That makes it impossible to compare different >>> implementations of >>> ???????? the Location interface. The functionality has to be >>> specified by >>> ???????? the interface. >>> >>> >>> ???? We probably never needed to compare them before. >>> ???? But such comparison can be needed for an IDE that has a deal with >>> ???? different JDI implementations. >>> >>> >>> >>> ???????????????? LocationImpl has decided how to compare two >>> ???????????????? LocaltionImp's (but doesn't even check they are in the >>> ???????????????? same VirtualMachine!). >>> >>> >>> ???????????? Nice catch! >>> ???????????? Interesting... >>> ???????????? Should comparing of locations from different mirrors be a >>> ???????????? no-op? >>> ???????????? Not sure if it would be right to throw a >>> VMMismatchException >>> ???????????? in such cases. >>> >>> >>> ???????? Not sure - without knowing why we need to compare Locations >>> it's >>> ???????? hard to say. >>> >>> >>> ???? Ok. >>> >>> >>> >>> ???????????????? Can we generalize that to accommodate other Location >>> ???????????????? implementations?Your change allows for this to happen, >>> ???????????????? but it will only work as expected if the other >>> Location >>> ???????????????? implementations use the same comparison basis as >>> ???????????????? LocationImpl - which is unspecified. >>> >>> >>> ???????????? It is not clear, what you mean here. >>> ???????????? What are the other Location implementations? >>> >>> >>> ???????? The ones that Egor is implementing and the reason for this bug >>> ???????? report. >>> >>> >>> ???? It is not clear to me why do they need their own Location >>> ???? implementation. >>> >>> >>> >>> ???????????? A JDI implementation normally has one base >>> implementation of >>> ???????????? the Location. >>> ???????????? What would be a need to have multiple? >>> >>> >>> ???????? Egor indicated it was for use in testing and the IDEA >>> debugger. >>> ???????? It's apparent they have their own implementation of Location, >>> ???????? but these instances have to interact with the default >>> ???????? LocationImpl implementations - else this bug report would >>> not be >>> ???????? needed. >>> >>> >>> ???? Will need to look at it more closely after NY. >>> ???? I'm going to vacation in a couple of hours until the Jan 3-rd. >>> ???? Will probably have a limited internet access there. >>> >>> ???? I wish you, guys, happy Xmas and New Year and nice Holidays! >>> >>> ???? Thanks, >>> ???? Serguei >>> >>> >>> >>> >>> ???????? Cheers, >>> ???????? David >>> >>> >>> ???????????? And different JDI implementations are not supposed to >>> ???????????? interact with each other, are they? >>> >>> >>> >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java >>> >>> ???????????????? Change looks good. It would also seem that now this >>> ???????????????? change is made that this: >>> >>> ????????????????? ? 37???? protected VirtualMachineImpl vm; >>> ????????????????? ? 38 >>> ????????????????? ? 39???? MirrorImpl(VirtualMachine aVm) { >>> ????????????????? ? 40???????? super(); >>> ????????????????? ? 41 >>> ????????????????? ? 42???????? // Yes, its a bit of a hack. But by >>> doing >>> ???????????????? it this >>> ????????????????? ? 43???????? // way, this is the only place we >>> have to >>> ???????????????? change >>> ????????????????? ? 44???????? // typing to substitute a new impl. >>> ????????????????? ? 45???????? vm = (VirtualMachineImpl)aVm; >>> >>> ???????????????? might reduce to: >>> >>> ????????????????? ? 37???? protected VirtualMachine vm; >>> ????????????????? ? 38 >>> ????????????????? ? 39???? MirrorImpl(VirtualMachine aVm) { >>> ????????????????? ? 40???????? super(); >>> ????????????????? ? 41???????? vm = aVm; >>> >>> ???????????????? if we no longer depend on it being VirtualMachineImpl >>> ???????????????? ... and neither do subclasses. >>> >>> >>> ???????????? Good suggestion. >>> >>> >>> ???????????? Thanks, >>> ???????????? Serguei >>> >>> >>> >>> ???????????????? David >>> ???????????????? ----- >>> >>> >>> ???????????????????? I do not have rights to create JDK bug report >>> ???????????????????? directly, please create it if it is needed for the >>> ???????????????????? procedure. >>> >>> ???????????????????? Thanks! >>> >>> >>> >>> -- >>> >>> 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 david.holmes at oracle.com Tue Jan 16 03:47:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Jan 2018 13:47:08 +1000 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <1b8d581d-c8af-1ead-6bcf-32b5fde110fb@jetbrains.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> <85e0911a375147feb43eb499db0442b6@sap.com> <0dda82e0-79e9-259f-b792-ab78d7d09178@oracle.com> <1b8d581d-c8af-1ead-6bcf-32b5fde110fb@jetbrains.com> Message-ID: Hi Egor, On 15/01/2018 7:07 PM, Egor Ushakov wrote: > Guys, thank you all for your comments! I'm a little bit lost now, how do > we proceed? I think your proposed changes can be taken as is. They have highlighted some deficiencies in the existing API and implementation, but we don't need to try and solve that problem now (or even at all). You'll need a sponsor from the serviceability team (Hi Serguei!) Thanks, David > > > On 02-Jan-18 12:17, David Holmes wrote: >> On 2/01/2018 6:21 PM, Langer, Christoph wrote: >>> Hi David, >>> >>> thanks for pointing this out. I see what you mean. >>> >>> However, you were the one who brought up the point that rather the >>> Location interface should specify the means to compare two Locations :) >> >> All I meant by that is that Location should _specify_ what it means to >> compare two Locations. Any interface (or class for that matter) that >> implements Comparable should provide an overriding specification for >> compareTo. >> >>> And that would be an interface default method - or would there be >>> another way? I guess, as there are no generics involved, the >>> overloading instead of overriding thing should at least be more >>> obvious for other implementers of the Location interface. But, for >>> sure, I'm leaving the decision whether the default interface is the >>> right thing here or not to better language and jdi experts than I >>> am.? Egor's original proposal should work well, too, and is >>> definitely less obtrusive. >> >> Yeah I'm going to punt on this one too. :) >> >>> BTW: your suggested change in MirrorImpl to go from "protected >>> VirtualMachineImpl vm;" to "protected VirtualMachine vm;" would not >>> really work out as VirtualMachineImpl extends MirrorImpl and in there >>> VirtualMachineImpl is definitely needed. It's really a bit weird... >> >> Thanks for checking. Despite the use of interfaces and classes this >> stuff doesn't really seem to be that amenable to supporting >> alternative implementations of the interfaces. >> >> Cheers, >> David >> >>> Best regards >>> Christoph >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 2. Januar 2018 08:31 >>> To: Langer, Christoph ; Egor Ushakov >>> ; serguei.spitsyn at oracle.com; >>> serviceability-dev at openjdk.java.net >>> Subject: Re: RFR: cleanup - removed unneeded casts in jdi >>> >>> Hi Christoph, >>> >>> On 2/01/2018 4:41 PM, Langer, Christoph wrote: >>>> Hi Egor, David and Serguei, >>>> >>>> I had a look at this, too. I would think this really calls out for a >>>> ?public default int compareTo(Location other) {?}? in Location.java >>> >>> I think this could run into the "overloads instead of overrides" problem >>> that Brian describes here: >>> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050060.html >>> >>> >>> ... unsure. But this would need a CSR request any way so hopefully any >>> issues with doing this would be caught there. >>> >>> I'm very wary of adding default methods, though this may be such a >>> little used interface that it's not really an issue. >>> >>> Cheers, >>> David >>> >>>> which uses the implementation out of LocationImpl.java. That way, all >>>> the suggested improvements for MirrorImpl.java can be done as well. And >>>> other implementers of Location, such as IntelliJ?s >>>> GeneratedLocation.java, would still build and won?t be necessarily >>>> wrong >>>> but could probably gradually remove their compareTo methods. >>>> >>>> As for checking for the same VM within Location comparison, e.g. by >>>> using the equals() method, I guess this can be added. At least it >>>> should >>>> not add a notable cost. But I suggest to do it with a separate change, >>>> in case it turns out to be not a good idea and one needs to revert it. >>>> >>>> @Egor: Would you mind to create an updated Webrev with an interface >>>> default method? >>>> >>>> Best regards >>>> >>>> Christoph >>>> >>>> *From:*serviceability-dev >>>> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of >>>> *Egor >>>> Ushakov >>>> *Sent:* Montag, 25. Dezember 2017 12:30 >>>> *To:* serguei.spitsyn at oracle.com; David Holmes >>>> ; serviceability-dev at openjdk.java.net >>>> *Subject:* Re: RFR: cleanup - removed unneeded casts in jdi >>>> >>>> Thanks for your comments! >>>> >>>> I'll try to provide more details: >>>> We have our own Location implementaion in IDEA code: >>>> GeneratedLocation.java >>>> >>>> >>>> which is not intended to be used inside the jdi, but mostly to mock >>>> Location in our own APIs like PositionManager.java >>>> >>>> >>>> Unfortunately some implementations keep the provided Location objects >>>> (both LocationImpl and ours) in collections (maybe sorted) so we >>>> have to >>>> prevent cast exceptions from compareTo somehow. >>>> Hope it helps. >>>> >>>> Egor >>>> >>>> On 24-Dec-17 03:32, serguei.spitsyn at oracle.com >>>> wrote: >>>> >>>> ???? Hi David, >>>> >>>> ???? Thank you for the explanations! >>>> ???? I've got your points. >>>> >>>> >>>> ???? On 12/23/17 15:32, David Holmes wrote: >>>> >>>> ???????? Hi Serguei, >>>> >>>> ???????? On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com >>>> ???????? wrote: >>>> >>>> ???????????? Hi Egor and David, >>>> >>>> >>>> ???????????? Egor, >>>> >>>> ???????????? The fix looks good in general. >>>> ???????????? I've filed bug: >>>> ???????????? https://bugs.openjdk.java.net/browse/JDK-8194143 >>>> ????????????? ???? remove unneeded casts in LocationImpl and MirrorImpl >>>> ???????????? classes >>>> >>>> >>>> ???????????? On 12/22/17 13:06, David Holmes wrote: >>>> >>>> ???????????????? Hi Egor, >>>> >>>> ???????????????? On 23/12/2017 1:32 AM, Egor Ushakov wrote: >>>> >>>> ???????????????????? Hi all, >>>> >>>> ???????????????????? could you please review and sponsor this small >>>> ???????????????????? cleanup removing unneeded casts in jdi >>>> LocationImpl >>>> ???????????????????? and MirrorImpl. >>>> ???????????????????? They were preventing creating custom Location and >>>> ???????????????????? Mirror implementations used for tests and IDEA >>>> ???????????????????? debugger impl. >>>> http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>> >>>> >>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java >>>> >>>> >>>> ???????????????? !???? public int compareTo(Location object) { >>>> ???????????????? -??????? LocationImpl other = (LocationImpl)object; >>>> >>>> ???????????????? The existing code is somewhat suspect as the Location >>>> ???????????????? interface implements Comparable but it does not >>>> specify >>>> ???????????????? what it means to compare two Locations! That's a >>>> bug in >>>> ???????????????? itself. >>>> >>>> >>>> ???????????? Not sure, if it is really needed as it is abstract. >>>> ???????????? We could say: An implementation of the Location is >>>> expected >>>> ???????????? to specify it. >>>> >>>> >>>> ???????? That makes it impossible to compare different >>>> implementations of >>>> ???????? the Location interface. The functionality has to be >>>> specified by >>>> ???????? the interface. >>>> >>>> >>>> ???? We probably never needed to compare them before. >>>> ???? But such comparison can be needed for an IDE that has a deal with >>>> ???? different JDI implementations. >>>> >>>> >>>> >>>> ???????????????? LocationImpl has decided how to compare two >>>> ???????????????? LocaltionImp's (but doesn't even check they are in the >>>> ???????????????? same VirtualMachine!). >>>> >>>> >>>> ???????????? Nice catch! >>>> ???????????? Interesting... >>>> ???????????? Should comparing of locations from different mirrors be a >>>> ???????????? no-op? >>>> ???????????? Not sure if it would be right to throw a >>>> VMMismatchException >>>> ???????????? in such cases. >>>> >>>> >>>> ???????? Not sure - without knowing why we need to compare Locations >>>> it's >>>> ???????? hard to say. >>>> >>>> >>>> ???? Ok. >>>> >>>> >>>> >>>> ???????????????? Can we generalize that to accommodate other Location >>>> ???????????????? implementations?Your change allows for this to happen, >>>> ???????????????? but it will only work as expected if the other >>>> Location >>>> ???????????????? implementations use the same comparison basis as >>>> ???????????????? LocationImpl - which is unspecified. >>>> >>>> >>>> ???????????? It is not clear, what you mean here. >>>> ???????????? What are the other Location implementations? >>>> >>>> >>>> ???????? The ones that Egor is implementing and the reason for this bug >>>> ???????? report. >>>> >>>> >>>> ???? It is not clear to me why do they need their own Location >>>> ???? implementation. >>>> >>>> >>>> >>>> ???????????? A JDI implementation normally has one base >>>> implementation of >>>> ???????????? the Location. >>>> ???????????? What would be a need to have multiple? >>>> >>>> >>>> ???????? Egor indicated it was for use in testing and the IDEA >>>> debugger. >>>> ???????? It's apparent they have their own implementation of Location, >>>> ???????? but these instances have to interact with the default >>>> ???????? LocationImpl implementations - else this bug report would >>>> not be >>>> ???????? needed. >>>> >>>> >>>> ???? Will need to look at it more closely after NY. >>>> ???? I'm going to vacation in a couple of hours until the Jan 3-rd. >>>> ???? Will probably have a limited internet access there. >>>> >>>> ???? I wish you, guys, happy Xmas and New Year and nice Holidays! >>>> >>>> ???? Thanks, >>>> ???? Serguei >>>> >>>> >>>> >>>> >>>> ???????? Cheers, >>>> ???????? David >>>> >>>> >>>> ???????????? And different JDI implementations are not supposed to >>>> ???????????? interact with each other, are they? >>>> >>>> >>>> >>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java >>>> >>>> ???????????????? Change looks good. It would also seem that now this >>>> ???????????????? change is made that this: >>>> >>>> ????????????????? ? 37???? protected VirtualMachineImpl vm; >>>> ????????????????? ? 38 >>>> ????????????????? ? 39???? MirrorImpl(VirtualMachine aVm) { >>>> ????????????????? ? 40???????? super(); >>>> ????????????????? ? 41 >>>> ????????????????? ? 42???????? // Yes, its a bit of a hack. But by >>>> doing >>>> ???????????????? it this >>>> ????????????????? ? 43???????? // way, this is the only place we >>>> have to >>>> ???????????????? change >>>> ????????????????? ? 44???????? // typing to substitute a new impl. >>>> ????????????????? ? 45???????? vm = (VirtualMachineImpl)aVm; >>>> >>>> ???????????????? might reduce to: >>>> >>>> ????????????????? ? 37???? protected VirtualMachine vm; >>>> ????????????????? ? 38 >>>> ????????????????? ? 39???? MirrorImpl(VirtualMachine aVm) { >>>> ????????????????? ? 40???????? super(); >>>> ????????????????? ? 41???????? vm = aVm; >>>> >>>> ???????????????? if we no longer depend on it being VirtualMachineImpl >>>> ???????????????? ... and neither do subclasses. >>>> >>>> >>>> ???????????? Good suggestion. >>>> >>>> >>>> ???????????? Thanks, >>>> ???????????? Serguei >>>> >>>> >>>> >>>> ???????????????? David >>>> ???????????????? ----- >>>> >>>> >>>> ???????????????????? I do not have rights to create JDK bug report >>>> ???????????????????? directly, please create it if it is needed for the >>>> ???????????????????? procedure. >>>> >>>> ???????????????????? Thanks! >>>> >>>> >>>> >>>> -- >>>> >>>> Egor Ushakov >>>> >>>> Software Developer >>>> >>>> JetBrains >>>> >>>> http://www.jetbrains.com >>>> >>>> The Drive to Develop >>>> > From goetz.lindenmaier at sap.com Tue Jan 16 07:47:41 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 16 Jan 2018 07:47:41 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help Message-ID: Hi, The CSR for this change is approved now. https://bugs.openjdk.java.net/browse/JDK-8191477 If there aren't any more objections, I will push this. Webrev rebased and with updated 2018 copyright messages: http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.08/ Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Jan 16 20:11:10 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 16 Jan 2018 12:11:10 -0800 Subject: JDK-8187447: 2081 doc issues in jvmti.html In-Reply-To: <88A31E71-3BEE-4D38-B8B8-1BC57D393026@oracle.com> References: <88A31E71-3BEE-4D38-B8B8-1BC57D393026@oracle.com> Message-ID: Hi Alex, The fix looks good. The only question I have is regarding the changes in jvmti.xml where
element was introduced, e.g.: -
+
element indicates a block of text quoted from an external source so if this element was used here for indentation purposes only probably it makes sense to consider using a regular
element instead? For example:
some content
Thanks! Best regards, Daniil On 1/12/18, 5:06 PM, "serviceability-dev on behalf of Alex Menkov" wrote: Updated the fix after offline discussion with Serguei: http://cr.openjdk.java.net/~amenkov/8187447/webrev.01/ changes: rollback replacement

with in jvmti.xml, handle the case by transform in jvmti.xsl Resulting jvmti.html is exactly the same. --alex On 01/11/2018 17:21, Alex Menkov wrote: > Hi, > > Please review a fix for doc issue. > > jira: https://bugs.openjdk.java.net/browse/JDK-8187447 > webrev: http://cr.openjdk.java.net/~amenkov/8187447/webrev/ > > old jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti_0.html > new jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti.html > > specdiff reports no changes: > http://cr.openjdk.java.net/~amenkov/8187447/specdiff/diff.html > > The fix: > - converts jvmti.html from HTML4 to HTML5; > - fixes all errors and almost all warnings reported by tidy and W3C HTML > Validator: > - empty

; > - unsupported attributes (align, border, width, cellpadding, > cellspacing, noshade, size, bgcolor, type); > -

without nested
; > - with "name" attribute; > - table with column with no cells beginning in it (all cells have > colspan=2); > - adds "lang" attribute for (accessibility issue). > > The only remaining warning (reported by W3C HTML Validator) is > Warning: Documents should not use about:legacy-compat, except if > generated by legacy systems that can't output the standard html> doctype. > This is expected as the DOCTYPE legacy string > (http://w3c.github.io/html/single-page.html#doctype-legacy-string) was > added to HTML5 standard to handle issue with XLST which cannot produce > standard doctype. > > --alex From alexey.menkov at oracle.com Tue Jan 16 21:00:50 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 16 Jan 2018 13:00:50 -0800 Subject: JDK-8187447: 2081 doc issues in jvmti.html In-Reply-To: References: <88A31E71-3BEE-4D38-B8B8-1BC57D393026@oracle.com> Message-ID: On 01/16/2018 12:11, Daniil Titov wrote: > Hi Alex, > > The fix looks good. The only question I have is regarding the changes in jvmti.xml where
element was introduced, e.g.: > -
> +
> >
element indicates a block of text quoted from an external source so if this element was used here for indentation purposes only probably it makes sense to consider using a regular
element instead? I used
for consistency - in other similar places
is used for indentation. --alex > > For example:
some content
> > Thanks! > > Best regards, > Daniil > > > On 1/12/18, 5:06 PM, "serviceability-dev on behalf of Alex Menkov" wrote: > > Updated the fix after offline discussion with Serguei: > http://cr.openjdk.java.net/~amenkov/8187447/webrev.01/ > > changes: > rollback replacement

with in jvmti.xml, > handle the case by transform in jvmti.xsl > > Resulting jvmti.html is exactly the same. > > --alex > > On 01/11/2018 17:21, Alex Menkov wrote: > > Hi, > > > > Please review a fix for doc issue. > > > > jira: https://bugs.openjdk.java.net/browse/JDK-8187447 > > webrev: http://cr.openjdk.java.net/~amenkov/8187447/webrev/ > > > > old jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti_0.html > > new jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti.html > > > > specdiff reports no changes: > > http://cr.openjdk.java.net/~amenkov/8187447/specdiff/diff.html > > > > The fix: > > - converts jvmti.html from HTML4 to HTML5; > > - fixes all errors and almost all warnings reported by tidy and W3C HTML > > Validator: > > - empty

; > > - unsupported attributes (align, border, width, cellpadding, > > cellspacing, noshade, size, bgcolor, type); > > -

without nested
; > > - with "name" attribute; > > - table with column with no cells beginning in it (all cells have > > colspan=2); > > - adds "lang" attribute for (accessibility issue). > > > > The only remaining warning (reported by W3C HTML Validator) is > > Warning: Documents should not use about:legacy-compat, except if > > generated by legacy systems that can't output the standard > html> doctype. > > This is expected as the DOCTYPE legacy string > > (http://w3c.github.io/html/single-page.html#doctype-legacy-string) was > > added to HTML5 standard to handle issue with XLST which cannot produce > > standard doctype. > > > > --alex > > > > From daniil.x.titov at oracle.com Tue Jan 16 21:20:25 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 16 Jan 2018 13:20:25 -0800 Subject: JDK-8187447: 2081 doc issues in jvmti.html In-Reply-To: References: <88A31E71-3BEE-4D38-B8B8-1BC57D393026@oracle.com> Message-ID: Got it. +1 Thanks! Best regards, Daniil On 1/16/18, 1:00 PM, "Alex Menkov" wrote: On 01/16/2018 12:11, Daniil Titov wrote: > Hi Alex, > > The fix looks good. The only question I have is regarding the changes in jvmti.xml where
element was introduced, e.g.: > -
> +
> >
element indicates a block of text quoted from an external source so if this element was used here for indentation purposes only probably it makes sense to consider using a regular
element instead? I used
for consistency - in other similar places
is used for indentation. --alex > > For example:
some content
> > Thanks! > > Best regards, > Daniil > > > On 1/12/18, 5:06 PM, "serviceability-dev on behalf of Alex Menkov" wrote: > > Updated the fix after offline discussion with Serguei: > http://cr.openjdk.java.net/~amenkov/8187447/webrev.01/ > > changes: > rollback replacement

with in jvmti.xml, > handle the case by transform in jvmti.xsl > > Resulting jvmti.html is exactly the same. > > --alex > > On 01/11/2018 17:21, Alex Menkov wrote: > > Hi, > > > > Please review a fix for doc issue. > > > > jira: https://bugs.openjdk.java.net/browse/JDK-8187447 > > webrev: http://cr.openjdk.java.net/~amenkov/8187447/webrev/ > > > > old jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti_0.html > > new jvmti.html: http://cr.openjdk.java.net/~amenkov/8187447/jvmti.html > > > > specdiff reports no changes: > > http://cr.openjdk.java.net/~amenkov/8187447/specdiff/diff.html > > > > The fix: > > - converts jvmti.html from HTML4 to HTML5; > > - fixes all errors and almost all warnings reported by tidy and W3C HTML > > Validator: > > - empty

; > > - unsupported attributes (align, border, width, cellpadding, > > cellspacing, noshade, size, bgcolor, type); > > -

without nested
; > > - with "name" attribute; > > - table with column with no cells beginning in it (all cells have > > colspan=2); > > - adds "lang" attribute for (accessibility issue). > > > > The only remaining warning (reported by W3C HTML Validator) is > > Warning: Documents should not use about:legacy-compat, except if > > generated by legacy systems that can't output the standard > html> doctype. > > This is expected as the DOCTYPE legacy string > > (http://w3c.github.io/html/single-page.html#doctype-legacy-string) was > > added to HTML5 standard to handle issue with XLST which cannot produce > > standard doctype. > > > > --alex > > > > From serguei.spitsyn at oracle.com Tue Jan 16 23:02:15 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 16 Jan 2018 15:02:15 -0800 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> <85e0911a375147feb43eb499db0442b6@sap.com> <0dda82e0-79e9-259f-b792-ab78d7d09178@oracle.com> <1b8d581d-c8af-1ead-6bcf-32b5fde110fb@jetbrains.com> Message-ID: <3a5b3c57-b2cd-c81c-125f-1f4982c244cc@oracle.com> Hi Egor, Just for a correct email record, could you, please, resend this RFR with a correct subject line that includes the bug number and synopsis: ? 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes Additionally, please, attach a committed patch for this fix, so I could push this fix into the jdk/hs. On 1/15/18 19:47, David Holmes wrote: > Hi Egor, > > On 15/01/2018 7:07 PM, Egor Ushakov wrote: >> Guys, thank you all for your comments! I'm a little bit lost now, how >> do we proceed? > > I think your proposed changes can be taken as is. They have > highlighted some deficiencies in the existing API and implementation, > but we don't need to try and solve that problem now (or even at all). > > You'll need a sponsor from the serviceability team (Hi Serguei!) Sure, I'll sponsor it, David! Thanks, Serguei > > Thanks, > David > >> >> >> On 02-Jan-18 12:17, David Holmes wrote: >>> On 2/01/2018 6:21 PM, Langer, Christoph wrote: >>>> Hi David, >>>> >>>> thanks for pointing this out. I see what you mean. >>>> >>>> However, you were the one who brought up the point that rather the >>>> Location interface should specify the means to compare two >>>> Locations :) >>> >>> All I meant by that is that Location should _specify_ what it means >>> to compare two Locations. Any interface (or class for that matter) >>> that implements Comparable should provide an overriding >>> specification for compareTo. >>> >>>> And that would be an interface default method - or would there be >>>> another way? I guess, as there are no generics involved, the >>>> overloading instead of overriding thing should at least be more >>>> obvious for other implementers of the Location interface. But, for >>>> sure, I'm leaving the decision whether the default interface is the >>>> right thing here or not to better language and jdi experts than I >>>> am.? Egor's original proposal should work well, too, and is >>>> definitely less obtrusive. >>> >>> Yeah I'm going to punt on this one too. :) >>> >>>> BTW: your suggested change in MirrorImpl to go from "protected >>>> VirtualMachineImpl vm;" to "protected VirtualMachine vm;" would not >>>> really work out as VirtualMachineImpl extends MirrorImpl and in >>>> there VirtualMachineImpl is definitely needed. It's really a bit >>>> weird... >>> >>> Thanks for checking. Despite the use of interfaces and classes this >>> stuff doesn't really seem to be that amenable to supporting >>> alternative implementations of the interfaces. >>> >>> Cheers, >>> David >>> >>>> Best regards >>>> Christoph >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 2. Januar 2018 08:31 >>>> To: Langer, Christoph ; Egor Ushakov >>>> ; serguei.spitsyn at oracle.com; >>>> serviceability-dev at openjdk.java.net >>>> Subject: Re: RFR: cleanup - removed unneeded casts in jdi >>>> >>>> Hi Christoph, >>>> >>>> On 2/01/2018 4:41 PM, Langer, Christoph wrote: >>>>> Hi Egor, David and Serguei, >>>>> >>>>> I had a look at this, too. I would think this really calls out for a >>>>> ?public default int compareTo(Location other) {?}? in Location.java >>>> >>>> I think this could run into the "overloads instead of overrides" >>>> problem >>>> that Brian describes here: >>>> >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050060.html >>>> >>>> >>>> ... unsure. But this would need a CSR request any way so hopefully any >>>> issues with doing this would be caught there. >>>> >>>> I'm very wary of adding default methods, though this may be such a >>>> little used interface that it's not really an issue. >>>> >>>> Cheers, >>>> David >>>> >>>>> which uses the implementation out of LocationImpl.java. That way, all >>>>> the suggested improvements for MirrorImpl.java can be done as >>>>> well. And >>>>> other implementers of Location, such as IntelliJ?s >>>>> GeneratedLocation.java, would still build and won?t be necessarily >>>>> wrong >>>>> but could probably gradually remove their compareTo methods. >>>>> >>>>> As for checking for the same VM within Location comparison, e.g. by >>>>> using the equals() method, I guess this can be added. At least it >>>>> should >>>>> not add a notable cost. But I suggest to do it with a separate >>>>> change, >>>>> in case it turns out to be not a good idea and one needs to revert >>>>> it. >>>>> >>>>> @Egor: Would you mind to create an updated Webrev with an interface >>>>> default method? >>>>> >>>>> Best regards >>>>> >>>>> Christoph >>>>> >>>>> *From:*serviceability-dev >>>>> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of >>>>> *Egor >>>>> Ushakov >>>>> *Sent:* Montag, 25. Dezember 2017 12:30 >>>>> *To:* serguei.spitsyn at oracle.com; David Holmes >>>>> ; serviceability-dev at openjdk.java.net >>>>> *Subject:* Re: RFR: cleanup - removed unneeded casts in jdi >>>>> >>>>> Thanks for your comments! >>>>> >>>>> I'll try to provide more details: >>>>> We have our own Location implementaion in IDEA code: >>>>> GeneratedLocation.java >>>>> >>>>> >>>>> which is not intended to be used inside the jdi, but mostly to mock >>>>> Location in our own APIs like PositionManager.java >>>>> >>>>> >>>>> Unfortunately some implementations keep the provided Location objects >>>>> (both LocationImpl and ours) in collections (maybe sorted) so we >>>>> have to >>>>> prevent cast exceptions from compareTo somehow. >>>>> Hope it helps. >>>>> >>>>> Egor >>>>> >>>>> On 24-Dec-17 03:32, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>> ???? Hi David, >>>>> >>>>> ???? Thank you for the explanations! >>>>> ???? I've got your points. >>>>> >>>>> >>>>> ???? On 12/23/17 15:32, David Holmes wrote: >>>>> >>>>> ???????? Hi Serguei, >>>>> >>>>> ???????? On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com >>>>> ???????? wrote: >>>>> >>>>> ???????????? Hi Egor and David, >>>>> >>>>> >>>>> ???????????? Egor, >>>>> >>>>> ???????????? The fix looks good in general. >>>>> ???????????? I've filed bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8194143 >>>>> ????????????? ???? remove unneeded casts in LocationImpl and >>>>> MirrorImpl >>>>> ???????????? classes >>>>> >>>>> >>>>> ???????????? On 12/22/17 13:06, David Holmes wrote: >>>>> >>>>> ???????????????? Hi Egor, >>>>> >>>>> ???????????????? On 23/12/2017 1:32 AM, Egor Ushakov wrote: >>>>> >>>>> ???????????????????? Hi all, >>>>> >>>>> ???????????????????? could you please review and sponsor this small >>>>> ???????????????????? cleanup removing unneeded casts in jdi >>>>> LocationImpl >>>>> ???????????????????? and MirrorImpl. >>>>> ???????????????????? They were preventing creating custom Location >>>>> and >>>>> ???????????????????? Mirror implementations used for tests and IDEA >>>>> ???????????????????? debugger impl. >>>>> http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>>> >>>>> >>>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java >>>>> >>>>> >>>>> ???????????????? !???? public int compareTo(Location object) { >>>>> ???????????????? -??????? LocationImpl other = (LocationImpl)object; >>>>> >>>>> ???????????????? The existing code is somewhat suspect as the >>>>> Location >>>>> ???????????????? interface implements Comparable but it does not >>>>> specify >>>>> ???????????????? what it means to compare two Locations! That's a >>>>> bug in >>>>> ???????????????? itself. >>>>> >>>>> >>>>> ???????????? Not sure, if it is really needed as it is abstract. >>>>> ???????????? We could say: An implementation of the Location is >>>>> expected >>>>> ???????????? to specify it. >>>>> >>>>> >>>>> ???????? That makes it impossible to compare different >>>>> implementations of >>>>> ???????? the Location interface. The functionality has to be >>>>> specified by >>>>> ???????? the interface. >>>>> >>>>> >>>>> ???? We probably never needed to compare them before. >>>>> ???? But such comparison can be needed for an IDE that has a deal >>>>> with >>>>> ???? different JDI implementations. >>>>> >>>>> >>>>> >>>>> ???????????????? LocationImpl has decided how to compare two >>>>> ???????????????? LocaltionImp's (but doesn't even check they are >>>>> in the >>>>> ???????????????? same VirtualMachine!). >>>>> >>>>> >>>>> ???????????? Nice catch! >>>>> ???????????? Interesting... >>>>> ???????????? Should comparing of locations from different mirrors >>>>> be a >>>>> ???????????? no-op? >>>>> ???????????? Not sure if it would be right to throw a >>>>> VMMismatchException >>>>> ???????????? in such cases. >>>>> >>>>> >>>>> ???????? Not sure - without knowing why we need to compare >>>>> Locations it's >>>>> ???????? hard to say. >>>>> >>>>> >>>>> ???? Ok. >>>>> >>>>> >>>>> >>>>> ???????????????? Can we generalize that to accommodate other Location >>>>> ???????????????? implementations?Your change allows for this to >>>>> happen, >>>>> ???????????????? but it will only work as expected if the other >>>>> Location >>>>> ???????????????? implementations use the same comparison basis as >>>>> ???????????????? LocationImpl - which is unspecified. >>>>> >>>>> >>>>> ???????????? It is not clear, what you mean here. >>>>> ???????????? What are the other Location implementations? >>>>> >>>>> >>>>> ???????? The ones that Egor is implementing and the reason for >>>>> this bug >>>>> ???????? report. >>>>> >>>>> >>>>> ???? It is not clear to me why do they need their own Location >>>>> ???? implementation. >>>>> >>>>> >>>>> >>>>> ???????????? A JDI implementation normally has one base >>>>> implementation of >>>>> ???????????? the Location. >>>>> ???????????? What would be a need to have multiple? >>>>> >>>>> >>>>> ???????? Egor indicated it was for use in testing and the IDEA >>>>> debugger. >>>>> ???????? It's apparent they have their own implementation of >>>>> Location, >>>>> ???????? but these instances have to interact with the default >>>>> ???????? LocationImpl implementations - else this bug report would >>>>> not be >>>>> ???????? needed. >>>>> >>>>> >>>>> ???? Will need to look at it more closely after NY. >>>>> ???? I'm going to vacation in a couple of hours until the Jan 3-rd. >>>>> ???? Will probably have a limited internet access there. >>>>> >>>>> ???? I wish you, guys, happy Xmas and New Year and nice Holidays! >>>>> >>>>> ???? Thanks, >>>>> ???? Serguei >>>>> >>>>> >>>>> >>>>> >>>>> ???????? Cheers, >>>>> ???????? David >>>>> >>>>> >>>>> ???????????? And different JDI implementations are not supposed to >>>>> ???????????? interact with each other, are they? >>>>> >>>>> >>>>> >>>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java >>>>> >>>>> ???????????????? Change looks good. It would also seem that now this >>>>> ???????????????? change is made that this: >>>>> >>>>> ????????????????? ? 37???? protected VirtualMachineImpl vm; >>>>> ????????????????? ? 38 >>>>> ????????????????? ? 39???? MirrorImpl(VirtualMachine aVm) { >>>>> ????????????????? ? 40???????? super(); >>>>> ????????????????? ? 41 >>>>> ????????????????? ? 42???????? // Yes, its a bit of a hack. But by >>>>> doing >>>>> ???????????????? it this >>>>> ????????????????? ? 43???????? // way, this is the only place we >>>>> have to >>>>> ???????????????? change >>>>> ????????????????? ? 44???????? // typing to substitute a new impl. >>>>> ????????????????? ? 45???????? vm = (VirtualMachineImpl)aVm; >>>>> >>>>> ???????????????? might reduce to: >>>>> >>>>> ????????????????? ? 37???? protected VirtualMachine vm; >>>>> ????????????????? ? 38 >>>>> ????????????????? ? 39???? MirrorImpl(VirtualMachine aVm) { >>>>> ????????????????? ? 40???????? super(); >>>>> ????????????????? ? 41???????? vm = aVm; >>>>> >>>>> ???????????????? if we no longer depend on it being >>>>> VirtualMachineImpl >>>>> ???????????????? ... and neither do subclasses. >>>>> >>>>> >>>>> ???????????? Good suggestion. >>>>> >>>>> >>>>> ???????????? Thanks, >>>>> ???????????? Serguei >>>>> >>>>> >>>>> >>>>> ???????????????? David >>>>> ???????????????? ----- >>>>> >>>>> >>>>> ???????????????????? I do not have rights to create JDK bug report >>>>> ???????????????????? directly, please create it if it is needed >>>>> for the >>>>> ???????????????????? procedure. >>>>> >>>>> ???????????????????? Thanks! >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Egor Ushakov >>>>> >>>>> Software Developer >>>>> >>>>> JetBrains >>>>> >>>>> http://www.jetbrains.com >>>>> >>>>> The Drive to Develop >>>>> >> From daniil.x.titov at oracle.com Wed Jan 17 02:31:14 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 16 Jan 2018 18:31:14 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <9EDC72A1-D0C3-4C62-A8F6-232500151A62@oracle.com> References: <9EDC72A1-D0C3-4C62-A8F6-232500151A62@oracle.com> Message-ID: <299D78E4-479B-47D8-8B19-F4C2588E7C43@oracle.com> Hello, Please review an updated fix that makes the test more extensive and includes suggested changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.02/ Thank you! Best regards, Daniil On 1/12/18, 2:26 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, It is pretty good in general. Thank you for taking care about it! Some comments though. The test case is too trivial. I'd suggest to extend it to have at least a couple of locks in the returned array. One way to do it would be to add a instance synchronized method and invoke it from the synchronized statement of the tested Thread. Then the verifyOwnedMonitors() can be invoked from this method. A couple of comments on the native agent. 72 // JNI_OnLoad has not been called yet, so can't possibly be an instance of TEST_CLASS. Could you, please, rewrite this comment? Maybe just tell that there probably was an error in loading the TEST_CLASS. What about moving the FindClass(env, TEST_CLASS) to the verifyOwnedMonitors() function? It will make the testClass variable local. 200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: stackDepthInfo[0].stack_depth should be 1.\n"); 207 fprintf(stderr, "VerifyOwnedMonitors: FAIL: monitorCount should be 1.\n"); It'd better to rephrase the messages above to tell about actual values vs expected. It normally simplifies the analysis of failures as there is no need to find what values were printed before and that they are exactly what needed for comparison. Thanks, Serguei On 1/11/18 17:45, Daniil Titov wrote: > Hello, > > Please review the following fix that adds a jtreg test for GetOwnedMonitorStackDepthInfo JVMTI function. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 > > > The tests ran successfully with Mach5. > > Best regards, > Daniil > > From egor.ushakov at jetbrains.com Wed Jan 17 09:15:00 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 17 Jan 2018 12:15:00 +0300 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes Message-ID: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> Hello, Please review and push the fix. This is a formal letter after the discussion on the alias. Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jan 17 09:35:23 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 01:35:23 -0800 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> Message-ID: An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Wed Jan 17 09:48:12 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 17 Jan 2018 12:48:12 +0300 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> Message-ID: <41fcc990-0dae-2f82-af75-9e9820c97c7a@jetbrains.com> Thanks, Serguei. We have tested this with JTreg tests already. On 17-Jan-18 12:35, serguei.spitsyn at oracle.com wrote: > Thanks, Egor! > I'll sponsor the push. > > Do I have to run the JDI tests, or already tested it with the JTreg > JDI tests? > > Thanks, > Serguei > > > On 1/17/18 01:15, Egor Ushakov wrote: >> Hello, >> >> Please review and push the fix. >> This is a formal letter after the discussion on the alias. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >> >> -- >> 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 david.holmes at oracle.com Wed Jan 17 10:24:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jan 2018 20:24:51 +1000 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> Message-ID: Hi Egor, On 17/01/2018 7:15 PM, Egor Ushakov wrote: > Hello, > > Please review and push the fix. > This is a formal letter after the discussion on the alias. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 > Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ The underlying link actually pointed to: http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 :) Real webrev looks fine. Thanks, David > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > From bob.vandette at oracle.com Wed Jan 17 16:37:32 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 17 Jan 2018 11:37:32 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers Message-ID: <22077896-E632-4153-B70E-14B6FE10C9DB@oracle.com> Here?s an updated webrev addressing the comments from David Holmes. 1. Moved new cgroup specific support from unix -> Linux and put stubs in all other OS's 2. Reduced the size of the stack arrays in perfMemory_linux.cpp There are still two outstanding issues: [serviceability] : Can we and should we remove the getFile methods in the PerfDataFile class? [core-libs]: Do you have any problems with the module info file changes impacting java.base? Details: Bug: https://bugs.openjdk.java.net/browse/JDK-8193710 Webrev: http://cr.openjdk.java.net/~bobv/8193710/webrev.01/ Summary: This changeset enables the ability to use jcmd and jps running on a Host to list the java processes that are running in docker (cgroup based) containers. I?ve tested this change by examining processes running as root on both host and in docker containers as well as under my userid using ?jps and jcmd -l?. I?ve also tested the getFile functions with a small example program that I wrote. From what I can tell, these two getFile functions are not used in the JDK sources and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! I?d really like to remove these two methods. 140 candidate = new File(f.getName(), name); < References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> Message-ID: <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> Hi Egor and David, Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. Also, I expect new webrev is based on the JDK 11 jdk/hs repository and with 2018 copyright comments updated. Thanks, Serguei On 1/17/18 02:24, David Holmes wrote: > Hi Egor, > > On 17/01/2018 7:15 PM, Egor Ushakov wrote: >> Hello, >> >> Please review and push the fix. >> This is a formal letter after the discussion on the alias. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ > > The underlying link actually pointed to: > > http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 > > :) > > Real webrev looks fine. > > Thanks, > David > >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop >> From egor.ushakov at jetbrains.com Wed Jan 17 17:32:50 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 17 Jan 2018 20:32:50 +0300 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> Message-ID: <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> Is the link http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix broken? for me it works well. attaching the patch just in case. It was created on jdk10, do I need to recreate it based on jdk11 with the 2018 copyrights? On 17-Jan-18 20:26, serguei.spitsyn at oracle.com wrote: > Hi Egor and David, > > Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. > Also, I expect new webrev is based on the JDK 11 jdk/hs repository and > with 2018 copyright comments updated. > > Thanks, > Serguei > > > On 1/17/18 02:24, David Holmes wrote: >> Hi Egor, >> >> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>> Hello, >>> >>> Please review and push the fix. >>> This is a formal letter after the discussion on the alias. >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >> >> The underlying link actually pointed to: >> >> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >> >> :) >> >> Real webrev looks fine. >> >> 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 -------------- next part -------------- --- old/src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java 2017-12-22 17:06:43.000000000 +0300 +++ new/src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java 2017-12-22 17:06:43.000000000 +0300 @@ -79,8 +79,7 @@ return method().hashCode() + (int)codeIndex(); } - public int compareTo(Location object) { - LocationImpl other = (LocationImpl)object; + public int compareTo(Location other) { int rc = method().compareTo(other.method()); if (rc == 0) { long diff = codeIndex() - other.codeIndex(); --- old/src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java 2017-12-22 17:06:44.000000000 +0300 +++ new/src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java 2017-12-22 17:06:43.000000000 +0300 @@ -26,7 +26,6 @@ package com.sun.tools.jdi; import java.util.Collection; -import java.util.Iterator; import com.sun.jdi.Mirror; import com.sun.jdi.VMMismatchException; @@ -87,12 +86,8 @@ * Throw VMMismatchException on wrong VM. */ void validateMirrors(Collection mirrors) { - Iterator iter = mirrors.iterator(); - while (iter.hasNext()) { - MirrorImpl mirror = (MirrorImpl)iter.next(); - if (!vm.equals(mirror.vm)) { - throw new VMMismatchException(mirror.toString()); - } + for (Mirror mirror : mirrors) { + validateMirror(mirror); } } @@ -101,12 +96,8 @@ * Throw VMMismatchException on wrong VM. */ void validateMirrorsOrNulls(Collection mirrors) { - Iterator iter = mirrors.iterator(); - while (iter.hasNext()) { - MirrorImpl mirror = (MirrorImpl)iter.next(); - if ((mirror != null) && !vm.equals(mirror.vm)) { - throw new VMMismatchException(mirror.toString()); - } + for (Mirror mirror : mirrors) { + validateMirrorOrNull(mirror); } } } From serguei.spitsyn at oracle.com Wed Jan 17 17:34:17 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 09:34:17 -0800 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> Message-ID: <463271c4-dd24-1d43-1d2b-c8df0f416912@oracle.com> On 1/17/18 09:26, serguei.spitsyn at oracle.com wrote: > Hi Egor and David, > > Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. Sorry, it is not fully correct. The first is the old link points to the jdk 10 related webrev with an uncommitted patch and 2017 copyright comments. > Also, I expect new webrev is based on the JDK 11 jdk/hs repository and > with 2018 copyright comments updated. Also need this patch committed with reviewers listed. Thanks, Serguei > Thanks, > Serguei > > > On 1/17/18 02:24, David Holmes wrote: >> Hi Egor, >> >> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>> Hello, >>> >>> Please review and push the fix. >>> This is a formal letter after the discussion on the alias. >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >> >> The underlying link actually pointed to: >> >> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >> >> :) >> >> Real webrev looks fine. >> >> Thanks, >> David >> >>> -- >>> Egor Ushakov >>> Software Developer >>> JetBrains >>> http://www.jetbrains.com >>> The Drive to Develop >>> > From egor.ushakov at jetbrains.com Wed Jan 17 17:36:50 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 17 Jan 2018 20:36:50 +0300 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <463271c4-dd24-1d43-1d2b-c8df0f416912@oracle.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <463271c4-dd24-1d43-1d2b-c8df0f416912@oracle.com> Message-ID: Got it, will do! BTW who are the reviewers? You and David? On 17-Jan-18 20:34, serguei.spitsyn at oracle.com wrote: > On 1/17/18 09:26, serguei.spitsyn at oracle.com wrote: >> Hi Egor and David, >> >> Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. > > Sorry, it is not fully correct. > The first is the old link points to the jdk 10 related webrev with an > uncommitted patch and 2017 copyright comments. > > >> Also, I expect new webrev is based on the JDK 11 jdk/hs repository >> and with 2018 copyright comments updated. > > Also need this patch committed with reviewers listed. > > > Thanks, > Serguei > > >> Thanks, >> Serguei >> >> >> On 1/17/18 02:24, David Holmes wrote: >>> Hi Egor, >>> >>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>> Hello, >>>> >>>> Please review and push the fix. >>>> This is a formal letter after the discussion on the alias. >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>> >>> The underlying link actually pointed to: >>> >>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>> >>> :) >>> >>> Real webrev looks fine. >>> >>> 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 From serguei.spitsyn at oracle.com Wed Jan 17 17:37:15 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 09:37:15 -0800 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> Message-ID: <55e6b92c-c7e7-f079-8b6b-fcc78b0b8e06@oracle.com> On 1/17/18 09:32, Egor Ushakov wrote: > Is the link http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix > broken? for me it works well. > attaching the patch just in case. It was my mistake this time, sorry. :( Please, see my previous message. > It was created on jdk10, do I need to recreate it based on jdk11 with > the 2018 copyrights? Yes, and it needs to be committed with the reviewers listed. Thanks, Serguei > > On 17-Jan-18 20:26, serguei.spitsyn at oracle.com wrote: >> Hi Egor and David, >> >> Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. >> Also, I expect new webrev is based on the JDK 11 jdk/hs repository >> and with 2018 copyright comments updated. >> >> Thanks, >> Serguei >> >> >> On 1/17/18 02:24, David Holmes wrote: >>> Hi Egor, >>> >>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>> Hello, >>>> >>>> Please review and push the fix. >>>> This is a formal letter after the discussion on the alias. >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>> >>> The underlying link actually pointed to: >>> >>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>> >>> :) >>> >>> Real webrev looks fine. >>> >>> Thanks, >>> David >>> >>>> -- >>>> Egor Ushakov >>>> Software Developer >>>> JetBrains >>>> http://www.jetbrains.com >>>> The Drive to Develop >>>> >> > From serguei.spitsyn at oracle.com Wed Jan 17 17:37:58 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 09:37:58 -0800 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <463271c4-dd24-1d43-1d2b-c8df0f416912@oracle.com> Message-ID: <0f469134-adc9-5597-9cbf-c15f72932330@oracle.com> On 1/17/18 09:36, Egor Ushakov wrote: > Got it, will do! > > BTW who are the reviewers? You and David? I think so. Thanks, Serguei > On 17-Jan-18 20:34, serguei.spitsyn at oracle.com wrote: >> On 1/17/18 09:26, serguei.spitsyn at oracle.com wrote: >>> Hi Egor and David, >>> >>> Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. >> >> Sorry, it is not fully correct. >> The first is the old link points to the jdk 10 related webrev with an >> uncommitted patch and 2017 copyright comments. >> >> >>> Also, I expect new webrev is based on the JDK 11 jdk/hs repository >>> and with 2018 copyright comments updated. >> >> Also need this patch committed with reviewers listed. >> >> >> Thanks, >> Serguei >> >> >>> Thanks, >>> Serguei >>> >>> >>> On 1/17/18 02:24, David Holmes wrote: >>>> Hi Egor, >>>> >>>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>>> Hello, >>>>> >>>>> Please review and push the fix. >>>>> This is a formal letter after the discussion on the alias. >>>>> >>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>> >>>> The underlying link actually pointed to: >>>> >>>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>>> >>>> :) >>>> >>>> Real webrev looks fine. >>>> >>>> Thanks, >>>> David >>>> >>>>> -- >>>>> Egor Ushakov >>>>> Software Developer >>>>> JetBrains >>>>> http://www.jetbrains.com >>>>> The Drive to Develop >>>>> >>> >> > From mandy.chung at oracle.com Wed Jan 17 18:16:35 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 17 Jan 2018 10:16:35 -0800 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: <22077896-E632-4153-B70E-14B6FE10C9DB@oracle.com> References: <22077896-E632-4153-B70E-14B6FE10C9DB@oracle.com> Message-ID: <7ea44913-4391-442f-3175-81524b106e7e@oracle.com> Hi Bob, I think the new methods in VMSupport and probablywith VMSupport.getVMTemporaryDirectory should belong to jdk.internal.jvmstat as they are specific for jvmstat and attach API to use. W.r.t VMSupportImpl, the implementation is the same for all platforms except Linux.? One option is to have a shared implementation class and instantiate an alternate implementation class, if present, using Class::forName. Another minor point is that the new getVMTemporaryDirectories method can return a List rather than an array. Mandy On 1/17/18 8:37 AM, Bob Vandette wrote: > Here?s an updated webrev addressing the comments from David Holmes. > > 1. Moved new cgroup specific support from unix -> Linux and put stubs in all other OS's > 2. Reduced the size of the stack arrays in perfMemory_linux.cpp > > > There are still two outstanding issues: > > [serviceability] : Can we and should we remove the getFile methods in the PerfDataFile class? > > [core-libs]: Do you have any problems with the module info file changes impacting java.base? > > Details: > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8193710 > > Webrev: > > http://cr.openjdk.java.net/~bobv/8193710/webrev.01/ > > Summary: > > This changeset enables the ability to use jcmd and jps running on a Host to > list the java processes that are running in docker (cgroup based) containers. > > I?ve tested this change by examining processes running as root on both host and in > docker containers as well as under my userid using ?jps and jcmd -l?. > I?ve also tested the getFile functions with a small example program that I wrote. > From what I can tell, these two getFile functions are not used in the JDK sources > and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! > I?d really like to remove these two methods. > > 140 candidate = new File(f.getName(), name); < > Here are some implementation details that I?ve added added to one of the Unix > specific source files (src/java.base/unix/classes/jdk/internal/vm/VMSupportImpl.java) > > /* Implementation Details: > * > * Java processes that run in docker containers are typically running > * under cgroups with separate pid namespaces which means that pids > * within the container are different that the pid which is visible > * from the host. The container pids typically start with 1 and > * increase. The java process running in the container will use these > * pids when creating the hsperfdata files. In order to locate java > * processes that are running in containers, we take advantage of > * the Linux proc file system which maps the containers tmp directory > * to the hosts under /proc/{hostpid}/root/tmp. We use the /proc status > * file /proc/{hostpid}/status to determine the containers pid and > * then access the hsperfdata file. The status file contains an > * entry "NSPid:" which shows the mapping from the hostpid to the > * containers pid. > * > * Example: > * > * NSPid: 24345 11 > * > * In this example process 24345 is visible from the host, > * is running under the PID namespace and has a container specific > * pid of 11. > * > * The search for Java processes is done by first looking in the > * traditional /tmp for host process hsperfdata files and then > * the search will container in every /proc/*/root/tmp directory. > * There are of course added complications to this search that > * need to be taken into account. > * > * 1. duplication of tmp directories > * > * /proc/{hostpid}/root/tmp directories exist for many processes > * that are running on a Linux kernel that has cgroups enabled even > * if they are not running in a container. To avoid this duplication, > * we compare the inode of the /proc tmp directories to /tmp and > * skip these duplicated directories. > * > * 2. Containerized processes without PID namespaces being enabled. > * > * If a container is running a Java process without namespaces being > * enabled, an hsperfdata file will only be located at > * /proc/{hostpid}/root/tmp/{hostpid}. This is handled by > * checking the last component in the path for both the hostpid > * and potential namespacepids (if one exists). > */ > > > > Bob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.vandette at oracle.com Wed Jan 17 19:08:49 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 17 Jan 2018 14:08:49 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: <7ea44913-4391-442f-3175-81524b106e7e@oracle.com> References: <22077896-E632-4153-B70E-14B6FE10C9DB@oracle.com> <7ea44913-4391-442f-3175-81524b106e7e@oracle.com> Message-ID: <28DD8D38-DF9E-448F-AF72-63062D2CF781@oracle.com> I put these new methods in VMSupport since this was the class containg the getVMTemporaryDirectory and the intention of this class was document as: /* * Support class used by JVMTI and VM attach mechanism. */ class VMSupport { I could create a new PerfDataFileImpl or jdk.internal.jvmstat.VMSupport class with a Linux specific alternate implementation that contains these classes: getTemporaryDirectories getTemporaryDirectory getLocalVmId But the getNamespaceVmId method is also needed by the attach mechanism. I removed the duplicated functionality to avoid having to maintain this in 2 places. Shouldn?t the attach functionality, in the future, be decoupled from jvmstat? It looked like jcmd was using these jvmstat classes in order to avoid duplication but I don?t have all the history. Bob. > On Jan 17, 2018, at 1:16 PM, mandy chung wrote: > > Hi Bob, > > I think the new methods in VMSupport and probably with VMSupport.getVMTemporaryDirectory should belong to jdk.internal.jvmstat as they are specific for jvmstat and attach API to use. > > W.r.t VMSupportImpl, the implementation is the same for all platforms except Linux. One option is to have a shared implementation class and instantiate an alternate implementation class, if present, using Class::forName. > Another minor point is that the new getVMTemporaryDirectories method can return a List rather than an array. > > Mandy > > On 1/17/18 8:37 AM, Bob Vandette wrote: >> Here?s an updated webrev addressing the comments from David Holmes. >> >> 1. Moved new cgroup specific support from unix -> Linux and put stubs in all other OS's >> 2. Reduced the size of the stack arrays in perfMemory_linux.cpp >> >> >> There are still two outstanding issues: >> >> [serviceability] : Can we and should we remove the getFile methods in the PerfDataFile class? >> >> [core-libs]: Do you have any problems with the module info file changes impacting java.base? >> >> Details: >> >> Bug: >> >> >> https://bugs.openjdk.java.net/browse/JDK-8193710 >> >> >> Webrev: >> >> >> http://cr.openjdk.java.net/~bobv/8193710/webrev.01/ >> >> >> Summary: >> >> This changeset enables the ability to use jcmd and jps running on a Host to >> list the java processes that are running in docker (cgroup based) containers. >> >> I?ve tested this change by examining processes running as root on both host and in >> docker containers as well as under my userid using ?jps and jcmd -l?. >> I?ve also tested the getFile functions with a small example program that I wrote. >> From what I can tell, these two getFile functions are not used in the JDK sources >> and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! >> I?d really like to remove these two methods. >> >> 140 candidate = new File(f.getName(), name); <> >> Here are some implementation details that I?ve added added to one of the Unix >> specific source files (src/java.base/unix/classes/jdk/internal/vm/VMSupportImpl.java) >> >> /* Implementation Details: >> * >> * Java processes that run in docker containers are typically running >> * under cgroups with separate pid namespaces which means that pids >> * within the container are different that the pid which is visible >> * from the host. The container pids typically start with 1 and >> * increase. The java process running in the container will use these >> * pids when creating the hsperfdata files. In order to locate java >> * processes that are running in containers, we take advantage of >> * the Linux proc file system which maps the containers tmp directory >> * to the hosts under /proc/{hostpid}/root/tmp. We use the /proc status >> * file /proc/{hostpid}/status to determine the containers pid and >> * then access the hsperfdata file. The status file contains an >> * entry "NSPid:" which shows the mapping from the hostpid to the >> * containers pid. >> * >> * Example: >> * >> * NSPid: 24345 11 >> * >> * In this example process 24345 is visible from the host, >> * is running under the PID namespace and has a container specific >> * pid of 11. >> * >> * The search for Java processes is done by first looking in the >> * traditional /tmp for host process hsperfdata files and then >> * the search will container in every /proc/*/root/tmp directory. >> * There are of course added complications to this search that >> * need to be taken into account. >> * >> * 1. duplication of tmp directories >> * >> * /proc/{hostpid}/root/tmp directories exist for many processes >> * that are running on a Linux kernel that has cgroups enabled even >> * if they are not running in a container. To avoid this duplication, >> * we compare the inode of the /proc tmp directories to /tmp and >> * skip these duplicated directories. >> * >> * 2. Containerized processes without PID namespaces being enabled. >> * >> * If a container is running a Java process without namespaces being >> * enabled, an hsperfdata file will only be located at >> * /proc/{hostpid}/root/tmp/{hostpid}. This is handled by >> * checking the last component in the path for both the hostpid >> * and potential namespacepids (if one exists). >> */ >> >> >> >> Bob. >> > From chris.plummer at oracle.com Wed Jan 17 19:29:51 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Jan 2018 11:29:51 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <299D78E4-479B-47D8-8B19-F4C2588E7C43@oracle.com> References: <9EDC72A1-D0C3-4C62-A8F6-232500151A62@oracle.com> <299D78E4-479B-47D8-8B19-F4C2588E7C43@oracle.com> Message-ID: <8c57dfb8-3626-1818-9776-7a01df048764@oracle.com> Hi Daniil, Have you run with -Xcomp. I'm concerned that inlining will cause the test to fail because stack depths will not be as expected. Also, if you find the owned monitor, but the depth is not as expected, I think you are better off printing an error message right away rather than the somewhat misleading "FAIL: invalid number of %s monitors" message later on. thanks, Chris On 1/16/18 6:31 PM, Daniil Titov wrote: > Hello, > > Please review an updated fix that makes the test more extensive and includes suggested changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.02/ > > Thank you! > > Best regards, > Daniil > > On 1/12/18, 2:26 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > It is pretty good in general. > Thank you for taking care about it! > > Some comments though. > > The test case is too trivial. > I'd suggest to extend it to have at least a couple of locks in the > returned array. > One way to do it would be to add a instance synchronized method and > invoke it from the synchronized statement of the tested Thread. > Then the verifyOwnedMonitors() can be invoked from this method. > > A couple of comments on the native agent. > > 72 // JNI_OnLoad has not been called yet, so can't possibly be an instance of TEST_CLASS. > > Could you, please, rewrite this comment? > Maybe just tell that there probably was an error in loading the TEST_CLASS. > What about moving the FindClass(env, TEST_CLASS) to the > verifyOwnedMonitors() function? > It will make the testClass variable local. > > 200 fprintf(stderr, "VerifyOwnedMonitors: FAIL: stackDepthInfo[0].stack_depth should be 1.\n"); > > 207 fprintf(stderr, "VerifyOwnedMonitors: FAIL: monitorCount should be 1.\n"); > > > It'd better to rephrase the messages above to tell about actual values > vs expected. > It normally simplifies the analysis of failures as there is no need to find > what values were printed before and that they are exactly what needed > for comparison. > > Thanks, > Serguei > > > > On 1/11/18 17:45, Daniil Titov wrote: > > Hello, > > > > Please review the following fix that adds a jtreg test for GetOwnedMonitorStackDepthInfo JVMTI function. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 > > > > > > The tests ran successfully with Mach5. > > > > Best regards, > > Daniil > > > > > > > > > > From serguei.spitsyn at oracle.com Wed Jan 17 20:21:57 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 12:21:57 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <8c57dfb8-3626-1818-9776-7a01df048764@oracle.com> References: <9EDC72A1-D0C3-4C62-A8F6-232500151A62@oracle.com> <299D78E4-479B-47D8-8B19-F4C2588E7C43@oracle.com> <8c57dfb8-3626-1818-9776-7a01df048764@oracle.com> Message-ID: <2674075e-aa24-d32c-1b74-7091d47e93de@oracle.com> Hi Daniil, Some nits. 207 if (monitorCount == 3) { 208 for (idx = 0; idx < 3; idx++) { ? Need to get rid of hardcoded number of monitors (3). 184 err = (*jvmti) -> GetCurrentThread(jvmti, &thread); ? Extra spaces around '->'. 214 TEST_CLASS, TEST_OBJECT_LOCK_DEPTH,stackDepthInfo[idx].stack_depth); 221 LOCK1_CLASS, LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); Missed a space before stackDepthInfo[... Also, I have more suggestions to add to the Chris's comment: ? - Remove the big condition if (monitorCount == 3) around the loop and replace it with: ????? for (idx = 0; idx < monitorCount; idx++) { ??? and print monitor miscount separately before of after the loop: ???? if (monitorCount != 3) { ?????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid monitorCount, expected: %d, found: %d.\n", ?????????????????????? 3, monitorCount); ???? } Then it would look like this: status = PASSED; ??? if (monitorCount != EXP_MON_COUNT) { ???? ?? fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid monitorCount, expected: %d, found: %d.\n", ?????????? EXP_MON_COUNT, monitorCount); status = FAILED; ??? } ??? for (idx = 0; idx < monitorCount; idx++) { ??????? if (CheckLockObject(env, stackDepthInfo[idx].monitor, testClass) == JNI_TRUE) { ??????????? if (stackDepthInfo[idx].stack_depth != TEST_OBJECT_LOCK_DEPTH) { fprintf(stderr, "FAILED: invalid stack_depth for %s monitor, expected: %d, found: %d.\n", TEST_CLASS, TEST_OBJECT_LOCK_DEPTH, stackDepthInfo[idx].stack_depth); status = FAILED; } } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, lock1Class) == JNI_TRUE) { if (stackDepthInfo[idx].stack_depth != LOCK1_DEPTH) { fprintf(stderr, "FAILED: invalid stack_depth for %s monitor, expected: %d, found: %d.\n", LOCK1_CLASS, LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); status = FAILED; } } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, lock2Class) == JNI_TRUE) { if (stackDepthInfo[idx].stack_depth != LOCK2_DEPTH) { fprintf(stderr, "FAILED: invalid stack_depth for %s monitor, expected: %d, found: %d.\n", LOCK2_CLASS, LOCK2_DEPTH, stackDepthInfo[idx].stack_depth); status = FAILED; } } else { fprintf(stderr, "FAILED: monitor[%d] should be instance of %s, %s, or %s\n", idx, TEST_CLASS, LOCK1_CLASS, LOCK2_CLASS); status = FAILED; } } Also, it does not seem that important to have two different lock classes Lock1 and Lock2. Would it be simpler to keep just one of them? Thanks, Serguei On 1/17/18 11:29, Chris Plummer wrote: > Hi Daniil, > > Have you run with -Xcomp. I'm concerned that inlining will cause the > test to fail because stack depths will not be as expected. Also, if > you find the owned monitor, but the depth is not as expected, I think > you are better off printing an error message right away rather than > the somewhat misleading "FAIL: invalid number of %s monitors" message > later on. > > thanks, > > Chris > > On 1/16/18 6:31 PM, Daniil Titov wrote: >> Hello, >> >> Please review? an updated fix that makes the test more extensive and >> includes suggested changes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.02/ >> >> Thank you! >> >> Best regards, >> Daniil >> >> On 1/12/18, 2:26 PM, "serguei.spitsyn at oracle.com" >> wrote: >> >> ???? Hi Daniil, >> ???? ???? It is pretty good in general. >> ???? Thank you for taking care about it! >> ???? ???? Some comments though. >> ???? ???? The test case is too trivial. >> ???? I'd suggest to extend it to have at least a couple of locks in the >> ???? returned array. >> ???? One way to do it would be to add a instance synchronized method and >> ???? invoke it from the synchronized statement of the tested Thread. >> ???? Then the verifyOwnedMonitors() can be invoked from this method. >> ???? ???? A couple of comments on the native agent. >> ???? ???? 72???????? // JNI_OnLoad has not been called yet, so can't >> possibly be an instance of TEST_CLASS. >> ???? ???? Could you, please, rewrite this comment? >> ???? Maybe just tell that there probably was an error in loading the >> TEST_CLASS. >> ???? What about moving the FindClass(env, TEST_CLASS) to the >> ???? verifyOwnedMonitors() function? >> ???? It will make the testClass variable local. >> ???? ?????? 200???????????????? fprintf(stderr, "VerifyOwnedMonitors: >> FAIL: stackDepthInfo[0].stack_depth should be 1.\n"); >> ???? ?????? 207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: >> monitorCount should be 1.\n"); >> ???? ???? ???? It'd better to rephrase the messages above to tell >> about actual values >> ???? vs expected. >> ???? It normally simplifies the analysis of failures as there is no >> need to find >> ???? what values were printed before and that they are exactly what >> needed >> ???? for comparison. >> ???? ???? Thanks, >> ???? Serguei >> ???? ???? ???? ???? On 1/11/18 17:45, Daniil Titov wrote: >> ???? > Hello, >> ???? > >> ???? > Please review the following fix that adds a jtreg test for >> GetOwnedMonitorStackDepthInfo JVMTI function. >> ???? > >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >> ???? > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >> ???? > >> ???? > >> ???? > The tests ran successfully with Mach5. >> ???? > >> ???? > Best regards, >> ???? > Daniil >> ???? > >> ???? > >> >> > From serguei.spitsyn at oracle.com Wed Jan 17 20:29:51 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 12:29:51 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <2674075e-aa24-d32c-1b74-7091d47e93de@oracle.com> References: <9EDC72A1-D0C3-4C62-A8F6-232500151A62@oracle.com> <299D78E4-479B-47D8-8B19-F4C2588E7C43@oracle.com> <8c57dfb8-3626-1818-9776-7a01df048764@oracle.com> <2674075e-aa24-d32c-1b74-7091d47e93de@oracle.com> Message-ID: <5562e500-f16b-05ec-f293-bd87de988d40@oracle.com> On 1/17/18 12:21, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > > Some nits. > > ?207???? if (monitorCount == 3) { > ?208???????? for (idx = 0; idx < 3; idx++) { > > ? Need to get rid of hardcoded number of monitors (3). > > ?184???? err = (*jvmti) -> GetCurrentThread(jvmti, &thread); > > ? Extra spaces around '->'. > > ?214???????????????????????????? TEST_CLASS, > TEST_OBJECT_LOCK_DEPTH,stackDepthInfo[idx].stack_depth); > ?221???????????????????????????? LOCK1_CLASS, > LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); > > ? Missed a space before stackDepthInfo[... > > > > Also, I have more suggestions to add to the Chris's comment: > > ? - Remove the big condition if (monitorCount == 3) around the loop > and replace it with: > ????? for (idx = 0; idx < monitorCount; idx++) { > > ??? and print monitor miscount separately before of after the loop: > ???? if (monitorCount != 3) { > ?????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid > monitorCount, expected: %d, found: %d.\n", > ?????????????????????? 3, monitorCount); > ???? } > > > Then it would look like this: > > ??? status = PASSED; > ??? if (monitorCount != EXP_MON_COUNT) { > ???? ?? fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid > monitorCount, expected: %d, found: %d.\n", > ??????????????? EXP_MON_COUNT, monitorCount); > ??????? status = FAILED; > ??? } > ??? for (idx = 0; idx < monitorCount; idx++) { > ??????? if (CheckLockObject(env, stackDepthInfo[idx].monitor, > testClass) == JNI_TRUE) { > ??????????? if (stackDepthInfo[idx].stack_depth != > TEST_OBJECT_LOCK_DEPTH) { > ???????????????? fprintf(stderr, "FAILED: invalid stack_depth for %s > monitor, expected: %d, found: %d.\n", > ???????????????????????? TEST_CLASS, TEST_OBJECT_LOCK_DEPTH, > stackDepthInfo[idx].stack_depth); > ???????????????? status = FAILED; > ???????????? } > ???????? } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, > lock1Class) == JNI_TRUE) { > ???????????? if (stackDepthInfo[idx].stack_depth != LOCK1_DEPTH) { > ???????????????? fprintf(stderr, "FAILED: invalid stack_depth for %s > monitor, expected: %d, found: %d.\n", > ???????????????????????? LOCK1_CLASS, > LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); > ???????????????? status = FAILED; > ???????????? } > ???????? } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, > lock2Class) == JNI_TRUE) { > ???????????? if (stackDepthInfo[idx].stack_depth != LOCK2_DEPTH) { > ???????????????? fprintf(stderr, "FAILED: invalid stack_depth for %s > monitor, expected: %d, found: %d.\n", > ???????????????????????? LOCK2_CLASS, LOCK2_DEPTH, > stackDepthInfo[idx].stack_depth); > ???????????????? status = FAILED; > ???????????? } > ???????? } else { > ???????????? fprintf(stderr, "FAILED: monitor[%d] should be instance > of %s, %s, or %s\n", > ???????????????????? idx, TEST_CLASS, LOCK1_CLASS, LOCK2_CLASS); > ???????????? status = FAILED; > ???????? } > ???? } > > Also, it does not seem that important to have two different lock > classes Lock1 and Lock2. > Would it be simpler to keep just one of them? Please, skip this last question. I see the reason two have two different classes. It is in the suggestion above this question. Thanks, Serguei > Thanks, > Serguei > > > On 1/17/18 11:29, Chris Plummer wrote: >> Hi Daniil, >> >> Have you run with -Xcomp. I'm concerned that inlining will cause the >> test to fail because stack depths will not be as expected. Also, if >> you find the owned monitor, but the depth is not as expected, I think >> you are better off printing an error message right away rather than >> the somewhat misleading "FAIL: invalid number of %s monitors" message >> later on. >> >> thanks, >> >> Chris >> >> On 1/16/18 6:31 PM, Daniil Titov wrote: >>> Hello, >>> >>> Please review? an updated fix that makes the test more extensive and >>> includes suggested changes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.02/ >>> >>> Thank you! >>> >>> Best regards, >>> Daniil >>> >>> On 1/12/18, 2:26 PM, "serguei.spitsyn at oracle.com" >>> wrote: >>> >>> ???? Hi Daniil, >>> ???? ???? It is pretty good in general. >>> ???? Thank you for taking care about it! >>> ???? ???? Some comments though. >>> ???? ???? The test case is too trivial. >>> ???? I'd suggest to extend it to have at least a couple of locks in the >>> ???? returned array. >>> ???? One way to do it would be to add a instance synchronized method >>> and >>> ???? invoke it from the synchronized statement of the tested Thread. >>> ???? Then the verifyOwnedMonitors() can be invoked from this method. >>> ???? ???? A couple of comments on the native agent. >>> ???? ???? 72???????? // JNI_OnLoad has not been called yet, so can't >>> possibly be an instance of TEST_CLASS. >>> ???? ???? Could you, please, rewrite this comment? >>> ???? Maybe just tell that there probably was an error in loading the >>> TEST_CLASS. >>> ???? What about moving the FindClass(env, TEST_CLASS) to the >>> ???? verifyOwnedMonitors() function? >>> ???? It will make the testClass variable local. >>> ???? ?????? 200???????????????? fprintf(stderr, >>> "VerifyOwnedMonitors: FAIL: stackDepthInfo[0].stack_depth should be >>> 1.\n"); >>> ???? ?????? 207???????? fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>> monitorCount should be 1.\n"); >>> ???? ???? ???? It'd better to rephrase the messages above to tell >>> about actual values >>> ???? vs expected. >>> ???? It normally simplifies the analysis of failures as there is no >>> need to find >>> ???? what values were printed before and that they are exactly what >>> needed >>> ???? for comparison. >>> ???? ???? Thanks, >>> ???? Serguei >>> ???? ???? ???? ???? On 1/11/18 17:45, Daniil Titov wrote: >>> ???? > Hello, >>> ???? > >>> ???? > Please review the following fix that adds a jtreg test for >>> GetOwnedMonitorStackDepthInfo JVMTI function. >>> ???? > >>> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>> ???? > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>> ???? > >>> ???? > >>> ???? > The tests ran successfully with Mach5. >>> ???? > >>> ???? > Best regards, >>> ???? > Daniil >>> ???? > >>> ???? > >>> >>> >> > From daniil.x.titov at oracle.com Wed Jan 17 21:36:35 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Jan 2018 13:36:35 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <5562e500-f16b-05ec-f293-bd87de988d40@oracle.com> References: <9EDC72A1-D0C3-4C62-A8F6-232500151A62@oracle.com> <299D78E4-479B-47D8-8B19-F4C2588E7C43@oracle.com> <8c57dfb8-3626-1818-9776-7a01df048764@oracle.com> <2674075e-aa24-d32c-1b74-7091d47e93de@oracle.com> <5562e500-f16b-05ec-f293-bd87de988d40@oracle.com> Message-ID: <33A12FCC-D140-4402-8E1A-C022C9F8FD77@oracle.com> Thank you, Serguei and Chris! The test runs successfully in mach5 when ?Xcomp Java option is added. Please review a new version of patch that changes the way how the error messages are printed as suggested. Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 Best regards, Daniil On 1/17/18, 12:29 PM, "serguei.spitsyn at oracle.com" wrote: On 1/17/18 12:21, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > > Some nits. > > 207 if (monitorCount == 3) { > 208 for (idx = 0; idx < 3; idx++) { > > Need to get rid of hardcoded number of monitors (3). > > 184 err = (*jvmti) -> GetCurrentThread(jvmti, &thread); > > Extra spaces around '->'. > > 214 TEST_CLASS, > TEST_OBJECT_LOCK_DEPTH,stackDepthInfo[idx].stack_depth); > 221 LOCK1_CLASS, > LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); > > Missed a space before stackDepthInfo[... > > > > Also, I have more suggestions to add to the Chris's comment: > > - Remove the big condition if (monitorCount == 3) around the loop > and replace it with: > for (idx = 0; idx < monitorCount; idx++) { > > and print monitor miscount separately before of after the loop: > if (monitorCount != 3) { > fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid > monitorCount, expected: %d, found: %d.\n", > 3, monitorCount); > } > > > Then it would look like this: > > status = PASSED; > if (monitorCount != EXP_MON_COUNT) { > fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid > monitorCount, expected: %d, found: %d.\n", > EXP_MON_COUNT, monitorCount); > status = FAILED; > } > for (idx = 0; idx < monitorCount; idx++) { > if (CheckLockObject(env, stackDepthInfo[idx].monitor, > testClass) == JNI_TRUE) { > if (stackDepthInfo[idx].stack_depth != > TEST_OBJECT_LOCK_DEPTH) { > fprintf(stderr, "FAILED: invalid stack_depth for %s > monitor, expected: %d, found: %d.\n", > TEST_CLASS, TEST_OBJECT_LOCK_DEPTH, > stackDepthInfo[idx].stack_depth); > status = FAILED; > } > } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, > lock1Class) == JNI_TRUE) { > if (stackDepthInfo[idx].stack_depth != LOCK1_DEPTH) { > fprintf(stderr, "FAILED: invalid stack_depth for %s > monitor, expected: %d, found: %d.\n", > LOCK1_CLASS, > LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); > status = FAILED; > } > } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, > lock2Class) == JNI_TRUE) { > if (stackDepthInfo[idx].stack_depth != LOCK2_DEPTH) { > fprintf(stderr, "FAILED: invalid stack_depth for %s > monitor, expected: %d, found: %d.\n", > LOCK2_CLASS, LOCK2_DEPTH, > stackDepthInfo[idx].stack_depth); > status = FAILED; > } > } else { > fprintf(stderr, "FAILED: monitor[%d] should be instance > of %s, %s, or %s\n", > idx, TEST_CLASS, LOCK1_CLASS, LOCK2_CLASS); > status = FAILED; > } > } > > Also, it does not seem that important to have two different lock > classes Lock1 and Lock2. > Would it be simpler to keep just one of them? Please, skip this last question. I see the reason two have two different classes. It is in the suggestion above this question. Thanks, Serguei > Thanks, > Serguei > > > On 1/17/18 11:29, Chris Plummer wrote: >> Hi Daniil, >> >> Have you run with -Xcomp. I'm concerned that inlining will cause the >> test to fail because stack depths will not be as expected. Also, if >> you find the owned monitor, but the depth is not as expected, I think >> you are better off printing an error message right away rather than >> the somewhat misleading "FAIL: invalid number of %s monitors" message >> later on. >> >> thanks, >> >> Chris >> >> On 1/16/18 6:31 PM, Daniil Titov wrote: >>> Hello, >>> >>> Please review an updated fix that makes the test more extensive and >>> includes suggested changes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.02/ >>> >>> Thank you! >>> >>> Best regards, >>> Daniil >>> >>> On 1/12/18, 2:26 PM, "serguei.spitsyn at oracle.com" >>> wrote: >>> >>> Hi Daniil, >>> It is pretty good in general. >>> Thank you for taking care about it! >>> Some comments though. >>> The test case is too trivial. >>> I'd suggest to extend it to have at least a couple of locks in the >>> returned array. >>> One way to do it would be to add a instance synchronized method >>> and >>> invoke it from the synchronized statement of the tested Thread. >>> Then the verifyOwnedMonitors() can be invoked from this method. >>> A couple of comments on the native agent. >>> 72 // JNI_OnLoad has not been called yet, so can't >>> possibly be an instance of TEST_CLASS. >>> Could you, please, rewrite this comment? >>> Maybe just tell that there probably was an error in loading the >>> TEST_CLASS. >>> What about moving the FindClass(env, TEST_CLASS) to the >>> verifyOwnedMonitors() function? >>> It will make the testClass variable local. >>> 200 fprintf(stderr, >>> "VerifyOwnedMonitors: FAIL: stackDepthInfo[0].stack_depth should be >>> 1.\n"); >>> 207 fprintf(stderr, "VerifyOwnedMonitors: FAIL: >>> monitorCount should be 1.\n"); >>> It'd better to rephrase the messages above to tell >>> about actual values >>> vs expected. >>> It normally simplifies the analysis of failures as there is no >>> need to find >>> what values were printed before and that they are exactly what >>> needed >>> for comparison. >>> Thanks, >>> Serguei >>> On 1/11/18 17:45, Daniil Titov wrote: >>> > Hello, >>> > >>> > Please review the following fix that adds a jtreg test for >>> GetOwnedMonitorStackDepthInfo JVMTI function. >>> > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 >>> > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 >>> > >>> > >>> > The tests ran successfully with Mach5. >>> > >>> > Best regards, >>> > Daniil >>> > >>> > >>> >>> >> > From serguei.spitsyn at oracle.com Wed Jan 17 21:49:52 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 13:49:52 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <33A12FCC-D140-4402-8E1A-C022C9F8FD77@oracle.com> References: <9EDC72A1-D0C3-4C62-A8F6-232500151A62@oracle.com> <299D78E4-479B-47D8-8B19-F4C2588E7C43@oracle.com> <8c57dfb8-3626-1818-9776-7a01df048764@oracle.com> <2674075e-aa24-d32c-1b74-7091d47e93de@oracle.com> <5562e500-f16b-05ec-f293-bd87de988d40@oracle.com> <33A12FCC-D140-4402-8E1A-C022C9F8FD77@oracle.com> Message-ID: Daniil, Looks great! Could you, please, make a minor cleanup of status handling? 60 jint status = FAILED; => 60 jint status = PASSED; At the lines 167, 173, 179, 186 and 192: return status; => return FAILED; And remove the line: 205 status = PASSED; No need for another round of review. Thanks, Serguei On 1/17/18 13:36, Daniil Titov wrote: > Thank you, Serguei and Chris! > > The test runs successfully in mach5 when ?Xcomp Java option is added. Please review a new version of patch that changes the way how the error messages are printed as suggested. > > > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > > Best regards, > Daniil > > > On 1/17/18, 12:29 PM, "serguei.spitsyn at oracle.com" wrote: > > On 1/17/18 12:21, serguei.spitsyn at oracle.com wrote: > > Hi Daniil, > > > > > > Some nits. > > > > 207 if (monitorCount == 3) { > > 208 for (idx = 0; idx < 3; idx++) { > > > > Need to get rid of hardcoded number of monitors (3). > > > > 184 err = (*jvmti) -> GetCurrentThread(jvmti, &thread); > > > > Extra spaces around '->'. > > > > 214 TEST_CLASS, > > TEST_OBJECT_LOCK_DEPTH,stackDepthInfo[idx].stack_depth); > > 221 LOCK1_CLASS, > > LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); > > > > Missed a space before stackDepthInfo[... > > > > > > > > Also, I have more suggestions to add to the Chris's comment: > > > > - Remove the big condition if (monitorCount == 3) around the loop > > and replace it with: > > for (idx = 0; idx < monitorCount; idx++) { > > > > and print monitor miscount separately before of after the loop: > > if (monitorCount != 3) { > > fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid > > monitorCount, expected: %d, found: %d.\n", > > 3, monitorCount); > > } > > > > > > Then it would look like this: > > > > status = PASSED; > > if (monitorCount != EXP_MON_COUNT) { > > fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid > > monitorCount, expected: %d, found: %d.\n", > > EXP_MON_COUNT, monitorCount); > > status = FAILED; > > } > > for (idx = 0; idx < monitorCount; idx++) { > > if (CheckLockObject(env, stackDepthInfo[idx].monitor, > > testClass) == JNI_TRUE) { > > if (stackDepthInfo[idx].stack_depth != > > TEST_OBJECT_LOCK_DEPTH) { > > fprintf(stderr, "FAILED: invalid stack_depth for %s > > monitor, expected: %d, found: %d.\n", > > TEST_CLASS, TEST_OBJECT_LOCK_DEPTH, > > stackDepthInfo[idx].stack_depth); > > status = FAILED; > > } > > } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, > > lock1Class) == JNI_TRUE) { > > if (stackDepthInfo[idx].stack_depth != LOCK1_DEPTH) { > > fprintf(stderr, "FAILED: invalid stack_depth for %s > > monitor, expected: %d, found: %d.\n", > > LOCK1_CLASS, > > LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); > > status = FAILED; > > } > > } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, > > lock2Class) == JNI_TRUE) { > > if (stackDepthInfo[idx].stack_depth != LOCK2_DEPTH) { > > fprintf(stderr, "FAILED: invalid stack_depth for %s > > monitor, expected: %d, found: %d.\n", > > LOCK2_CLASS, LOCK2_DEPTH, > > stackDepthInfo[idx].stack_depth); > > status = FAILED; > > } > > } else { > > fprintf(stderr, "FAILED: monitor[%d] should be instance > > of %s, %s, or %s\n", > > idx, TEST_CLASS, LOCK1_CLASS, LOCK2_CLASS); > > status = FAILED; > > } > > } > > > > Also, it does not seem that important to have two different lock > > classes Lock1 and Lock2. > > Would it be simpler to keep just one of them? > > Please, skip this last question. > I see the reason two have two different classes. > It is in the suggestion above this question. > > Thanks, > Serguei > > > > Thanks, > > Serguei > > > > > > On 1/17/18 11:29, Chris Plummer wrote: > >> Hi Daniil, > >> > >> Have you run with -Xcomp. I'm concerned that inlining will cause the > >> test to fail because stack depths will not be as expected. Also, if > >> you find the owned monitor, but the depth is not as expected, I think > >> you are better off printing an error message right away rather than > >> the somewhat misleading "FAIL: invalid number of %s monitors" message > >> later on. > >> > >> thanks, > >> > >> Chris > >> > >> On 1/16/18 6:31 PM, Daniil Titov wrote: > >>> Hello, > >>> > >>> Please review an updated fix that makes the test more extensive and > >>> includes suggested changes. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.02/ > >>> > >>> Thank you! > >>> > >>> Best regards, > >>> Daniil > >>> > >>> On 1/12/18, 2:26 PM, "serguei.spitsyn at oracle.com" > >>> wrote: > >>> > >>> Hi Daniil, > >>> It is pretty good in general. > >>> Thank you for taking care about it! > >>> Some comments though. > >>> The test case is too trivial. > >>> I'd suggest to extend it to have at least a couple of locks in the > >>> returned array. > >>> One way to do it would be to add a instance synchronized method > >>> and > >>> invoke it from the synchronized statement of the tested Thread. > >>> Then the verifyOwnedMonitors() can be invoked from this method. > >>> A couple of comments on the native agent. > >>> 72 // JNI_OnLoad has not been called yet, so can't > >>> possibly be an instance of TEST_CLASS. > >>> Could you, please, rewrite this comment? > >>> Maybe just tell that there probably was an error in loading the > >>> TEST_CLASS. > >>> What about moving the FindClass(env, TEST_CLASS) to the > >>> verifyOwnedMonitors() function? > >>> It will make the testClass variable local. > >>> 200 fprintf(stderr, > >>> "VerifyOwnedMonitors: FAIL: stackDepthInfo[0].stack_depth should be > >>> 1.\n"); > >>> 207 fprintf(stderr, "VerifyOwnedMonitors: FAIL: > >>> monitorCount should be 1.\n"); > >>> It'd better to rephrase the messages above to tell > >>> about actual values > >>> vs expected. > >>> It normally simplifies the analysis of failures as there is no > >>> need to find > >>> what values were printed before and that they are exactly what > >>> needed > >>> for comparison. > >>> Thanks, > >>> Serguei > >>> On 1/11/18 17:45, Daniil Titov wrote: > >>> > Hello, > >>> > > >>> > Please review the following fix that adds a jtreg test for > >>> GetOwnedMonitorStackDepthInfo JVMTI function. > >>> > > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > >>> > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 > >>> > > >>> > > >>> > The tests ran successfully with Mach5. > >>> > > >>> > Best regards, > >>> > Daniil > >>> > > >>> > > >>> > >>> > >> > > > > > > From chris.plummer at oracle.com Wed Jan 17 22:10:00 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Jan 2018 14:10:00 -0800 Subject: RFR 8153629: Need to cover JVMTI's GetOwnedMonitorStackDepthInfo function In-Reply-To: <33A12FCC-D140-4402-8E1A-C022C9F8FD77@oracle.com> References: <9EDC72A1-D0C3-4C62-A8F6-232500151A62@oracle.com> <299D78E4-479B-47D8-8B19-F4C2588E7C43@oracle.com> <8c57dfb8-3626-1818-9776-7a01df048764@oracle.com> <2674075e-aa24-d32c-1b74-7091d47e93de@oracle.com> <5562e500-f16b-05ec-f293-bd87de988d40@oracle.com> <33A12FCC-D140-4402-8E1A-C022C9F8FD77@oracle.com> Message-ID: Hi Daniil, Looks good. Thanks for the -Xcomp testing. Chris On 1/17/18 1:36 PM, Daniil Titov wrote: > Thank you, Serguei and Chris! > > The test runs successfully in mach5 when ?Xcomp Java option is added. Please review a new version of patch that changes the way how the error messages are printed as suggested. > > > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > > Best regards, > Daniil > > > On 1/17/18, 12:29 PM, "serguei.spitsyn at oracle.com" wrote: > > On 1/17/18 12:21, serguei.spitsyn at oracle.com wrote: > > Hi Daniil, > > > > > > Some nits. > > > > 207 if (monitorCount == 3) { > > 208 for (idx = 0; idx < 3; idx++) { > > > > Need to get rid of hardcoded number of monitors (3). > > > > 184 err = (*jvmti) -> GetCurrentThread(jvmti, &thread); > > > > Extra spaces around '->'. > > > > 214 TEST_CLASS, > > TEST_OBJECT_LOCK_DEPTH,stackDepthInfo[idx].stack_depth); > > 221 LOCK1_CLASS, > > LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); > > > > Missed a space before stackDepthInfo[... > > > > > > > > Also, I have more suggestions to add to the Chris's comment: > > > > - Remove the big condition if (monitorCount == 3) around the loop > > and replace it with: > > for (idx = 0; idx < monitorCount; idx++) { > > > > and print monitor miscount separately before of after the loop: > > if (monitorCount != 3) { > > fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid > > monitorCount, expected: %d, found: %d.\n", > > 3, monitorCount); > > } > > > > > > Then it would look like this: > > > > status = PASSED; > > if (monitorCount != EXP_MON_COUNT) { > > fprintf(stderr, "VerifyOwnedMonitors: FAIL: invalid > > monitorCount, expected: %d, found: %d.\n", > > EXP_MON_COUNT, monitorCount); > > status = FAILED; > > } > > for (idx = 0; idx < monitorCount; idx++) { > > if (CheckLockObject(env, stackDepthInfo[idx].monitor, > > testClass) == JNI_TRUE) { > > if (stackDepthInfo[idx].stack_depth != > > TEST_OBJECT_LOCK_DEPTH) { > > fprintf(stderr, "FAILED: invalid stack_depth for %s > > monitor, expected: %d, found: %d.\n", > > TEST_CLASS, TEST_OBJECT_LOCK_DEPTH, > > stackDepthInfo[idx].stack_depth); > > status = FAILED; > > } > > } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, > > lock1Class) == JNI_TRUE) { > > if (stackDepthInfo[idx].stack_depth != LOCK1_DEPTH) { > > fprintf(stderr, "FAILED: invalid stack_depth for %s > > monitor, expected: %d, found: %d.\n", > > LOCK1_CLASS, > > LOCK1_DEPTH,stackDepthInfo[idx].stack_depth); > > status = FAILED; > > } > > } else if (CheckLockObject(env, stackDepthInfo[idx].monitor, > > lock2Class) == JNI_TRUE) { > > if (stackDepthInfo[idx].stack_depth != LOCK2_DEPTH) { > > fprintf(stderr, "FAILED: invalid stack_depth for %s > > monitor, expected: %d, found: %d.\n", > > LOCK2_CLASS, LOCK2_DEPTH, > > stackDepthInfo[idx].stack_depth); > > status = FAILED; > > } > > } else { > > fprintf(stderr, "FAILED: monitor[%d] should be instance > > of %s, %s, or %s\n", > > idx, TEST_CLASS, LOCK1_CLASS, LOCK2_CLASS); > > status = FAILED; > > } > > } > > > > Also, it does not seem that important to have two different lock > > classes Lock1 and Lock2. > > Would it be simpler to keep just one of them? > > Please, skip this last question. > I see the reason two have two different classes. > It is in the suggestion above this question. > > Thanks, > Serguei > > > > Thanks, > > Serguei > > > > > > On 1/17/18 11:29, Chris Plummer wrote: > >> Hi Daniil, > >> > >> Have you run with -Xcomp. I'm concerned that inlining will cause the > >> test to fail because stack depths will not be as expected. Also, if > >> you find the owned monitor, but the depth is not as expected, I think > >> you are better off printing an error message right away rather than > >> the somewhat misleading "FAIL: invalid number of %s monitors" message > >> later on. > >> > >> thanks, > >> > >> Chris > >> > >> On 1/16/18 6:31 PM, Daniil Titov wrote: > >>> Hello, > >>> > >>> Please review an updated fix that makes the test more extensive and > >>> includes suggested changes. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.02/ > >>> > >>> Thank you! > >>> > >>> Best regards, > >>> Daniil > >>> > >>> On 1/12/18, 2:26 PM, "serguei.spitsyn at oracle.com" > >>> wrote: > >>> > >>> Hi Daniil, > >>> It is pretty good in general. > >>> Thank you for taking care about it! > >>> Some comments though. > >>> The test case is too trivial. > >>> I'd suggest to extend it to have at least a couple of locks in the > >>> returned array. > >>> One way to do it would be to add a instance synchronized method > >>> and > >>> invoke it from the synchronized statement of the tested Thread. > >>> Then the verifyOwnedMonitors() can be invoked from this method. > >>> A couple of comments on the native agent. > >>> 72 // JNI_OnLoad has not been called yet, so can't > >>> possibly be an instance of TEST_CLASS. > >>> Could you, please, rewrite this comment? > >>> Maybe just tell that there probably was an error in loading the > >>> TEST_CLASS. > >>> What about moving the FindClass(env, TEST_CLASS) to the > >>> verifyOwnedMonitors() function? > >>> It will make the testClass variable local. > >>> 200 fprintf(stderr, > >>> "VerifyOwnedMonitors: FAIL: stackDepthInfo[0].stack_depth should be > >>> 1.\n"); > >>> 207 fprintf(stderr, "VerifyOwnedMonitors: FAIL: > >>> monitorCount should be 1.\n"); > >>> It'd better to rephrase the messages above to tell > >>> about actual values > >>> vs expected. > >>> It normally simplifies the analysis of failures as there is no > >>> need to find > >>> what values were printed before and that they are exactly what > >>> needed > >>> for comparison. > >>> Thanks, > >>> Serguei > >>> On 1/11/18 17:45, Daniil Titov wrote: > >>> > Hello, > >>> > > >>> > Please review the following fix that adds a jtreg test for > >>> GetOwnedMonitorStackDepthInfo JVMTI function. > >>> > > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8153629 > >>> > Webrev: http://cr.openjdk.java.net/~dtitov/8153629/webrev.00 > >>> > > >>> > > >>> > The tests ran successfully with Mach5. > >>> > > >>> > Best regards, > >>> > Daniil > >>> > > >>> > > >>> > >>> > >> > > > > > > From david.holmes at oracle.com Wed Jan 17 22:26:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jan 2018 08:26:40 +1000 Subject: New JBS component for the serviceability agent In-Reply-To: <90C83861-D6CF-4490-8EB4-2FC49B7A4A0A@oracle.com> References: <90C83861-D6CF-4490-8EB4-2FC49B7A4A0A@oracle.com> Message-ID: Hi Jesper, cc'd serviceability-dev On 18/01/2018 7:03 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > A new JBS component is now available for the serviceability agent: hotspot/svc-agent > This means that the old label svc-sa is deprecated and any issue that had this label has been moved to the new subcomponent. > > So, wherever you'd previously used the label svc-sa (mainly in hotspot/svc or in core-svc/tools) you should now use the component hotspot/svc-agent. Do we have guidelines on what kind of svc issues to file where? It often isn't clear which components are involved. Thanks, David > Thanks, > /Jesper > From david.holmes at oracle.com Wed Jan 17 22:36:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jan 2018 08:36:20 +1000 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> Message-ID: On 18/01/2018 3:32 AM, Egor Ushakov wrote: > Is the link http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix > broken? for me it works well. To clarify ... your earlier email was in multi-part-mime format including a plain text and html part. The html version has: Bug: https://bugs.openjdk.java.net/browse/JDK-8194143 Webrev: http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ where as you can see the actual target for the links is not the same as the text describing the links. David > attaching the patch just in case. > It was created on jdk10, do I need to recreate it based on jdk11 with > the 2018 copyrights? > > On 17-Jan-18 20:26, serguei.spitsyn at oracle.com wrote: >> Hi Egor and David, >> >> Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. >> Also, I expect new webrev is based on the JDK 11 jdk/hs repository and >> with 2018 copyright comments updated. >> >> Thanks, >> Serguei >> >> >> On 1/17/18 02:24, David Holmes wrote: >>> Hi Egor, >>> >>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>> Hello, >>>> >>>> Please review and push the fix. >>>> This is a formal letter after the discussion on the alias. >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>> >>> The underlying link actually pointed to: >>> >>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>> >>> :) >>> >>> Real webrev looks fine. >>> >>> Thanks, >>> David >>> >>>> -- >>>> Egor Ushakov >>>> Software Developer >>>> JetBrains >>>> http://www.jetbrains.com >>>> The Drive to Develop >>>> >> > From serguei.spitsyn at oracle.com Wed Jan 17 22:41:41 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 14:41:41 -0800 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> Message-ID: On 1/17/18 14:36, David Holmes wrote: > On 18/01/2018 3:32 AM, Egor Ushakov wrote: >> Is the link http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix >> broken? for me it works well. > > To clarify ... your earlier email was in multi-part-mime format > including a plain text and html part. The html version has: > > Bug: href="https://bugs.openjdk.java.net/browse/JDK-8153629">https://bugs.openjdk.java.net/browse/JDK-8194143 > Webrev: href="http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00">http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ > > where as you can see the actual target for the links is not the same > as the text describing the links. I guess, this happens if you copy a link from another email and modify it with your content. The link href remains unchanged in such a case. Thanks, Serguei > David > >> attaching the patch just in case. >> It was created on jdk10, do I need to recreate it based on jdk11 with >> the 2018 copyrights? >> >> On 17-Jan-18 20:26, serguei.spitsyn at oracle.com wrote: >>> Hi Egor and David, >>> >>> Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. >>> Also, I expect new webrev is based on the JDK 11 jdk/hs repository >>> and with 2018 copyright comments updated. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/17/18 02:24, David Holmes wrote: >>>> Hi Egor, >>>> >>>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>>> Hello, >>>>> >>>>> Please review and push the fix. >>>>> This is a formal letter after the discussion on the alias. >>>>> >>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>> >>>> The underlying link actually pointed to: >>>> >>>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>>> >>>> :) >>>> >>>> Real webrev looks fine. >>>> >>>> Thanks, >>>> David >>>> >>>>> -- >>>>> Egor Ushakov >>>>> Software Developer >>>>> JetBrains >>>>> http://www.jetbrains.com >>>>> The Drive to Develop >>>>> >>> >> From jesper.wilhelmsson at oracle.com Thu Jan 18 00:35:01 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 18 Jan 2018 01:35:01 +0100 Subject: New JBS component for the serviceability agent In-Reply-To: References: <90C83861-D6CF-4490-8EB4-2FC49B7A4A0A@oracle.com> Message-ID: <654AB883-901B-42BB-8E2E-51740CE2D84B@oracle.com> > On 17 Jan 2018, at 23:26, David Holmes wrote: > > Hi Jesper, > > cc'd serviceability-dev > > On 18/01/2018 7:03 AM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> A new JBS component is now available for the serviceability agent: hotspot/svc-agent >> This means that the old label svc-sa is deprecated and any issue that had this label has been moved to the new subcomponent. >> So, wherever you'd previously used the label svc-sa (mainly in hotspot/svc or in core-svc/tools) you should now use the component hotspot/svc-agent. > > Do we have guidelines on what kind of svc issues to file where? It often isn't clear which components are involved. hotspot/svc-agent is for issues concerning the serviceability agent (code in src/jdk.hotspot.agent/* and vmStructs.cpp). JMX issues goes into core-svc/javax.management. Both of these components are considered part of the M&M area. (They also have core-svc/java.lang.management.) As for the serviceability area there are components like: hotspot/jvmti, hotspot/svc, core-svc/debugger, core-svc/tools, core-svc/java.lang.instrument, and tools/hprof. Some of these have fairly descriptive names, the rest I leave for the serviceability folks to sort out :-) /Jesper > > Thanks, > David > >> Thanks, >> /Jesper From mandy.chung at oracle.com Thu Jan 18 00:49:26 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 17 Jan 2018 16:49:26 -0800 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: <28DD8D38-DF9E-448F-AF72-63062D2CF781@oracle.com> References: <22077896-E632-4153-B70E-14B6FE10C9DB@oracle.com> <7ea44913-4391-442f-3175-81524b106e7e@oracle.com> <28DD8D38-DF9E-448F-AF72-63062D2CF781@oracle.com> Message-ID: On 1/17/18 11:08 AM, Bob Vandette wrote: > I put these new methods in VMSupport since this was the class containg the getVMTemporaryDirectory and > the intention of this class was document as: > > /* > * Support class used by JVMTI and VM attach mechanism. > */ > class VMSupport { I looked at the history.? Initially VMSupport provides entry points for VM to call out.? VMSupport::serializePropertiesToByteArray and serializeAgentPropertiesToByteArray? are called by VM. VMSupport::getVMTemporaryDirectory was added in JDK 9 and all VMs use the same directory for all hsperfdata files. The API is currently used by jdk.internal.jvmstat and jdk.management.agent.?? But you may be right that when we decouple jdk.attach from jvmstat, jdk.attach may need to use this API (I don't know how it looks like yet). > I could create a new PerfDataFileImpl or jdk.internal.jvmstat.VMSupport class with a Linux specific alternate implementation that contains these classes: > > getTemporaryDirectories > getTemporaryDirectory > getLocalVmId > But the getNamespaceVmId method is also needed by the attach mechanism. > I removed the duplicated functionality to avoid having to maintain this in > 2 places. Ah, it was in jdk.attach. > Shouldn?t the attach functionality, in the future, be decoupled from jvmstat? It looked like jcmd was using these jvmstat classes in order to avoid duplication but I don?t have all the history. Yes and we attempted to eliminate the dependency from jdk.attach to jdk.internal.jvmstat but we haven't found a good way yet.? Since these new methods are implementation for attach and jvmstat, I personally prefer them to live there. ? As for getNamespaceVmId, there is also a native implementation in VM.? I don't have a good suggestion.? Since it's a small utility, duplicating it for now may not be too bad and wait until attach and jvmstat are decoupled. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Thu Jan 18 08:56:51 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Thu, 18 Jan 2018 11:56:51 +0300 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <55e6b92c-c7e7-f079-8b6b-fcc78b0b8e06@oracle.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> <55e6b92c-c7e7-f079-8b6b-fcc78b0b8e06@oracle.com> Message-ID: <53563ce8-3c01-b336-40ba-0307b60800fe@jetbrains.com> Hi Serguei, I do not see jdk11 repo on http://hg.openjdk.java.net, do I need to use http://hg.openjdk.java.net/jdk/hs? Thanks, Egor On 17-Jan-18 20:37, serguei.spitsyn at oracle.com wrote: > On 1/17/18 09:32, Egor Ushakov wrote: >> Is the link http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix >> broken? for me it works well. >> attaching the patch just in case. > > It was my mistake this time, sorry. :( > Please, see my previous message. > > >> It was created on jdk10, do I need to recreate it based on jdk11 with >> the 2018 copyrights? > > Yes, and it needs to be committed with the reviewers listed. > > > Thanks, > Serguei > >> >> On 17-Jan-18 20:26, serguei.spitsyn at oracle.com wrote: >>> Hi Egor and David, >>> >>> Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. >>> Also, I expect new webrev is based on the JDK 11 jdk/hs repository >>> and with 2018 copyright comments updated. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/17/18 02:24, David Holmes wrote: >>>> Hi Egor, >>>> >>>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>>> Hello, >>>>> >>>>> Please review and push the fix. >>>>> This is a formal letter after the discussion on the alias. >>>>> >>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>> >>>> The underlying link actually pointed to: >>>> >>>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>>> >>>> :) >>>> >>>> Real webrev looks fine. >>>> >>>> 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 From david.holmes at oracle.com Thu Jan 18 09:08:11 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jan 2018 19:08:11 +1000 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <53563ce8-3c01-b336-40ba-0307b60800fe@jetbrains.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> <55e6b92c-c7e7-f079-8b6b-fcc78b0b8e06@oracle.com> <53563ce8-3c01-b336-40ba-0307b60800fe@jetbrains.com> Message-ID: On 18/01/2018 6:56 PM, Egor Ushakov wrote: > Hi Serguei, > > I do not see jdk11 repo on http://hg.openjdk.java.net, > do I need to use http://hg.openjdk.java.net/jdk/hs? Yes. jdk/hs always contains the latest version under development (as does jdk/jdk). Cheers, David > Thanks, > Egor > > On 17-Jan-18 20:37, serguei.spitsyn at oracle.com wrote: >> On 1/17/18 09:32, Egor Ushakov wrote: >>> Is the link http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix >>> broken? for me it works well. >>> attaching the patch just in case. >> >> It was my mistake this time, sorry. :( >> Please, see my previous message. >> >> >>> It was created on jdk10, do I need to recreate it based on jdk11 with >>> the 2018 copyrights? >> >> Yes, and it needs to be committed with the reviewers listed. >> >> >> Thanks, >> Serguei >> >>> >>> On 17-Jan-18 20:26, serguei.spitsyn at oracle.com wrote: >>>> Hi Egor and David, >>>> >>>> Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. >>>> Also, I expect new webrev is based on the JDK 11 jdk/hs repository >>>> and with 2018 copyright comments updated. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 1/17/18 02:24, David Holmes wrote: >>>>> Hi Egor, >>>>> >>>>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review and push the fix. >>>>>> This is a formal letter after the discussion on the alias. >>>>>> >>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>>> >>>>> The underlying link actually pointed to: >>>>> >>>>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>>>> >>>>> :) >>>>> >>>>> Real webrev looks fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> -- >>>>>> Egor Ushakov >>>>>> Software Developer >>>>>> JetBrains >>>>>> http://www.jetbrains.com >>>>>> The Drive to Develop >>>>>> >>>> >>> >> > From hohensee at amazon.com Fri Jan 19 23:40:49 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Jan 2018 23:40:49 +0000 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Message-ID: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> I?d appreciate a review please. Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.00/ The bug is that from the JMX point of view, G1?s incremental collector (misnamed as the ?G1 Young Generation? collector) only affects G1?s survivor and eden spaces. In fact, mixed collections run by this collector also affect the G1 old generation. This proposed fix is to record, for each of a JMX garbage collector's memory pools, whether that memory pool is affected by all collections using that collector. And, for each collection, record whether or not all the collector's memory pools are affected. After each collection, for each memory pool, if either all the collector's memory pools were affected or the memory pool is affected for all collections, record CollectionUsage for that pool. For collectors other than G1 Young Generation, all pools are recorded as affected by all collections and every collection is recorded as affecting all the collector?s memory pools. For the G1 Young Generation collector, the G1 Old Gen pool is recorded as not being affected by all collections, and non-mixed collections are recorded as not affecting all memory pools. The result is that for non-mixed collections, CollectionUsage is recorded after a collection only the G1 Eden Space and G1 Survivor Space pools, while for mixed collections CollectionUsage is recorded for G1 Old Gen as well. Other than the effect of the fix on G1 Old Gen MemoryPool. CollectionUsage, the only external behavior change is that GarbageCollectorMXBean.getMemoryPoolNames will now return 3 pool names rather than 2. With this fix, a collector?s memory pools can be divided into two disjoint subsets, one that participates in all collections and one that doesn?t. This is a bit more general than the minimum necessary to fix G1, but not by much. Because I expect it to apply to other incremental region-based collectors, I went with the more general solution. I minimized the amount of code I had to touch by using default parameters for GCMemoryManager::add_pool and the TraceMemoryManagerStats constructors. Tested by running the new jtreg test included in the webrev. I tried to use the submit repo, but it was out of order earlier today, so I?d be much obliged if someone could run it through mach5 and sponsor an eventual push. I successfully ran a JDK8 version of the patch through all the JDK8 jtreg tests as well as the JDK8 TCK. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Mon Jan 22 04:14:52 2018 From: jini.george at oracle.com (Jini George) Date: Mon, 22 Jan 2018 09:44:52 +0530 Subject: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> Message-ID: <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> Hi Yasumasa, The changes look good to me. Please do update the copyright year to 2018. Thanks! Jini (Not a Reviewer). On 12/31/2017 10:03 AM, Yasumasa Suenaga wrote: > Hi David, > > >> How did you submit to mach5 ??? > > I'm using Submit Repo for testing: > ? https://wiki.openjdk.java.net/display/Build/Submit+Repo > > >> Anyway the failure is with: > > Thanks! > I've fixed them in new webrev: > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ > > This webrev has passed Mach 5 tier 1 tests in Submit Repo: > > http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171231-0202-8291 > > > > Yasumasa > > > On 2017/12/30 10:31, David Holmes wrote: >> Hi Yasumasa, >> >> Not a review ... >> >> On 29/12/2017 11:16 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> G1HeapRegionTable#getByAddress() returns incorrect HeapRegion which >>> contains incorrect address. We can see it in Stack Memory window on >>> HSDB. Some oop addresses are shown as Free Region (attached image). >>> >>> G1HeapRegion#getByAddress() should create HeapRegion instance from >>> the address in _biased_base array. >>> >>> I uploaded webrev. Could you review it? >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ >>> >>> I've tested this change with test/hotspot/jtreg/serviceability/sa, it >>> works fine. >>> But I received some failure from Mach 5. I also tested this change >>> via submit repos. >>> >>> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 >>> >>> >>> I cannot access this URL. Could you share the result? >> >> How did you submit to mach5 ??? >> >> Anyway the failure is with: >> >> test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java >> >> On linux and OS X: >> >> ??stderr: [Exception in thread "main" java.lang.NullPointerException >> ?????at >> TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >> >> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >> >> On Solaris sparcv9: >> >> ??stderr: [Exception in thread "main" java.lang.RuntimeException: >> Address of HeapRegion does not match.: expected 0x00000007afb00000 to >> equal 0x00000007afc00000 >> ?????at jdk.test.lib.Asserts.fail(Asserts.java:594) >> ?????at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> ?????at >> TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >> >> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >> ] >> >> David >> ----- >> >>> Also I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa From yasuenag at gmail.com Mon Jan 22 10:53:15 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 22 Jan 2018 19:53:15 +0900 Subject: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> Message-ID: <122a2fbf-6c0d-6209-28b4-0b03064b65ab@gmail.com> Hi Jini, Thank you for your review! I will update the copyright year in this changeset. I'm waiting for Reviewer and sponsor. Yasumasa On 2018/01/22 13:14, Jini George wrote: > Hi Yasumasa, > > The changes look good to me. Please do update the copyright year to 2018. > > Thanks! > Jini (Not a Reviewer). > > > > On 12/31/2017 10:03 AM, Yasumasa Suenaga wrote: >> Hi David, >> >> >>> How did you submit to mach5 ??? >> >> I'm using Submit Repo for testing: >> ?? https://wiki.openjdk.java.net/display/Build/Submit+Repo >> >> >>> Anyway the failure is with: >> >> Thanks! >> I've fixed them in new webrev: >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ >> >> This webrev has passed Mach 5 tier 1 tests in Submit Repo: >> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171231-0202-8291 >> >> >> Yasumasa >> >> >> On 2017/12/30 10:31, David Holmes wrote: >>> Hi Yasumasa, >>> >>> Not a review ... >>> >>> On 29/12/2017 11:16 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> G1HeapRegionTable#getByAddress() returns incorrect HeapRegion which contains incorrect address. We can see it in Stack Memory window on HSDB. Some oop addresses are shown as Free Region (attached image). >>>> >>>> G1HeapRegion#getByAddress() should create HeapRegion instance from the address in _biased_base array. >>>> >>>> I uploaded webrev. Could you review it? >>>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ >>>> >>>> I've tested this change with test/hotspot/jtreg/serviceability/sa, it works fine. >>>> But I received some failure from Mach 5. I also tested this change via submit repos. >>>> >>>> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 >>>> >>>> I cannot access this URL. Could you share the result? >>> >>> How did you submit to mach5 ??? >>> >>> Anyway the failure is with: >>> >>> test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java >>> >>> On linux and OS X: >>> >>> ??stderr: [Exception in thread "main" java.lang.NullPointerException >>> ?????at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >>> ?????at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >>> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >>> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >>> >>> On Solaris sparcv9: >>> >>> ??stderr: [Exception in thread "main" java.lang.RuntimeException: Address of HeapRegion does not match.: expected 0x00000007afb00000 to equal 0x00000007afc00000 >>> ?????at jdk.test.lib.Asserts.fail(Asserts.java:594) >>> ?????at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >>> ?????at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >>> ?????at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >>> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >>> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >>> ] >>> >>> David >>> ----- >>> >>>> Also I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa From egor.ushakov at jetbrains.com Mon Jan 22 12:14:31 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Mon, 22 Jan 2018 15:14:31 +0300 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: <55e6b92c-c7e7-f079-8b6b-fcc78b0b8e06@oracle.com> References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> <55e6b92c-c7e7-f079-8b6b-fcc78b0b8e06@oracle.com> Message-ID: Serguei, here is the fixed webrev, sorry for the delay, it took forever to clone the repo. http://cr.openjdk.java.net/~avu/JDK-8194143/webrev.00/ Thanks, Egor On 17-Jan-18 20:37, serguei.spitsyn at oracle.com wrote: > On 1/17/18 09:32, Egor Ushakov wrote: >> Is the link http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix >> broken? for me it works well. >> attaching the patch just in case. > > It was my mistake this time, sorry. :( > Please, see my previous message. > > >> It was created on jdk10, do I need to recreate it based on jdk11 with >> the 2018 copyrights? > > Yes, and it needs to be committed with the reviewers listed. > > > Thanks, > Serguei > >> >> On 17-Jan-18 20:26, serguei.spitsyn at oracle.com wrote: >>> Hi Egor and David, >>> >>> Both webrevs below are from Daniil Titov on the JVMTI bug: JDK-8153629. >>> Also, I expect new webrev is based on the JDK 11 jdk/hs repository >>> and with 2018 copyright comments updated. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/17/18 02:24, David Holmes wrote: >>>> Hi Egor, >>>> >>>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>>> Hello, >>>>> >>>>> Please review and push the fix. >>>>> This is a formal letter after the discussion on the alias. >>>>> >>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>> >>>> The underlying link actually pointed to: >>>> >>>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>>> >>>> :) >>>> >>>> Real webrev looks fine. >>>> >>>> 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 From bob.vandette at oracle.com Mon Jan 22 17:20:17 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 22 Jan 2018 12:20:17 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers Message-ID: Please review this change that resolves the detection of Java processes that are running in cgroup based containers. This latest (and hopefully final) update of this fix addresses comments from David Holmes and Mandy Chung. Bug: https://bugs.openjdk.java.net/browse/JDK-8193710 Webrev: http://cr.openjdk.java.net/~bobv/8193710/webrev.02/ Summary: This changeset enables the ability to use jcmd and jps running on a Host to list the java processes that are running in docker (cgroup based) containers. I?ve tested this change by examining processes running as root on both host and in docker containers as well as under my userid using ?jps and jcmd -l?. I?ve also tested updates to the getFile functions with a small example program that I wrote. Here are some implementation details that I?ve added to the Linux specific implementation class: src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java /* Implementation Details: * * Java processes that run in docker containers are typically running * under cgroups with separate pid namespaces which means that pids * within the container are different that the pid which is visible * from the host. The container pids typically start with 1 and * increase. The java process running in the container will use these * pids when creating the hsperfdata files. In order to locate java * processes that are running in containers, we take advantage of * the Linux proc file system which maps the containers tmp directory * to the hosts under /proc/{hostpid}/root/tmp. We use the /proc status * file /proc/{hostpid}/status to determine the containers pid and * then access the hsperfdata file. The status file contains an * entry "NSPid:" which shows the mapping from the hostpid to the * containers pid. * * Example: * * NSPid: 24345 11 * * In this example process 24345 is visible from the host, * is running under the PID namespace and has a container specific * pid of 11. * * The search for Java processes is done by first looking in the * traditional /tmp for host process hsperfdata files and then * the search will container in every /proc/*/root/tmp directory. * There are of course added complications to this search that * need to be taken into account. * * 1. duplication of tmp directories * * /proc/{hostpid}/root/tmp directories exist for many processes * that are running on a Linux kernel that has cgroups enabled even * if they are not running in a container. To avoid this duplication, * we compare the inode of the /proc tmp directories to /tmp and * skip these duplicated directories. * * 2. Containerized processes without PID namespaces being enabled. * * If a container is running a Java process without namespaces being * enabled, an hsperfdata file will only be located at * /proc/{hostpid}/root/tmp/{hostpid}. This is handled by * checking the last component in the path for both the hostpid * and potential namespacepids (if one exists). */ Bob. From gary.adams at oracle.com Mon Jan 22 17:43:55 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 22 Jan 2018 12:43:55 -0500 Subject: RFR: JDK-8167253: com.sun.jdi invokeMethod has duplicated @throws for InvalidTypeException Message-ID: <5A6622DB.908@oracle.com> Here's a small fix to remove a duplicate InvalidTypeException. The other reported locations appear to have already been fixed. Issue: https://bugs.openjdk.java.net/browse/JDK-8167253 Webrev: http://cr.openjdk.java.net/~gadams/8167253/ From mandy.chung at oracle.com Mon Jan 22 18:32:32 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 22 Jan 2018 10:32:32 -0800 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: References: Message-ID: On 1/22/18 9:20 AM, Bob Vandette wrote: > : > > Webrev: > > http://cr.openjdk.java.net/~bobv/8193710/webrev.02/ Thanks for the update.? Looks good to me. It would be good to add a comment in PlatformSupport::getInstance to explain that PlatformSupport provides the default implementation that can be overridden by a platform-specific version PlatformSupportImpl, if present. We discussed that PlatformSupport::getLocalVmId could throw IAE rather than NumberFormatException if the given file is invalid. This carries from existing jvmstat code and so agree to leave it as a future clean up.? PlatformSupportImpl::getTemporaryDirectories can be simplified with java.nio.file.Path but what you have is fine with me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Mon Jan 22 19:00:53 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 22 Jan 2018 14:00:53 -0500 Subject: RFR: JDK-8167253: com.sun.jdi invokeMethod has duplicated @throws for InvalidTypeException In-Reply-To: <5A6622DB.908@oracle.com> References: <5A6622DB.908@oracle.com> Message-ID: <26644f98-046c-aac5-b01b-6c2a5f93aeaf@Oracle.com> Hi Gary, Looks fine, Roger On 1/22/2018 12:43 PM, Gary Adams wrote: > Here's a small fix to remove a duplicate InvalidTypeException. > The other reported locations appear to have already been fixed. > > ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8167253 > ?? Webrev: http://cr.openjdk.java.net/~gadams/8167253/ From serguei.spitsyn at oracle.com Mon Jan 22 21:48:25 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Jan 2018 13:48:25 -0800 Subject: RFR: JDK-8167253: com.sun.jdi invokeMethod has duplicated @throws for InvalidTypeException In-Reply-To: <26644f98-046c-aac5-b01b-6c2a5f93aeaf@Oracle.com> References: <5A6622DB.908@oracle.com> <26644f98-046c-aac5-b01b-6c2a5f93aeaf@Oracle.com> Message-ID: Hi Gary, +1 Thanks, Serguei On 1/22/18 11:00, Roger Riggs wrote: > Hi Gary, > > Looks fine, > > Roger > > > On 1/22/2018 12:43 PM, Gary Adams wrote: >> Here's a small fix to remove a duplicate InvalidTypeException. >> The other reported locations appear to have already been fixed. >> >> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8167253 >> ?? Webrev: http://cr.openjdk.java.net/~gadams/8167253/ > From david.holmes at oracle.com Mon Jan 22 22:15:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jan 2018 08:15:46 +1000 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: References: Message-ID: Thanks Bob. Seems okay. David On 23/01/2018 3:20 AM, Bob Vandette wrote: > Please review this change that resolves the detection of Java processes that are running in cgroup > based containers. > > This latest (and hopefully final) update of this fix addresses comments from David Holmes and Mandy Chung. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8193710 > > Webrev: > > http://cr.openjdk.java.net/~bobv/8193710/webrev.02/ > > Summary: > > This changeset enables the ability to use jcmd and jps running on a Host to > list the java processes that are running in docker (cgroup based) containers. > > I?ve tested this change by examining processes running as root on both host and in > docker containers as well as under my userid using ?jps and jcmd -l?. > I?ve also tested updates to the getFile functions with a small example program that I wrote. > > > Here are some implementation details that I?ve added to the Linux specific implementation class: > > src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java > > /* Implementation Details: > * > * Java processes that run in docker containers are typically running > * under cgroups with separate pid namespaces which means that pids > * within the container are different that the pid which is visible > * from the host. The container pids typically start with 1 and > * increase. The java process running in the container will use these > * pids when creating the hsperfdata files. In order to locate java > * processes that are running in containers, we take advantage of > * the Linux proc file system which maps the containers tmp directory > * to the hosts under /proc/{hostpid}/root/tmp. We use the /proc status > * file /proc/{hostpid}/status to determine the containers pid and > * then access the hsperfdata file. The status file contains an > * entry "NSPid:" which shows the mapping from the hostpid to the > * containers pid. > * > * Example: > * > * NSPid: 24345 11 > * > * In this example process 24345 is visible from the host, > * is running under the PID namespace and has a container specific > * pid of 11. > * > * The search for Java processes is done by first looking in the > * traditional /tmp for host process hsperfdata files and then > * the search will container in every /proc/*/root/tmp directory. > * There are of course added complications to this search that > * need to be taken into account. > * > * 1. duplication of tmp directories > * > * /proc/{hostpid}/root/tmp directories exist for many processes > * that are running on a Linux kernel that has cgroups enabled even > * if they are not running in a container. To avoid this duplication, > * we compare the inode of the /proc tmp directories to /tmp and > * skip these duplicated directories. > * > * 2. Containerized processes without PID namespaces being enabled. > * > * If a container is running a Java process without namespaces being > * enabled, an hsperfdata file will only be located at > * /proc/{hostpid}/root/tmp/{hostpid}. This is handled by > * checking the last component in the path for both the hostpid > * and potential namespacepids (if one exists). > */ > > Bob. > From david.holmes at oracle.com Mon Jan 22 22:26:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jan 2018 08:26:01 +1000 Subject: RFR: JDK-8167253: com.sun.jdi invokeMethod has duplicated @throws for InvalidTypeException In-Reply-To: <5A6622DB.908@oracle.com> References: <5A6622DB.908@oracle.com> Message-ID: Thanks Gary. The other duplicates were removed by JDK-8179538 "Update jdk.jdi to be HTML-5 friendly" David On 23/01/2018 3:43 AM, Gary Adams wrote: > Here's a small fix to remove a duplicate InvalidTypeException. > The other reported locations appear to have already been fixed. > > ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8167253 > ?? Webrev: http://cr.openjdk.java.net/~gadams/8167253/ From serguei.spitsyn at oracle.com Mon Jan 22 23:19:32 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Jan 2018 15:19:32 -0800 Subject: RFR: 8194143: remove unneeded casts in LocationImpl and MirrorImpl classes In-Reply-To: References: <1e51da31-7dc5-2ca5-4172-6d5c363b69c3@jetbrains.com> <334f26cc-7413-0822-ad01-ca6c6be7547e@oracle.com> <350dd9b5-44bb-4a94-cd51-db2589847a40@jetbrains.com> <55e6b92c-c7e7-f079-8b6b-fcc78b0b8e06@oracle.com> Message-ID: <5a990de4-74ef-85f9-4592-e73ec3ef6b20@oracle.com> Hi Egor, It occurred you do not have any openJDK status, even an author. So that I've committed and pushed your patch with: Contributed-by: egor.ushakov at jetbrains.com Thanks, Serguei On 1/22/18 04:14, Egor Ushakov wrote: > Serguei, > > here is the fixed webrev, sorry for the delay, it took forever to > clone the repo. > http://cr.openjdk.java.net/~avu/JDK-8194143/webrev.00/ > Thanks, > Egor > > On 17-Jan-18 20:37, serguei.spitsyn at oracle.com wrote: >> On 1/17/18 09:32, Egor Ushakov wrote: >>> Is the link http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix >>> broken? for me it works well. >>> attaching the patch just in case. >> >> It was my mistake this time, sorry. :( >> Please, see my previous message. >> >> >>> It was created on jdk10, do I need to recreate it based on jdk11 >>> with the 2018 copyrights? >> >> Yes, and it needs to be committed with the reviewers listed. >> >> >> Thanks, >> Serguei >> >>> >>> On 17-Jan-18 20:26, serguei.spitsyn at oracle.com wrote: >>>> Hi Egor and David, >>>> >>>> Both webrevs below are from Daniil Titov on the JVMTI bug: >>>> JDK-8153629. >>>> Also, I expect new webrev is based on the JDK 11 jdk/hs repository >>>> and with 2018 copyright comments updated. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 1/17/18 02:24, David Holmes wrote: >>>>> Hi Egor, >>>>> >>>>> On 17/01/2018 7:15 PM, Egor Ushakov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review and push the fix. >>>>>> This is a formal letter after the discussion on the alias. >>>>>> >>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8194143 >>>>>> Webrev:http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>>> >>>>> The underlying link actually pointed to: >>>>> >>>>> http://cr.openjdk.java.net/%7Edtitov/8153629/webrev.00 >>>>> >>>>> :) >>>>> >>>>> Real webrev looks fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> -- >>>>>> Egor Ushakov >>>>>> Software Developer >>>>>> JetBrains >>>>>> http://www.jetbrains.com >>>>>> The Drive to Develop >>>>>> >>>> >>> >> > From jcbeyler at google.com Wed Jan 24 00:40:06 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 23 Jan 2018 16:40:06 -0800 Subject: Low-Overhead Heap Profiling In-Reply-To: <1511450419.2477.24.camel@oracle.com> References: <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> <1510146425.3155.11.camel@oracle.com> <1511450419.2477.24.camel@oracle.com> Message-ID: And it has been exactly two months since I posted an update here :) Thanksgiving, Christmas, and handling https://bugs.openjdk.java.net/browse/JDK-8190862 will do that to you :) I have gotten back to this item now that JDK-8190862 is done and I have the following webrev ready: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ With the incremental here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.01_02/ The updates are: a) GetCachedTraces - I added a GC collection if the GetLiveTraces is called, this is because you really want to know what is currently live when you call that method - If you are worried about performance and only care about what was live at the last GC, you can now call GetCachedTraces, which does not provoke a GC Let me know if there are any questions here or concerns. I'm happy to explain and defend the choices :). Note: I added a new test for this and updated other tests to double check the live call. (see for example http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.01_02/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorCachedTest.java.html) b) Disabling samples wipes out the data I had originally implemented for OpenJdk a version that keeps the data in memory after disabling the sampler, allowing a user to get traces post-sampling. Because of this, we would always do the weak_oops_do method, whether enabled or disabled. This led to a slight regression in performance for GC reference processing time. I had initially fixed this with a small "was this ever enabled" flag. This would have allowed a program that never uses this to not have a regression but a program that enables the disabled the code for the rest of the execution would still pay the price after disabling the sampler. Because of this, I have moved things back to where they probably should be: if you disable the sampler, you lose the data. But this allows a simpler code path: if the sampler is disabled, skip over the GC weak_oops_do method. Let me know what you think and happy 2018 to all! Jc On Thu, Nov 23, 2017 at 7:20 AM, Thomas Schatzl wrote: > On Tue, 2017-11-21 at 13:50 -0800, JC Beyler wrote: >> Hi all, >> >> I have a new webrev here: >> http://cr.openjdk.java.net/~rasbold/8171119/webrev.15/ >> >> With the incremental one here: >> http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/ >> >> I think I did most items from Thomans and Robbin. I've especially >> added a new test: > > Thanks. Looks good. > > Thanks, > Thomas > From harsha.wardhana.b at oracle.com Wed Jan 24 11:18:26 2018 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 24 Jan 2018 16:48:26 +0530 Subject: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties Message-ID: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> Hi, Please review the changes for above enhancement having webrev at, http://cr.openjdk.java.net/~hb/8187498/webrev.00/ Thanks Harsha From Alan.Bateman at oracle.com Wed Jan 24 12:11:10 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Jan 2018 12:11:10 +0000 Subject: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties In-Reply-To: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> References: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> Message-ID: <783c17d1-c051-db62-3826-e53ff5cdffa2@oracle.com> On 24/01/2018 11:18, Harsha Wardhana B wrote: > Hi, > > Please review the changes for above enhancement having webrev at, > > http://cr.openjdk.java.net/~hb/8187498/webrev.00/ One of the guidelines in JEP 293 [1] is to not introduce new options with -X as a prefix. I think a related discussion point is whether it should be a java launcher or VM option. -Alan [1] http://openjdk.java.net/jeps/293 From erik.gahlin at oracle.com Wed Jan 24 12:43:33 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 24 Jan 2018 13:43:33 +0100 Subject: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties In-Reply-To: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> References: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> Message-ID: <5A687F75.3050404@oracle.com> Hi Harsha, Very nice to see progress on this! Before reviewing, the minimal command line to start up the default management server now becomes -Xmanagement:ssl=false,authenticate=false and if you use a property that doesn't exist, or that is mandatory, you will get an error message stating what is wrong? Could we reduce the command line further, so only a single property is needed: -Xmanagement:secure=false or perhaps: -Xmanagement:unsecure which would set ssl=false,authenticate=false, because that is what you want 99% of the time. Thanks Erik > Hi, > > Please review the changes for above enhancement having webrev at, > > http://cr.openjdk.java.net/~hb/8187498/webrev.00/ > > Thanks > Harsha From jini.george at oracle.com Wed Jan 24 17:43:37 2018 From: jini.george at oracle.com (Jini George) Date: Wed, 24 Jan 2018 23:13:37 +0530 Subject: RFR: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes Message-ID: <2c7094ce-2310-721c-0f1b-f17e26a8d014@oracle.com> Hello, Requesting reviews for the issue: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes ID: https://bugs.openjdk.java.net/browse/JDK-8175384 Webrev: http://cr.openjdk.java.net/~jgeorge/8175384/webrev.01/ The issue was seen while printing out the details of the invokevirtual bytecode of the java.lang.Enum.values() method. The fix is to avoid a ClassCastException by returning the bottom klass in the case of an object array klass, while printing out the details. Tests run: The SA tests pass with Mach5 and jprt. Thanks, Jini. From serguei.spitsyn at oracle.com Wed Jan 24 18:55:09 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Jan 2018 10:55:09 -0800 Subject: RFR: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes In-Reply-To: <2c7094ce-2310-721c-0f1b-f17e26a8d014@oracle.com> References: <2c7094ce-2310-721c-0f1b-f17e26a8d014@oracle.com> Message-ID: <08102274-7107-a4d9-611d-537bb345bba1@oracle.com> Hi Jini, It looks good to me. Thanks, Serguei On 1/24/18 09:43, Jini George wrote: > Hello, > > Requesting reviews for the issue: > > SA: clhsdb 'printall' throws ClassCastException while printing out the > bytecodes > > ID: https://bugs.openjdk.java.net/browse/JDK-8175384 > Webrev: http://cr.openjdk.java.net/~jgeorge/8175384/webrev.01/ > > The issue was seen while printing out the details of the invokevirtual > bytecode of the java.lang.Enum.values() method. The fix is to avoid a > ClassCastException by returning the bottom klass in the case of an > object array klass, while printing out the details. > > Tests run: The SA tests pass with Mach5 and jprt. > > Thanks, > Jini. From david.holmes at oracle.com Thu Jan 25 02:30:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jan 2018 12:30:33 +1000 Subject: RFR: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes In-Reply-To: <2c7094ce-2310-721c-0f1b-f17e26a8d014@oracle.com> References: <2c7094ce-2310-721c-0f1b-f17e26a8d014@oracle.com> Message-ID: <9327a930-d576-b625-1eb5-f5345c92f80c@oracle.com> Hi Jini, On 25/01/2018 3:43 AM, Jini George wrote: > Hello, > > Requesting reviews for the issue: > > SA: clhsdb 'printall' throws ClassCastException while printing out the > bytecodes > > ID: https://bugs.openjdk.java.net/browse/JDK-8175384 > Webrev: http://cr.openjdk.java.net/~jgeorge/8175384/webrev.01/ > > The issue was seen while printing out the details of the invokevirtual > bytecode of the java.lang.Enum.values() method. The fix is to avoid a > ClassCastException by returning the bottom klass in the case of an > object array klass, while printing out the details. I'm a bit confused as to what getFieldOrMethodKlassRefAt is supposed to be returning - should it really be instanceKlass? It's not at all clear to me that returning the array component type is the right thing to do. That aside a couple of minor nits: src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! k = (k.isObjArrayKlass())?((ObjArrayKlass)k).getBottomKlass():k; No () needed around k.isObjArrayKlass() Spaces needed around the ? and : operators test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java Copyright year should now be "2017, 2018," Thanks, David > Tests run: The SA tests pass with Mach5 and jprt. > > Thanks, > Jini. From harsha.wardhana.b at oracle.com Thu Jan 25 07:21:28 2018 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 25 Jan 2018 12:51:28 +0530 Subject: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties In-Reply-To: <5A687F75.3050404@oracle.com> References: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> <5A687F75.3050404@oracle.com> Message-ID: <05c2e5af-b9d0-0386-4565-ade1179a1d49@oracle.com> Hi Erik, The minimal command line would be, "-Xmanagement", that will start only the local management server. "-Xmanagement:local=true,port=aaaa" will start the remote management server without SSL or authentication. On Wednesday 24 January 2018 06:13 PM, Erik Gahlin wrote: > Hi Harsha, > > Very nice to see progress on this! > > Before reviewing, the minimal command line to start up the default > management server now becomes > > -Xmanagement:ssl=false,authenticate=false No. Please refer above for minimal options. > > and if you use a property that doesn't exist, or that is mandatory, > you will get an error message stating what is wrong? If we use property, that doesn't exist, we get invalid option error. As said before, no options are mandatory. /// //./java -Xmanagement:ssl=true,authenticate=false,rmiregistry_ssl=true HelloWorld// //Error: Invalid option specified: rmiregistry_ssl// /// > > Could we reduce the command line further, so only a single property is > needed: > > -Xmanagement:secure=false > > or perhaps: > > -Xmanagement:unsecure > > which would set ssl=false,authenticate=false, because that is what you > want 99% of the time. > > Thanks > Erik > Thanks Harsha >> Hi, >> >> Please review the changes for above enhancement having webrev at, >> >> http://cr.openjdk.java.net/~hb/8187498/webrev.00/ >> >> Thanks >> Harsha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Thu Jan 25 09:15:27 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 25 Jan 2018 10:15:27 +0100 Subject: Low-Overhead Heap Profiling In-Reply-To: References: <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> <1510146425.3155.11.camel@oracle.com> <1511450419.2477.24.camel@oracle.com> Message-ID: <787d7c33-43bf-328c-9b8f-c0708ae642e9@oracle.com> Hi JC, great to see another revision! #### heapMonitoring.cpp StackTraceData should not contain the oop for 'safety' reasons. When StackTraceData is moved from _allocated_traces: L452 store_garbage_trace(trace); it contains a dead oop. _allocated_traces could instead be a tupel of oop and StackTraceData thus dead oops are not kept. You should use the new Access API for loading the oop, something like this: RootAccess::load(...) I don't think you need to use Access API for clearing the oop, but it would look nicer. And you shouldn't probably be using: Universe::heap()->is_in_reserved(value) The lock: L424 MutexLocker mu(HeapMonitorStorage_lock); Is not needed as far as I can see. weak_oops_do is called in a safepoint, no TLAB allocation can happen and JVMTI thread can't access these data-structures. Is there something more to this lock that I'm missing? #### You have 6 files without any changes in them (any more): g1CollectedHeap.cpp psMarkSweep.cpp psParallelCompact.cpp genCollectedHeap.cpp referenceProcessor.cpp thread.hpp #### I have not looked closely, but is it possible to hide heap sampling in AllocTracer ? (with some minor changes to the AllocTracer API) #### Minor nit, when declaring pointer there is a little mix of having the pointer adjacent by type name and data name. (Most hotspot code is by type name) E.g. heapMonitoring.cpp:711 jvmtiStackTrace *trace = .... heapMonitoring.cpp:733 Method* m = vfst.method(); (not just this file) #### HeapMonitorThreadOnOffTest.java:77 I would make g_tmp volatile, otherwise the assignment in loop may theoretical be skipped. Thanks! /Robbin On 01/24/2018 01:40 AM, JC Beyler wrote: > And it has been exactly two months since I posted an update here :) > > Thanksgiving, Christmas, and handling > https://bugs.openjdk.java.net/browse/JDK-8190862 will do that to you > :) > > I have gotten back to this item now that JDK-8190862 is done and I > have the following webrev ready: > http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ > > With the incremental here: > http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.01_02/ > > The updates are: > > a) GetCachedTraces > > - I added a GC collection if the GetLiveTraces is called, this is > because you really want to know what is currently live when you call > that method > - If you are worried about performance and only care about what was > live at the last GC, you can now call GetCachedTraces, which does not > provoke a GC > > Let me know if there are any questions here or concerns. I'm happy to > explain and defend the choices :). > Note: I added a new test for this and updated other tests to double > check the live call. (see for example > http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.01_02/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorCachedTest.java.html) > > b) Disabling samples wipes out the data > > I had originally implemented for OpenJdk a version that keeps the data > in memory after disabling the sampler, allowing a user to get traces > post-sampling. Because of this, we would always do the weak_oops_do > method, whether enabled or disabled. This led to a slight regression > in performance for GC reference processing time. I had initially fixed > this with a small "was this ever enabled" flag. This would have > allowed a program that never uses this to not have a regression but a > program that enables the disabled the code for the rest of the > execution would still pay the price after disabling the sampler. > > Because of this, I have moved things back to where they probably > should be: if you disable the sampler, you lose the data. But this > allows a simpler code path: if the sampler is disabled, skip over the > GC weak_oops_do method. > > Let me know what you think and happy 2018 to all! > Jc > > On Thu, Nov 23, 2017 at 7:20 AM, Thomas Schatzl > wrote: >> On Tue, 2017-11-21 at 13:50 -0800, JC Beyler wrote: >>> Hi all, >>> >>> I have a new webrev here: >>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.15/ >>> >>> With the incremental one here: >>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/ >>> >>> I think I did most items from Thomans and Robbin. I've especially >>> added a new test: >> >> Thanks. Looks good. >> >> Thanks, >> Thomas >> From erik.helin at oracle.com Thu Jan 25 13:20:02 2018 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 25 Jan 2018 14:20:02 +0100 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> Message-ID: <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> Hi Paul, thanks for your interest in this area and for your patch! The GarbageCollectorMXBean and MemoryPoolMXBean support for G1 is in need of some updates, so thanks for working on this. Looking at your patch, I'm not sure that this is the direction we want to go in. I discussed this a bit with Thomas and Stefan J, and our current line of thinking is the following: - Memory pools (MemoryMXBean): - "G1 Eden Regions" - "G1 Survivor Regions" - "G1 Old Regions" - "G1 Humongous Regions" - "G1 Archive Regions" (if CDS and/or AppCDS is used) `init` for these pools would be 0, `used` would be total size of the "live" objects in the used regions of that type, `committed` the total size of the used regions of that that type and `max` would be MaxHeapSize. Note that "live" here means live from the GCs point of view, i.e. an object might be dead in an old region but the GC will consider that object live until a concurrent cycle has marked through the heap and deemed it dead. - Collectors (GarbageCollectorMXBean): - "G1 Young Collector" with the pools - "G1 Eden Regions" - "G1 Survivor Regions" - "G1 Humongous Regions" (due to early reclamation) - "G1 Mixed Collector" with the pools - "G1 Eden Regions" - "G1 Survivor Regions" - "G1 Old Regions" - "G1 Humongous Regions" (due to early reclamation) - "G1 Full Collector" with the pools - "G1 Eden Regions" - "G1 Survivor Regions" - "G1 Old Regions" - "G1 Humongous Regions" (can collect empty humongous regions) - "G1 Concurrent Cycle" with the pools - "G1 Old Regions" (can collect empty old regions) - "G1 Humongous Regions" (can collect empty humongous regions) Note that with this design, the GarbageCollectorMXBean::getCollectionTime() method for "G1 Concurrent Cycle" would be the wall clock time from start of the first initial mark to end of the last cleanup (also including the time of any eventual young collection during the concurrent cycle). So GarbageCollectorMXBean::getCollectionTime() would be a mix of concurrent and STW time for the GarbageCollectorMXBean with name "G1 Concurrent Cycle". Also note that the MemoryPoolMXBean with name "G1 Archive Regions" will not be attached to any GarbageCollectorMXBean, since those regions will never be collected. What do you think about this design, would it work for your use case? If we want to go ahead with this design, then I think we might have to file a CSR. David (who is the HotSpot CSR representative), do we have to file a CSR for changing the names of MemoryPoolMXBeans and GarbageCollectorMXBeans? Thanks, Erik On 01/20/2018 12:40 AM, Hohensee, Paul wrote: > I?d appreciate a review please. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.00/ > > The bug is that from the JMX point of view, G1?s incremental collector > (misnamed as the ?G1 Young Generation? collector) only affects G1?s > survivor and eden spaces. In fact, mixed collections run by this > collector also affect the G1 old generation. > > This proposed fix is to record, for each of a JMX garbage collector's > memory pools, whether that memory pool is affected by all collections > using that collector. And, for each collection, record whether or not > all the collector's memory pools are affected. After each collection, > for each memory pool, if either all the collector's memory pools were > affected or the memory pool is affected for all collections, record > CollectionUsage for that pool. > > For collectors other than G1 Young Generation, all pools are recorded as > affected by all collections and every collection is recorded as > affecting all the collector?s memory pools. For the G1 Young Generation > collector, the G1 Old Gen pool is recorded as not being affected by all > collections, and non-mixed collections are recorded as not affecting all > memory pools. The result is that for non-mixed collections, > CollectionUsage is recorded after a collection only the G1 Eden Space > and G1 Survivor Space pools, while for mixed collections CollectionUsage > is recorded for G1 Old Gen as well. > > Other than the effect of the fix on G1 Old Gen MemoryPool. > CollectionUsage, the only external behavior change is that > GarbageCollectorMXBean.getMemoryPoolNames will now return 3 pool names > rather than 2. > > With this fix, a collector?s memory pools can be divided into two > disjoint subsets, one that participates in all collections and one that > doesn?t. This is a bit more general than the minimum necessary to fix > G1, but not by much. Because I expect it to apply to other incremental > region-based collectors, I went with the more general solution. I > minimized the amount of code I had to touch by using default parameters > for GCMemoryManager::add_pool and the TraceMemoryManagerStats constructors. > > Tested by running the new jtreg test included in the webrev. I tried to > use the submit repo, but it was out of order earlier today, so I?d be > much obliged if someone could run it through mach5 and sponsor an > eventual push. I successfully ran a JDK8 version of the patch through > all the JDK8 jtreg tests as well as the JDK8 TCK. > > Thanks, > > Paul > From mandy.chung at oracle.com Thu Jan 25 16:01:17 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 25 Jan 2018 08:01:17 -0800 Subject: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties In-Reply-To: <05c2e5af-b9d0-0386-4565-ade1179a1d49@oracle.com> References: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> <5A687F75.3050404@oracle.com> <05c2e5af-b9d0-0386-4565-ade1179a1d49@oracle.com> Message-ID: Hi Harsha, JEP 293 [1] describes the guidelines for JDK command-line options.? As Alan points out, new options should move away from -X prefix but use `--` GNU-style long form option.? The guideline says: The use of |-X| as a prefix to indicate "non-standard" options will be discontinued for new options, although command-line help may continue to draw a distinction between more commonly used options and those for advanced use. You can consider `--management` as an alternative.? Should this be a launcher option that converts it to the corresponding `-Dcom.sun.management.jmxremote.` rather than a VM option? Mandy [1] http://openjdk.java.net/jeps/293 On 1/24/18 11:21 PM, Harsha Wardhana B wrote: > > Hi Erik, > > The minimal command line would be, > > "-Xmanagement", that will start only the local management server. > > "-Xmanagement:local=true,port=aaaa" will start the remote management > server without SSL or authentication. > > > On Wednesday 24 January 2018 06:13 PM, Erik Gahlin wrote: >> Hi Harsha, >> >> Very nice to see progress on this! >> >> Before reviewing, the minimal command line to start up the default >> management server now becomes >> >> -Xmanagement:ssl=false,authenticate=false > No. Please refer above for minimal options. >> >> and if you use a property that doesn't exist, or that is mandatory, >> you will get an error message stating what is wrong? > If we use property, that doesn't exist, we get invalid option error. > As said before, no options are mandatory. > /// > //./java -Xmanagement:ssl=true,authenticate=false,rmiregistry_ssl=true > HelloWorld// > //Error: Invalid option specified: rmiregistry_ssl// > /// >> >> Could we reduce the command line further, so only a single property >> is needed: >> >> -Xmanagement:secure=false >> >> or perhaps: >> >> -Xmanagement:unsecure >> >> which would set ssl=false,authenticate=false, because that is what >> you want 99% of the time. >> >> Thanks >> Erik >> > Thanks > Harsha >>> Hi, >>> >>> Please review the changes for above enhancement having webrev at, >>> >>> http://cr.openjdk.java.net/~hb/8187498/webrev.00/ >>> >>> Thanks >>> Harsha >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Jan 25 18:46:41 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 25 Jan 2018 13:46:41 -0500 Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() Message-ID: <5A6A2611.4030003@oracle.com> Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS build flag and update the winsock deprecated functions. Issue: https://bugs.openjdk.java.net/browse/JDK-8080990 Webrev: http://cr.openjdk.java.net/~gadams/8080990/ These are the initial deprecated functions updated: gethostbyname -> getaddrinfo inet_addr -> inet_pton inet_ntoa -> inet_ntop I'm not sure how to replace the existing WSASendDisconnect calls. It's not clear that it actually provides a graceful disconnect. From erik.joelsson at oracle.com Thu Jan 25 21:03:27 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Jan 2018 13:03:27 -0800 Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() In-Reply-To: <5A6A2611.4030003@oracle.com> References: <5A6A2611.4030003@oracle.com> Message-ID: <5a049eab-ce79-86d9-9f52-ba0dd7bb2d34@oracle.com> Build change looks fine. /Erik On 2018-01-25 10:46, Gary Adams wrote: > Here's a first pass attempt to remove the > -D_WINSOCK_DEPRECATED_NO_WARNINGS > build flag and update the winsock deprecated functions. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8080990 > ? Webrev: http://cr.openjdk.java.net/~gadams/8080990/ > > These are the initial deprecated functions updated: > ?? gethostbyname -> getaddrinfo > ?? inet_addr -> inet_pton > ?? inet_ntoa -> inet_ntop > > I'm not sure how to replace the existing WSASendDisconnect calls. > It's not clear that it actually provides a graceful disconnect. > > From hohensee at amazon.com Thu Jan 25 21:04:26 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 25 Jan 2018 21:04:26 +0000 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> Message-ID: <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> Hi Erik & co, thanks for looking at this. Would you be ok with pushing this fix (it really is a bug!) and then me doing a followup RFE? That way, I can backport the fix to 8u and eventually remove the patch I?ve already pushed to our OpenJDK8 internal release. Some background. We used to measure heap occupancy using MemoryPoolMXBean.Usage and alarm on it when it got ?too high?. The problem is that it?s an instantaneous measure and therefore includes an unknown amount of garbage, so you can?t determine where to set an alarm, because you don?t know how much of it will be collected in the near future. We want to detect steadily increasing memory use such as you?d see with a leak, so we?re switching to MemoryPoolMXBean.CollectionUsage, which is the usage immediately after the last GC that affected the memory pool. We have a synthetic metric that?s defined for all collectors as (sum of CollectionUsage.used for non-eden pools) / (sum of CollectionUsage.max-if-defined for all non-eden pools), and alarm on that. ?max-if-defined? means zero if JMX returns -1, which is the ?undefined? value. The JMX API spec doesn?t specify what the memory pool or garbage collector names are, but the current names are de-facto part of the API, so if we change the existing ones, imo a CSR should be filed. To avoid that, how about we keep the existing memory pool names the same and, in the spirit of compatibility, make the new ones similar to the existing ones. I.e., ?G1 Eden Space? ?G1 Survivor Space? ?G1 Old Gen? ?G1 Humongous Space? ?G1 Archive Space? Alternatively, we can make the existing names aliases for the new ones, though ?Regions? seems a bit G1-specific to me and doesn?t convey the relationship to the equivalent spaces in the other collectors. Especially if there?s an archive space for the other collectors (see below). There?s no specification requirement that memory pools be disjoint. What do you think of defining the archive space as a subset of the old gen? That way existing code can stay the same (it typically just iterates over a collector?s pools as above), and new code can decide exactly what it wants to report. Do/should the non-G1 collectors have an archive space too? If so, we should just call it ?Archive Space? and not make it G1 specific. I?d guess for non-G1 collectors it?s just the initial live prefix of the old gen and therefore ignored during a collection. In this scheme, the initial value of ?used? for all collectors? oldgens would be the size of the archive space. All the archive space?s MemoryUsage attributes would have the same value. Not attaching the archive space to any collector seems correct, because a collector?s memory pools are defined to be the ones that it affects. Currently, Usage.max and CollectionUsage.max for all G1 memory pools other than the oldgen is -1, for ?undefined?. For the oldgen it?s ?Xmx. This makes it easy to generate aggregate metrics for all the collectors by just summing used values and dividing by the sum of max values as described above. It would be nice to keep this characteristic. Otherwise we?d have to write special-case code for G1, and change existing code to check for which JDK we?re running on. I?m uncertain whether your definition of the memory pool usage fields is for MemoryPool.Usage or MemoryPool.CollectionUsage. Seems like the former, which is fine and matches the current definition, except for max. All the existing collector names have an implicit ? Collector? suffix, e.g., ?ConcurrentMarkSweep? means ?ConcurrentMarkSweep Collector?. So, I?d use ?G1 Young? ?G1 Mixed? ?G1 Full? ?G1 Concurrent Cycle? keep the existing ?G1 Young Collection? as an alias for both ?G1 Young? and ?G1 Mixed?, and keep the existing ?G1 Old Collection? as an alias for ?G1 Full?. If you accept this and the memory pool name suggestions, then strictly speaking you don?t need a CSR. The definition of the ?G1 Concurrent Cycle? elapsed time makes sense to me. The young collection would still be reported separately, right? Paul On 1/25/18, 5:27 AM, "Erik Helin" wrote: Hi Paul, thanks for your interest in this area and for your patch! The GarbageCollectorMXBean and MemoryPoolMXBean support for G1 is in need of some updates, so thanks for working on this. Looking at your patch, I'm not sure that this is the direction we want to go in. I discussed this a bit with Thomas and Stefan J, and our current line of thinking is the following: - Memory pools (MemoryMXBean): - "G1 Eden Regions" - "G1 Survivor Regions" - "G1 Old Regions" - "G1 Humongous Regions" - "G1 Archive Regions" (if CDS and/or AppCDS is used) `init` for these pools would be 0, `used` would be total size of the "live" objects in the used regions of that type, `committed` the total size of the used regions of that that type and `max` would be MaxHeapSize. Note that "live" here means live from the GCs point of view, i.e. an object might be dead in an old region but the GC will consider that object live until a concurrent cycle has marked through the heap and deemed it dead. - Collectors (GarbageCollectorMXBean): - "G1 Young Collector" with the pools - "G1 Eden Regions" - "G1 Survivor Regions" - "G1 Humongous Regions" (due to early reclamation) - "G1 Mixed Collector" with the pools - "G1 Eden Regions" - "G1 Survivor Regions" - "G1 Old Regions" - "G1 Humongous Regions" (due to early reclamation) - "G1 Full Collector" with the pools - "G1 Eden Regions" - "G1 Survivor Regions" - "G1 Old Regions" - "G1 Humongous Regions" (can collect empty humongous regions) - "G1 Concurrent Cycle" with the pools - "G1 Old Regions" (can collect empty old regions) - "G1 Humongous Regions" (can collect empty humongous regions) Note that with this design, the GarbageCollectorMXBean::getCollectionTime() method for "G1 Concurrent Cycle" would be the wall clock time from start of the first initial mark to end of the last cleanup (also including the time of any eventual young collection during the concurrent cycle). So GarbageCollectorMXBean::getCollectionTime() would be a mix of concurrent and STW time for the GarbageCollectorMXBean with name "G1 Concurrent Cycle". Also note that the MemoryPoolMXBean with name "G1 Archive Regions" will not be attached to any GarbageCollectorMXBean, since those regions will never be collected. What do you think about this design, would it work for your use case? If we want to go ahead with this design, then I think we might have to file a CSR. David (who is the HotSpot CSR representative), do we have to file a CSR for changing the names of MemoryPoolMXBeans and GarbageCollectorMXBeans? Thanks, Erik On 01/20/2018 12:40 AM, Hohensee, Paul wrote: > I?d appreciate a review please. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.00/ > > The bug is that from the JMX point of view, G1?s incremental collector > (misnamed as the ?G1 Young Generation? collector) only affects G1?s > survivor and eden spaces. In fact, mixed collections run by this > collector also affect the G1 old generation. > > This proposed fix is to record, for each of a JMX garbage collector's > memory pools, whether that memory pool is affected by all collections > using that collector. And, for each collection, record whether or not > all the collector's memory pools are affected. After each collection, > for each memory pool, if either all the collector's memory pools were > affected or the memory pool is affected for all collections, record > CollectionUsage for that pool. > > For collectors other than G1 Young Generation, all pools are recorded as > affected by all collections and every collection is recorded as > affecting all the collector?s memory pools. For the G1 Young Generation > collector, the G1 Old Gen pool is recorded as not being affected by all > collections, and non-mixed collections are recorded as not affecting all > memory pools. The result is that for non-mixed collections, > CollectionUsage is recorded after a collection only the G1 Eden Space > and G1 Survivor Space pools, while for mixed collections CollectionUsage > is recorded for G1 Old Gen as well. > > Other than the effect of the fix on G1 Old Gen MemoryPool. > CollectionUsage, the only external behavior change is that > GarbageCollectorMXBean.getMemoryPoolNames will now return 3 pool names > rather than 2. > > With this fix, a collector?s memory pools can be divided into two > disjoint subsets, one that participates in all collections and one that > doesn?t. This is a bit more general than the minimum necessary to fix > G1, but not by much. Because I expect it to apply to other incremental > region-based collectors, I went with the more general solution. I > minimized the amount of code I had to touch by using default parameters > for GCMemoryManager::add_pool and the TraceMemoryManagerStats constructors. > > Tested by running the new jtreg test included in the webrev. I tried to > use the submit repo, but it was out of order earlier today, so I?d be > much obliged if someone could run it through mach5 and sponsor an > eventual push. I successfully ran a JDK8 version of the patch through > all the JDK8 jtreg tests as well as the JDK8 TCK. > > Thanks, > > Paul > From alexey.menkov at oracle.com Fri Jan 26 00:11:38 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 25 Jan 2018 16:11:38 -0800 Subject: 8161605 : The '!UseSharedSpaces' check is not need in JvmtiManageCapabilities::recompute_always_capabilities Message-ID: Hi all, Please take a look at a fix for JDK-8161605 : The '!UseSharedSpaces' check is not need in JvmtiManageCapabilities::recompute_always_capabilities The fix moves can_generate_all_class_hook_events capability from "onload_capabilities" to "always_capabilities" and cleans up recompute_always_capabilities method. jira: https://bugs.openjdk.java.net/browse/JDK-8161605 webrev: http://cr.openjdk.java.net/~amenkov/can_generate_class_hook/webrev/ --alex From jcbeyler at google.com Fri Jan 26 05:45:27 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 25 Jan 2018 21:45:27 -0800 Subject: Low-Overhead Heap Profiling In-Reply-To: <787d7c33-43bf-328c-9b8f-c0708ae642e9@oracle.com> References: <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> <1510146425.3155.11.camel@oracle.com> <1511450419.2477.24.camel@oracle.com> <787d7c33-43bf-328c-9b8f-c0708ae642e9@oracle.com> Message-ID: Thanks Robbin for the reviews :) The new full webrev is here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.03/ The incremental webrev is here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02_03/ I inlined my answers: On Thu, Jan 25, 2018 at 1:15 AM, Robbin Ehn wrote: > Hi JC, great to see another revision! > > #### > heapMonitoring.cpp > > StackTraceData should not contain the oop for 'safety' reasons. > When StackTraceData is moved from _allocated_traces: > L452 store_garbage_trace(trace); > it contains a dead oop. > _allocated_traces could instead be a tupel of oop and StackTraceData thus > dead oops are not kept. Done I used inheritance to make the copier work regardless but the idea is the same. > > You should use the new Access API for loading the oop, something like this: > RootAccess::load(...) > I don't think you need to use Access API for clearing the oop, but it would > look nicer. And you shouldn't probably be using: > Universe::heap()->is_in_reserved(value) I am unfamiliar with this but I think I did do it like you wanted me to (all tests pass so that's a start). I'm not sure how to clear the oop exactly, is there somewhere that does that, which I can use to do the same? I removed the is_in_reserved, this came from our internal version, I don't know why it was there but my tests work without so I removed it :) > > The lock: > L424 MutexLocker mu(HeapMonitorStorage_lock); > Is not needed as far as I can see. > weak_oops_do is called in a safepoint, no TLAB allocation can happen and > JVMTI thread can't access these data-structures. Is there something more to > this lock that I'm missing? Since a thread can call the JVMTI getLiveTraces (or any of the other ones), it can get to the point of trying to copying the _allocated_traces. I imagine it is possible that this is happening during a GC or that it can be started and a GC happens afterwards. Therefore, it seems to me that you want this protected, no? > > #### > You have 6 files without any changes in them (any more): > g1CollectedHeap.cpp > psMarkSweep.cpp > psParallelCompact.cpp > genCollectedHeap.cpp > referenceProcessor.cpp > thread.hpp > Done. > #### > I have not looked closely, but is it possible to hide heap sampling in > AllocTracer ? (with some minor changes to the AllocTracer API) > I am imagining that you are saying to move the code that does the sampling code (change the tlab end, do the call to HeapMonitoring, etc.) into the AllocTracer code itself? I think that is right and I'll look if that is possible and prepare a webrev to show what would be needed to make that happen. > #### > Minor nit, when declaring pointer there is a little mix of having the > pointer adjacent by type name and data name. (Most hotspot code is by type > name) > E.g. > heapMonitoring.cpp:711 jvmtiStackTrace *trace = .... > heapMonitoring.cpp:733 Method* m = vfst.method(); > (not just this file) > Done! > #### > HeapMonitorThreadOnOffTest.java:77 > I would make g_tmp volatile, otherwise the assignment in loop may > theoretical be skipped. > Also done! Thanks again! Jc From robbin.ehn at oracle.com Fri Jan 26 13:51:08 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 26 Jan 2018 14:51:08 +0100 Subject: Low-Overhead Heap Profiling In-Reply-To: References: <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> <1510146425.3155.11.camel@oracle.com> <1511450419.2477.24.camel@oracle.com> <787d7c33-43bf-328c-9b8f-c0708ae642e9@oracle.com> Message-ID: <63a3a1ba-f566-8b9a-668c-f82e0479aef1@oracle.com> Hi JC, (dropping compiler on mail thread) On 01/26/2018 06:45 AM, JC Beyler wrote: > Thanks Robbin for the reviews :) > > The new full webrev is here: > http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.03/ > The incremental webrev is here: > http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02_03/ Thanks! I got this compile issue: /home/rehn/source/jdk/small/open/src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp: In static member function 'static void G1ResManTLABCache::put(ThreadLocalAllocBuffer&, AllocationContext_t)': /home/rehn/source/jdk/small/open/src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp:97:13: error: 'HeapWord* ThreadLocalAllocBuffer::hard_end()' is private HeapWord* hard_end(); ^ /home/rehn/source/jdk/small/closed/src/hotspot/share/gc/g1/g1ResManTLABCache.cpp:52:50: error: within this context size_t remaining = pointer_delta(tlab.hard_end(), tlab.top()); > > I inlined my answers: > > On Thu, Jan 25, 2018 at 1:15 AM, Robbin Ehn wrote: >> Hi JC, great to see another revision! >> >> #### >> heapMonitoring.cpp >> >> StackTraceData should not contain the oop for 'safety' reasons. >> When StackTraceData is moved from _allocated_traces: >> L452 store_garbage_trace(trace); >> it contains a dead oop. >> _allocated_traces could instead be a tupel of oop and StackTraceData thus >> dead oops are not kept. > > Done I used inheritance to make the copier work regardless but the > idea is the same. Looks good. > >> >> You should use the new Access API for loading the oop, something like this: >> RootAccess::load(...) >> I don't think you need to use Access API for clearing the oop, but it would >> look nicer. And you shouldn't probably be using: >> Universe::heap()->is_in_reserved(value) > > I am unfamiliar with this but I think I did do it like you wanted me > to (all tests pass so that's a start). I'm not sure how to clear the > oop exactly, is there somewhere that does that, which I can use to do > the same? > > I removed the is_in_reserved, this came from our internal version, I > don't know why it was there but my tests work without so I removed it > :) I talked a bit with GC folks about this today. So actually the oop should be in the oopStorage and your should have a weakhandle to that oop (at least in the near future). But this should work for now... In the future when we have the oop in oppStorage you will not get called, so you will not know when the oops are dead, either GC must trigger a concurrent vm operation (e.g. _no_ safepoint operation) so we can clear dead oops or do periodic scanning. It would be good with some input here from Thomas that knows what you are doing and knows GC. > > >> >> The lock: >> L424 MutexLocker mu(HeapMonitorStorage_lock); >> Is not needed as far as I can see. >> weak_oops_do is called in a safepoint, no TLAB allocation can happen and >> JVMTI thread can't access these data-structures. Is there something more to >> this lock that I'm missing? > > Since a thread can call the JVMTI getLiveTraces (or any of the other > ones), it can get to the point of trying to copying the > _allocated_traces. I imagine it is possible that this is happening > during a GC or that it can be started and a GC happens afterwards. > Therefore, it seems to me that you want this protected, no? A thread calling getLiveTraces will be stopped in the HeapThreadTransition. A safepoint don't allow any threads to be in_vm or to be in_java during safepoint. Only threads in native can execute, but they will be stopped on any transition. If a thread is in_vm the safepoint waits to a transition (locking a mutex is also transition to blocked). So if weak_oops is called you have an guarantee that no threads are executing inside the VM or executing Java code. (not counting GC threads of course) This also means that the lock can never be contented when weak_oops is called, so it's not harmful. > > >> >> #### >> You have 6 files without any changes in them (any more): >> g1CollectedHeap.cpp >> psMarkSweep.cpp >> psParallelCompact.cpp >> genCollectedHeap.cpp >> referenceProcessor.cpp >> thread.hpp >> > > Done. > >> #### >> I have not looked closely, but is it possible to hide heap sampling in >> AllocTracer ? (with some minor changes to the AllocTracer API) >> > > I am imagining that you are saying to move the code that does the > sampling code (change the tlab end, do the call to HeapMonitoring, > etc.) into the AllocTracer code itself? I think that is right and I'll > look if that is possible and prepare a webrev to show what would be > needed to make that happen. Sounds good. > >> #### >> Minor nit, when declaring pointer there is a little mix of having the >> pointer adjacent by type name and data name. (Most hotspot code is by type >> name) >> E.g. >> heapMonitoring.cpp:711 jvmtiStackTrace *trace = .... >> heapMonitoring.cpp:733 Method* m = vfst.method(); >> (not just this file) >> > > Done! > >> #### >> HeapMonitorThreadOnOffTest.java:77 >> I would make g_tmp volatile, otherwise the assignment in loop may >> theoretical be skipped. >> > > Also done! Looks good, thanks! /Robbin > > Thanks again! > Jc > From mandy.chung at oracle.com Fri Jan 26 20:53:39 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 26 Jan 2018 12:53:39 -0800 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> Message-ID: <731b851e-ddf5-1bcc-a333-1c73a0ea875d@oracle.com> Hi Erik, The proposal you outline below is reasonable. The API was designed to allow any number of memory pools managed by a memory manager that can represent different phases of a garbage collector or other resource manager to expose various metrics. How G1 exposes these monitoring metrics is implementation specific. More comments inlined below. On 1/25/18, 5:27 AM, "Erik Helin" wrote: > > Hi Paul, > > thanks for your interest in this area and for your patch! The > GarbageCollectorMXBean and MemoryPoolMXBean support for G1 is in need of > some updates, so thanks for working on this. > > Looking at your patch, I'm not sure that this is the direction we want > to go in. I discussed this a bit with Thomas and Stefan J, and our > current line of thinking is the following: > > - Memory pools (MemoryMXBean): > - "G1 Eden Regions" > - "G1 Survivor Regions" > - "G1 Old Regions" > - "G1 Humongous Regions" > - "G1 Archive Regions" (if CDS and/or AppCDS is used) > Can you describe more about G1 archive regions? Is it an immutable region that no object will be added or removed? > `init` for these pools would be 0, `used` would be total size of the > "live" objects in the used regions of that type, `committed` the total > size of the used regions of that that type and `max` would be > MaxHeapSize. Note that "live" here means live from the GCs point of > view, i.e. an object might be dead in an old region but the GC will > consider that object live until a concurrent cycle has marked through > the heap and deemed it dead. As specified in MemoryPoolMXBean spec, for MemoryPoolMXBean::getUsage of a garbage-collected memory pool, the amount of used memory includes the memory occupied by all objects in the pool including both reachable and unreachable objects. OTOH, getCollectionUsage returns the memory usage after JVM most recently expended effort in recycling unused objects in this memory pool. It would depend on what a GC cycle is defined for G1 and at what phase G1 can record the "collection usage" with low overhead. Definitely the API does not request G1 to perform any GC-like action and "collection usage" reports how much memory is used at most recent GC cycle after some memory has been reclaimed. > > - Collectors (GarbageCollectorMXBean): > - "G1 Young Collector" with the pools > - "G1 Eden Regions" > - "G1 Survivor Regions" > - "G1 Humongous Regions" (due to early reclamation) > - "G1 Mixed Collector" with the pools > - "G1 Eden Regions" > - "G1 Survivor Regions" > - "G1 Old Regions" > - "G1 Humongous Regions" (due to early reclamation) > - "G1 Full Collector" with the pools > - "G1 Eden Regions" > - "G1 Survivor Regions" > - "G1 Old Regions" > - "G1 Humongous Regions" (can collect empty humongous regions) > - "G1 Concurrent Cycle" with the pools > - "G1 Old Regions" (can collect empty old regions) > - "G1 Humongous Regions" (can collect empty humongous regions) > > Note that with this design, the > GarbageCollectorMXBean::getCollectionTime() method for "G1 Concurrent > Cycle" would be the wall clock time from start of the first initial mark > to end of the last cleanup (also including the time of any eventual > young collection during the concurrent cycle). So > GarbageCollectorMXBean::getCollectionTime() would be a mix of concurrent > and STW time for the GarbageCollectorMXBean with name "G1 Concurrent Cycle". > GarbageCollectorMXBean API was defined prior to G1. It's a future enhancement to investigate how to represent the concurrent garbage collection metrics for better monitoring purpose. Do you have any thought for monitoring of G1 GC metrics besides memory usage? > Also note that the MemoryPoolMXBean with name "G1 Archive Regions" will > not be attached to any GarbageCollectorMXBean, since those regions will > never be collected. > > What do you think about this design, would it work for your use case? > > If we want to go ahead with this design, then I think we might have to > file a CSR. David (who is the HotSpot CSR representative), do we have to > file a CSR for changing the names of MemoryPoolMXBeans and > GarbageCollectorMXBeans? The names are not a supported interface but I'm not surprised applications may depend on the names. CSR as well as a release note to document this change is reasonable. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Jan 26 22:38:18 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 26 Jan 2018 14:38:18 -0800 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> Message-ID: <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> On 1/25/18 1:04 PM, Hohensee, Paul wrote: > The JMX API spec doesn?t specify what the memory pool or garbage > collector names are, but the current names are de-facto part of the > API, so if we change the existing ones, imo a CSR should be filed. The names are implementation details but I can see how an application might be impacted if they depend on it. CSR approval is not strictly necessary while I think filing one to document the change would be good. Does the name change impact any application you know of?? I'm trying to understand if any improvement to API is needed so that applications don't need to depend on the names. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Sat Jan 27 04:01:38 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 26 Jan 2018 20:01:38 -0800 Subject: JDK-8171119: Low-Overhead Heap Profiling Message-ID: (Change of subject to contain the bug number :)). New webrev is here: Incremental: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.03_04/ Full webrev: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.04/ Inlined are my answers again :). On Fri, Jan 26, 2018 at 5:51 AM, Robbin Ehn wrote: > Hi JC, (dropping compiler on mail thread) > > On 01/26/2018 06:45 AM, JC Beyler wrote: >> >> Thanks Robbin for the reviews :) >> >> The new full webrev is here: >> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.03/ >> The incremental webrev is here: >> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02_03/ > > > Thanks! > > I got this compile issue: > /home/rehn/source/jdk/small/open/src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp: > In static member function 'static void > G1ResManTLABCache::put(ThreadLocalAllocBuffer&, AllocationContext_t)': > /home/rehn/source/jdk/small/open/src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp:97:13: > error: 'HeapWord* ThreadLocalAllocBuffer::hard_end()' is private > HeapWord* hard_end(); > ^ > /home/rehn/source/jdk/small/closed/src/hotspot/share/gc/g1/g1ResManTLABCache.cpp:52:50: > error: within this context > size_t remaining = pointer_delta(tlab.hard_end(), tlab.top()); This is strange but I'm assuming it is because we are not working on the same repo? I used: hg clone http://hg.openjdk.java.net/jdk/hs jdkhs-heap I'll try a new clone on Monday and see. My new version moved hard_end back to public so it should work now. > >> >> I inlined my answers: >> >> On Thu, Jan 25, 2018 at 1:15 AM, Robbin Ehn wrote: >>> >>> Hi JC, great to see another revision! >>> >>> #### >>> heapMonitoring.cpp >>> >>> StackTraceData should not contain the oop for 'safety' reasons. >>> When StackTraceData is moved from _allocated_traces: >>> L452 store_garbage_trace(trace); >>> it contains a dead oop. >>> _allocated_traces could instead be a tupel of oop and StackTraceData thus >>> dead oops are not kept. >> >> >> Done I used inheritance to make the copier work regardless but the >> idea is the same. > > > Looks good. > >> >>> >>> You should use the new Access API for loading the oop, something like >>> this: >>> RootAccess::load(...) >>> I don't think you need to use Access API for clearing the oop, but it >>> would >>> look nicer. And you shouldn't probably be using: >>> Universe::heap()->is_in_reserved(value) >> >> >> I am unfamiliar with this but I think I did do it like you wanted me >> to (all tests pass so that's a start). I'm not sure how to clear the >> oop exactly, is there somewhere that does that, which I can use to do >> the same? >> >> I removed the is_in_reserved, this came from our internal version, I >> don't know why it was there but my tests work without so I removed it >> :) > > > I talked a bit with GC folks about this today. > So actually the oop should be in the oopStorage and your should have a > weakhandle to that oop (at least in the near future). > But this should work for now... > In the future when we have the oop in oppStorage you will not get called, so > you will not know when the oops are dead, either GC must trigger a > concurrent vm operation (e.g. _no_ safepoint operation) so we can clear dead > oops or do periodic scanning. > > It would be good with some input here from Thomas that knows what you are > doing and knows GC. Fair enough, hopefully Thomas will chime in. Are you saying that this first version could go in and we can work on a refinement? Or are you saying I should work on this now at the same time and fix it before this V1 goes in? (Just so I know :)) > >> >> >>> >>> The lock: >>> L424 MutexLocker mu(HeapMonitorStorage_lock); >>> Is not needed as far as I can see. >>> weak_oops_do is called in a safepoint, no TLAB allocation can happen and >>> JVMTI thread can't access these data-structures. Is there something more >>> to >>> this lock that I'm missing? >> >> >> Since a thread can call the JVMTI getLiveTraces (or any of the other >> ones), it can get to the point of trying to copying the >> _allocated_traces. I imagine it is possible that this is happening >> during a GC or that it can be started and a GC happens afterwards. >> Therefore, it seems to me that you want this protected, no? Looks like it yes, I removed it, ran my tests and they work so the new webrev no longer has that mutex at all. > > > A thread calling getLiveTraces will be stopped in the HeapThreadTransition. > A safepoint don't allow any threads to be in_vm or to be in_java during > safepoint. Only threads in native can execute, but they will be stopped on > any transition. If a thread is in_vm the safepoint waits to a transition > (locking a mutex is also transition to blocked). So if weak_oops is called > you have an guarantee that no threads are executing inside the VM or > executing Java code. (not counting GC threads of course) > This also means that the lock can never be contented when weak_oops is > called, so it's not harmful. > >> >> >>> >>> #### >>> You have 6 files without any changes in them (any more): >>> g1CollectedHeap.cpp >>> psMarkSweep.cpp >>> psParallelCompact.cpp >>> genCollectedHeap.cpp >>> referenceProcessor.cpp >>> thread.hpp >>> >> >> Done. >> >>> #### >>> I have not looked closely, but is it possible to hide heap sampling in >>> AllocTracer ? (with some minor changes to the AllocTracer API) >>> >> >> I am imagining that you are saying to move the code that does the >> sampling code (change the tlab end, do the call to HeapMonitoring, >> etc.) into the AllocTracer code itself? I think that is right and I'll >> look if that is possible and prepare a webrev to show what would be >> needed to make that happen. > > > Sounds good. I'll look at this on Monday then! Thanks for the reply and have a great weekend! Jc > >> >>> #### >>> Minor nit, when declaring pointer there is a little mix of having the >>> pointer adjacent by type name and data name. (Most hotspot code is by >>> type >>> name) >>> E.g. >>> heapMonitoring.cpp:711 jvmtiStackTrace *trace = .... >>> heapMonitoring.cpp:733 Method* m = vfst.method(); >>> (not just this file) >>> >> >> Done! >> >>> #### >>> HeapMonitorThreadOnOffTest.java:77 >>> I would make g_tmp volatile, otherwise the assignment in loop may >>> theoretical be skipped. >>> >> >> Also done! > > > Looks good, thanks! > > /Robbin > >> >> Thanks again! >> Jc >> > From yasuenag at gmail.com Sun Jan 28 12:41:55 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 28 Jan 2018 21:41:55 +0900 Subject: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <122a2fbf-6c0d-6209-28b4-0b03064b65ab@gmail.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> <122a2fbf-6c0d-6209-28b4-0b03064b65ab@gmail.com> Message-ID: <1efaeb12-720c-e93e-6010-38b3687d3bf9@gmail.com> PING: Could you review it? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ This webrev has been reviewed by Jini. I need a Reviewer and sponsor. Yasumasa On 2018/01/22 19:53, Yasumasa Suenaga wrote: > Hi Jini, > > Thank you for your review! > I will update the copyright year in this changeset. > > I'm waiting for Reviewer and sponsor. > > > Yasumasa > > > On 2018/01/22 13:14, Jini George wrote: >> Hi Yasumasa, >> >> The changes look good to me. Please do update the copyright year to 2018. >> >> Thanks! >> Jini (Not a Reviewer). >> >> >> >> On 12/31/2017 10:03 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> >>>> How did you submit to mach5 ??? >>> >>> I'm using Submit Repo for testing: >>> ?? https://wiki.openjdk.java.net/display/Build/Submit+Repo >>> >>> >>>> Anyway the failure is with: >>> >>> Thanks! >>> I've fixed them in new webrev: >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ >>> >>> This webrev has passed Mach 5 tier 1 tests in Submit Repo: >>> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171231-0202-8291 >>> >>> >>> Yasumasa >>> >>> >>> On 2017/12/30 10:31, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> Not a review ... >>>> >>>> On 29/12/2017 11:16 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> G1HeapRegionTable#getByAddress() returns incorrect HeapRegion which contains incorrect address. We can see it in Stack Memory window on HSDB. Some oop addresses are shown as Free Region (attached image). >>>>> >>>>> G1HeapRegion#getByAddress() should create HeapRegion instance from the address in _biased_base array. >>>>> >>>>> I uploaded webrev. Could you review it? >>>>> >>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ >>>>> >>>>> I've tested this change with test/hotspot/jtreg/serviceability/sa, it works fine. >>>>> But I received some failure from Mach 5. I also tested this change via submit repos. >>>>> >>>>> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 >>>>> >>>>> I cannot access this URL. Could you share the result? >>>> >>>> How did you submit to mach5 ??? >>>> >>>> Anyway the failure is with: >>>> >>>> test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java >>>> >>>> On linux and OS X: >>>> >>>> ??stderr: [Exception in thread "main" java.lang.NullPointerException >>>> ?????at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >>>> ?????at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >>>> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >>>> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >>>> >>>> On Solaris sparcv9: >>>> >>>> ??stderr: [Exception in thread "main" java.lang.RuntimeException: Address of HeapRegion does not match.: expected 0x00000007afb00000 to equal 0x00000007afc00000 >>>> ?????at jdk.test.lib.Asserts.fail(Asserts.java:594) >>>> ?????at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >>>> ?????at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >>>> ?????at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >>>> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >>>> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >>>> ] >>>> >>>> David >>>> ----- >>>> >>>>> Also I cannot access JPRT. So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa From harsha.wardhana.b at ORACLE.COM Mon Jan 29 05:20:32 2018 From: harsha.wardhana.b at ORACLE.COM (Harsha Wardhana B) Date: Mon, 29 Jan 2018 10:50:32 +0530 Subject: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties In-Reply-To: References: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> <5A687F75.3050404@oracle.com> <05c2e5af-b9d0-0386-4565-ade1179a1d49@oracle.com> Message-ID: <7a18b9d5-3a59-8132-2c4f-ba5de35bfa1d@oracle.com> Hi Mandy,Alan, Thanks for your inputs. If I keep it as launcher option, it may need to know JMX agent flags which may need to be extended in future. I would prefer making it a VM option. I will make the required changes and send out an updated webrev. -Harsha On Thursday 25 January 2018 09:31 PM, mandy chung wrote: > Hi Harsha, > > JEP 293 [1] describes the guidelines for JDK command-line options.? As > Alan points out, new options should move away from -X prefix but use > `--` GNU-style long form option.? The guideline says: > > The use of |-X| as a prefix to indicate "non-standard" options will be > discontinued for new options, although command-line help may continue > to draw a distinction between more commonly used options and those for > advanced use. > > You can consider `--management` as an alternative.? Should this be a > launcher option that converts it to the corresponding > `-Dcom.sun.management.jmxremote.` rather than a VM option? > > Mandy > [1] http://openjdk.java.net/jeps/293 > > On 1/24/18 11:21 PM, Harsha Wardhana B wrote: >> >> Hi Erik, >> >> The minimal command line would be, >> >> "-Xmanagement", that will start only the local management server. >> >> "-Xmanagement:local=true,port=aaaa" will start the remote management >> server without SSL or authentication. >> >> >> On Wednesday 24 January 2018 06:13 PM, Erik Gahlin wrote: >>> Hi Harsha, >>> >>> Very nice to see progress on this! >>> >>> Before reviewing, the minimal command line to start up the default >>> management server now becomes >>> >>> -Xmanagement:ssl=false,authenticate=false >> No. Please refer above for minimal options. >>> >>> and if you use a property that doesn't exist, or that is mandatory, >>> you will get an error message stating what is wrong? >> If we use property, that doesn't exist, we get invalid option error. >> As said before, no options are mandatory. >> /// >> //./java >> -Xmanagement:ssl=true,authenticate=false,rmiregistry_ssl=true >> HelloWorld// >> //Error: Invalid option specified: rmiregistry_ssl// >> /// >>> >>> Could we reduce the command line further, so only a single property >>> is needed: >>> >>> -Xmanagement:secure=false >>> >>> or perhaps: >>> >>> -Xmanagement:unsecure >>> >>> which would set ssl=false,authenticate=false, because that is what >>> you want 99% of the time. >>> >>> Thanks >>> Erik >>> >> Thanks >> Harsha >>>> Hi, >>>> >>>> Please review the changes for above enhancement having webrev at, >>>> >>>> http://cr.openjdk.java.net/~hb/8187498/webrev.00/ >>>> >>>> Thanks >>>> Harsha >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jan 29 08:25:23 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Jan 2018 08:25:23 +0000 Subject: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties In-Reply-To: <7a18b9d5-3a59-8132-2c4f-ba5de35bfa1d@oracle.com> References: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> <5A687F75.3050404@oracle.com> <05c2e5af-b9d0-0386-4565-ade1179a1d49@oracle.com> <7a18b9d5-3a59-8132-2c4f-ba5de35bfa1d@oracle.com> Message-ID: <0e019151-ef48-b4f4-d253-b9da62aa07c3@oracle.com> On 29/01/2018 05:20, Harsha Wardhana B wrote: > Hi Mandy,Alan, > > Thanks for your inputs. > If I keep it as launcher option, it may need to know JMX agent flags > which may need to be extended in future. > I would prefer making it a VM option. I will make the required changes > and send out an updated webrev. I think Mandy's suggestion is to just transform --management so a form that the VM can read. The launcher will need to replace the space anyway as the VM only accepts "=". -Alan From robbin.ehn at oracle.com Mon Jan 29 09:29:51 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 29 Jan 2018 10:29:51 +0100 Subject: JDK-8171119: Low-Overhead Heap Profiling In-Reply-To: References: Message-ID: Hi JC, thanks! I'm happy with current state, looks good! Truncated: On 01/27/2018 05:01 AM, JC Beyler wrote: > This is strange but I'm assuming it is because we are not working on > the same repo? > > I used: > hg clone http://hg.openjdk.java.net/jdk/hs jdkhs-heap > > I'll try a new clone on Monday and see. My new version moved hard_end > back to public so it should work now. Sorry this compile error was in closed code. Now the closed part compiles, thanks. > > Fair enough, hopefully Thomas will chime in. Are you saying that this > first version could go in and we can work on a refinement? Or are you > saying I should work on this now at the same time and fix it before > this V1 goes in? (Just so I know :)) We may have to change this before integration, but for now keep it as is. > I'll look at this on Monday then! Great! /Robbin > > Thanks for the reply and have a great weekend! > Jc > >> >>> >>>> #### >>>> Minor nit, when declaring pointer there is a little mix of having the >>>> pointer adjacent by type name and data name. (Most hotspot code is by >>>> type >>>> name) >>>> E.g. >>>> heapMonitoring.cpp:711 jvmtiStackTrace *trace = .... >>>> heapMonitoring.cpp:733 Method* m = vfst.method(); >>>> (not just this file) >>>> >>> >>> Done! >>> >>>> #### >>>> HeapMonitorThreadOnOffTest.java:77 >>>> I would make g_tmp volatile, otherwise the assignment in loop may >>>> theoretical be skipped. >>>> >>> >>> Also done! >> >> >> Looks good, thanks! >> >> /Robbin >> >>> >>> Thanks again! >>> Jc >>> >> From harsha.wardhana.b at oracle.com Mon Jan 29 09:44:07 2018 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 29 Jan 2018 15:14:07 +0530 Subject: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties In-Reply-To: <0e019151-ef48-b4f4-d253-b9da62aa07c3@oracle.com> References: <0fca13c3-1b8f-947c-9041-bdea87b04ba8@oracle.com> <5A687F75.3050404@oracle.com> <05c2e5af-b9d0-0386-4565-ade1179a1d49@oracle.com> <7a18b9d5-3a59-8132-2c4f-ba5de35bfa1d@oracle.com> <0e019151-ef48-b4f4-d253-b9da62aa07c3@oracle.com> Message-ID: <248276b1-1589-561f-0718-7bcb1fd578c7@oracle.com> Hi Alan, I am not fully aware about Java launcher or how it passes options to VM. Let me check with some other folks and get back to you. Thanks Harsha On Monday 29 January 2018 01:55 PM, Alan Bateman wrote: > > > On 29/01/2018 05:20, Harsha Wardhana B wrote: >> Hi Mandy,Alan, >> >> Thanks for your inputs. >> If I keep it as launcher option, it may need to know JMX agent flags >> which may need to be extended in future. >> I would prefer making it a VM option. I will make the required >> changes and send out an updated webrev. > I think Mandy's suggestion is to just transform --management > so a form that the VM can read. The launcher will need to replace the > space anyway as the VM only accepts "=". > > -Alan From shafi.s.ahmad at oracle.com Mon Jan 29 12:31:32 2018 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 29 Jan 2018 04:31:32 -0800 (PST) Subject: [8u] RFR for 'JDK-8195088: [TEST_BUG] StartManagementAgent got unexpected exception' Message-ID: <35e118d1-5f59-4947-bad0-4f5fbc032474@default> Hi, Please review the trivial code change for the fix of 'JDK-8195088: [TEST_BUG] StartManagementAgent got unexpected exception' to jdk8u-dev. Summary: This test case is expected to fail but the expected exception message is different. This fix - if (!ex.getMessage().contains("Invalid com.sun.management.jmxremote.port number")) { + if (!ex.getMessage().contains("NumberFormatException: For input string: \"apa\"")) { is checking for the correct message. This is fixed in jdk10 under bug JDK-8165736 [Error message should be shown when JVMTI agent cannot be attache] http://hg.openjdk.java.net/jdk/hs/rev/bc1cffa26561#l10.1 Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8195088 webrev link: http://cr.openjdk.java.net/~shshahma/8195088/webrev.00/ Regards, Shafi From hohensee at amazon.com Mon Jan 29 16:27:25 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 29 Jan 2018 16:27:25 +0000 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> Message-ID: <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> A name change would affect Amazon?s heap monitoring, and thus I expect it would affect other users as well. As long as there are gc-specific memory pools, we?re going to need to be able to identify them, and right now that?s done via name. All the mxbeans are identified by name, so that?s a general design principle. The only way I can think of to get rid of name dependency would be to figure out what abstract metrics users want to monitor and implement them for all collectors. HeapUsage (instantaneous occupancy) is one, CollectionUsage (long-lived occupancy) is another, both of these for the entire heap, not just particular memory pools. That said, imo there will always be a demand for the ability to get collector and memory pool specific details, so I don?t see a way to get around providing named entities. Paul From: mandy chung Organization: Oracle Corporation Date: Friday, January 26, 2018 at 2:38 PM To: "Hohensee, Paul" , Erik Helin , David Holmes Cc: "serviceability-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" Subject: Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results On 1/25/18 1:04 PM, Hohensee, Paul wrote: > The JMX API spec doesn?t specify what the memory pool or garbage > collector names are, but the current names are de-facto part of the > API, so if we change the existing ones, imo a CSR should be filed. The names are implementation details but I can see how an application might be impacted if they depend on it. CSR approval is not strictly necessary while I think filing one to document the change would be good. Does the name change impact any application you know of? I'm trying to understand if any improvement to API is needed so that applications don't need to depend on the names. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Jan 29 18:35:20 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 29 Jan 2018 10:35:20 -0800 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> Message-ID: Thanks for the reply Paul.?? Try to understand a little more on the specific from gc-specific memory pool you depend on. On 1/29/18 8:27 AM, Hohensee, Paul wrote: > > A name change would affect Amazon?s heap monitoring, and thus I expect > it would affect other users as well. > > As long as there are gc-specific memory pools, we?re going to need to > be able to identify them, and right now that?s done via name. > MemoryPoolMXBean::getType returns "heap" memory type for GC-specific memory pools.? Are you using this method?? Do you use the name to build in specific characteristic of a memory pool (e.g. eden vs old gen)? > All the mxbeans are identified by name, so that?s a general design > principle. The only way I can think of to get rid of name dependency > would be to figure out what abstract metrics users want to monitor and > implement them for all collectors. HeapUsage (instantaneous occupancy) > is one, CollectionUsage (long-lived occupancy) is another, both of > these for the entire heap, not just particular memory pools. > The sum of HeapUsage and CollectionUsage of all heap memory pools was expected to give an incorrect approximation for the entire heap usage.? Are you seeing issue/bug with the sum result? Mandy > That said, imo there will always be a demand for the ability to get > collector and memory pool specific details, so I don?t see a way to > get around providing named entities. > > Paul > > *From: *mandy chung > *Organization: *Oracle Corporation > *Date: *Friday, January 26, 2018 at 2:38 PM > *To: *"Hohensee, Paul" , Erik Helin > , David Holmes > *Cc: *"serviceability-dev at openjdk.java.net" > , > "hotspot-gc-dev at openjdk.java.net" > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > On 1/25/18 1:04 PM, Hohensee, Paul wrote: > > > > The JMX API spec doesn?t specify what the memory pool or garbage > > collector names are, but the current names are de-facto part of the > > API, so if we change the existing ones, imo a CSR should be filed. > > The names are implementation details but I can see how an application > might be impacted if they depend on it.? CSR approval is not strictly > necessary while I think filing one to document the change would be > good. > > Does the name change impact any application you know of?? I'm trying to > understand if any improvement to API is needed so that applications > don't need to depend on the names. > > > Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Jan 29 18:52:06 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 29 Jan 2018 10:52:06 -0800 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> Message-ID: <997a766f-9f4b-f192-ae87-03f4c8d2666d@oracle.com> On 1/29/18 10:35 AM, mandy chung wrote: > Thanks for the reply Paul.?? Try to understand a little more on the > specific from gc-specific memory pool you depend on. > > On 1/29/18 8:27 AM, Hohensee, Paul wrote: >> >> A name change would affect Amazon?s heap monitoring, and thus I >> expect it would affect other users as well. >> >> As long as there are gc-specific memory pools, we?re going to need to >> be able to identify them, and right now that?s done via name. >> > > MemoryPoolMXBean::getType returns "heap" memory type for GC-specific > memory pools.? Are you using this method?? Do you use the name to > build in specific characteristic of a memory pool (e.g. eden vs old gen)? > > >> All the mxbeans are identified by name, so that?s a general design >> principle. The only way I can think of to get rid of name dependency >> would be to figure out what abstract metrics users want to monitor >> and implement them for all collectors. HeapUsage (instantaneous >> occupancy) is one, CollectionUsage (long-lived occupancy) is another, >> both of these for the entire heap, not just particular memory pools. >> > > The sum of HeapUsage and CollectionUsage of all heap memory pools was > expected to give an incorrect approximation for the entire heap > usage.? Are you seeing issue/bug with the sum result? > typo: s/an incorrect approximation/an approximation. Mandy > Mandy > >> That said, imo there will always be a demand for the ability to get >> collector and memory pool specific details, so I don?t see a way to >> get around providing named entities. >> >> Paul >> >> *From: *mandy chung >> *Organization: *Oracle Corporation >> *Date: *Friday, January 26, 2018 at 2:38 PM >> *To: *"Hohensee, Paul" , Erik Helin >> , David Holmes >> *Cc: *"serviceability-dev at openjdk.java.net" >> , >> "hotspot-gc-dev at openjdk.java.net" >> *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool >> CollectionUsage.used values don't reflect mixed GC results >> >> On 1/25/18 1:04 PM, Hohensee, Paul wrote: >> >> >> > The JMX API spec doesn?t specify what the memory pool or garbage > >> collector names are, but the current names are de-facto part of the > >> API, so if we change the existing ones, imo a CSR should be filed. >> >> The names are implementation details but I can see how an application >> might be impacted if they depend on it.? CSR approval is not strictly >> necessary while I think filing one to document the change would be >> good. >> >> Does the name change impact any application you know of?? I'm trying to >> understand if any improvement to API is needed so that applications >> don't need to depend on the names. >> >> >> Mandy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jan 29 21:00:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jan 2018 07:00:40 +1000 Subject: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <1efaeb12-720c-e93e-6010-38b3687d3bf9@gmail.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> <122a2fbf-6c0d-6209-28b4-0b03064b65ab@gmail.com> <1efaeb12-720c-e93e-6010-38b3687d3bf9@gmail.com> Message-ID: <03152805-7b8b-b107-cb99-0d2b53c0dabc@oracle.com> Added in hotspot-gc-dev. Although this is in the SA it is about the SA interaction with G1 and so likely needs someone familiar with G1 to review it. David On 28/01/2018 10:41 PM, Yasumasa Suenaga wrote: > PING: Could you review it? > >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ > > This webrev has been reviewed by Jini. > I need a Reviewer and sponsor. > > > Yasumasa > > > On 2018/01/22 19:53, Yasumasa Suenaga wrote: >> Hi Jini, >> >> Thank you for your review! >> I will update the copyright year in this changeset. >> >> I'm waiting for Reviewer and sponsor. >> >> >> Yasumasa >> >> >> On 2018/01/22 13:14, Jini George wrote: >>> Hi Yasumasa, >>> >>> The changes look good to me. Please do update the copyright year to >>> 2018. >>> >>> Thanks! >>> Jini (Not a Reviewer). >>> >>> >>> >>> On 12/31/2017 10:03 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> >>>>> How did you submit to mach5 ??? >>>> >>>> I'm using Submit Repo for testing: >>>> ?? https://wiki.openjdk.java.net/display/Build/Submit+Repo >>>> >>>> >>>>> Anyway the failure is with: >>>> >>>> Thanks! >>>> I've fixed them in new webrev: >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ >>>> >>>> This webrev has passed Mach 5 tier 1 tests in Submit Repo: >>>> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171231-0202-8291 >>>> >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/12/30 10:31, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> Not a review ... >>>>> >>>>> On 29/12/2017 11:16 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> G1HeapRegionTable#getByAddress() returns incorrect HeapRegion >>>>>> which contains incorrect address. We can see it in Stack Memory >>>>>> window on HSDB. Some oop addresses are shown as Free Region >>>>>> (attached image). >>>>>> >>>>>> G1HeapRegion#getByAddress() should create HeapRegion instance from >>>>>> the address in _biased_base array. >>>>>> >>>>>> I uploaded webrev. Could you review it? >>>>>> >>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ >>>>>> >>>>>> I've tested this change with test/hotspot/jtreg/serviceability/sa, >>>>>> it works fine. >>>>>> But I received some failure from Mach 5. I also tested this change >>>>>> via submit repos. >>>>>> >>>>>> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 >>>>>> >>>>>> >>>>>> I cannot access this URL. Could you share the result? >>>>> >>>>> How did you submit to mach5 ??? >>>>> >>>>> Anyway the failure is with: >>>>> >>>>> test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java >>>>> >>>>> On linux and OS X: >>>>> >>>>> ??stderr: [Exception in thread "main" java.lang.NullPointerException >>>>> ?????at >>>>> TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >>>>> >>>>> ?????at >>>>> jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >>>>> >>>>> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >>>>> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >>>>> >>>>> On Solaris sparcv9: >>>>> >>>>> ??stderr: [Exception in thread "main" java.lang.RuntimeException: >>>>> Address of HeapRegion does not match.: expected 0x00000007afb00000 >>>>> to equal 0x00000007afc00000 >>>>> ?????at jdk.test.lib.Asserts.fail(Asserts.java:594) >>>>> ?????at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >>>>> ?????at >>>>> TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) >>>>> >>>>> ?????at >>>>> jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) >>>>> >>>>> ?????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) >>>>> ?????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) >>>>> ] >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Also I cannot access JPRT. So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa From hohensee at amazon.com Mon Jan 29 21:02:36 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 29 Jan 2018 21:02:36 +0000 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <997a766f-9f4b-f192-ae87-03f4c8d2666d@oracle.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> <997a766f-9f4b-f192-ae87-03f4c8d2666d@oracle.com> Message-ID: We don?t use getType, and you guessed correctly: we use the memory pool name as an indicator of the specific characteristics of a memory pool, in particular eden. What we want is an indication of long term heap occupancy. We calculate it using CollectionUsage for non-eden heap memory pools, regardless of collector. We don?t use JMX notification, rather we periodically poll CollectionUsage for memory pools with names that contain ?Old?, ?Tenured?, or ?Survivor?. We get the memory pools from the GarbageCollectorMXBeans (we don?t care what the collector names are). For the named memory pools, we sum CollectionUsage.used and divide by the sum of CollectionUsage.max to get a long term heap occupancy percentage. We don?t want to include eden because it?s really just an allocation buffer and not part of the storage for long-lived objects. I suppose we could use a negative test instead by using all memory pools with names that don?t include ?Eden?. The bug is that the ?G1 Old Gen? memory pool isn?t being updated when the ?G1 Young Generation? collector runs a mixed collection. As far as JMX is concerned, that collector only knows about eden and the survivor space. The patch adds the old gen to the memory pools it knows about and has mixed collections update the old gen?s CollectionUsage. I managed to get a submit repo run to succeed last week and it found a problem. I?ve uploaded a new webrev that fixes the failure of the jtreg test TestMemoryMXBeansAndPoolsPresence.java due to the young gen collector being expected to know only about eden and the survivor space. http://cr.openjdk.java.net/~phh/8195115/webrev.hs.01/ Waiting on the submit repo to come back with a result on it. Thanks, Paul From: mandy chung Organization: Oracle Corporation Date: Monday, January 29, 2018 at 10:52 AM To: "Hohensee, Paul" , Erik Helin , David Holmes Cc: "serviceability-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" Subject: Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results On 1/29/18 10:35 AM, mandy chung wrote: Thanks for the reply Paul. Try to understand a little more on the specific from gc-specific memory pool you depend on. On 1/29/18 8:27 AM, Hohensee, Paul wrote: A name change would affect Amazon?s heap monitoring, and thus I expect it would affect other users as well. As long as there are gc-specific memory pools, we?re going to need to be able to identify them, and right now that?s done via name. MemoryPoolMXBean::getType returns "heap" memory type for GC-specific memory pools. Are you using this method? Do you use the name to build in specific characteristic of a memory pool (e.g. eden vs old gen)? All the mxbeans are identified by name, so that?s a general design principle. The only way I can think of to get rid of name dependency would be to figure out what abstract metrics users want to monitor and implement them for all collectors. HeapUsage (instantaneous occupancy) is one, CollectionUsage (long-lived occupancy) is another, both of these for the entire heap, not just particular memory pools. The sum of HeapUsage and CollectionUsage of all heap memory pools was expected to give an incorrect approximation for the entire heap usage. Are you seeing issue/bug with the sum result? typo: s/an incorrect approximation/an approximation. Mandy Mandy That said, imo there will always be a demand for the ability to get collector and memory pool specific details, so I don?t see a way to get around providing named entities. Paul From: mandy chung Organization: Oracle Corporation Date: Friday, January 26, 2018 at 2:38 PM To: "Hohensee, Paul" , Erik Helin , David Holmes Cc: "serviceability-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" Subject: Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results On 1/25/18 1:04 PM, Hohensee, Paul wrote: > The JMX API spec doesn?t specify what the memory pool or garbage > collector names are, but the current names are de-facto part of the > API, so if we change the existing ones, imo a CSR should be filed. The names are implementation details but I can see how an application might be impacted if they depend on it. CSR approval is not strictly necessary while I think filing one to document the change would be good. Does the name change impact any application you know of? I'm trying to understand if any improvement to API is needed so that applications don't need to depend on the names. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jan 29 21:03:52 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jan 2018 07:03:52 +1000 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> Message-ID: <4add2e5b-cae9-7b3c-cb1c-277a8490a732@oracle.com> On the CSR question, yes this would need a CSR just to ensure the compatibility issues have been covered. David On 25/01/2018 11:20 PM, Erik Helin wrote: > Hi Paul, > > thanks for your interest in this area and for your patch! The > GarbageCollectorMXBean and MemoryPoolMXBean support for G1 is in need of > some updates, so thanks for working on this. > > Looking at your patch, I'm not sure that this is the direction we want > to go in. I discussed this a bit with Thomas and Stefan J, and our > current line of thinking is the following: > > - Memory pools (MemoryMXBean): > ? - "G1 Eden Regions" > ? - "G1 Survivor Regions" > ? - "G1 Old Regions" > ? - "G1 Humongous Regions" > ? - "G1 Archive Regions" (if CDS and/or AppCDS is used) > > `init` for these pools would be 0, `used` would be total size of the > "live" objects in the used regions of that type, `committed` the total > size of the used regions of that that type and `max` would be > MaxHeapSize. Note that "live" here means live from the GCs point of > view, i.e. an object might be dead in an old region but the GC will > consider that object live until a concurrent cycle has marked through > the heap and deemed it dead. > > - Collectors (GarbageCollectorMXBean): > ? - "G1 Young Collector" with the pools > ??? - "G1 Eden Regions" > ??? - "G1 Survivor Regions" > ??? - "G1 Humongous Regions" (due to early reclamation) > ? - "G1 Mixed Collector" with the pools > ??? - "G1 Eden Regions" > ??? - "G1 Survivor Regions" > ??? - "G1 Old Regions" > ??? - "G1 Humongous Regions" (due to early reclamation) > ? - "G1 Full Collector" with the pools > ??? - "G1 Eden Regions" > ??? - "G1 Survivor Regions" > ??? - "G1 Old Regions" > ??? - "G1 Humongous Regions" (can collect empty humongous regions) > ? - "G1 Concurrent Cycle" with the pools > ??? - "G1 Old Regions" (can collect empty old regions) > ??? - "G1 Humongous Regions" (can collect empty humongous regions) > > Note that with this design, the > GarbageCollectorMXBean::getCollectionTime() method for "G1 Concurrent > Cycle" would be the wall clock time from start of the first initial mark > to end of the last cleanup (also including the time of any eventual > young collection during the concurrent cycle). So > GarbageCollectorMXBean::getCollectionTime() would be a mix of concurrent > and STW time for the GarbageCollectorMXBean with name "G1 Concurrent > Cycle". > > Also note that the MemoryPoolMXBean with name "G1 Archive Regions" will > not be attached to any GarbageCollectorMXBean, since those regions will > never be collected. > > What do you think about this design, would it work for your use case? > > If we want to go ahead with this design, then I think we might have to > file a CSR. David (who is the HotSpot CSR representative), do we have to > file a CSR for changing the names of MemoryPoolMXBeans and > GarbageCollectorMXBeans? > > Thanks, > Erik > > On 01/20/2018 12:40 AM, Hohensee, Paul wrote: >> I?d appreciate a review please. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 >> >> Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.00/ >> >> The bug is that from the JMX point of view, G1?s incremental collector >> (misnamed as the ?G1 Young Generation? collector) only affects G1?s >> survivor and eden spaces. In fact, mixed collections run by this >> collector also affect the G1 old generation. >> >> This proposed fix is to record, for each of a JMX garbage collector's >> memory pools, whether that memory pool is affected by all collections >> using that collector. And, for each collection, record whether or not >> all the collector's memory pools are affected. After each collection, >> for each memory pool, if either all the collector's memory pools were >> affected or the memory pool is affected for all collections, record >> CollectionUsage for that pool. >> >> For collectors other than G1 Young Generation, all pools are recorded >> as affected by all collections and every collection is recorded as >> affecting all the collector?s memory pools. For the G1 Young >> Generation collector, the G1 Old Gen pool is recorded as not being >> affected by all collections, and non-mixed collections are recorded as >> not affecting all memory pools. The result is that for non-mixed >> collections, CollectionUsage is recorded after a collection only the >> G1 Eden Space and G1 Survivor Space pools, while for mixed collections >> CollectionUsage is recorded for G1 Old Gen as well. >> >> Other than the effect of the fix on G1 Old Gen MemoryPool. >> CollectionUsage, the only external behavior change is that >> GarbageCollectorMXBean.getMemoryPoolNames will now return 3 pool names >> rather than 2. >> >> With this fix, a collector?s memory pools can be divided into two >> disjoint subsets, one that participates in all collections and one >> that doesn?t. This is a bit more general than the minimum necessary to >> fix G1, but not by much. Because I expect it to apply to other >> incremental region-based collectors, I went with the more general >> solution. I minimized the amount of code I had to touch by using >> default parameters for GCMemoryManager::add_pool and the >> TraceMemoryManagerStats constructors. >> >> Tested by running the new jtreg test included in the webrev. I tried >> to use the submit repo, but it was out of order earlier today, so I?d >> be much obliged if someone could run it through mach5 and sponsor an >> eventual push. I successfully ran a JDK8 version of the patch through >> all the JDK8 jtreg tests as well as the JDK8 TCK. >> >> Thanks, >> >> Paul >> From mandy.chung at oracle.com Mon Jan 29 21:40:41 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 29 Jan 2018 13:40:41 -0800 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> <997a766f-9f4b-f192-ae87-03f4c8d2666d@oracle.com> Message-ID: <64793ff3-4805-79f9-4e72-6e469cd511dc@oracle.com> I created? JDK-8196362 to look into whether it makes sense to provide some categorization to differentiate eden space vs the heap space for long-lived objects. W.r.t. to JDK-8195115, I have to defer to GC team to comment on the mixed collection update.? If they are okay, I have no objection to implement a short-term fix and do the proper G1 memory pools as a separate patch. Mandy On 1/29/18 1:02 PM, Hohensee, Paul wrote: > > We don?t use getType, and you guessed correctly: we use the memory > pool name as an indicator of the specific characteristics of a memory > pool, in particular eden. > > What we want is an indication of long term heap occupancy. We > calculate it using CollectionUsage for non-eden heap memory pools, > regardless of collector. We don?t use JMX notification, rather we > periodically poll CollectionUsage for memory pools with names that > contain ?Old?, ?Tenured?, or ?Survivor?. We get the memory pools from > the GarbageCollectorMXBeans (we don?t care what the collector names > are). For the named memory pools, we sum CollectionUsage.used and > divide by the sum of CollectionUsage.max to get a long term heap > occupancy percentage. We don?t want to include eden because it?s > really just an allocation buffer and not part of the storage for > long-lived objects. I suppose we could use a negative test instead by > using all memory pools with names that don?t include ?Eden?. > > The bug is that the ?G1 Old Gen? memory pool isn?t being updated when > the ?G1 Young Generation? collector runs a mixed collection. As far as > JMX is concerned, that collector only knows about eden and the > survivor space. The patch adds the old gen to the memory pools it > knows about and has mixed collections update the old gen?s > CollectionUsage. > > I managed to get a submit repo run to succeed last week and it found a > problem. I?ve uploaded a new webrev that fixes the failure of the > jtreg test TestMemoryMXBeansAndPoolsPresence.java due to the young gen > collector being expected to know only about eden and the survivor space. > > http://cr.openjdk.java.net/~phh/8195115/webrev.hs.01/ > > > Waiting on the submit repo to come back with a result on it. > > Thanks, > > Paul > > *From: *mandy chung > *Organization: *Oracle Corporation > *Date: *Monday, January 29, 2018 at 10:52 AM > *To: *"Hohensee, Paul" , Erik Helin > , David Holmes > *Cc: *"serviceability-dev at openjdk.java.net" > , > "hotspot-gc-dev at openjdk.java.net" > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > On 1/29/18 10:35 AM, mandy chung wrote: > > Thanks for the reply Paul.?? Try to understand a little more on > the specific from gc-specific memory pool you depend on. > > On 1/29/18 8:27 AM, Hohensee, Paul wrote: > > A name change would affect Amazon?s heap monitoring, and thus > I expect it would affect other users as well. > > As long as there are gc-specific memory pools, we?re going to > need to be able to identify them, and right now that?s done > via name. > > > MemoryPoolMXBean::getType returns "heap" memory type for > GC-specific memory pools.? Are you using this method?? Do you use > the name to build in specific characteristic of a memory pool > (e.g. eden vs old gen)? > > > > All the mxbeans are identified by name, so that?s a general > design principle. The only way I can think of to get rid of > name dependency would be to figure out what abstract metrics > users want to monitor and implement them for all collectors. > HeapUsage (instantaneous occupancy) is one, CollectionUsage > (long-lived occupancy) is another, both of these for the > entire heap, not just particular memory pools. > > > The sum of HeapUsage and CollectionUsage of all heap memory pools > was expected to give an incorrect approximation for the entire > heap usage.? Are you seeing issue/bug with the sum result? > > > typo: s/an incorrect approximation/an approximation. > > Mandy > > > Mandy > > > That said, imo there will always be a demand for the ability > to get collector and memory pool specific details, so I don?t > see a way to get around providing named entities. > > Paul > > *From: *mandy chung > > *Organization: *Oracle Corporation > *Date: *Friday, January 26, 2018 at 2:38 PM > *To: *"Hohensee, Paul" > , Erik Helin > , David > Holmes > *Cc: *"serviceability-dev at openjdk.java.net" > > > , > "hotspot-gc-dev at openjdk.java.net" > > > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > On 1/25/18 1:04 PM, Hohensee, Paul wrote: > > > > The JMX API spec doesn?t specify what the memory pool or > garbage > collector names are, but the current names are > de-facto part of the > API, so if we change the existing ones, > imo a CSR should be filed. > > The names are implementation details but I can see how an application > > might be impacted if they depend on it.? CSR approval is not strictly > > necessary while I think filing one to document the change would be > > good. > > Does the name change impact any application you know of?? I'm trying to > > understand if any improvement to API is needed so that applications > > don't need to depend on the names. > > > Mandy > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jan 29 22:05:44 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jan 2018 08:05:44 +1000 Subject: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java In-Reply-To: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> References: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> Message-ID: <44a71e46-3da2-53c6-7e6b-82658183ae8c@oracle.com> Hi Daniel, Serviceability issues should go to serviceability-dev at openjdk.java.net - now cc'd. On 30/01/2018 7:53 AM, stewartd.qdt wrote: > Please review this webrev [1] which attempts to fix a test error in serviceability/sa/ClhsdbInspect.java when it is run under an AArch64 system (not necessarily exclusive to this system, but it was the system under test). The bug report [2] provides further details. Essentially the line "waiting to re-lock in wait" never actually occurs. Instead I have the line "waiting to lock" which occurs for the referenced item of /java/lang/ref/ReferenceQueue$Lock. Unfortunately the test is written such that only the first "waiting to lock" occurrence is seen (for java/lang/Class), which is already accounted for in the test. I can't tell exactly what the test expects, or why, but it would be extremely hard to arrange for "waiting to re-lock in wait" to be seen for the ReferenceQueue lock! That requires acquiring the lock yourself, issuing a notify() to unblock the wait(), and then issuing the jstack command while still holding the lock! David ----- > I'm not overly happy with this approach as it actually removes a test line. However, the test line does not actually appear in the output (at least on my system) and the test is not currently written to look for the second occurrence of the line "waiting to lock". Perhaps the original author could chime in and provide further guidance as to the intention of the test. > > I am happy to modify the patch as necessary. > > Regards, > Daniel Stewart > > > [1] - http://cr.openjdk.java.net/~dstewart/8196361/webrev.00/ > [2] - https://bugs.openjdk.java.net/browse/JDK-8196361 > From kirk at kodewerk.com Mon Jan 29 22:09:21 2018 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 29 Jan 2018 23:09:21 +0100 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> Message-ID: <1C279B19-5B8A-4622-B6D7-B7CD36C1B0FC@kodewerk.com> > On Jan 29, 2018, at 5:27 PM, Hohensee, Paul wrote: > > A name change would affect Amazon?s heap monitoring, and thus I expect it would affect other users as well. I can name a number of tools that would be disrupted by this type of change. Additionally tooling would be complicated by the need to support both the old and new versions. The current names have been with us for years and they are well known, well documented and well understood. Given the level of disruption this change is likely to cause IMHO you?d need a very very good reason to want to make it. > > As long as there are gc-specific memory pools, we?re going to need to be able to identify them, and right now that?s done via name. All the mxbeans are identified by name, so that?s a general design principle. The only way I can think of to get rid of name dependency would be to figure out what abstract metrics users want to monitor and implement them for all collectors. HeapUsage (instantaneous occupancy) is one, CollectionUsage (long-lived occupancy) is another, both of these for the entire heap, not just particular memory pools. That said, imo there will always be a demand for the ability to get collector and memory pool specific details, so I don?t see a way to get around providing named entities. Agreed?tuning strategies are implementation dependent and sensitive to specific versions. One is always going to need to know this information. Kind regards, Kirk Pepperdine -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Tue Jan 30 02:07:32 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 30 Jan 2018 02:07:32 +0000 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <64793ff3-4805-79f9-4e72-6e469cd511dc@oracle.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> <997a766f-9f4b-f192-ae87-03f4c8d2666d@oracle.com> <64793ff3-4805-79f9-4e72-6e469cd511dc@oracle.com> Message-ID: That?s one reviewer who?s ok with a short term patch. Anyone else? And, any reviewers for said short term patch? :) Thanks, Paul From: mandy chung Organization: Oracle Corporation Date: Monday, January 29, 2018 at 1:41 PM To: "Hohensee, Paul" Cc: "serviceability-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" Subject: Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results I created JDK-8196362 to look into whether it makes sense to provide some categorization to differentiate eden space vs the heap space for long-lived objects. W.r.t. to JDK-8195115, I have to defer to GC team to comment on the mixed collection update. If they are okay, I have no objection to implement a short-term fix and do the proper G1 memory pools as a separate patch. Mandy On 1/29/18 1:02 PM, Hohensee, Paul wrote: We don?t use getType, and you guessed correctly: we use the memory pool name as an indicator of the specific characteristics of a memory pool, in particular eden. What we want is an indication of long term heap occupancy. We calculate it using CollectionUsage for non-eden heap memory pools, regardless of collector. We don?t use JMX notification, rather we periodically poll CollectionUsage for memory pools with names that contain ?Old?, ?Tenured?, or ?Survivor?. We get the memory pools from the GarbageCollectorMXBeans (we don?t care what the collector names are). For the named memory pools, we sum CollectionUsage.used and divide by the sum of CollectionUsage.max to get a long term heap occupancy percentage. We don?t want to include eden because it?s really just an allocation buffer and not part of the storage for long-lived objects. I suppose we could use a negative test instead by using all memory pools with names that don?t include ?Eden?. The bug is that the ?G1 Old Gen? memory pool isn?t being updated when the ?G1 Young Generation? collector runs a mixed collection. As far as JMX is concerned, that collector only knows about eden and the survivor space. The patch adds the old gen to the memory pools it knows about and has mixed collections update the old gen?s CollectionUsage. I managed to get a submit repo run to succeed last week and it found a problem. I?ve uploaded a new webrev that fixes the failure of the jtreg test TestMemoryMXBeansAndPoolsPresence.java due to the young gen collector being expected to know only about eden and the survivor space. http://cr.openjdk.java.net/~phh/8195115/webrev.hs.01/ Waiting on the submit repo to come back with a result on it. Thanks, Paul From: mandy chung Organization: Oracle Corporation Date: Monday, January 29, 2018 at 10:52 AM To: "Hohensee, Paul" , Erik Helin , David Holmes Cc: "serviceability-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" Subject: Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results On 1/29/18 10:35 AM, mandy chung wrote: Thanks for the reply Paul. Try to understand a little more on the specific from gc-specific memory pool you depend on. On 1/29/18 8:27 AM, Hohensee, Paul wrote: A name change would affect Amazon?s heap monitoring, and thus I expect it would affect other users as well. As long as there are gc-specific memory pools, we?re going to need to be able to identify them, and right now that?s done via name. MemoryPoolMXBean::getType returns "heap" memory type for GC-specific memory pools. Are you using this method? Do you use the name to build in specific characteristic of a memory pool (e.g. eden vs old gen)? All the mxbeans are identified by name, so that?s a general design principle. The only way I can think of to get rid of name dependency would be to figure out what abstract metrics users want to monitor and implement them for all collectors. HeapUsage (instantaneous occupancy) is one, CollectionUsage (long-lived occupancy) is another, both of these for the entire heap, not just particular memory pools. The sum of HeapUsage and CollectionUsage of all heap memory pools was expected to give an incorrect approximation for the entire heap usage. Are you seeing issue/bug with the sum result? typo: s/an incorrect approximation/an approximation. Mandy Mandy That said, imo there will always be a demand for the ability to get collector and memory pool specific details, so I don?t see a way to get around providing named entities. Paul From: mandy chung Organization: Oracle Corporation Date: Friday, January 26, 2018 at 2:38 PM To: "Hohensee, Paul" , Erik Helin , David Holmes Cc: "serviceability-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" Subject: Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results On 1/25/18 1:04 PM, Hohensee, Paul wrote: > The JMX API spec doesn?t specify what the memory pool or garbage > collector names are, but the current names are de-facto part of the > API, so if we change the existing ones, imo a CSR should be filed. The names are implementation details but I can see how an application might be impacted if they depend on it. CSR approval is not strictly necessary while I think filing one to document the change would be good. Does the name change impact any application you know of? I'm trying to understand if any improvement to API is needed so that applications don't need to depend on the names. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Jan 30 03:22:57 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 29 Jan 2018 19:22:57 -0800 Subject: JDK-8171119: Low-Overhead Heap Profiling In-Reply-To: References: Message-ID: Hi Robbin, So I did the changes to move most of the code into the AllocTracer and you can see it incrementally here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.04_05/ And the full webrev here: http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.05/ Now the issues I see here: - AllocTracer now does "things" instead of just having a send_*_event API, that is a change in concept for that class - Collectedheap still needs to call AllocTracer to see if it is to be sampled, I can't hide everything in it without a bigger refactor (want me to try?) - The ordering is now important: AllocTracer has to get called before tlab().fill - Otherwise the fact that the allocation has to get sampled will get lost when the tlab gets replaced If this still looks better to you or in a better direction, let me know. I can do the end part of it and add an event for a sample since now that is easy and makes sense to probably add such an event, and I can add a few more tests. Thanks! On Mon, Jan 29, 2018 at 1:29 AM, Robbin Ehn wrote: > Hi JC, thanks! > > I'm happy with current state, looks good! > > Truncated: > > On 01/27/2018 05:01 AM, JC Beyler wrote: >> >> This is strange but I'm assuming it is because we are not working on >> the same repo? >> >> I used: >> hg clone http://hg.openjdk.java.net/jdk/hs jdkhs-heap >> >> I'll try a new clone on Monday and see. My new version moved hard_end >> back to public so it should work now. > > > Sorry this compile error was in closed code. > Now the closed part compiles, thanks. > >> >> Fair enough, hopefully Thomas will chime in. Are you saying that this >> first version could go in and we can work on a refinement? Or are you >> saying I should work on this now at the same time and fix it before >> this V1 goes in? (Just so I know :)) > > > We may have to change this before integration, but for now keep it as is. > >> I'll look at this on Monday then! > > > Great! > > /Robbin > > >> >> Thanks for the reply and have a great weekend! >> Jc >> >>> >>>> >>>>> #### >>>>> Minor nit, when declaring pointer there is a little mix of having the >>>>> pointer adjacent by type name and data name. (Most hotspot code is by >>>>> type >>>>> name) >>>>> E.g. >>>>> heapMonitoring.cpp:711 jvmtiStackTrace *trace = .... >>>>> heapMonitoring.cpp:733 Method* m = vfst.method(); >>>>> (not just this file) >>>>> >>>> >>>> Done! >>>> >>>>> #### >>>>> HeapMonitorThreadOnOffTest.java:77 >>>>> I would make g_tmp volatile, otherwise the assignment in loop may >>>>> theoretical be skipped. >>>>> >>>> >>>> Also done! >>> >>> >>> >>> Looks good, thanks! >>> >>> /Robbin >>> >>>> >>>> Thanks again! >>>> Jc >>>> >>> > From robbin.ehn at oracle.com Tue Jan 30 09:40:34 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 30 Jan 2018 10:40:34 +0100 Subject: JDK-8171119: Low-Overhead Heap Profiling In-Reply-To: References: Message-ID: Hi JC, On 01/30/2018 04:22 AM, JC Beyler wrote: > - Collectedheap still needs to call AllocTracer to see if it is to be > sampled, I can't hide everything in it without a bigger refactor (want > me to try?) Yes we need a bigger refactor to do this nicely. I suggested not doing that now, so just rollback to the previously version. Thanks for having a look at it! /Robbin > > On Mon, Jan 29, 2018 at 1:29 AM, Robbin Ehn wrote: >> Hi JC, thanks! >> >> I'm happy with current state, looks good! >> >> Truncated: >> >> On 01/27/2018 05:01 AM, JC Beyler wrote: >>> >>> This is strange but I'm assuming it is because we are not working on >>> the same repo? >>> >>> I used: >>> hg clone http://hg.openjdk.java.net/jdk/hs jdkhs-heap >>> >>> I'll try a new clone on Monday and see. My new version moved hard_end >>> back to public so it should work now. >> >> >> Sorry this compile error was in closed code. >> Now the closed part compiles, thanks. >> >>> >>> Fair enough, hopefully Thomas will chime in. Are you saying that this >>> first version could go in and we can work on a refinement? Or are you >>> saying I should work on this now at the same time and fix it before >>> this V1 goes in? (Just so I know :)) >> >> >> We may have to change this before integration, but for now keep it as is. >> >>> I'll look at this on Monday then! >> >> >> Great! >> >> /Robbin >> >> >>> >>> Thanks for the reply and have a great weekend! >>> Jc >>> >>>> >>>>> >>>>>> #### >>>>>> Minor nit, when declaring pointer there is a little mix of having the >>>>>> pointer adjacent by type name and data name. (Most hotspot code is by >>>>>> type >>>>>> name) >>>>>> E.g. >>>>>> heapMonitoring.cpp:711 jvmtiStackTrace *trace = .... >>>>>> heapMonitoring.cpp:733 Method* m = vfst.method(); >>>>>> (not just this file) >>>>>> >>>>> >>>>> Done! >>>>> >>>>>> #### >>>>>> HeapMonitorThreadOnOffTest.java:77 >>>>>> I would make g_tmp volatile, otherwise the assignment in loop may >>>>>> theoretical be skipped. >>>>>> >>>>> >>>>> Also done! >>>> >>>> >>>> >>>> Looks good, thanks! >>>> >>>> /Robbin >>>> >>>>> >>>>> Thanks again! >>>>> Jc >>>>> >>>> >> From thomas.schatzl at oracle.com Tue Jan 30 10:06:14 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Jan 2018 11:06:14 +0100 Subject: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <03152805-7b8b-b107-cb99-0d2b53c0dabc@oracle.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> <122a2fbf-6c0d-6209-28b4-0b03064b65ab@gmail.com> <1efaeb12-720c-e93e-6010-38b3687d3bf9@gmail.com> <03152805-7b8b-b107-cb99-0d2b53c0dabc@oracle.com> Message-ID: <1517306774.2832.6.camel@oracle.com> Hi, On Tue, 2018-01-30 at 07:00 +1000, David Holmes wrote: > Added in hotspot-gc-dev. Although this is in the SA it is about the > SA interaction with G1 and so likely needs someone familiar with G1 > to review it. > > David > > On 28/01/2018 10:41 PM, Yasumasa Suenaga wrote: > > PING: Could you review it? > > > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ > > > > This webrev has been reviewed by Jini. > > I need a Reviewer and sponsor. looks good to me - however there is another (pre-existing) bug: the shift in that code should be a logical shift, not an arithmetic shift. I.e. ">>" instead of ">>>". I will run the patch through testing and report back in a few hours. Should be okay. Thanks, Thomas From jini.george at oracle.com Tue Jan 30 11:57:36 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 30 Jan 2018 17:27:36 +0530 Subject: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java In-Reply-To: <44a71e46-3da2-53c6-7e6b-82658183ae8c@oracle.com> References: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> <44a71e46-3da2-53c6-7e6b-82658183ae8c@oracle.com> Message-ID: <3318aed7-f04a-3b92-2660-39cdf13c2d24@oracle.com> Hi Daniel, David, Thanks, Daniel, for bringing this up. The intent of the test is to get the oop address corresponding to a java.lang.ref.ReferenceQueue$Lock, which can typically be obtained from the stack traces of the Common-Cleaner or the Finalizer threads. The stack traces which I had been noticing were typically of the form: "Common-Cleaner" #8 daemon prio=8 tid=0x00007f09c82ac000 nid=0xf6e in Object.wait() [0x00007f09a18d2000] java.lang.Thread.State: TIMED_WAITING (on object monitor) JavaThread state: _thread_blocked - java.lang.Object.wait(long) @bci=0, pc=0x00007f09b7d6480b, Method*=0x00007f09acc43d60 (Interpreted frame) - waiting on <0x000000072e61f6e0> (a java.lang.ref.ReferenceQueue$Lock) - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=151, pc=0x00007f09b7d55243, Method*=0x00007f09acdab9b0 (Interpreted frame) - waiting to re-lock in wait() <0x000000072e61f6e0> (a java.lang.ref.ReferenceQueue$Lock) ... I chose 'waiting to re-lock in wait' since that was what I had been observing next to the oop address of java.lang.ref.ReferenceQueue$Lock. But I see how with a timing difference, one could get 'waiting to lock' as in your case. So, a good way to fix might be to check for the line containing '(a java.lang.ref.ReferenceQueue$Lock)', getting the oop address from that line (should be the address appearing immediately before '(a java.lang.ref.ReferenceQueue$Lock)') and passing that to the 'inspect' command. Thanks much, Jini. On 1/30/2018 3:35 AM, David Holmes wrote: > Hi Daniel, > > Serviceability issues should go to serviceability-dev at openjdk.java.net - > now cc'd. > > On 30/01/2018 7:53 AM, stewartd.qdt wrote: >> Please review this webrev [1] which attempts to fix a test error in >> serviceability/sa/ClhsdbInspect.java when it is run under an AArch64 >> system (not necessarily exclusive to this system, but it was the >> system under test). The bug report [2] provides further details. >> Essentially the line "waiting to re-lock in wait" never actually >> occurs. Instead I have the line "waiting to lock" which occurs for the >> referenced item of /java/lang/ref/ReferenceQueue$Lock. Unfortunately >> the test is written such that only the first "waiting to lock" >> occurrence is seen (for java/lang/Class), which is already accounted >> for in the test. > > I can't tell exactly what the test expects, or why, but it would be > extremely hard to arrange for "waiting to re-lock in wait" to be seen > for the ReferenceQueue lock! That requires acquiring the lock yourself, > issuing a notify() to unblock the wait(), and then issuing the jstack > command while still holding the lock! > > David > ----- > >> I'm not overly happy with this approach as it actually removes a test >> line. However, the test line does not actually appear in the output >> (at least on my system) and the test is not currently written to look >> for the second occurrence of the line "waiting to lock". Perhaps the >> original author could chime in and provide further guidance as to the >> intention of the test. >> >> I am happy to modify the patch as necessary. >> >> Regards, >> Daniel Stewart >> >> >> [1] -? http://cr.openjdk.java.net/~dstewart/8196361/webrev.00/ >> [2] - https://bugs.openjdk.java.net/browse/JDK-8196361 >> From erik.helin at oracle.com Tue Jan 30 13:50:03 2018 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 30 Jan 2018 14:50:03 +0100 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> <997a766f-9f4b-f192-ae87-03f4c8d2666d@oracle.com> <64793ff3-4805-79f9-4e72-6e469cd511dc@oracle.com> Message-ID: <15754d34-f3c7-6431-7abf-05214bd6b9d2@oracle.com> On 01/30/2018 03:07 AM, Hohensee, Paul wrote: > That?s one reviewer who?s ok with a short term patch. Anyone else? And, > any reviewers for said short term patch? :) Well, the patch is not really complete as it is. The problem is the definitions of the MemoryPoolMXBeans and GarbageCollectorMXBeans, which, as I tried to hint at in my first email, is a mess for G1. The names and implementations of these MemoryPoolMXBeans and GarbageCollectionMXBeans for G1 are very old, G1 has changed a lot since those were implemented (hence my suggestion for finally fixing this). The issue with your patch is that the MemoryPoolMXBean named "G1 Old Gen" consists of both old and humongous regions (it will also include archive regions). Old regions can be collected by mixed, concurrent and full collections. Humongous regions can be collected by young, mixed or full collections and the concurrent cycle. Archive regions will never be collected. Your patch will update the pool in the case of a mixed collection collecting old regions or humongous regions, but misses the following cases: - a young collection collecting humongous regions - a concurrent cycle collecting humongous regions - a concurrent cycle collecting old regions Unfortunately I could not come up with a good way to solve the above without re-designing the pools. I'm not sure about accepting your patch as is, since it might cause even more confusion for users compared to the current (already confusing) situation. One idea we have discussed is to implement the re-design but also add a flag, -XX:+UseG1LegacyPoolsAndBeans (false by default), to allow for a smoother transition. Would that solution work for you? Thanks, Erik > Thanks, > > Paul > > *From: *mandy chung > *Organization: *Oracle Corporation > *Date: *Monday, January 29, 2018 at 1:41 PM > *To: *"Hohensee, Paul" > *Cc: *"serviceability-dev at openjdk.java.net" > , "hotspot-gc-dev at openjdk.java.net" > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > I created? JDK-8196362 to look into whether it makes sense to provide > some categorization to differentiate eden space vs the heap space for > long-lived objects. > > W.r.t. to JDK-8195115, I have to defer to GC team to comment on the > mixed collection update.? If they are okay, I have no objection to > implement a short-term fix and do the proper G1 memory pools as a > separate patch. > > Mandy > > On 1/29/18 1:02 PM, Hohensee, Paul wrote: > > We don?t use getType, and you guessed correctly: we use the memory > pool name as an indicator of the specific characteristics of a > memory pool, in particular eden. > > What we want is an indication of long term heap occupancy. We > calculate it using CollectionUsage for non-eden heap memory pools, > regardless of collector. We don?t use JMX notification, rather we > periodically poll CollectionUsage for memory pools with names that > contain ?Old?, ?Tenured?, or ?Survivor?. We get the memory pools > from the GarbageCollectorMXBeans (we don?t care what the collector > names are). For the named memory pools, we sum CollectionUsage.used > and divide by the sum of CollectionUsage.max to get a long term heap > occupancy percentage. We don?t want to include eden because it?s > really just an allocation buffer and not part of the storage for > long-lived objects. I suppose we could use a negative test instead > by using all memory pools with names that don?t include ?Eden?. > > The bug is that the ?G1 Old Gen? memory pool isn?t being updated > when the ?G1 Young Generation? collector runs a mixed collection. As > far as JMX is concerned, that collector only knows about eden and > the survivor space. The patch adds the old gen to the memory pools > it knows about and has mixed collections update the old gen?s > CollectionUsage. > > I managed to get a submit repo run to succeed last week and it found > a problem. I?ve uploaded a new webrev that fixes the failure of the > jtreg test TestMemoryMXBeansAndPoolsPresence.java due to the young > gen collector being expected to know only about eden and the > survivor space. > > http://cr.openjdk.java.net/~phh/8195115/webrev.hs.01/ > > > Waiting on the submit repo to come back with a result on it. > > Thanks, > > Paul > > *From: *mandy chung > > *Organization: *Oracle Corporation > *Date: *Monday, January 29, 2018 at 10:52 AM > *To: *"Hohensee, Paul" > , Erik Helin > , David Holmes > > *Cc: *"serviceability-dev at openjdk.java.net" > > > , > "hotspot-gc-dev at openjdk.java.net" > > > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > On 1/29/18 10:35 AM, mandy chung wrote: > > Thanks for the reply Paul.?? Try to understand a little more on > the specific from gc-specific memory pool you depend on. > > On 1/29/18 8:27 AM, Hohensee, Paul wrote: > > A name change would affect Amazon?s heap monitoring, and > thus I expect it would affect other users as well. > > As long as there are gc-specific memory pools, we?re going > to need to be able to identify them, and right now that?s > done via name. > > > MemoryPoolMXBean::getType returns "heap" memory type for > GC-specific memory pools.? Are you using this method?? Do you > use the name to build in specific characteristic of a memory > pool (e.g. eden vs old gen)? > > > > > All the mxbeans are identified by name, so that?s a general > design principle. The only way I can think of to get rid of > name dependency would be to figure out what abstract metrics > users want to monitor and implement them for all collectors. > HeapUsage (instantaneous occupancy) is one, CollectionUsage > (long-lived occupancy) is another, both of these for the > entire heap, not just particular memory pools. > > > The sum of HeapUsage and CollectionUsage of all heap memory > pools was expected to give an incorrect approximation for the > entire heap usage.? Are you seeing issue/bug with the sum result? > > > typo: s/an incorrect approximation/an approximation. > > Mandy > > > > Mandy > > > > That said, imo there will always be a demand for the ability > to get collector and memory pool specific details, so I > don?t see a way to get around providing named entities. > > Paul > > *From: *mandy chung > > *Organization: *Oracle Corporation > *Date: *Friday, January 26, 2018 at 2:38 PM > *To: *"Hohensee, Paul" > , Erik Helin > , > David Holmes > > *Cc: *"serviceability-dev at openjdk.java.net" > > > , > "hotspot-gc-dev at openjdk.java.net" > > > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > On 1/25/18 1:04 PM, Hohensee, Paul wrote: > > > > The JMX API spec doesn?t specify what the memory pool or > garbage > collector names are, but the current names are > de-facto part of the > API, so if we change the existing > ones, imo a CSR should be filed. > > The names are implementation details but I can see how an application > > might be impacted if they depend on it.? CSR approval is not strictly > > necessary while I think filing one to document the change would be > > good. > > Does the name change impact any application you know of?? I'm trying to > > understand if any improvement to API is needed so that applications > > don't need to depend on the names. > > > Mandy > > > > > > > > From thomas.schatzl at oracle.com Tue Jan 30 15:51:50 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Jan 2018 16:51:50 +0100 Subject: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <1517306774.2832.6.camel@oracle.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> <122a2fbf-6c0d-6209-28b4-0b03064b65ab@gmail.com> <1efaeb12-720c-e93e-6010-38b3687d3bf9@gmail.com> <03152805-7b8b-b107-cb99-0d2b53c0dabc@oracle.com> <1517306774.2832.6.camel@oracle.com> Message-ID: <1517327510.2368.27.camel@oracle.com> Hi all, On Tue, 2018-01-30 at 11:06 +0100, Thomas Schatzl wrote: > Hi, > > On Tue, 2018-01-30 at 07:00 +1000, David Holmes wrote: > > Added in hotspot-gc-dev. Although this is in the SA it is about the > > SA interaction with G1 and so likely needs someone familiar with G1 > > to review it. > > > > David > > > > On 28/01/2018 10:41 PM, Yasumasa Suenaga wrote: > > > PING: Could you review it? > > > > > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ > > > > > > This webrev has been reviewed by Jini. > > > I need a Reviewer and sponsor. > > looks good to me - however there is another (pre-existing) bug: the > shift in that code should be a logical shift, not an arithmetic > shift. > > I.e. ">>" instead of ">>>". > > I will run the patch through testing and report back in a few hours. > Should be okay. is good. Do you want to fix the issue with the shift operator too here, or use another CR? Thanks, Thomas From yasuenag at gmail.com Wed Jan 31 00:49:52 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 31 Jan 2018 09:49:52 +0900 Subject: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <1517327510.2368.27.camel@oracle.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> <122a2fbf-6c0d-6209-28b4-0b03064b65ab@gmail.com> <1efaeb12-720c-e93e-6010-38b3687d3bf9@gmail.com> <03152805-7b8b-b107-cb99-0d2b53c0dabc@oracle.com> <1517306774.2832.6.camel@oracle.com> <1517327510.2368.27.camel@oracle.com> Message-ID: Hi Thomas, >> looks good to me - however there is another (pre-existing) bug: the >> shift in that code should be a logical shift, not an arithmetic >> shift. >> >> I.e. ">>" instead of ">>>". >> >> I will run the patch through testing and report back in a few hours. >> Should be okay. > > is good. Do you want to fix the issue with the shift operator too > here, or use another CR? Thanks! If the use of ">>>" is the bug, I want to fix it in new bug ticket. I do not think the use of ">>>" is not a bug. I g1BiasedArray.hpp, G1BiasedMappedArray::get_by_address() uses ">>" operator to calculate biased_index: http://hg.openjdk.java.net/jdk/hs/file/ee513596f3ee/src/hotspot/share/gc/g1/g1BiasedArray.hpp#l134 idx_t is defined as size_t. So it is calculated as unsigned value. In JLS 15.19, ">>>" is for unsigned. If we use ">>", it might remain MSB in some cases. https://docs.oracle.com/javase/specs/jls/se9/html/jls-15.html#jls-15.19 Thus I think this is not a bug. Thanks, Yasumasa 2018-01-31 0:51 GMT+09:00 Thomas Schatzl : > Hi all, > > On Tue, 2018-01-30 at 11:06 +0100, Thomas Schatzl wrote: >> Hi, >> >> On Tue, 2018-01-30 at 07:00 +1000, David Holmes wrote: >> > Added in hotspot-gc-dev. Although this is in the SA it is about the >> > SA interaction with G1 and so likely needs someone familiar with G1 >> > to review it. >> > >> > David >> > >> > On 28/01/2018 10:41 PM, Yasumasa Suenaga wrote: >> > > PING: Could you review it? >> > > >> > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ >> > > >> > > This webrev has been reviewed by Jini. >> > > I need a Reviewer and sponsor. >> >> looks good to me - however there is another (pre-existing) bug: the >> shift in that code should be a logical shift, not an arithmetic >> shift. >> >> I.e. ">>" instead of ">>>". >> >> I will run the patch through testing and report back in a few hours. >> Should be okay. > > is good. Do you want to fix the issue with the shift operator too > here, or use another CR? > > Thanks, > Thomas > From hohensee at amazon.com Wed Jan 31 01:30:59 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 31 Jan 2018 01:30:59 +0000 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <15754d34-f3c7-6431-7abf-05214bd6b9d2@oracle.com> References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> <997a766f-9f4b-f192-ae87-03f4c8d2666d@oracle.com> <64793ff3-4805-79f9-4e72-6e469cd511dc@oracle.com> <15754d34-f3c7-6431-7abf-05214bd6b9d2@oracle.com> Message-ID: It?s true that my patch doesn?t completely solve the larger problem, but it fixes the most immediately important part of it, particularly for JDK8 where current expected behavior is entrenched. If we?re going to fix the larger problem, imo we should file another bug/rfe to do it. I?d be happy to fix that one too, once we have a spec. What do you think of my suggestions? To summarize: - Keep the existing memory pools and add humongous and archive pools. - Make the archive pool part of the old gen, and generalize it to all collectors. - Split humongous regions off from the old gen pool into their own pool. The old gen and humongous pools are disjoint region sets. - Keep the existing ?G1 Young Generation? and ?G1 Old Generation? collectors and their associated memory pools (net of this patch). We add the humongous pool to them. - Add ?G1 Full? as an alias of the existing ?G1 Old Generation? collector. - Add the ?G1 Young?, ?G1 Mixed? and ?G1 Concurrent Cycle? collectors. - Set the G1 old gen memory pool max size to ?Xmx, the archive space max size to whatever it is, and the rest of the G1 memory pool max sizes to -1 == undefined, as now. The resulting memory pools: ?G1 Eden Space? ?G1 Survivor Space? ?G1 Old Gen? ?G1 Humongous Space? ?Archive Space? The resulting collectors and their memory pools: ?G1 Young Generation? (the existing young/mixed collector), ?G1 Old Generation?/?G1 Full?, ?G1 Mixed? - ?G1 Eden Space? - ?G1 Survivor Space? - ?G1 Old Gen? - ?G1 Humongous Space? ?G1 Young? - ?G1 Eden Space? - ?G1 Survivor Space? - ?G1 Humongous Space? ?G1 Concurrent Cycle? - ?G1 Old Gen? - ?G1 Humongous Space? I?m not religious about the names, but I like my suggestions. :) The significant addition to my previous email, and an incompatible change, is splitting humongous regions off from the old gen pool. This means that apps that specifically monitor old gen occupancy will no longer see humongous regions. Monitoring apps that just add up info about all a collector?s pools won?t see a difference. I may be corrected (by Kirk, perhaps), but imo it?s not as bad a compatibility issue as one might think, because the type of app that uses a lot of humongous regions isn?t all that common. E.g., apps that cache data in the heap in the form of large compressed arrays, and apps with large hashmap bucket list arrays. The heaps such apps use are very often large enough to use 32mb regions, hence need really big objects to actually allocate humongous regions. Thanks, Paul On 1/30/18, 5:51 AM, "Erik Helin" wrote: On 01/30/2018 03:07 AM, Hohensee, Paul wrote: > That?s one reviewer who?s ok with a short term patch. Anyone else? And, > any reviewers for said short term patch? :) Well, the patch is not really complete as it is. The problem is the definitions of the MemoryPoolMXBeans and GarbageCollectorMXBeans, which, as I tried to hint at in my first email, is a mess for G1. The names and implementations of these MemoryPoolMXBeans and GarbageCollectionMXBeans for G1 are very old, G1 has changed a lot since those were implemented (hence my suggestion for finally fixing this). The issue with your patch is that the MemoryPoolMXBean named "G1 Old Gen" consists of both old and humongous regions (it will also include archive regions). Old regions can be collected by mixed, concurrent and full collections. Humongous regions can be collected by young, mixed or full collections and the concurrent cycle. Archive regions will never be collected. Your patch will update the pool in the case of a mixed collection collecting old regions or humongous regions, but misses the following cases: - a young collection collecting humongous regions - a concurrent cycle collecting humongous regions - a concurrent cycle collecting old regions Unfortunately I could not come up with a good way to solve the above without re-designing the pools. I'm not sure about accepting your patch as is, since it might cause even more confusion for users compared to the current (already confusing) situation. One idea we have discussed is to implement the re-design but also add a flag, -XX:+UseG1LegacyPoolsAndBeans (false by default), to allow for a smoother transition. Would that solution work for you? Thanks, Erik > Thanks, > > Paul > > *From: *mandy chung > *Organization: *Oracle Corporation > *Date: *Monday, January 29, 2018 at 1:41 PM > *To: *"Hohensee, Paul" > *Cc: *"serviceability-dev at openjdk.java.net" > , "hotspot-gc-dev at openjdk.java.net" > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > I created JDK-8196362 to look into whether it makes sense to provide > some categorization to differentiate eden space vs the heap space for > long-lived objects. > > W.r.t. to JDK-8195115, I have to defer to GC team to comment on the > mixed collection update. If they are okay, I have no objection to > implement a short-term fix and do the proper G1 memory pools as a > separate patch. > > Mandy > > On 1/29/18 1:02 PM, Hohensee, Paul wrote: > > We don?t use getType, and you guessed correctly: we use the memory > pool name as an indicator of the specific characteristics of a > memory pool, in particular eden. > > What we want is an indication of long term heap occupancy. We > calculate it using CollectionUsage for non-eden heap memory pools, > regardless of collector. We don?t use JMX notification, rather we > periodically poll CollectionUsage for memory pools with names that > contain ?Old?, ?Tenured?, or ?Survivor?. We get the memory pools > from the GarbageCollectorMXBeans (we don?t care what the collector > names are). For the named memory pools, we sum CollectionUsage.used > and divide by the sum of CollectionUsage.max to get a long term heap > occupancy percentage. We don?t want to include eden because it?s > really just an allocation buffer and not part of the storage for > long-lived objects. I suppose we could use a negative test instead > by using all memory pools with names that don?t include ?Eden?. > > The bug is that the ?G1 Old Gen? memory pool isn?t being updated > when the ?G1 Young Generation? collector runs a mixed collection. As > far as JMX is concerned, that collector only knows about eden and > the survivor space. The patch adds the old gen to the memory pools > it knows about and has mixed collections update the old gen?s > CollectionUsage. > > I managed to get a submit repo run to succeed last week and it found > a problem. I?ve uploaded a new webrev that fixes the failure of the > jtreg test TestMemoryMXBeansAndPoolsPresence.java due to the young > gen collector being expected to know only about eden and the > survivor space. > > http://cr.openjdk.java.net/~phh/8195115/webrev.hs.01/ > > > Waiting on the submit repo to come back with a result on it. > > Thanks, > > Paul > > *From: *mandy chung > > *Organization: *Oracle Corporation > *Date: *Monday, January 29, 2018 at 10:52 AM > *To: *"Hohensee, Paul" > , Erik Helin > , David Holmes > > *Cc: *"serviceability-dev at openjdk.java.net" > > > , > "hotspot-gc-dev at openjdk.java.net" > > > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > On 1/29/18 10:35 AM, mandy chung wrote: > > Thanks for the reply Paul. Try to understand a little more on > the specific from gc-specific memory pool you depend on. > > On 1/29/18 8:27 AM, Hohensee, Paul wrote: > > A name change would affect Amazon?s heap monitoring, and > thus I expect it would affect other users as well. > > As long as there are gc-specific memory pools, we?re going > to need to be able to identify them, and right now that?s > done via name. > > > MemoryPoolMXBean::getType returns "heap" memory type for > GC-specific memory pools. Are you using this method? Do you > use the name to build in specific characteristic of a memory > pool (e.g. eden vs old gen)? > > > > > All the mxbeans are identified by name, so that?s a general > design principle. The only way I can think of to get rid of > name dependency would be to figure out what abstract metrics > users want to monitor and implement them for all collectors. > HeapUsage (instantaneous occupancy) is one, CollectionUsage > (long-lived occupancy) is another, both of these for the > entire heap, not just particular memory pools. > > > The sum of HeapUsage and CollectionUsage of all heap memory > pools was expected to give an incorrect approximation for the > entire heap usage. Are you seeing issue/bug with the sum result? > > > typo: s/an incorrect approximation/an approximation. > > Mandy > > > > Mandy > > > > That said, imo there will always be a demand for the ability > to get collector and memory pool specific details, so I > don?t see a way to get around providing named entities. > > Paul > > *From: *mandy chung > > *Organization: *Oracle Corporation > *Date: *Friday, January 26, 2018 at 2:38 PM > *To: *"Hohensee, Paul" > , Erik Helin > , > David Holmes > > *Cc: *"serviceability-dev at openjdk.java.net" > > > , > "hotspot-gc-dev at openjdk.java.net" > > > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > CollectionUsage.used values don't reflect mixed GC results > > On 1/25/18 1:04 PM, Hohensee, Paul wrote: > > > > The JMX API spec doesn?t specify what the memory pool or > garbage > collector names are, but the current names are > de-facto part of the > API, so if we change the existing > ones, imo a CSR should be filed. > > The names are implementation details but I can see how an application > > might be impacted if they depend on it. CSR approval is not strictly > > necessary while I think filing one to document the change would be > > good. > > Does the name change impact any application you know of? I'm trying to > > understand if any improvement to API is needed so that applications > > don't need to depend on the names. > > > Mandy > > > > > > > > From thomas.schatzl at oracle.com Wed Jan 31 08:57:12 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 31 Jan 2018 09:57:12 +0100 Subject: PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> <2bc3972c-837f-076e-60a3-a3b019761a97@oracle.com> <122a2fbf-6c0d-6209-28b4-0b03064b65ab@gmail.com> <1efaeb12-720c-e93e-6010-38b3687d3bf9@gmail.com> <03152805-7b8b-b107-cb99-0d2b53c0dabc@oracle.com> <1517306774.2832.6.camel@oracle.com> <1517327510.2368.27.camel@oracle.com> Message-ID: <1517389032.2352.2.camel@oracle.com> Hi, On Wed, 2018-01-31 at 09:49 +0900, Yasumasa Suenaga wrote: > Hi Thomas, > > > > looks good to me - however there is another (pre-existing) bug: > > > the > > > shift in that code should be a logical shift, not an arithmetic > > > shift. > > > > > > I.e. ">>" instead of ">>>". > > > > > > I will run the patch through testing and report back in a few > > > hours. > > > Should be okay. > > > > is good. Do you want to fix the issue with the shift operator too > > here, or use another CR? > > Thanks! > > If the use of ">>>" is the bug, I want to fix it in new bug ticket. > I do not think the use of ">>>" is not a bug. > > I g1BiasedArray.hpp, G1BiasedMappedArray::get_by_address() uses ">>" > operator to calculate biased_index: > http://hg.openjdk.java.net/jdk/hs/file/ee513596f3ee/src/hotspot/sha > re/gc/g1/g1BiasedArray.hpp#l134 > > idx_t is defined as size_t. So it is calculated as unsigned value. > In JLS 15.19, ">>>" is for unsigned. If we use ">>", it might remain > MSB in some cases. > https://docs.oracle.com/javase/specs/jls/se9/html/jls-15.html#jls-1 > 5.19 > > Thus I think this is not a bug. You are right, I mixed them up. I will push the change then, with jgeorge and me as reviewers. Thomas From leo.korinth at oracle.com Wed Jan 31 10:00:15 2018 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 31 Jan 2018 11:00:15 +0100 Subject: RFR: 8196337 Add commit methods that take all event properties as argument Message-ID: <6c57498a-d0cc-e7bd-c54d-bfd4b2acf323@oracle.com> Hi, I am adding commit methods that take all event properties as argument. For instant events (without start and stop times) a static commit method is created (taking all properties). For non-instant events, a non static commit method is created (taking all properties). Also a static commit method (with additional startTicks/endTicks) is created. Also an extra constructor is created (taking all properties). An auto commit destructor was considered (that would auto commit if the constructor with all properties was used) but has not yet been implemented. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8196337 Webrev: http://cr.openjdk.java.net/~lkorinth/8196337/00/ (open) Testing: - hs-tier1, hs-tier2 Thanks, Leo From erik.helin at oracle.com Wed Jan 31 11:40:46 2018 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 31 Jan 2018 12:40:46 +0100 Subject: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: References: <3A67BF1B-CE35-4759-B5B4-959C24020A45@amazon.com> <22ceea57-7d27-8350-4457-21f765cb3d0f@oracle.com> <878D6678-84CB-471E-B126-AF14B1BC8EB9@amazon.com> <727f9bcb-9404-df32-917f-70aca6e31cb6@oracle.com> <4BA32239-D645-4B1A-A58E-502258C8FFB7@amazon.com> <997a766f-9f4b-f192-ae87-03f4c8d2666d@oracle.com> <64793ff3-4805-79f9-4e72-6e469cd511dc@oracle.com> <15754d34-f3c7-6431-7abf-05214bd6b9d2@oracle.com> Message-ID: <93417506-8e12-6ad3-690a-439e36719652@oracle.com> On 01/31/2018 02:30 AM, Hohensee, Paul wrote: > It?s true that my patch doesn?t completely solve the larger problem, but it fixes the most immediately important part of it, particularly for JDK8 where current expected behavior is entrenched. Yes, your patch fixes part of the problem, but as I said, can potentially lead to more confusion. I'm not sure that doing this behavioral change for a public API in an JDK 8 update release is the right thing. There are likely users that rely on the memory pool "G1 Old Gen" only being updated by a full collection (even though that behavior is not correct), those uses will encounter a new behavior in an update release with your patch. The good thing is that we have very experienced engineers participating in the CSR process that have much more experience than I have in evaluating the impact of behavioral changes such as this one. Would you please file a CSR request for your patch to get their opinion? See https://wiki.openjdk.java.net/display/csr/Main for more details about CSR. On 01/31/2018 02:30 AM, Hohensee, Paul wrote: If we?re going to fix the larger problem, imo we should file another bug/rfe to do it. I?d be happy to fix that one too, once we have a spec. > > What do you think of my suggestions? To summarize: > > - Keep the existing memory pools and add humongous and archive pools. > - Make the archive pool part of the old gen, and generalize it to all collectors. > - Split humongous regions off from the old gen pool into their own pool. The old gen and humongous pools are disjoint region sets. > - Keep the existing ?G1 Young Generation? and ?G1 Old Generation? collectors and their associated memory pools (net of this patch). We add the humongous pool to them. > - Add ?G1 Full? as an alias of the existing ?G1 Old Generation? collector. > - Add the ?G1 Young?, ?G1 Mixed? and ?G1 Concurrent Cycle? collectors. > - Set the G1 old gen memory pool max size to ?Xmx, the archive space max size to whatever it is, and the rest of the G1 memory pool max sizes to -1 == undefined, as now. > > The resulting memory pools: > > ?G1 Eden Space? > ?G1 Survivor Space? > ?G1 Old Gen? > ?G1 Humongous Space? > ?Archive Space? The "Space" suffix is unfortunate, but acceptable. I'm least happy about the "Gen" suffix for the "G1 Old Gen", since G1's old regions differ from a generation in the traditional sense as applied to e.g. Serial, Parallel and CMS. I would be more happy to use a consistent naming scheme in the form of "G1 Old Space" (having only one pool ending "Gen" begs the question how it differs from the others ending in "Space"). Again, we could introduce a flag such as -XX:+UseG1LegacyPoolsAndBeans for those that really wants the old names. "Archive Space" should be named "G1 Archive Space" since it differs in implementation from the other collectors. It would be unfortunate if users thought they could change collector and the "Archive Space" memory pool would keep the same behavior. > The resulting collectors and their memory pools: > > ?G1 Young Generation? (the existing young/mixed collector), ?G1 Old Generation?/?G1 Full?, ?G1 Mixed? > - ?G1 Eden Space? > - ?G1 Survivor Space? > - ?G1 Old Gen? > - ?G1 Humongous Space? > ?G1 Young? > - ?G1 Eden Space? > - ?G1 Survivor Space? > - ?G1 Humongous Space? > ?G1 Concurrent Cycle? > - ?G1 Old Gen? > - ?G1 Humongous Space? > > I?m not religious about the names, but I like my suggestions. :) I think it will be confusing for users to have both "G1 Old Generation" and "G1 Full", particularly for tools iterating over all GarbageCollectorMXBeans. There is no way to indicate that a GarbageCollectorMXBeans is an alias of another GarbageCollectorMXBean (I thought about such a solution as well). I guess I don't follow what the GarbageCollectorMXBean "G1 Young Generation" is meant to represent? > The significant addition to my previous email, and an incompatible change, is splitting humongous regions off from the old gen pool. This means that apps that specifically monitor old gen occupancy will no longer see humongous regions. Monitoring apps that just add up info about all a collector?s pools won?t see a difference. I may be corrected (by Kirk, perhaps), but imo it?s not as bad a compatibility issue as one might think, because the type of app that uses a lot of humongous regions isn?t all that common. E.g., apps that cache data in the heap in the form of large compressed arrays, and apps with large hashmap bucket list arrays. The heaps such apps use are very often large enough to use 32mb regions, hence need really big objects to actually allocate humongous regions. So why not enable backwards compatibility by allowing a user to set the flag -XX:+UseG1LegacyPoolsAndBeans? It is not that cumbersome for us to maintain the current definition of memory pools and collectors. Such a flag allows us to start over and do this right and a user who relies on the current behavior can get that by just setting a flag. Doing such a change in a major release also allows us to clearly highlight the change in the release notes (users are more prepared for larger changes in a major release and that they might have to add flags to keep old behavior). It is not uncommon for memory pools to change in major releases. The perm gen pool was removed in JDK 8, the default pools changed when Parallel Old became default old collector way back in JDK 7 and changed again when G1 became the default collector in JDK 9. Thanks, Erik > Thanks, > > Paul > > On 1/30/18, 5:51 AM, "Erik Helin" wrote: > > On 01/30/2018 03:07 AM, Hohensee, Paul wrote: > > That?s one reviewer who?s ok with a short term patch. Anyone else? And, > > any reviewers for said short term patch? :) > > Well, the patch is not really complete as it is. The problem is the > definitions of the MemoryPoolMXBeans and GarbageCollectorMXBeans, which, > as I tried to hint at in my first email, is a mess for G1. The names and > implementations of these MemoryPoolMXBeans and GarbageCollectionMXBeans > for G1 are very old, G1 has changed a lot since those were implemented > (hence my suggestion for finally fixing this). > > The issue with your patch is that the MemoryPoolMXBean named "G1 Old > Gen" consists of both old and humongous regions (it will also include > archive regions). Old regions can be collected by mixed, concurrent and > full collections. Humongous regions can be collected by young, mixed or > full collections and the concurrent cycle. Archive regions will never be > collected. Your patch will update the pool in the case of a mixed > collection collecting old regions or humongous regions, but misses the > following cases: > - a young collection collecting humongous regions > - a concurrent cycle collecting humongous regions > - a concurrent cycle collecting old regions > > Unfortunately I could not come up with a good way to solve the above > without re-designing the pools. I'm not sure about accepting your patch > as is, since it might cause even more confusion for users compared to > the current (already confusing) situation. > > One idea we have discussed is to implement the re-design but also add a > flag, -XX:+UseG1LegacyPoolsAndBeans (false by default), to allow for a > smoother transition. Would that solution work for you? > > Thanks, > Erik > > > Thanks, > > > > Paul > > > > *From: *mandy chung > > *Organization: *Oracle Corporation > > *Date: *Monday, January 29, 2018 at 1:41 PM > > *To: *"Hohensee, Paul" > > *Cc: *"serviceability-dev at openjdk.java.net" > > , "hotspot-gc-dev at openjdk.java.net" > > > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > > CollectionUsage.used values don't reflect mixed GC results > > > > I created JDK-8196362 to look into whether it makes sense to provide > > some categorization to differentiate eden space vs the heap space for > > long-lived objects. > > > > W.r.t. to JDK-8195115, I have to defer to GC team to comment on the > > mixed collection update. If they are okay, I have no objection to > > implement a short-term fix and do the proper G1 memory pools as a > > separate patch. > > > > Mandy > > > > On 1/29/18 1:02 PM, Hohensee, Paul wrote: > > > > We don?t use getType, and you guessed correctly: we use the memory > > pool name as an indicator of the specific characteristics of a > > memory pool, in particular eden. > > > > What we want is an indication of long term heap occupancy. We > > calculate it using CollectionUsage for non-eden heap memory pools, > > regardless of collector. We don?t use JMX notification, rather we > > periodically poll CollectionUsage for memory pools with names that > > contain ?Old?, ?Tenured?, or ?Survivor?. We get the memory pools > > from the GarbageCollectorMXBeans (we don?t care what the collector > > names are). For the named memory pools, we sum CollectionUsage.used > > and divide by the sum of CollectionUsage.max to get a long term heap > > occupancy percentage. We don?t want to include eden because it?s > > really just an allocation buffer and not part of the storage for > > long-lived objects. I suppose we could use a negative test instead > > by using all memory pools with names that don?t include ?Eden?. > > > > The bug is that the ?G1 Old Gen? memory pool isn?t being updated > > when the ?G1 Young Generation? collector runs a mixed collection. As > > far as JMX is concerned, that collector only knows about eden and > > the survivor space. The patch adds the old gen to the memory pools > > it knows about and has mixed collections update the old gen?s > > CollectionUsage. > > > > I managed to get a submit repo run to succeed last week and it found > > a problem. I?ve uploaded a new webrev that fixes the failure of the > > jtreg test TestMemoryMXBeansAndPoolsPresence.java due to the young > > gen collector being expected to know only about eden and the > > survivor space. > > > > http://cr.openjdk.java.net/~phh/8195115/webrev.hs.01/ > > > > > > Waiting on the submit repo to come back with a result on it. > > > > Thanks, > > > > Paul > > > > *From: *mandy chung > > > > *Organization: *Oracle Corporation > > *Date: *Monday, January 29, 2018 at 10:52 AM > > *To: *"Hohensee, Paul" > > , Erik Helin > > , David Holmes > > > > *Cc: *"serviceability-dev at openjdk.java.net" > > > > > > , > > "hotspot-gc-dev at openjdk.java.net" > > > > > > > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > > CollectionUsage.used values don't reflect mixed GC results > > > > On 1/29/18 10:35 AM, mandy chung wrote: > > > > Thanks for the reply Paul. Try to understand a little more on > > the specific from gc-specific memory pool you depend on. > > > > On 1/29/18 8:27 AM, Hohensee, Paul wrote: > > > > A name change would affect Amazon?s heap monitoring, and > > thus I expect it would affect other users as well. > > > > As long as there are gc-specific memory pools, we?re going > > to need to be able to identify them, and right now that?s > > done via name. > > > > > > MemoryPoolMXBean::getType returns "heap" memory type for > > GC-specific memory pools. Are you using this method? Do you > > use the name to build in specific characteristic of a memory > > pool (e.g. eden vs old gen)? > > > > > > > > > > All the mxbeans are identified by name, so that?s a general > > design principle. The only way I can think of to get rid of > > name dependency would be to figure out what abstract metrics > > users want to monitor and implement them for all collectors. > > HeapUsage (instantaneous occupancy) is one, CollectionUsage > > (long-lived occupancy) is another, both of these for the > > entire heap, not just particular memory pools. > > > > > > The sum of HeapUsage and CollectionUsage of all heap memory > > pools was expected to give an incorrect approximation for the > > entire heap usage. Are you seeing issue/bug with the sum result? > > > > > > typo: s/an incorrect approximation/an approximation. > > > > Mandy > > > > > > > > Mandy > > > > > > > > That said, imo there will always be a demand for the ability > > to get collector and memory pool specific details, so I > > don?t see a way to get around providing named entities. > > > > Paul > > > > *From: *mandy chung > > > > *Organization: *Oracle Corporation > > *Date: *Friday, January 26, 2018 at 2:38 PM > > *To: *"Hohensee, Paul" > > , Erik Helin > > , > > David Holmes > > > > *Cc: *"serviceability-dev at openjdk.java.net" > > > > > > , > > "hotspot-gc-dev at openjdk.java.net" > > > > > > > > *Subject: *Re: RFR (S): 8195115: G1 Old Gen MemoryPool > > CollectionUsage.used values don't reflect mixed GC results > > > > On 1/25/18 1:04 PM, Hohensee, Paul wrote: > > > > > > > The JMX API spec doesn?t specify what the memory pool or > > garbage > collector names are, but the current names are > > de-facto part of the > API, so if we change the existing > > ones, imo a CSR should be filed. > > > > The names are implementation details but I can see how an application > > > > might be impacted if they depend on it. CSR approval is not strictly > > > > necessary while I think filing one to document the change would be > > > > good. > > > > Does the name change impact any application you know of? I'm trying to > > > > understand if any improvement to API is needed so that applications > > > > don't need to depend on the names. > > > > > > Mandy > > > > > > > > > > > > > > > > > > From stewartd.qdt at qualcommdatacenter.com Wed Jan 31 16:45:12 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Wed, 31 Jan 2018 16:45:12 +0000 Subject: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java In-Reply-To: <3318aed7-f04a-3b92-2660-39cdf13c2d24@oracle.com> References: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> <44a71e46-3da2-53c6-7e6b-82658183ae8c@oracle.com> <3318aed7-f04a-3b92-2660-39cdf13c2d24@oracle.com> Message-ID: <24c556061ffb4fde9e87a8806c04c8f7@NASANEXM01E.na.qualcomm.com> Hi Jini, David, Please have a look at the revised webrev: http://cr.openjdk.java.net/~dstewart/8196361/webrev.01/ In this webrev I have changed the approach to finding the addresses. This was necessary because in the case of matching for the locks the addresses are before what is matched and in the case of Method the address is after it. The existing code only looked for the addresses after the matched string. I've also tried to align what tokens are being looked for in the lock case. I've taken an approach of breaking the jstack output into lines and then searching each line for it containing what we want. Once found, the line is broken into pieces to find the actual address we want. Please let me know if this is an unacceptable approach or any changes you would like to see. Thanks, Daniel -----Original Message----- From: Jini George [mailto:jini.george at oracle.com] Sent: Tuesday, January 30, 2018 6:58 AM To: David Holmes ; stewartd.qdt Cc: serviceability-dev ; hotspot-dev at openjdk.java.net Subject: Re: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java Hi Daniel, David, Thanks, Daniel, for bringing this up. The intent of the test is to get the oop address corresponding to a java.lang.ref.ReferenceQueue$Lock, which can typically be obtained from the stack traces of the Common-Cleaner or the Finalizer threads. The stack traces which I had been noticing were typically of the form: "Common-Cleaner" #8 daemon prio=8 tid=0x00007f09c82ac000 nid=0xf6e in Object.wait() [0x00007f09a18d2000] java.lang.Thread.State: TIMED_WAITING (on object monitor) JavaThread state: _thread_blocked - java.lang.Object.wait(long) @bci=0, pc=0x00007f09b7d6480b, Method*=0x00007f09acc43d60 (Interpreted frame) - waiting on <0x000000072e61f6e0> (a java.lang.ref.ReferenceQueue$Lock) - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=151, pc=0x00007f09b7d55243, Method*=0x00007f09acdab9b0 (Interpreted frame) - waiting to re-lock in wait() <0x000000072e61f6e0> (a java.lang.ref.ReferenceQueue$Lock) ... I chose 'waiting to re-lock in wait' since that was what I had been observing next to the oop address of java.lang.ref.ReferenceQueue$Lock. But I see how with a timing difference, one could get 'waiting to lock' as in your case. So, a good way to fix might be to check for the line containing '(a java.lang.ref.ReferenceQueue$Lock)', getting the oop address from that line (should be the address appearing immediately before '(a java.lang.ref.ReferenceQueue$Lock)') and passing that to the 'inspect' command. Thanks much, Jini. On 1/30/2018 3:35 AM, David Holmes wrote: > Hi Daniel, > > Serviceability issues should go to serviceability-dev at openjdk.java.net > - now cc'd. > > On 30/01/2018 7:53 AM, stewartd.qdt wrote: >> Please review this webrev [1] which attempts to fix a test error in >> serviceability/sa/ClhsdbInspect.java when it is run under an AArch64 >> system (not necessarily exclusive to this system, but it was the >> system under test). The bug report [2] provides further details. >> Essentially the line "waiting to re-lock in wait" never actually >> occurs. Instead I have the line "waiting to lock" which occurs for >> the referenced item of /java/lang/ref/ReferenceQueue$Lock. >> Unfortunately the test is written such that only the first "waiting to lock" >> occurrence is seen (for java/lang/Class), which is already accounted >> for in the test. > > I can't tell exactly what the test expects, or why, but it would be > extremely hard to arrange for "waiting to re-lock in wait" to be seen > for the ReferenceQueue lock! That requires acquiring the lock > yourself, issuing a notify() to unblock the wait(), and then issuing > the jstack command while still holding the lock! > > David > ----- > >> I'm not overly happy with this approach as it actually removes a test >> line. However, the test line does not actually appear in the output >> (at least on my system) and the test is not currently written to look >> for the second occurrence of the line "waiting to lock". Perhaps the >> original author could chime in and provide further guidance as to the >> intention of the test. >> >> I am happy to modify the patch as necessary. >> >> Regards, >> Daniel Stewart >> >> >> [1] -? http://cr.openjdk.java.net/~dstewart/8196361/webrev.00/ >> [2] - https://bugs.openjdk.java.net/browse/JDK-8196361 >> From stewartd.qdt at qualcommdatacenter.com Wed Jan 31 21:09:30 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Wed, 31 Jan 2018 21:09:30 +0000 Subject: RFR: 8196521: serviceability/sa/ClhsdbWhere.java fails to find method 'waitForReferencePendingList' in output Message-ID: <71d86c90cba444c6967883078e5c5cc3@NASANEXM01E.na.qualcomm.com> Please review this webrev [1] which attempts to fix a test error in serviceability/sa/ClhsdbWhere.java when it is run under an AArch64 system (not necessarily exclusive to this system, but it was the system under test). The bug report [2] provides further details and has the jtr report that was generated. Essentially the line "waitForReferencePendingList" never actually occurs. The test is written such that it is expecting that line. This patch simply removes the line from the set of tested lines it expects. I'm not overly happy with this approach as it actually removes a test line. However, the test line does not actually appear in the output (at least on my system) and I'm not sure if there is actually another way of testing for the intent of this line or if it doesn't actually have to appear in the output, depending on the system. Perhaps the original author could chime in and provide further guidance as to the intention of the test. I am happy to modify the patch as necessary. Regards, Daniel Stewart [1] - http://cr.openjdk.java.net/~dstewart/8196521/webrev.00/ [2] - https://bugs.openjdk.java.net/browse/JDK-8196521 -------------- next part -------------- An HTML attachment was scrubbed... URL: