From felix.yang at huawei.com Wed Jan 8 01:09:15 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 8 Jan 2020 01:09:15 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX Message-ID: Hi, Please review this patch adding a way to configure the third port for remote JMX. Currently, it is possible to configure two of the three ports for JMX with com.sun.management.jmxremote.port and com.sun.management.jmxremote.rmi.port. However, there is no way to configure the third port. This can cause problems if the randomly assigned port conflicts with another service that has not yet acquired its port. Bug: https://bugs.openjdk.java.net/browse/JDK-8234484 Webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.00/ Passed tiered-1 test. Thanks, Felix -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Jan 8 10:20:57 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 8 Jan 2020 10:20:57 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: Message-ID: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> Hi Felix, Shouldn't this be configurable via the management.properties file, like all other JMX properties? Also on the one hand - it would be good to have a test. On the other hand - writing a stable test will be problematic as there is no way to ensure that any particular port number will be available for the agent to bind to. best regards, -- daniel On 08/01/2020 01:09, Yangfei (Felix) wrote: > Hi, > > Please review this patch adding a way to configure the third port for > remote JMX. > > Currently, it is possible to configure two of the three ports for JMX > with com.sun.management.jmxremote.port and > com.sun.management.jmxremote.rmi.port. > > However, there is no way to configure the third port. This can cause > problems if the randomly assigned port conflicts with another service > that has not yet acquired its port. > > ?? Bug: https://bugs.openjdk.java.net/browse/JDK-8234484 > > ??Webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.00/ > > ? Passed tiered-1 test. > > Thanks, > > Felix > From daniil.x.titov at oracle.com Sat Jan 11 04:52:14 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 10 Jan 2020 20:52:14 -0800 Subject: jmx-dev RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES Message-ID: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() remote method call. This constant was superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and marked as deprecated for removal in JDK 10 [3]. A new CRS [4] and a release note sub-task [5] were also created. Please review the CSR [4] as well. Text search over the repository didn't find any other usage of this constant. Tier1 - tier3 Mach5 tests succeeded. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8213222/webrev.01/ [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8213222 [3] https://bugs.openjdk.java.net/browse/JDK-8191313 [4] CSR: https://bugs.openjdk.java.net/browse/JDK-8236954 [5] Release Note sub-task: https://bugs.openjdk.java.net/browse/JDK-8236955 Thank you, Daniil From Alan.Bateman at oracle.com Sat Jan 11 07:17:36 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Jan 2020 07:17:36 +0000 Subject: jmx-dev RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES In-Reply-To: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> References: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> Message-ID: <1861b33d-2659-c177-af24-52bbdbc5b317@oracle.com> On 11/01/2020 04:52, Daniil Titov wrote: > Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. > This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() > remote method call. This constant was superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and marked as > deprecated for removal in JDK 10 [3]. > > A new CRS [4] and a release note sub-task [5] were also created. Please review the CSR [4] as well. > Looks good. I changed the scope of the CSR to "SE" and added myself as Reviewer. -Alan From felix.yang at huawei.com Sat Jan 11 07:37:39 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sat, 11 Jan 2020 07:37:39 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> Message-ID: Hi Daniel, Thanks for the suggestions. I modified the patch making the third port also configurable via the management.properties file. New webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.01/ Previously, we test the effectiveness of the patch by checking the port usage with -Dsun.rmi.transport.tcp.logLevel=VERBOSE. Is it good to modify the following test case specifying the third port for the testing purpose? diff -r d630c0a63222 test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java --- a/test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java Wed Jan 08 08:53:28 2020 +0900 +++ b/test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java Sat Jan 11 15:30:25 2020 +0000 @@ -31,6 +31,7 @@ import jdk.test.lib.process.OutputAnalyzer; import jdk.test.lib.process.ProcessTools; +import jdk.test.lib.Utils; /** * @test @@ -203,6 +204,12 @@ args.add("-Dcom.sun.management.jmxremote.host=" + address); args.add("-Dcom.sun.management.jmxremote.port=" + jmxPort); args.add("-Dcom.sun.management.jmxremote.rmi.port=" + rmiPort); + try { + int port = Utils.getFreePort(); + args.add("-Dcom.sun.management.jmxlocal.port=" + port); + } catch (Exception e) { + System.out.println(e); + } args.add("-Dcom.sun.management.jmxremote.authenticate=false"); args.add("-Dcom.sun.management.jmxremote.ssl=" + Boolean.toString(useSSL)); // This is needed for testing on loopback Felix > > Hi Felix, > > Shouldn't this be configurable via the management.properties file, like all other > JMX properties? > > Also on the one hand - it would be good to have a test. > On the other hand - writing a stable test will be problematic as there is no way > to ensure that any particular port number will be available for the agent to bind > to. > > best regards, > > -- daniel > > On 08/01/2020 01:09, Yangfei (Felix) wrote: > > Hi, > > > > Please review this patch adding a way to configure the third port for > > remote JMX. > > > > Currently, it is possible to configure two of the three ports for JMX > > with com.sun.management.jmxremote.port and > > com.sun.management.jmxremote.rmi.port. > > > > However, there is no way to configure the third port. This can cause > > problems if the randomly assigned port conflicts with another service > > that has not yet acquired its port. > > > > ?? Bug: https://bugs.openjdk.java.net/browse/JDK-8234484 > > > > ??Webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.00/ > > > > ? Passed tiered-1 test. > > > > Thanks, > > > > Felix > > From daniel.fuchs at oracle.com Mon Jan 13 15:10:56 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Jan 2020 15:10:56 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> Message-ID: <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Hi Felix, On 11/01/2020 07:37, Yangfei (Felix) wrote: > Hi Daniel, > > Thanks for the suggestions. > I modified the patch making the third port also configurable via the management.properties file. > New webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.01/ I think I would prefer the try catch NumberFormatException to be just around the call to Integer.parseInt(), as it is done elsewhere in this file (e.g. line 337). > > Previously, we test the effectiveness of the patch by checking the port usage with -Dsun.rmi.transport.tcp.logLevel=VERBOSE. > Is it good to modify the following test case specifying the third port for the testing purpose? Please don't do that. That test is not appropriate for this - as it opens a remote connector, not a local connector. Also please get someone from serviceability-dev to also look at changes (added in cc:). best regards, -- daniel > > diff -r d630c0a63222 test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > --- a/test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java Wed Jan 08 08:53:28 2020 +0900 > +++ b/test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java Sat Jan 11 15:30:25 2020 +0000 > @@ -31,6 +31,7 @@ > > import jdk.test.lib.process.OutputAnalyzer; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.Utils; > > /** > * @test > @@ -203,6 +204,12 @@ > args.add("-Dcom.sun.management.jmxremote.host=" + address); > args.add("-Dcom.sun.management.jmxremote.port=" + jmxPort); > args.add("-Dcom.sun.management.jmxremote.rmi.port=" + rmiPort); > + try { > + int port = Utils.getFreePort(); > + args.add("-Dcom.sun.management.jmxlocal.port=" + port); > + } catch (Exception e) { > + System.out.println(e); > + } > args.add("-Dcom.sun.management.jmxremote.authenticate=false"); > args.add("-Dcom.sun.management.jmxremote.ssl=" + Boolean.toString(useSSL)); > // This is needed for testing on loopback > > Felix > >> >> Hi Felix, >> >> Shouldn't this be configurable via the management.properties file, like all other >> JMX properties? >> >> Also on the one hand - it would be good to have a test. >> On the other hand - writing a stable test will be problematic as there is no way >> to ensure that any particular port number will be available for the agent to bind >> to. >> >> best regards, >> >> -- daniel >> >> On 08/01/2020 01:09, Yangfei (Felix) wrote: >>> Hi, >>> >>> Please review this patch adding a way to configure the third port for >>> remote JMX. >>> >>> Currently, it is possible to configure two of the three ports for JMX >>> with com.sun.management.jmxremote.port and >>> com.sun.management.jmxremote.rmi.port. >>> >>> However, there is no way to configure the third port. This can cause >>> problems if the randomly assigned port conflicts with another service >>> that has not yet acquired its port. >>> >>> ?? Bug: https://bugs.openjdk.java.net/browse/JDK-8234484 >>> >>> ??Webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.00/ >>> >>> ? Passed tiered-1 test. >>> >>> Thanks, >>> >>> Felix >>> > From daniel.fuchs at oracle.com Mon Jan 13 15:36:17 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Jan 2020 15:36:17 +0000 Subject: jmx-dev RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES In-Reply-To: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> References: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> Message-ID: Hi Daniil, Looks good to me as well. I wonder however if the release note should point to the replacement? Something like: The terminally deprecated constant `javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE` has been removed. A filter pattern can be specified instead using `RMIConnectorServer.CREDENTIALS_FILTER_PATTERN`. best regards, -- daniel On 11/01/2020 04:52, Daniil Titov wrote: > Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. > This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() > remote method call. This constant was superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and marked as > deprecated for removal in JDK 10 [3]. > > A new CRS [4] and a release note sub-task [5] were also created. Please review the CSR [4] as well. > > Text search over the repository didn't find any other usage of this constant. Tier1 - tier3 Mach5 tests succeeded. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8213222/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8213222 > [3] https://bugs.openjdk.java.net/browse/JDK-8191313 > [4] CSR: https://bugs.openjdk.java.net/browse/JDK-8236954 > [5] Release Note sub-task: https://bugs.openjdk.java.net/browse/JDK-8236955 > > Thank you, > Daniil > > From daniil.x.titov at oracle.com Tue Jan 14 21:05:10 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 14 Jan 2020 13:05:10 -0800 Subject: jmx-dev RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES Message-ID: Hi Alan and Daniel, Thank you for reviewing this change and the CSR. I updated the release note as Daniel suggested. Best regards, Daniil ?On 1/13/20, 7:36 AM, "Daniel Fuchs" wrote: Hi Daniil, Looks good to me as well. I wonder however if the release note should point to the replacement? Something like: The terminally deprecated constant `javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE` has been removed. A filter pattern can be specified instead using `RMIConnectorServer.CREDENTIALS_FILTER_PATTERN`. best regards, -- daniel On 11/01/2020 04:52, Daniil Titov wrote: > Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. > This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() > remote method call. This constant was superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and marked as > deprecated for removal in JDK 10 [3]. > > A new CRS [4] and a release note sub-task [5] were also created. Please review the CSR [4] as well. > > Text search over the repository didn't find any other usage of this constant. Tier1 - tier3 Mach5 tests succeeded. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8213222/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8213222 > [3] https://bugs.openjdk.java.net/browse/JDK-8191313 > [4] CSR: https://bugs.openjdk.java.net/browse/JDK-8236954 > [5] Release Note sub-task: https://bugs.openjdk.java.net/browse/JDK-8236955 > > Thank you, > Daniil > > From felix.yang at huawei.com Thu Jan 16 02:01:05 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 16 Jan 2020 02:01:05 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Message-ID: Hi Daniel, > > Hi Felix, > > On 11/01/2020 07:37, Yangfei (Felix) wrote: > > Hi Daniel, > > > > Thanks for the suggestions. > > I modified the patch making the third port also configurable via the > management.properties file. > > New webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.01/ > > I think I would prefer the try catch NumberFormatException to be just around > the call to Integer.parseInt(), as it is done elsewhere in this file (e.g. line 337). Modified accordingly in new webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.02/ Also renamed property to: com.sun.management.jmxremote.local.port Thanks, Felix From daniel.fuchs at oracle.com Fri Jan 17 11:51:04 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 17 Jan 2020 11:51:04 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Message-ID: Thanks Felix! On 16/01/2020 02:01, Yangfei (Felix) wrote: > Modified accordingly in new webrev:http://cr.openjdk.java.net/~fyang/8234484/webrev.02/ > > Also renamed property to: com.sun.management.jmxremote.local.port That looks fine to me. best regards, -- daniel From daniil.x.titov at oracle.com Sat Jan 18 03:10:51 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 17 Jan 2020 19:10:51 -0800 Subject: jmx-dev RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c Message-ID: Please review a change that removes unnecessary workaround in UnixOperatingSystem.c. It looks as this workaround if (pticks->usedKernel < tmp.usedKernel) { kdiff = 0; } was added to compensate a missed initialization of counters.jvmTicks that resulted in the new counters being compared with the garbage when get_cpuload_internal(...) was called for the first time. This missed initialization was fixed in [3]. Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker tests successfully passed. [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 [3] https://bugs.openjdk.java.net/browse/JDK-8226575 Thank you, Daniil From felix.yang at huawei.com Tue Jan 21 07:15:28 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 21 Jan 2020 07:15:28 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Message-ID: Hi Daniel, Thanks for reviewing the patch. Will do the push. Felix > > On 16/01/2020 02:01, Yangfei (Felix) wrote: > > Modified accordingly in new > webrev:http://cr.openjdk.java.net/~fyang/8234484/webrev.02/ > > > > Also renamed property to: com.sun.management.jmxremote.local.port > > That looks fine to me. > > best regards, > > -- daniel From Alan.Bateman at oracle.com Tue Jan 21 16:00:27 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jan 2020 16:00:27 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Message-ID: <8fc616ec-4913-662c-6eba-6e6334801a46@oracle.com> On 21/01/2020 07:15, Yangfei (Felix) wrote: > Hi Daniel, > > Thanks for reviewing the patch. Will do the push. > Is this a documented and supported property? I assume so, in which case you should create a CSR. I think a Release-Note sub-task will needed too so that it gets into at least the release notes. -Alan From chris.plummer at oracle.com Tue Jan 21 18:38:43 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 21 Jan 2020 10:38:43 -0800 Subject: jmx-dev RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: References: Message-ID: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> Hi Daniil, Do you think it's worth changing the check to an assert instead of removing it? Also, I'm not clear on the need for the *pkernelLoad initialization. It seems this is attempting to fix a different issue, but it's already initialized to 0 at the start of the function. thanks, Chris On 1/17/20 7:10 PM, Daniil Titov wrote: > Please review a change that removes unnecessary workaround in UnixOperatingSystem.c. > > It looks as this workaround > > if (pticks->usedKernel < tmp.usedKernel) { > kdiff = 0; > } > > was added to compensate a missed initialization of counters.jvmTicks that resulted in the new > counters being compared with the garbage when get_cpuload_internal(...) was called for the first time. > > This missed initialization was fixed in [3]. > > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker tests successfully passed. > > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 > > Thank you, > Daniil > > From felix.yang at huawei.com Wed Jan 22 08:12:37 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 22 Jan 2020 08:12:37 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: <8fc616ec-4913-662c-6eba-6e6334801a46@oracle.com> References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> <8fc616ec-4913-662c-6eba-6e6334801a46@oracle.com> Message-ID: > On 21/01/2020 07:15, Yangfei (Felix) wrote: > > Hi Daniel, > > > > Thanks for reviewing the patch. Will do the push. > > > Is this a documented and supported property? I assume so, in which case you > should create a CSR. I think a Release-Note sub-task will needed too so that it > gets into at least the release notes. Hi, Thanks for reminding this. I have created a retroactive CSR for that: https://bugs.openjdk.java.net/browse/JDK-8237631 Larry Cable has added release-note label to indicate need for this addition to be mentioned in the release notes for 15. Please let me know if there are other things that I can help. Best regards, Felix From daniil.x.titov at oracle.com Wed Jan 22 23:30:12 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 22 Jan 2020 15:30:12 -0800 Subject: jmx-dev RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> References: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> Message-ID: Hi Chris, Please review a new version of the fix [1] that converts the check to the assert. > Also, I'm not clear on the need for the *pkernelLoad initialization. It > seems this is attempting to fix a different issue, but it's already > initialized to 0 at the start of the function. You are right, *pkernelLoad is already initialized on line 251. The new version of the webrev does not include this change. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8235681/webrev.02/ [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8235681 Thank you, Daniil ?On 1/21/20, 10:38 AM, "Chris Plummer" wrote: Hi Daniil, Do you think it's worth changing the check to an assert instead of removing it? Also, I'm not clear on the need for the *pkernelLoad initialization. It seems this is attempting to fix a different issue, but it's already initialized to 0 at the start of the function. thanks, Chris On 1/17/20 7:10 PM, Daniil Titov wrote: > Please review a change that removes unnecessary workaround in UnixOperatingSystem.c. > > It looks as this workaround > > if (pticks->usedKernel < tmp.usedKernel) { > kdiff = 0; > } > > was added to compensate a missed initialization of counters.jvmTicks that resulted in the new > counters being compared with the garbage when get_cpuload_internal(...) was called for the first time. > > This missed initialization was fixed in [3]. > > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker tests successfully passed. > > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 > > Thank you, > Daniil > > From chris.plummer at oracle.com Thu Jan 23 03:02:59 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 22 Jan 2020 19:02:59 -0800 Subject: jmx-dev RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: References: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> Message-ID: <1ce5fdb5-a1da-0ce2-b6dc-50fb1953c592@oracle.com> Looks good. Chris On 1/22/20 3:30 PM, Daniil Titov wrote: > Hi Chris, > > Please review a new version of the fix [1] that converts the check to the assert. > >> Also, I'm not clear on the need for the *pkernelLoad initialization. It >> seems this is attempting to fix a different issue, but it's already >> initialized to 0 at the start of the function. > You are right, *pkernelLoad is already initialized on line 251. The new version of > the webrev does not include this change. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8235681/webrev.02/ > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8235681 > > Thank you, > Daniil > > ?On 1/21/20, 10:38 AM, "Chris Plummer" wrote: > > Hi Daniil, > > Do you think it's worth changing the check to an assert instead of > removing it? > > Also, I'm not clear on the need for the *pkernelLoad initialization. It > seems this is attempting to fix a different issue, but it's already > initialized to 0 at the start of the function. > > thanks, > > Chris > > On 1/17/20 7:10 PM, Daniil Titov wrote: > > Please review a change that removes unnecessary workaround in UnixOperatingSystem.c. > > > > It looks as this workaround > > > > if (pticks->usedKernel < tmp.usedKernel) { > > kdiff = 0; > > } > > > > was added to compensate a missed initialization of counters.jvmTicks that resulted in the new > > counters being compared with the garbage when get_cpuload_internal(...) was called for the first time. > > > > This missed initialization was fixed in [3]. > > > > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker tests successfully passed. > > > > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ > > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 > > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 > > > > Thank you, > > Daniil > > > > > > > > From alexey.menkov at oracle.com Fri Jan 24 18:38:04 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 24 Jan 2020 10:38:04 -0800 Subject: jmx-dev RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: <1ce5fdb5-a1da-0ce2-b6dc-50fb1953c592@oracle.com> References: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> <1ce5fdb5-a1da-0ce2-b6dc-50fb1953c592@oracle.com> Message-ID: <7e17fc44-54ad-b5a8-494e-25419620c5ca@oracle.com> +1 --alex On 01/22/2020 19:02, Chris Plummer wrote: > Looks good. > > Chris > > On 1/22/20 3:30 PM, Daniil Titov wrote: >> Hi Chris, >> >> Please review a new version of the fix [1] that converts the check to >> the assert. >> >>> ??? Also, I'm not clear on the need for the *pkernelLoad >>> initialization. It >>> ??? seems this is attempting to fix a different issue, but it's already >>> ??? initialized to 0 at the start of the function. >> You are right, *pkernelLoad is already initialized on line 251. The >> new version of >> the webrev does not include this change. >> >> [1] Webrev:? http://cr.openjdk.java.net/~dtitov/8235681/webrev.02/ >> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8235681 >> >> Thank you, >> Daniil >> >> ?On 1/21/20, 10:38 AM, "Chris Plummer" wrote: >> >> ???? Hi Daniil, >> ???? Do you think it's worth changing the check to an assert instead of >> ???? removing it? >> ???? Also, I'm not clear on the need for the *pkernelLoad >> initialization. It >> ???? seems this is attempting to fix a different issue, but it's already >> ???? initialized to 0 at the start of the function. >> ???? thanks, >> ???? Chris >> ???? On 1/17/20 7:10 PM, Daniil Titov wrote: >> ???? > Please review a change that removes unnecessary workaround in >> UnixOperatingSystem.c. >> ???? > >> ???? > It looks as this workaround >> ???? > >> ???? > if (pticks->usedKernel < tmp.usedKernel) { >> ???? >????????? kdiff = 0; >> ???? >?? } >> ???? > >> ???? > was added to compensate a missed initialization of >> counters.jvmTicks that resulted in the new >> ???? > counters being compared with the garbage when >> get_cpuload_internal(...) was called for the first time. >> ???? > >> ???? > This missed initialization was fixed in [3]. >> ???? > >> ???? > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker >> tests successfully passed. >> ???? > >> ???? > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ >> ???? > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 >> ???? > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 >> ???? > >> ???? > Thank you, >> ???? > Daniil >> ???? > >> ???? > >> >> > > From daniil.x.titov at oracle.com Fri Jan 24 18:39:15 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 24 Jan 2020 10:39:15 -0800 Subject: jmx-dev RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: <7e17fc44-54ad-b5a8-494e-25419620c5ca@oracle.com> References: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> <1ce5fdb5-a1da-0ce2-b6dc-50fb1953c592@oracle.com> <7e17fc44-54ad-b5a8-494e-25419620c5ca@oracle.com> Message-ID: Thank you Alex and Chris for reviewing this change! Best regards, Daniil ?On 1/24/20, 10:38 AM, "Alex Menkov" wrote: +1 --alex On 01/22/2020 19:02, Chris Plummer wrote: > Looks good. > > Chris > > On 1/22/20 3:30 PM, Daniil Titov wrote: >> Hi Chris, >> >> Please review a new version of the fix [1] that converts the check to >> the assert. >> >>> Also, I'm not clear on the need for the *pkernelLoad >>> initialization. It >>> seems this is attempting to fix a different issue, but it's already >>> initialized to 0 at the start of the function. >> You are right, *pkernelLoad is already initialized on line 251. The >> new version of >> the webrev does not include this change. >> >> [1] Webrev: http://cr.openjdk.java.net/~dtitov/8235681/webrev.02/ >> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8235681 >> >> Thank you, >> Daniil >> >> ?On 1/21/20, 10:38 AM, "Chris Plummer" wrote: >> >> Hi Daniil, >> Do you think it's worth changing the check to an assert instead of >> removing it? >> Also, I'm not clear on the need for the *pkernelLoad >> initialization. It >> seems this is attempting to fix a different issue, but it's already >> initialized to 0 at the start of the function. >> thanks, >> Chris >> On 1/17/20 7:10 PM, Daniil Titov wrote: >> > Please review a change that removes unnecessary workaround in >> UnixOperatingSystem.c. >> > >> > It looks as this workaround >> > >> > if (pticks->usedKernel < tmp.usedKernel) { >> > kdiff = 0; >> > } >> > >> > was added to compensate a missed initialization of >> counters.jvmTicks that resulted in the new >> > counters being compared with the garbage when >> get_cpuload_internal(...) was called for the first time. >> > >> > This missed initialization was fixed in [3]. >> > >> > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker >> tests successfully passed. >> > >> > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ >> > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 >> > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 >> > >> > Thank you, >> > Daniil >> > >> > >> >> > >