From mandy.chung at oracle.com Wed Feb 1 05:11:23 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 21:11:23 -0800 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> Message-ID: > On Jan 31, 2017, at 10:26 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a patch for: > > 8173607: JMX RMI connector should be in its own module > https://bugs.openjdk.java.net/browse/JDK-8173607 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 > This mostly looks good. I?d like to see an updated webrev after you sync with JDK-8173608. I believe you can revert test/sun/management/jdp and test/sun/management/jmxremote tests change and ConnectorBootstrap.java as you noted. Also you can run jdeps ?-check on java.rmi, java.management, and jdk.management.agent to update its requires and qualified exports. java.management should no longer require java.rmi and the qualified exports from java.rmi is not needed. java.management.rmi module-info.java 32 * @see javax.management.remote.rmi This @see is not needed. This package is listed in the exported packages table. JMXConnectorFactory.java I like the ProviderFinder approach to look up the custom providers and platform providers; and shared code used by both JMXConnectorFactory and JMXConnectorServerFactory which is good. Nit: line 481-491 - this is javadoc and probably /* .. */ comment block is more appropriate here. > > Some further cleanup of java.base and java.rmi module-info.java > should become possible once JDK-8173608 is in (as well as moving > RMIExporter to java.management.rmi - which is not possible yet). > Yes. > Further cleanup of @modules in tests might become possible as > well. > Hope there will be a bulk @modules cleanup some time. Thanks Mandy From Alan.Bateman at oracle.com Wed Feb 1 09:40:39 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Feb 2017 09:40:39 +0000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: On 30/01/2017 23:48, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > Just catching up this. It looks like the native methods for jdk.internal.agent.FileSystemImpl have been moved to libmanagemtn_rmi.so, shouldn't this be libmanagement_agent.so? -Alan From erik.joelsson at oracle.com Wed Feb 1 11:56:59 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 1 Feb 2017 12:56:59 +0100 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> Message-ID: <32acdd4e-0ec3-d76d-fd17-cb2514570f5d@oracle.com> Build changes look ok. /Erik On 2017-01-31 19:26, Daniel Fuchs wrote: > Hi, > > Please find below a patch for: > > 8173607: JMX RMI connector should be in its own module > https://bugs.openjdk.java.net/browse/JDK-8173607 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 > > This patch makes it possible to remove the requires transitive > java.rmi from the java.management module. > > For convenience here is the HTML module-level API documentation > produced by javadoc for the new java.management.rmi module: > > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05/java.management.rmi-summary.html > > > The patch has some temporary hacks (mainly ConnectorBootstrap.java) > that we will be able to revert when > JDK-8173608 Separate JDK management agent from java.management module > is pushed. > > The changes were mainly mechanical except for: > > ConnectorBootstrap.java: see above > JMXConnectorFactory.java/JMXConnectorServerFactory.java: > ServiceLoader is now used to load the default RMI Connector provider > as a service. There should however be no observable behavior change > to existing application. > ProxyRef.java, Unmarshal.java: are moved to a new > com.sun.jmx.remote.internal.rmi package in the new module. > ClientNotifForwarder.java: is modified to no longer depend on > java.rmi.UnmarshalException - NotSerializableException is used > instead > RMIConnector.java: fetchNotif is updated to throw > NotSerializableException instead of UnmarshalException > The PRef serialization bytes are updated to accomodate the > new ProxyRef package name. > > Some further cleanup of java.base and java.rmi module-info.java > should become possible once JDK-8173608 is in (as well as moving > RMIExporter to java.management.rmi - which is not possible yet). > > Further cleanup of @modules in tests might become possible as > well. > > Note: > JCK tests for api/javax_management and api/java_lang/management > are passing with this change. > > best regards, > > -- daniel > From daniel.fuchs at oracle.com Wed Feb 1 15:29:22 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 1 Feb 2017 15:29:22 +0000 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> Message-ID: <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> Hi Mandy, On 01/02/17 05:11, Mandy Chung wrote: > >> On Jan 31, 2017, at 10:26 AM, Daniel Fuchs wrote: >> >> Hi, >> >> Please find below a patch for: >> >> 8173607: JMX RMI connector should be in its own module >> https://bugs.openjdk.java.net/browse/JDK-8173607 >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 >> > > This mostly looks good. I?d like to see an updated webrev after you sync with JDK-8173608. I believe you can revert test/sun/management/jdp and test/sun/management/jmxremote tests change and ConnectorBootstrap.java as you noted. Also you can run jdeps ?-check on java.rmi, java.management, and jdk.management.agent to update its requires and qualified exports. java.management should no longer require java.rmi and the qualified exports from java.rmi is not needed. Here is the updated webrev, rebased after pulling JDK-8173608, and with your feedback below integrated. I am pleased to report that java.management no longer requires java.rmi or java.naming :-) Compared to previous version, then RMIExporter has been moved to java.management.rmi, various module-info.java have been cleaned up, some @modules in tests have been updated (mostly due to the RMIExporter move). I have also improved some javadoc comments in JMXConnectorFactory.java No changes in build files compared to webrev.05 http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html best regards, -- daniel > > java.management.rmi module-info.java > 32 * @see javax.management.remote.rmi > > This @see is not needed. This package is listed in the exported packages table. > > JMXConnectorFactory.java > I like the ProviderFinder approach to look up the custom providers and platform providers; and shared code used by both JMXConnectorFactory and JMXConnectorServerFactory which is good. > > Nit: line 481-491 - this is javadoc and probably /* .. */ comment block is more appropriate here. > >> >> Some further cleanup of java.base and java.rmi module-info.java >> should become possible once JDK-8173608 is in (as well as moving >> RMIExporter to java.management.rmi - which is not possible yet). >> > > Yes. > >> Further cleanup of @modules in tests might become possible as >> well. >> > > Hope there will be a bulk @modules cleanup some time. > > Thanks > Mandy > From mandy.chung at oracle.com Thu Feb 2 02:41:42 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Feb 2017 18:41:42 -0800 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> Message-ID: <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com> > On Feb 1, 2017, at 7:29 AM, Daniel Fuchs wrote: > > Here is the updated webrev, rebased after pulling JDK-8173608, and with > your feedback below integrated. > > I am pleased to report that java.management no longer requires > java.rmi or java.naming :-) > This is great! > Compared to previous version, then RMIExporter has been moved > to java.management.rmi, various module-info.java have been > cleaned up, some @modules in tests have been updated (mostly > due to the RMIExporter move). > > I have also improved some javadoc comments in JMXConnectorFactory.java > No changes in build files compared to webrev.05 > > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 Does java.management still depend on java.base/jdk.internal.module? > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html > Maybe the first sentence of @provides could be simplified to: A provider of JMXConnectorProvider for the RMI protocol. A provider of JMXConnectorServerProvider for the RMI protocol. Otherwise looks good. Mandy From daniel.fuchs at oracle.com Thu Feb 2 12:37:55 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 2 Feb 2017 12:37:55 +0000 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com> References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com> Message-ID: Hi Mandy, On 02/02/17 02:41, Mandy Chung wrote: >> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 > > Does java.management still depend on java.base/jdk.internal.module? Well spotted! It doesn't. I have updated module-info.java for java.base. http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07 >> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html >> > > Maybe the first sentence of @provides could be simplified to: > > A provider of JMXConnectorProvider for the RMI protocol. > A provider of JMXConnectorServerProvider for the RMI protocol. Done. But I think you meant A provider of JMXConnector[Server] for the RMI protocol. http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07/java.management.rmi-summary.html best regards, -- daniel > > Otherwise looks good. > Mandy > > > From mandy.chung at oracle.com Thu Feb 2 16:02:11 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Feb 2017 08:02:11 -0800 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com> Message-ID: > On Feb 2, 2017, at 4:37 AM, Daniel Fuchs wrote: > > Hi Mandy, > > On 02/02/17 02:41, Mandy Chung wrote: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 >> >> Does java.management still depend on java.base/jdk.internal.module? > > Well spotted! It doesn't. I have updated module-info.java for java.base. > > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07 Looks good. Mandy From daniel.fuchs at oracle.com Thu Feb 2 17:14:44 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 2 Feb 2017 17:14:44 +0000 Subject: Heads up: Fwd: hg: jdk9/dev/jdk: 8173607: JMX RMI connector should be in its own module In-Reply-To: <201702021653.v12GrvPL028871@aojmv0008.oracle.com> References: <201702021653.v12GrvPL028871@aojmv0008.oracle.com> Message-ID: <8e7a89d7-0db0-d610-2b70-2722ec8ddec0@oracle.com> Hi, A direct consequence of this change is that you may have to either blow up your ./build directory, or run 'make clean-java' after pulling this fix. Otherwise you may see strange build failures like below: Error occurred during initialization of VM java.lang.RuntimeException: Package com.sun.jmx.remote.protocol.rmi in both module java.management.rmi and module java.management at jdk.internal.module.ModuleBootstrap.fail(java.base/ModuleBootstrap.java:699) at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:329) at java.lang.System.initPhase2(java.base/System.java:1928) best regards, -- daniel -------------- next part -------------- An embedded message was scrubbed... From: daniel.fuchs at oracle.com Subject: hg: jdk9/dev/jdk: 8173607: JMX RMI connector should be in its own module Date: Thu, 02 Feb 2017 16:53:57 +0000 Size: 11018 URL: From daniel.fuchs at oracle.com Thu Feb 2 18:41:54 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 2 Feb 2017 18:41:54 +0000 Subject: RFR: 8173821: com.sun.jmx.remote.internal.Unmarshal should be removed. Message-ID: Hi, Please find below a trivial patch for: 8173821: com.sun.jmx.remote.internal.Unmarshal should be removed. https://bugs.openjdk.java.net/browse/JDK-8173821 It appears this interface was last referred to (import) in JDK 6, and last actually used in JDK 5. Now that it's hidden away by module boundaries anyway it may be time to retire it... http://cr.openjdk.java.net/~dfuchs/webrev_8173821/webrev.00/ best regards -- daniel From Alan.Bateman at oracle.com Thu Feb 2 18:44:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Feb 2017 18:44:53 +0000 Subject: RFR: 8173821: com.sun.jmx.remote.internal.Unmarshal should be removed. In-Reply-To: References: Message-ID: <6edf4d5f-5b2b-017f-4c0d-ee9b3bf82b21@oracle.com> On 02/02/2017 18:41, Daniel Fuchs wrote: > Hi, > > Please find below a trivial patch for: > > 8173821: com.sun.jmx.remote.internal.Unmarshal should be removed. > https://bugs.openjdk.java.net/browse/JDK-8173821 > > It appears this interface was last referred to (import) in JDK 6, > and last actually used in JDK 5. > Now that it's hidden away by module boundaries anyway it may be > time to retire it... > > http://cr.openjdk.java.net/~dfuchs/webrev_8173821/webrev.00/ Make sense to me. -Alan From sangheon.kim at oracle.com Thu Feb 2 19:11:43 2017 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 2 Feb 2017 11:11:43 -0800 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier Message-ID: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> Hi all, Could I have some reviews for this change that adds G1 pre-barrier? JvmtiTagHashmapEntry has a bare oop member and this is a weak reference. So any place that allows this oop to 'escape' needs the G1 pre-barrier. JvmtiEnv::GetObjectsWithTags() provides such an escape path. For G1, in order to maintain the SATB invariants, reading the referent of a weak reference must ensure the referent is marked alive. So this proposal includes adding the pre-barrier at TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I see the only place interacts(except 'peek' operations) with the bare oop member. As writing stable test could take some more time, Stefan Karlsson and I did some tests to provoke this problem. ( Stefan Karlsson kindly provided the test, http://cr.openjdk.java.net/~stefank/8173013/reproducer/ ) With this proposed patch, the problem goes away. CR: https://bugs.openjdk.java.net/browse/JDK-8173013 Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.0 Testing: JPRT, some closed tests which use JVMTI and JDI. Thanks, Sangheon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Feb 2 19:53:27 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Feb 2017 11:53:27 -0800 Subject: RFR: 8173821: com.sun.jmx.remote.internal.Unmarshal should be removed. In-Reply-To: References: Message-ID: <22AAA567-7ED0-42F6-8E60-C6F0969370C1@oracle.com> > On Feb 2, 2017, at 10:41 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a trivial patch for: > > 8173821: com.sun.jmx.remote.internal.Unmarshal should be removed. > https://bugs.openjdk.java.net/browse/JDK-8173821 > > It appears this interface was last referred to (import) in JDK 6, > and last actually used in JDK 5. > Now that it's hidden away by module boundaries anyway it may be > time to retire it... > > http://cr.openjdk.java.net/~dfuchs/webrev_8173821/webrev.00/ +1 Mandy From mandy.chung at oracle.com Thu Feb 2 22:27:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Feb 2017 14:27:52 -0800 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent Message-ID: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. Mandy From david.holmes at oracle.com Thu Feb 2 23:58:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Feb 2017 09:58:26 +1000 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: Hi Mandy, Looks reasonable. No tests that need changing? Thanks, David On 3/02/2017 8:27 AM, Mandy Chung wrote: > libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ > > This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. > > Mandy > From mandy.chung at oracle.com Fri Feb 3 00:03:59 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Feb 2017 16:03:59 -0800 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: <26A44B4D-56EB-4063-BEE3-09A607EB9032@oracle.com> > On Feb 2, 2017, at 3:58 PM, David Holmes wrote: > > Hi Mandy, > > Looks reasonable. > > No tests that need changing? > No since it?s just the shared library name change. The shared library provides the native method implementation for jdk.internal.agent.FileSystem (no change there) Mandy > Thanks, > David > > On 3/02/2017 8:27 AM, Mandy Chung wrote: >> libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ >> >> This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. >> >> Mandy >> From david.holmes at oracle.com Fri Feb 3 01:20:14 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Feb 2017 11:20:14 +1000 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> Message-ID: <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> Hi Sangheon, On 3/02/2017 5:11 AM, sangheon wrote: > Hi all, > > Could I have some reviews for this change that adds G1 pre-barrier? > > JvmtiTagHashmapEntry has a bare oop member and this is a weak reference. > So any place that allows this oop to 'escape' needs the G1 pre-barrier. > JvmtiEnv::GetObjectsWithTags() provides such an escape path. > > For G1, in order to maintain the SATB invariants, reading the referent > of a weak reference must ensure the referent is marked alive. > > So this proposal includes adding the pre-barrier at > TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I see > the only place interacts(except 'peek' operations) with the bare oop member. Pardon my GC ignorance but it seems odd to me that this barrier is inserted immediately before we create a local JNIHandle. Won't the JNIHandle ensure the object is seen as live? Thanks, David > As writing stable test could take some more time, Stefan Karlsson and I > did some tests to provoke this problem. > ( Stefan Karlsson kindly provided the test, > http://cr.openjdk.java.net/~stefank/8173013/reproducer/ > ) > With this proposed patch, the problem goes away. > > CR: https://bugs.openjdk.java.net/browse/JDK-8173013 > Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.0 > Testing: JPRT, some closed tests which use JVMTI and JDI. > > Thanks, > Sangheon > From sangheon.kim at oracle.com Fri Feb 3 04:00:53 2017 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 2 Feb 2017 20:00:53 -0800 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> Message-ID: Hi David, Thank you for looking at this! On 02/02/2017 05:20 PM, David Holmes wrote: > Hi Sangheon, > > On 3/02/2017 5:11 AM, sangheon wrote: >> Hi all, >> >> Could I have some reviews for this change that adds G1 pre-barrier? >> >> JvmtiTagHashmapEntry has a bare oop member and this is a weak reference. >> So any place that allows this oop to 'escape' needs the G1 pre-barrier. >> JvmtiEnv::GetObjectsWithTags() provides such an escape path. >> >> For G1, in order to maintain the SATB invariants, reading the referent >> of a weak reference must ensure the referent is marked alive. >> >> So this proposal includes adding the pre-barrier at >> TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I see >> the only place interacts(except 'peek' operations) with the bare oop >> member. > > Pardon my GC ignorance but it seems odd to me that this barrier is > inserted immediately before we create a local JNIHandle. Won't the > JNIHandle ensure the object is seen as live? Unfortunately it isn't. If we are using G1 and accessing the value of the referent field in a reference object then we need to register a non-null referent with the SATB barrier. In this code path, for example: (1) Object x is tagged. (2) x becomes unreachable, with the only remaining reference being the weak reference in the tag hashmap. (3) Concurrent GC starts and has completed marking, but has not yet entered the remark pause where reference processing occurs. (4) GetObjectsWithTags is used to obtain x. As reference processing has not yet run, x is still present in the tag hashmap. x remains unmarked, because there is no read(SATB) barrier on that access. (5) GC remark pause runs reference processing, determines x is dead, so clears the tag entry, and reuses the space previously occupied by x. (6) The GetObjectsWithTags result now refers to a dead and reclaimed x. A crash may follow. (From Kim Barrett's note) FYI, there are similar treatments already for this case. Plz, search for "G1SATBCardTableModRefBS::enqueue", especially Unsafe_GetObject(). I added this comment at the patch. Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.1 Thanks, Sangheon > > Thanks, > David > >> As writing stable test could take some more time, Stefan Karlsson and I >> did some tests to provoke this problem. >> ( Stefan Karlsson kindly provided the test, >> http://cr.openjdk.java.net/~stefank/8173013/reproducer/ >> ) >> With this proposed patch, the problem goes away. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8173013 >> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.0 >> Testing: JPRT, some closed tests which use JVMTI and JDI. >> >> Thanks, >> Sangheon >> From Alan.Bateman at oracle.com Fri Feb 3 07:41:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 3 Feb 2017 07:41:59 +0000 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: <2886b79d-e238-aac9-e2a1-56b9e726d3ad@oracle.com> On 02/02/2017 22:27, Mandy Chung wrote: > libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ > > This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. > Looks good. -Alan From erik.joelsson at oracle.com Fri Feb 3 09:04:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Feb 2017 10:04:17 +0100 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: Looks good. /Erik On 2017-02-02 23:27, Mandy Chung wrote: > libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ > > This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. > > Mandy From daniel.fuchs at oracle.com Fri Feb 3 10:16:23 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 3 Feb 2017 10:16:23 +0000 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: +1 libmanagement_agent is indeed a better name :-) best regards, -- daniel On 02/02/17 22:27, Mandy Chung wrote: > libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ > > This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. > > Mandy > From thomas.schatzl at oracle.com Fri Feb 3 13:51:27 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 03 Feb 2017 14:51:27 +0100 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> Message-ID: <1486129887.2892.49.camel@oracle.com> Hi Sangheon, On Thu, 2017-02-02 at 20:00 -0800, sangheon wrote: > Hi David, > > Thank you for looking at this! > > On 02/02/2017 05:20 PM, David Holmes wrote: > > > > Hi Sangheon, > > > > On 3/02/2017 5:11 AM, sangheon wrote: > > > > > > Hi all, > > > > > > Could I have some reviews for this change that adds G1 pre- > > > barrier? > > > > > > JvmtiTagHashmapEntry has a bare oop member and this is a weak > > > reference. > > > So any place that allows this oop to 'escape' needs the G1 pre- > > > barrier. > > > JvmtiEnv::GetObjectsWithTags() provides such an escape path. > > > > > > For G1, in order to maintain the SATB invariants, reading the > > > referent > > > of a weak reference must ensure the referent is marked alive. > > > > > > So this proposal includes adding the pre-barrier at > > > TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I > > > see > > > the only place interacts(except 'peek' operations) with the bare > > > oop? > > > member. > > Pardon my GC ignorance but it seems odd to me that this barrier is? > > inserted immediately before we create a local JNIHandle. Won't the? > > JNIHandle ensure the object is seen as live? > Unfortunately it isn't. > > If we are using G1 and accessing the value of the referent field in a > reference object then we need to register a non-null referent with > the SATB barrier. > > In this code path, for example: > > (1) Object x is tagged. > (2) x becomes unreachable, with the only remaining reference being > the weak reference in the tag hashmap. > (3) Concurrent GC starts and has completed marking, but has not yet? > entered the remark pause where reference processing occurs. > (4) GetObjectsWithTags is used to obtain x. As reference processing > has not yet run, x is still present in the tag hashmap. x remains > unmarked, because there is no read(SATB) barrier on that access. > (5) GC remark pause runs reference processing, determines x is dead, > so clears the tag entry, and reuses the space previously occupied by > x. > (6) The GetObjectsWithTags result now refers to a dead and reclaimed > x.? > A crash may follow. > (From Kim Barrett's note) > > FYI, there are similar treatments already for this case. > Plz, search for "G1SATBCardTableModRefBS::enqueue", especially? > Unsafe_GetObject(). > > I added this comment at the patch. > Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.1 1539?????????// We could be accessing the referent field in a reference 1540?????????// object. If G1 is enabled then we need to register non- null 1541?????????// referent with the SATB barrier. I do not think this comment is complete, or at least I do not see why the object in question needs to be a "referent field in a reference". Maybe you meant that the tag map entry acts similar to the referent of a j.l.ref.WeakReference, so we need to handle it the same as when a thread accesses a weak reference in normal java code (i.e. the read barrier). As the problem description above indicates, this can occur with any reference to an object where the tag map has the only (implicitly weak) reference to as far as I can see. I.e. maybe something like: "The reference in this tag map could be the only (implicitly weak) reference to that object. If we hand it out we need to keep it live wrt SATB marking similar to other j.l.ref.Reference referents." Probably others can provide a better description. Otherwise it seems good. esses? Thanks, ? Thomas From sangheon.kim at oracle.com Fri Feb 3 18:41:44 2017 From: sangheon.kim at oracle.com (sangheon) Date: Fri, 3 Feb 2017 10:41:44 -0800 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: <1486129887.2892.49.camel@oracle.com> References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <1486129887.2892.49.camel@oracle.com> Message-ID: <36da56ec-9add-89ad-59ce-84a85eb875a3@oracle.com> Hi Thomas, On 02/03/2017 05:51 AM, Thomas Schatzl wrote: > Hi Sangheon, > > On Thu, 2017-02-02 at 20:00 -0800, sangheon wrote: >> Hi David, >> >> Thank you for looking at this! >> >> On 02/02/2017 05:20 PM, David Holmes wrote: >>> Hi Sangheon, >>> >>> On 3/02/2017 5:11 AM, sangheon wrote: >>>> Hi all, >>>> >>>> Could I have some reviews for this change that adds G1 pre- >>>> barrier? >>>> >>>> JvmtiTagHashmapEntry has a bare oop member and this is a weak >>>> reference. >>>> So any place that allows this oop to 'escape' needs the G1 pre- >>>> barrier. >>>> JvmtiEnv::GetObjectsWithTags() provides such an escape path. >>>> >>>> For G1, in order to maintain the SATB invariants, reading the >>>> referent >>>> of a weak reference must ensure the referent is marked alive. >>>> >>>> So this proposal includes adding the pre-barrier at >>>> TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I >>>> see >>>> the only place interacts(except 'peek' operations) with the bare >>>> oop >>>> member. >>> Pardon my GC ignorance but it seems odd to me that this barrier is >>> inserted immediately before we create a local JNIHandle. Won't the >>> JNIHandle ensure the object is seen as live? >> Unfortunately it isn't. >> >> If we are using G1 and accessing the value of the referent field in a >> reference object then we need to register a non-null referent with >> the SATB barrier. >> >> In this code path, for example: >> >> (1) Object x is tagged. >> (2) x becomes unreachable, with the only remaining reference being >> the weak reference in the tag hashmap. >> (3) Concurrent GC starts and has completed marking, but has not yet >> entered the remark pause where reference processing occurs. >> (4) GetObjectsWithTags is used to obtain x. As reference processing >> has not yet run, x is still present in the tag hashmap. x remains >> unmarked, because there is no read(SATB) barrier on that access. >> (5) GC remark pause runs reference processing, determines x is dead, >> so clears the tag entry, and reuses the space previously occupied by >> x. >> (6) The GetObjectsWithTags result now refers to a dead and reclaimed >> x. >> A crash may follow. >> (From Kim Barrett's note) >> >> FYI, there are similar treatments already for this case. >> Plz, search for "G1SATBCardTableModRefBS::enqueue", especially >> Unsafe_GetObject(). >> >> I added this comment at the patch. >> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.1 > 1539 // We could be accessing the referent field in a reference > 1540 // object. If G1 is enabled then we need to register non- > null > 1541 // referent with the SATB barrier. > > I do not think this comment is complete, or at least I do not see why > the object in question needs to be a "referent field in a reference". > Maybe you meant that the tag map entry acts similar to the referent of > a j.l.ref.WeakReference, so we need to handle it the same as when a > thread accesses a weak reference in normal java code (i.e. the read > barrier). Thank you for correctly understanding what I wanted to say. > > As the problem description above indicates, this can occur with any > reference to an object where the tag map has the only (implicitly weak) > reference to as far as I can see. > > I.e. maybe something like: > > "The reference in this tag map could be the only (implicitly weak) > reference to that object. If we hand it out we need to keep it live wrt > SATB marking similar to other j.l.ref.Reference referents." I like this comment. If other reviewers don't have better suggestion, I will upload the revised patch with this. Thanks, Sangheon > > Probably others can provide a better description. > > Otherwise it seems good. > > esses > > Thanks, > Thomas From kim.barrett at oracle.com Fri Feb 3 21:05:21 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 3 Feb 2017 16:05:21 -0500 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: <36da56ec-9add-89ad-59ce-84a85eb875a3@oracle.com> References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <1486129887.2892.49.camel@oracle.com> <36da56ec-9add-89ad-59ce-84a85eb875a3@oracle.com> Message-ID: > On Feb 3, 2017, at 1:41 PM, sangheon wrote: >> "The reference in this tag map could be the only (implicitly weak) >> reference to that object. If we hand it out we need to keep it live wrt >> SATB marking similar to other j.l.ref.Reference referents." > I like this comment. > If other reviewers don't have better suggestion, I will upload the revised patch with this. Looks good with something like Thomas's improved comment. From sangheon.kim at oracle.com Fri Feb 3 21:10:00 2017 From: sangheon.kim at oracle.com (sangheon) Date: Fri, 3 Feb 2017 13:10:00 -0800 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <1486129887.2892.49.camel@oracle.com> <36da56ec-9add-89ad-59ce-84a85eb875a3@oracle.com> Message-ID: Hi Kim, On 02/03/2017 01:05 PM, Kim Barrett wrote: >> On Feb 3, 2017, at 1:41 PM, sangheon wrote: >>> "The reference in this tag map could be the only (implicitly weak) >>> reference to that object. If we hand it out we need to keep it live wrt >>> SATB marking similar to other j.l.ref.Reference referents." >> I like this comment. >> If other reviewers don't have better suggestion, I will upload the revised patch with this. > Looks good with something like Thomas's improved comment. > Thanks for the review and all the discussion for this CR. And Thomas' comment is the candidate for now. Sangheon From yasuenag at gmail.com Sun Feb 5 14:25:16 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 5 Feb 2017 23:25:16 +0900 Subject: SA does not work if executable is DSO Message-ID: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> Hi all, In modern Linux e.g. Fedora 25, executables are built as DSO for security [1]. java command in OpenJDK which is provided by distribution is also DSO. However, SA does not work with DSO executables. I want to propose the fix as below. ------------------------ diff -r a26b9492461b src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c --- a/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Wed Feb 01 17:56:22 2017 -0500 +++ b/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Sun Feb 05 23:13:19 2017 +0900 @@ -642,6 +642,9 @@ if (core_handle_prstatus(ph, descdata, notep->n_descsz) != true) { return false; } + } else if (notep->n_type == NT_FILE) { + // Skip "count", "page_size" in NT_FILE + memcpy(&ph->core->dynamic_addr, ((long *)descdata) + 2, sizeof(long)); } p = descdata + ROUNDUP(notep->n_descsz, 4); } @@ -832,7 +835,11 @@ // from PT_DYNAMIC we want to read address of first link_map addr case PT_DYNAMIC: { - ph->core->dynamic_addr = exec_php->p_vaddr; + if (exec_ehdr->e_type == ET_EXEC) { + ph->core->dynamic_addr = exec_php->p_vaddr; + } else { // ET_DYN + ph->core->dynamic_addr += exec_php->p_offset; + } print_debug("address of _DYNAMIC is 0x%lx\n", ph->core->dynamic_addr); break; } @@ -1030,8 +1037,9 @@ goto err; } - if (read_elf_header(ph->core->exec_fd, &exec_ehdr) != true || exec_ehdr.e_type != ET_EXEC) { - print_debug("executable file is not a valid ELF ET_EXEC file\n"); + if (read_elf_header(ph->core->exec_fd, &exec_ehdr) != true || + ((exec_ehdr.e_type != ET_EXEC) && (exec_ehdr.e_type != ET_DYN))) { + print_debug("executable file is not a valid ELF file\n"); goto err; } ------------------------ Currently, OpenJDK 8 in Fedora25 is built as DSO. So I want to contribute this patch to JDK 8 or later release. Can I file it to JBS and can send review request? Thanks, Yasumasa [1] https://fedoraproject.org/wiki/Packaging:Guidelines#PIE From yasuenag at gmail.com Sun Feb 5 15:16:30 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 6 Feb 2017 00:16:30 +0900 Subject: SA does not work if executable is DSO In-Reply-To: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> Message-ID: <7286cef2-3172-04a5-a6be-5e1ee4d158e7@gmail.com> I filed it to JBS as JDK-8173941. Yasumasa On 2017/02/05 23:25, Yasumasa Suenaga wrote: > Hi all, > > In modern Linux e.g. Fedora 25, executables are built as DSO for security [1]. > java command in OpenJDK which is provided by distribution is also DSO. > However, SA does not work with DSO executables. > > I want to propose the fix as below. > > ------------------------ > diff -r a26b9492461b src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > --- a/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Wed Feb 01 17:56:22 2017 -0500 > +++ b/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Sun Feb 05 23:13:19 2017 +0900 > @@ -642,6 +642,9 @@ > if (core_handle_prstatus(ph, descdata, notep->n_descsz) != true) { > return false; > } > + } else if (notep->n_type == NT_FILE) { > + // Skip "count", "page_size" in NT_FILE > + memcpy(&ph->core->dynamic_addr, ((long *)descdata) + 2, sizeof(long)); > } > p = descdata + ROUNDUP(notep->n_descsz, 4); > } > @@ -832,7 +835,11 @@ > > // from PT_DYNAMIC we want to read address of first link_map addr > case PT_DYNAMIC: { > - ph->core->dynamic_addr = exec_php->p_vaddr; > + if (exec_ehdr->e_type == ET_EXEC) { > + ph->core->dynamic_addr = exec_php->p_vaddr; > + } else { // ET_DYN > + ph->core->dynamic_addr += exec_php->p_offset; > + } > print_debug("address of _DYNAMIC is 0x%lx\n", ph->core->dynamic_addr); > break; > } > @@ -1030,8 +1037,9 @@ > goto err; > } > > - if (read_elf_header(ph->core->exec_fd, &exec_ehdr) != true || exec_ehdr.e_type != ET_EXEC) { > - print_debug("executable file is not a valid ELF ET_EXEC file\n"); > + if (read_elf_header(ph->core->exec_fd, &exec_ehdr) != true || > + ((exec_ehdr.e_type != ET_EXEC) && (exec_ehdr.e_type != ET_DYN))) { > + print_debug("executable file is not a valid ELF file\n"); > goto err; > } > > ------------------------ > > Currently, OpenJDK 8 in Fedora25 is built as DSO. > So I want to contribute this patch to JDK 8 or later release. > > Can I file it to JBS and can send review request? > > > Thanks, > > Yasumasa > > > [1] https://fedoraproject.org/wiki/Packaging:Guidelines#PIE From mandy.chung at oracle.com Mon Feb 6 00:29:06 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 5 Feb 2017 16:29:06 -0800 Subject: Review Request: JDK-8173947: jconsole does not show local running VMs to attach Message-ID: sun.management.ConnectorAddressLink is renamed to jdk.internal.agent.ConnectorAddressLink but missed the Class.forName call in JConsole. Thanks to Peter catching this regression. Since jdk.jconsole requires jdk.attach and jdk.management.agent that guarantees the classes required are present at runtime, so we can drop the Class.forName calls. I leave the isLocalAttachAvailable() method there to keep the current implementation that supports to run even if the local attach is not supported. Mandy diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java b/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java --- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java +++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java @@ -949,23 +949,12 @@ } } - private static final boolean localAttachmentSupported; - static { - boolean supported; - try { - Class.forName("com.sun.tools.attach.VirtualMachine"); - Class.forName("sun.management.ConnectorAddressLink"); - supported = true; - } catch (NoClassDefFoundError x) { - supported = false; - } catch (ClassNotFoundException x) { - supported = false; - } - localAttachmentSupported = supported; - } - + /** + * local attach is supported in this implementation as jdk.jconsole + * requires jdk.attach and jdk.management.agent + */ public static boolean isLocalAttachAvailable() { - return localAttachmentSupported; + return true; } From david.holmes at oracle.com Mon Feb 6 03:05:31 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Feb 2017 13:05:31 +1000 Subject: Review Request: JDK-8173947: jconsole does not show local running VMs to attach In-Reply-To: References: Message-ID: Looks fine to me Mandy. Thanks, David On 6/02/2017 10:29 AM, Mandy Chung wrote: > sun.management.ConnectorAddressLink is renamed to jdk.internal.agent.ConnectorAddressLink but missed the Class.forName call in JConsole. Thanks to Peter catching this regression. Since jdk.jconsole requires jdk.attach and jdk.management.agent that guarantees the classes required are present at runtime, so we can drop the Class.forName calls. > > I leave the isLocalAttachAvailable() method there to keep the current implementation that supports to run even if the local attach is not supported. > > Mandy > > diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java b/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java > --- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java > +++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java > @@ -949,23 +949,12 @@ > } > } > > - private static final boolean localAttachmentSupported; > - static { > - boolean supported; > - try { > - Class.forName("com.sun.tools.attach.VirtualMachine"); > - Class.forName("sun.management.ConnectorAddressLink"); > - supported = true; > - } catch (NoClassDefFoundError x) { > - supported = false; > - } catch (ClassNotFoundException x) { > - supported = false; > - } > - localAttachmentSupported = supported; > - } > - > + /** > + * local attach is supported in this implementation as jdk.jconsole > + * requires jdk.attach and jdk.management.agent > + */ > public static boolean isLocalAttachAvailable() { > - return localAttachmentSupported; > + return true; > } > > > From david.holmes at oracle.com Mon Feb 6 03:19:13 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Feb 2017 13:19:13 +1000 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> Message-ID: <36dad25a-7879-0729-3963-8baddef70efe@oracle.com> Hi Sangheon, On 3/02/2017 2:00 PM, sangheon wrote: > Hi David, > > Thank you for looking at this! > > On 02/02/2017 05:20 PM, David Holmes wrote: >> Hi Sangheon, >> >> On 3/02/2017 5:11 AM, sangheon wrote: >>> Hi all, >>> >>> Could I have some reviews for this change that adds G1 pre-barrier? >>> >>> JvmtiTagHashmapEntry has a bare oop member and this is a weak reference. >>> So any place that allows this oop to 'escape' needs the G1 pre-barrier. >>> JvmtiEnv::GetObjectsWithTags() provides such an escape path. >>> >>> For G1, in order to maintain the SATB invariants, reading the referent >>> of a weak reference must ensure the referent is marked alive. >>> >>> So this proposal includes adding the pre-barrier at >>> TagObjectCollector::do_entry(JvmtiTagHashmapEntry* entry) which I see >>> the only place interacts(except 'peek' operations) with the bare oop >>> member. >> >> Pardon my GC ignorance but it seems odd to me that this barrier is >> inserted immediately before we create a local JNIHandle. Won't the >> JNIHandle ensure the object is seen as live? > Unfortunately it isn't. > > If we are using G1 and accessing the value of the referent field in a > reference object then we need to register a non-null referent with the > SATB barrier. > > In this code path, for example: > > (1) Object x is tagged. > (2) x becomes unreachable, with the only remaining reference being the > weak reference in the tag hashmap. > (3) Concurrent GC starts and has completed marking, but has not yet > entered the remark pause where reference processing occurs. > (4) GetObjectsWithTags is used to obtain x. As reference processing has > not yet run, x is still present in the tag hashmap. x remains unmarked, > because there is no read(SATB) barrier on that access. > (5) GC remark pause runs reference processing, determines x is dead, so > clears the tag entry, and reuses the space previously occupied by x. > (6) The GetObjectsWithTags result now refers to a dead and reclaimed x. > A crash may follow. > (From Kim Barrett's note) > > FYI, there are similar treatments already for this case. > Plz, search for "G1SATBCardTableModRefBS::enqueue", especially > Unsafe_GetObject(). Thanks for explaining. I must say that I find this treatment rather ad-hoc as we seem to be discovering by trial-and-error where these places occur. I would have hoped this was all encapsulated within the weakreference code itself (in this case). Does the SATB occur at a global safepoint? David > I added this comment at the patch. > Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.1 > > Thanks, > Sangheon > > >> >> Thanks, >> David >> >>> As writing stable test could take some more time, Stefan Karlsson and I >>> did some tests to provoke this problem. >>> ( Stefan Karlsson kindly provided the test, >>> http://cr.openjdk.java.net/~stefank/8173013/reproducer/ >>> ) >>> With this proposed patch, the problem goes away. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8173013 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8173013/webrev.0 >>> Testing: JPRT, some closed tests which use JVMTI and JDI. >>> >>> Thanks, >>> Sangheon >>> > From sangheon.kim at oracle.com Mon Feb 6 06:10:51 2017 From: sangheon.kim at oracle.com (sangheon) Date: Sun, 5 Feb 2017 22:10:51 -0800 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <1486129887.2892.49.camel@oracle.com> <36da56ec-9add-89ad-59ce-84a85eb875a3@oracle.com> Message-ID: Hi Kim and Thomas, Here's webrev.2 with Thomas' comment version. http://cr.openjdk.java.net/~sangheki/8173013/webrev.2 -------------------- 1538 #if INCLUDE_ALL_GCS 1539 if (UseG1GC) { 1540 // The reference in this tag map could be the only (implicitly weak) 1541 // reference to that object. If we hand it out, we need to keep it live wrt 1542 // SATB marking similar to other j.l.ref.Reference referents. 1543 G1SATBCardTableModRefBS::enqueue(o); 1544 } 1545 #endif -------------------- Thanks, Sangheon On 02/03/2017 01:10 PM, sangheon wrote: > Hi Kim, > > On 02/03/2017 01:05 PM, Kim Barrett wrote: >>> On Feb 3, 2017, at 1:41 PM, sangheon wrote: >>>> "The reference in this tag map could be the only (implicitly weak) >>>> reference to that object. If we hand it out we need to keep it live >>>> wrt >>>> SATB marking similar to other j.l.ref.Reference referents." >>> I like this comment. >>> If other reviewers don't have better suggestion, I will upload the >>> revised patch with this. >> Looks good with something like Thomas's improved comment. >> > Thanks for the review and all the discussion for this CR. > And Thomas' comment is the candidate for now. > > Sangheon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Mon Feb 6 06:17:41 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 6 Feb 2017 01:17:41 -0500 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <1486129887.2892.49.camel@oracle.com> <36da56ec-9add-89ad-59ce-84a85eb875a3@oracle.com> Message-ID: <04B5F1BB-0E5F-4F12-9D0A-C0AEBDC1C13C@oracle.com> > On Feb 6, 2017, at 1:10 AM, sangheon wrote: > > Hi Kim and Thomas, > > Here's webrev.2 with Thomas' comment version. > http://cr.openjdk.java.net/~sangheki/8173013/webrev.2 > > -------------------- > 1538 #if INCLUDE_ALL_GCS > 1539 if (UseG1GC) { > 1540 // The reference in this tag map could be the only (implicitly weak) > 1541 // reference to that object. If we hand it out, we need to keep it live wrt > 1542 // SATB marking similar to other j.l.ref.Reference referents. > 1543 G1SATBCardTableModRefBS::enqueue(o); > 1544 } > 1545 #endif > ?????????? Looks good. > > Thanks, > Sangheon > > > On 02/03/2017 01:10 PM, sangheon wrote: >> Hi Kim, >> >> On 02/03/2017 01:05 PM, Kim Barrett wrote: >>>> On Feb 3, 2017, at 1:41 PM, sangheon wrote: >>>>> "The reference in this tag map could be the only (implicitly weak) >>>>> reference to that object. If we hand it out we need to keep it live wrt >>>>> SATB marking similar to other j.l.ref.Reference referents." >>>> I like this comment. >>>> If other reviewers don't have better suggestion, I will upload the revised patch with this. >>> Looks good with something like Thomas's improved comment. >>> >> Thanks for the review and all the discussion for this CR. >> And Thomas' comment is the candidate for now. >> >> Sangheon From Alan.Bateman at oracle.com Mon Feb 6 06:42:45 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Feb 2017 06:42:45 +0000 Subject: Review Request: JDK-8173947: jconsole does not show local running VMs to attach In-Reply-To: References: Message-ID: <029f3243-3938-7892-1d57-600915d9d68b@oracle.com> On 06/02/2017 00:29, Mandy Chung wrote: > sun.management.ConnectorAddressLink is renamed to jdk.internal.agent.ConnectorAddressLink but missed the Class.forName call in JConsole. Thanks to Peter catching this regression. Since jdk.jconsole requires jdk.attach and jdk.management.agent that guarantees the classes required are present at runtime, so we can drop the Class.forName calls. > > I leave the isLocalAttachAvailable() method there to keep the current implementation that supports to run even if the local attach is not supported. > This looks okay to me. -Alan From thomas.schatzl at oracle.com Mon Feb 6 09:22:44 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 06 Feb 2017 10:22:44 +0100 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: <04B5F1BB-0E5F-4F12-9D0A-C0AEBDC1C13C@oracle.com> References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <1486129887.2892.49.camel@oracle.com> <36da56ec-9add-89ad-59ce-84a85eb875a3@oracle.com> <04B5F1BB-0E5F-4F12-9D0A-C0AEBDC1C13C@oracle.com> Message-ID: <1486372964.2950.0.camel@oracle.com> Hi, On Mon, 2017-02-06 at 01:17 -0500, Kim Barrett wrote: > > > > On Feb 6, 2017, at 1:10 AM, sangheon > > wrote: > > > > Hi Kim and Thomas, > > > > Here's webrev.2 with Thomas' comment version. > > http://cr.openjdk.java.net/~sangheki/8173013/webrev.2 > > > > -------------------- > > 1538 #if INCLUDE_ALL_GCS > > 1539?????????if (UseG1GC) { > > 1540???????????// The reference in this tag map could be the only > > (implicitly weak) > > 1541???????????// reference to that object. If we hand it out, we > > need to keep it live wrt > > 1542???????????// SATB marking similar to other j.l.ref.Reference > > referents. > > 1543???????????G1SATBCardTableModRefBS::enqueue(o); > > 1544?????????} > > 1545 #endif > > ?????????? > Looks good. ? looks good. Ship it. Thomas From daniel.fuchs at oracle.com Mon Feb 6 09:42:27 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 6 Feb 2017 09:42:27 +0000 Subject: Review Request: JDK-8173947: jconsole does not show local running VMs to attach In-Reply-To: References: Message-ID: +1 regards, -- daniel On 06/02/17 00:29, Mandy Chung wrote: > sun.management.ConnectorAddressLink is renamed to jdk.internal.agent.ConnectorAddressLink but missed the Class.forName call in JConsole. Thanks to Peter catching this regression. Since jdk.jconsole requires jdk.attach and jdk.management.agent that guarantees the classes required are present at runtime, so we can drop the Class.forName calls. > > I leave the isLocalAttachAvailable() method there to keep the current implementation that supports to run even if the local attach is not supported. > > Mandy > > diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java b/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java > --- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java > +++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/JConsole.java > @@ -949,23 +949,12 @@ > } > } > > - private static final boolean localAttachmentSupported; > - static { > - boolean supported; > - try { > - Class.forName("com.sun.tools.attach.VirtualMachine"); > - Class.forName("sun.management.ConnectorAddressLink"); > - supported = true; > - } catch (NoClassDefFoundError x) { > - supported = false; > - } catch (ClassNotFoundException x) { > - supported = false; > - } > - localAttachmentSupported = supported; > - } > - > + /** > + * local attach is supported in this implementation as jdk.jconsole > + * requires jdk.attach and jdk.management.agent > + */ > public static boolean isLocalAttachAvailable() { > - return localAttachmentSupported; > + return true; > } > > > From kim.barrett at oracle.com Mon Feb 6 22:46:32 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 6 Feb 2017 17:46:32 -0500 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: <36dad25a-7879-0729-3963-8baddef70efe@oracle.com> References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <36dad25a-7879-0729-3963-8baddef70efe@oracle.com> Message-ID: > On Feb 5, 2017, at 10:19 PM, David Holmes wrote: > Thanks for explaining. I must say that I find this treatment rather ad-hoc as we seem to be discovering by trial-and-error where these places occur. I would have hoped this was all encapsulated within the weakreference code itself (in this case). The GC team is taking a hard look at weak reference handling, as part of preparing for some improvements we are considering. That's turned up some holes that probably should have been dealt with as part of productizing G1, but seem to have gone unnoticed until recently. For now we're patching over these holes. I expect some cleanup tasks for JDK 10; we're not happy with this littering of otherwise generic runtime code with G1-specific stuff. OTOH, I have to say that some of the abstraction violations I'm finding around jobject, Handle, and oop* in non-GC code are not helpful. > Does the SATB occur at a global safepoint? SATB is the approach G1 uses for a part of concurrent collection. It defines the invariants that must be maintained by the mutator so that the collector can find all the live objects. The barriers in question are executed by the mutator concurrently with the collector, in order to inform the collector of reachability graph modifications. From david.holmes at oracle.com Tue Feb 7 03:44:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Feb 2017 13:44:26 +1000 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <36dad25a-7879-0729-3963-8baddef70efe@oracle.com> Message-ID: <50755ead-1281-df4c-c03e-1d355bcc41c8@oracle.com> Hi Kim, On 7/02/2017 8:46 AM, Kim Barrett wrote: >> On Feb 5, 2017, at 10:19 PM, David Holmes wrote: >> Thanks for explaining. I must say that I find this treatment rather ad-hoc as we seem to be discovering by trial-and-error where these places occur. I would have hoped this was all encapsulated within the weakreference code itself (in this case). > > The GC team is taking a hard look at weak reference handling, as part > of preparing for some improvements we are considering. That's turned > up some holes that probably should have been dealt with as part of > productizing G1, but seem to have gone unnoticed until recently. > > For now we're patching over these holes. I expect some cleanup tasks > for JDK 10; we're not happy with this littering of otherwise generic > runtime code with G1-specific stuff. OTOH, I have to say that some of > the abstraction violations I'm finding around jobject, Handle, and > oop* in non-GC code are not helpful. Ok. Understood. >> Does the SATB occur at a global safepoint? > > SATB is the approach G1 uses for a part of concurrent collection. It > defines the invariants that must be maintained by the mutator so that > the collector can find all the live objects. The barriers in question > are executed by the mutator concurrently with the collector, in order > to inform the collector of reachability graph modifications. Is that a "no"? :) I don't understand how the barriers operate in relation to concurrent actions by the GC. To take the current case, what prevents the GC from deciding that the referent is garbage and can deleted, before the enqueue is called? I assumed a safepoint had to be involved somewhere so that the sequence of actions: extract, enqueue, store, was atomic with respect to the GC. Thanks, David From aph at redhat.com Tue Feb 7 10:14:32 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Feb 2017 10:14:32 +0000 Subject: SA does not work if executable is DSO In-Reply-To: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> Message-ID: <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> On 05/02/17 14:25, Yasumasa Suenaga wrote: > In modern Linux e.g. Fedora 25, executables are built as DSO for security [1]. > java command in OpenJDK which is provided by distribution is also DSO. > However, SA does not work with DSO executables. > > I want to propose the fix as below. Please explain what steps are needed to reproduce this problem. What commands did you use? Thanks, Andrew. From yasuenag at gmail.com Tue Feb 7 10:29:58 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 7 Feb 2017 19:29:58 +0900 Subject: SA does not work if executable is DSO In-Reply-To: <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> Message-ID: <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> Hi Andrew, You can build PIE binaries with files which are provided by redhat-rpm-config as below: ``` $ bash configure --with-native-debug-symbols=internal --enable-debug --disable-warnings-as-errors --disable-hotspot-gtest --with-extra-cflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 --with-extra-cxxflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 --with-extra-ldflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-ld $ make images ``` If you use OpenJDK 8 in Fedora 25, you can reproduce as below: 1. Run Java App with OpenJDK I use java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64 2. Collect core images via gcore $ gcore 3. Run jstack with LIBSAPROC_DEBUG ``` $ LIBSAPROC_DEBUG=1 jstack /usr/lib/jvm/java-1.8.0-open jdk-1.8.0.121-1.b14.fc25.x86_64/bin/java core.1031 Attaching to core core.1031 from executable /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/bin/java, please wait... libsaproc DEBUG: executable file is not a valid ELF ET_EXEC file Error attaching to core file: Can't attach to the core file sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method) : ``` Thanks, Yasumasa On 2017/02/07 19:14, Andrew Haley wrote: > On 05/02/17 14:25, Yasumasa Suenaga wrote: > >> In modern Linux e.g. Fedora 25, executables are built as DSO for security [1]. >> java command in OpenJDK which is provided by distribution is also DSO. >> However, SA does not work with DSO executables. >> >> I want to propose the fix as below. > > Please explain what steps are needed to reproduce this problem. What > commands did you use? > > Thanks, > > Andrew. > > From kim.barrett at oracle.com Wed Feb 8 07:00:41 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 8 Feb 2017 02:00:41 -0500 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: <50755ead-1281-df4c-c03e-1d355bcc41c8@oracle.com> References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <36dad25a-7879-0729-3963-8baddef70efe@oracle.com> <50755ead-1281-df4c-c03e-1d355bcc41c8@oracle.com> Message-ID: > On Feb 6, 2017, at 10:44 PM, David Holmes wrote: >>> Does the SATB occur at a global safepoint? >> >> SATB is the approach G1 uses for a part of concurrent collection. It >> defines the invariants that must be maintained by the mutator so that >> the collector can find all the live objects. The barriers in question >> are executed by the mutator concurrently with the collector, in order >> to inform the collector of reachability graph modifications. > > Is that a "no"? :) I don't understand how the barriers operate in relation to concurrent actions by the GC. To take the current case, what prevents the GC from deciding that the referent is garbage and can deleted, before the enqueue is called? I assumed a safepoint had to be involved somewhere so that the sequence of actions: extract, enqueue, store, was atomic with respect to the GC. To be more precise, the barriers in question are executed by the mutator concurrently with the marking phase of the collector. Once marking is (mostly) complete, G1 safepoints and performs various tasks, including reference processing. The barrier must be atomic wrto that safepoint (which is accomplished by not allowing any safepoints during the barrier execution). So yes, the sequence of extract and enqueue are atomic wrto the relevant part of the GC. From aph at redhat.com Wed Feb 8 11:46:30 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Feb 2017 11:46:30 +0000 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> Message-ID: <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> Okay, thanks. The patch will have to be submitted to JDK 9 first and then back- ported to earlier releases. Unfortunately it doesn't work on JDK 9. I don't know why: I spent some time looking at it, but I couldn't figure out what was wrong. Is there any way you could have a look? This is using hg.openjdk.java.net/jdk9/hs on F25. Thanks, Andrew. [aph at localhost hs-8173941]$ LIBSAPROC_DEBUG=1 ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb jstack --core core.63600 --exe build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java Attaching to core core.63600 from executable build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java, please wait... libsaproc DEBUG: Note header with n_type = 3 and n_descsz = 136 libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 336 libsaproc DEBUG: got integer regset for lwp 63600 libsaproc DEBUG: integer regset ... libsaproc DEBUG: Note address of NT_FILE is 0x564be32e5000 libsaproc DEBUG: ELF interpreter /lib64/ld-linux-x86-64.so.2 libsaproc DEBUG: address of _DYNAMIC p_vaddr is 0x201d28 libsaproc DEBUG: address of _DYNAMIC is 0x564be32e6d28 libsaproc DEBUG: ---- sorted virtual address map ---- ... libsaproc DEBUG: base = 0x7fe62227c000 size = 4096 libsaproc DEBUG: base = 0x7ffeabb33000 size = 135168 libsaproc DEBUG: base = 0x7ffeabbc0000 size = 8192 libsaproc DEBUG: base = 0xffffffffff600000 size = 4096 libsaproc DEBUG: can't locate map_info at 0x564be32e7000 libsaproc DEBUG: core read failed for 16 byte(s) @ 0x564be32e7000 (8 more bytes) libsaproc DEBUG: 1: can't read debug info from _DYNAMIC Error attaching to core file: Can't attach to the core file sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:286) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:679) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:617) From yasuenag at gmail.com Wed Feb 8 14:21:44 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 8 Feb 2017 23:21:44 +0900 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> Message-ID: <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> Hi Andrew, I could reproduce it in my environment. * libsaproc debug ``` libsaproc DEBUG: address of _DYNAMIC is 0x563bc6dd8d28 ``` * Address of .dynamic in GDB ``` 0x0000563bc6dd7d28 - 0x0000563bc6dd7f68 is .dynamic ``` It differs 1 page (0x1000). In this case, according to GDB, `java` was loaded 0x563bc6dd7000. According to readelf of `java`, offset of dynamic section is 0x1d28. So I want to investigate why we found 1 memory page difference. (Is it caused by ASLR? Do you have any idea?) Thanks, Yasumasa On 2017/02/08 20:46, Andrew Haley wrote: > Okay, thanks. > > The patch will have to be submitted to JDK 9 first and then back- > ported to earlier releases. Unfortunately it doesn't work on JDK 9. > I don't know why: I spent some time looking at it, but I couldn't > figure out what was wrong. > > Is there any way you could have a look? This is using hg.openjdk.java.net/jdk9/hs > on F25. > > Thanks, > > Andrew. > > > [aph at localhost hs-8173941]$ LIBSAPROC_DEBUG=1 ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb jstack --core core.63600 --exe build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java > Attaching to core core.63600 from executable build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java, please wait... > libsaproc DEBUG: Note header with n_type = 3 and n_descsz = 136 > libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 336 > libsaproc DEBUG: got integer regset for lwp 63600 > libsaproc DEBUG: integer regset > ... > libsaproc DEBUG: Note address of NT_FILE is 0x564be32e5000 > libsaproc DEBUG: ELF interpreter /lib64/ld-linux-x86-64.so.2 > libsaproc DEBUG: address of _DYNAMIC p_vaddr is 0x201d28 > libsaproc DEBUG: address of _DYNAMIC is 0x564be32e6d28 > libsaproc DEBUG: ---- sorted virtual address map ---- > ... > libsaproc DEBUG: base = 0x7fe62227c000 size = 4096 > libsaproc DEBUG: base = 0x7ffeabb33000 size = 135168 > libsaproc DEBUG: base = 0x7ffeabbc0000 size = 8192 > libsaproc DEBUG: base = 0xffffffffff600000 size = 4096 > libsaproc DEBUG: can't locate map_info at 0x564be32e7000 > libsaproc DEBUG: core read failed for 16 byte(s) @ 0x564be32e7000 (8 more bytes) > libsaproc DEBUG: 1: can't read debug info from _DYNAMIC > Error attaching to core file: Can't attach to the core file > sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:286) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:679) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:617) > From aph at redhat.com Wed Feb 8 15:10:25 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Feb 2017 15:10:25 +0000 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> Message-ID: On 08/02/17 14:21, Yasumasa Suenaga wrote: > It differs 1 page (0x1000). > In this case, according to GDB, `java` was loaded 0x563bc6dd7000. > According to readelf of `java`, offset of dynamic section is 0x1d28. > So I want to investigate why we found 1 memory page difference. > (Is it caused by ASLR? Do you have any idea?) I don't. GDB manages to find it in the right place, so I suppose that there must be some clue in GDB, but that's all I know. Andrew. From amy.lu at oracle.com Thu Feb 9 09:32:27 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 9 Feb 2017 17:32:27 +0800 Subject: JDK 9 RFR for JDK-8174241: ProblemList update for TestWsImport, JdbMethodExitTest and jimage tests Message-ID: <91db090f-0b77-381b-a261-55334f32a8e4@oracle.com> Please review the ProblemList.txt cleanup on updating bugid for several tests. javax/xml/ws/clientjar/TestWsImport.java 8170370 generic-all This test is in ProblemList, related bug JDK-8170370 has been resolved. Test is going to be revisited in JDK-8173317 tools/jimage/JImageExtractTest.java 8169713 generic-all tools/jimage/JImageListTest.java 8169713 generic-all tools/jimage/JImageVerifyTest.java 8169713 generic-all Mentioned bug JDK-8169713 has been closed, while test is going to be fixed in JDK-8170120 com/sun/jdi/JdbMethodExitTest.sh 6902121 generic-all Mentioned bug JDK-6902121 has been closed, test is going to be revisited in JDK-8171483 Thanks, Amy --- old/test/ProblemList.txt 2017-02-09 17:28:52.000000000 +0800 +++ new/test/ProblemList.txt 2017-02-09 17:28:51.000000000 +0800 @@ -253,9 +253,9 @@ tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all -tools/jimage/JImageExtractTest.java 8169713 generic-all -tools/jimage/JImageListTest.java 8169713 generic-all -tools/jimage/JImageVerifyTest.java 8169713 generic-all +tools/jimage/JImageExtractTest.java 8170120 generic-all +tools/jimage/JImageListTest.java 8170120 generic-all +tools/jimage/JImageVerifyTest.java 8170120 generic-all tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java 8169971 windows-x64 @@ -266,7 +266,7 @@ com/sun/jdi/RedefineImplementor.sh 8004127 generic-all -com/sun/jdi/JdbMethodExitTest.sh 6902121 generic-all +com/sun/jdi/JdbMethodExitTest.sh 8171483 generic-all com/sun/jdi/RepStep.java 8043571 generic-all @@ -307,6 +307,6 @@ javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all -javax/xml/ws/clientjar/TestWsImport.java 8170370 generic-all +javax/xml/ws/clientjar/TestWsImport.java 8173317 generic-all ############################################################################ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Thu Feb 9 12:23:06 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 9 Feb 2017 07:23:06 -0500 Subject: JDK 9 RFR for JDK-8174241: ProblemList update for TestWsImport, JdbMethodExitTest and jimage tests In-Reply-To: <91db090f-0b77-381b-a261-55334f32a8e4@oracle.com> References: <91db090f-0b77-381b-a261-55334f32a8e4@oracle.com> Message-ID: +1 > On Feb 9, 2017, at 4:32 AM, Amy Lu wrote: > > Please review the ProblemList.txt cleanup on updating bugid for several tests. > > javax/xml/ws/clientjar/TestWsImport.java 8170370 generic-all > This test is in ProblemList, related bug JDK-8170370 has been resolved. Test is going to be revisited in JDK-8173317 > > tools/jimage/JImageExtractTest.java 8169713 generic-all > tools/jimage/JImageListTest.java 8169713 generic-all > tools/jimage/JImageVerifyTest.java 8169713 generic-all > Mentioned bug JDK-8169713 has been closed, while test is going to be fixed in JDK-8170120 > > com/sun/jdi/JdbMethodExitTest.sh 6902121 generic-all > Mentioned bug JDK-6902121 has been closed, test is going to be revisited in JDK-8171483 > > Thanks, > Amy > > > > --- old/test/ProblemList.txt 2017-02-09 17:28:52.000000000 +0800 > +++ new/test/ProblemList.txt 2017-02-09 17:28:51.000000000 +0800 > @@ -253,9 +253,9 @@ > tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all > -tools/jimage/JImageExtractTest.java 8169713 generic-all > -tools/jimage/JImageListTest.java 8169713 generic-all > -tools/jimage/JImageVerifyTest.java 8169713 generic-all > +tools/jimage/JImageExtractTest.java 8170120 generic-all > +tools/jimage/JImageListTest.java 8170120 generic-all > +tools/jimage/JImageVerifyTest.java 8170120 generic-all > tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java 8169971 windows-x64 > @@ -266,7 +266,7 @@ > com/sun/jdi/RedefineImplementor.sh 8004127 generic-all > -com/sun/jdi/JdbMethodExitTest.sh 6902121 generic-all > +com/sun/jdi/JdbMethodExitTest.sh 8171483 generic-all > com/sun/jdi/RepStep.java 8043571 generic-all > @@ -307,6 +307,6 @@ > javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all > -javax/xml/ws/clientjar/TestWsImport.java 8170370 generic-all > +javax/xml/ws/clientjar/TestWsImport.java 8173317 generic-all > ############################################################################ > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From yasuenag at gmail.com Thu Feb 9 14:40:19 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 9 Feb 2017 23:40:19 +0900 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> Message-ID: Hi Andrew, I checked with GDB, readelf and libsaproc debug message. I found that we should calculate .dynamic address from entry point in ELF. I uploaded webrev. This patch works fine on JDK 9 and JDK 10. http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.00/ Thanks, Yasumasa On 2017/02/08 23:21, Yasumasa Suenaga wrote: > Hi Andrew, > > I could reproduce it in my environment. > > > * libsaproc debug > ``` > libsaproc DEBUG: address of _DYNAMIC is 0x563bc6dd8d28 > ``` > > * Address of .dynamic in GDB > ``` > 0x0000563bc6dd7d28 - 0x0000563bc6dd7f68 is .dynamic > ``` > > It differs 1 page (0x1000). > In this case, according to GDB, `java` was loaded 0x563bc6dd7000. > According to readelf of `java`, offset of dynamic section is 0x1d28. > So I want to investigate why we found 1 memory page difference. > (Is it caused by ASLR? Do you have any idea?) > > > Thanks, > > Yasumasa > > > On 2017/02/08 20:46, Andrew Haley wrote: >> Okay, thanks. >> >> The patch will have to be submitted to JDK 9 first and then back- >> ported to earlier releases. Unfortunately it doesn't work on JDK 9. >> I don't know why: I spent some time looking at it, but I couldn't >> figure out what was wrong. >> >> Is there any way you could have a look? This is using hg.openjdk.java.net/jdk9/hs >> on F25. >> >> Thanks, >> >> Andrew. >> >> >> [aph at localhost hs-8173941]$ LIBSAPROC_DEBUG=1 ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb jstack --core core.63600 --exe build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java >> Attaching to core core.63600 from executable build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java, please wait... >> libsaproc DEBUG: Note header with n_type = 3 and n_descsz = 136 >> libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 336 >> libsaproc DEBUG: got integer regset for lwp 63600 >> libsaproc DEBUG: integer regset >> ... >> libsaproc DEBUG: Note address of NT_FILE is 0x564be32e5000 >> libsaproc DEBUG: ELF interpreter /lib64/ld-linux-x86-64.so.2 >> libsaproc DEBUG: address of _DYNAMIC p_vaddr is 0x201d28 >> libsaproc DEBUG: address of _DYNAMIC is 0x564be32e6d28 >> libsaproc DEBUG: ---- sorted virtual address map ---- >> ... >> libsaproc DEBUG: base = 0x7fe62227c000 size = 4096 >> libsaproc DEBUG: base = 0x7ffeabb33000 size = 135168 >> libsaproc DEBUG: base = 0x7ffeabbc0000 size = 8192 >> libsaproc DEBUG: base = 0xffffffffff600000 size = 4096 >> libsaproc DEBUG: can't locate map_info at 0x564be32e7000 >> libsaproc DEBUG: core read failed for 16 byte(s) @ 0x564be32e7000 (8 more bytes) >> libsaproc DEBUG: 1: can't read debug info from _DYNAMIC >> Error attaching to core file: Can't attach to the core file >> sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:286) >> at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:679) >> at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:617) >> From aph at redhat.com Thu Feb 9 14:49:32 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Feb 2017 14:49:32 +0000 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> Message-ID: On 09/02/17 14:40, Yasumasa Suenaga wrote: > Hi Andrew, > > I checked with GDB, readelf and libsaproc debug message. > I found that we should calculate .dynamic address from entry point in ELF. > > I uploaded webrev. This patch works fine on JDK 9 and JDK 10. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.00/ Very cool, thanks! One clarification: + // Align page size + ph->core->dynamic_addr = auxv->a_un.a_val & ~(uintptr_t)0xfff; I guess this isn't the physical page size, but some notional 4k page, which may or may not correspond to the real page size? Thanks, Andrew. From yasuenag at gmail.com Thu Feb 9 14:57:22 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 9 Feb 2017 23:57:22 +0900 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> Message-ID: <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> > I guess this isn't the physical page size, but some notional 4k page, > which may or may not correspond to the real page size? I think we should use sysconf(3) with _SC_PAGESIZE or p_align in ELF PHDR. > + // Align page size > + ph->core->dynamic_addr = auxv->a_un.a_val & ~(uintptr_t)0xfff; We cannot access ELF PHDR of executable. So I think we can use sysconf(3) to get page size. Should I change it and upload new webrev? Yasumasa On 2017/02/09 23:49, Andrew Haley wrote: > On 09/02/17 14:40, Yasumasa Suenaga wrote: >> Hi Andrew, >> >> I checked with GDB, readelf and libsaproc debug message. >> I found that we should calculate .dynamic address from entry point in ELF. >> >> I uploaded webrev. This patch works fine on JDK 9 and JDK 10. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.00/ > > Very cool, thanks! > > One clarification: > > + // Align page size > + ph->core->dynamic_addr = auxv->a_un.a_val & ~(uintptr_t)0xfff; > > I guess this isn't the physical page size, but some notional 4k page, > which may or may not correspond to the real page size? > > Thanks, > > Andrew. > From aph at redhat.com Thu Feb 9 16:04:31 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Feb 2017 16:04:31 +0000 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> Message-ID: On 09/02/17 14:57, Yasumasa Suenaga wrote: > So I think we can use sysconf(3) to get page size. In OpenJDK code we should use os::vm_page_size() for the physical page size. Andrew. From sangheon.kim at oracle.com Thu Feb 9 18:54:55 2017 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 9 Feb 2017 10:54:55 -0800 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <36dad25a-7879-0729-3963-8baddef70efe@oracle.com> <50755ead-1281-df4c-c03e-1d355bcc41c8@oracle.com> Message-ID: Hi David, If you don't have any other questions/comments, can I proceed to push? Kim, thank you very much for the all explanations. Thanks, Sangheon On 02/07/2017 11:00 PM, Kim Barrett wrote: >> On Feb 6, 2017, at 10:44 PM, David Holmes wrote: >>>> Does the SATB occur at a global safepoint? >>> SATB is the approach G1 uses for a part of concurrent collection. It >>> defines the invariants that must be maintained by the mutator so that >>> the collector can find all the live objects. The barriers in question >>> are executed by the mutator concurrently with the collector, in order >>> to inform the collector of reachability graph modifications. >> Is that a "no"? :) I don't understand how the barriers operate in relation to concurrent actions by the GC. To take the current case, what prevents the GC from deciding that the referent is garbage and can deleted, before the enqueue is called? I assumed a safepoint had to be involved somewhere so that the sequence of actions: extract, enqueue, store, was atomic with respect to the GC. > To be more precise, the barriers in question are executed by the > mutator concurrently with the marking phase of the collector. Once > marking is (mostly) complete, G1 safepoints and performs various > tasks, including reference processing. The barrier must be atomic > wrto that safepoint (which is accomplished by not allowing any > safepoints during the barrier execution). So yes, the sequence of > extract and enqueue are atomic wrto the relevant part of the GC. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Thu Feb 9 22:53:12 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 Feb 2017 07:53:12 +0900 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> Message-ID: On 2017/02/10 1:04, Andrew Haley wrote: > On 09/02/17 14:57, Yasumasa Suenaga wrote: >> So I think we can use sysconf(3) to get page size. > > In OpenJDK code we should use os::vm_page_size() for the physical page > size. SA is not part of HotSpot (not in libjvm). Thus SA cannot access HotSpot internal function. > Andrew. > From david.holmes at oracle.com Fri Feb 10 00:32:10 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Feb 2017 10:32:10 +1000 Subject: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier In-Reply-To: References: <32c27cb2-2341-450f-a783-d24ae194ce83@oracle.com> <15fedfc6-aa77-0c3e-e362-baf8ffedb5af@oracle.com> <36dad25a-7879-0729-3963-8baddef70efe@oracle.com> <50755ead-1281-df4c-c03e-1d355bcc41c8@oracle.com> Message-ID: On 10/02/2017 4:54 AM, sangheon wrote: > Hi David, > > If you don't have any other questions/comments, can I proceed to push? Sorry - yes, of course. > Kim, thank you very much for the all explanations. Yes much appreciated! Thanks, David > Thanks, > Sangheon > > > On 02/07/2017 11:00 PM, Kim Barrett wrote: >>> On Feb 6, 2017, at 10:44 PM, David Holmes wrote: >>>>> Does the SATB occur at a global safepoint? >>>> SATB is the approach G1 uses for a part of concurrent collection. It >>>> defines the invariants that must be maintained by the mutator so that >>>> the collector can find all the live objects. The barriers in question >>>> are executed by the mutator concurrently with the collector, in order >>>> to inform the collector of reachability graph modifications. >>> Is that a "no"? :) I don't understand how the barriers operate in relation to concurrent actions by the GC. To take the current case, what prevents the GC from deciding that the referent is garbage and can deleted, before the enqueue is called? I assumed a safepoint had to be involved somewhere so that the sequence of actions: extract, enqueue, store, was atomic with respect to the GC. >> To be more precise, the barriers in question are executed by the >> mutator concurrently with the marking phase of the collector. Once >> marking is (mostly) complete, G1 safepoints and performs various >> tasks, including reference processing. The barrier must be atomic >> wrto that safepoint (which is accomplished by not allowing any >> safepoints during the barrier execution). So yes, the sequence of >> extract and enqueue are atomic wrto the relevant part of the GC. >> >> > From yasuenag at gmail.com Fri Feb 10 03:13:36 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 Feb 2017 12:13:36 +0900 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> Message-ID: Hi Andrew, We can calculate start address of executable (java command) through entry point. I updated webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ This patch can ignore page size. Thanks, Yasumasa 2017-02-10 7:53 GMT+09:00 Yasumasa Suenaga : > On 2017/02/10 1:04, Andrew Haley wrote: > >> On 09/02/17 14:57, Yasumasa Suenaga wrote: >> >>> So I think we can use sysconf(3) to get page size. >>> >> >> In OpenJDK code we should use os::vm_page_size() for the physical page >> size. >> > > SA is not part of HotSpot (not in libjvm). > Thus SA cannot access HotSpot internal function. > > Andrew. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Fri Feb 10 09:40:22 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Feb 2017 09:40:22 +0000 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> Message-ID: <270af19e-e0f5-1ea4-02a1-69c13259df28@redhat.com> On 10/02/17 03:13, Yasumasa Suenaga wrote: > We can calculate start address of executable (java command) through entry > point. > I updated webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ > > This patch can ignore page size. Excellent. I think this is safe for JDK 9, but there may be some argument about whether we'll be able to get it in now. I'm happy to approve it, but I guess we should appeal to hotspot-dev and see what people say. Andrew. From volker.simonis at gmail.com Fri Feb 10 13:21:07 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 10 Feb 2017 14:21:07 +0100 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: <270af19e-e0f5-1ea4-02a1-69c13259df28@redhat.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> <270af19e-e0f5-1ea4-02a1-69c13259df28@redhat.com> Message-ID: On Fri, Feb 10, 2017 at 10:40 AM, Andrew Haley wrote: > On 10/02/17 03:13, Yasumasa Suenaga wrote: >> We can calculate start address of executable (java command) through entry >> point. >> I updated webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ >> >> This patch can ignore page size. > > Excellent. I think this is safe for JDK 9, but there may be some > argument about whether we'll be able to get it in now. I'm happy to > approve it, but I guess we should appeal to hotspot-dev and see what > people say. > I haven't looked at this change in full detail until now so this is not a review. But the change looks reasonable and non-intrusive so I strongly support its integration into jdk9. It also doesn't touch the libjvm.so which means it can't introduce any harm. Second, it's good to see that somebody cares for the SA tools. It would be nice if somebody from the SA team could have a look at this and sponsor it. @Andrew: as this bug is assigned to you, I'd suggest to change it's status to open, the priority to P3 and target it for 9 (i.e. Fix Version = 9). Regards, Volker > Andrew. > From aph at redhat.com Fri Feb 10 13:44:11 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Feb 2017 13:44:11 +0000 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> <270af19e-e0f5-1ea4-02a1-69c13259df28@redhat.com> Message-ID: <69ace0dc-f6ed-ebd6-0188-745b9207e53d@redhat.com> On 10/02/17 13:21, Volker Simonis wrote: > @Andrew: as this bug is assigned to you, I'd suggest to change it's > status to open, the priority to P3 and target it for 9 (i.e. Fix > Version = 9). OK, done. It should really not be assigned to me, but the rather inscrutable JIRA doesn't let me move it back to Yasumasa. Andrew. From yasuenag at gmail.com Fri Feb 10 14:15:09 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 Feb 2017 23:15:09 +0900 Subject: RFR: 8173941: SA does not work if executable is DSO Message-ID: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> Hi all, In modern Linux e.g. Fedora 25, executables are built as DSO for security [1]. java command in OpenJDK which is provided by distribution is also DSO. However, SA does not work with DSO executables. I uploaded a webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ I discussed about this issue with Andrew in mail thread [2], and this webrev has been reviewed by him. We need one or more reviewer. Could you review it? Currently, OpenJDK 8 in Fedora 25 is built as DSO. So I want to contribute this patch to JDK 8 or later release. I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] https://fedoraproject.org/wiki/Packaging:Guidelines#PIE [2] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-February/020940.html From aph at redhat.com Fri Feb 10 14:16:28 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Feb 2017 14:16:28 +0000 Subject: RFR: 8173941: SA does not work if executable is DSO In-Reply-To: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> References: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> Message-ID: <9263a5ed-b677-6bb2-faa1-3074b1aa9e8c@redhat.com> On 10/02/17 14:15, Yasumasa Suenaga wrote: > We need one or more reviewer. Could you review it? We don't need another reviewer. We need a sponsor to put it through JPRT. Andrew. From dmitry.samersoff at oracle.com Fri Feb 10 14:41:40 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 10 Feb 2017 17:41:40 +0300 Subject: RFR: 8173941: SA does not work if executable is DSO In-Reply-To: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> References: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> Message-ID: Yasumasa, Changes looks good to me. I'll sponsor the push. -Dmitry On 2017-02-10 17:15, Yasumasa Suenaga wrote: > Hi all, > > In modern Linux e.g. Fedora 25, executables are built as DSO for > security [1]. > java command in OpenJDK which is provided by distribution is also DSO. > However, SA does not work with DSO executables. > > I uploaded a webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ > > I discussed about this issue with Andrew in mail thread [2], and this > webrev has been reviewed by him. > We need one or more reviewer. Could you review it? > > > Currently, OpenJDK 8 in Fedora 25 is built as DSO. > So I want to contribute this patch to JDK 8 or later release. > > I cannot access JPRT. So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] https://fedoraproject.org/wiki/Packaging:Guidelines#PIE > [2] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-February/020940.html > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Fri Feb 10 14:55:16 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 Feb 2017 23:55:16 +0900 Subject: RFR: 8173941: SA does not work if executable is DSO In-Reply-To: References: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> Message-ID: Thanks Dmitry! Should I send a changeset to you for JDK 9? or JDK 10? Yasumasa On 2017/02/10 23:41, Dmitry Samersoff wrote: > Yasumasa, > > Changes looks good to me. > > I'll sponsor the push. > > -Dmitry > > On 2017-02-10 17:15, Yasumasa Suenaga wrote: >> Hi all, >> >> In modern Linux e.g. Fedora 25, executables are built as DSO for >> security [1]. >> java command in OpenJDK which is provided by distribution is also DSO. >> However, SA does not work with DSO executables. >> >> I uploaded a webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ >> >> I discussed about this issue with Andrew in mail thread [2], and this >> webrev has been reviewed by him. >> We need one or more reviewer. Could you review it? >> >> >> Currently, OpenJDK 8 in Fedora 25 is built as DSO. >> So I want to contribute this patch to JDK 8 or later release. >> >> I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://fedoraproject.org/wiki/Packaging:Guidelines#PIE >> [2] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-February/020940.html >> > > From volker.simonis at gmail.com Fri Feb 10 15:03:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 10 Feb 2017 16:03:18 +0100 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: <69ace0dc-f6ed-ebd6-0188-745b9207e53d@redhat.com> References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> <270af19e-e0f5-1ea4-02a1-69c13259df28@redhat.com> <69ace0dc-f6ed-ebd6-0188-745b9207e53d@redhat.com> Message-ID: On Fri, Feb 10, 2017 at 2:44 PM, Andrew Haley wrote: > On 10/02/17 13:21, Volker Simonis wrote: >> @Andrew: as this bug is assigned to you, I'd suggest to change it's >> status to open, the priority to P3 and target it for 9 (i.e. Fix >> Version = 9). > > OK, done. It should really not be assigned to me, but the rather > inscrutable JIRA doesn't let me move it back to Yasumasa. > I've done it for you :) You have press the "Assign" button in the upper-left corner and select the new owner from the drop-down list. I think you can also start typing a name and it will auto-complete. > Andrew. > From jini.george at oracle.com Sat Feb 11 12:32:55 2017 From: jini.george at oracle.com (Jini George) Date: Sat, 11 Feb 2017 18:02:55 +0530 Subject: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client Message-ID: Could I pls get reviews done for the SA testbug: https://bugs.openjdk.java.net/browse/JDK-8173896 Webrev: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.00/ Thanks, Jini. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Feb 13 00:06:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2017 10:06:11 +1000 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> <270af19e-e0f5-1ea4-02a1-69c13259df28@redhat.com> Message-ID: Hi Volker, On 10/02/2017 11:21 PM, Volker Simonis wrote: > On Fri, Feb 10, 2017 at 10:40 AM, Andrew Haley wrote: >> On 10/02/17 03:13, Yasumasa Suenaga wrote: >>> We can calculate start address of executable (java command) through entry >>> point. >>> I updated webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ >>> >>> This patch can ignore page size. >> >> Excellent. I think this is safe for JDK 9, but there may be some >> argument about whether we'll be able to get it in now. I'm happy to >> approve it, but I guess we should appeal to hotspot-dev and see what >> people say. >> > > I haven't looked at this change in full detail until now so this is > not a review. But the change looks reasonable and non-intrusive so I > strongly support its integration into jdk9. I don't know this code or the issue being addressed, but I have run this through your JPRT testing just to make sure there are no surprises. I'm a bit unclear on the problem being fixed - do I take it that Oracle JDK binaries are not built as DSO's and so do not experience this problem? Is there a reasonable way to test this (is it covered by any existing tests) ? Thanks, David ----- > It also doesn't touch the libjvm.so which means it can't introduce any > harm. Second, it's good to see that somebody cares for the SA tools. > It would be nice if somebody from the SA team could have a look at > this and sponsor it. > > @Andrew: as this bug is assigned to you, I'd suggest to change it's > status to open, the priority to P3 and target it for 9 (i.e. Fix > Version = 9). > > Regards, > Volker > > >> Andrew. >> From david.holmes at oracle.com Mon Feb 13 00:19:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2017 10:19:12 +1000 Subject: (trivial) RFR: 8174798: Mis-merge left serviceability/sa/TestCpoolForInvokeDynamic.java ignored Message-ID: <8ae8b416-2926-221d-c3e6-1e2552cd5d8b@oracle.com> Planning to push under trivial rules so just need one Reviewer please. Bug: https://bugs.openjdk.java.net/browse/JDK-8174798 Stumbled on this by accident. This test should no longer be ignored, but somehow the removal of the @ignore was lost in a Merge. webrev: http://cr.openjdk.java.net/~dholmes/8174798/webrev/ Patch below. Thanks, David --- old/test/serviceability/sa/TestCpoolForInvokeDynamic.java 2017-02-12 19:08:58.969198177 -0500 +++ new/test/serviceability/sa/TestCpoolForInvokeDynamic.java 2017-02-12 19:08:57.005084892 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -51,7 +51,6 @@ * jdk.hotspot.agent/sun.jvm.hotspot.oops * jdk.hotspot.agent/sun.jvm.hotspot.debugger * jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser - * @ignore 8169232 * @run main/othervm TestCpoolForInvokeDynamic */ From daniel.daugherty at oracle.com Mon Feb 13 00:46:56 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 12 Feb 2017 17:46:56 -0700 Subject: (trivial) RFR: 8174798: Mis-merge left serviceability/sa/TestCpoolForInvokeDynamic.java ignored In-Reply-To: <8ae8b416-2926-221d-c3e6-1e2552cd5d8b@oracle.com> References: <8ae8b416-2926-221d-c3e6-1e2552cd5d8b@oracle.com> Message-ID: <05590fb3-5412-46d8-b440-711a5ed875b5@oracle.com> Thumbs up! Dan On 2/12/17 5:19 PM, David Holmes wrote: > Planning to push under trivial rules so just need one Reviewer please. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174798 > > Stumbled on this by accident. This test should no longer be ignored, > but somehow the removal of the @ignore was lost in a Merge. > > webrev: http://cr.openjdk.java.net/~dholmes/8174798/webrev/ > > Patch below. > > Thanks, > David > > --- old/test/serviceability/sa/TestCpoolForInvokeDynamic.java > 2017-02-12 19:08:58.969198177 -0500 > +++ new/test/serviceability/sa/TestCpoolForInvokeDynamic.java > 2017-02-12 19:08:57.005084892 -0500 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -51,7 +51,6 @@ > * jdk.hotspot.agent/sun.jvm.hotspot.oops > * jdk.hotspot.agent/sun.jvm.hotspot.debugger > * jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser > - * @ignore 8169232 > * @run main/othervm TestCpoolForInvokeDynamic > */ > From david.holmes at oracle.com Mon Feb 13 01:09:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2017 11:09:51 +1000 Subject: RFR: 8173941: SA does not work if executable is DSO In-Reply-To: <9263a5ed-b677-6bb2-faa1-3074b1aa9e8c@redhat.com> References: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> <9263a5ed-b677-6bb2-faa1-3074b1aa9e8c@redhat.com> Message-ID: Hi Yasumasa, Please don't start new email threads on the same topic just to add a cc. I've added to the existing thread and that is now missed on this new one! It makes it hard to track comments, reviews and outstanding issues. serviceability-dev was the correct mailing list for this change, there was no need to also send to hotspot-dev. On 11/02/2017 12:16 AM, Andrew Haley wrote: > On 10/02/17 14:15, Yasumasa Suenaga wrote: >> We need one or more reviewer. Could you review it? > > We don't need another reviewer. We need a sponsor to put it > through JPRT. For hotspot changes we do prefer at least 2 reviews (though only 1 need be a Reviewer). The rules are not clearly documented anywhere that I can see. Based on this: http://openjdk.java.net/guide/changePlanning.html "Changeset pushes before the Feature Complete require at least one Reviewer; pushes after the Feature Complete require at least two Reviewers. In either case, the more the merrier. Some teams may require more Reviewers. Check with members of the Project." we need two Reviewers after FC, but I don't think anyone has been aware of and enforcing that! David ----- > Andrew. > From david.holmes at oracle.com Mon Feb 13 01:20:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2017 11:20:15 +1000 Subject: (trivial) RFR: 8174798: Mis-merge left serviceability/sa/TestCpoolForInvokeDynamic.java ignored In-Reply-To: <05590fb3-5412-46d8-b440-711a5ed875b5@oracle.com> References: <8ae8b416-2926-221d-c3e6-1e2552cd5d8b@oracle.com> <05590fb3-5412-46d8-b440-711a5ed875b5@oracle.com> Message-ID: <0840a454-9ee5-ab5b-5b0c-34af73de7e20@oracle.com> Thanks Dan! Pushing now. David On 13/02/2017 10:46 AM, Daniel D. Daugherty wrote: > Thumbs up! > > Dan > > > > On 2/12/17 5:19 PM, David Holmes wrote: >> Planning to push under trivial rules so just need one Reviewer please. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8174798 >> >> Stumbled on this by accident. This test should no longer be ignored, >> but somehow the removal of the @ignore was lost in a Merge. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8174798/webrev/ >> >> Patch below. >> >> Thanks, >> David >> >> --- old/test/serviceability/sa/TestCpoolForInvokeDynamic.java >> 2017-02-12 19:08:58.969198177 -0500 >> +++ new/test/serviceability/sa/TestCpoolForInvokeDynamic.java >> 2017-02-12 19:08:57.005084892 -0500 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -51,7 +51,6 @@ >> * jdk.hotspot.agent/sun.jvm.hotspot.oops >> * jdk.hotspot.agent/sun.jvm.hotspot.debugger >> * jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser >> - * @ignore 8169232 >> * @run main/othervm TestCpoolForInvokeDynamic >> */ >> > From yasuenag at gmail.com Mon Feb 13 03:02:07 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 13 Feb 2017 12:02:07 +0900 Subject: RFR: 8173941: SA does not work if executable is DSO In-Reply-To: References: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> <9263a5ed-b677-6bb2-faa1-3074b1aa9e8c@redhat.com> Message-ID: Hi David, Sorry for my incorrect mail thread. For this issue, I already got two reviewers: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-February/020968.html http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-February/020973.html Yasumasa 2017-02-13 10:09 GMT+09:00 David Holmes : > Hi Yasumasa, > > Please don't start new email threads on the same topic just to add a cc. > I've added to the existing thread and that is now missed on this new one! > It makes it hard to track comments, reviews and outstanding issues. > serviceability-dev was the correct mailing list for this change, there was > no need to also send to hotspot-dev. > > On 11/02/2017 12:16 AM, Andrew Haley wrote: > >> On 10/02/17 14:15, Yasumasa Suenaga wrote: >> >>> We need one or more reviewer. Could you review it? >>> >> >> We don't need another reviewer. We need a sponsor to put it >> through JPRT. >> > > For hotspot changes we do prefer at least 2 reviews (though only 1 need be > a Reviewer). The rules are not clearly documented anywhere that I can see. > Based on this: > > http://openjdk.java.net/guide/changePlanning.html > > "Changeset pushes before the Feature Complete require at least one > Reviewer; pushes after the Feature Complete require at least two Reviewers. > In either case, the more the merrier. Some teams may require more > Reviewers. Check with members of the Project." > > we need two Reviewers after FC, but I don't think anyone has been aware of > and enforcing that! > > David > ----- > > > Andrew. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Feb 13 03:29:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2017 13:29:15 +1000 Subject: RFR: 8173941: SA does not work if executable is DSO In-Reply-To: References: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> <9263a5ed-b677-6bb2-faa1-3074b1aa9e8c@redhat.com> Message-ID: <63b324ef-dd57-e815-f270-0a602cc66de1@oracle.com> On 13/02/2017 1:02 PM, Yasumasa Suenaga wrote: > Hi David, > > Sorry for my incorrect mail thread. > > For this issue, I already got two reviewers: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-February/020968.html > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-February/020973.html Yes. But please see my queries on the original thread. Thanks, David > > Yasumasa > > > 2017-02-13 10:09 GMT+09:00 David Holmes >: > > Hi Yasumasa, > > Please don't start new email threads on the same topic just to add a > cc. I've added to the existing thread and that is now missed on this > new one! It makes it hard to track comments, reviews and outstanding > issues. serviceability-dev was the correct mailing list for this > change, there was no need to also send to hotspot-dev. > > On 11/02/2017 12:16 AM, Andrew Haley wrote: > > On 10/02/17 14:15, Yasumasa Suenaga wrote: > > We need one or more reviewer. Could you review it? > > > We don't need another reviewer. We need a sponsor to put it > through JPRT. > > > For hotspot changes we do prefer at least 2 reviews (though only 1 > need be a Reviewer). The rules are not clearly documented anywhere > that I can see. Based on this: > > http://openjdk.java.net/guide/changePlanning.html > > > "Changeset pushes before the Feature Complete require at least one > Reviewer; pushes after the Feature Complete require at least two > Reviewers. In either case, the more the merrier. Some teams may > require more Reviewers. Check with members of the Project." > > we need two Reviewers after FC, but I don't think anyone has been > aware of and enforcing that! > > David > ----- > > > Andrew. > > From yasuenag at gmail.com Mon Feb 13 03:54:51 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 13 Feb 2017 12:54:51 +0900 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> <270af19e-e0f5-1ea4-02a1-69c13259df28@redhat.com> Message-ID: Hi David, > I'm a bit unclear on the problem being fixed - do I take it that Oracle JDK binaries are not built as DSO's and so do not experience this problem? Is there a reasonable way to test this (is it covered by any existing tests) ? You cannot check this issue with Oracle JDK because it is not DSO (PIE). This fix is only confirmed with DSO (PIE) binaries. So I did not make testcase for this issue. You have to check with DSO build as below: ``` $ bash configure --with-native-debug-symbols=internal --enable-debug --disable-warnings-as-errors --disable-hotspot-gtest --with-extra-cflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 --with-extra-cxxflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 --with-extra-ldflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-ld $ make images ``` Thanks, Yasumasa 2017-02-13 9:06 GMT+09:00 David Holmes : > Hi Volker, > > On 10/02/2017 11:21 PM, Volker Simonis wrote: > >> On Fri, Feb 10, 2017 at 10:40 AM, Andrew Haley wrote: >> >>> On 10/02/17 03:13, Yasumasa Suenaga wrote: >>> >>>> We can calculate start address of executable (java command) through >>>> entry >>>> point. >>>> I updated webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ >>>> >>>> This patch can ignore page size. >>>> >>> >>> Excellent. I think this is safe for JDK 9, but there may be some >>> argument about whether we'll be able to get it in now. I'm happy to >>> approve it, but I guess we should appeal to hotspot-dev and see what >>> people say. >>> >>> >> I haven't looked at this change in full detail until now so this is >> not a review. But the change looks reasonable and non-intrusive so I >> strongly support its integration into jdk9. >> > > I don't know this code or the issue being addressed, but I have run this > through your JPRT testing just to make sure there are no surprises. > > I'm a bit unclear on the problem being fixed - do I take it that Oracle > JDK binaries are not built as DSO's and so do not experience this problem? > Is there a reasonable way to test this (is it covered by any existing > tests) ? > > Thanks, > David > ----- > > > It also doesn't touch the libjvm.so which means it can't introduce any >> harm. Second, it's good to see that somebody cares for the SA tools. >> It would be nice if somebody from the SA team could have a look at >> this and sponsor it. >> >> @Andrew: as this bug is assigned to you, I'd suggest to change it's >> status to open, the priority to P3 and target it for 9 (i.e. Fix >> Version = 9). >> >> Regards, >> Volker >> >> >> Andrew. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Feb 13 03:58:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2017 13:58:36 +1000 Subject: 8173941 Re: SA does not work if executable is DSO In-Reply-To: References: <5ba1b87e-0611-2d76-09c2-5a522cae19f0@gmail.com> <770e1898-4fda-23e8-11f5-e6ca1da1a5d7@redhat.com> <26927bfa-a44b-a8b5-3548-5e3611ea0db3@gmail.com> <888a2371-5fc3-2967-2fa1-746291645f2a@redhat.com> <1d22d915-3640-400e-06c0-7523665a5362@gmail.com> <68d32d81-27c7-fa12-e997-840f4ccd1186@gmail.com> <270af19e-e0f5-1ea4-02a1-69c13259df28@redhat.com> Message-ID: On 13/02/2017 1:54 PM, Yasumasa Suenaga wrote: > Hi David, > >> I'm a bit unclear on the problem being fixed - do I take it that > Oracle JDK binaries are not built as DSO's and so do not experience this > problem? Is there a reasonable way to test this (is it covered by any > existing tests) ? > > You cannot check this issue with Oracle JDK because it is not DSO (PIE). > This fix is only confirmed with DSO (PIE) binaries. > So I did not make testcase for this issue. > > You have to check with DSO build as below: > > ``` > $ bash configure --with-native-debug-symbols=internal --enable-debug --disable-warnings-as-errors --disable-hotspot-gtest --with-extra-cflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 --with-extra-cxxflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 --with-extra-ldflags=-specs=/usr/lib/rpm/redhat/redhat-hardened-ld > $ make images > ``` Ok. Thanks. David > > Thanks, > > Yasumasa > > > 2017-02-13 9:06 GMT+09:00 David Holmes >: > > Hi Volker, > > On 10/02/2017 11:21 PM, Volker Simonis wrote: > > On Fri, Feb 10, 2017 at 10:40 AM, Andrew Haley > wrote: > > On 10/02/17 03:13, Yasumasa Suenaga wrote: > > We can calculate start address of executable (java > command) through entry > point. > I updated webrev: > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ > > > This patch can ignore page size. > > > Excellent. I think this is safe for JDK 9, but there may be > some > argument about whether we'll be able to get it in now. I'm > happy to > approve it, but I guess we should appeal to hotspot-dev and > see what > people say. > > > I haven't looked at this change in full detail until now so this is > not a review. But the change looks reasonable and non-intrusive so I > strongly support its integration into jdk9. > > > I don't know this code or the issue being addressed, but I have run > this through your JPRT testing just to make sure there are no surprises. > > I'm a bit unclear on the problem being fixed - do I take it that > Oracle JDK binaries are not built as DSO's and so do not experience > this problem? Is there a reasonable way to test this (is it covered > by any existing tests) ? > > Thanks, > David > ----- > > > It also doesn't touch the libjvm.so which means it can't > introduce any > harm. Second, it's good to see that somebody cares for the SA tools. > It would be nice if somebody from the SA team could have a look at > this and sponsor it. > > @Andrew: as this bug is assigned to you, I'd suggest to change it's > status to open, the priority to P3 and target it for 9 (i.e. Fix > Version = 9). > > Regards, > Volker > > > Andrew. > > From serguei.spitsyn at oracle.com Mon Feb 13 06:25:39 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 12 Feb 2017 22:25:39 -0800 Subject: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client In-Reply-To: References: Message-ID: Hi Jini, It looks pretty good to me. A couple of comments. http://cr.openjdk.java.net/%7Ejgeorge/8173896/webrev.00/hotspot/test/serviceability/sa/TestPrintMdo.java.html It seems these exports are not really needed: 29 import java.io.BufferedInputStream; 31 import java.io.FileInputStream; This line looks strange as the variable of type OutputStream is called "input": 127 OutputStream input = p.getOutputStream(); Adding a comment explaining why is that would be nice. Thanks, Serguei On 2/11/17 04:32, Jini George wrote: > > Could I pls get reviews done for the SA testbug: > > https://bugs.openjdk.java.net/browse/JDK-8173896 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.00/ > > > Thanks, > > Jini. > > > > > From serguei.spitsyn at oracle.com Mon Feb 13 07:33:28 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 12 Feb 2017 23:33:28 -0800 Subject: RFR (XXS): 8172969: JVMTI spec: GetCurrentThread may return NULL in the early start phase Message-ID: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> Please, review a JDK 9 fix for the bug: https://bugs.openjdk.java.net/browse/JDK-8172969 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172969-jvmti-spec.hs1/ Summary: It was identified during the review of 8172261 that the GetCurrentThread may return NULL during the early start phase. This issue existed with the normal start phase in the initial JVM TI implementation (JDK 1.5). Now the GetCurrentThread is Ok to call during the normal start phase as the VMStart event is shifted to the point where the java.base is fully initialized. But now the early VMStart event is at the same point where the VMStart was in all previous releases. The fix is a spec update saying that the GetCurrentThread may return NULL in the early start phase when the java.lang.Thread class has not been initialized yet. Thanks, Serguei From david.holmes at oracle.com Mon Feb 13 07:40:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Feb 2017 17:40:24 +1000 Subject: RFR (XXS): 8172969: JVMTI spec: GetCurrentThread may return NULL in the early start phase In-Reply-To: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> References: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> Message-ID: Looks good! Thanks Serguei! David On 13/02/2017 5:33 PM, serguei.spitsyn at oracle.com wrote: > Please, review a JDK 9 fix for the bug: > https://bugs.openjdk.java.net/browse/JDK-8172969 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172969-jvmti-spec.hs1/ > > > > Summary: > > It was identified during the review of 8172261 that the GetCurrentThread > may return NULL during the early start phase. This issue existed with > the normal start phase in the initial JVM TI implementation (JDK 1.5). > Now the GetCurrentThread is Ok to call during the normal start phase > as the > VMStart event is shifted to the point where the java.base is fully > initialized. > But now the early VMStart event is at the same point where the VMStart > was in all previous releases. > > The fix is a spec update saying that the GetCurrentThread may return > NULL in the > early start phase when the java.lang.Thread class has not been > initialized yet. > > Thanks, > Serguei From serguei.spitsyn at oracle.com Mon Feb 13 07:41:11 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 12 Feb 2017 23:41:11 -0800 Subject: RFR (XXS): 8172969: JVMTI spec: GetCurrentThread may return NULL in the early start phase In-Reply-To: References: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> Message-ID: Thank you, David! Serguei On 2/12/17 23:40, David Holmes wrote: > Looks good! > > Thanks Serguei! > > David > > On 13/02/2017 5:33 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a JDK 9 fix for the bug: >> https://bugs.openjdk.java.net/browse/JDK-8172969 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172969-jvmti-spec.hs1/ >> >> >> >> >> Summary: >> >> It was identified during the review of 8172261 that the >> GetCurrentThread >> may return NULL during the early start phase. This issue existed with >> the normal start phase in the initial JVM TI implementation (JDK 1.5). >> Now the GetCurrentThread is Ok to call during the normal start phase >> as the >> VMStart event is shifted to the point where the java.base is fully >> initialized. >> But now the early VMStart event is at the same point where the VMStart >> was in all previous releases. >> >> The fix is a spec update saying that the GetCurrentThread may return >> NULL in the >> early start phase when the java.lang.Thread class has not been >> initialized yet. >> >> Thanks, >> Serguei From Alan.Bateman at oracle.com Mon Feb 13 07:45:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2017 07:45:58 +0000 Subject: RFR (XXS): 8172969: JVMTI spec: GetCurrentThread may return NULL in the early start phase In-Reply-To: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> References: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> Message-ID: <1cae7ea0-b294-aa89-a4d2-8b56094e0d18@oracle.com> On 13/02/2017 07:33, serguei.spitsyn at oracle.com wrote: > Please, review a JDK 9 fix for the bug: > https://bugs.openjdk.java.net/browse/JDK-8172969 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172969-jvmti-spec.hs1/ > This looks okay to me. -Alan From serguei.spitsyn at oracle.com Mon Feb 13 07:57:57 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 12 Feb 2017 23:57:57 -0800 Subject: RFR (XXS): 8172969: JVMTI spec: GetCurrentThread may return NULL in the early start phase In-Reply-To: <1cae7ea0-b294-aa89-a4d2-8b56094e0d18@oracle.com> References: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> <1cae7ea0-b294-aa89-a4d2-8b56094e0d18@oracle.com> Message-ID: <69c2f0e3-55e1-0936-63f9-617933397eff@oracle.com> Thank you, Alan! Serguei On 2/12/17 23:45, Alan Bateman wrote: > > > On 13/02/2017 07:33, serguei.spitsyn at oracle.com wrote: >> Please, review a JDK 9 fix for the bug: >> https://bugs.openjdk.java.net/browse/JDK-8172969 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172969-jvmti-spec.hs1/ >> > This looks okay to me. > > -Alan From aph at redhat.com Mon Feb 13 09:35:12 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Feb 2017 09:35:12 +0000 Subject: RFR: 8173941: SA does not work if executable is DSO In-Reply-To: References: <6a8b8a71-d792-d5ed-0bef-369fce313f66@gmail.com> <9263a5ed-b677-6bb2-faa1-3074b1aa9e8c@redhat.com> Message-ID: <53500e7a-f0e2-636c-06b9-e2bf1d7b3bbb@redhat.com> On 13/02/17 01:09, David Holmes wrote: > serviceability-dev was the correct mailing list for this change, there > was no need to also send to hotspot-dev. My bad, sorry. Andrew. From dmitry.samersoff at oracle.com Mon Feb 13 12:02:38 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 13 Feb 2017 15:02:38 +0300 Subject: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client In-Reply-To: References: Message-ID: <9cfba9da-1fbe-fe6c-129d-bd95168277a7@oracle.com> Jini, The fix looks good to me. -Dmitry On 2017-02-11 15:32, Jini George wrote: > Could I pls get reviews done for the SA testbug: > > https://bugs.openjdk.java.net/browse/JDK-8173896 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.00/ > > > Thanks, > > Jini. > > > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Mon Feb 13 12:47:29 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 13 Feb 2017 18:17:29 +0530 Subject: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client In-Reply-To: References: Message-ID: <717d96f3-a3b2-b0c6-4cad-82148b092df3@oracle.com> Thank you, Serguei, for the review. I have addressed your comments and have a revised webrev at: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.01/ -Jini. On 2/13/2017 11:55 AM, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > It looks pretty good to me. > A couple of comments. > > http://cr.openjdk.java.net/%7Ejgeorge/8173896/webrev.00/hotspot/test/serviceability/sa/TestPrintMdo.java.html > > > It seems these exports are not really needed: > > 29 import java.io.BufferedInputStream; > 31 import java.io.FileInputStream; > > > This line looks strange as the variable of type OutputStream is called > "input": > 127 OutputStream input = p.getOutputStream(); > > Adding a comment explaining why is that would be nice. > > > Thanks, > Serguei > > On 2/11/17 04:32, Jini George wrote: >> >> Could I pls get reviews done for the SA testbug: >> >> https://bugs.openjdk.java.net/browse/JDK-8173896 >> >> Webrev: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.00/ >> >> >> Thanks, >> >> Jini. >> >> >> >> >> From jini.george at oracle.com Mon Feb 13 12:50:38 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 13 Feb 2017 18:20:38 +0530 Subject: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client In-Reply-To: <9cfba9da-1fbe-fe6c-129d-bd95168277a7@oracle.com> References: <9cfba9da-1fbe-fe6c-129d-bd95168277a7@oracle.com> Message-ID: Thank you very much, Dmitry! -Jini. On 2/13/2017 5:32 PM, Dmitry Samersoff wrote: > Jini, > > The fix looks good to me. > > -Dmitry > > On 2017-02-11 15:32, Jini George wrote: >> Could I pls get reviews done for the SA testbug: >> >> https://bugs.openjdk.java.net/browse/JDK-8173896 >> >> Webrev: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.00/ >> >> >> Thanks, >> >> Jini. >> >> >> >> >> >> >> > From daniel.daugherty at oracle.com Mon Feb 13 14:38:03 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 13 Feb 2017 07:38:03 -0700 Subject: RFR (XXS): 8172969: JVMTI spec: GetCurrentThread may return NULL in the early start phase In-Reply-To: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> References: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> Message-ID: <08dee9b2-0db6-47b5-42b2-295ab2f1940c@oracle.com> On 2/13/17 12:33 AM, serguei.spitsyn at oracle.com wrote: > Please, review a JDK 9 fix for the bug: > https://bugs.openjdk.java.net/browse/JDK-8172969 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172969-jvmti-spec.hs1/ > src/share/vm/prims/jvmti.xml No comments. Thumbs up! Dan > > > Summary: > > It was identified during the review of 8172261 that the > GetCurrentThread > may return NULL during the early start phase. This issue existed with > the normal start phase in the initial JVM TI implementation (JDK 1.5). > Now the GetCurrentThread is Ok to call during the normal start phase > as the > VMStart event is shifted to the point where the java.base is fully > initialized. > But now the early VMStart event is at the same point where the VMStart > was in all previous releases. > > The fix is a spec update saying that the GetCurrentThread may return > NULL in the > early start phase when the java.lang.Thread class has not been > initialized yet. > > Thanks, > Serguei From serguei.spitsyn at oracle.com Mon Feb 13 17:53:12 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 Feb 2017 09:53:12 -0800 Subject: RFR (XXS): 8172969: JVMTI spec: GetCurrentThread may return NULL in the early start phase In-Reply-To: <08dee9b2-0db6-47b5-42b2-295ab2f1940c@oracle.com> References: <20ba0746-e45b-f805-08e0-3de4f3708be6@oracle.com> <08dee9b2-0db6-47b5-42b2-295ab2f1940c@oracle.com> Message-ID: Thank you, Dan! Serguei On 2/13/17 06:38, Daniel D. Daugherty wrote: > On 2/13/17 12:33 AM, serguei.spitsyn at oracle.com wrote: >> Please, review a JDK 9 fix for the bug: >> https://bugs.openjdk.java.net/browse/JDK-8172969 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172969-jvmti-spec.hs1/ >> > > src/share/vm/prims/jvmti.xml > No comments. > > Thumbs up! > > Dan > > >> >> >> Summary: >> >> It was identified during the review of 8172261 that the >> GetCurrentThread >> may return NULL during the early start phase. This issue existed with >> the normal start phase in the initial JVM TI implementation (JDK 1.5). >> Now the GetCurrentThread is Ok to call during the normal start >> phase as the >> VMStart event is shifted to the point where the java.base is fully >> initialized. >> But now the early VMStart event is at the same point where the VMStart >> was in all previous releases. >> >> The fix is a spec update saying that the GetCurrentThread may >> return NULL in the >> early start phase when the java.lang.Thread class has not been >> initialized yet. >> >> Thanks, >> Serguei > From serguei.spitsyn at oracle.com Tue Feb 14 04:21:05 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 Feb 2017 20:21:05 -0800 Subject: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client In-Reply-To: <717d96f3-a3b2-b0c6-4cad-82148b092df3@oracle.com> References: <717d96f3-a3b2-b0c6-4cad-82148b092df3@oracle.com> Message-ID: Hi Jini, Looks good. Thank you for the update! Thanks, Serguei On 2/13/17 04:47, Jini George wrote: > Thank you, Serguei, for the review. I have addressed your comments and > have a revised webrev at: > > http://cr.openjdk.java.net/~jgeorge/8173896/webrev.01/ > > > -Jini. > > On 2/13/2017 11:55 AM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> It looks pretty good to me. >> A couple of comments. >> >> http://cr.openjdk.java.net/%7Ejgeorge/8173896/webrev.00/hotspot/test/serviceability/sa/TestPrintMdo.java.html >> >> >> It seems these exports are not really needed: >> >> 29 import java.io.BufferedInputStream; >> 31 import java.io.FileInputStream; >> >> >> This line looks strange as the variable of type OutputStream is >> called "input": >> 127 OutputStream input = p.getOutputStream(); >> >> Adding a comment explaining why is that would be nice. >> >> >> Thanks, >> Serguei >> >> On 2/11/17 04:32, Jini George wrote: >>> >>> Could I pls get reviews done for the SA testbug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8173896 >>> >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.00/ >>> >>> >>> Thanks, >>> >>> Jini. >>> >>> >>> >>> >>> > From jini.george at oracle.com Tue Feb 14 04:24:43 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 14 Feb 2017 09:54:43 +0530 Subject: RFR: JDK-8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client In-Reply-To: References: <717d96f3-a3b2-b0c6-4cad-82148b092df3@oracle.com> Message-ID: <76452315-61ec-7f3e-3784-83393e4cae88@oracle.com> Thank you, Serguei! -jini On 2/14/2017 9:51 AM, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > Looks good. > Thank you for the update! > > > Thanks, > Serguei > > > On 2/13/17 04:47, Jini George wrote: >> Thank you, Serguei, for the review. I have addressed your comments >> and have a revised webrev at: >> >> http://cr.openjdk.java.net/~jgeorge/8173896/webrev.01/ >> >> >> -Jini. >> >> On 2/13/2017 11:55 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> It looks pretty good to me. >>> A couple of comments. >>> >>> http://cr.openjdk.java.net/%7Ejgeorge/8173896/webrev.00/hotspot/test/serviceability/sa/TestPrintMdo.java.html >>> >>> >>> It seems these exports are not really needed: >>> >>> 29 import java.io.BufferedInputStream; >>> 31 import java.io.FileInputStream; >>> >>> >>> This line looks strange as the variable of type OutputStream is >>> called "input": >>> 127 OutputStream input = p.getOutputStream(); >>> >>> Adding a comment explaining why is that would be nice. >>> >>> >>> Thanks, >>> Serguei >>> >>> On 2/11/17 04:32, Jini George wrote: >>>> >>>> Could I pls get reviews done for the SA testbug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8173896 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8173896/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Jini. >>>> >>>> >>>> >>>> >>>> >> > From amit.sapre at oracle.com Tue Feb 14 11:52:16 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Tue, 14 Feb 2017 03:52:16 -0800 (PST) Subject: RFR : JDK-8174196 : sun/management/jdp tests are not running properly Message-ID: <03d3db5b-4190-4f86-bdd2-485af8ed72f8@default> Hello, Please review following test case fix Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174196 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174196/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Feb 14 12:20:52 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Feb 2017 12:20:52 +0000 Subject: RFR : JDK-8174196 : sun/management/jdp tests are not running properly In-Reply-To: <03d3db5b-4190-4f86-bdd2-485af8ed72f8@default> References: <03d3db5b-4190-4f86-bdd2-485af8ed72f8@default> Message-ID: <799ba97e-645c-6cf5-ff41-63bfba5458cd@oracle.com> Looks good to me Amit. best regards, -- daniel On 14/02/17 11:52, Amit Sapre wrote: > Hello, > > > > Please review following test case fix > > > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174196 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174196/webrev.00/ > > > > Thanks, > > Amit > From erik.gahlin at oracle.com Tue Feb 14 12:21:35 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 14 Feb 2017 13:21:35 +0100 Subject: RFR : JDK-8174196 : sun/management/jdp tests are not running properly In-Reply-To: <03d3db5b-4190-4f86-bdd2-485af8ed72f8@default> References: <03d3db5b-4190-4f86-bdd2-485af8ed72f8@default> Message-ID: <58A2F64F.10403@oracle.com> Looks good. Erik > Hello, > > Please review following test case fix > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174196 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174196/webrev.00/ > > > Thanks, > > Amit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.sapre at oracle.com Tue Feb 14 12:34:26 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Tue, 14 Feb 2017 04:34:26 -0800 (PST) Subject: RFR : JDK-8174196 : sun/management/jdp tests are not running properly In-Reply-To: <58A2F64F.10403@oracle.com> References: <03d3db5b-4190-4f86-bdd2-485af8ed72f8@default> <58A2F64F.10403@oracle.com> Message-ID: <85070155-858d-4d3f-8e55-7b22e644b80d@default> Thanks Daniel & Erik for the review From: Erik Gahlin Sent: Tuesday, February 14, 2017 5:52 PM To: serviceability-dev at openjdk.java.net Subject: Re: RFR : JDK-8174196 : sun/management/jdp tests are not running properly Looks good. Erik Hello, Please review following test case fix Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174196 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174196/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Feb 14 13:08:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Feb 2017 23:08:38 +1000 Subject: RFR : JDK-8174196 : sun/management/jdp tests are not running properly In-Reply-To: <03d3db5b-4190-4f86-bdd2-485af8ed72f8@default> References: <03d3db5b-4190-4f86-bdd2-485af8ed72f8@default> Message-ID: Hi Amit, On 14/02/2017 9:52 PM, Amit Sapre wrote: > Hello, > > Please review following test case fix > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174196 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174196/webrev.00/ The change to use othervm seems fine, but I'm unclear how useful this is by itself without the changes now being tracked in JDK-8174915? Thanks, David > > > Thanks, > > Amit > From yasuenag at gmail.com Tue Feb 14 23:38:52 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 15 Feb 2017 08:38:52 +0900 Subject: RFA: 8173941: SA does not work if executable is DSO In-Reply-To: <20170214230905.GA2647@vimes> References: <5319530e-b62d-5393-8807-b8fb7af02293@gmail.com> <20170214230905.GA2647@vimes> Message-ID: * I added serviceability-dev Hi all, JDK-8173941 has been approved to push to jdk8u repo. I added noreg label to JBS. Could you help me to push it? Thanks, Yasumasa 2017/02/15 ??8:09 "Rob McKenna" : > Approved, but please add an appropriate noreg label to the bug. Also > please work with the serviceability team to get this pushed. > > -Rob > > On 14/02/17 10:16, Yasumasa Suenaga wrote: > > Hi all, > > > > JBS: > > https://bugs.openjdk.java.net/browse/JDK-8173941 > > > > 9 changeset: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b3d95edd4467 > > > > 9 review: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/ > 2017-February/020968.html > > http://mail.openjdk.java.net/pipermail/serviceability-dev/ > 2017-February/020973.html > > > > In modern Linux e.g. Fedora 25, executables are built as DSO for > security [1]. > > java command in OpenJDK which is provided by distribution is also DSO. > > However, SA does not work with DSO executables. > > > > Currently, OpenJDK 8 in Fedora 25 is built as DSO. > > So I want to contribute this patch to jdk8u. > > > > > > I'm not a committer of jdk8u. So I need a sponsor. > > > > > > Thanks, > > > > Yasumasa > > > > > > [1] https://fedoraproject.org/wiki/Packaging:Guidelines#PIE > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Feb 14 23:57:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Feb 2017 09:57:22 +1000 Subject: RFA: 8173941: SA does not work if executable is DSO In-Reply-To: References: <5319530e-b62d-5393-8807-b8fb7af02293@gmail.com> <20170214230905.GA2647@vimes> Message-ID: Hi Yasumasa, On 15/02/2017 9:38 AM, Yasumasa Suenaga wrote: > * I added serviceability-dev > > Hi all, > > JDK-8173941 has been approved to push to jdk8u repo. > I added noreg label to JBS. Could you help me to push it? An 'appropriate noreg label' has to follow the guidelines here: http://openjdk.java.net/guide/changePlanning.html#noreg I changed it to noreg-hard and added an explanatory comment. I will push this to jdk8u/dev for you. David ----- > > Thanks, > > Yasumasa > > > 2017/02/15 ??8:09 "Rob McKenna" : > >> Approved, but please add an appropriate noreg label to the bug. Also >> please work with the serviceability team to get this pushed. >> >> -Rob >> >> On 14/02/17 10:16, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8173941 >>> >>> 9 changeset: >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b3d95edd4467 >>> >>> 9 review: >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/ >> 2017-February/020968.html >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/ >> 2017-February/020973.html >>> >>> In modern Linux e.g. Fedora 25, executables are built as DSO for >> security [1]. >>> java command in OpenJDK which is provided by distribution is also DSO. >>> However, SA does not work with DSO executables. >>> >>> Currently, OpenJDK 8 in Fedora 25 is built as DSO. >>> So I want to contribute this patch to jdk8u. >>> >>> >>> I'm not a committer of jdk8u. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] https://fedoraproject.org/wiki/Packaging:Guidelines#PIE >> From yasuenag at gmail.com Wed Feb 15 00:00:35 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 15 Feb 2017 09:00:35 +0900 Subject: RFA: 8173941: SA does not work if executable is DSO In-Reply-To: References: <5319530e-b62d-5393-8807-b8fb7af02293@gmail.com> <20170214230905.GA2647@vimes> Message-ID: Thanks David, and sorry to add incorrect label. Yasumasa 2017/02/15 ??8:57 "David Holmes" : > Hi Yasumasa, > > On 15/02/2017 9:38 AM, Yasumasa Suenaga wrote: > >> * I added serviceability-dev >> >> Hi all, >> >> JDK-8173941 has been approved to push to jdk8u repo. >> I added noreg label to JBS. Could you help me to push it? >> > > An 'appropriate noreg label' has to follow the guidelines here: > > http://openjdk.java.net/guide/changePlanning.html#noreg > > I changed it to noreg-hard and added an explanatory comment. I will push > this to jdk8u/dev for you. > > David > ----- > > >> Thanks, >> >> Yasumasa >> >> >> 2017/02/15 ??8:09 "Rob McKenna" : >> >> Approved, but please add an appropriate noreg label to the bug. Also >>> please work with the serviceability team to get this pushed. >>> >>> -Rob >>> >>> On 14/02/17 10:16, Yasumasa Suenaga wrote: >>> >>>> Hi all, >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8173941 >>>> >>>> 9 changeset: >>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b3d95edd4467 >>>> >>>> 9 review: >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/ >>>> >>> 2017-February/020968.html >>> >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/ >>>> >>> 2017-February/020973.html >>> >>>> >>>> In modern Linux e.g. Fedora 25, executables are built as DSO for >>>> >>> security [1]. >>> >>>> java command in OpenJDK which is provided by distribution is also DSO. >>>> However, SA does not work with DSO executables. >>>> >>>> Currently, OpenJDK 8 in Fedora 25 is built as DSO. >>>> So I want to contribute this patch to jdk8u. >>>> >>>> >>>> I'm not a committer of jdk8u. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://fedoraproject.org/wiki/Packaging:Guidelines#PIE >>>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Feb 15 00:05:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Feb 2017 10:05:36 +1000 Subject: RFA: 8173941: SA does not work if executable is DSO In-Reply-To: References: <5319530e-b62d-5393-8807-b8fb7af02293@gmail.com> <20170214230905.GA2647@vimes> Message-ID: <7a9defda-3ddb-d318-f333-784b7009e065@oracle.com> On 15/02/2017 10:00 AM, Yasumasa Suenaga wrote: > Thanks David, and sorry to add incorrect label. No problem. Where is the patch for 8u? Thanks, David > Yasumasa > > > 2017/02/15 ??8:57 "David Holmes" >: > > Hi Yasumasa, > > On 15/02/2017 9:38 AM, Yasumasa Suenaga wrote: > > * I added serviceability-dev > > Hi all, > > JDK-8173941 has been approved to push to jdk8u repo. > I added noreg label to JBS. Could you help me to push it? > > > An 'appropriate noreg label' has to follow the guidelines here: > > http://openjdk.java.net/guide/changePlanning.html#noreg > > > I changed it to noreg-hard and added an explanatory comment. I will > push this to jdk8u/dev for you. > > David > ----- > > > Thanks, > > Yasumasa > > > 2017/02/15 ??8:09 "Rob McKenna" >: > > Approved, but please add an appropriate noreg label to the > bug. Also > please work with the serviceability team to get this pushed. > > -Rob > > On 14/02/17 10:16, Yasumasa Suenaga wrote: > > Hi all, > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8173941 > > > 9 changeset: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/b3d95edd4467 > > > 9 review: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/ > > > 2017-February/020968.html > > > http://mail.openjdk.java.net/pipermail/serviceability-dev/ > > > 2017-February/020973.html > > > In modern Linux e.g. Fedora 25, executables are built as > DSO for > > security [1]. > > java command in OpenJDK which is provided by > distribution is also DSO. > However, SA does not work with DSO executables. > > Currently, OpenJDK 8 in Fedora 25 is built as DSO. > So I want to contribute this patch to jdk8u. > > > I'm not a committer of jdk8u. So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] > https://fedoraproject.org/wiki/Packaging:Guidelines#PIE > > > From jini.george at oracle.com Thu Feb 16 05:15:17 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 16 Feb 2017 10:45:17 +0530 Subject: RFR: JDK-8175054: Move new TestPrintMdo.java to hotspot/test directory Message-ID: <0eae1f9d-b113-b7d4-feb5-e5ef766d8122@oracle.com> Hi, Could I pls get a quick review for the following minor change to correct an incorrect push wrt the file path of a new test case added ? Bug: https://bugs.openjdk.java.net/browse/JDK-8175054 Webrev: http://cr.openjdk.java.net/~jgeorge/8175054/webrev/ Thanks, Jini. From david.holmes at oracle.com Thu Feb 16 07:38:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Feb 2017 17:38:49 +1000 Subject: RFR: JDK-8175054: Move new TestPrintMdo.java to hotspot/test directory In-Reply-To: <0eae1f9d-b113-b7d4-feb5-e5ef766d8122@oracle.com> References: <0eae1f9d-b113-b7d4-feb5-e5ef766d8122@oracle.com> Message-ID: <3ad9b216-47dc-4bd7-997b-1ddfa3a8f9ca@oracle.com> Reviewed. Thanks, David On 16/02/2017 3:15 PM, Jini George wrote: > Hi, > > Could I pls get a quick review for the following minor change to correct > an incorrect push wrt the file path of a new test case added ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175054 > Webrev: http://cr.openjdk.java.net/~jgeorge/8175054/webrev/ > > Thanks, > Jini. From jini.george at oracle.com Thu Feb 16 08:06:58 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 16 Feb 2017 13:36:58 +0530 Subject: RFR: JDK-8175054: Move new TestPrintMdo.java to hotspot/test directory In-Reply-To: <3ad9b216-47dc-4bd7-997b-1ddfa3a8f9ca@oracle.com> References: <0eae1f9d-b113-b7d4-feb5-e5ef766d8122@oracle.com> <3ad9b216-47dc-4bd7-997b-1ddfa3a8f9ca@oracle.com> Message-ID: Thanks, David. -jini On 2/16/2017 1:08 PM, David Holmes wrote: > Reviewed. > > Thanks, > David > > On 16/02/2017 3:15 PM, Jini George wrote: >> Hi, >> >> Could I pls get a quick review for the following minor change to correct >> an incorrect push wrt the file path of a new test case added ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8175054 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8175054/webrev/ >> >> Thanks, >> Jini. From amit.sapre at oracle.com Mon Feb 20 07:22:01 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Sun, 19 Feb 2017 23:22:01 -0800 (PST) Subject: RFR : JDK-8174915 - Improve error handing for Jdp tests under sun/management/jdp Message-ID: <1e893518-50b4-4cae-b36d-e0b428048dbb@default> Hello, Please review minor improvements to jdp test helper class to handle error conditions. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174915 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174915/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Feb 21 03:20:52 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Feb 2017 13:20:52 +1000 Subject: RFR : JDK-8174915 - Improve error handing for Jdp tests under sun/management/jdp In-Reply-To: <1e893518-50b4-4cae-b36d-e0b428048dbb@default> References: <1e893518-50b4-4cae-b36d-e0b428048dbb@default> Message-ID: <53f77c1f-07a4-17a5-d9ca-27043adc2c4c@oracle.com> Looks okay to me. Thanks, David On 20/02/2017 5:22 PM, Amit Sapre wrote: > Hello, > > > > Please review minor improvements to jdp test helper class to handle > error conditions. > > > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174915 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174915/webrev.00/ > > > > Thanks, > > Amit > From serguei.spitsyn at oracle.com Tue Feb 21 06:16:01 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Feb 2017 22:16:01 -0800 Subject: RFR : JDK-8174915 - Improve error handing for Jdp tests under sun/management/jdp In-Reply-To: <53f77c1f-07a4-17a5-d9ca-27043adc2c4c@oracle.com> References: <1e893518-50b4-4cae-b36d-e0b428048dbb@default> <53f77c1f-07a4-17a5-d9ca-27043adc2c4c@oracle.com> Message-ID: +1 Thanks, Serguei On 2/20/17 19:20, David Holmes wrote: > Looks okay to me. > > Thanks, > David > > On 20/02/2017 5:22 PM, Amit Sapre wrote: >> Hello, >> >> >> >> Please review minor improvements to jdp test helper class to handle >> error conditions. >> >> >> >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174915 >> >> Webrev : >> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174915/webrev.00/ >> >> >> >> Thanks, >> >> Amit >> From daniel.fuchs at oracle.com Tue Feb 21 10:21:04 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 21 Feb 2017 10:21:04 +0000 Subject: RFR : JDK-8174915 - Improve error handing for Jdp tests under sun/management/jdp In-Reply-To: <1e893518-50b4-4cae-b36d-e0b428048dbb@default> References: <1e893518-50b4-4cae-b36d-e0b428048dbb@default> Message-ID: <4143b702-ea58-b3f2-5cc5-6b87c80a746c@oracle.com> Hi Amit, Looks good to me. maybe you could add a comment in DynanicLauncher.java: // This exception is thrown by JdpTestCase.java when // something goes wrong. For instance, see // JdpTestCase::shutdown() 62 output.shouldNotContain("java.lang.Exception:"); No need to produce a new webrev! best regards, -- daniel On 20/02/17 07:22, Amit Sapre wrote: > Hello, > > > > Please review minor improvements to jdp test helper class to handle > error conditions. > > > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8174915 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8174915/webrev.00/ > > > > Thanks, > > Amit > From jini.george at oracle.com Tue Feb 21 15:48:15 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 21 Feb 2017 21:18:15 +0530 Subject: RFR: JDK-8162504: [SA testbug] TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS Message-ID: <2c12e4b8-b524-1a68-ec41-8bdd011d3cff@oracle.com> Requesting reviews for the following SA testbug: https://bugs.openjdk.java.net/browse/JDK-8162504 Webrev: http://cr.openjdk.java.net/~jgeorge/8162504/webrev.00/ Thank you, Jini. From dmitry.samersoff at oracle.com Tue Feb 21 16:21:51 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Feb 2017 19:21:51 +0300 Subject: RFR: JDK-8162504: [SA testbug] TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS In-Reply-To: <2c12e4b8-b524-1a68-ec41-8bdd011d3cff@oracle.com> References: <2c12e4b8-b524-1a68-ec41-8bdd011d3cff@oracle.com> Message-ID: <7aebe898-e02b-0edb-60b6-d1322f567ce4@oracle.com> Jini, Looks good to me. -Dmitry On 2017-02-21 18:48, Jini George wrote: > Requesting reviews for the following SA testbug: > > https://bugs.openjdk.java.net/browse/JDK-8162504 > Webrev: http://cr.openjdk.java.net/~jgeorge/8162504/webrev.00/ > > Thank you, > Jini. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Wed Feb 22 03:00:33 2017 From: jini.george at oracle.com (Jini George) Date: Wed, 22 Feb 2017 08:30:33 +0530 Subject: RFR: JDK-8162504: [SA testbug] TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS In-Reply-To: <7aebe898-e02b-0edb-60b6-d1322f567ce4@oracle.com> References: <2c12e4b8-b524-1a68-ec41-8bdd011d3cff@oracle.com> <7aebe898-e02b-0edb-60b6-d1322f567ce4@oracle.com> Message-ID: <2d6f30b2-ba24-6718-667b-51a8306dde87@oracle.com> Thank you, Dmitry. Could I get one more review for this ? -Jini. On 2/21/2017 9:51 PM, Dmitry Samersoff wrote: > Jini, > > Looks good to me. > > -Dmitry > > On 2017-02-21 18:48, Jini George wrote: >> Requesting reviews for the following SA testbug: >> >> https://bugs.openjdk.java.net/browse/JDK-8162504 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8162504/webrev.00/ >> >> Thank you, >> Jini. > From serguei.spitsyn at oracle.com Wed Feb 22 07:28:37 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Feb 2017 23:28:37 -0800 Subject: RFR: JDK-8162504: [SA testbug] TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS In-Reply-To: <2c12e4b8-b524-1a68-ec41-8bdd011d3cff@oracle.com> References: <2c12e4b8-b524-1a68-ec41-8bdd011d3cff@oracle.com> Message-ID: Hi Jini, It looks good. Thanks, Serguei On 2/21/17 07:48, Jini George wrote: > Requesting reviews for the following SA testbug: > > https://bugs.openjdk.java.net/browse/JDK-8162504 > Webrev: http://cr.openjdk.java.net/~jgeorge/8162504/webrev.00/ > > Thank you, > Jini. From jini.george at oracle.com Wed Feb 22 08:37:24 2017 From: jini.george at oracle.com (Jini George) Date: Wed, 22 Feb 2017 14:07:24 +0530 Subject: RFR: JDK-8162504: [SA testbug] TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS In-Reply-To: References: <2c12e4b8-b524-1a68-ec41-8bdd011d3cff@oracle.com> Message-ID: <5c1ec1af-bd7a-0706-a245-a18562261b21@oracle.com> Thank you, Serguei. - jini. On 2/22/2017 12:58 PM, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > It looks good. > > Thanks, > Serguei > > > On 2/21/17 07:48, Jini George wrote: >> Requesting reviews for the following SA testbug: >> >> https://bugs.openjdk.java.net/browse/JDK-8162504 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8162504/webrev.00/ >> >> Thank you, >> Jini. > From amit.sapre at oracle.com Wed Feb 22 09:59:11 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 22 Feb 2017 01:59:11 -0800 (PST) Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 Message-ID: <88465114-5f74-4384-b114-6506b1f8441c@default> Hello, Please review this test bug fix which eliminates test case's own timeout mechanism to default jtreg timeout. Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Wed Feb 22 10:56:51 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 22 Feb 2017 11:56:51 +0100 Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: <88465114-5f74-4384-b114-6506b1f8441c@default> References: <88465114-5f74-4384-b114-6506b1f8441c@default> Message-ID: Looks good. Erik > > Hello, > > Please review this test bug fix which eliminates test case?s own > timeout mechanism to default jtreg timeout. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.00/ > > > Thanks, > > Amit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Feb 22 13:35:04 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 22 Feb 2017 19:05:04 +0530 Subject: RFR: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris Message-ID: <2fcfad92-509c-a7ca-d8a3-85aa11a63e46@oracle.com> Hi All, Please review the below test fix for Issue: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris webrev : http://cr.openjdk.java.net/~hb/8173130/webrev.00/ The fix does the following. 1. Removes explicit platform check 2. Fixes JMXServiceURL 3. Adds required RuntimePermissions for test to execute. Regards Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Feb 22 14:13:55 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Feb 2017 14:13:55 +0000 Subject: RFR: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris In-Reply-To: <2fcfad92-509c-a7ca-d8a3-85aa11a63e46@oracle.com> References: <2fcfad92-509c-a7ca-d8a3-85aa11a63e46@oracle.com> Message-ID: <529edcbb-47de-0f1a-a2f5-ea5687eae4a7@oracle.com> Hi Harsha, Looks good - but do you really need java.lang.RuntimePermission "*" ? What permission was missing? best regards, -- daniel On 22/02/17 13:35, Harsha Wardhana B wrote: > Hi All, > > Please review the below test fix for > > Issue: JDK-8173130 - SubjectDelegation2Test.java > and SubjectDelegation3Test.java failing on solaris > > webrev : http://cr.openjdk.java.net/~hb/8173130/webrev.00/ > > The fix does the following. > > 1. Removes explicit platform check > > 2. Fixes JMXServiceURL > > 3. Adds required RuntimePermissions for test to execute. > > Regards > > Harsha > From harsha.wardhana.b at oracle.com Wed Feb 22 14:18:29 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 22 Feb 2017 19:48:29 +0530 Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: <88465114-5f74-4384-b114-6506b1f8441c@default> References: <88465114-5f74-4384-b114-6506b1f8441c@default> Message-ID: Hi Amit, There is no need to wait in a loop to check we have not received any notifications. Without starting the monitors, the listener count will be zero. The first part of diff L116-L121 could be left as is. By relying on Jtreg timeout for receiving notifications, we will be unable to print the number of listeners emitted by each Monitor. But I guess there is no way to intercept a Jtreg timeout and print out those values. Regards Harsha On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: > > Hello, > > Please review this test bug fix which eliminates test case?s own > timeout mechanism to default jtreg timeout. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.00/ > > > Thanks, > > Amit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Feb 22 14:38:58 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 22 Feb 2017 20:08:58 +0530 Subject: RFR: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris In-Reply-To: <529edcbb-47de-0f1a-a2f5-ea5687eae4a7@oracle.com> References: <2fcfad92-509c-a7ca-d8a3-85aa11a63e46@oracle.com> <529edcbb-47de-0f1a-a2f5-ea5687eae4a7@oracle.com> Message-ID: Hi Daniel, ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.krb5") was missing. I gave all the RuntimePermissions since we don't want test cases to fail in future. Granting java.lang.RuntimePermission "*" does not affect the test cases in anyway as test cases rely on delegation of specific permissions. Regards Harsha On Wednesday 22 February 2017 07:43 PM, Daniel Fuchs wrote: > Hi Harsha, > > Looks good - but do you really need java.lang.RuntimePermission "*" ? > > What permission was missing? > > best regards, > > -- daniel > > On 22/02/17 13:35, Harsha Wardhana B wrote: >> Hi All, >> >> Please review the below test fix for >> >> Issue: JDK-8173130 - SubjectDelegation2Test.java >> and SubjectDelegation3Test.java failing on solaris >> >> webrev : http://cr.openjdk.java.net/~hb/8173130/webrev.00/ >> >> The fix does the following. >> >> 1. Removes explicit platform check >> >> 2. Fixes JMXServiceURL >> >> 3. Adds required RuntimePermissions for test to execute. >> >> Regards >> >> Harsha >> > From daniel.fuchs at oracle.com Wed Feb 22 14:51:57 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Feb 2017 14:51:57 +0000 Subject: RFR: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris In-Reply-To: References: <2fcfad92-509c-a7ca-d8a3-85aa11a63e46@oracle.com> <529edcbb-47de-0f1a-a2f5-ea5687eae4a7@oracle.com> Message-ID: <518b85f8-2551-5b62-fd95-0363f29eb456@oracle.com> Hi Harsha, OK - makes sense to me. Maybe just wait for tomorrow to see if you get any other comments form other reviewers... best regards, -- daniel On 22/02/17 14:38, Harsha Wardhana B wrote: > Hi Daniel, > > ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.krb5") > was missing. > > I gave all the RuntimePermissions since we don't want test cases to fail > in future. > > Granting java.lang.RuntimePermission "*" does not affect the test cases > in anyway as test cases rely on delegation of specific permissions. > > Regards > Harsha > > On Wednesday 22 February 2017 07:43 PM, Daniel Fuchs wrote: >> Hi Harsha, >> >> Looks good - but do you really need java.lang.RuntimePermission "*" ? >> >> What permission was missing? >> >> best regards, >> >> -- daniel >> >> On 22/02/17 13:35, Harsha Wardhana B wrote: >>> Hi All, >>> >>> Please review the below test fix for >>> >>> Issue: JDK-8173130 - SubjectDelegation2Test.java >>> and SubjectDelegation3Test.java failing on solaris >>> >>> webrev : http://cr.openjdk.java.net/~hb/8173130/webrev.00/ >>> >>> The fix does the following. >>> >>> 1. Removes explicit platform check >>> >>> 2. Fixes JMXServiceURL >>> >>> 3. Adds required RuntimePermissions for test to execute. >>> >>> Regards >>> >>> Harsha >>> >> > From harsha.wardhana.b at oracle.com Wed Feb 22 14:54:06 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 22 Feb 2017 20:24:06 +0530 Subject: RFR: JDK-8173130 - SubjectDelegation2Test.java and SubjectDelegation3Test.java failing on solaris In-Reply-To: <518b85f8-2551-5b62-fd95-0363f29eb456@oracle.com> References: <2fcfad92-509c-a7ca-d8a3-85aa11a63e46@oracle.com> <529edcbb-47de-0f1a-a2f5-ea5687eae4a7@oracle.com> <518b85f8-2551-5b62-fd95-0363f29eb456@oracle.com> Message-ID: Thanks for the review Daniel. -Harsha On Wednesday 22 February 2017 08:21 PM, Daniel Fuchs wrote: > Hi Harsha, > > OK - makes sense to me. > Maybe just wait for tomorrow to see if you get any other comments > form other reviewers... > > best regards, > > -- daniel > > On 22/02/17 14:38, Harsha Wardhana B wrote: >> Hi Daniel, >> >> ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.krb5") >> was missing. >> >> I gave all the RuntimePermissions since we don't want test cases to fail >> in future. >> >> Granting java.lang.RuntimePermission "*" does not affect the test cases >> in anyway as test cases rely on delegation of specific permissions. >> >> Regards >> Harsha >> >> On Wednesday 22 February 2017 07:43 PM, Daniel Fuchs wrote: >>> Hi Harsha, >>> >>> Looks good - but do you really need java.lang.RuntimePermission "*" ? >>> >>> What permission was missing? >>> >>> best regards, >>> >>> -- daniel >>> >>> On 22/02/17 13:35, Harsha Wardhana B wrote: >>>> Hi All, >>>> >>>> Please review the below test fix for >>>> >>>> Issue: JDK-8173130 - SubjectDelegation2Test.java >>>> and SubjectDelegation3Test.java failing on solaris >>>> >>>> webrev : http://cr.openjdk.java.net/~hb/8173130/webrev.00/ >>>> >>>> The fix does the following. >>>> >>>> 1. Removes explicit platform check >>>> >>>> 2. Fixes JMXServiceURL >>>> >>>> 3. Adds required RuntimePermissions for test to execute. >>>> >>>> Regards >>>> >>>> Harsha >>>> >>> >> > From david.holmes at oracle.com Thu Feb 23 03:53:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Feb 2017 13:53:36 +1000 Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: References: <88465114-5f74-4384-b114-6506b1f8441c@default> Message-ID: <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> Hi Amit, On 23/02/2017 12:18 AM, Harsha Wardhana B wrote: > Hi Amit, > > There is no need to wait in a loop to check we have not received any > notifications. Without starting the monitors, the listener count will be > zero. > > The first part of diff L116-L121 could be left as is. Agreed. > By relying on Jtreg timeout for receiving notifications, we will be > unable to print the number of listeners emitted by each Monitor. But I > guess there is no way to intercept a Jtreg timeout and print out those > values. You could print out the values every 1 second, or 5 or 10, ... at least that way we can see what the values are when we timeout, and also if they have been changing. Thanks, David > Regards > > Harsha > > > On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: >> >> Hello, >> >> >> >> Please review this test bug fix which eliminates test case?s own >> timeout mechanism to default jtreg timeout. >> >> >> >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 >> >> Webrev : >> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.00/ >> >> >> >> >> Thanks, >> >> Amit >> > From amit.sapre at oracle.com Thu Feb 23 06:18:12 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 22 Feb 2017 22:18:12 -0800 (PST) Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> References: <88465114-5f74-4384-b114-6506b1f8441c@default> <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> Message-ID: Hello, Thanks David & Harsha for your inputs. Here is the new webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/ Thanks, Amit > -----Original Message----- > From: David Holmes > Sent: Thursday, February 23, 2017 9:24 AM > To: serviceability-dev at openjdk.java.net; Sapre Amit > Cc: Harsha Wardhana B > Subject: Re: RFR : JDK-7132577 - > javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > > Hi Amit, > > On 23/02/2017 12:18 AM, Harsha Wardhana B wrote: > > Hi Amit, > > > > There is no need to wait in a loop to check we have not received any > > notifications. Without starting the monitors, the listener count will > > be zero. > > > > The first part of diff L116-L121 could be left as is. > > Agreed. > > > By relying on Jtreg timeout for receiving notifications, we will be > > unable to print the number of listeners emitted by each Monitor. But > I > > guess there is no way to intercept a Jtreg timeout and print out > those > > values. > > You could print out the values every 1 second, or 5 or 10, ... at least > that way we can see what the values are when we timeout, and also if > they have been changing. > > Thanks, > David > > > Regards > > > > Harsha > > > > > > On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: > >> > >> Hello, > >> > >> > >> > >> Please review this test bug fix which eliminates test case's own > >> timeout mechanism to default jtreg timeout. > >> > >> > >> > >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 > >> > >> Webrev : > >> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > 7132577/webrev.00/ > >> 7132577/webrev. > >> 00/> > >> > >> > >> > >> Thanks, > >> > >> Amit > >> > > From amit.sapre at oracle.com Thu Feb 23 06:25:22 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 22 Feb 2017 22:25:22 -0800 (PST) Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: References: <88465114-5f74-4384-b114-6506b1f8441c@default> <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> Message-ID: Hello, In a messy run of this test case, the number of prints for the counter values will be 240 (120 seconds is jtreg timeout) Will try to optimize this. Please hold on for a new webrev. Thanks, Amit > -----Original Message----- > From: Amit Sapre > Sent: Thursday, February 23, 2017 11:48 AM > To: David Holmes; serviceability-dev at openjdk.java.net; Harsha Wardhana > B > Subject: RE: RFR : JDK-7132577 - > javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > > Hello, > > Thanks David & Harsha for your inputs. > Here is the new webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/ > > Thanks, > Amit > > > -----Original Message----- > > From: David Holmes > > Sent: Thursday, February 23, 2017 9:24 AM > > To: serviceability-dev at openjdk.java.net; Sapre Amit > > Cc: Harsha Wardhana B > > Subject: Re: RFR : JDK-7132577 - > > javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > > > > Hi Amit, > > > > On 23/02/2017 12:18 AM, Harsha Wardhana B wrote: > > > Hi Amit, > > > > > > There is no need to wait in a loop to check we have not received > any > > > notifications. Without starting the monitors, the listener count > > > will be zero. > > > > > > The first part of diff L116-L121 could be left as is. > > > > Agreed. > > > > > By relying on Jtreg timeout for receiving notifications, we will be > > > unable to print the number of listeners emitted by each Monitor. > But > > I > > > guess there is no way to intercept a Jtreg timeout and print out > > those > > > values. > > > > You could print out the values every 1 second, or 5 or 10, ... at > > least that way we can see what the values are when we timeout, and > > also if they have been changing. > > > > Thanks, > > David > > > > > Regards > > > > > > Harsha > > > > > > > > > On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: > > >> > > >> Hello, > > >> > > >> > > >> > > >> Please review this test bug fix which eliminates test case's own > > >> timeout mechanism to default jtreg timeout. > > >> > > >> > > >> > > >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 > > >> > > >> Webrev : > > >> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > > 7132577/webrev.00/ > > >> > 7132577/webrev. > > >> 00/> > > >> > > >> > > >> > > >> Thanks, > > >> > > >> Amit > > >> > > > From david.holmes at oracle.com Thu Feb 23 06:29:01 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Feb 2017 16:29:01 +1000 Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: References: <88465114-5f74-4384-b114-6506b1f8441c@default> <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> Message-ID: <95093a53-1ad4-3d8a-463e-660cfa3838f4@oracle.com> Hi Amit, On 23/02/2017 4:18 PM, Amit Sapre wrote: > Hello, > > Thanks David & Harsha for your inputs. > Here is the new webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/ You didn't leave L116 - L121 as-is, you deleted them. Isn't checking they are all 0 a useful sanity check? Moving the printing into listenersAreAll is not ideal as the only way to control the output rate is by changing the sleep time in the loop. But we want the test to be responsive (no big sleeps) and also don't want excessive output. The 500ms sleep might be a reasonable compromise but I can't tell that - how long does the test normally take to run and how much output is generated? Thanks, David > Thanks, > Amit > >> -----Original Message----- >> From: David Holmes >> Sent: Thursday, February 23, 2017 9:24 AM >> To: serviceability-dev at openjdk.java.net; Sapre Amit >> Cc: Harsha Wardhana B >> Subject: Re: RFR : JDK-7132577 - >> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 >> >> Hi Amit, >> >> On 23/02/2017 12:18 AM, Harsha Wardhana B wrote: >>> Hi Amit, >>> >>> There is no need to wait in a loop to check we have not received any >>> notifications. Without starting the monitors, the listener count will >>> be zero. >>> >>> The first part of diff L116-L121 could be left as is. >> >> Agreed. >> >>> By relying on Jtreg timeout for receiving notifications, we will be >>> unable to print the number of listeners emitted by each Monitor. But >> I >>> guess there is no way to intercept a Jtreg timeout and print out >> those >>> values. >> >> You could print out the values every 1 second, or 5 or 10, ... at least >> that way we can see what the values are when we timeout, and also if >> they have been changing. >> >> Thanks, >> David >> >>> Regards >>> >>> Harsha >>> >>> >>> On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: >>>> >>>> Hello, >>>> >>>> >>>> >>>> Please review this test bug fix which eliminates test case's own >>>> timeout mechanism to default jtreg timeout. >>>> >>>> >>>> >>>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 >>>> >>>> Webrev : >>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- >> 7132577/webrev.00/ >>>> > 7132577/webrev. >>>> 00/> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Amit >>>> >>> From amit.sapre at oracle.com Thu Feb 23 06:58:59 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 22 Feb 2017 22:58:59 -0800 (PST) Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: References: <88465114-5f74-4384-b114-6506b1f8441c@default> <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> Message-ID: <19912c82-2cd7-4b29-b9bd-138167b4cb98@default> Hello, http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.02/ has the updated changes. I ran this test on my VM and roughly takes 250-300 ms to get all the listener count. Thanks, Amit > -----Original Message----- > From: Amit Sapre > Sent: Thursday, February 23, 2017 11:55 AM > To: David Holmes; serviceability-dev at openjdk.java.net; Harsha Wardhana > B > Subject: RE: RFR : JDK-7132577 - > javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > > Hello, > > In a messy run of this test case, > the number of prints for the counter values will be 240 (120 seconds is > jtreg timeout) > > Will try to optimize this. Please hold on for a new webrev. > > Thanks, > Amit > > > > -----Original Message----- > > From: Amit Sapre > > Sent: Thursday, February 23, 2017 11:48 AM > > To: David Holmes; serviceability-dev at openjdk.java.net; Harsha > Wardhana > > B > > Subject: RE: RFR : JDK-7132577 - > > javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > > > > Hello, > > > > Thanks David & Harsha for your inputs. > > Here is the new webrev : > > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/ > > > > Thanks, > > Amit > > > > > -----Original Message----- > > > From: David Holmes > > > Sent: Thursday, February 23, 2017 9:24 AM > > > To: serviceability-dev at openjdk.java.net; Sapre Amit > > > Cc: Harsha Wardhana B > > > Subject: Re: RFR : JDK-7132577 - > > > javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > > > > > > Hi Amit, > > > > > > On 23/02/2017 12:18 AM, Harsha Wardhana B wrote: > > > > Hi Amit, > > > > > > > > There is no need to wait in a loop to check we have not received > > any > > > > notifications. Without starting the monitors, the listener count > > > > will be zero. > > > > > > > > The first part of diff L116-L121 could be left as is. > > > > > > Agreed. > > > > > > > By relying on Jtreg timeout for receiving notifications, we will > > > > be unable to print the number of listeners emitted by each > Monitor. > > But > > > I > > > > guess there is no way to intercept a Jtreg timeout and print out > > > those > > > > values. > > > > > > You could print out the values every 1 second, or 5 or 10, ... at > > > least that way we can see what the values are when we timeout, and > > > also if they have been changing. > > > > > > Thanks, > > > David > > > > > > > Regards > > > > > > > > Harsha > > > > > > > > > > > > On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: > > > >> > > > >> Hello, > > > >> > > > >> > > > >> > > > >> Please review this test bug fix which eliminates test case's own > > > >> timeout mechanism to default jtreg timeout. > > > >> > > > >> > > > >> > > > >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 > > > >> > > > >> Webrev : > > > >> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > > > 7132577/webrev.00/ > > > >> > > 7132577/webrev. > > > >> 00/> > > > >> > > > >> > > > >> > > > >> Thanks, > > > >> > > > >> Amit > > > >> > > > > From david.holmes at oracle.com Thu Feb 23 07:38:02 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Feb 2017 17:38:02 +1000 Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: <19912c82-2cd7-4b29-b9bd-138167b4cb98@default> References: <88465114-5f74-4384-b114-6506b1f8441c@default> <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> <19912c82-2cd7-4b29-b9bd-138167b4cb98@default> Message-ID: Hi Amit, Just a couple of style nits: ! iterations++; ! ! if (10 == iterations) { => if (++iterations == 10) { -- ! iterations=0; => iterations = 0; Thanks, David On 23/02/2017 4:58 PM, Amit Sapre wrote: > Hello, > > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.02/ has the updated changes. > > I ran this test on my VM and roughly takes 250-300 ms to get all the listener count. > > Thanks, > Amit > >> -----Original Message----- >> From: Amit Sapre >> Sent: Thursday, February 23, 2017 11:55 AM >> To: David Holmes; serviceability-dev at openjdk.java.net; Harsha Wardhana >> B >> Subject: RE: RFR : JDK-7132577 - >> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 >> >> Hello, >> >> In a messy run of this test case, >> the number of prints for the counter values will be 240 (120 seconds is >> jtreg timeout) >> >> Will try to optimize this. Please hold on for a new webrev. >> >> Thanks, >> Amit >> >> >>> -----Original Message----- >>> From: Amit Sapre >>> Sent: Thursday, February 23, 2017 11:48 AM >>> To: David Holmes; serviceability-dev at openjdk.java.net; Harsha >> Wardhana >>> B >>> Subject: RE: RFR : JDK-7132577 - >>> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 >>> >>> Hello, >>> >>> Thanks David & Harsha for your inputs. >>> Here is the new webrev : >>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/ >>> >>> Thanks, >>> Amit >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Thursday, February 23, 2017 9:24 AM >>>> To: serviceability-dev at openjdk.java.net; Sapre Amit >>>> Cc: Harsha Wardhana B >>>> Subject: Re: RFR : JDK-7132577 - >>>> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 >>>> >>>> Hi Amit, >>>> >>>> On 23/02/2017 12:18 AM, Harsha Wardhana B wrote: >>>>> Hi Amit, >>>>> >>>>> There is no need to wait in a loop to check we have not received >>> any >>>>> notifications. Without starting the monitors, the listener count >>>>> will be zero. >>>>> >>>>> The first part of diff L116-L121 could be left as is. >>>> >>>> Agreed. >>>> >>>>> By relying on Jtreg timeout for receiving notifications, we will >>>>> be unable to print the number of listeners emitted by each >> Monitor. >>> But >>>> I >>>>> guess there is no way to intercept a Jtreg timeout and print out >>>> those >>>>> values. >>>> >>>> You could print out the values every 1 second, or 5 or 10, ... at >>>> least that way we can see what the values are when we timeout, and >>>> also if they have been changing. >>>> >>>> Thanks, >>>> David >>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>>> >>>>> On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> >>>>>> Please review this test bug fix which eliminates test case's own >>>>>> timeout mechanism to default jtreg timeout. >>>>>> >>>>>> >>>>>> >>>>>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 >>>>>> >>>>>> Webrev : >>>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- >>>> 7132577/webrev.00/ >>>>>> >>> 7132577/webrev. >>>>>> 00/> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Amit >>>>>> >>>>> From harsha.wardhana.b at oracle.com Thu Feb 23 08:00:30 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 23 Feb 2017 13:30:30 +0530 Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: <19912c82-2cd7-4b29-b9bd-138167b4cb98@default> References: <88465114-5f74-4384-b114-6506b1f8441c@default> <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> <19912c82-2cd7-4b29-b9bd-138167b4cb98@default> Message-ID: <182a6b70-4395-6a75-ba39-cb38b4d584e8@oracle.com> Looks good. -Harsha On Thursday 23 February 2017 12:28 PM, Amit Sapre wrote: > Hello, > > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.02/ has the updated changes. > > I ran this test on my VM and roughly takes 250-300 ms to get all the listener count. > > Thanks, > Amit > >> -----Original Message----- >> From: Amit Sapre >> Sent: Thursday, February 23, 2017 11:55 AM >> To: David Holmes; serviceability-dev at openjdk.java.net; Harsha Wardhana >> B >> Subject: RE: RFR : JDK-7132577 - >> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 >> >> Hello, >> >> In a messy run of this test case, >> the number of prints for the counter values will be 240 (120 seconds is >> jtreg timeout) >> >> Will try to optimize this. Please hold on for a new webrev. >> >> Thanks, >> Amit >> >> >>> -----Original Message----- >>> From: Amit Sapre >>> Sent: Thursday, February 23, 2017 11:48 AM >>> To: David Holmes; serviceability-dev at openjdk.java.net; Harsha >> Wardhana >>> B >>> Subject: RE: RFR : JDK-7132577 - >>> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 >>> >>> Hello, >>> >>> Thanks David & Harsha for your inputs. >>> Here is the new webrev : >>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.01/ >>> >>> Thanks, >>> Amit >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Thursday, February 23, 2017 9:24 AM >>>> To: serviceability-dev at openjdk.java.net; Sapre Amit >>>> Cc: Harsha Wardhana B >>>> Subject: Re: RFR : JDK-7132577 - >>>> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 >>>> >>>> Hi Amit, >>>> >>>> On 23/02/2017 12:18 AM, Harsha Wardhana B wrote: >>>>> Hi Amit, >>>>> >>>>> There is no need to wait in a loop to check we have not received >>> any >>>>> notifications. Without starting the monitors, the listener count >>>>> will be zero. >>>>> >>>>> The first part of diff L116-L121 could be left as is. >>>> Agreed. >>>> >>>>> By relying on Jtreg timeout for receiving notifications, we will >>>>> be unable to print the number of listeners emitted by each >> Monitor. >>> But >>>> I >>>>> guess there is no way to intercept a Jtreg timeout and print out >>>> those >>>>> values. >>>> You could print out the values every 1 second, or 5 or 10, ... at >>>> least that way we can see what the values are when we timeout, and >>>> also if they have been changing. >>>> >>>> Thanks, >>>> David >>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>>> >>>>> On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: >>>>>> Hello, >>>>>> >>>>>> >>>>>> >>>>>> Please review this test bug fix which eliminates test case's own >>>>>> timeout mechanism to default jtreg timeout. >>>>>> >>>>>> >>>>>> >>>>>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 >>>>>> >>>>>> Webrev : >>>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- >>>> 7132577/webrev.00/ >>>>>> >>> 7132577/webrev. >>>>>> 00/> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Amit >>>>>> From amit.sapre at oracle.com Fri Feb 24 06:07:08 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Thu, 23 Feb 2017 22:07:08 -0800 (PST) Subject: RFR : JDK-7132577 - javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 In-Reply-To: References: <88465114-5f74-4384-b114-6506b1f8441c@default> <688ae596-6b7d-fc5d-adb3-843130fe2343@oracle.com> <19912c82-2cd7-4b29-b9bd-138167b4cb98@default> Message-ID: <2ef28d40-4007-485d-86b2-1aaee45f2de4@default> Thanks David & Harsha, Fixed the nits in this webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.03/ Amit > -----Original Message----- > From: David Holmes > Sent: Thursday, February 23, 2017 1:08 PM > To: Amit Sapre; serviceability-dev at openjdk.java.net; Harsha Wardhana B > Subject: Re: RFR : JDK-7132577 - > javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > > Hi Amit, > > Just a couple of style nits: > > ! iterations++; > ! > ! if (10 == iterations) { > > => > > if (++iterations == 10) { > -- > > ! iterations=0; > > => > iterations = 0; > > Thanks, > David > > On 23/02/2017 4:58 PM, Amit Sapre wrote: > > Hello, > > > > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-7132577/webrev.02/ > has the updated changes. > > > > I ran this test on my VM and roughly takes 250-300 ms to get all the > listener count. > > > > Thanks, > > Amit > > > >> -----Original Message----- > >> From: Amit Sapre > >> Sent: Thursday, February 23, 2017 11:55 AM > >> To: David Holmes; serviceability-dev at openjdk.java.net; Harsha > >> Wardhana B > >> Subject: RE: RFR : JDK-7132577 - > >> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > >> > >> Hello, > >> > >> In a messy run of this test case, > >> the number of prints for the counter values will be 240 (120 seconds > >> is jtreg timeout) > >> > >> Will try to optimize this. Please hold on for a new webrev. > >> > >> Thanks, > >> Amit > >> > >> > >>> -----Original Message----- > >>> From: Amit Sapre > >>> Sent: Thursday, February 23, 2017 11:48 AM > >>> To: David Holmes; serviceability-dev at openjdk.java.net; Harsha > >> Wardhana > >>> B > >>> Subject: RE: RFR : JDK-7132577 - > >>> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > >>> > >>> Hello, > >>> > >>> Thanks David & Harsha for your inputs. > >>> Here is the new webrev : > >>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > 7132577/webrev.01 > >>> / > >>> > >>> Thanks, > >>> Amit > >>> > >>>> -----Original Message----- > >>>> From: David Holmes > >>>> Sent: Thursday, February 23, 2017 9:24 AM > >>>> To: serviceability-dev at openjdk.java.net; Sapre Amit > >>>> Cc: Harsha Wardhana B > >>>> Subject: Re: RFR : JDK-7132577 - > >>>> javax/management/monitor/MultiMonitorTest.java fails in JDK8-B22 > >>>> > >>>> Hi Amit, > >>>> > >>>> On 23/02/2017 12:18 AM, Harsha Wardhana B wrote: > >>>>> Hi Amit, > >>>>> > >>>>> There is no need to wait in a loop to check we have not received > >>> any > >>>>> notifications. Without starting the monitors, the listener count > >>>>> will be zero. > >>>>> > >>>>> The first part of diff L116-L121 could be left as is. > >>>> > >>>> Agreed. > >>>> > >>>>> By relying on Jtreg timeout for receiving notifications, we will > >>>>> be unable to print the number of listeners emitted by each > >> Monitor. > >>> But > >>>> I > >>>>> guess there is no way to intercept a Jtreg timeout and print out > >>>> those > >>>>> values. > >>>> > >>>> You could print out the values every 1 second, or 5 or 10, ... at > >>>> least that way we can see what the values are when we timeout, and > >>>> also if they have been changing. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> Regards > >>>>> > >>>>> Harsha > >>>>> > >>>>> > >>>>> On Wednesday 22 February 2017 03:29 PM, Amit Sapre wrote: > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Please review this test bug fix which eliminates test case's own > >>>>>> timeout mechanism to default jtreg timeout. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-7132577 > >>>>>> > >>>>>> Webrev : > >>>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > >>>> 7132577/webrev.00/ > >>>>>> >>>> 7132577/webrev. > >>>>>> 00/> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Amit > >>>>>> > >>>>> From daniel.fuchs at oracle.com Fri Feb 24 13:44:04 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 24 Feb 2017 13:44:04 +0000 Subject: Soften interface for javax.management.ObjectName.getInstance and friends In-Reply-To: <41720970-031e-6302-4056-d7301856b3c8@mebigfatguy.com> References: <41720970-031e-6302-4056-d7301856b3c8@mebigfatguy.com> Message-ID: Hi Dave, I'm not sure this is quite a good idea because order doesn't count when comparing ObjectNames. So the folder analogy would just be a lure: /a/b/c would be equal to /a/c/b That said - I can see value in trying to get rid of the legacy Hashtable - so adding a new method that takes a Map wouldn't necessarily be a bad thing :-) A work around for your use case would be to use: static ObjectName getInstance(String name) instead of static ObjectName getInstance(String domain Hashtable table) An object name has both a string representation and a canonical representation. IIRC we did try to preserve the original string representation, even if it's not canonical. It's also preserved in the serial form. See: https://docs.oracle.com/javase/8/docs/api/javax/management/ObjectName.html#getKeyPropertyListString-- Hope this helps, -- daniel On 24/02/17 00:17, Dave Brosius wrote: > Greetings. the method > > public static ObjectName getInstance(String domain, > Hashtable table) > throws MalformedObjectNameException { > return new ObjectName(domain, table); > } > > in javax.management.ObjectName allows for a provided Hashtable to > specify properties for the objectname. > > The semantics of an ObjectName don't consider the order of these > properties, however certain tools like jconsole (when used as a name for > a jmx property) does consider the order. > > If you wish to create a folder structure to report metrics in jmx, you > need to use this properties map to specify the folder names. JConsole, > then, uses order of iteration to determine the order of the folder > hierarchy. > > Suppose you want a folder hierarchy similar to a package name, you may > specify properties like > > table.put("a0", "com"); > table.put("a1", "acme"); > table.put("name", "MyMetric"); > > in hopes of producing a metric in JConsole in the folder structure, > com/acme/MyMetric. > > The problem is of course, that the argument is a Hashtable, not a Map, > and so the items are not ordered at all, yet JConsole uses iteration > order to build the path, so you may get > > acme/ao/MyMetric or MyMetric/acme/ao or ..... > > This means if you really want to have ordered packages, you have to > derive from Hashtable, and override the entrySet() method, including > that set's iterator() to return the values in the order you wish to have > them shown. > > That is really janky. > > I'm proposing that the interface for getInstance be softened to > > public static ObjectName getInstance(String domain, > Map table) > > as well as > > public ObjectName(String domain, Map table) > > thoughts? > From harsha.wardhana.b at oracle.com Sun Feb 26 16:50:07 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Sun, 26 Feb 2017 22:20:07 +0530 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters Message-ID: Hi All, Please review the below RFE, JDK-8007141 : Introduce Dynamic MBean exposing the perf counters. with webrev at, http://cr.openjdk.java.net/~hb/8007141/webrev.00/ Appreciate if I can get inputs for below. 1. Location of HotSpotPerfCounterMBean. It is located at src/jdk.management/share/classes/com/sun/management/internal. It can be moved to src/jdk.management/share/classes/com/sun/management if required. 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is adequate. 3. Description for each attribute of MBean. I am using getUnits(), getVariability(), and getFlags() for description. I am not sure if that is the right description. Appreciate inputs from someone who knows perf counters well. Thanks Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Mon Feb 27 05:01:27 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 27 Feb 2017 10:31:27 +0530 Subject: RFR: [SA testbug]: JDK-8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 Message-ID: Requesting a review for the one line fix for the following testbug: https://bugs.openjdk.java.net/browse/JDK-8175512 Webrev: http://cr.openjdk.java.net/~jgeorge/8175512/webrev.00/ Thanks, Jini. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Mon Feb 27 05:43:54 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Feb 2017 08:43:54 +0300 Subject: RFR: [SA testbug]: JDK-8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 In-Reply-To: References: Message-ID: Looks good to me! On 2017-02-27 08:01, Jini George wrote: > Requesting a review for the one line fix for the following testbug: > > https://bugs.openjdk.java.net/browse/JDK-8175512 > Webrev: http://cr.openjdk.java.net/~jgeorge/8175512/webrev.00/ > > Thanks, > Jini. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Mon Feb 27 08:04:14 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 27 Feb 2017 13:34:14 +0530 Subject: RFR: [SA testbug]: JDK-8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 In-Reply-To: References: Message-ID: Thank you, Dmitry! -jini On 2/27/2017 11:13 AM, Dmitry Samersoff wrote: > Looks good to me! > > On 2017-02-27 08:01, Jini George wrote: >> Requesting a review for the one line fix for the following testbug: >> >> https://bugs.openjdk.java.net/browse/JDK-8175512 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8175512/webrev.00/ >> >> Thanks, >> Jini. > From serguei.spitsyn at oracle.com Mon Feb 27 09:33:23 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Feb 2017 01:33:23 -0800 Subject: RFR: [SA testbug]: JDK-8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 In-Reply-To: References: Message-ID: <470ccdc1-768a-c12c-6579-489d43be092a@oracle.com> +1 Thanks, Serguei On 2/26/17 21:43, Dmitry Samersoff wrote: > Looks good to me! > > On 2017-02-27 08:01, Jini George wrote: >> Requesting a review for the one line fix for the following testbug: >> >> https://bugs.openjdk.java.net/browse/JDK-8175512 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8175512/webrev.00/ >> >> Thanks, >> Jini. > From jini.george at oracle.com Mon Feb 27 13:25:17 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 27 Feb 2017 18:55:17 +0530 Subject: RFR: [SA testbug]: JDK-8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 In-Reply-To: <470ccdc1-768a-c12c-6579-489d43be092a@oracle.com> References: <470ccdc1-768a-c12c-6579-489d43be092a@oracle.com> Message-ID: Thank you, Serguei! -jini On 2/27/2017 3:03 PM, serguei.spitsyn at oracle.com wrote: > +1 > > Thanks, > Serguei > > > On 2/26/17 21:43, Dmitry Samersoff wrote: >> Looks good to me! >> >> On 2017-02-27 08:01, Jini George wrote: >>> Requesting a review for the one line fix for the following testbug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8175512 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8175512/webrev.00/ >>> >>> Thanks, >>> Jini. >> > From erik.gahlin at oracle.com Mon Feb 27 14:09:51 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 27 Feb 2017 15:09:51 +0100 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters In-Reply-To: References: Message-ID: <58B4332F.3020608@oracle.com> Hi Harsha, How will perf counters be supported? Can they be removed at anytime, or only at major releases etc. Do we have tests for them? I think it would be good know, and perhaps state somewhere so we don't break people's code. Erik > Hi All, > > Please review the below RFE, > > JDK-8007141 : Introduce Dynamic MBean exposing > the perf counters. > > with webrev at, > > http://cr.openjdk.java.net/~hb/8007141/webrev.00/ > > Appreciate if I can get inputs for below. > > 1. Location of HotSpotPerfCounterMBean. It is located at > src/jdk.management/share/classes/com/sun/management/internal. It can > be moved to src/jdk.management/share/classes/com/sun/management if > required. > > 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is > adequate. > > 3. Description for each attribute of MBean. I am using getUnits(), > getVariability(), and getFlags() for description. I am not sure if > that is the right description. Appreciate inputs from someone who > knows perf counters well. > > Thanks > > Harsha > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Mon Feb 27 14:57:00 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 27 Feb 2017 20:27:00 +0530 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters In-Reply-To: <58B4332F.3020608@oracle.com> References: <58B4332F.3020608@oracle.com> Message-ID: <6f3c6d15-1323-854d-8775-031bbdec6c23@oracle.com> Hi Erik, I am not sure if Perf Counters could be disabled. If yes, then PerfCounter MBean must throw appropriate exception while getting MBeanInfo. I don't know about tests for PerfCounter. The webrev contains tests for PerfCounter MBean. I am not sure how we will be breaking other's code. Could you please elaborate? Thanks Harsha On Monday 27 February 2017 07:39 PM, Erik Gahlin wrote: > Hi Harsha, > > How will perf counters be supported? > > Can they be removed at anytime, or only at major releases etc. Do we > have tests for them? I think it would be good know, and perhaps state > somewhere so we don't break people's code. > > Erik > >> Hi All, >> >> Please review the below RFE, >> >> JDK-8007141 : Introduce Dynamic MBean exposing >> the perf counters. >> >> with webrev at, >> >> http://cr.openjdk.java.net/~hb/8007141/webrev.00/ >> >> Appreciate if I can get inputs for below. >> >> 1. Location of HotSpotPerfCounterMBean. It is located at >> src/jdk.management/share/classes/com/sun/management/internal. It can >> be moved to src/jdk.management/share/classes/com/sun/management if >> required. >> >> 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is >> adequate. >> >> 3. Description for each attribute of MBean. I am using getUnits(), >> getVariability(), and getFlags() for description. I am not sure if >> that is the right description. Appreciate inputs from someone who >> knows perf counters well. >> >> Thanks >> >> Harsha >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Mon Feb 27 17:52:43 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 27 Feb 2017 18:52:43 +0100 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters In-Reply-To: <6f3c6d15-1323-854d-8775-031bbdec6c23@oracle.com> References: <58B4332F.3020608@oracle.com> <6f3c6d15-1323-854d-8775-031bbdec6c23@oracle.com> Message-ID: <58B4676B.6070202@oracle.com> If somebody writes a tool that plots the values that the perf counters provide, which is bound to happen if it is exposed via JMX, but then the internals of the JVM is changed and the perf counter value is removed or it is incorrect. Erik > Hi Erik, > > I am not sure if Perf Counters could be disabled. If yes, then > PerfCounter MBean must throw appropriate exception while getting > MBeanInfo. > > I don't know about tests for PerfCounter. The webrev contains tests > for PerfCounter MBean. > > I am not sure how we will be breaking other's code. Could you please > elaborate? > > Thanks > Harsha > > On Monday 27 February 2017 07:39 PM, Erik Gahlin wrote: >> Hi Harsha, >> >> How will perf counters be supported? >> >> Can they be removed at anytime, or only at major releases etc. Do we >> have tests for them? I think it would be good know, and perhaps state >> somewhere so we don't break people's code. >> >> Erik >> >>> Hi All, >>> >>> Please review the below RFE, >>> >>> JDK-8007141 : Introduce Dynamic MBean exposing >>> the perf counters. >>> >>> with webrev at, >>> >>> http://cr.openjdk.java.net/~hb/8007141/webrev.00/ >>> >>> Appreciate if I can get inputs for below. >>> >>> 1. Location of HotSpotPerfCounterMBean. It is located at >>> src/jdk.management/share/classes/com/sun/management/internal. It can >>> be moved to src/jdk.management/share/classes/com/sun/management if >>> required. >>> >>> 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is >>> adequate. >>> >>> 3. Description for each attribute of MBean. I am using getUnits(), >>> getVariability(), and getFlags() for description. I am not sure if >>> that is the right description. Appreciate inputs from someone who >>> knows perf counters well. >>> >>> Thanks >>> >>> Harsha >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Feb 28 04:52:07 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 28 Feb 2017 10:22:07 +0530 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters In-Reply-To: <58B4676B.6070202@oracle.com> References: <58B4332F.3020608@oracle.com> <6f3c6d15-1323-854d-8775-031bbdec6c23@oracle.com> <58B4676B.6070202@oracle.com> Message-ID: <0b263c01-3bcf-fd7d-dcd2-dc6ea7ed892d@oracle.com> Perfcounter are dynamic and can change. Applications must be aware of that and work around it. Perf counters being dynamic must be documented and must not be a deterrent for consuming them (via Dymanic MBean). Regards Harsha On Monday 27 February 2017 11:22 PM, Erik Gahlin wrote: > If somebody writes a tool that plots the values that the perf counters > provide, which is bound to happen if it is exposed via JMX, but then > the internals of the JVM is changed and the perf counter value is > removed or it is incorrect. > > Erik > >> Hi Erik, >> >> I am not sure if Perf Counters could be disabled. If yes, then >> PerfCounter MBean must throw appropriate exception while getting >> MBeanInfo. >> >> I don't know about tests for PerfCounter. The webrev contains tests >> for PerfCounter MBean. >> >> I am not sure how we will be breaking other's code. Could you please >> elaborate? >> >> Thanks >> Harsha >> >> On Monday 27 February 2017 07:39 PM, Erik Gahlin wrote: >>> Hi Harsha, >>> >>> How will perf counters be supported? >>> >>> Can they be removed at anytime, or only at major releases etc. Do we >>> have tests for them? I think it would be good know, and perhaps >>> state somewhere so we don't break people's code. >>> >>> Erik >>> >>>> Hi All, >>>> >>>> Please review the below RFE, >>>> >>>> JDK-8007141 : Introduce Dynamic MBean exposing >>>> the perf counters. >>>> >>>> with webrev at, >>>> >>>> http://cr.openjdk.java.net/~hb/8007141/webrev.00/ >>>> >>>> Appreciate if I can get inputs for below. >>>> >>>> 1. Location of HotSpotPerfCounterMBean. It is located at >>>> src/jdk.management/share/classes/com/sun/management/internal. It >>>> can be moved to src/jdk.management/share/classes/com/sun/management >>>> if required. >>>> >>>> 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is >>>> adequate. >>>> >>>> 3. Description for each attribute of MBean. I am using getUnits(), >>>> getVariability(), and getFlags() for description. I am not sure if >>>> that is the right description. Appreciate inputs from someone who >>>> knows perf counters well. >>>> >>>> Thanks >>>> >>>> Harsha >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Feb 28 07:06:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Feb 2017 17:06:41 +1000 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters In-Reply-To: References: Message-ID: <4663ef4b-2700-71ed-bac5-9fdfe40b204f@oracle.com> Hi Harsha, Not a review :) On 27/02/2017 2:50 AM, Harsha Wardhana B wrote: > Hi All, > > Please review the below RFE, > > JDK-8007141 : Introduce Dynamic MBean exposing the > perf counters. What perf counters are these and where/how are they currently documented? They may be affected by the UsePerfData VM flag (which some/most of the management code seems to be ignorant of). Thanks, David ----- > with webrev at, > > http://cr.openjdk.java.net/~hb/8007141/webrev.00/ > > Appreciate if I can get inputs for below. > > 1. Location of HotSpotPerfCounterMBean. It is located at > src/jdk.management/share/classes/com/sun/management/internal. It can be > moved to src/jdk.management/share/classes/com/sun/management if required. > > 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is adequate. > > 3. Description for each attribute of MBean. I am using getUnits(), > getVariability(), and getFlags() for description. I am not sure if that > is the right description. Appreciate inputs from someone who knows perf > counters well. > > Thanks > > Harsha > > From dmitry.samersoff at oracle.com Tue Feb 28 09:41:17 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 28 Feb 2017 12:41:17 +0300 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only Message-ID: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> Everybody, Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ These changes introduce new parameter[1] of the socket transport - allow. Users can explicitly specify a list of hosts that allowed to connect to jdwp server and it's the second part of JDWP hardening[2]. No restrictions are applied by default now but I'll file a separate CR to restrict list of allowed peers to localhost by default. Also these changes implement versioning for jdwp transport and therefor simplify feature development of jdwp. 1. Example command line: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, address=*,allow="127.0.0.0/8;192.168.0.0/24" Possible values for allow parameter: * - accept connections from everywhere. N.N.N.N - accept connections from this IP address only N.N.N.N/nn - accept connections from particular ip subnet 2. JDK-8052136 JDWP hardening -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From harsha.wardhana.b at oracle.com Tue Feb 28 10:27:15 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 28 Feb 2017 15:57:15 +0530 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters In-Reply-To: <4663ef4b-2700-71ed-bac5-9fdfe40b204f@oracle.com> References: <4663ef4b-2700-71ed-bac5-9fdfe40b204f@oracle.com> Message-ID: <971a16a2-d93b-6a23-0df3-6d53ab571ac9@oracle.com> Hi David, Performance counters are specific to Hotspot and can be dumped via JCMD as documented below. https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr006.html I could not find any documentation as to what each performance counter means. But I know JMXServiceURL is published as one of perf counter. I don't think UsePerfData vm flag has any effect on perf counters. @see https://bugs.openjdk.java.net/browse/JDK-8069149 Regards Harsha P.S. Below is the list of perf counters I was able to dump. java.ci.totalTime --> 9894679495 java.cls.loadedClasses --> 2104 java.cls.sharedLoadedClasses --> 0 java.cls.sharedUnloadedClasses --> 0 java.cls.unloadedClasses --> 0 java.property.java.class.path --> /home/harsha/work/jdk10_PerfCounter/build/linux-x86_64-normal-server-fastdebug/nb-jtreg/work/classes/java/lang/management:/home/harsha/work/jdk10_PerfCounter/jdk/test/java/lang/management:/home/harsha/netbeans-8.2/platform/modules/ext/testng-6.8.1-dist.jar:/home/harsha/.netbeans/8.2/modules/ext/javatest.jar:/home/harsha/.netbeans/8.2/modules/ext/jtreg.jar java.property.java.home --> /home/harsha/work/jdk10_PerfCounter/build/linux-x86_64-normal-server-fastdebug/jdk java.property.java.library.path --> /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib java.property.java.version --> 10-internal java.property.java.vm.info --> mixed mode java.property.java.vm.name --> Java HotSpot(TM) 64-Bit Server VM java.property.java.vm.specification.name --> Java Virtual Machine Specification java.property.java.vm.specification.vendor --> Oracle Corporation java.property.java.vm.specification.version --> 10 java.property.java.vm.vendor --> Oracle Corporation java.property.java.vm.version --> 10-internal+0-adhoc.harsha.jdk10PerfCounter java.property.jdk.debug --> fastdebug java.rt.vmArgs --> -Dtest.src=/home/harsha/work/jdk10_PerfCounter/jdk/test/java/lang/management -Dtest.src.path=/home/harsha/work/jdk10_PerfCounter/jdk/test/java/lang/management -Dtest.classes=/home/harsha/work/jdk10_PerfCounter/build/linux-x86_64-normal-server-fastdebug/nb-jtreg/work/classes/java/lang/management -Dtest.class.path=/home/harsha/work/jdk10_PerfCounter/build/linux-x86_64-normal-server-fastdebug/nb-jtreg/work/classes/java/lang/management -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts=-g -Dtest.java.opts= -Dtest.jdk=/home/harsha/work/jdk10_PerfCounter/build/linux-x86_64-normal-server-fastdebug/jdk -Dcompile.jdk=/home/harsha/work/jdk10_PerfCounter/build/linux-x86_64-normal-server-fastdebug/jdk -Dtest.timeout.factor=10.0 -Dtest.modules=java.management java.rt.vmFlags --> java.threads.daemon --> 4 java.threads.live --> 6 java.threads.livePeak --> 6 java.threads.started --> 6 jdk.module.bootstrap.defineBaseTime --> 2435193646 jdk.module.bootstrap.layerCreateTime --> 13317562 jdk.module.bootstrap.loadModulesTime --> 14338283 jdk.module.bootstrap.optionsAndRootsTime --> 17304889 jdk.module.bootstrap.resolveTime --> 55133833 jdk.module.bootstrap.systemModulesTime --> 41492856 jdk.module.bootstrap.totalTime --> 2593369105 jdk.module.finder.modulepath.modules --> 81 jdk.module.finder.modulepath.scanTime --> 2415452842 sun.ci.lastFailedMethod --> java/nio/file/FileTreeIterator fetchNextIfNeeded sun.ci.lastFailedType --> 1 sun.ci.lastInvalidatedMethod --> sun.ci.lastInvalidatedType --> 0 sun.ci.lastMethod --> java/lang/invoke/MemberName$Factory resolveOrFail sun.ci.lastSize --> 66 sun.ci.lastType --> 1 sun.ci.nmethodBucketsAllocated --> 453 sun.ci.nmethodBucketsDeallocated --> 0 sun.ci.nmethodBucketsStale --> 0 sun.ci.nmethodBucketsStaleAccumulated --> 0 sun.ci.nmethodCodeSize --> 2033472 sun.ci.nmethodSize --> 3243232 sun.ci.osrBytes --> 3066 sun.ci.osrCompiles --> 15 sun.ci.osrTime --> 330004625 sun.ci.standardBytes --> 118206 sun.ci.standardCompiles --> 1139 sun.ci.standardTime --> 9652101881 sun.ci.threads --> 3 sun.ci.totalBailouts --> 2 sun.ci.totalCompiles --> 1154 sun.ci.totalInvalidates --> 0 sun.classloader.findClassTime --> 2068382 sun.classloader.findClasses --> 1 sun.classloader.parentDelegationTime --> 23310 sun.cls.appClassBytes --> 945293 sun.cls.appClassLoadCount --> 360 sun.cls.appClassLoadTime --> 664947306 sun.cls.appClassLoadTime.self --> 412849295 sun.cls.classInitTime --> 1102258326 sun.cls.classInitTime.self --> 976802405 sun.cls.classLinkedTime --> 680729996 sun.cls.classLinkedTime.self --> 430206421 sun.cls.classVerifyTime --> 252472122 sun.cls.classVerifyTime.self --> 105603174 sun.cls.defineAppClassTime --> 273298992 sun.cls.defineAppClassTime.self --> 257133022 sun.cls.defineAppClasses --> 261 sun.cls.initializedClasses --> 1732 sun.cls.isUnsyncloadClassSet --> 0 sun.cls.jniDefineClassNoLockCalls --> 0 sun.cls.jvmDefineClassNoLockCalls --> 225 sun.cls.jvmFindLoadedClassNoLockCalls --> 582 sun.cls.linkedClasses --> 1960 sun.cls.loadInstanceClassFailRate --> 0 sun.cls.loadedBytes --> 4041536 sun.cls.lookupSysClassTime --> 0 sun.cls.methodBytes --> 2346336 sun.cls.nonSystemLoaderLockContentionRate --> 0 sun.cls.parseClassTime --> 0 sun.cls.parseClassTime.self --> 0 sun.cls.sharedClassLoadTime --> 396807 sun.cls.sharedLoadedBytes --> 0 sun.cls.sharedUnloadedBytes --> 0 sun.cls.sysClassBytes --> 6782757 sun.cls.sysClassLoadTime --> 586961829 sun.cls.systemLoaderLockContentionRate --> 0 sun.cls.time --> 2182594317 sun.cls.unloadedBytes --> 0 sun.cls.unsafeDefineClassCalls --> 390 sun.cls.verifiedClasses --> 182 sun.gc.cause --> No GC sun.gc.collector.0.invocations --> 1 sun.gc.collector.0.lastEntryTime --> 1132440403 sun.gc.collector.0.lastExitTime --> 1140612084 sun.gc.collector.0.name --> G1 incremental collections sun.gc.collector.0.time --> 8172070 sun.gc.collector.1.invocations --> 0 sun.gc.collector.1.lastEntryTime --> 0 sun.gc.collector.1.lastExitTime --> 0 sun.gc.collector.1.name --> G1 stop-the-world full collections sun.gc.collector.1.time --> 0 sun.gc.compressedclassspace.capacity --> 655360 sun.gc.compressedclassspace.maxCapacity --> 1073741824 sun.gc.compressedclassspace.minCapacity --> 0 sun.gc.compressedclassspace.used --> 514992 sun.gc.generation.0.agetable.bytes.00 --> 0 sun.gc.generation.0.agetable.bytes.01 --> 555624 sun.gc.generation.0.agetable.bytes.02 --> 0 sun.gc.generation.0.agetable.bytes.03 --> 0 sun.gc.generation.0.agetable.bytes.04 --> 0 sun.gc.generation.0.agetable.bytes.05 --> 0 sun.gc.generation.0.agetable.bytes.06 --> 0 sun.gc.generation.0.agetable.bytes.07 --> 0 sun.gc.generation.0.agetable.bytes.08 --> 0 sun.gc.generation.0.agetable.bytes.09 --> 0 sun.gc.generation.0.agetable.bytes.10 --> 0 sun.gc.generation.0.agetable.bytes.11 --> 0 sun.gc.generation.0.agetable.bytes.12 --> 0 sun.gc.generation.0.agetable.bytes.13 --> 0 sun.gc.generation.0.agetable.bytes.14 --> 0 sun.gc.generation.0.agetable.bytes.15 --> 0 sun.gc.generation.0.agetable.size --> 16 sun.gc.generation.0.capacity --> 165675032 sun.gc.generation.0.maxCapacity --> 4179623960 sun.gc.generation.0.minCapacity --> 24 sun.gc.generation.0.name --> young sun.gc.generation.0.space.0.capacity --> 164626440 sun.gc.generation.0.space.0.initCapacity --> 15728648 sun.gc.generation.0.space.0.maxCapacity --> 4179623944 sun.gc.generation.0.space.0.name --> eden sun.gc.generation.0.space.0.used --> 144703488 sun.gc.generation.0.space.1.capacity --> 8 sun.gc.generation.0.space.1.initCapacity --> 8 sun.gc.generation.0.space.1.maxCapacity --> 8 sun.gc.generation.0.space.1.name --> s0 sun.gc.generation.0.space.1.used --> 0 sun.gc.generation.0.space.2.capacity --> 1048584 sun.gc.generation.0.space.2.initCapacity --> 8 sun.gc.generation.0.space.2.maxCapacity --> 4179623944 sun.gc.generation.0.space.2.name --> s1 sun.gc.generation.0.space.2.used --> 1048576 sun.gc.generation.0.spaces --> 3 sun.gc.generation.1.capacity --> 96469000 sun.gc.generation.1.maxCapacity --> 4179623944 sun.gc.generation.1.minCapacity --> 8 sun.gc.generation.1.name --> old sun.gc.generation.1.space.0.capacity --> 96469000 sun.gc.generation.1.space.0.initCapacity --> 246415368 sun.gc.generation.1.space.0.maxCapacity --> 4179623944 sun.gc.generation.1.space.0.name --> space sun.gc.generation.1.space.0.used --> 0 sun.gc.generation.1.spaces --> 1 sun.gc.lastCause --> G1 Evacuation Pause sun.gc.metaspace.capacity --> 6160384 sun.gc.metaspace.maxCapacity --> 1082130432 sun.gc.metaspace.minCapacity --> 0 sun.gc.metaspace.used --> 5701904 sun.gc.policy.collectors --> 1 sun.gc.policy.desiredSurvivorSize --> 1048576 sun.gc.policy.generations --> 3 sun.gc.policy.maxTenuringThreshold --> 15 sun.gc.policy.name --> GarbageFirst sun.gc.policy.tenuringThreshold --> 15 sun.gc.tlab.alloc --> 2532300 sun.gc.tlab.allocThreads --> 3 sun.gc.tlab.fastWaste --> 0 sun.gc.tlab.fills --> 69 sun.gc.tlab.gcWaste --> 73306 sun.gc.tlab.maxFastWaste --> 0 sun.gc.tlab.maxFills --> 67 sun.gc.tlab.maxGcWaste --> 36674 sun.gc.tlab.maxSlowAlloc --> 0 sun.gc.tlab.maxSlowWaste --> 5028 sun.gc.tlab.slowAlloc --> 0 sun.gc.tlab.slowWaste --> 5028 sun.os.hrt.frequency --> 1000000000 sun.os.hrt.ticks --> 6279815676 sun.property.sun.boot.library.path --> /home/harsha/work/jdk10_PerfCounter/build/linux-x86_64-normal-server-fastdebug/jdk/lib sun.rt._sync_ContendedLockAttempts --> 0 sun.rt._sync_Deflations --> 3 sun.rt._sync_EmptyNotifications --> 0 sun.rt._sync_FailedSpins --> 0 sun.rt._sync_FutileWakeups --> 0 sun.rt._sync_Inflations --> 8 sun.rt._sync_MonExtant --> 4 sun.rt._sync_MonInCirculation --> 0 sun.rt._sync_MonScavenged --> 0 sun.rt._sync_Notifications --> 2 sun.rt._sync_Parks --> 2 sun.rt._sync_PrivateA --> 0 sun.rt._sync_PrivateB --> 0 sun.rt._sync_SlowEnter --> 0 sun.rt._sync_SlowExit --> 0 sun.rt._sync_SlowNotify --> 0 sun.rt._sync_SlowNotifyAll --> 0 sun.rt._sync_SuccessfulSpins --> 0 sun.rt.applicationTime --> 4337190130 sun.rt.createVmBeginTime --> 1488277242189 sun.rt.createVmEndTime --> 1488277244988 sun.rt.internalVersion --> Java HotSpot(TM) 64-Bit Server VM (fastdebug 10-internal+0-adhoc.harsha.jdk10PerfCounter) for linux-amd64 JRE (10-internal+0-adhoc.harsha.jdk10PerfCounter), built on Feb 25 2017 22:24:55 by "harsha" with gcc 5.4.0 20160609 sun.rt.javaCommand --> com.sun.javatest.regtest.agent.MainWrapper /home/harsha/work/jdk10_PerfCounter/build/linux-x86_64-normal-server-fastdebug/nb-jtreg/work/java/lang/management/PerfCounterMBeanTest.d/testng.0.jta java/lang/management/PerfCounterMBeanTest.java PerfCounterMBeanTest sun.rt.jvmCapabilities --> 1100000000000000000000000000000000000000000000000000000000000000 sun.rt.jvmVersion --> 167772160 sun.rt.safepointSyncTime --> 35150781 sun.rt.safepointTime --> 44606495 sun.rt.safepoints --> 9 sun.rt.vmInitDoneTime --> 1488277242348 sun.threads.vmOperationTime --> 8730462 sun.urlClassLoader.readClassBytesTime --> 0 sun.zip.zipFile.openTime --> 32909964 sun.zip.zipFiles --> 3 On Tuesday 28 February 2017 12:36 PM, David Holmes wrote: > Hi Harsha, > > Not a review :) > > On 27/02/2017 2:50 AM, Harsha Wardhana B wrote: >> Hi All, >> >> Please review the below RFE, >> >> JDK-8007141 : Introduce Dynamic MBean exposing the >> perf counters. > > What perf counters are these and where/how are they currently documented? > > They may be affected by the UsePerfData VM flag (which some/most of > the management code seems to be ignorant of). > > Thanks, > David > ----- > >> with webrev at, >> >> http://cr.openjdk.java.net/~hb/8007141/webrev.00/ >> >> Appreciate if I can get inputs for below. >> >> 1. Location of HotSpotPerfCounterMBean. It is located at >> src/jdk.management/share/classes/com/sun/management/internal. It can be >> moved to src/jdk.management/share/classes/com/sun/management if >> required. >> >> 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is >> adequate. >> >> 3. Description for each attribute of MBean. I am using getUnits(), >> getVariability(), and getFlags() for description. I am not sure if that >> is the right description. Appreciate inputs from someone who knows perf >> counters well. >> >> Thanks >> >> Harsha >> >>