From serguei.spitsyn at oracle.com Fri Aug 1 00:29:27 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jul 2014 17:29:27 -0700 Subject: RFR (S) 7187999: dtrace jstack action is broken Message-ID: <53DADF67.1040508@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-7187999 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 Summary: The DTrace jstack action support was broken for several years. The issue came when the build flag -Xlazyload was added by request from the Solaris team. This flag was necessary to resolve a performance issue. The jstack action stopped working as the jhelper.d was loaded lazily as well. The idea of this fix was suggested by Junsang Cho from the Solaris team. The jhelper.d and hotspot probes (other USDT scripts) are separated into two different SUNW_DOF sections. Now the jhelper.d is built without the -Xlazyload flag. Testing: Running the adhoc dtrace tests on Solaris sparcv9 and amd64 Thanks, Serguei From serguei.spitsyn at oracle.com Fri Aug 1 00:45:45 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jul 2014 17:45:45 -0700 Subject: RFR(XS): JDK-8049049 Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp In-Reply-To: <53D3837A.8050407@oracle.com> References: <53D3837A.8050407@oracle.com> Message-ID: <53DAE339.8010804@oracle.com> Dmitry, It looks good. Thanks, Serguei On 7/26/14 3:31 AM, Dmitry Samersoff wrote: > Hi Everybody, > > Please review an one line fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8049049/webrev.01/ > > From serguei.spitsyn at oracle.com Fri Aug 1 00:48:03 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jul 2014 17:48:03 -0700 Subject: RFR(S): Warning from b62 for hotspot.agent.src.os.solaris.proc: use after free In-Reply-To: <53D66A25.8090209@oracle.com> References: <53D66A25.8090209@oracle.com> Message-ID: <53DAE3C3.4040402@oracle.com> This looks good. Thanks, Serguei On 7/28/14 8:20 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Please review small fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8025667/webrev.01 > > Move free() call few lines down. It is not necessary at ll. 666, but I > move it as well to keep pattern. > > -Dmitry > From david.holmes at oracle.com Fri Aug 1 07:23:47 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Aug 2014 17:23:47 +1000 Subject: RFR (S) 7187999: dtrace jstack action is broken In-Reply-To: <53DADF67.1040508@oracle.com> References: <53DADF67.1040508@oracle.com> Message-ID: <53DB4083.7090204@oracle.com> Hi Serguei, This seems reasonable. One nit: 355 $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -G -o $@ -s $(DTRACE_JHELPER).d There should be a $(QUIETLY) in front of that. Also the copyright year needs updating. Thanks, David On 1/08/2014 10:29 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-7187999 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 > > > Summary: > > The DTrace jstack action support was broken for several years. > The issue came when the build flag -Xlazyload was added by request > from the Solaris team. > This flag was necessary to resolve a performance issue. > The jstack action stopped working as the jhelper.d was loaded lazily > as well. > > The idea of this fix was suggested by Junsang Cho from the Solaris team. > The jhelper.d and hotspot probes (other USDT scripts) are separated > into two different SUNW_DOF sections. > Now the jhelper.d is built without the -Xlazyload flag. > > Testing: > Running the adhoc dtrace tests on Solaris sparcv9 and amd64 > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Fri Aug 1 08:15:32 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 01 Aug 2014 01:15:32 -0700 Subject: RFR (S) 7187999: dtrace jstack action is broken In-Reply-To: <53DB4083.7090204@oracle.com> References: <53DADF67.1040508@oracle.com> <53DB4083.7090204@oracle.com> Message-ID: <53DB4CA4.9050108@oracle.com> Hi David, I'll fix this. Thank you for the review! Serguei On 8/1/14 12:23 AM, David Holmes wrote: > Hi Serguei, > > This seems reasonable. One nit: > > 355 $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -G -o $@ -s > $(DTRACE_JHELPER).d > > There should be a $(QUIETLY) in front of that. > > Also the copyright year needs updating. > > Thanks, > David > > On 1/08/2014 10:29 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-7187999 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 >> >> >> >> Summary: >> >> The DTrace jstack action support was broken for several years. >> The issue came when the build flag -Xlazyload was added by request >> from the Solaris team. >> This flag was necessary to resolve a performance issue. >> The jstack action stopped working as the jhelper.d was loaded lazily >> as well. >> >> The idea of this fix was suggested by Junsang Cho from the Solaris >> team. >> The jhelper.d and hotspot probes (other USDT scripts) are separated >> into two different SUNW_DOF sections. >> Now the jhelper.d is built without the -Xlazyload flag. >> >> Testing: >> Running the adhoc dtrace tests on Solaris sparcv9 and amd64 >> >> >> Thanks, >> Serguei From dmitry.samersoff at oracle.com Fri Aug 1 08:25:43 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 01 Aug 2014 12:25:43 +0400 Subject: RFR (S) 7187999: dtrace jstack action is broken In-Reply-To: <53DADF67.1040508@oracle.com> References: <53DADF67.1040508@oracle.com> Message-ID: <53DB4F07.10504@oracle.com> Serguei, Looks good for me. Could you put comments below into makefile? -Dmitry On 2014-08-01 04:29, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-7187999 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 > > > Summary: > > The DTrace jstack action support was broken for several years. > The issue came when the build flag -Xlazyload was added by request > from the Solaris team. > This flag was necessary to resolve a performance issue. > The jstack action stopped working as the jhelper.d was loaded lazily > as well. > > The idea of this fix was suggested by Junsang Cho from the Solaris team. > The jhelper.d and hotspot probes (other USDT scripts) are separated > into two different SUNW_DOF sections. > Now the jhelper.d is built without the -Xlazyload flag. > > Testing: > Running the adhoc dtrace tests on Solaris sparcv9 and amd64 > > > Thanks, > Serguei -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Aug 1 08:41:49 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 01 Aug 2014 01:41:49 -0700 Subject: RFR (S) 7187999: dtrace jstack action is broken In-Reply-To: <53DB4F07.10504@oracle.com> References: <53DADF67.1040508@oracle.com> <53DB4F07.10504@oracle.com> Message-ID: <53DB52CD.9020104@oracle.com> Dmitry, I'll add a part of the comment into make file. Thank you for the review! Serguei On 8/1/14 1:25 AM, Dmitry Samersoff wrote: > Serguei, > > Looks good for me. > > Could you put comments below into makefile? > > -Dmitry > > On 2014-08-01 04:29, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-7187999 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 >> >> >> Summary: >> >> The DTrace jstack action support was broken for several years. >> The issue came when the build flag -Xlazyload was added by request >> from the Solaris team. >> This flag was necessary to resolve a performance issue. >> The jstack action stopped working as the jhelper.d was loaded lazily >> as well. >> >> The idea of this fix was suggested by Junsang Cho from the Solaris team. >> The jhelper.d and hotspot probes (other USDT scripts) are separated >> into two different SUNW_DOF sections. >> Now the jhelper.d is built without the -Xlazyload flag. >> >> Testing: >> Running the adhoc dtrace tests on Solaris sparcv9 and amd64 >> >> >> Thanks, >> Serguei > From jaroslav.bachorik at oracle.com Fri Aug 1 09:10:08 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 01 Aug 2014 11:10:08 +0200 Subject: RFR(XS): JDK-8049049 Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp In-Reply-To: <53DAE339.8010804@oracle.com> References: <53D3837A.8050407@oracle.com> <53DAE339.8010804@oracle.com> Message-ID: <53DB5970.4050509@oracle.com> Looks fine. I suppose the (void *) pointer would always be 64bit. -JB- On 08/01/2014 02:45 AM, serguei.spitsyn at oracle.com wrote: > Dmitry, > > It looks good. > > Thanks, > Serguei > > On 7/26/14 3:31 AM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review an one line fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8049049/webrev.01/ >> >> > From maynardj at us.ibm.com Thu Aug 7 13:43:58 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Thu, 07 Aug 2014 08:43:58 -0500 Subject: Problem generating C header file for Hotspot debugger PPC64ThreadContext class Message-ID: <53E3829E.6000204@us.ibm.com> Hi, all, I've begun adding ppc64 support for the serviceability tools that take a java core file as input (jmap, jstack). See my original July 3 posting to ppc-aix-port-dev (subject "PowerPC: core file option not available with serviceability tools") for reference. I've created a number of new ppc64-specific Java classes within sun.jvm.hotspot.debugger.*, but am now running into a build issue that I've not been able to resolve. The build error is as follows: --------------- Compiling /home/mpj/jdk9-dev/hotspot/src/share/vm/runtime/vm_version.cpp Making SA debugger back-end... /home/mpj/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c:53:63: fatal error: sun_jvm_hotspot_debugger_ppc64_PPC64ThreadContext.h: No such file or directory #include "sun_jvm_hotspot_debugger_ppc64_PPC64ThreadContext.h" ^ compilation terminated. --------------- The crux of the problem is that this missing header file is not being generated earlier in the build, when the other arch-specific ThreadContext headers (X86, AMD64, and SPARC) are built. These headers are generated into build/linux-ppc64-normal-server-release/hotspot/linux_ppc64_compiler2/generated. I had found hotspot/agent/src/os/linux/Makefile where there's a target defined to use 'javah' for generating header files from the *ThreadContext classes (the target is "$(ARCH)/LinuxDebuggerLocal.o:"). I added my PPC64ThreadContext class to that target, but that had no effect. In fact, hacking that Makefile to remove other arch-specific ThreadContext classes from that target had no effect either -- i.e., a 'make clean' and 'rm -rf build' followed by './configure' and 'make all' still manages to generate the header files for the three existing arch-specific ThreadContext classes. So my question is how do those header files get generated? What file do I need to edit to add PPC64ThreadContext into the mix? Thanks. -Maynard From volker.simonis at gmail.com Fri Aug 8 14:59:06 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Aug 2014 16:59:06 +0200 Subject: Problem generating C header file for Hotspot debugger PPC64ThreadContext class In-Reply-To: <53E3829E.6000204@us.ibm.com> References: <53E3829E.6000204@us.ibm.com> Message-ID: Hy Maynard, sorry, but I think you edited the wrong Make file (that's why you saw no effect - neither positive nor negative:) The right Makefile is "hotspot/make/linux/makefiles/sa.make". If you add your new Thread context class to the 'javah' rules at the end of the file it should work. I actually don't know why "hotspot/agent/src/os/linux/Makefile" is still there. Maybe it can (or could) be used to build the sa-agent standalone? Perhaps somebody from the serviceability list can tell if this Make file couldn't (or even shouldn't) be removed to prevent confusion. Regards, Volker On Thu, Aug 7, 2014 at 3:43 PM, Maynard Johnson wrote: > Hi, all, > I've begun adding ppc64 support for the serviceability tools that take a java core file as input (jmap, jstack). See my original July 3 posting to ppc-aix-port-dev (subject "PowerPC: core file option not available with serviceability tools") for reference. I've created a number of new ppc64-specific Java classes within sun.jvm.hotspot.debugger.*, but am now running into a build issue that I've not been able to resolve. The build error is as follows: > > --------------- > Compiling /home/mpj/jdk9-dev/hotspot/src/share/vm/runtime/vm_version.cpp > Making SA debugger back-end... > /home/mpj/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c:53:63: fatal error: sun_jvm_hotspot_debugger_ppc64_PPC64ThreadContext.h: No such file or directory > #include "sun_jvm_hotspot_debugger_ppc64_PPC64ThreadContext.h" > ^ > compilation terminated. > --------------- > > The crux of the problem is that this missing header file is not being generated earlier in the build, when the other arch-specific ThreadContext headers (X86, AMD64, and SPARC) are built. These headers are generated into build/linux-ppc64-normal-server-release/hotspot/linux_ppc64_compiler2/generated. > > I had found hotspot/agent/src/os/linux/Makefile where there's a target defined to use 'javah' for generating header files from the *ThreadContext classes (the target is "$(ARCH)/LinuxDebuggerLocal.o:"). I added my PPC64ThreadContext class to that target, but that had no effect. In fact, hacking that Makefile to remove other arch-specific ThreadContext classes from that target had no effect either -- i.e., a 'make clean' and 'rm -rf build' followed by './configure' and 'make all' still manages to generate the header files for the three existing arch-specific ThreadContext classes. So my question is how do those header files get generated? What file do I need to edit to add PPC64ThreadContext into the mix? > > Thanks. > -Maynard > From dmitry.samersoff at oracle.com Sat Aug 9 17:12:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 09 Aug 2014 21:12:18 +0400 Subject: RFR(S): 8054174: minor buglet in computation of end of pc descs in libjvm_db.c Message-ID: <53E65672.20604@oracle.com> Hi Everybody, Sponsoring Tom Rodriguez's fix for libjvm_db.c please review. http://cr.openjdk.java.net/~dsamersoff/JDK-8054174/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Sat Aug 9 19:24:54 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 09 Aug 2014 12:24:54 -0700 Subject: RFR(S): 8054174: minor buglet in computation of end of pc descs in libjvm_db.c In-Reply-To: <53E65672.20604@oracle.com> References: <53E65672.20604@oracle.com> Message-ID: <53E67586.2070706@oracle.com> Looks good. Thanks, Serguei On 8/9/14 10:12 AM, Dmitry Samersoff wrote: > Hi Everybody, > > Sponsoring Tom Rodriguez's fix for libjvm_db.c please review. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8054174/webrev.01/ > > -Dmitry > From dmitry.samersoff at oracle.com Sun Aug 10 09:32:55 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 10 Aug 2014 13:32:55 +0400 Subject: RFR(S): JDK-8029172: warnings from b117 for hotspot.agent.src.os.linux: JNI exception pending Message-ID: <53E73C47.6020701@oracle.com> Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8029172/webrev.01/ Added more exception checks to agent/src/os/linux/LinuxDebuggerLocal.c -- 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 chris.hegarty at oracle.com Sun Aug 10 12:15:59 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 10 Aug 2014 13:15:59 +0100 Subject: RFR(S): JDK-8029172: warnings from b117 for hotspot.agent.src.os.linux: JNI exception pending In-Reply-To: <53E73C47.6020701@oracle.com> References: <53E73C47.6020701@oracle.com> Message-ID: <1664AD2E-05FE-496F-9A00-81D1A40E767C@oracle.com> Looks good to me Dmitry. -Chris > On 10 Aug 2014, at 10:32, Dmitry Samersoff wrote: > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8029172/webrev.01/ > > Added more exception checks to agent/src/os/linux/LinuxDebuggerLocal.c > > -- > 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 staffan.larsen at oracle.com Mon Aug 11 12:27:56 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 11 Aug 2014 14:27:56 +0200 Subject: RFR: 8054824 Clean up ProblemList.txt Message-ID: <61C47A9F-DF1F-466B-B954-1EFD005B278F@oracle.com> Please review the change below for ProblemList.txt. See details in the bug report: https://bugs.openjdk.java.net/browse/JDK-8054824 Thanks, /Staffan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -260,7 +260,7 @@ # 8031555 com/sun/jdi/JdbMethodExitTest.sh generic-all -# 8041934 +# 8043571 com/sun/jdi/RepStep.java generic-all # 8044419 @@ -287,9 +287,6 @@ # 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all -# 8041989 -sun/tools/jstatd/TestJstatdDefaults.java generic-all - # 8037285 sun/tools/jstatd/TestJstatdServer.java generic-all From yekaterina.kantserova at oracle.com Mon Aug 11 13:05:09 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 11 Aug 2014 15:05:09 +0200 Subject: RFR: 8054824 Clean up ProblemList.txt In-Reply-To: <61C47A9F-DF1F-466B-B954-1EFD005B278F@oracle.com> References: <61C47A9F-DF1F-466B-B954-1EFD005B278F@oracle.com> Message-ID: <53E8BF85.9060506@oracle.com> Staffan, please see my comments inlined. On 08/11/2014 02:27 PM, Staffan Larsen wrote: > Please review the change below for ProblemList.txt. See details in the bug report: https://bugs.openjdk.java.net/browse/JDK-8054824 > > Thanks, > /Staffan > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -260,7 +260,7 @@ > # 8031555 > com/sun/jdi/JdbMethodExitTest.sh generic-all > > -# 8041934 > +# 8043571 > com/sun/jdi/RepStep.java generic-all > > # 8044419 > @@ -287,9 +287,6 @@ > # 8033104 > sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all > > -# 8041989 > -sun/tools/jstatd/TestJstatdDefaults.java generic-all > - There is still one bug open - https://bugs.openjdk.java.net/browse/JDK-8027668. 8037285 is closed as duplicate of it. It should look like this: # 8027668 sun/tools/jstatd/TestJstatdDefaults.java generic-all sun/tools/jstatd/TestJstatdServer.java generic-all sun/tools/jstatd/TestJstatdPort.java generic-all > # 8037285 > sun/tools/jstatd/TestJstatdServer.java generic-all > // Katja From staffan.larsen at oracle.com Mon Aug 11 14:50:56 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 11 Aug 2014 16:50:56 +0200 Subject: RFR: 8054824 Clean up ProblemList.txt In-Reply-To: <53E8BF85.9060506@oracle.com> References: <61C47A9F-DF1F-466B-B954-1EFD005B278F@oracle.com> <53E8BF85.9060506@oracle.com> Message-ID: <3B7E2AA3-6FAB-44E4-BDC5-87B01152F34D@oracle.com> Updated diff: diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -260,7 +260,7 @@ # 8031555 com/sun/jdi/JdbMethodExitTest.sh generic-all -# 8041934 +# 8043571 com/sun/jdi/RepStep.java generic-all # 8044419 @@ -287,8 +287,10 @@ # 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all -# 8041989 -sun/tools/jstatd/TestJstatdDefaults.java generic-all +# 8027668 +sun/tools/jstatd/TestJstatdDefaults.java generic-all +sun/tools/jstatd/TestJstatdServer.java generic-all +sun/tools/jstatd/TestJstatdPort.java generic-all # 8037285 sun/tools/jstatd/TestJstatdServer.java generic-all On 11 aug 2014, at 15:05, Yekaterina Kantserova wrote: > Staffan, please see my comments inlined. > > On 08/11/2014 02:27 PM, Staffan Larsen wrote: >> Please review the change below for ProblemList.txt. See details in the bug report: https://bugs.openjdk.java.net/browse/JDK-8054824 >> >> Thanks, >> /Staffan >> >> >> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >> --- a/test/ProblemList.txt >> +++ b/test/ProblemList.txt >> @@ -260,7 +260,7 @@ >> # 8031555 >> com/sun/jdi/JdbMethodExitTest.sh generic-all >> >> -# 8041934 >> +# 8043571 >> com/sun/jdi/RepStep.java generic-all >> >> # 8044419 >> @@ -287,9 +287,6 @@ >> # 8033104 >> sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all >> >> -# 8041989 >> -sun/tools/jstatd/TestJstatdDefaults.java generic-all >> - > > There is still one bug open - https://bugs.openjdk.java.net/browse/JDK-8027668. 8037285 is closed as duplicate of it. It should look like this: > > # 8027668 > sun/tools/jstatd/TestJstatdDefaults.java generic-all > sun/tools/jstatd/TestJstatdServer.java generic-all > sun/tools/jstatd/TestJstatdPort.java generic-all > >> # 8037285 >> sun/tools/jstatd/TestJstatdServer.java generic-all >> > > // Katja -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Mon Aug 11 14:52:37 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 11 Aug 2014 16:52:37 +0200 Subject: RFR: 8054824 Clean up ProblemList.txt In-Reply-To: <3B7E2AA3-6FAB-44E4-BDC5-87B01152F34D@oracle.com> References: <61C47A9F-DF1F-466B-B954-1EFD005B278F@oracle.com> <53E8BF85.9060506@oracle.com> <3B7E2AA3-6FAB-44E4-BDC5-87B01152F34D@oracle.com> Message-ID: <53E8D8B5.9090706@oracle.com> Looks good to me! // Katja On 08/11/2014 04:50 PM, Staffan Larsen wrote: > Updated diff: > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -260,7 +260,7 @@ > # 8031555 > com/sun/jdi/JdbMethodExitTest.sh generic-all > > -# 8041934 > +# 8043571 > com/sun/jdi/RepStep.java generic-all > > # 8044419 > @@ -287,8 +287,10 @@ > # 8033104 > sun/jvmstat/monitor/MonitoredVm/CR6672135.javageneric-all > > -# 8041989 > -sun/tools/jstatd/TestJstatdDefaults.java generic-all > +# 8027668 > +sun/tools/jstatd/TestJstatdDefaults.java generic-all > +sun/tools/jstatd/TestJstatdServer.java generic-all > +sun/tools/jstatd/TestJstatdPort.java generic-all > > # 8037285 > sun/tools/jstatd/TestJstatdServer.java generic-all > > > On 11 aug 2014, at 15:05, Yekaterina Kantserova > > wrote: > >> Staffan, please see my comments inlined. >> >> On 08/11/2014 02:27 PM, Staffan Larsen wrote: >>> Please review the change below for ProblemList.txt. See details in >>> the bug report: https://bugs.openjdk.java.net/browse/JDK-8054824 >>> >>> Thanks, >>> /Staffan >>> >>> >>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >>> --- a/test/ProblemList.txt >>> +++ b/test/ProblemList.txt >>> @@ -260,7 +260,7 @@ >>> # 8031555 >>> com/sun/jdi/JdbMethodExitTest.sh >>> generic-all >>> >>> -# 8041934 >>> +# 8043571 >>> com/sun/jdi/RepStep.java >>> generic-all >>> >>> # 8044419 >>> @@ -287,9 +287,6 @@ >>> # 8033104 >>> sun/jvmstat/monitor/MonitoredVm/CR6672135.javageneric-all >>> >>> -# 8041989 >>> -sun/tools/jstatd/TestJstatdDefaults.java >>> generic-all >>> - >> >> There is still one bug open >> -https://bugs.openjdk.java.net/browse/JDK-8027668. 8037285 is closed >> as duplicate of it. It should look like this: >> >> # 8027668 >> sun/tools/jstatd/TestJstatdDefaults.java generic-all >> sun/tools/jstatd/TestJstatdServer.java generic-all >> sun/tools/jstatd/TestJstatdPort.java generic-all >> >>> # 8037285 >>> sun/tools/jstatd/TestJstatdServer.java >>> generic-all >>> >> >> // Katja > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Mon Aug 11 14:57:36 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 11 Aug 2014 18:57:36 +0400 Subject: RFR(S): JDK-8031583: warnings from b03 for hotspot/agent/src/os/solaris/proc: JNI exception pending Message-ID: <53E8D9E0.4070607@oracle.com> Hi Everybody, Please, review small fix that adds more exception handling code http://cr.openjdk.java.net/~dsamersoff/JDK-8031583/webrev.01/ -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 staffan.larsen at oracle.com Tue Aug 12 11:10:30 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 13:10:30 +0200 Subject: RFR(S): JDK-8031583: warnings from b03 for hotspot/agent/src/os/solaris/proc: JNI exception pending In-Reply-To: <53E8D9E0.4070607@oracle.com> References: <53E8D9E0.4070607@oracle.com> Message-ID: <0076EA5B-FF06-48B6-9AAC-B143096C2A9A@oracle.com> Dmitry, Since CHECK_EXCEPTION just returns if there was an exception, you will get no information that an exception happened or that there was an error looking up the exception class. I am not sure how this helps (other than get rid of a static analysis warning). /Staffan On 11 aug 2014, at 16:57, Dmitry Samersoff wrote: > Hi Everybody, > > Please, review small fix that adds more exception handling code > > http://cr.openjdk.java.net/~dsamersoff/JDK-8031583/webrev.01/ > > -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 staffan.larsen at oracle.com Tue Aug 12 11:12:58 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 13:12:58 +0200 Subject: RFR(S): 8054174: minor buglet in computation of end of pc descs in libjvm_db.c In-Reply-To: <53E65672.20604@oracle.com> References: <53E65672.20604@oracle.com> Message-ID: OK. On 9 aug 2014, at 19:12, Dmitry Samersoff wrote: > Hi Everybody, > > Sponsoring Tom Rodriguez's fix for libjvm_db.c please review. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8054174/webrev.01/ > > -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 staffan.larsen at oracle.com Tue Aug 12 11:15:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 13:15:09 +0200 Subject: Problem generating C header file for Hotspot debugger PPC64ThreadContext class In-Reply-To: References: <53E3829E.6000204@us.ibm.com> Message-ID: On 8 aug 2014, at 16:59, Volker Simonis wrote: > I actually don't know why "hotspot/agent/src/os/linux/Makefile" is > still there. Maybe it can (or could) be used to build the sa-agent > standalone? Perhaps somebody from the serviceability list can tell if > this Make file couldn't (or even shouldn't) be removed to prevent > confusion. I think it can safely be removed. /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Aug 12 11:17:19 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 13:17:19 +0200 Subject: RFR 8052961: Test "com/sun/tools/attach/StartManagementAgent.java" failing intermittently In-Reply-To: <53D7A607.5030500@oracle.com> References: <53D7A607.5030500@oracle.com> Message-ID: <56D299BC-6757-4518-8B07-0EAA7B64D159@oracle.com> Looks good! Thanks, /Staffan On 29 jul 2014, at 15:47, Jaroslav Bachorik wrote: > Please, review this (hopefully last) change to StartManagementAgent test > > Issue : https://bugs.openjdk.java.net/browse/JDK-8052961 > Webrev: http://cr.openjdk.java.net/~jbachorik/8052961/webrev.00 > > The test needs a properly registered service for the ServiceLoader - but it fails to compile the provider class explicitly leading to intermittent failures. The fix is to add the "SimpleProvider" to "@run build ..." line. > > Thanks, > > -JB- From dmitry.samersoff at oracle.com Tue Aug 12 13:03:16 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 12 Aug 2014 17:03:16 +0400 Subject: RFR(S): JDK-8031583: warnings from b03 for hotspot/agent/src/os/solaris/proc: JNI exception pending In-Reply-To: <0076EA5B-FF06-48B6-9AAC-B143096C2A9A@oracle.com> References: <53E8D9E0.4070607@oracle.com> <0076EA5B-FF06-48B6-9AAC-B143096C2A9A@oracle.com> Message-ID: <53EA1094.10009@oracle.com> Staffan, On 2014-08-12 15:10, Staffan Larsen wrote: > Dmitry, > > Since CHECK_EXCEPTION just returns if there was an exception, you > will get no information that an exception happened or that there was > an error looking up the exception class. I am not sure how this helps > (other than get rid of a static analysis warning). It's a common pattern in agent code. So this fix just make the code uniform and yes it fixes static analysis warning. -Dmitry > > /Staffan > > On 11 aug 2014, at 16:57, Dmitry Samersoff > wrote: > >> Hi Everybody, >> >> Please, review small fix that adds more exception handling code >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8031583/webrev.01/ >> >> -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. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From staffan.larsen at oracle.com Tue Aug 12 13:09:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 15:09:02 +0200 Subject: RFR(S): JDK-8031583: warnings from b03 for hotspot/agent/src/os/solaris/proc: JNI exception pending In-Reply-To: <53EA1094.10009@oracle.com> References: <53E8D9E0.4070607@oracle.com> <0076EA5B-FF06-48B6-9AAC-B143096C2A9A@oracle.com> <53EA1094.10009@oracle.com> Message-ID: On 12 aug 2014, at 15:03, Dmitry Samersoff wrote: > Staffan, > > On 2014-08-12 15:10, Staffan Larsen wrote: >> Dmitry, >> >> Since CHECK_EXCEPTION just returns if there was an exception, you >> will get no information that an exception happened or that there was >> an error looking up the exception class. I am not sure how this helps >> (other than get rid of a static analysis warning). > > It's a common pattern in agent code. So this fix just make the code > uniform and yes it fixes static analysis warning. OK then because it fixes the warning and that the particular class will always be present. Reviewed. /Staffan > > -Dmitry > > >> >> /Staffan >> >> On 11 aug 2014, at 16:57, Dmitry Samersoff >> wrote: >> >>> Hi Everybody, >>> >>> Please, review small fix that adds more exception handling code >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8031583/webrev.01/ >>> >>> -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. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the source code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Aug 14 07:04:50 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 14 Aug 2014 09:04:50 +0200 Subject: RFR: 8054824 Clean up ProblemList.txt In-Reply-To: <3B7E2AA3-6FAB-44E4-BDC5-87B01152F34D@oracle.com> References: <61C47A9F-DF1F-466B-B954-1EFD005B278F@oracle.com> <53E8BF85.9060506@oracle.com> <3B7E2AA3-6FAB-44E4-BDC5-87B01152F34D@oracle.com> Message-ID: <53EC5F92.10000@oracle.com> Shouldn't #8037285 be removed as well? It was closed as a dupe of #8027668 -JB- On 08/11/2014 04:50 PM, Staffan Larsen wrote: > Updated diff: > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -260,7 +260,7 @@ > # 8031555 > com/sun/jdi/JdbMethodExitTest.sh > generic-all > > -# 8041934 > +# 8043571 > com/sun/jdi/RepStep.java > generic-all > > # 8044419 > @@ -287,8 +287,10 @@ > # 8033104 > sun/jvmstat/monitor/MonitoredVm/CR6672135.javageneric-all > > -# 8041989 > -sun/tools/jstatd/TestJstatdDefaults.java generic-all > +# 8027668 > +sun/tools/jstatd/TestJstatdDefaults.java generic-all > +sun/tools/jstatd/TestJstatdServer.java generic-all > +sun/tools/jstatd/TestJstatdPort.java generic-all > > # 8037285 > sun/tools/jstatd/TestJstatdServer.java > generic-all > > > On 11 aug 2014, at 15:05, Yekaterina Kantserova > > wrote: > >> Staffan, please see my comments inlined. >> >> On 08/11/2014 02:27 PM, Staffan Larsen wrote: >>> Please review the change below for ProblemList.txt. See details in >>> the bug report: https://bugs.openjdk.java.net/browse/JDK-8054824 >>> >>> Thanks, >>> /Staffan >>> >>> >>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >>> --- a/test/ProblemList.txt >>> +++ b/test/ProblemList.txt >>> @@ -260,7 +260,7 @@ >>> # 8031555 >>> com/sun/jdi/JdbMethodExitTest.sh >>> generic-all >>> >>> -# 8041934 >>> +# 8043571 >>> com/sun/jdi/RepStep.java >>> generic-all >>> >>> # 8044419 >>> @@ -287,9 +287,6 @@ >>> # 8033104 >>> sun/jvmstat/monitor/MonitoredVm/CR6672135.javageneric-all >>> >>> -# 8041989 >>> -sun/tools/jstatd/TestJstatdDefaults.java >>> generic-all >>> - >> >> There is still one bug open >> -https://bugs.openjdk.java.net/browse/JDK-8027668. 8037285 is closed >> as duplicate of it. It should look like this: >> >> # 8027668 >> sun/tools/jstatd/TestJstatdDefaults.java generic-all >> sun/tools/jstatd/TestJstatdServer.java generic-all >> sun/tools/jstatd/TestJstatdPort.java generic-all >> >>> # 8037285 >>> sun/tools/jstatd/TestJstatdServer.java >>> generic-all >>> >> >> // Katja > From yekaterina.kantserova at oracle.com Thu Aug 14 11:40:50 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 14 Aug 2014 13:40:50 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests Message-ID: <53ECA042.7000302@oracle.com> Hi, Could I please have a review of this fix. webrev: http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8054278 As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. The tests have been run on all basic platforms. Thanks, Katja -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Aug 14 11:41:28 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 14 Aug 2014 13:41:28 +0200 Subject: RFR: 8054824 Clean up ProblemList.txt In-Reply-To: <53EC5F92.10000@oracle.com> References: <61C47A9F-DF1F-466B-B954-1EFD005B278F@oracle.com> <53E8BF85.9060506@oracle.com> <3B7E2AA3-6FAB-44E4-BDC5-87B01152F34D@oracle.com> <53EC5F92.10000@oracle.com> Message-ID: Good point. I will remove it and push the change. /Staffan On 14 aug 2014, at 09:04, Jaroslav Bachorik wrote: > Shouldn't #8037285 be removed as well? It was closed as a dupe of #8027668 > > -JB- > > On 08/11/2014 04:50 PM, Staffan Larsen wrote: >> Updated diff: >> >> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >> --- a/test/ProblemList.txt >> +++ b/test/ProblemList.txt >> @@ -260,7 +260,7 @@ >> # 8031555 >> com/sun/jdi/JdbMethodExitTest.sh >> generic-all >> >> -# 8041934 >> +# 8043571 >> com/sun/jdi/RepStep.java >> generic-all >> >> # 8044419 >> @@ -287,8 +287,10 @@ >> # 8033104 >> sun/jvmstat/monitor/MonitoredVm/CR6672135.javageneric-all >> >> -# 8041989 >> -sun/tools/jstatd/TestJstatdDefaults.java generic-all >> +# 8027668 >> +sun/tools/jstatd/TestJstatdDefaults.java generic-all >> +sun/tools/jstatd/TestJstatdServer.java generic-all >> +sun/tools/jstatd/TestJstatdPort.java generic-all >> >> # 8037285 >> sun/tools/jstatd/TestJstatdServer.java >> generic-all >> >> >> On 11 aug 2014, at 15:05, Yekaterina Kantserova >> > > wrote: >> >>> Staffan, please see my comments inlined. >>> >>> On 08/11/2014 02:27 PM, Staffan Larsen wrote: >>>> Please review the change below for ProblemList.txt. See details in >>>> the bug report: https://bugs.openjdk.java.net/browse/JDK-8054824 >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt >>>> --- a/test/ProblemList.txt >>>> +++ b/test/ProblemList.txt >>>> @@ -260,7 +260,7 @@ >>>> # 8031555 >>>> com/sun/jdi/JdbMethodExitTest.sh >>>> generic-all >>>> >>>> -# 8041934 >>>> +# 8043571 >>>> com/sun/jdi/RepStep.java >>>> generic-all >>>> >>>> # 8044419 >>>> @@ -287,9 +287,6 @@ >>>> # 8033104 >>>> sun/jvmstat/monitor/MonitoredVm/CR6672135.javageneric-all >>>> >>>> -# 8041989 >>>> -sun/tools/jstatd/TestJstatdDefaults.java >>>> generic-all >>>> - >>> >>> There is still one bug open >>> -https://bugs.openjdk.java.net/browse/JDK-8027668. 8037285 is closed >>> as duplicate of it. It should look like this: >>> >>> # 8027668 >>> sun/tools/jstatd/TestJstatdDefaults.java generic-all >>> sun/tools/jstatd/TestJstatdServer.java generic-all >>> sun/tools/jstatd/TestJstatdPort.java generic-all >>> >>>> # 8037285 >>>> sun/tools/jstatd/TestJstatdServer.java >>>> generic-all >>>> >>> >>> // Katja >> > From jaroslav.bachorik at oracle.com Thu Aug 14 11:52:19 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 14 Aug 2014 13:52:19 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA042.7000302@oracle.com> References: <53ECA042.7000302@oracle.com> Message-ID: <53ECA2F3.9030006@oracle.com> Hi Katja, firstly, the webrev contains seemingly unrelated change to test/ProblemList.txt - is it correct? * test/sun/tools/jps/TestJpsClass.java L33 - typo, JpasBase -> JpsBase Cheers, -JB- On 08/14/2014 01:40 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ > bug:https://bugs.openjdk.java.net/browse/JDK-8054278 > > As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. > > The tests have been run on all basic platforms. > > Thanks, > Katja > From Leonid.Mesnik at oracle.com Thu Aug 14 11:55:32 2014 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 14 Aug 2014 15:55:32 +0400 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA042.7000302@oracle.com> References: <53ECA042.7000302@oracle.com> Message-ID: <53ECA3B4.7000901@oracle.com> Katya I am not reviewing tests, just have small comment. I think it would be better to use '@run driver' instead of '@run main' in these tests. Leonid On 14.08.2014 15:40, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ > bug:https://bugs.openjdk.java.net/browse/JDK-8054278 > > As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. > > The tests have been run on all basic platforms. > > Thanks, > Katja -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Thu Aug 14 12:01:17 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 14 Aug 2014 14:01:17 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA2F3.9030006@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA2F3.9030006@oracle.com> Message-ID: <53ECA50D.3030308@oracle.com> Jaroslav, The change in ProblemList is related because sun/tools/jps/TestJpsJarRelative.java is failing due to https://bugs.openjdk.java.net/browse/JDK-6456333: ===== With jps -l, full path name is not shown if argument to java -jar is relative path name even though jps documentations says: "-l Output the full package name for the application?s main class or the full path name to the application?s JAR file." ===== I should mention this, sorry! // Katja On 08/14/2014 01:52 PM, Jaroslav Bachorik wrote: > Hi Katja, > > firstly, the webrev contains seemingly unrelated change to > test/ProblemList.txt - is it correct? > > * test/sun/tools/jps/TestJpsClass.java > L33 - typo, JpasBase -> JpsBase > > Cheers, > > -JB- > > On 08/14/2014 01:40 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >> >> As of today the test/jdk/sun/tools/jps tests are a number of shell >> and awk scripts that test only a few combinations of jps args. The >> tests also used to fail intermittently due to timing issues, >> e.g.JDK-7091195 >> andJDK-6542634 . In >> order to make tests more stable and make sure all combinations of >> arguments are tested the test will be refactored using >> jdk.testlibrary functionality. >> >> The tests have been run on all basic platforms. >> >> Thanks, >> Katja >> > From jaroslav.bachorik at oracle.com Thu Aug 14 12:06:12 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 14 Aug 2014 14:06:12 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA3B4.7000901@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA3B4.7000901@oracle.com> Message-ID: <53ECA634.9080407@oracle.com> On 08/14/2014 01:55 PM, Leonid Mesnik wrote: > Katya > > I am not reviewing tests, just have small comment. > I think it would be better to use '@run driver' instead of '@run main' Could you elaborate on this, please? In http://openjdk.java.net/jtreg/tag-spec.txt the "driver" action is not mentioned - what is its purpose and how it differs from "main"? Thanks, -JB- > in these tests. > > Leonid > > On 14.08.2014 15:40, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >> >> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >> >> The tests have been run on all basic platforms. >> >> Thanks, >> Katja > From yekaterina.kantserova at oracle.com Thu Aug 14 12:07:23 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 14 Aug 2014 14:07:23 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA3B4.7000901@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA3B4.7000901@oracle.com> Message-ID: <53ECA67B.4040409@oracle.com> Leonid, Yes, it seems to be a good idea. I'll check how it works. // Katja On 08/14/2014 01:55 PM, Leonid Mesnik wrote: > Katya > > I am not reviewing tests, just have small comment. > I think it would be better to use '@run driver' instead of '@run main' > in these tests. > > Leonid > > On 14.08.2014 15:40, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >> >> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >> >> The tests have been run on all basic platforms. >> >> Thanks, >> Katja > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Thu Aug 14 12:09:27 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 14 Aug 2014 14:09:27 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA634.9080407@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA3B4.7000901@oracle.com> <53ECA634.9080407@oracle.com> Message-ID: <53ECA6F7.60502@oracle.com> On 08/14/2014 02:06 PM, Jaroslav Bachorik wrote: > On 08/14/2014 01:55 PM, Leonid Mesnik wrote: >> Katya >> >> I am not reviewing tests, just have small comment. >> I think it would be better to use '@run driver' instead of '@run main' > > Could you elaborate on this, please? In > http://openjdk.java.net/jtreg/tag-spec.txt the "driver" action is not > mentioned - what is its purpose and how it differs from "main"? I've found this one: https://bugs.openjdk.java.net/browse/CODETOOLS-7900877 // Katja > > Thanks, > > -JB- > >> in these tests. >> >> Leonid >> >> On 14.08.2014 15:40, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >>> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >>> >>> As of today the test/jdk/sun/tools/jps tests are a number of shell >>> and awk scripts that test only a few combinations of jps args. The >>> tests also used to fail intermittently due to timing issues, >>> e.g.JDK-7091195 >>> andJDK-6542634 . >>> In order to make tests more stable and make sure all combinations of >>> arguments are tested the test will be refactored using >>> jdk.testlibrary functionality. >>> >>> The tests have been run on all basic platforms. >>> >>> Thanks, >>> Katja >> > From staffan.larsen at oracle.com Thu Aug 14 12:10:58 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 14 Aug 2014 14:10:58 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA634.9080407@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA3B4.7000901@oracle.com> <53ECA634.9080407@oracle.com> Message-ID: On 14 aug 2014, at 14:06, Jaroslav Bachorik wrote: > On 08/14/2014 01:55 PM, Leonid Mesnik wrote: >> Katya >> >> I am not reviewing tests, just have small comment. >> I think it would be better to use '@run driver' instead of '@run main' > > Could you elaborate on this, please? In http://openjdk.java.net/jtreg/tag-spec.txt the "driver" action is not mentioned - what is its purpose and how it differs from "main?? Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. So it?s a way to write testing code that really just launches other VMs where the actual test is. See it as a replacement for writing shell scripts to do this. /Staffan > > Thanks, > > -JB- > >> in these tests. >> >> Leonid >> >> On 14.08.2014 15:40, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >>> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >>> >>> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >>> >>> The tests have been run on all basic platforms. >>> >>> Thanks, >>> Katja >> > From stefan.karlsson at oracle.com Thu Aug 14 12:04:18 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Aug 2014 14:04:18 +0200 Subject: 8055111: [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't remove -Xconcgc Message-ID: <53ECA5C2.10801@oracle.com> Hi all, Please, review this patch to add -Xconcgc to the set of flags to be filtered out by Utils.removeGcOpts: http://cr.openjdk.java.net/~stefank/8055111/webrev.00/ This fixes one of the instances in: https://bugs.openjdk.java.net/browse/JDK-8019361 - [TESTBUG] Conflicting collector combinations in option list for GC tests Tested by running: jtreg -vmoption:-Xconcgc -jdk:/localhome/java/jdk-9-ea-bin-b26/ test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java jtreg -vmoption:-XX:+UseConcMarkSweepGC -jdk:/localhome/java/jdk-9-ea-bin-b26/ test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java thanks, StefanK From yekaterina.kantserova at oracle.com Thu Aug 14 12:16:36 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 14 Aug 2014 14:16:36 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA67B.4040409@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA3B4.7000901@oracle.com> <53ECA67B.4040409@oracle.com> Message-ID: <53ECA8A4.9060805@oracle.com> Opps, it doesn't seem we can use "@run driver" with jtreg 4.1 b09. I get following error: ... * @build jdk.testlibrary.* JpsHelper JpsBase * @run driver TestJpsClass ... TEST: sun/tools/jps/TestJpsClass.java TEST RESULT: Error. Bad action for script: driver ... // Katja On 08/14/2014 02:07 PM, Yekaterina Kantserova wrote: > Leonid, > > Yes, it seems to be a good idea. I'll check how it works. > > // Katja > > > On 08/14/2014 01:55 PM, Leonid Mesnik wrote: >> Katya >> >> I am not reviewing tests, just have small comment. >> I think it would be better to use '@run driver' instead of '@run >> main' in these tests. >> >> Leonid >> >> On 14.08.2014 15:40, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >>> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >>> >>> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >>> >>> The tests have been run on all basic platforms. >>> >>> Thanks, >>> Katja >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Aug 14 14:04:46 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 14 Aug 2014 16:04:46 +0200 Subject: 8055111: [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't remove -Xconcgc In-Reply-To: <53ECA5C2.10801@oracle.com> References: <53ECA5C2.10801@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 14 aug 2014, at 14:04, Stefan Karlsson wrote: > Hi all, > > Please, review this patch to add -Xconcgc to the set of flags to be filtered out by Utils.removeGcOpts: > http://cr.openjdk.java.net/~stefank/8055111/webrev.00/ > > This fixes one of the instances in: > https://bugs.openjdk.java.net/browse/JDK-8019361 - [TESTBUG] Conflicting collector combinations in option list for GC tests > > Tested by running: > jtreg -vmoption:-Xconcgc -jdk:/localhome/java/jdk-9-ea-bin-b26/ test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java > jtreg -vmoption:-XX:+UseConcMarkSweepGC -jdk:/localhome/java/jdk-9-ea-bin-b26/ test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java > > thanks, > StefanK From staffan.larsen at oracle.com Thu Aug 14 14:11:47 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 14 Aug 2014 16:11:47 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECA8A4.9060805@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA3B4.7000901@oracle.com> <53ECA67B.4040409@oracle.com> <53ECA8A4.9060805@oracle.com> Message-ID: <7B880A72-C7FB-4420-8829-6FC130B18C5B@oracle.com> It should work. Most of the test in jdk/test/com/sun/jdi uses "@run driver? and runs well with 4.1 fcs b09. /Staffan On 14 aug 2014, at 14:16, Yekaterina Kantserova wrote: > Opps, it doesn't seem we can use "@run driver" with jtreg 4.1 b09. I get following error: > > ... > * @build jdk.testlibrary.* JpsHelper JpsBase > * @run driver TestJpsClass > ... > TEST: sun/tools/jps/TestJpsClass.java > TEST RESULT: Error. Bad action for script: driver > ... > > // Katja > > > > On 08/14/2014 02:07 PM, Yekaterina Kantserova wrote: >> Leonid, >> >> Yes, it seems to be a good idea. I'll check how it works. >> >> // Katja >> >> >> On 08/14/2014 01:55 PM, Leonid Mesnik wrote: >>> Katya >>> >>> I am not reviewing tests, just have small comment. >>> I think it would be better to use '@run driver' instead of '@run main' in these tests. >>> >>> Leonid >>> >>> On 14.08.2014 15:40, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> webrev: http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054278 >>>> >>>> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g. JDK-7091195 and JDK-6542634. In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >>>> >>>> The tests have been run on all basic platforms. >>>> >>>> Thanks, >>>> Katja >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Thu Aug 14 14:38:19 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 14 Aug 2014 16:38:19 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <7B880A72-C7FB-4420-8829-6FC130B18C5B@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA3B4.7000901@oracle.com> <53ECA67B.4040409@oracle.com> <53ECA8A4.9060805@oracle.com> <7B880A72-C7FB-4420-8829-6FC130B18C5B@oracle.com> Message-ID: <53ECC9DB.2050508@oracle.com> My bad - I've used 4.1 fcs b09 nightly build from the past. With the promoted one it works fine. Please find the updated version here: http://cr.openjdk.java.net/~ykantser/8054278/webrev.01/ // Katja On 08/14/2014 04:11 PM, Staffan Larsen wrote: > It should work. Most of the test in jdk/test/com/sun/jdi uses "@run > driver? and runs well with 4.1 fcs b09. > > /Staffan > > > On 14 aug 2014, at 14:16, Yekaterina Kantserova > > wrote: > >> Opps, it doesn't seem we can use "@run driver" with jtreg 4.1 b09. I >> get following error: >> >> ... >> * @build jdk.testlibrary.* JpsHelper JpsBase >> * @run driver TestJpsClass >> ... >> TEST: sun/tools/jps/TestJpsClass.java >> TEST RESULT: Error. Bad action for script: driver >> ... >> >> // Katja >> >> >> >> On 08/14/2014 02:07 PM, Yekaterina Kantserova wrote: >>> Leonid, >>> >>> Yes, it seems to be a good idea. I'll check how it works. >>> >>> // Katja >>> >>> >>> On 08/14/2014 01:55 PM, Leonid Mesnik wrote: >>>> Katya >>>> >>>> I am not reviewing tests, just have small comment. >>>> I think it would be better to use '@run driver' instead of '@run >>>> main' in these tests. >>>> >>>> Leonid >>>> >>>> On 14.08.2014 15:40, Yekaterina Kantserova wrote: >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >>>>> >>>>> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >>>>> >>>>> The tests have been run on all basic platforms. >>>>> >>>>> Thanks, >>>>> Katja >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Aug 15 08:19:26 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 15 Aug 2014 10:19:26 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: <53ECC9DB.2050508@oracle.com> References: <53ECA042.7000302@oracle.com> <53ECA3B4.7000901@oracle.com> <53ECA67B.4040409@oracle.com> <53ECA8A4.9060805@oracle.com> <7B880A72-C7FB-4420-8829-6FC130B18C5B@oracle.com> <53ECC9DB.2050508@oracle.com> Message-ID: <53EDC28E.1010007@oracle.com> Looks good! Cheers, -JB- On 08/14/2014 04:38 PM, Yekaterina Kantserova wrote: > My bad - I've used 4.1 fcs b09 nightly build from the past. With the > promoted one it works fine. > > Please find the updated version here: > http://cr.openjdk.java.net/~ykantser/8054278/webrev.01/ > > // Katja > > > > On 08/14/2014 04:11 PM, Staffan Larsen wrote: >> It should work. Most of the test in jdk/test/com/sun/jdi uses "@run >> driver? and runs well with 4.1 fcs b09. >> >> /Staffan >> >> >> On 14 aug 2014, at 14:16, Yekaterina Kantserova >> > > wrote: >> >>> Opps, it doesn't seem we can use "@run driver" with jtreg 4.1 b09. I >>> get following error: >>> >>> ... >>> * @build jdk.testlibrary.* JpsHelper JpsBase >>> * @run driver TestJpsClass >>> ... >>> TEST: sun/tools/jps/TestJpsClass.java >>> TEST RESULT: Error. Bad action for script: driver >>> ... >>> >>> // Katja >>> >>> >>> >>> On 08/14/2014 02:07 PM, Yekaterina Kantserova wrote: >>>> Leonid, >>>> >>>> Yes, it seems to be a good idea. I'll check how it works. >>>> >>>> // Katja >>>> >>>> >>>> On 08/14/2014 01:55 PM, Leonid Mesnik wrote: >>>>> Katya >>>>> >>>>> I am not reviewing tests, just have small comment. >>>>> I think it would be better to use '@run driver' instead of '@run >>>>> main' in these tests. >>>>> >>>>> Leonid >>>>> >>>>> On 14.08.2014 15:40, Yekaterina Kantserova wrote: >>>>>> Hi, >>>>>> >>>>>> Could I please have a review of this fix. >>>>>> >>>>>> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >>>>>> >>>>>> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >>>>>> >>>>>> The tests have been run on all basic platforms. >>>>>> >>>>>> Thanks, >>>>>> Katja >>>>> >>>> >>> >> > From yekaterina.kantserova at oracle.com Fri Aug 15 10:34:12 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 15 Aug 2014 03:34:12 -0700 (PDT) Subject: RFR (M): 8054278: Refactor jps utility tests Message-ID: Jaroslav, Thanks for your review! Could you please be my sponsor and push the fix? The patch file is attached to this mail. // Katja ----- Original Message ----- From: jaroslav.bachorik at oracle.com To: serviceability-dev at openjdk.java.net Sent: Friday, August 15, 2014 10:19:43 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR (M): 8054278: Refactor jps utility tests Looks good! Cheers, -JB- On 08/14/2014 04:38 PM, Yekaterina Kantserova wrote: > My bad - I've used 4.1 fcs b09 nightly build from the past. With the > promoted one it works fine. > > Please find the updated version here: > http://cr.openjdk.java.net/~ykantser/8054278/webrev.01/ > > // Katja > > > > On 08/14/2014 04:11 PM, Staffan Larsen wrote: >> It should work. Most of the test in jdk/test/com/sun/jdi uses "@run >> driver? and runs well with 4.1 fcs b09. >> >> /Staffan >> >> >> On 14 aug 2014, at 14:16, Yekaterina Kantserova >> > > wrote: >> >>> Opps, it doesn't seem we can use "@run driver" with jtreg 4.1 b09. I >>> get following error: >>> >>> ... >>> * @build jdk.testlibrary.* JpsHelper JpsBase >>> * @run driver TestJpsClass >>> ... >>> TEST: sun/tools/jps/TestJpsClass.java >>> TEST RESULT: Error. Bad action for script: driver >>> ... >>> >>> // Katja >>> >>> >>> >>> On 08/14/2014 02:07 PM, Yekaterina Kantserova wrote: >>>> Leonid, >>>> >>>> Yes, it seems to be a good idea. I'll check how it works. >>>> >>>> // Katja >>>> >>>> >>>> On 08/14/2014 01:55 PM, Leonid Mesnik wrote: >>>>> Katya >>>>> >>>>> I am not reviewing tests, just have small comment. >>>>> I think it would be better to use '@run driver' instead of '@run >>>>> main' in these tests. >>>>> >>>>> Leonid >>>>> >>>>> On 14.08.2014 15:40, Yekaterina Kantserova wrote: >>>>>> Hi, >>>>>> >>>>>> Could I please have a review of this fix. >>>>>> >>>>>> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >>>>>> >>>>>> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >>>>>> >>>>>> The tests have been run on all basic platforms. >>>>>> >>>>>> Thanks, >>>>>> Katja >>>>> >>>> >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8054278.1.patch Type: text/x-patch Size: 59990 bytes Desc: not available URL: From jaroslav.bachorik at oracle.com Fri Aug 15 10:44:20 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 15 Aug 2014 12:44:20 +0200 Subject: RFR (M): 8054278: Refactor jps utility tests In-Reply-To: References: Message-ID: <53EDE484.7090700@oracle.com> On 08/15/2014 12:34 PM, Yekaterina Kantserova wrote: > Jaroslav, > > Thanks for your review! Could you please be my sponsor and push the fix? The patch file is attached to this mail. Ok. -JB- > > // Katja > > > > ----- Original Message ----- > From: jaroslav.bachorik at oracle.com > To: serviceability-dev at openjdk.java.net > Sent: Friday, August 15, 2014 10:19:43 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR (M): 8054278: Refactor jps utility tests > > Looks good! > > Cheers, > > -JB- > > On 08/14/2014 04:38 PM, Yekaterina Kantserova wrote: >> My bad - I've used 4.1 fcs b09 nightly build from the past. With the >> promoted one it works fine. >> >> Please find the updated version here: >> http://cr.openjdk.java.net/~ykantser/8054278/webrev.01/ >> >> // Katja >> >> >> >> On 08/14/2014 04:11 PM, Staffan Larsen wrote: >>> It should work. Most of the test in jdk/test/com/sun/jdi uses "@run >>> driver? and runs well with 4.1 fcs b09. >>> >>> /Staffan >>> >>> >>> On 14 aug 2014, at 14:16, Yekaterina Kantserova >>> >> > wrote: >>> >>>> Opps, it doesn't seem we can use "@run driver" with jtreg 4.1 b09. I >>>> get following error: >>>> >>>> ... >>>> * @build jdk.testlibrary.* JpsHelper JpsBase >>>> * @run driver TestJpsClass >>>> ... >>>> TEST: sun/tools/jps/TestJpsClass.java >>>> TEST RESULT: Error. Bad action for script: driver >>>> ... >>>> >>>> // Katja >>>> >>>> >>>> >>>> On 08/14/2014 02:07 PM, Yekaterina Kantserova wrote: >>>>> Leonid, >>>>> >>>>> Yes, it seems to be a good idea. I'll check how it works. >>>>> >>>>> // Katja >>>>> >>>>> >>>>> On 08/14/2014 01:55 PM, Leonid Mesnik wrote: >>>>>> Katya >>>>>> >>>>>> I am not reviewing tests, just have small comment. >>>>>> I think it would be better to use '@run driver' instead of '@run >>>>>> main' in these tests. >>>>>> >>>>>> Leonid >>>>>> >>>>>> On 14.08.2014 15:40, Yekaterina Kantserova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please have a review of this fix. >>>>>>> >>>>>>> webrev:http://cr.openjdk.java.net/~ykantser/8054278/webrev.00/ >>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8054278 >>>>>>> >>>>>>> As of today the test/jdk/sun/tools/jps tests are a number of shell and awk scripts that test only a few combinations of jps args. The tests also used to fail intermittently due to timing issues, e.g.JDK-7091195 andJDK-6542634 . In order to make tests more stable and make sure all combinations of arguments are tested the test will be refactored using jdk.testlibrary functionality. >>>>>>> >>>>>>> The tests have been run on all basic platforms. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>> >>>>> >>>> >>> >> > From christian.tornqvist at oracle.com Fri Aug 15 14:55:04 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 15 Aug 2014 10:55:04 -0400 Subject: RFR(XS): 8055012 - [TESTBUG] NMTHelper fails to parse NMT output Message-ID: <002f01cfb898$e65120d0$b2f36270$@oracle.com> Hi, This is a small update to NMTHelper.java to make it work with recent changes in the NMT implementation that changed the output format a bit. I've tested the change locally using java\lang\instrument\RedefineBigClass.sh and java\lang\instrument\RetransformBigClass.sh Webrev doesn't seem to like whitespace-only changes so I can't post a webrev, I'm pasting the diff here instead: diff -r 362a6ea9bc84 test/java/lang/instrument/NMTHelper.java --- a/test/java/lang/instrument/NMTHelper.java Thu Aug 14 15:54:04 2014 -0700 +++ b/test/java/lang/instrument/NMTHelper.java Fri Aug 15 10:43:15 2014 -0400 @@ -32,8 +32,8 @@ executeDcmd("vmNativeMemory", "baseline"); } - // Total: reserved=3484685KB +293KB, committed=266629KB +293KB - private static Pattern totalLine = Pattern.compile("^Total: reserved=\\d+KB .*KB, committed=\\d+KB (.*)KB$"); + // Total: reserved=3484685KB +293KB, committed=266629KB +293KB + private static Pattern totalLine = Pattern.compile("^Total: reserved=\\d+KB .*KB, committed=\\d+KB (.*)KB$"); public static long committedDiff() throws Exception { String res = (String) executeDcmd("vmNativeMemory", "detail.diff"); Bug: https://bugs.openjdk.java.net/browse/JDK-8055012 Thanks, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Aug 15 16:26:52 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 15 Aug 2014 18:26:52 +0200 Subject: RFR(XS): 8055012 - [TESTBUG] NMTHelper fails to parse NMT output In-Reply-To: <002f01cfb898$e65120d0$b2f36270$@oracle.com> References: <002f01cfb898$e65120d0$b2f36270$@oracle.com> Message-ID: <43D9EA4E-3D16-4953-8504-716D7A23ADF9@oracle.com> Looks good! Thanks, /Staffan On 15 aug 2014, at 16:55, Christian Tornqvist wrote: > Hi, > > This is a small update to NMTHelper.java to make it work with recent changes in the NMT implementation that changed the output format a bit. > > I?ve tested the change locally using java\lang\instrument\RedefineBigClass.sh and java\lang\instrument\RetransformBigClass.sh > > Webrev doesn?t seem to like whitespace-only changes so I can?t post a webrev, I?m pasting the diff here instead: > > diff -r 362a6ea9bc84 test/java/lang/instrument/NMTHelper.java > --- a/test/java/lang/instrument/NMTHelper.java Thu Aug 14 15:54:04 2014 -0700 > +++ b/test/java/lang/instrument/NMTHelper.java Fri Aug 15 10:43:15 2014 -0400 > @@ -32,8 +32,8 @@ > executeDcmd("vmNativeMemory", "baseline"); > } > > - // Total: reserved=3484685KB +293KB, committed=266629KB +293KB > - private static Pattern totalLine = Pattern.compile("^Total: reserved=\\d+KB .*KB, committed=\\d+KB (.*)KB$"); > + // Total: reserved=3484685KB +293KB, committed=266629KB +293KB > + private static Pattern totalLine = Pattern.compile("^Total: reserved=\\d+KB .*KB, committed=\\d+KB (.*)KB$"); > > public static long committedDiff() throws Exception { > String res = (String) executeDcmd("vmNativeMemory", "detail.diff"); > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8055012 > > Thanks, > Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Aug 15 20:18:42 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Aug 2014 16:18:42 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes Message-ID: <53EE6B22.3040107@oracle.com> Summary: Use scratch_class to find EMCP methods for breakpoints if the old methods are still running See bug for more details. This fix also includes a change to nmethod::metadata_do() to not walk the _method multiple times (the _method is added to the metadata section of the nmethod), and an attempt to help the sweeper clean up these scratch_class instance classes sooner. Tested with nsk tests, java/lang/instrument tests and jck tests (which include some jvmti tests). open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ bug link https://bugs.openjdk.java.net/browse/JDK-8055008 Thanks, Coleen From olivier.lagneau at oracle.com Mon Aug 18 11:39:23 2014 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Mon, 18 Aug 2014 13:39:23 +0200 Subject: RFR(XS): 8055012 - [TESTBUG] NMTHelper fails to parse NMT output In-Reply-To: <002f01cfb898$e65120d0$b2f36270$@oracle.com> References: <002f01cfb898$e65120d0$b2f36270$@oracle.com> Message-ID: <53F1E5EB.9050602@oracle.com> Hi Christian, Looks good ! Olivier. On 15/08/2014 16:55, Christian Tornqvist wrote: > > Hi, > > This is a small update to NMTHelper.java to make it work with recent > changes in the NMT implementation that changed the output format a bit. > > I?ve tested the change locally using > java\lang\instrument\RedefineBigClass.sh and > java\lang\instrument\RetransformBigClass.sh > > Webrev doesn?t seem to like whitespace-only changes so I can?t post a > webrev, I?m pasting the diff here instead: > > diff -r 362a6ea9bc84 test/java/lang/instrument/NMTHelper.java > > --- a/test/java/lang/instrument/NMTHelper.java Thu Aug 14 15:54:04 > 2014 -0700 > > +++ b/test/java/lang/instrument/NMTHelper.java Fri Aug 15 10:43:15 > 2014 -0400 > > @@ -32,8 +32,8 @@ > > executeDcmd("vmNativeMemory", "baseline"); > > } > > - // Total: reserved=3484685KB +293KB, committed=266629KB +293KB > > - private static Pattern totalLine = Pattern.compile("^Total: > reserved=\\d+KB .*KB, committed=\\d+KB (.*)KB$"); > > + // Total: reserved=3484685KB +293KB, committed=266629KB +293KB > > + private static Pattern totalLine = Pattern.compile("^Total: > reserved=\\d+KB .*KB, committed=\\d+KB (.*)KB$"); > > public static long committedDiff() throws Exception { > > String res = (String) executeDcmd("vmNativeMemory", > "detail.diff"); > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8055012 > > Thanks, > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Mon Aug 18 11:43:58 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 18 Aug 2014 13:43:58 +0200 Subject: 8055111: [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't remove -Xconcgc In-Reply-To: <53ECA5C2.10801@oracle.com> References: <53ECA5C2.10801@oracle.com> Message-ID: <53F1E6FE.5010105@oracle.com> Jon suggested that I should add -Xincgc. Here's the updated webrev: http://cr.openjdk.java.net/~stefank/8055111/webrev.01/ thanks, StefanK On 2014-08-14 14:04, Stefan Karlsson wrote: > Hi all, > > Please, review this patch to add -Xconcgc to the set of flags to be > filtered out by Utils.removeGcOpts: > http://cr.openjdk.java.net/~stefank/8055111/webrev.00/ > > This fixes one of the instances in: > https://bugs.openjdk.java.net/browse/JDK-8019361 - [TESTBUG] > Conflicting collector combinations in option list for GC tests > > Tested by running: > jtreg -vmoption:-Xconcgc -jdk:/localhome/java/jdk-9-ea-bin-b26/ > test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java > jtreg -vmoption:-XX:+UseConcMarkSweepGC > -jdk:/localhome/java/jdk-9-ea-bin-b26/ > test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java > > thanks, > StefanK From bengt.rutisson at oracle.com Mon Aug 18 11:56:15 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 18 Aug 2014 13:56:15 +0200 Subject: 8055111: [TESTBUG] jdk.testlibrary.Utils.removeGcOpts doesn't remove -Xconcgc In-Reply-To: <53F1E6FE.5010105@oracle.com> References: <53ECA5C2.10801@oracle.com> <53F1E6FE.5010105@oracle.com> Message-ID: <53F1E9DF.1080302@oracle.com> Hi Stefan, On 2014-08-18 13:43, Stefan Karlsson wrote: > Jon suggested that I should add -Xincgc. > > Here's the updated webrev: > http://cr.openjdk.java.net/~stefank/8055111/webrev.01/ Looks good. Thanks, Bengt > > thanks, > StefanK > > On 2014-08-14 14:04, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this patch to add -Xconcgc to the set of flags to be >> filtered out by Utils.removeGcOpts: >> http://cr.openjdk.java.net/~stefank/8055111/webrev.00/ >> >> This fixes one of the instances in: >> https://bugs.openjdk.java.net/browse/JDK-8019361 - [TESTBUG] >> Conflicting collector combinations in option list for GC tests >> >> Tested by running: >> jtreg -vmoption:-Xconcgc -jdk:/localhome/java/jdk-9-ea-bin-b26/ >> test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java >> jtreg -vmoption:-XX:+UseConcMarkSweepGC >> -jdk:/localhome/java/jdk-9-ea-bin-b26/ >> test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java >> >> thanks, >> StefanK > From ivan.gerasimov at oracle.com Mon Aug 18 21:19:54 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 19 Aug 2014 01:19:54 +0400 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 Message-ID: <53F26DFA.9010707@oracle.com> Hello! This is a request to temporarily add some instrumentation code to hotspot to help diagnose the intermittent failure on Windows, which results in a wrong exit code of (sub-)process. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ Sincerely yours, Ivan From daniel.daugherty at oracle.com Mon Aug 18 22:14:29 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Aug 2014 16:14:29 -0600 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F26DFA.9010707@oracle.com> References: <53F26DFA.9010707@oracle.com> Message-ID: <53F27AC5.9000304@oracle.com> On 8/18/14 3:19 PM, Ivan Gerasimov wrote: > Hello! > > This is a request to temporarily add some instrumentation code to > hotspot to help diagnose the intermittent failure on Windows, which > results in a wrong exit code of (sub-)process. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 > WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ src/os/windows/vm/os_windows.cpp No comments. src/share/vm/runtime/java.cpp No comments. Good luck with the hunt! Many of us have looked for this bug for years off and on... Dan > > Sincerely yours, > Ivan > From kellyohair at gmail.com Mon Aug 18 23:04:01 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Mon, 18 Aug 2014 16:04:01 -0700 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F27AC5.9000304@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F27AC5.9000304@oracle.com> Message-ID: 454 if (vm_getting_terminated && thread->is_Java_thread()) { 455 JavaThread* java_thread = (JavaThread*)thread; 456 if (java_thread && java_lang_Thread::is_daemon(java_thread->threadObj())) { 457 return 70115; 458 } Seems like the check for java_thread being null on line 456 can never happen, because it was assigned thread which was dereferenced on line 454. Maybe on line 454 you should check to make sure thread is not null and skip the check for java_thread being null? Just comments from the peanut gallery. ;) -kto On Aug 18, 2014, at 3:14 PM, Daniel D. Daugherty wrote: > > On 8/18/14 3:19 PM, Ivan Gerasimov wrote: >> Hello! >> >> This is a request to temporarily add some instrumentation code to hotspot to help diagnose the intermittent failure on Windows, which results in a wrong exit code of (sub-)process. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ > > src/os/windows/vm/os_windows.cpp > No comments. > > src/share/vm/runtime/java.cpp > No comments. > > Good luck with the hunt! Many of us have looked for this bug > for years off and on... > > Dan > > >> >> Sincerely yours, >> Ivan >> > From ioi.lam at oracle.com Tue Aug 19 00:12:46 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 18 Aug 2014 17:12:46 -0700 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F26DFA.9010707@oracle.com> References: <53F26DFA.9010707@oracle.com> Message-ID: <53F2967E.6040105@oracle.com> With the Windows/x86/x64 memory model, is the write to vm_getting_terminated guaranteed to be observable by java_start()? - Ioi On 8/18/14, 2:19 PM, Ivan Gerasimov wrote: > Hello! > > This is a request to temporarily add some instrumentation code to > hotspot to help diagnose the intermittent failure on Windows, which > results in a wrong exit code of (sub-)process. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 > WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ > > Sincerely yours, > Ivan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Aug 19 02:14:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Aug 2014 12:14:04 +1000 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: References: <53F26DFA.9010707@oracle.com> <53F27AC5.9000304@oracle.com> Message-ID: <53F2B2EC.2070106@oracle.com> On 19/08/2014 9:04 AM, Kelly O'Hair wrote: > 454 if (vm_getting_terminated && thread->is_Java_thread()) { > 455 JavaThread* java_thread = (JavaThread*)thread; > 456 if (java_thread && java_lang_Thread::is_daemon(java_thread->threadObj())) { > 457 return 70115; > 458 } > > Seems like the check for java_thread being null on line 456 can never happen, because it was assigned thread which was dereferenced on line 454. > Maybe on line 454 you should check to make sure thread is not null and skip the check for java_thread being null? Neither thread nor java_thread can be NULL. > Just comments from the peanut gallery. ;) Ditto :) David H. > -kto > > On Aug 18, 2014, at 3:14 PM, Daniel D. Daugherty wrote: > >> >> On 8/18/14 3:19 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> This is a request to temporarily add some instrumentation code to hotspot to help diagnose the intermittent failure on Windows, which results in a wrong exit code of (sub-)process. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> No comments. >> >> src/share/vm/runtime/java.cpp >> No comments. >> >> Good luck with the hunt! Many of us have looked for this bug >> for years off and on... >> >> Dan >> >> >>> >>> Sincerely yours, >>> Ivan >>> >> > From david.holmes at oracle.com Tue Aug 19 02:42:13 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Aug 2014 12:42:13 +1000 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F2967E.6040105@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> Message-ID: <53F2B985.2070909@oracle.com> On 19/08/2014 10:12 AM, Ioi Lam wrote: > With the Windows/x86/x64 memory model, is the write to > vm_getting_terminated guaranteed to be observable by java_start()? In the general case, not immediately. For the threads actually of interest the logic that tells the threads to terminate happens after the write to the flag, and that logic contains sufficient "synchronization" that if the termination logic is correct then the flag must also be visible. David > - Ioi > > On 8/18/14, 2:19 PM, Ivan Gerasimov wrote: >> Hello! >> >> This is a request to temporarily add some instrumentation code to >> hotspot to help diagnose the intermittent failure on Windows, which >> results in a wrong exit code of (sub-)process. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ >> >> Sincerely yours, >> Ivan >> > From ivan.gerasimov at oracle.com Tue Aug 19 04:36:05 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 19 Aug 2014 08:36:05 +0400 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F2B2EC.2070106@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F27AC5.9000304@oracle.com> <53F2B2EC.2070106@oracle.com> Message-ID: <53F2D435.8060701@oracle.com> Thanks Kelly and David! On 19.08.2014 6:14, David Holmes wrote: > On 19/08/2014 9:04 AM, Kelly O'Hair wrote: >> 454 if (vm_getting_terminated && thread->is_Java_thread()) { >> 455 JavaThread* java_thread = (JavaThread*)thread; >> 456 if (java_thread && >> java_lang_Thread::is_daemon(java_thread->threadObj())) { >> 457 return 70115; >> 458 } >> >> Seems like the check for java_thread being null on line 456 can never >> happen, because it was assigned thread which was dereferenced on line >> 454. >> Maybe on line 454 you should check to make sure thread is not null >> and skip the check for java_thread being null? > > Neither thread nor java_thread can be NULL. > Yes, I'll remove this unnecessary check. Sincerely yours, Ivan >> Just comments from the peanut gallery. ;) > > Ditto :) > > David H. > > >> -kto >> >> On Aug 18, 2014, at 3:14 PM, Daniel D. Daugherty wrote: >> >>> >>> On 8/18/14 3:19 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> This is a request to temporarily add some instrumentation code to >>>> hotspot to help diagnose the intermittent failure on Windows, which >>>> results in a wrong exit code of (sub-)process. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ >>> >>> src/os/windows/vm/os_windows.cpp >>> No comments. >>> >>> src/share/vm/runtime/java.cpp >>> No comments. >>> >>> Good luck with the hunt! Many of us have looked for this bug >>> for years off and on... >>> >>> Dan >>> >>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> >> > > From stefan.karlsson at oracle.com Tue Aug 19 10:25:15 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 19 Aug 2014 12:25:15 +0200 Subject: RFR: 8035939: java/lang/management/MemoryMXBean/MemoryManagement.java timed out on Linux-amd64 Message-ID: <53F3260B.3080400@oracle.com> Hi all, Please review this patch harden two MemoryMXBean tests. These tests cause intermittent test failures when the allocated objects are put in the young gen instead of the old gen. The proposed fix/workaround is to lower the young gen size and assert that the allocated objects are large enough to not fit in the young gen. http://cr.openjdk.java.net/~stefank/8035939/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8035939 thanks, StefanK From staffan.larsen at oracle.com Tue Aug 19 10:51:44 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 19 Aug 2014 12:51:44 +0200 Subject: RFR: 8035939: java/lang/management/MemoryMXBean/MemoryManagement.java timed out on Linux-amd64 In-Reply-To: <53F3260B.3080400@oracle.com> References: <53F3260B.3080400@oracle.com> Message-ID: <904492CB-C134-4FED-AB48-3F39846EE900@oracle.com> Looks good! Thanks, /Staffan On 19 aug 2014, at 12:25, Stefan Karlsson wrote: > Hi all, > > Please review this patch harden two MemoryMXBean tests. These tests cause intermittent test failures when the allocated objects are put in the young gen instead of the old gen. The proposed fix/workaround is to lower the young gen size and assert that the allocated objects are large enough to not fit in the young gen. > > http://cr.openjdk.java.net/~stefank/8035939/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8035939 > > thanks, > StefanK From bengt.rutisson at oracle.com Tue Aug 19 10:48:56 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 19 Aug 2014 12:48:56 +0200 Subject: RFR: 8035939: java/lang/management/MemoryMXBean/MemoryManagement.java timed out on Linux-amd64 In-Reply-To: <53F3260B.3080400@oracle.com> References: <53F3260B.3080400@oracle.com> Message-ID: <53F32B98.2010809@oracle.com> Hi Stefank, Seems reasonable. Reviewed. Bengt On 2014-08-19 12:25, Stefan Karlsson wrote: > Hi all, > > Please review this patch harden two MemoryMXBean tests. These tests > cause intermittent test failures when the allocated objects are put in > the young gen instead of the old gen. The proposed fix/workaround is > to lower the young gen size and assert that the allocated objects are > large enough to not fit in the young gen. > > http://cr.openjdk.java.net/~stefank/8035939/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8035939 > > thanks, > StefanK From stefan.karlsson at oracle.com Tue Aug 19 10:50:39 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 19 Aug 2014 12:50:39 +0200 Subject: RFR: 8035939: java/lang/management/MemoryMXBean/MemoryManagement.java timed out on Linux-amd64 In-Reply-To: <904492CB-C134-4FED-AB48-3F39846EE900@oracle.com> References: <53F3260B.3080400@oracle.com> <904492CB-C134-4FED-AB48-3F39846EE900@oracle.com> Message-ID: <53F32BFF.90409@oracle.com> On 2014-08-19 12:51, Staffan Larsen wrote: > Looks good! Thanks! StefanK > > Thanks, > /Staffan > > On 19 aug 2014, at 12:25, Stefan Karlsson wrote: > >> Hi all, >> >> Please review this patch harden two MemoryMXBean tests. These tests cause intermittent test failures when the allocated objects are put in the young gen instead of the old gen. The proposed fix/workaround is to lower the young gen size and assert that the allocated objects are large enough to not fit in the young gen. >> >> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8035939 >> >> thanks, >> StefanK From stefan.karlsson at oracle.com Tue Aug 19 10:50:55 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 19 Aug 2014 12:50:55 +0200 Subject: RFR: 8035939: java/lang/management/MemoryMXBean/MemoryManagement.java timed out on Linux-amd64 In-Reply-To: <53F32B98.2010809@oracle.com> References: <53F3260B.3080400@oracle.com> <53F32B98.2010809@oracle.com> Message-ID: <53F32C0F.4030006@oracle.com> On 2014-08-19 12:48, Bengt Rutisson wrote: > > Hi Stefank, > > Seems reasonable. Reviewed. Thanks. =) StefanK > > Bengt > > > On 2014-08-19 12:25, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch harden two MemoryMXBean tests. These tests >> cause intermittent test failures when the allocated objects are put >> in the young gen instead of the old gen. The proposed fix/workaround >> is to lower the young gen size and assert that the allocated objects >> are large enough to not fit in the young gen. >> >> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8035939 >> >> thanks, >> StefanK > From mikael.gerdin at oracle.com Tue Aug 19 11:28:02 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Aug 2014 13:28:02 +0200 Subject: RFR: 8035939: java/lang/management/MemoryMXBean/MemoryManagement.java timed out on Linux-amd64 In-Reply-To: <53F3260B.3080400@oracle.com> References: <53F3260B.3080400@oracle.com> Message-ID: <53F334C2.6020505@oracle.com> Hi Stefan, On 2014-08-19 12:25, Stefan Karlsson wrote: > Hi all, > > Please review this patch harden two MemoryMXBean tests. These tests > cause intermittent test failures when the allocated objects are put in > the young gen instead of the old gen. The proposed fix/workaround is to > lower the young gen size and assert that the allocated objects are large > enough to not fit in the young gen. > > http://cr.openjdk.java.net/~stefank/8035939/webrev.00/ Looks good. /Mikael > https://bugs.openjdk.java.net/browse/JDK-8035939 > > thanks, > StefanK From stefan.karlsson at oracle.com Tue Aug 19 11:52:10 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 19 Aug 2014 13:52:10 +0200 Subject: RFR: 8035939: java/lang/management/MemoryMXBean/MemoryManagement.java timed out on Linux-amd64 In-Reply-To: <53F334C2.6020505@oracle.com> References: <53F3260B.3080400@oracle.com> <53F334C2.6020505@oracle.com> Message-ID: <53F33A6A.7010108@oracle.com> On 2014-08-19 13:28, Mikael Gerdin wrote: > Hi Stefan, > > On 2014-08-19 12:25, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch harden two MemoryMXBean tests. These tests >> cause intermittent test failures when the allocated objects are put in >> the young gen instead of the old gen. The proposed fix/workaround is to >> lower the young gen size and assert that the allocated objects are large >> enough to not fit in the young gen. >> >> http://cr.openjdk.java.net/~stefank/8035939/webrev.00/ > > Looks good. Thanks. StefanK > > /Mikael > >> https://bugs.openjdk.java.net/browse/JDK-8035939 >> >> thanks, >> StefanK From ivan.gerasimov at oracle.com Tue Aug 19 12:57:22 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 19 Aug 2014 16:57:22 +0400 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F2B985.2070909@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> Message-ID: <53F349B2.7010903@oracle.com> Hello again! I updated the patch to cover situations when the exiting thread isn't daemon. I also added load_acquire/store_release for the sake of accuracy, even though on Windows they seem to add nothing to the volatile access. http://cr.openjdk.java.net/~igerasim/8055338/1/webrev/ If the updated patch looks Okay, I'll need a sponsor to push it. Sincerely yours, Ivan On 19.08.2014 6:42, David Holmes wrote: > On 19/08/2014 10:12 AM, Ioi Lam wrote: >> With the Windows/x86/x64 memory model, is the write to >> vm_getting_terminated guaranteed to be observable by java_start()? > > In the general case, not immediately. For the threads actually of > interest the logic that tells the threads to terminate happens after > the write to the flag, and that logic contains sufficient > "synchronization" that if the termination logic is correct then the > flag must also be visible. > > David > >> - Ioi >> >> On 8/18/14, 2:19 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> This is a request to temporarily add some instrumentation code to >>> hotspot to help diagnose the intermittent failure on Windows, which >>> results in a wrong exit code of (sub-)process. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >> > > From neugens.limasoftware at gmail.com Tue Aug 19 13:16:16 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 19 Aug 2014 15:16:16 +0200 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F26DFA.9010707@oracle.com> References: <53F26DFA.9010707@oracle.com> Message-ID: Is there any reason why this link is only accessible if I log-in? Mario 2014-08-18 23:19 GMT+02:00 Ivan Gerasimov : > Hello! > > This is a request to temporarily add some instrumentation code to hotspot to > help diagnose the intermittent failure on Windows, which results in a wrong > exit code of (sub-)process. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 > WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ > > Sincerely yours, > Ivan > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From daniel.daugherty at oracle.com Tue Aug 19 13:30:33 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Aug 2014 07:30:33 -0600 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F349B2.7010903@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> Message-ID: <53F35179.2050601@oracle.com> On 8/19/14 6:57 AM, Ivan Gerasimov wrote: > Hello again! > > I updated the patch to cover situations when the exiting thread isn't > daemon. > I also added load_acquire/store_release for the sake of accuracy, even > though on Windows they seem to add nothing to the volatile access. > > http://cr.openjdk.java.net/~igerasim/8055338/1/webrev/ src/os/windows/vm/os_windows.cpp No comments. src/share/vm/runtime/java.cpp No comments. Thumbs up. I like this version even more. Dan > > If the updated patch looks Okay, I'll need a sponsor to push it. > > Sincerely yours, > Ivan > > On 19.08.2014 6:42, David Holmes wrote: >> On 19/08/2014 10:12 AM, Ioi Lam wrote: >>> With the Windows/x86/x64 memory model, is the write to >>> vm_getting_terminated guaranteed to be observable by java_start()? >> >> In the general case, not immediately. For the threads actually of >> interest the logic that tells the threads to terminate happens after >> the write to the flag, and that logic contains sufficient >> "synchronization" that if the termination logic is correct then the >> flag must also be visible. >> >> David >> >>> - Ioi >>> >>> On 8/18/14, 2:19 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> This is a request to temporarily add some instrumentation code to >>>> hotspot to help diagnose the intermittent failure on Windows, which >>>> results in a wrong exit code of (sub-)process. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> >> >> > From ivan.gerasimov at oracle.com Tue Aug 19 14:12:56 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 19 Aug 2014 18:12:56 +0400 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: References: <53F26DFA.9010707@oracle.com> Message-ID: <53F35B68.6070607@oracle.com> This is a sub-task and it inherits its security level from the parent bug. It appears that Jira doesn't allow editing the security level of sub-tasks. Sincerely yours, Ivan On 19.08.2014 17:16, Mario Torre wrote: > Is there any reason why this link is only accessible if I log-in? > > Mario > > 2014-08-18 23:19 GMT+02:00 Ivan Gerasimov : >> Hello! >> >> This is a request to temporarily add some instrumentation code to hotspot to >> help diagnose the intermittent failure on Windows, which results in a wrong >> exit code of (sub-)process. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ >> >> Sincerely yours, >> Ivan >> > > From dmitry.samersoff at oracle.com Tue Aug 19 19:09:53 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 19 Aug 2014 23:09:53 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again Message-ID: <53F3A101.4050506@oracle.com> Hi Everybody, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ JDWP call jniFatalError if transport can't be initialized (e.g. wrong parameters) and jniFatalError call os::abort(). Therefor all transport initialization errors cause vm to coredump. I see no reason for debugInit_exit to call jniFatalError so remove this code. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Tue Aug 19 20:12:28 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Aug 2014 13:12:28 -0700 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F349B2.7010903@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> Message-ID: <53F3AFAC.7080103@oracle.com> Hi Ivan, It is a nice step in the investigation of this nasty and very old issue! The fix looks good in general. A minor comment: Is it possible to make the exit code more consistent in the os_windows.cpp? For instance, make them 70115, 80115 and 90115 instead of 70115, 80211 and 90223? Thanks, Serguei On 8/19/14 5:57 AM, Ivan Gerasimov wrote: > Hello again! > > I updated the patch to cover situations when the exiting thread isn't > daemon. > I also added load_acquire/store_release for the sake of accuracy, even > though on Windows they seem to add nothing to the volatile access. > > http://cr.openjdk.java.net/~igerasim/8055338/1/webrev/ > > If the updated patch looks Okay, I'll need a sponsor to push it. > > Sincerely yours, > Ivan > > On 19.08.2014 6:42, David Holmes wrote: >> On 19/08/2014 10:12 AM, Ioi Lam wrote: >>> With the Windows/x86/x64 memory model, is the write to >>> vm_getting_terminated guaranteed to be observable by java_start()? >> >> In the general case, not immediately. For the threads actually of >> interest the logic that tells the threads to terminate happens after >> the write to the flag, and that logic contains sufficient >> "synchronization" that if the termination logic is correct then the >> flag must also be visible. >> >> David >> >>> - Ioi >>> >>> On 8/18/14, 2:19 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> This is a request to temporarily add some instrumentation code to >>>> hotspot to help diagnose the intermittent failure on Windows, which >>>> results in a wrong exit code of (sub-)process. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8055338/0/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> >> >> > From serguei.spitsyn at oracle.com Tue Aug 19 20:54:54 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Aug 2014 13:54:54 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53F3A101.4050506@oracle.com> References: <53F3A101.4050506@oracle.com> Message-ID: <53F3B99E.7090203@oracle.com> Hi Dmitry, The fix seems to be Ok. Just want to make it clear... This fix just changes the bug pattern. It a case of incorrect transport parameters the test is still going to fail but without crash, right? Thanks, Serguei On 8/19/14 12:09 PM, Dmitry Samersoff wrote: > Hi Everybody, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ > > JDWP call jniFatalError if transport can't be initialized (e.g. wrong > parameters) and jniFatalError call os::abort(). Therefor all transport > initialization errors cause vm to coredump. > > I see no reason for debugInit_exit to call jniFatalError so remove this > code. > > -Dmitry > From daniel.daugherty at oracle.com Tue Aug 19 21:39:50 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Aug 2014 15:39:50 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53EE6B22.3040107@oracle.com> References: <53EE6B22.3040107@oracle.com> Message-ID: <53F3C426.9080408@oracle.com> On 8/15/14 2:18 PM, Coleen Phillimore wrote: > Summary: Use scratch_class to find EMCP methods for breakpoints if the > old methods are still running > > See bug for more details. This fix also includes a change to > nmethod::metadata_do() to not walk the _method multiple times (the > _method is added to the metadata section of the nmethod), and an > attempt to help the sweeper clean up these scratch_class instance > classes sooner. > > Tested with nsk tests, java/lang/instrument tests and jck tests (which > include some jvmti tests). > > open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ src/share/vm/oops/instanceKlass.hpp line 1047 // RedefineClass support Should be 'RedefineClasses'. line 1049: void mark_newly_obsolete_methods(Array* old_methods, int emcp_method_count); The 'obsolete' part of the function name does not match with the 'emcp' part of the parameter name. EMCP methods are 'old', but not 'obsolete'. Update: OK, I think I get it. We want to mark methods that are newly transitioning from EMCP -> obsolete and the emcp_method_count parameter tells us if there is any work to do. src/share/vm/oops/instanceKlass.cpp line 3023: } // pvw is cleaned up 'pvw' no longer exists so comment is stale. line 3455: // check the previous versions array This comment should move above this line: 3453 for (; pv_node != NULL; ) { and 'array' should change to 'list'. Sorry for the bad placement of the original comment. line 3463: last->link_previous_versions(pv_node); So now we've overwritten the previous value of last->previous_versions. How does that InstanceKlass get freed? Maybe a short comment? line 3484: // Mark the emcp method as obsolete if it's not executing I'm not sure about whether this is a good idea. When we had a redefine make a method obsolete before, we knew that we could make all older but previously EMCP methods obsolete because the new method version did make them obsolete. With this optimization, we're saying that no thread is executing the method so we're going to make it obsolete even if the current redefine did not do so. I worry about a method call that is in the early stages of assembling the call stack being caught calling a method that is now obsolete but not because of a redefine made it obsolete. Just FYI, one of the tracing flags catches unexpected calls to obsolete methods today and it does catch the current system's legitimate race. line 3527: // clear out any matching EMCP method entries the hard way. Perhaps "mark" instead of "clear out"? old line 3659: if (!method->is_obsolete() && new line 3546: if (method->is_emcp() && The old code is correct. The old code won't remark a method that was already made obsolete so there won't be more than one trace message for that operation. line 3581: // stack, and set emcp methods on the stack. In comments 'emcp' should be 'EMCP'. We did not do that in the code because of HotSpot's variable name style. Also, set what on EMCP methods on the stack? line 3591: ... If emcp method from line 3592: // a previous redefinition may be made obsolete by this redefinition. Having trouble parsing this comment. src/share/vm/oops/method.hpp line 693: // emcp methods (equivalent method except constant pool is different) line 694: // that are old but not obsolete or deleted. Perhaps: // EMCP methods are old but not obsolete or deleted. Equivalent // Modulo Constant Pool means the method is equivalent except // the constant pool and instructions that access the constant // pool might be different. src/share/vm/prims/jvmtiImpl.cpp No comments. src/share/vm/prims/jvmtiRedefineClasses.cpp No comments. src/share/vm/code/nmethod.cpp So in the original code f(_method) was being called two extra times? (once in the while-loop and once at the end) So I'm guessing that f(_method) is properly called when the rest of the metadata is handled in the nmethod (line 2085)? src/share/vm/memory/universe.cpp No comments (resisting 'The Walking Dead' ref...) test/runtime/RedefineTests/RedefineFinalizer.java No comments. test/runtime/RedefineTests/RedefineRunningMethods.java line 44: " while (!stop) { count2++; }" + line 53: while (!stop) { count1++; } line 56: while (!stop) { count2++; } These may not behave well on OSes with bad threading models. You might want to add a helper function that sleeps for 10ms and have each of these loops call it so the test more well behaved. Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8055008 > > Thanks, > Coleen From daniel.daugherty at oracle.com Tue Aug 19 22:53:37 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Aug 2014 16:53:37 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F3C426.9080408@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> Message-ID: <53F3D571.7060609@oracle.com> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: > On 8/15/14 2:18 PM, Coleen Phillimore wrote: >> Summary: Use scratch_class to find EMCP methods for breakpoints if >> the old methods are still running >> >> See bug for more details. This fix also includes a change to >> nmethod::metadata_do() to not walk the _method multiple times (the >> _method is added to the metadata section of the nmethod), and an >> attempt to help the sweeper clean up these scratch_class instance >> classes sooner. >> >> Tested with nsk tests, java/lang/instrument tests and jck tests >> (which include some jvmti tests). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ > > src/share/vm/oops/instanceKlass.hpp > line 1047 // RedefineClass support > Should be 'RedefineClasses'. > > line 1049: void mark_newly_obsolete_methods(Array* > old_methods, > int emcp_method_count); > The 'obsolete' part of the function name does not match with > the 'emcp' part of the parameter name. EMCP methods are 'old', > but not 'obsolete'. > > Update: OK, I think I get it. We want to mark methods that are > newly transitioning from EMCP -> obsolete and the > emcp_method_count > parameter tells us if there is any work to do. > > src/share/vm/oops/instanceKlass.cpp > line 3023: } // pvw is cleaned up > 'pvw' no longer exists so comment is stale. > > line 3455: // check the previous versions array > This comment should move above this line: > > 3453 for (; pv_node != NULL; ) { > > and 'array' should change to 'list'. > > Sorry for the bad placement of the original comment. > > line 3463: last->link_previous_versions(pv_node); > So now we've overwritten the previous value of > last->previous_versions. How does that InstanceKlass > get freed? Maybe a short comment? > > line 3484: // Mark the emcp method as obsolete if it's not executing > I'm not sure about whether this is a good idea. When we had a > redefine make a method obsolete before, we knew that we could > make all older but previously EMCP methods obsolete because > the new method version did make them obsolete. > > With this optimization, we're saying that no thread is executing > the method so we're going to make it obsolete even if the current > redefine did not do so. I worry about a method call that is in > the early stages of assembling the call stack being caught > calling a method that is now obsolete but not because of a > redefine made it obsolete. Just FYI, one of the tracing flags > catches unexpected calls to obsolete methods today and it does > catch the current system's legitimate race. JVM/TI has an isMethodObsolete() API: jvmtiError IsMethodObsolete(jvmtiEnv* env, jmethodID method, jboolean* is_obsolete_ptr) It would be possible for an agent to observe a method changing from not obsolete to obsolete when that's not expected. I suspect that this would be a spec violation. Dan > > line 3527: // clear out any matching EMCP method entries the hard > way. > Perhaps "mark" instead of "clear out"? > > old line 3659: if (!method->is_obsolete() && > new line 3546: if (method->is_emcp() && > The old code is correct. The old code won't remark a method that > was already made obsolete so there won't be more than one trace > message for that operation. > > line 3581: // stack, and set emcp methods on the stack. > In comments 'emcp' should be 'EMCP'. We did not do that in the > code because of HotSpot's variable name style. > > Also, set what on EMCP methods on the stack? > > line 3591: ... If emcp method from > line 3592: // a previous redefinition may be made obsolete by this > redefinition. > Having trouble parsing this comment. > > src/share/vm/oops/method.hpp > line 693: // emcp methods (equivalent method except constant pool > is different) > line 694: // that are old but not obsolete or deleted. > Perhaps: > > // EMCP methods are old but not obsolete or deleted. Equivalent > // Modulo Constant Pool means the method is equivalent except > // the constant pool and instructions that access the constant > // pool might be different. > > src/share/vm/prims/jvmtiImpl.cpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > src/share/vm/code/nmethod.cpp > So in the original code f(_method) was being called two extra > times? (once in the while-loop and once at the end) So I'm > guessing that f(_method) is properly called when the rest of > the metadata is handled in the nmethod (line 2085)? > > src/share/vm/memory/universe.cpp > No comments (resisting 'The Walking Dead' ref...) > > test/runtime/RedefineTests/RedefineFinalizer.java > No comments. > > test/runtime/RedefineTests/RedefineRunningMethods.java > line 44: " while (!stop) { count2++; }" + > line 53: while (!stop) { count1++; } > line 56: while (!stop) { count2++; } > > These may not behave well on OSes with bad threading > models. You might want to add a helper function that > sleeps for 10ms and have each of these loops call it > so the test more well behaved. > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >> >> Thanks, >> Coleen > > From serguei.spitsyn at oracle.com Tue Aug 19 23:52:59 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Aug 2014 16:52:59 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F3D571.7060609@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> Message-ID: <53F3E35B.5010205@oracle.com> On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: > > On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>> the old methods are still running >>> >>> See bug for more details. This fix also includes a change to >>> nmethod::metadata_do() to not walk the _method multiple times (the >>> _method is added to the metadata section of the nmethod), and an >>> attempt to help the sweeper clean up these scratch_class instance >>> classes sooner. >>> >>> Tested with nsk tests, java/lang/instrument tests and jck tests >>> (which include some jvmti tests). >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >> >> src/share/vm/oops/instanceKlass.hpp >> line 1047 // RedefineClass support >> Should be 'RedefineClasses'. >> >> line 1049: void mark_newly_obsolete_methods(Array* >> old_methods, >> int emcp_method_count); >> The 'obsolete' part of the function name does not match with >> the 'emcp' part of the parameter name. EMCP methods are 'old', >> but not 'obsolete'. >> >> Update: OK, I think I get it. We want to mark methods that are >> newly transitioning from EMCP -> obsolete and the >> emcp_method_count >> parameter tells us if there is any work to do. >> >> src/share/vm/oops/instanceKlass.cpp >> line 3023: } // pvw is cleaned up >> 'pvw' no longer exists so comment is stale. >> >> line 3455: // check the previous versions array >> This comment should move above this line: >> >> 3453 for (; pv_node != NULL; ) { >> >> and 'array' should change to 'list'. >> >> Sorry for the bad placement of the original comment. >> >> line 3463: last->link_previous_versions(pv_node); >> So now we've overwritten the previous value of >> last->previous_versions. How does that InstanceKlass >> get freed? Maybe a short comment? >> >> line 3484: // Mark the emcp method as obsolete if it's not executing >> I'm not sure about whether this is a good idea. When we had a >> redefine make a method obsolete before, we knew that we could >> make all older but previously EMCP methods obsolete because >> the new method version did make them obsolete. >> >> With this optimization, we're saying that no thread is executing >> the method so we're going to make it obsolete even if the >> current >> redefine did not do so. I worry about a method call that is in >> the early stages of assembling the call stack being caught >> calling a method that is now obsolete but not because of a >> redefine made it obsolete. Just FYI, one of the tracing flags >> catches unexpected calls to obsolete methods today and it does >> catch the current system's legitimate race. > > JVM/TI has an isMethodObsolete() API: > > jvmtiError > IsMethodObsolete(jvmtiEnv* env, > jmethodID method, > jboolean* is_obsolete_ptr) > > It would be possible for an agent to observe a method changing from > not obsolete to obsolete when that's not expected. I suspect that > this would be a spec violation. I agree that this looks like a spec violation. The emcp methods by definition are non-obsolete, or in opposite, the obsolete methods are non-emcp: http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods Old method versions may become obsolete, not emcp: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses But maybe I'm missing something... Thanks, Serguei > > Dan > > >> >> line 3527: // clear out any matching EMCP method entries the hard >> way. >> Perhaps "mark" instead of "clear out"? >> >> old line 3659: if (!method->is_obsolete() && >> new line 3546: if (method->is_emcp() && >> The old code is correct. The old code won't remark a method that >> was already made obsolete so there won't be more than one trace >> message for that operation. >> >> line 3581: // stack, and set emcp methods on the stack. >> In comments 'emcp' should be 'EMCP'. We did not do that in the >> code because of HotSpot's variable name style. >> >> Also, set what on EMCP methods on the stack? >> >> line 3591: ... If emcp method from >> line 3592: // a previous redefinition may be made obsolete by >> this redefinition. >> Having trouble parsing this comment. >> >> src/share/vm/oops/method.hpp >> line 693: // emcp methods (equivalent method except constant pool >> is different) >> line 694: // that are old but not obsolete or deleted. >> Perhaps: >> >> // EMCP methods are old but not obsolete or deleted. Equivalent >> // Modulo Constant Pool means the method is equivalent except >> // the constant pool and instructions that access the constant >> // pool might be different. >> >> src/share/vm/prims/jvmtiImpl.cpp >> No comments. >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> No comments. >> >> src/share/vm/code/nmethod.cpp >> So in the original code f(_method) was being called two extra >> times? (once in the while-loop and once at the end) So I'm >> guessing that f(_method) is properly called when the rest of >> the metadata is handled in the nmethod (line 2085)? >> >> src/share/vm/memory/universe.cpp >> No comments (resisting 'The Walking Dead' ref...) >> >> test/runtime/RedefineTests/RedefineFinalizer.java >> No comments. >> >> test/runtime/RedefineTests/RedefineRunningMethods.java >> line 44: " while (!stop) { count2++; }" + >> line 53: while (!stop) { count1++; } >> line 56: while (!stop) { count2++; } >> >> These may not behave well on OSes with bad threading >> models. You might want to add a helper function that >> sleeps for 10ms and have each of these loops call it >> so the test more well behaved. >> >> Dan >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>> >>> Thanks, >>> Coleen >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Aug 20 08:01:30 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 20 Aug 2014 12:01:30 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53F3B99E.7090203@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> Message-ID: <53F455DA.7070405@oracle.com> Serguei, 1. Historically JDI test-suite had no tests for failed transport initialization behavior and invalid parameters handling. 2. As a part of JDWP hardening work I added couple of such tests to OptionTest.java - these tests pass invalid parameters to dt_socket transport to make sure that transport doesn't crash (one such crash was discovered and fixed) but just return non-zero exit code to upper level. 3. After fix for JDK-6694099 any non-zero exit code from transport cause VM to coredump. Dumping multiple cores on busy machine takes a time so harness kills the test by timeout. We can just increase timeout for this test but I don't think it's a good idea to dump core when invalid parameters passed to transport. So there is the fix. 4. After the fix tests for negative parameters will return non-zero exit code as expected but will not dump the core. -Dmitry On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > The fix seems to be Ok. > Just want to make it clear... > This fix just changes the bug pattern. > It a case of incorrect transport parameters the test is still going to > fail but without crash, right? > > Thanks, > Serguei > > On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review the fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >> >> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >> parameters) and jniFatalError call os::abort(). Therefor all transport >> initialization errors cause vm to coredump. >> >> I see no reason for debugInit_exit to call jniFatalError so remove this >> code. >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Aug 20 08:08:55 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Aug 2014 01:08:55 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53F455DA.7070405@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> Message-ID: <53F45797.4040509@oracle.com> Ok. Thank you for the explanation! Serguei On 8/20/14 1:01 AM, Dmitry Samersoff wrote: > Serguei, > > 1. Historically JDI test-suite had no tests for failed transport > initialization behavior and invalid parameters handling. > > 2. As a part of JDWP hardening work I added couple of such tests to > OptionTest.java - these tests pass invalid parameters to dt_socket > transport to make sure that transport doesn't crash (one such crash was > discovered and fixed) but just return non-zero exit code to upper level. > > 3. After fix for JDK-6694099 any non-zero exit code from transport cause > VM to coredump. Dumping multiple cores on busy machine takes a time so > harness kills the test by timeout. > > We can just increase timeout for this test but I don't think it's a good > idea to dump core when invalid parameters passed to transport. > > So there is the fix. > > 4. After the fix tests for negative parameters will return non-zero exit > code as expected but will not dump the core. > > -Dmitry > > On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> The fix seems to be Ok. >> Just want to make it clear... >> This fix just changes the bug pattern. >> It a case of incorrect transport parameters the test is still going to >> fail but without crash, right? >> >> Thanks, >> Serguei >> >> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review the fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>> >>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>> parameters) and jniFatalError call os::abort(). Therefor all transport >>> initialization errors cause vm to coredump. >>> >>> I see no reason for debugInit_exit to call jniFatalError so remove this >>> code. >>> >>> -Dmitry >>> > From markus.gronlund at oracle.com Wed Aug 20 10:27:54 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 20 Aug 2014 03:27:54 -0700 (PDT) Subject: RFR (XXS): 8055662: Update mapfile for libjfr Message-ID: <7c0007fb-8843-4fbf-a8ff-27da6479cc91@default> Greetings, ? Kindly asking for review for this very small change. ? Bug: https://bugs.openjdk.java.net/browse/JDK-8055662 Webrev: http://cr.openjdk.java.net/~mgronlun/8055662/webrev01/ ? Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Aug 20 10:50:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 20 Aug 2014 12:50:53 +0200 Subject: RFR (XXS): 8055662: Update mapfile for libjfr In-Reply-To: <7c0007fb-8843-4fbf-a8ff-27da6479cc91@default> References: <7c0007fb-8843-4fbf-a8ff-27da6479cc91@default> Message-ID: <5A614EA8-B7D3-498B-8E52-5242E20B8CD9@oracle.com> Looks good! Thanks, /Staffan On 20 aug 2014, at 12:27, Markus Gr?nlund wrote: > Greetings, > > Kindly asking for review for this very small change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055662 > Webrev: http://cr.openjdk.java.net/~mgronlun/8055662/webrev01/ > > Thanks > Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Wed Aug 20 11:38:53 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 20 Aug 2014 13:38:53 +0200 Subject: RFR (XXS): 8055662: Update mapfile for libjfr In-Reply-To: <7c0007fb-8843-4fbf-a8ff-27da6479cc91@default> References: <7c0007fb-8843-4fbf-a8ff-27da6479cc91@default> Message-ID: <53F488CD.80902@oracle.com> Looks good Markus Gr?nlund skrev 20/08/14 12:27: > > Greetings, > > Kindly asking for review for this very small change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055662 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8055662/webrev01/ > > > Thanks > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Aug 20 13:06:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 20 Aug 2014 15:06:50 +0200 Subject: RFR: 8055673 test/com/sun/jdi/ShellScaffold.sh does not honor -javaoption Message-ID: <5A7C214F-9B05-4B84-BBC6-04180B06455C@oracle.com> All, Running something like: jtreg -javaoption:-Xmixed jdk/test/com/sun/jdi/RedefineStep.sh Will print an error message: test/com/sun/jdi/ShellScaffold.sh: line 885: -Xmixed: command not found The test will not fail, but the -javaoption argument will be ignored. The fix is to add some missing quotes: --- a/test/com/sun/jdi/ShellScaffold.sh +++ b/test/com/sun/jdi/ShellScaffold.sh @@ -882,7 +882,7 @@ startDebuggee() { - args=$TESTVMOPTS $TESTJAVAOPTS + args="$TESTVMOPTS $TESTJAVAOPTS" if [ ! -z "$args" ] ; then echo "--Starting debuggee with args from TESTVMOPTS and/or TESTJAVAOPTS: $args? Thanks, /Staffan From jaroslav.bachorik at oracle.com Wed Aug 20 13:49:41 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 20 Aug 2014 15:49:41 +0200 Subject: RFR: 8055673 test/com/sun/jdi/ShellScaffold.sh does not honor -javaoption In-Reply-To: <5A7C214F-9B05-4B84-BBC6-04180B06455C@oracle.com> References: <5A7C214F-9B05-4B84-BBC6-04180B06455C@oracle.com> Message-ID: <53F4A775.8070104@oracle.com> Thumbs up! -JB- On 08/20/2014 03:06 PM, Staffan Larsen wrote: > All, > > Running something like: > > jtreg -javaoption:-Xmixed jdk/test/com/sun/jdi/RedefineStep.sh > > Will print an error message: > > test/com/sun/jdi/ShellScaffold.sh: line 885: -Xmixed: command not found > > The test will not fail, but the -javaoption argument will be ignored. > > The fix is to add some missing quotes: > > --- a/test/com/sun/jdi/ShellScaffold.sh > +++ b/test/com/sun/jdi/ShellScaffold.sh > @@ -882,7 +882,7 @@ > > startDebuggee() > { > - args=$TESTVMOPTS $TESTJAVAOPTS > + args="$TESTVMOPTS $TESTJAVAOPTS" > > if [ ! -z "$args" ] ; then > echo "--Starting debuggee with args from TESTVMOPTS and/or TESTJAVAOPTS: $args? > > > Thanks, > /Staffan > From mandy.chung at oracle.com Wed Aug 20 15:24:57 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 Aug 2014 08:24:57 -0700 Subject: RFR: 8055673 test/com/sun/jdi/ShellScaffold.sh does not honor -javaoption In-Reply-To: <5A7C214F-9B05-4B84-BBC6-04180B06455C@oracle.com> References: <5A7C214F-9B05-4B84-BBC6-04180B06455C@oracle.com> Message-ID: <53F4BDC9.5020201@oracle.com> On 8/20/2014 6:06 AM, Staffan Larsen wrote: > All, > > Running something like: > > jtreg -javaoption:-Xmixed jdk/test/com/sun/jdi/RedefineStep.sh > > Will print an error message: > > test/com/sun/jdi/ShellScaffold.sh: line 885: -Xmixed: command not found > > The test will not fail, but the -javaoption argument will be ignored. > > The fix is to add some missing quotes: > > --- a/test/com/sun/jdi/ShellScaffold.sh > +++ b/test/com/sun/jdi/ShellScaffold.sh > @@ -882,7 +882,7 @@ > > startDebuggee() > { > - args=$TESTVMOPTS $TESTJAVAOPTS > + args="$TESTVMOPTS $TESTJAVAOPTS" > > if [ ! -z "$args" ] ; then > echo "--Starting debuggee with args from TESTVMOPTS and/or TESTJAVAOPTS: $args? > Looks okay. Mandy From coleen.phillimore at oracle.com Wed Aug 20 15:29:36 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 11:29:36 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F3C426.9080408@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> Message-ID: <53F4BEE0.60107@oracle.com> Dan, Thanks for taking the time to review this! On 8/19/14, 5:39 PM, Daniel D. Daugherty wrote: > On 8/15/14 2:18 PM, Coleen Phillimore wrote: >> Summary: Use scratch_class to find EMCP methods for breakpoints if >> the old methods are still running >> >> See bug for more details. This fix also includes a change to >> nmethod::metadata_do() to not walk the _method multiple times (the >> _method is added to the metadata section of the nmethod), and an >> attempt to help the sweeper clean up these scratch_class instance >> classes sooner. >> >> Tested with nsk tests, java/lang/instrument tests and jck tests >> (which include some jvmti tests). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ > > src/share/vm/oops/instanceKlass.hpp > line 1047 // RedefineClass support > Should be 'RedefineClasses'. Yes, fixed. > > line 1049: void mark_newly_obsolete_methods(Array* > old_methods, > int emcp_method_count); > The 'obsolete' part of the function name does not match with > the 'emcp' part of the parameter name. EMCP methods are 'old', > but not 'obsolete'. > > Update: OK, I think I get it. We want to mark methods that are > newly transitioning from EMCP -> obsolete and the > emcp_method_count > parameter tells us if there is any work to do. Yes, it's not used to figure out which ones are EMCP anymore, just to know if there are any. > > src/share/vm/oops/instanceKlass.cpp > line 3023: } // pvw is cleaned up > 'pvw' no longer exists so comment is stale. fixed. > > line 3455: // check the previous versions array > This comment should move above this line: > > 3453 for (; pv_node != NULL; ) { > > and 'array' should change to 'list'. > > Sorry for the bad placement of the original comment. ok. > > line 3463: last->link_previous_versions(pv_node); > So now we've overwritten the previous value of > last->previous_versions. How does that InstanceKlass > get freed? Maybe a short comment? // The previous version InstanceKlass is on the ClassLoaderData deallocate list // so will be deallocated during the next phase of class unloading. > > line 3484: // Mark the emcp method as obsolete if it's not executing > I'm not sure about whether this is a good idea. When we had a > redefine make a method obsolete before, we knew that we could > make all older but previously EMCP methods obsolete because > the new method version did make them obsolete. > > With this optimization, we're saying that no thread is executing > the method so we're going to make it obsolete even if the current > redefine did not do so. I worry about a method call that is in > the early stages of assembling the call stack being caught > calling a method that is now obsolete but not because of a > redefine made it obsolete. Just FYI, one of the tracing flags > catches unexpected calls to obsolete methods today and it does > catch the current system's legitimate race. I need to study this (I think your next email is about this too). I tried to preserve the behavior before but maybe I didn't. > > line 3527: // clear out any matching EMCP method entries the hard > way. > Perhaps "mark" instead of "clear out"? > > old line 3659: if (!method->is_obsolete() && > new line 3546: if (method->is_emcp() && > The old code is correct. The old code won't remark a method that > was already made obsolete so there won't be more than one trace > message for that operation. Since is_emcp() means !is_obsolete && !is_deleted, so ineffect I changed that to not include the deleted methods. So I think it's equivalent and I think I have to account for deleted methods in the previous_version instanceKlasses. > > line 3581: // stack, and set emcp methods on the stack. > In comments 'emcp' should be 'EMCP'. We did not do that in the > code because of HotSpot's variable name style. Yes, I can change all emcp to EMCP - should I change the is_EMCP() function as well? > > Also, set what on EMCP methods on the stack? This comment doesn't make very much sense. How about: But I may have to rewrite it because I think your point about line 3484: // Mark the emcp method as obsolete if it's not executing > line 3591: ... If emcp method from > line 3592: // a previous redefinition may be made obsolete by this > redefinition. > Having trouble parsing this comment. // Mark newly obsolete methods in remaining previous versions. An EMCP method from // a previous redefinition may be made obsolete by this redefinition. > > src/share/vm/oops/method.hpp > line 693: // emcp methods (equivalent method except constant pool > is different) > line 694: // that are old but not obsolete or deleted. > Perhaps: > > // EMCP methods are old but not obsolete or deleted. Equivalent > // Modulo Constant Pool means the method is equivalent except > // the constant pool and instructions that access the constant > // pool might be different. > Your comment is better, thanks! It's nice to have that comment there. > src/share/vm/prims/jvmtiImpl.cpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > src/share/vm/code/nmethod.cpp > So in the original code f(_method) was being called two extra > times? (once in the while-loop and once at the end) So I'm > guessing that f(_method) is properly called when the rest of > the metadata is handled in the nmethod (line 2085)? Yes. It is added to the metadata_section so didn't need an extra walk. This is only used for checking code and redefine classes, so it's safe to remove this. > > src/share/vm/memory/universe.cpp > No comments (resisting 'The Walking Dead' ref...) Yeah the sematics for zombie nmethods is chilling. > > test/runtime/RedefineTests/RedefineFinalizer.java > No comments. > > test/runtime/RedefineTests/RedefineRunningMethods.java > line 44: " while (!stop) { count2++; }" + > line 53: while (!stop) { count1++; } > line 56: while (!stop) { count2++; } > > These may not behave well on OSes with bad threading > models. You might want to add a helper function that > sleeps for 10ms and have each of these loops call it > so the test more well behaved. I don't like adding sleeps but you are right, we might not be able to interrupt these threads. I'll answer your other mail also. I think that you are right, we may be making EMCP methods obsolete too soon. Thanks for the spending time and thinking hard about this. This is some complicated code. Coleen > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Wed Aug 20 15:54:05 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 11:54:05 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F3E35B.5010205@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> Message-ID: <53F4C49D.4070404@oracle.com> Hi, it appears that my code is wrong and maybe the existing code is wrong also. I have a spec question below. On 8/19/14, 7:52 PM, serguei.spitsyn at oracle.com wrote: > On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: >> >> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >>> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>>> the old methods are still running >>>> >>>> See bug for more details. This fix also includes a change to >>>> nmethod::metadata_do() to not walk the _method multiple times (the >>>> _method is added to the metadata section of the nmethod), and an >>>> attempt to help the sweeper clean up these scratch_class instance >>>> classes sooner. >>>> >>>> Tested with nsk tests, java/lang/instrument tests and jck tests >>>> (which include some jvmti tests). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >>> >>> src/share/vm/oops/instanceKlass.hpp >>> line 1047 // RedefineClass support >>> Should be 'RedefineClasses'. >>> >>> line 1049: void mark_newly_obsolete_methods(Array* >>> old_methods, >>> int emcp_method_count); >>> The 'obsolete' part of the function name does not match with >>> the 'emcp' part of the parameter name. EMCP methods are 'old', >>> but not 'obsolete'. >>> >>> Update: OK, I think I get it. We want to mark methods that are >>> newly transitioning from EMCP -> obsolete and the >>> emcp_method_count >>> parameter tells us if there is any work to do. >>> >>> src/share/vm/oops/instanceKlass.cpp >>> line 3023: } // pvw is cleaned up >>> 'pvw' no longer exists so comment is stale. >>> >>> line 3455: // check the previous versions array >>> This comment should move above this line: >>> >>> 3453 for (; pv_node != NULL; ) { >>> >>> and 'array' should change to 'list'. >>> >>> Sorry for the bad placement of the original comment. >>> >>> line 3463: last->link_previous_versions(pv_node); >>> So now we've overwritten the previous value of >>> last->previous_versions. How does that InstanceKlass >>> get freed? Maybe a short comment? >>> >>> line 3484: // Mark the emcp method as obsolete if it's not >>> executing >>> I'm not sure about whether this is a good idea. When we had a >>> redefine make a method obsolete before, we knew that we could >>> make all older but previously EMCP methods obsolete because >>> the new method version did make them obsolete. >>> >>> With this optimization, we're saying that no thread is >>> executing >>> the method so we're going to make it obsolete even if the >>> current >>> redefine did not do so. I worry about a method call that is in >>> the early stages of assembling the call stack being caught >>> calling a method that is now obsolete but not because of a >>> redefine made it obsolete. Just FYI, one of the tracing flags >>> catches unexpected calls to obsolete methods today and it does >>> catch the current system's legitimate race. >> >> JVM/TI has an isMethodObsolete() API: >> >> jvmtiError >> IsMethodObsolete(jvmtiEnv* env, >> jmethodID method, >> jboolean* is_obsolete_ptr) >> >> It would be possible for an agent to observe a method changing from >> not obsolete to obsolete when that's not expected. I suspect that >> this would be a spec violation. > > I agree that this looks like a spec violation. > The emcp methods by definition are non-obsolete, > or in opposite, the obsolete methods are non-emcp: > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods > > Old method versions may become obsolete, not emcp: > http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses > > But maybe I'm missing something... If an EMCP method is not running, should we save it on a previous version list anyway so that we can make it obsolete if it's redefined and made obsolete? Currently we don't save previous versions of methods that are not running. We didn't before permgen elimination either. If GC didn't find the EMCP method, we would remove the entry. Thanks, Coleen > > > Thanks, > Serguei > >> >> Dan >> >> >>> >>> line 3527: // clear out any matching EMCP method entries the >>> hard way. >>> Perhaps "mark" instead of "clear out"? >>> >>> old line 3659: if (!method->is_obsolete() && >>> new line 3546: if (method->is_emcp() && >>> The old code is correct. The old code won't remark a method >>> that >>> was already made obsolete so there won't be more than one trace >>> message for that operation. >>> >>> line 3581: // stack, and set emcp methods on the stack. >>> In comments 'emcp' should be 'EMCP'. We did not do that in the >>> code because of HotSpot's variable name style. >>> >>> Also, set what on EMCP methods on the stack? >>> >>> line 3591: ... If emcp method from >>> line 3592: // a previous redefinition may be made obsolete by >>> this redefinition. >>> Having trouble parsing this comment. >>> >>> src/share/vm/oops/method.hpp >>> line 693: // emcp methods (equivalent method except constant >>> pool is different) >>> line 694: // that are old but not obsolete or deleted. >>> Perhaps: >>> >>> // EMCP methods are old but not obsolete or deleted. Equivalent >>> // Modulo Constant Pool means the method is equivalent except >>> // the constant pool and instructions that access the constant >>> // pool might be different. >>> >>> src/share/vm/prims/jvmtiImpl.cpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>> No comments. >>> >>> src/share/vm/code/nmethod.cpp >>> So in the original code f(_method) was being called two extra >>> times? (once in the while-loop and once at the end) So I'm >>> guessing that f(_method) is properly called when the rest of >>> the metadata is handled in the nmethod (line 2085)? >>> >>> src/share/vm/memory/universe.cpp >>> No comments (resisting 'The Walking Dead' ref...) >>> >>> test/runtime/RedefineTests/RedefineFinalizer.java >>> No comments. >>> >>> test/runtime/RedefineTests/RedefineRunningMethods.java >>> line 44: " while (!stop) { count2++; }" + >>> line 53: while (!stop) { count1++; } >>> line 56: while (!stop) { count2++; } >>> >>> These may not behave well on OSes with bad threading >>> models. You might want to add a helper function that >>> sleeps for 10ms and have each of these loops call it >>> so the test more well behaved. >>> >>> Dan >>> >>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>> >>>> Thanks, >>>> Coleen >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Aug 20 15:55:08 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 20 Aug 2014 19:55:08 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53F45797.4040509@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> Message-ID: <53F4C4DC.9090903@oracle.com> Serguei, After some additional testing I changed the fix a bit. Please take a look at new version. http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ New version reports JVMTI error to stderr. Also jniFatalError is not referenced any more so I remove it. -Dmitry On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: > Ok. > > Thank you for the explanation! > Serguei > > On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >> Serguei, >> >> 1. Historically JDI test-suite had no tests for failed transport >> initialization behavior and invalid parameters handling. >> >> 2. As a part of JDWP hardening work I added couple of such tests to >> OptionTest.java - these tests pass invalid parameters to dt_socket >> transport to make sure that transport doesn't crash (one such crash was >> discovered and fixed) but just return non-zero exit code to upper level. >> >> 3. After fix for JDK-6694099 any non-zero exit code from transport cause >> VM to coredump. Dumping multiple cores on busy machine takes a time so >> harness kills the test by timeout. >> >> We can just increase timeout for this test but I don't think it's a good >> idea to dump core when invalid parameters passed to transport. >> >> So there is the fix. >> >> 4. After the fix tests for negative parameters will return non-zero exit >> code as expected but will not dump the core. >> >> -Dmitry >> >> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>> Hi Dmitry, >>> >>> The fix seems to be Ok. >>> Just want to make it clear... >>> This fix just changes the bug pattern. >>> It a case of incorrect transport parameters the test is still going to >>> fail but without crash, right? >>> >>> Thanks, >>> Serguei >>> >>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>> Hi Everybody, >>>> >>>> Please review the fix: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>> >>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>> parameters) and jniFatalError call os::abort(). Therefor all transport >>>> initialization errors cause vm to coredump. >>>> >>>> I see no reason for debugInit_exit to call jniFatalError so remove this >>>> code. >>>> >>>> -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 ivan.gerasimov at oracle.com Wed Aug 20 19:36:00 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 20 Aug 2014 23:36:00 +0400 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F3AFAC.7080103@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> <53F3AFAC.7080103@oracle.com> Message-ID: <53F4F8A0.9050308@oracle.com> Hello everyone! Here's the third version of the webrev: http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ The control build of the previous one was causing a lot of test failures. This one seems to be innocent enough: no new test failures so far. Additionally, this version keeps the timing around the thread exit close to original, which might be important if we deal with a race. Sincerely yours, Ivan From serguei.spitsyn at oracle.com Wed Aug 20 19:49:47 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Aug 2014 12:49:47 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4C49D.4070404@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> Message-ID: <53F4FBDB.9080508@oracle.com> On 8/20/14 8:54 AM, Coleen Phillimore wrote: > > Hi, it appears that my code is wrong and maybe the existing code is > wrong also. I have a spec question below. > > On 8/19/14, 7:52 PM, serguei.spitsyn at oracle.com wrote: >> On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: >>> >>> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >>>> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>>>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>>>> the old methods are still running >>>>> >>>>> See bug for more details. This fix also includes a change to >>>>> nmethod::metadata_do() to not walk the _method multiple times (the >>>>> _method is added to the metadata section of the nmethod), and an >>>>> attempt to help the sweeper clean up these scratch_class instance >>>>> classes sooner. >>>>> >>>>> Tested with nsk tests, java/lang/instrument tests and jck tests >>>>> (which include some jvmti tests). >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >>>> >>>> src/share/vm/oops/instanceKlass.hpp >>>> line 1047 // RedefineClass support >>>> Should be 'RedefineClasses'. >>>> >>>> line 1049: void mark_newly_obsolete_methods(Array* >>>> old_methods, >>>> int emcp_method_count); >>>> The 'obsolete' part of the function name does not match with >>>> the 'emcp' part of the parameter name. EMCP methods are 'old', >>>> but not 'obsolete'. >>>> >>>> Update: OK, I think I get it. We want to mark methods that are >>>> newly transitioning from EMCP -> obsolete and the >>>> emcp_method_count >>>> parameter tells us if there is any work to do. >>>> >>>> src/share/vm/oops/instanceKlass.cpp >>>> line 3023: } // pvw is cleaned up >>>> 'pvw' no longer exists so comment is stale. >>>> >>>> line 3455: // check the previous versions array >>>> This comment should move above this line: >>>> >>>> 3453 for (; pv_node != NULL; ) { >>>> >>>> and 'array' should change to 'list'. >>>> >>>> Sorry for the bad placement of the original comment. >>>> >>>> line 3463: last->link_previous_versions(pv_node); >>>> So now we've overwritten the previous value of >>>> last->previous_versions. How does that InstanceKlass >>>> get freed? Maybe a short comment? >>>> >>>> line 3484: // Mark the emcp method as obsolete if it's not >>>> executing >>>> I'm not sure about whether this is a good idea. When we had a >>>> redefine make a method obsolete before, we knew that we could >>>> make all older but previously EMCP methods obsolete because >>>> the new method version did make them obsolete. >>>> >>>> With this optimization, we're saying that no thread is >>>> executing >>>> the method so we're going to make it obsolete even if the >>>> current >>>> redefine did not do so. I worry about a method call that is in >>>> the early stages of assembling the call stack being caught >>>> calling a method that is now obsolete but not because of a >>>> redefine made it obsolete. Just FYI, one of the tracing flags >>>> catches unexpected calls to obsolete methods today and it does >>>> catch the current system's legitimate race. >>> >>> JVM/TI has an isMethodObsolete() API: >>> >>> jvmtiError >>> IsMethodObsolete(jvmtiEnv* env, >>> jmethodID method, >>> jboolean* is_obsolete_ptr) >>> >>> It would be possible for an agent to observe a method changing from >>> not obsolete to obsolete when that's not expected. I suspect that >>> this would be a spec violation. >> >> I agree that this looks like a spec violation. >> The emcp methods by definition are non-obsolete, >> or in opposite, the obsolete methods are non-emcp: >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods >> >> Old method versions may become obsolete, not emcp: >> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses >> >> But maybe I'm missing something... > > If an EMCP method is not running, should we save it on a previous > version list anyway so that we can make it obsolete if it's redefined > and made obsolete? I hope, Dan will catch me if I'm wrong... I think, we should not. An EMCP method can not be made obsolete if it is not running. BTW, I'm reviewing the webrev too, but probably it'd be better to switch to updated webrev after it is ready. Thanks, Serguei > > Currently we don't save previous versions of methods that are not > running. We didn't before permgen elimination either. If GC didn't > find the EMCP method, we would remove the entry. > > Thanks, > Coleen > >> >> >> Thanks, >> Serguei >> >>> >>> Dan >>> >>> >>>> >>>> line 3527: // clear out any matching EMCP method entries the >>>> hard way. >>>> Perhaps "mark" instead of "clear out"? >>>> >>>> old line 3659: if (!method->is_obsolete() && >>>> new line 3546: if (method->is_emcp() && >>>> The old code is correct. The old code won't remark a method >>>> that >>>> was already made obsolete so there won't be more than one >>>> trace >>>> message for that operation. >>>> >>>> line 3581: // stack, and set emcp methods on the stack. >>>> In comments 'emcp' should be 'EMCP'. We did not do that in the >>>> code because of HotSpot's variable name style. >>>> >>>> Also, set what on EMCP methods on the stack? >>>> >>>> line 3591: ... If emcp method from >>>> line 3592: // a previous redefinition may be made obsolete by >>>> this redefinition. >>>> Having trouble parsing this comment. >>>> >>>> src/share/vm/oops/method.hpp >>>> line 693: // emcp methods (equivalent method except constant >>>> pool is different) >>>> line 694: // that are old but not obsolete or deleted. >>>> Perhaps: >>>> >>>> // EMCP methods are old but not obsolete or deleted. >>>> Equivalent >>>> // Modulo Constant Pool means the method is equivalent except >>>> // the constant pool and instructions that access the constant >>>> // pool might be different. >>>> >>>> src/share/vm/prims/jvmtiImpl.cpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> No comments. >>>> >>>> src/share/vm/code/nmethod.cpp >>>> So in the original code f(_method) was being called two extra >>>> times? (once in the while-loop and once at the end) So I'm >>>> guessing that f(_method) is properly called when the rest of >>>> the metadata is handled in the nmethod (line 2085)? >>>> >>>> src/share/vm/memory/universe.cpp >>>> No comments (resisting 'The Walking Dead' ref...) >>>> >>>> test/runtime/RedefineTests/RedefineFinalizer.java >>>> No comments. >>>> >>>> test/runtime/RedefineTests/RedefineRunningMethods.java >>>> line 44: " while (!stop) { count2++; }" + >>>> line 53: while (!stop) { count1++; } >>>> line 56: while (!stop) { count2++; } >>>> >>>> These may not behave well on OSes with bad threading >>>> models. You might want to add a helper function that >>>> sleeps for 10ms and have each of these loops call it >>>> so the test more well behaved. >>>> >>>> Dan >>>> >>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Aug 20 20:01:41 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 16:01:41 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4FBDB.9080508@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> Message-ID: <53F4FEA5.2090606@oracle.com> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >> >> If an EMCP method is not running, should we save it on a previous >> version list anyway so that we can make it obsolete if it's redefined >> and made obsolete? > > I hope, Dan will catch me if I'm wrong... > > I think, we should not. > An EMCP method can not be made obsolete if it is not running. > It should be this way otherwise we'd have to hang onto things forever. > > BTW, I'm reviewing the webrev too, but probably it'd be better to > switch to updated webrev after it is ready. Yes, this is a good idea. I figured out why I made emcp methods obsolete, and I'm fixing that as well as Dan's comments. Thanks! Coleen > > Thanks, > Serguei From daniel.daugherty at oracle.com Wed Aug 20 22:26:14 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 16:26:14 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4BEE0.60107@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F4BEE0.60107@oracle.com> Message-ID: <53F52086.2070307@oracle.com> On 8/20/14 9:29 AM, Coleen Phillimore wrote: > Dan, > Thanks for taking the time to review this! No problem. More responses below... > > On 8/19/14, 5:39 PM, Daniel D. Daugherty wrote: >> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>> the old methods are still running >>> >>> See bug for more details. This fix also includes a change to >>> nmethod::metadata_do() to not walk the _method multiple times (the >>> _method is added to the metadata section of the nmethod), and an >>> attempt to help the sweeper clean up these scratch_class instance >>> classes sooner. >>> >>> Tested with nsk tests, java/lang/instrument tests and jck tests >>> (which include some jvmti tests). >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >> >> src/share/vm/oops/instanceKlass.hpp >> line 1047 // RedefineClass support >> Should be 'RedefineClasses'. > > Yes, fixed. >> >> line 1049: void mark_newly_obsolete_methods(Array* >> old_methods, >> int emcp_method_count); >> The 'obsolete' part of the function name does not match with >> the 'emcp' part of the parameter name. EMCP methods are 'old', >> but not 'obsolete'. >> >> Update: OK, I think I get it. We want to mark methods that are >> newly transitioning from EMCP -> obsolete and the >> emcp_method_count >> parameter tells us if there is any work to do. > > Yes, it's not used to figure out which ones are EMCP anymore, just to > know if there are any. >> >> src/share/vm/oops/instanceKlass.cpp >> line 3023: } // pvw is cleaned up >> 'pvw' no longer exists so comment is stale. > > fixed. >> >> line 3455: // check the previous versions array >> This comment should move above this line: >> >> 3453 for (; pv_node != NULL; ) { >> >> and 'array' should change to 'list'. >> >> Sorry for the bad placement of the original comment. > > ok. > >> >> line 3463: last->link_previous_versions(pv_node); >> So now we've overwritten the previous value of >> last->previous_versions. How does that InstanceKlass >> get freed? Maybe a short comment? > > // The previous version InstanceKlass is on the > ClassLoaderData deallocate list > // so will be deallocated during the next phase of class > unloading. Like the new comment. > >> line 3484: // Mark the emcp method as obsolete if it's not executing >> I'm not sure about whether this is a good idea. When we had a >> redefine make a method obsolete before, we knew that we could >> make all older but previously EMCP methods obsolete because >> the new method version did make them obsolete. >> >> With this optimization, we're saying that no thread is executing >> the method so we're going to make it obsolete even if the >> current >> redefine did not do so. I worry about a method call that is in >> the early stages of assembling the call stack being caught >> calling a method that is now obsolete but not because of a >> redefine made it obsolete. Just FYI, one of the tracing flags >> catches unexpected calls to obsolete methods today and it does >> catch the current system's legitimate race. > > I need to study this (I think your next email is about this too). I > tried to preserve the behavior before but maybe I didn't. I'll pick this one up in the later reply. >> >> line 3527: // clear out any matching EMCP method entries the hard >> way. >> Perhaps "mark" instead of "clear out"? >> >> old line 3659: if (!method->is_obsolete() && >> new line 3546: if (method->is_emcp() && >> The old code is correct. The old code won't remark a method that >> was already made obsolete so there won't be more than one trace >> message for that operation. > > Since is_emcp() means !is_obsolete && !is_deleted, so ineffect I > changed that to not include the deleted methods. So I think it's > equivalent and I think I have to account for deleted methods in the > previous_version instanceKlasses. Thanks for setting me straight and I agree you are right here. >> >> line 3581: // stack, and set emcp methods on the stack. >> In comments 'emcp' should be 'EMCP'. We did not do that in the >> code because of HotSpot's variable name style. > > Yes, I can change all emcp to EMCP - should I change the is_EMCP() > function as well? Just in the comments (I think). I'm fairly certain that we didn't use EMCP in code, but I could be wrong... >> >> Also, set what on EMCP methods on the stack? > > This comment doesn't make very much sense. How about: > > But I may have to rewrite it because I think your point about > > line 3484: // Mark the emcp method as obsolete if it's not executing Right, we'll finalize the comment later. > >> line 3591: ... If emcp method from >> line 3592: // a previous redefinition may be made obsolete by >> this redefinition. >> Having trouble parsing this comment. > > // Mark newly obsolete methods in remaining previous versions. An > EMCP method from > // a previous redefinition may be made obsolete by this redefinition. I like the new comment. > >> src/share/vm/oops/method.hpp >> line 693: // emcp methods (equivalent method except constant pool >> is different) >> line 694: // that are old but not obsolete or deleted. >> Perhaps: >> >> // EMCP methods are old but not obsolete or deleted. Equivalent >> // Modulo Constant Pool means the method is equivalent except >> // the constant pool and instructions that access the constant >> // pool might be different. >> > > Your comment is better, thanks! It's nice to have that comment there. Glad you like it. > >> src/share/vm/prims/jvmtiImpl.cpp >> No comments. >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> No comments. >> >> src/share/vm/code/nmethod.cpp >> So in the original code f(_method) was being called two extra >> times? (once in the while-loop and once at the end) So I'm >> guessing that f(_method) is properly called when the rest of >> the metadata is handled in the nmethod (line 2085)? > > Yes. It is added to the metadata_section so didn't need an extra > walk. This is only used for checking code and redefine classes, so > it's safe to remove this. Thanks for confirming. Kinda reminds me of the oop-map stuff... :-) > >> src/share/vm/memory/universe.cpp >> No comments (resisting 'The Walking Dead' ref...) > > Yeah the sematics for zombie nmethods is chilling. Meant to have a :-) in that comment... :-O >> >> test/runtime/RedefineTests/RedefineFinalizer.java >> No comments. >> >> test/runtime/RedefineTests/RedefineRunningMethods.java >> line 44: " while (!stop) { count2++; }" + >> line 53: while (!stop) { count1++; } >> line 56: while (!stop) { count2++; } >> >> These may not behave well on OSes with bad threading >> models. You might want to add a helper function that >> sleeps for 10ms and have each of these loops call it >> so the test more well behaved. > > I don't like adding sleeps but you are right, we might not be able to > interrupt these threads. I agree when the sleep() calls are for timing or "correctness". In this case, they are for not swamping the test machine... > I'll answer your other mail also. I think that you are right, we may > be making EMCP methods obsolete too soon. > > Thanks for the spending time and thinking hard about this. This is > some complicated code. Do It Yourself brain surgery usually is... :-) Dan > > Coleen >> >> Dan >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>> >>> Thanks, >>> Coleen >> > From daniel.daugherty at oracle.com Wed Aug 20 22:37:50 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 16:37:50 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4C49D.4070404@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> Message-ID: <53F5233E.2070508@oracle.com> On 8/20/14 9:54 AM, Coleen Phillimore wrote: > > Hi, it appears that my code is wrong and maybe the existing code is > wrong also. I have a spec question below. Rely embedded below... > > On 8/19/14, 7:52 PM, serguei.spitsyn at oracle.com wrote: >> On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: >>> >>> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >>>> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>>>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>>>> the old methods are still running >>>>> >>>>> See bug for more details. This fix also includes a change to >>>>> nmethod::metadata_do() to not walk the _method multiple times (the >>>>> _method is added to the metadata section of the nmethod), and an >>>>> attempt to help the sweeper clean up these scratch_class instance >>>>> classes sooner. >>>>> >>>>> Tested with nsk tests, java/lang/instrument tests and jck tests >>>>> (which include some jvmti tests). >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >>>> >>>> src/share/vm/oops/instanceKlass.hpp >>>> line 1047 // RedefineClass support >>>> Should be 'RedefineClasses'. >>>> >>>> line 1049: void mark_newly_obsolete_methods(Array* >>>> old_methods, >>>> int emcp_method_count); >>>> The 'obsolete' part of the function name does not match with >>>> the 'emcp' part of the parameter name. EMCP methods are 'old', >>>> but not 'obsolete'. >>>> >>>> Update: OK, I think I get it. We want to mark methods that are >>>> newly transitioning from EMCP -> obsolete and the >>>> emcp_method_count >>>> parameter tells us if there is any work to do. >>>> >>>> src/share/vm/oops/instanceKlass.cpp >>>> line 3023: } // pvw is cleaned up >>>> 'pvw' no longer exists so comment is stale. >>>> >>>> line 3455: // check the previous versions array >>>> This comment should move above this line: >>>> >>>> 3453 for (; pv_node != NULL; ) { >>>> >>>> and 'array' should change to 'list'. >>>> >>>> Sorry for the bad placement of the original comment. >>>> >>>> line 3463: last->link_previous_versions(pv_node); >>>> So now we've overwritten the previous value of >>>> last->previous_versions. How does that InstanceKlass >>>> get freed? Maybe a short comment? >>>> >>>> line 3484: // Mark the emcp method as obsolete if it's not >>>> executing >>>> I'm not sure about whether this is a good idea. When we had a >>>> redefine make a method obsolete before, we knew that we could >>>> make all older but previously EMCP methods obsolete because >>>> the new method version did make them obsolete. >>>> >>>> With this optimization, we're saying that no thread is >>>> executing >>>> the method so we're going to make it obsolete even if the >>>> current >>>> redefine did not do so. I worry about a method call that is in >>>> the early stages of assembling the call stack being caught >>>> calling a method that is now obsolete but not because of a >>>> redefine made it obsolete. Just FYI, one of the tracing flags >>>> catches unexpected calls to obsolete methods today and it does >>>> catch the current system's legitimate race. >>> >>> JVM/TI has an isMethodObsolete() API: >>> >>> jvmtiError >>> IsMethodObsolete(jvmtiEnv* env, >>> jmethodID method, >>> jboolean* is_obsolete_ptr) >>> >>> It would be possible for an agent to observe a method changing from >>> not obsolete to obsolete when that's not expected. I suspect that >>> this would be a spec violation. >> >> I agree that this looks like a spec violation. >> The emcp methods by definition are non-obsolete, >> or in opposite, the obsolete methods are non-emcp: >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods >> >> Old method versions may become obsolete, not emcp: >> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses >> >> But maybe I'm missing something... > > If an EMCP method is not running, should we save it on a previous > version list anyway so that we can make it obsolete if it's redefined > and made obsolete? Interesting question. The problem with an EMCP method is that it might not be running right now, but we could have a Java thread that's in the process of invoking it that is stopped on a safepoint. We resume the world and the Java thread finishes calling the EMCP method... It's really hard to catch in-progress uses of jmethodIDs and make sure that the in-progress use switches from the EMCP method to the latest version of the method. A rarely seen race, but it does happen... > Currently we don't save previous versions of methods that are not > running. We didn't before permgen elimination either. If GC didn't > find the EMCP method, we would remove the entry. Not quite true for the pre-PermGen-Removal (PGR) world. We used to save weak refs for all of the EMCP methods in the previous version info. As the EMCP methods became collectible we removed them from the previous version info. This means if GC could find the EMCP method anywhere (stack, jmethodID, JNI handle, etc), then it stayed alive. This means that even if no thread was currently executing an EMCP method, an in-progress call to that method could still complete and poof now we have the EMCP method back on a stack somewhere... Dan > > Thanks, > Coleen > >> >> >> Thanks, >> Serguei >> >>> >>> Dan >>> >>> >>>> >>>> line 3527: // clear out any matching EMCP method entries the >>>> hard way. >>>> Perhaps "mark" instead of "clear out"? >>>> >>>> old line 3659: if (!method->is_obsolete() && >>>> new line 3546: if (method->is_emcp() && >>>> The old code is correct. The old code won't remark a method >>>> that >>>> was already made obsolete so there won't be more than one >>>> trace >>>> message for that operation. >>>> >>>> line 3581: // stack, and set emcp methods on the stack. >>>> In comments 'emcp' should be 'EMCP'. We did not do that in the >>>> code because of HotSpot's variable name style. >>>> >>>> Also, set what on EMCP methods on the stack? >>>> >>>> line 3591: ... If emcp method from >>>> line 3592: // a previous redefinition may be made obsolete by >>>> this redefinition. >>>> Having trouble parsing this comment. >>>> >>>> src/share/vm/oops/method.hpp >>>> line 693: // emcp methods (equivalent method except constant >>>> pool is different) >>>> line 694: // that are old but not obsolete or deleted. >>>> Perhaps: >>>> >>>> // EMCP methods are old but not obsolete or deleted. >>>> Equivalent >>>> // Modulo Constant Pool means the method is equivalent except >>>> // the constant pool and instructions that access the constant >>>> // pool might be different. >>>> >>>> src/share/vm/prims/jvmtiImpl.cpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> No comments. >>>> >>>> src/share/vm/code/nmethod.cpp >>>> So in the original code f(_method) was being called two extra >>>> times? (once in the while-loop and once at the end) So I'm >>>> guessing that f(_method) is properly called when the rest of >>>> the metadata is handled in the nmethod (line 2085)? >>>> >>>> src/share/vm/memory/universe.cpp >>>> No comments (resisting 'The Walking Dead' ref...) >>>> >>>> test/runtime/RedefineTests/RedefineFinalizer.java >>>> No comments. >>>> >>>> test/runtime/RedefineTests/RedefineRunningMethods.java >>>> line 44: " while (!stop) { count2++; }" + >>>> line 53: while (!stop) { count1++; } >>>> line 56: while (!stop) { count2++; } >>>> >>>> These may not behave well on OSes with bad threading >>>> models. You might want to add a helper function that >>>> sleeps for 10ms and have each of these loops call it >>>> so the test more well behaved. >>>> >>>> Dan >>>> >>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Aug 20 22:45:53 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 16:45:53 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4FEA5.2090606@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> Message-ID: <53F52521.1080309@oracle.com> On 8/20/14 2:01 PM, Coleen Phillimore wrote: > On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>> >>> If an EMCP method is not running, should we save it on a previous >>> version list anyway so that we can make it obsolete if it's >>> redefined and made obsolete? >> >> I hope, Dan will catch me if I'm wrong... >> >> I think, we should not. >> An EMCP method can not be made obsolete if it is not running. >> > > > It should be this way otherwise we'd have to hang onto things forever. An EMCP method should only be made obsolete if a RedefineClasses() or RetransformClasses() operation made it so. We should not be leveraging off the obsolete-ness attribute to solve a life-cycle problem. In the pre-PGR world, we could trust GC to make a completely unused EMCP method collectible and eventually our weak reference would go away. Just because an EMCP method is not on a stack does not mean that it is not used so we need a different way to determine whether it is OK to no longer track an EMCP method. > >> BTW, I'm reviewing the webrev too, but probably it'd be better to >> switch to updated webrev after it is ready. > > Yes, this is a good idea. I figured out why I made emcp methods > obsolete, and I'm fixing that as well as Dan's comments. Thanks! Cool! I'm looking forward to the next review. Dan > > Coleen > >> >> Thanks, >> Serguei > From coleen.phillimore at oracle.com Thu Aug 21 01:20:11 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 21:20:11 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F5233E.2070508@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F5233E.2070508@oracle.com> Message-ID: <53F5494B.7030008@oracle.com> On 8/20/14, 6:37 PM, Daniel D. Daugherty wrote: > On 8/20/14 9:54 AM, Coleen Phillimore wrote: >> >> Hi, it appears that my code is wrong and maybe the existing code is >> wrong also. I have a spec question below. > > Rely embedded below... Also embedded reply but I cut some stuff out. > ... >> If an EMCP method is not running, should we save it on a previous >> version list anyway so that we can make it obsolete if it's redefined >> and made obsolete? > > Interesting question. The problem with an EMCP method is that it might > not be running right now, but we could have a Java thread that's in > the process of invoking it that is stopped on a safepoint. We resume > the world and the Java thread finishes calling the EMCP method... > > It's really hard to catch in-progress uses of jmethodIDs and make > sure that the in-progress use switches from the EMCP method to the > latest version of the method. A rarely seen race, but it does happen... > Yes, there may be small cases where EMCP methods could be brought back to life, possibly with jmethodIDs. Although the combination of changing Method* in the cpCache for the interpreter, making old methods non-entrant and deoptimized, and replacing jmethodIDs should prevent it mostly if not completely. I wouldn't be surprised if there's leakage though. > >> Currently we don't save previous versions of methods that are not >> running. We didn't before permgen elimination either. If GC didn't >> find the EMCP method, we would remove the entry. > > Not quite true for the pre-PermGen-Removal (PGR) world. We used to > save weak refs for all of the EMCP methods in the previous version > info. As the EMCP methods became collectible we removed them from > the previous version info. This means if GC could find the EMCP > method anywhere (stack, jmethodID, JNI handle, etc), then it stayed > alive. This means that even if no thread was currently executing > an EMCP method, an in-progress call to that method could still > complete and poof now we have the EMCP method back on a stack > somewhere... > True. The case I was worried about is if an EMCP method is made obsolete by redefinition but we don't have a pointer to it anywhere because it's not running or referenced, so we can't mark it obsolete. In this case I guess you can't call the isMethodObsolete() function on it. I think I went down a rabbit hole. Thanks, Coleen > Dan > > >> >> Thanks, >> Coleen >> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> line 3527: // clear out any matching EMCP method entries the >>>>> hard way. >>>>> Perhaps "mark" instead of "clear out"? >>>>> >>>>> old line 3659: if (!method->is_obsolete() && >>>>> new line 3546: if (method->is_emcp() && >>>>> The old code is correct. The old code won't remark a >>>>> method that >>>>> was already made obsolete so there won't be more than one >>>>> trace >>>>> message for that operation. >>>>> >>>>> line 3581: // stack, and set emcp methods on the stack. >>>>> In comments 'emcp' should be 'EMCP'. We did not do that in >>>>> the >>>>> code because of HotSpot's variable name style. >>>>> >>>>> Also, set what on EMCP methods on the stack? >>>>> >>>>> line 3591: ... If emcp method from >>>>> line 3592: // a previous redefinition may be made obsolete by >>>>> this redefinition. >>>>> Having trouble parsing this comment. >>>>> >>>>> src/share/vm/oops/method.hpp >>>>> line 693: // emcp methods (equivalent method except constant >>>>> pool is different) >>>>> line 694: // that are old but not obsolete or deleted. >>>>> Perhaps: >>>>> >>>>> // EMCP methods are old but not obsolete or deleted. >>>>> Equivalent >>>>> // Modulo Constant Pool means the method is equivalent except >>>>> // the constant pool and instructions that access the >>>>> constant >>>>> // pool might be different. >>>>> >>>>> src/share/vm/prims/jvmtiImpl.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/code/nmethod.cpp >>>>> So in the original code f(_method) was being called two extra >>>>> times? (once in the while-loop and once at the end) So I'm >>>>> guessing that f(_method) is properly called when the rest of >>>>> the metadata is handled in the nmethod (line 2085)? >>>>> >>>>> src/share/vm/memory/universe.cpp >>>>> No comments (resisting 'The Walking Dead' ref...) >>>>> >>>>> test/runtime/RedefineTests/RedefineFinalizer.java >>>>> No comments. >>>>> >>>>> test/runtime/RedefineTests/RedefineRunningMethods.java >>>>> line 44: " while (!stop) { count2++; }" + >>>>> line 53: while (!stop) { count1++; } >>>>> line 56: while (!stop) { count2++; } >>>>> >>>>> These may not behave well on OSes with bad threading >>>>> models. You might want to add a helper function that >>>>> sleeps for 10ms and have each of these loops call it >>>>> so the test more well behaved. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Aug 21 01:26:24 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 21:26:24 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F52521.1080309@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> Message-ID: <53F54AC0.7010007@oracle.com> On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote: > On 8/20/14 2:01 PM, Coleen Phillimore wrote: >> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>> If an EMCP method is not running, should we save it on a previous >>>> version list anyway so that we can make it obsolete if it's >>>> redefined and made obsolete? >>> >>> I hope, Dan will catch me if I'm wrong... >>> >>> I think, we should not. >>> An EMCP method can not be made obsolete if it is not running. >>> >> >> >> It should be this way otherwise we'd have to hang onto things forever. > > An EMCP method should only be made obsolete if a RedefineClasses() or > RetransformClasses() operation made it so. We should not be leveraging > off the obsolete-ness attribute to solve a life-cycle problem. Yes, this was my error in the change. This is why I made things obsolete if they were not running. I think I can't reuse this flag. My latest changes add a new explicit flag (which we have space for in Method*). > > In the pre-PGR world, we could trust GC to make a completely unused > EMCP method collectible and eventually our weak reference would go > away. Just because an EMCP method is not on a stack does not mean > that it is not used so we need a different way to determine whether > it is OK to no longer track an EMCP method. Our on_stack marking is supposed to look at all the places where GC used to look so I think we can use on_stack to track the lifecycle of EMCP methods. If the EMCP method is somewhere, we will find it! I'm running tests on the latest change, but am also waiting for confirmation from Roland because we were only cleaning out MethodData for EMCP methods and not for running obsolete methods and I think we need to do that for obsolete methods also, which my change does now. I think it was a bug. Thanks Dan for remembering all of this for me! Coleen > > >> >>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>> switch to updated webrev after it is ready. >> >> Yes, this is a good idea. I figured out why I made emcp methods >> obsolete, and I'm fixing that as well as Dan's comments. Thanks! > > Cool! I'm looking forward to the next review. > > Dan > > >> >> Coleen >> >>> >>> Thanks, >>> Serguei >> > From staffan.larsen at oracle.com Thu Aug 21 05:57:23 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 21 Aug 2014 07:57:23 +0200 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F4F8A0.9050308@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> <53F3AFAC.7080103@oracle.com> <53F4F8A0.9050308@oracle.com> Message-ID: <8A7E9581-2A3C-402F-851D-62A85F12AC45@oracle.com> Looks good to me. Let?s see what it uncovers. /Staffan On 20 aug 2014, at 21:36, Ivan Gerasimov wrote: > Hello everyone! > > Here's the third version of the webrev: > http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ > > The control build of the previous one was causing a lot of test failures. > This one seems to be innocent enough: no new test failures so far. > > Additionally, this version keeps the timing around the thread exit close to original, which might be important if we deal with a race. > > Sincerely yours, > Ivan > From serguei.spitsyn at oracle.com Thu Aug 21 07:46:58 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Aug 2014 00:46:58 -0700 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <8A7E9581-2A3C-402F-851D-62A85F12AC45@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> <53F3AFAC.7080103@oracle.com> <53F4F8A0.9050308@oracle.com> <8A7E9581-2A3C-402F-851D-62A85F12AC45@oracle.com> Message-ID: <53F5A3F2.3080903@oracle.com> +1 On 8/20/14 10:57 PM, Staffan Larsen wrote: > Looks good to me. Let?s see what it uncovers. > > /Staffan > > On 20 aug 2014, at 21:36, Ivan Gerasimov wrote: > >> Hello everyone! >> >> Here's the third version of the webrev: >> http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ >> >> The control build of the previous one was causing a lot of test failures. >> This one seems to be innocent enough: no new test failures so far. >> >> Additionally, this version keeps the timing around the thread exit close to original, which might be important if we deal with a race. >> >> Sincerely yours, >> Ivan >> From staffan.larsen at oracle.com Thu Aug 21 10:15:44 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 21 Aug 2014 12:15:44 +0200 Subject: RFR: 8055677 java/lang/instrument/RedefineBigClass.sh RetransformBigClass.sh start failing after JDK-8055012 Message-ID: <7086A4C6-1643-4BA3-876D-F7767275AF6A@oracle.com> This failure happens because the test look for the string ?Exception? in the output of the program to signal a failure. With the improved version of NMT, the output from NMT sometimes includes this string in a stack trace. The solution I?ve implemented is to redirect the NMT output to a file instead of having it on stdout. bug: https://bugs.openjdk.java.net/browse/JDK-8055677 webrev: http://cr.openjdk.java.net/~sla/8055677/webrev.00/ Thanks, /Staffan From markus.gronlund at oracle.com Thu Aug 21 10:30:54 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Thu, 21 Aug 2014 03:30:54 -0700 (PDT) Subject: RFR: 8055677 java/lang/instrument/RedefineBigClass.sh RetransformBigClass.sh start failing after JDK-8055012 In-Reply-To: <7086A4C6-1643-4BA3-876D-F7767275AF6A@oracle.com> References: <7086A4C6-1643-4BA3-876D-F7767275AF6A@oracle.com> Message-ID: <891368a9-ee0a-4bff-a263-d8f7101352cc@default> Looks good. /Markus -----Original Message----- From: Staffan Larsen Sent: den 21 augusti 2014 12:16 To: serviceability-dev at openjdk.java.net Subject: RFR: 8055677 java/lang/instrument/RedefineBigClass.sh RetransformBigClass.sh start failing after JDK-8055012 This failure happens because the test look for the string "Exception" in the output of the program to signal a failure. With the improved version of NMT, the output from NMT sometimes includes this string in a stack trace. The solution I've implemented is to redirect the NMT output to a file instead of having it on stdout. bug: https://bugs.openjdk.java.net/browse/JDK-8055677 webrev: http://cr.openjdk.java.net/~sla/8055677/webrev.00/ Thanks, /Staffan From david.holmes at oracle.com Thu Aug 21 10:28:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Aug 2014 20:28:42 +1000 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F4F8A0.9050308@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> <53F3AFAC.7080103@oracle.com> <53F4F8A0.9050308@oracle.com> Message-ID: <53F5C9DA.90008@oracle.com> Third time lucky :) Let's give it a go. David On 21/08/2014 5:36 AM, Ivan Gerasimov wrote: > Hello everyone! > > Here's the third version of the webrev: > http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ > > The control build of the previous one was causing a lot of test failures. > This one seems to be innocent enough: no new test failures so far. > > Additionally, this version keeps the timing around the thread exit close > to original, which might be important if we deal with a race. > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Thu Aug 21 10:57:21 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 21 Aug 2014 14:57:21 +0400 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F5A3F2.3080903@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> <53F3AFAC.7080103@oracle.com> <53F4F8A0.9050308@oracle.com> <8A7E9581-2A3C-402F-851D-62A85F12AC45@oracle.com> <53F5A3F2.3080903@oracle.com> Message-ID: <53F5D091.4060008@oracle.com> Thanks for review! Could someone please sponsor it for me? I'm not sure what the correct repository is. Sincerely yours, Ivan On 21.08.2014 11:46, serguei.spitsyn at oracle.com wrote: > +1 > > On 8/20/14 10:57 PM, Staffan Larsen wrote: >> Looks good to me. Let?s see what it uncovers. >> >> /Staffan >> >> On 20 aug 2014, at 21:36, Ivan Gerasimov >> wrote: >> >>> Hello everyone! >>> >>> Here's the third version of the webrev: >>> http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ >>> >>> The control build of the previous one was causing a lot of test >>> failures. >>> This one seems to be innocent enough: no new test failures so far. >>> >>> Additionally, this version keeps the timing around the thread exit >>> close to original, which might be important if we deal with a race. >>> >>> Sincerely yours, >>> Ivan >>> > > > From christian.tornqvist at oracle.com Thu Aug 21 11:10:53 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 21 Aug 2014 07:10:53 -0400 Subject: 8055677 java/lang/instrument/RedefineBigClass.sh RetransformBigClass.sh start failing after JDK-8055012 In-Reply-To: <7086A4C6-1643-4BA3-876D-F7767275AF6A@oracle.com> References: <7086A4C6-1643-4BA3-876D-F7767275AF6A@oracle.com> Message-ID: <092901cfbd30$9355d730$ba018590$@oracle.com> Hi Staffan, This looks good, thanks for fixing this. Thanks, Christian -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Staffan Larsen Sent: Thursday, August 21, 2014 6:16 AM To: serviceability-dev at openjdk.java.net Subject: RFR: 8055677 java/lang/instrument/RedefineBigClass.sh RetransformBigClass.sh start failing after JDK-8055012 This failure happens because the test look for the string "Exception" in the output of the program to signal a failure. With the improved version of NMT, the output from NMT sometimes includes this string in a stack trace. The solution I've implemented is to redirect the NMT output to a file instead of having it on stdout. bug: https://bugs.openjdk.java.net/browse/JDK-8055677 webrev: http://cr.openjdk.java.net/~sla/8055677/webrev.00/ Thanks, /Staffan From staffan.larsen at oracle.com Thu Aug 21 11:30:30 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 21 Aug 2014 13:30:30 +0200 Subject: 8055677 java/lang/instrument/RedefineBigClass.sh RetransformBigClass.sh start failing after JDK-8055012 In-Reply-To: <092901cfbd30$9355d730$ba018590$@oracle.com> References: <7086A4C6-1643-4BA3-876D-F7767275AF6A@oracle.com> <092901cfbd30$9355d730$ba018590$@oracle.com> Message-ID: Markus, Christian: Thanks! On 21 aug 2014, at 13:10, Christian Tornqvist wrote: > Hi Staffan, > > This looks good, thanks for fixing this. > > Thanks, > Christian > > -----Original Message----- > From: serviceability-dev > [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Staffan > Larsen > Sent: Thursday, August 21, 2014 6:16 AM > To: serviceability-dev at openjdk.java.net > Subject: RFR: 8055677 java/lang/instrument/RedefineBigClass.sh > RetransformBigClass.sh start failing after JDK-8055012 > > This failure happens because the test look for the string "Exception" in the > output of the program to signal a failure. With the improved version of NMT, > the output from NMT sometimes includes this string in a stack trace. The > solution I've implemented is to redirect the NMT output to a file instead of > having it on stdout. > > bug: https://bugs.openjdk.java.net/browse/JDK-8055677 > webrev: http://cr.openjdk.java.net/~sla/8055677/webrev.00/ > > Thanks, > /Staffan > From jaroslav.bachorik at oracle.com Thu Aug 21 12:44:48 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 21 Aug 2014 14:44:48 +0200 Subject: RFR 8040692: [TESTBUG] sun/management/jmxremote/bootstrap/JvmstatCountersTest.java requires -XX:+UsePerfData option to pass on embedded platforms Message-ID: <53F5E9C0.6050906@oracle.com> Please, review this simple fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8040692 Webrev: http://cr.openjdk.java.net/~jbachorik/8040692/webrev.00 On embedded platforms it is necessary to provide "-XX:+UsePerfData" flag in order to make the performance counters accessible. This fix does this for the tests which need to access the performance counters. Thanks, -JB- From staffan.larsen at oracle.com Thu Aug 21 12:52:18 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 21 Aug 2014 14:52:18 +0200 Subject: jmx-dev RFR 8040692: [TESTBUG] sun/management/jmxremote/bootstrap/JvmstatCountersTest.java requires -XX:+UsePerfData option to pass on embedded platforms In-Reply-To: <53F5E9C0.6050906@oracle.com> References: <53F5E9C0.6050906@oracle.com> Message-ID: <62C456B6-2045-4B2F-9DDD-462C3DCD8D24@oracle.com> Looks good, except I don?t think you wanted to add the test/sources.list file? /Staffan On 21 aug 2014, at 14:44, Jaroslav Bachorik wrote: > Please, review this simple fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8040692 > Webrev: http://cr.openjdk.java.net/~jbachorik/8040692/webrev.00 > > On embedded platforms it is necessary to provide "-XX:+UsePerfData" flag in order to make the performance counters accessible. This fix does this for the tests which need to access the performance counters. > > Thanks, > > -JB- From dmitry.samersoff at oracle.com Thu Aug 21 12:56:00 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 21 Aug 2014 16:56:00 +0400 Subject: RFR(S): JDK-8054194 jstack crash: assert(handle != NULL) failed: JNI handle should not be null Message-ID: <53F5EC60.9030800@oracle.com> Hi Everyone, Please review small agent changes: http://cr.openjdk.java.net/~dsamersoff/JDK-8054194/webrev.01/ Under windows, If jstack attempts to attach to java process that is being killed by someone else, GetStaticObjectField might return NULL. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Aug 21 12:58:21 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 21 Aug 2014 14:58:21 +0200 Subject: jmx-dev RFR 8040692: [TESTBUG] sun/management/jmxremote/bootstrap/JvmstatCountersTest.java requires -XX:+UsePerfData option to pass on embedded platforms In-Reply-To: <62C456B6-2045-4B2F-9DDD-462C3DCD8D24@oracle.com> References: <53F5E9C0.6050906@oracle.com> <62C456B6-2045-4B2F-9DDD-462C3DCD8D24@oracle.com> Message-ID: <53F5ECED.2000005@oracle.com> On 08/21/2014 02:52 PM, Staffan Larsen wrote: > Looks good, except I don?t think you wanted to add the test/sources.list file? Nope. I've just realized that my review script includes all the applied MQ patches instead of only the last one. -JB- > > /Staffan > > On 21 aug 2014, at 14:44, Jaroslav Bachorik wrote: > >> Please, review this simple fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8040692 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8040692/webrev.00 >> >> On embedded platforms it is necessary to provide "-XX:+UsePerfData" flag in order to make the performance counters accessible. This fix does this for the tests which need to access the performance counters. >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Thu Aug 21 13:21:36 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 21 Aug 2014 15:21:36 +0200 Subject: jmx-dev RFR 8040692: [TESTBUG] sun/management/jmxremote/bootstrap/JvmstatCountersTest.java requires -XX:+UsePerfData option to pass on embedded platforms In-Reply-To: <62C456B6-2045-4B2F-9DDD-462C3DCD8D24@oracle.com> References: <53F5E9C0.6050906@oracle.com> <62C456B6-2045-4B2F-9DDD-462C3DCD8D24@oracle.com> Message-ID: <53F5F260.2030000@oracle.com> On 08/21/2014 02:52 PM, Staffan Larsen wrote: > Looks good, except I don?t think you wanted to add the test/sources.list file? Fixed the webrev - http://cr.openjdk.java.net/~jbachorik/8040692/webrev.01 - not to include test/sources.list file. Thanks for the review. -JB- > > /Staffan > > On 21 aug 2014, at 14:44, Jaroslav Bachorik wrote: > >> Please, review this simple fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8040692 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8040692/webrev.00 >> >> On embedded platforms it is necessary to provide "-XX:+UsePerfData" flag in order to make the performance counters accessible. This fix does this for the tests which need to access the performance counters. >> >> Thanks, >> >> -JB- > From daniel.daugherty at oracle.com Thu Aug 21 14:17:18 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Aug 2014 08:17:18 -0600 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F4F8A0.9050308@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> <53F3AFAC.7080103@oracle.com> <53F4F8A0.9050308@oracle.com> Message-ID: <53F5FF6E.3060308@oracle.com> On 8/20/14 1:36 PM, Ivan Gerasimov wrote: > Hello everyone! > > Here's the third version of the webrev: > http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ src/os/windows/vm/os_windows.cpp line 444: res = java_lang_Thread::is_daemon(java_thread->threadObj()) line 453: thread->run(); Querying the 'is_daemon' flag before the thread is run won't catch all cases of daemon threads, but I think it is good enough for our purposes. src/share/vm/runtime/java.cpp No comments. Thumbs up. > The control build of the previous one was causing a lot of test failures. > This one seems to be innocent enough: no new test failures so far. So the previous version was querying everything after the thread had finished with thread->run(). I'll take it the data we were querying was no longer stable at that point? > Additionally, this version keeps the timing around the thread exit > close to original, which might be important if we deal with a race. Agreed. Dan > > Sincerely yours, > Ivan > From daniel.daugherty at oracle.com Thu Aug 21 14:21:04 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Aug 2014 08:21:04 -0600 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F5D091.4060008@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> <53F3AFAC.7080103@oracle.com> <53F4F8A0.9050308@oracle.com> <8A7E9581-2A3C-402F-851D-62A85F12AC45@oracle.com> <53F5A3F2.3080903@oracle.com> <53F5D091.4060008@oracle.com> Message-ID: <53F60050.2020309@oracle.com> The correct repository would be RT_Baseline. What testing has been run on your fix? I know you've done a control build so that covers JPRT testing. I'll prep a repo for sponsoring the push, but I'll hold off pushing until I know what testing has been done. Dan On 8/21/14 4:57 AM, Ivan Gerasimov wrote: > Thanks for review! > > Could someone please sponsor it for me? > I'm not sure what the correct repository is. > > Sincerely yours, > Ivan > > On 21.08.2014 11:46, serguei.spitsyn at oracle.com wrote: >> +1 >> >> On 8/20/14 10:57 PM, Staffan Larsen wrote: >>> Looks good to me. Let?s see what it uncovers. >>> >>> /Staffan >>> >>> On 20 aug 2014, at 21:36, Ivan Gerasimov >>> wrote: >>> >>>> Hello everyone! >>>> >>>> Here's the third version of the webrev: >>>> http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ >>>> >>>> The control build of the previous one was causing a lot of test >>>> failures. >>>> This one seems to be innocent enough: no new test failures so far. >>>> >>>> Additionally, this version keeps the timing around the thread exit >>>> close to original, which might be important if we deal with a race. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >> >> >> > From daniel.daugherty at oracle.com Thu Aug 21 15:05:22 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Aug 2014 09:05:22 -0600 Subject: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254 In-Reply-To: <53F60050.2020309@oracle.com> References: <53F26DFA.9010707@oracle.com> <53F2967E.6040105@oracle.com> <53F2B985.2070909@oracle.com> <53F349B2.7010903@oracle.com> <53F3AFAC.7080103@oracle.com> <53F4F8A0.9050308@oracle.com> <8A7E9581-2A3C-402F-851D-62A85F12AC45@oracle.com> <53F5A3F2.3080903@oracle.com> <53F5D091.4060008@oracle.com> <53F60050.2020309@oracle.com> Message-ID: <53F60AB2.90809@oracle.com> Here's the commit message: $ cat commit.txt 8055338: (process) Add instrumentation to help diagnose JDK-6573254 Reviewed-by: dcubed, ohair, iklam, dholmes, sspitsyn, sla I will commit the changeset as 'igerasim'. Didn't think a summary line was needed. Dan On 8/21/14 8:21 AM, Daniel D. Daugherty wrote: > The correct repository would be RT_Baseline. What testing has been > run on your fix? I know you've done a control build so that covers > JPRT testing. > > I'll prep a repo for sponsoring the push, but I'll hold off pushing > until I know what testing has been done. > > Dan > > > On 8/21/14 4:57 AM, Ivan Gerasimov wrote: >> Thanks for review! >> >> Could someone please sponsor it for me? >> I'm not sure what the correct repository is. >> >> Sincerely yours, >> Ivan >> >> On 21.08.2014 11:46, serguei.spitsyn at oracle.com wrote: >>> +1 >>> >>> On 8/20/14 10:57 PM, Staffan Larsen wrote: >>>> Looks good to me. Let?s see what it uncovers. >>>> >>>> /Staffan >>>> >>>> On 20 aug 2014, at 21:36, Ivan Gerasimov >>>> wrote: >>>> >>>>> Hello everyone! >>>>> >>>>> Here's the third version of the webrev: >>>>> http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ >>>>> >>>>> The control build of the previous one was causing a lot of test >>>>> failures. >>>>> This one seems to be innocent enough: no new test failures so far. >>>>> >>>>> Additionally, this version keeps the timing around the thread exit >>>>> close to original, which might be important if we deal with a race. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>> >>> >>> >> > > From staffan.larsen at oracle.com Mon Aug 25 10:58:19 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 12:58:19 +0200 Subject: RFR(S): JDK-8054194 jstack crash: assert(handle != NULL) failed: JNI handle should not be null In-Reply-To: <53F5EC60.9030800@oracle.com> References: <53F5EC60.9030800@oracle.com> Message-ID: <56DA62BE-E0EF-4C17-AE77-0D67AB1297E4@oracle.com> Dmitry, Your changes look good (except missing spaces after commas). But what I do not understand is how this relates to the bug. The code in setImageAndSymbolPath() is not looking at the remote process, it?s just setting up data in the jstack process. How does killing the remote process affect this code? What am I missing? /Staffan On 21 aug 2014, at 14:56, Dmitry Samersoff wrote: > Hi Everyone, > > Please review small agent changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8054194/webrev.01/ > > Under windows, If jstack attempts to attach to java process that is > being killed by someone else, GetStaticObjectField might return NULL. > > -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 staffan.larsen at oracle.com Mon Aug 25 11:01:13 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 13:01:13 +0200 Subject: RFR(S): JDK-8029172: warnings from b117 for hotspot.agent.src.os.linux: JNI exception pending In-Reply-To: <53E73C47.6020701@oracle.com> References: <53E73C47.6020701@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 10 aug 2014, at 11:32, Dmitry Samersoff wrote: > Please review: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8029172/webrev.01/ > > Added more exception checks to agent/src/os/linux/LinuxDebuggerLocal.c > > -- > 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 staffan.larsen at oracle.com Mon Aug 25 11:26:36 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 13:26:36 +0200 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53F4C4DC.9090903@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> Message-ID: <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> Dmitry, One problem with this fix is that debugInit_exit() is used from many places in the JDWP code. For some of these I think it still does make sense to receive a core dump for analysis. I agree that when parsing options, we do not need a core dump. /Staffan On 20 aug 2014, at 17:55, Dmitry Samersoff wrote: > Serguei, > > After some additional testing I changed the fix a bit. Please take a > look at new version. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ > > New version reports JVMTI error to stderr. > > Also jniFatalError is not referenced any more so I remove it. > > -Dmitry > > > > On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >> Ok. >> >> Thank you for the explanation! >> Serguei >> >> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> 1. Historically JDI test-suite had no tests for failed transport >>> initialization behavior and invalid parameters handling. >>> >>> 2. As a part of JDWP hardening work I added couple of such tests to >>> OptionTest.java - these tests pass invalid parameters to dt_socket >>> transport to make sure that transport doesn't crash (one such crash was >>> discovered and fixed) but just return non-zero exit code to upper level. >>> >>> 3. After fix for JDK-6694099 any non-zero exit code from transport cause >>> VM to coredump. Dumping multiple cores on busy machine takes a time so >>> harness kills the test by timeout. >>> >>> We can just increase timeout for this test but I don't think it's a good >>> idea to dump core when invalid parameters passed to transport. >>> >>> So there is the fix. >>> >>> 4. After the fix tests for negative parameters will return non-zero exit >>> code as expected but will not dump the core. >>> >>> -Dmitry >>> >>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>> Hi Dmitry, >>>> >>>> The fix seems to be Ok. >>>> Just want to make it clear... >>>> This fix just changes the bug pattern. >>>> It a case of incorrect transport parameters the test is still going to >>>> fail but without crash, right? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>> Hi Everybody, >>>>> >>>>> Please review the fix: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>> >>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>> parameters) and jniFatalError call os::abort(). Therefor all transport >>>>> initialization errors cause vm to coredump. >>>>> >>>>> I see no reason for debugInit_exit to call jniFatalError so remove this >>>>> code. >>>>> >>>>> -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 dmitry.samersoff at oracle.com Mon Aug 25 11:33:38 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Aug 2014 15:33:38 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> Message-ID: <53FB1F12.7090407@oracle.com> Staffan, On 2014-08-25 15:26, Staffan Larsen wrote: > Dmitry, > > One problem with this fix is that debugInit_exit() is used from many > places in the JDWP code. For some of these I think it still does make > sense to receive a core dump for analysis. I agree that when parsing > options, we do not need a core dump. jdwp has explicit option to request a coredump at debugInit_exit(). Is it enough or I should create a more sophisticated fix ? Actually, I don't think that coredump on every call to jni_FatalError() (see jni.cpp:726) is necessary but this hotspot code is here for 6 years and changing it probably out of scope of this fix. -Dmitry > > /Staffan > > > On 20 aug 2014, at 17:55, Dmitry Samersoff > wrote: > >> Serguei, >> >> After some additional testing I changed the fix a bit. Please take >> a look at new version. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >> >> New version reports JVMTI error to stderr. >> >> Also jniFatalError is not referenced any more so I remove it. >> >> -Dmitry >> >> >> >> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>> Ok. >>> >>> Thank you for the explanation! Serguei >>> >>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> 1. Historically JDI test-suite had no tests for failed >>>> transport initialization behavior and invalid parameters >>>> handling. >>>> >>>> 2. As a part of JDWP hardening work I added couple of such >>>> tests to OptionTest.java - these tests pass invalid parameters >>>> to dt_socket transport to make sure that transport doesn't >>>> crash (one such crash was discovered and fixed) but just return >>>> non-zero exit code to upper level. >>>> >>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>> transport cause VM to coredump. Dumping multiple cores on busy >>>> machine takes a time so harness kills the test by timeout. >>>> >>>> We can just increase timeout for this test but I don't think >>>> it's a good idea to dump core when invalid parameters passed to >>>> transport. >>>> >>>> So there is the fix. >>>> >>>> 4. After the fix tests for negative parameters will return >>>> non-zero exit code as expected but will not dump the core. >>>> >>>> -Dmitry >>>> >>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dmitry, >>>>> >>>>> The fix seems to be Ok. Just want to make it clear... This >>>>> fix just changes the bug pattern. It a case of incorrect >>>>> transport parameters the test is still going to fail but >>>>> without crash, right? >>>>> >>>>> Thanks, Serguei >>>>> >>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>> Hi Everybody, >>>>>> >>>>>> Please review the fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>> >>>>>> >>>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>> all transport initialization errors cause vm to coredump. >>>>>> >>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>> remove this code. >>>>>> >>>>>> -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. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Mon Aug 25 11:36:44 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 25 Aug 2014 04:36:44 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> Message-ID: <53FB1FCC.9030307@oracle.com> This is a valid concern. Sorry, I did not catch it. Thanks, Serguei On 8/25/14 4:26 AM, Staffan Larsen wrote: > Dmitry, > > One problem with this fix is that debugInit_exit() is used from many places in the JDWP code. For some of these I think it still does make sense to receive a core dump for analysis. I agree that when parsing options, we do not need a core dump. > > /Staffan > > > On 20 aug 2014, at 17:55, Dmitry Samersoff wrote: > >> Serguei, >> >> After some additional testing I changed the fix a bit. Please take a >> look at new version. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >> >> New version reports JVMTI error to stderr. >> >> Also jniFatalError is not referenced any more so I remove it. >> >> -Dmitry >> >> >> >> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>> Ok. >>> >>> Thank you for the explanation! >>> Serguei >>> >>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> 1. Historically JDI test-suite had no tests for failed transport >>>> initialization behavior and invalid parameters handling. >>>> >>>> 2. As a part of JDWP hardening work I added couple of such tests to >>>> OptionTest.java - these tests pass invalid parameters to dt_socket >>>> transport to make sure that transport doesn't crash (one such crash was >>>> discovered and fixed) but just return non-zero exit code to upper level. >>>> >>>> 3. After fix for JDK-6694099 any non-zero exit code from transport cause >>>> VM to coredump. Dumping multiple cores on busy machine takes a time so >>>> harness kills the test by timeout. >>>> >>>> We can just increase timeout for this test but I don't think it's a good >>>> idea to dump core when invalid parameters passed to transport. >>>> >>>> So there is the fix. >>>> >>>> 4. After the fix tests for negative parameters will return non-zero exit >>>> code as expected but will not dump the core. >>>> >>>> -Dmitry >>>> >>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dmitry, >>>>> >>>>> The fix seems to be Ok. >>>>> Just want to make it clear... >>>>> This fix just changes the bug pattern. >>>>> It a case of incorrect transport parameters the test is still going to >>>>> fail but without crash, right? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>> Hi Everybody, >>>>>> >>>>>> Please review the fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>> >>>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>> parameters) and jniFatalError call os::abort(). Therefor all transport >>>>>> initialization errors cause vm to coredump. >>>>>> >>>>>> I see no reason for debugInit_exit to call jniFatalError so remove this >>>>>> code. >>>>>> >>>>>> -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 staffan.larsen at oracle.com Mon Aug 25 11:53:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 13:53:57 +0200 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FB1F12.7090407@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> Message-ID: <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> On 25 aug 2014, at 13:33, Dmitry Samersoff wrote: > Staffan, > > On 2014-08-25 15:26, Staffan Larsen wrote: >> Dmitry, >> >> One problem with this fix is that debugInit_exit() is used from many >> places in the JDWP code. For some of these I think it still does make >> sense to receive a core dump for analysis. I agree that when parsing >> options, we do not need a core dump. > > jdwp has explicit option to request a coredump at debugInit_exit(). > > Is it enough or I should create a more sophisticated fix ? I don?t think that is enough. Often a problem will happen and will not be reproducible. Maybe this code: if ((arg.error != JDWP_ERROR(NONE)) && (arg.startCount == 0) && initOnStartup) { EXIT_ERROR(map2jvmtiError(arg.error), "No transports initialized"); } can use some variant of EXIT_ERROR that does not call fatalError() ? /Staffan > > Actually, I don't think that coredump on every call to jni_FatalError() > (see jni.cpp:726) is necessary but this hotspot code is here for 6 years > and changing it probably out of scope of this fix. > > -Dmitry > > >> >> /Staffan >> >> >> On 20 aug 2014, at 17:55, Dmitry Samersoff >> wrote: >> >>> Serguei, >>> >>> After some additional testing I changed the fix a bit. Please take >>> a look at new version. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>> >>> New version reports JVMTI error to stderr. >>> >>> Also jniFatalError is not referenced any more so I remove it. >>> >>> -Dmitry >>> >>> >>> >>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>> Ok. >>>> >>>> Thank you for the explanation! Serguei >>>> >>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> 1. Historically JDI test-suite had no tests for failed >>>>> transport initialization behavior and invalid parameters >>>>> handling. >>>>> >>>>> 2. As a part of JDWP hardening work I added couple of such >>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>> to dt_socket transport to make sure that transport doesn't >>>>> crash (one such crash was discovered and fixed) but just return >>>>> non-zero exit code to upper level. >>>>> >>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>> machine takes a time so harness kills the test by timeout. >>>>> >>>>> We can just increase timeout for this test but I don't think >>>>> it's a good idea to dump core when invalid parameters passed to >>>>> transport. >>>>> >>>>> So there is the fix. >>>>> >>>>> 4. After the fix tests for negative parameters will return >>>>> non-zero exit code as expected but will not dump the core. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>> transport parameters the test is still going to fail but >>>>>> without crash, right? >>>>>> >>>>>> Thanks, Serguei >>>>>> >>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>> Hi Everybody, >>>>>>> >>>>>>> Please review the fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>> >>>>>>> >>>>>>> > JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>> all transport initialization errors cause vm to coredump. >>>>>>> >>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>> remove this code. >>>>>>> >>>>>>> -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. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Mon Aug 25 11:56:44 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Aug 2014 15:56:44 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> Message-ID: <53FB247C.7080800@oracle.com> Staffan, OK. Will create better fix. -Dmitry On 2014-08-25 15:53, Staffan Larsen wrote: > > On 25 aug 2014, at 13:33, Dmitry Samersoff > wrote: > >> Staffan, >> >> On 2014-08-25 15:26, Staffan Larsen wrote: >>> Dmitry, >>> >>> One problem with this fix is that debugInit_exit() is used from many >>> places in the JDWP code. For some of these I think it still does make >>> sense to receive a core dump for analysis. I agree that when parsing >>> options, we do not need a core dump. >> >> jdwp has explicit option to request a coredump at debugInit_exit(). >> >> Is it enough or I should create a more sophisticated fix ? > > I don?t think that is enough. Often a problem will happen and will not > be reproducible. > > Maybe this code: > > if ((arg.error != JDWP_ERROR(NONE)) && > (arg.startCount == 0) && > initOnStartup) { > EXIT_ERROR(map2jvmtiError(arg.error), "No transports initialized"); > } > > can use some variant of EXIT_ERROR that does not call fatalError() ? > > /Staffan > >> >> Actually, I don't think that coredump on every call to jni_FatalError() >> (see jni.cpp:726) is necessary but this hotspot code is here for 6 years >> and changing it probably out of scope of this fix. >> >> -Dmitry >> >> >>> >>> /Staffan >>> >>> >>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>> > wrote: >>> >>>> Serguei, >>>> >>>> After some additional testing I changed the fix a bit. Please take >>>> a look at new version. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>> >>>> New version reports JVMTI error to stderr. >>>> >>>> Also jniFatalError is not referenced any more so I remove it. >>>> >>>> -Dmitry >>>> >>>> >>>> >>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>> Ok. >>>>> >>>>> Thank you for the explanation! Serguei >>>>> >>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>> transport initialization behavior and invalid parameters >>>>>> handling. >>>>>> >>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>> to dt_socket transport to make sure that transport doesn't >>>>>> crash (one such crash was discovered and fixed) but just return >>>>>> non-zero exit code to upper level. >>>>>> >>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>> machine takes a time so harness kills the test by timeout. >>>>>> >>>>>> We can just increase timeout for this test but I don't think >>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>> transport. >>>>>> >>>>>> So there is the fix. >>>>>> >>>>>> 4. After the fix tests for negative parameters will return >>>>>> non-zero exit code as expected but will not dump the core. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>> transport parameters the test is still going to fail but >>>>>>> without crash, right? >>>>>>> >>>>>>> Thanks, Serguei >>>>>>> >>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>> Hi Everybody, >>>>>>>> >>>>>>>> Please review the fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>> >>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>> remove this code. >>>>>>>> >>>>>>>> -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. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- 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 staffan.larsen at oracle.com Mon Aug 25 13:35:48 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 15:35:48 +0200 Subject: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK Message-ID: <4816BD14-39A1-4497-8A1F-3D1A1E5A79AE@oracle.com> Please review the following change to remove hprof as part of the demo package. Instead, the source code has been moved to the jdk.hprof.agent module. bug: https://bugs.openjdk.java.net/browse/JDK-8043936 webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/ Thanks, /Staffan From staffan.larsen at oracle.com Mon Aug 25 13:48:04 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 15:48:04 +0200 Subject: RFR: JDK-8043981 Remove the JPDA demo Message-ID: <05E135CB-41ED-4522-8CF1-C58DEAC67608@oracle.com> Please review this change to remove the legacy JPDA demos. These demos are quite dated at this point and the included instructions are incomplete. In addition the example/demo JPDA code does not fit well into the new modular structure because the source code is used for both jdb and for the demo. bug: https://bugs.openjdk.java.net/browse/JDK-8043981 webrev: http://cr.openjdk.java.net/~sla/8043981/webrev.00/ Thanks, /Staffan From Alan.Bateman at oracle.com Mon Aug 25 13:59:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Aug 2014 14:59:41 +0100 Subject: RFR: JDK-8043981 Remove the JPDA demo In-Reply-To: <05E135CB-41ED-4522-8CF1-C58DEAC67608@oracle.com> References: <05E135CB-41ED-4522-8CF1-C58DEAC67608@oracle.com> Message-ID: <53FB414D.30501@oracle.com> On 25/08/2014 14:48, Staffan Larsen wrote: > Please review this change to remove the legacy JPDA demos. These demos are quite dated at this point and the included instructions are incomplete. In addition the example/demo JPDA code does not fit well into the new modular structure because the source code is used for both jdb and for the demo. > > bug: https://bugs.openjdk.java.net/browse/JDK-8043981 > webrev: http://cr.openjdk.java.net/~sla/8043981/webrev.00/ > Good to see this going away, it also addresses one of Magnus' recent comments here about jpda/src.zip being built from sources in two locations (a consequence of the code being used for two things). The changes looks okay to me. A passing comment is that the move of Expr.jj is a reminder that we have generated code checked-in but that has been the case for a long time. -Alan. From staffan.larsen at oracle.com Mon Aug 25 14:06:44 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 16:06:44 +0200 Subject: RFR: JDK-8043981 Remove the JPDA demo In-Reply-To: <53FB414D.30501@oracle.com> References: <05E135CB-41ED-4522-8CF1-C58DEAC67608@oracle.com> <53FB414D.30501@oracle.com> Message-ID: <993EA264-FD6D-4670-B4F7-365C923629E9@oracle.com> On 25 aug 2014, at 15:59, Alan Bateman wrote: > On 25/08/2014 14:48, Staffan Larsen wrote: >> Please review this change to remove the legacy JPDA demos. These demos are quite dated at this point and the included instructions are incomplete. In addition the example/demo JPDA code does not fit well into the new modular structure because the source code is used for both jdb and for the demo. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8043981 >> webrev: http://cr.openjdk.java.net/~sla/8043981/webrev.00/ >> > Good to see this going away, it also addresses one of Magnus' recent comments here about jpda/src.zip being built from sources in two locations (a consequence of the code being used for two things). > > The changes looks okay to me. A passing comment is that the move of Expr.jj is a reminder that we have generated code checked-in but that has been the case for a long time. Thanks Alan. Yes, Ideally we should run JavaCC during the build on Expr.jj, but that adds a dependency and execution time for something that is very rarely changed. /Staffan > > -Alan. > From Alan.Bateman at oracle.com Mon Aug 25 14:15:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Aug 2014 15:15:34 +0100 Subject: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK In-Reply-To: <4816BD14-39A1-4497-8A1F-3D1A1E5A79AE@oracle.com> References: <4816BD14-39A1-4497-8A1F-3D1A1E5A79AE@oracle.com> Message-ID: <53FB4506.4040101@oracle.com> On 25/08/2014 14:35, Staffan Larsen wrote: > Please review the following change to remove hprof as part of the demo package. Instead, the source code has been moved to the jdk.hprof.agent module. > > bug: https://bugs.openjdk.java.net/browse/JDK-8043936 > webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/ > The move of the source code to native/libhprof looks good. Having the README and manual in the same directory is probably okay as it has always lived in the same directory as the source code. One thing is check is the contents of manual.html as there is at least one place where it references the directory demo/jvmti/hprof. I assume Erik or Magnus will check the make changes, I don't see any issues. -Alan From erik.joelsson at oracle.com Mon Aug 25 14:17:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Aug 2014 16:17:45 +0200 Subject: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK In-Reply-To: <4816BD14-39A1-4497-8A1F-3D1A1E5A79AE@oracle.com> References: <4816BD14-39A1-4497-8A1F-3D1A1E5A79AE@oracle.com> Message-ID: <53FB4589.70101@oracle.com> Build changes look ok to me. /Erik On 2014-08-25 15:35, Staffan Larsen wrote: > Please review the following change to remove hprof as part of the demo package. Instead, the source code has been moved to the jdk.hprof.agent module. > > bug: https://bugs.openjdk.java.net/browse/JDK-8043936 > webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/ > > Thanks, > /Staffan From staffan.larsen at oracle.com Mon Aug 25 14:38:19 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 16:38:19 +0200 Subject: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK In-Reply-To: <53FB4506.4040101@oracle.com> References: <4816BD14-39A1-4497-8A1F-3D1A1E5A79AE@oracle.com> <53FB4506.4040101@oracle.com> Message-ID: <99FA5E6E-73F2-4DA1-BCAC-8E744A61212C@oracle.com> On 25 aug 2014, at 16:15, Alan Bateman wrote: > On 25/08/2014 14:35, Staffan Larsen wrote: >> Please review the following change to remove hprof as part of the demo package. Instead, the source code has been moved to the jdk.hprof.agent module. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8043936 >> webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/ >> > The move of the source code to native/libhprof looks good. > > Having the README and manual in the same directory is probably okay as it has always lived in the same directory as the source code. One thing is check is the contents of manual.html as there is at least one place where it references the directory demo/jvmti/hprof. Good point. I have removed the section about Source Code in the latest version since all OpenJDK source code can be found at the same place: http://cr.openjdk.java.net/~sla/8043936/webrev.01/ I plan to push this version tomorrow unless someone shouts ;) Thanks, /Staffan > > I assume Erik or Magnus will check the make changes, I don't see any issues. > > -Alan > From Alan.Bateman at oracle.com Mon Aug 25 14:46:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Aug 2014 15:46:04 +0100 Subject: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK In-Reply-To: <99FA5E6E-73F2-4DA1-BCAC-8E744A61212C@oracle.com> References: <4816BD14-39A1-4497-8A1F-3D1A1E5A79AE@oracle.com> <53FB4506.4040101@oracle.com> <99FA5E6E-73F2-4DA1-BCAC-8E744A61212C@oracle.com> Message-ID: <53FB4C2C.6000004@oracle.com> On 25/08/2014 15:38, Staffan Larsen wrote: > On 25 aug 2014, at 16:15, Alan Bateman wrote: > >> : >> >> Having the README and manual in the same directory is probably okay as it has always lived in the same directory as the source code. One thing is check is the contents of manual.html as there is at least one place where it references the directory demo/jvmti/hprof. > Good point. I have removed the section about Source Code in the latest version since all OpenJDK source code can be found at the same place: > > http://cr.openjdk.java.net/~sla/8043936/webrev.01/ > > The update to the manual looks good. -Alan From staffan.friberg at oracle.com Mon Aug 25 16:28:34 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 25 Aug 2014 09:28:34 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects Message-ID: <53FB6432.1010501@oracle.com> Hi, Could I please get reviews for this RFE that adds a trace event for aging and promotion for young collections in G1, CMS and Parallel GC. It works similarly to allocation events, and generates the event on the slow path when either a direct copy occurs or a new PLAB is request. Since I'm adding an event I cc:ed the serviceability list in case anyone has any comments on the event and changes to trace.xml. RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 Bengt has been kind and agreed to both sponsor and host the the webrev. Thanks, Staffan From erik.gahlin at oracle.com Mon Aug 25 16:55:34 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 25 Aug 2014 18:55:34 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FB6432.1010501@oracle.com> References: <53FB6432.1010501@oracle.com> Message-ID: <53FB6A86.1080908@oracle.com> Did you manage to call the field "class"? It's a reserved word in C++, so we had to use "klass" in the past Descriptions with only one sentence shouldn't end with "." How is "Object Age" measured? As a user, I would expect the number to be in seconds/minutes/hours, but that is not the case. Perhaps an explanation in the description and/or a field name that better reflects what we really mean with age. Otherwise trace.xml looks good! Erik Staffan Friberg skrev 25/08/14 18:28: > Hi, > > Could I please get reviews for this RFE that adds a trace event for > aging and promotion for young collections in G1, CMS and Parallel GC. > It works similarly to allocation events, and generates the event on > the slow path when either a direct copy occurs or a new PLAB is request. > > Since I'm adding an event I cc:ed the serviceability list in case > anyone has any comments on the event and changes to trace.xml. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 > Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 > > Bengt has been kind and agreed to both sponsor and host the the webrev. > > Thanks, > Staffan > From jaroslav.bachorik at oracle.com Mon Aug 25 17:16:10 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 25 Aug 2014 19:16:10 +0200 Subject: RFR 8037082: java/lang/instrument/NativeMethodPrefixAgent.java failing Message-ID: <53FB6F5A.9030201@oracle.com> Please, review the following test fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8037082 Webrev: http://cr.openjdk.java.net/~jbachorik/8037082/webrev.00 As Staffan mentions in the issue comments - "The two tests NativeMethodPrefixAgent and RetransformAgent use their own byte code instrumentation library in jdk/test/java/lang/instrument/ilib/. These tests need to be rewritten to use ASM instead so that we don't have to maintain the ilib library." This patch is intended to remove the "ilib" library and replace the usages with an ASM5 alternative. Only the currently used features of the "ilib" library are being ported. Thanks, -JB- From staffan.friberg at oracle.com Mon Aug 25 17:32:40 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 25 Aug 2014 10:32:40 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FB6A86.1080908@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> Message-ID: <53FB7338.9030208@oracle.com> Hi Erik, No issue with naming the field class, since the event is similar to the Allocation event I used that as a starting point and it also uses class as name together with a couple of other events. Will go through the descriptions and remove periods. Object age is basically the how many times an object has been kept in survivor region, it is incremented each time a YC happens and the object is aged. Will see how I can update the description to make it clearer. Calling the field tenuringAge might help? > From the documentation, > http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html > > -XX:MaxTenuringThreshold=/threshold/ > > Sets the maximum tenuring threshold for use in adaptive GC sizing. > The largest value is 15. The default value is 15 for the parallel > (throughput) collector, and 6 for the CMS collector. > > The following example shows how to set the maximum tenuring > threshold to 10: > > -XX:MaxTenuringThreshold=10 > > > -XX:+PrintTenuringDistribution > > Enables printing of tenuring age information. The following is an > example of the output: > > Desired survivor size 48286924 bytes, new threshold 10 (max 10) > - age 1: 28992024 bytes, 28992024 total > - age 2: 1366864 bytes, 30358888 total > - age 3: 1425912 bytes, 31784800 total > ... > > Age 1 objects are the youngest survivors (they were created after > the previous scavenge, survived the latest scavenge, and moved > from eden to survivor space). Age 2 objects have survived two > scavenges (during the second scavenge they were copied from one > survivor space to the next). And so on. > > In the preceding example, 28 992 024 bytes survived one scavenge > and were copied from eden to survivor space, 1 366 864 bytes are > occupied by age 2 objects, etc. The third value in each row is the > cumulative size of objects of age n or less. > > By default, this option is disabled. > Thanks for the comments, Staffan On 08/25/2014 09:55 AM, Erik Gahlin wrote: > Did you manage to call the field "class"? It's a reserved word in C++, > so we had to use "klass" in the past > > Descriptions with only one sentence shouldn't end with "." > > How is "Object Age" measured? > > As a user, I would expect the number to be in seconds/minutes/hours, > but that is not the case. Perhaps an explanation in the description > and/or a field name that better reflects what we really mean with age. > > Otherwise trace.xml looks good! > > Erik > > Staffan Friberg skrev 25/08/14 18:28: >> Hi, >> >> Could I please get reviews for this RFE that adds a trace event for >> aging and promotion for young collections in G1, CMS and Parallel GC. >> It works similarly to allocation events, and generates the event on >> the slow path when either a direct copy occurs or a new PLAB is request. >> >> Since I'm adding an event I cc:ed the serviceability list in case >> anyone has any comments on the event and changes to trace.xml. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >> >> Bengt has been kind and agreed to both sponsor and host the the webrev. >> >> Thanks, >> Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Aug 25 18:37:24 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Aug 2014 20:37:24 +0200 Subject: RFR 8037082: java/lang/instrument/NativeMethodPrefixAgent.java failing In-Reply-To: <53FB6F5A.9030201@oracle.com> References: <53FB6F5A.9030201@oracle.com> Message-ID: <9010C628-1EDA-4E73-9FAC-EE91DCD32AEC@oracle.com> Thanks for taking on this one! The code looks good. Just two small things below. Have you tested with -Xverify:all, just to see if there are any byte code problems? Could fix the auto-naming of the params in this code? 131 @Override 132 public void visit(int i, int i1, String className, String string1, String string2, String[] strings) { 133 this.className = className; 134 super.visit(i, i1, className, string1, string2, strings); 135 } nit: let?s ClassWriter to deal -> let ClassWriter deal 163 mv.visitMaxs(1, 1); // dummy call; let's ClassWriter to deal with this Thanks, /Staffan On 25 aug 2014, at 19:16, Jaroslav Bachorik wrote: > Please, review the following test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8037082 > Webrev: http://cr.openjdk.java.net/~jbachorik/8037082/webrev.00 > > As Staffan mentions in the issue comments - "The two tests NativeMethodPrefixAgent and RetransformAgent use their own byte code instrumentation library in jdk/test/java/lang/instrument/ilib/. These tests need to be rewritten to use ASM instead so that we don't have to maintain the ilib library." > > This patch is intended to remove the "ilib" library and replace the usages with an ASM5 alternative. Only the currently used features of the "ilib" library are being ported. > > Thanks, > > -JB- From david.holmes at oracle.com Tue Aug 26 04:03:41 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Aug 2014 14:03:41 +1000 Subject: RFR 8040692: [TESTBUG] sun/management/jmxremote/bootstrap/JvmstatCountersTest.java requires -XX:+UsePerfData option to pass on embedded platforms In-Reply-To: <53F5E9C0.6050906@oracle.com> References: <53F5E9C0.6050906@oracle.com> Message-ID: <53FC071D.20100@oracle.com> On 21/08/2014 10:44 PM, Jaroslav Bachorik wrote: > Please, review this simple fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8040692 > Webrev: http://cr.openjdk.java.net/~jbachorik/8040692/webrev.00 > > On embedded platforms it is necessary to provide "-XX:+UsePerfData" flag > in order to make the performance counters accessible. This fix does this > for the tests which need to access the performance counters. Looks fine to me - except for the sources.list file ?? :) Thanks, David > Thanks, > > -JB- From mandy.chung at oracle.com Tue Aug 26 04:29:35 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Aug 2014 21:29:35 -0700 Subject: Review request: 8055230: Rename attach provider implementation class Message-ID: <53FC0D2F.9090002@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ This patch renames the class name of attach provider implementation class to be the same for all platforms. This simplifies the build logic and removes the need for generating the service config file at build time. The files renamed are unix/classes/sun/tools/attach/${OS}VirtualMachine.java -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java unix/classes/sun/tools/attach/${OS}AttachProvider.java -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java and also corresponding native files. Mandy From david.holmes at oracle.com Tue Aug 26 05:09:57 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Aug 2014 15:09:57 +1000 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <53FC0D2F.9090002@oracle.com> References: <53FC0D2F.9090002@oracle.com> Message-ID: <53FC16A5.6080800@oracle.com> I like this change! :) Looks good to me. Thanks Mandy! David ----- On 26/08/2014 2:29 PM, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ > > This patch renames the class name of attach provider implementation class > to be the same for all platforms. This simplifies the build logic and > removes the need for generating the service config file at build time. > > The files renamed are > unix/classes/sun/tools/attach/${OS}VirtualMachine.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > unix/classes/sun/tools/attach/${OS}AttachProvider.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > > ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > > and also corresponding native files. > > Mandy > > From staffan.larsen at oracle.com Tue Aug 26 05:52:55 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Aug 2014 07:52:55 +0200 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <53FC0D2F.9090002@oracle.com> References: <53FC0D2F.9090002@oracle.com> Message-ID: <3C7903E1-0A1C-4D64-98E5-81D561E053AE@oracle.com> Ahh. The simplicity! Looks good! Thanks, /Staffan On 26 aug 2014, at 06:29, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ > > This patch renames the class name of attach provider implementation class > to be the same for all platforms. This simplifies the build logic and > removes the need for generating the service config file at build time. > > The files renamed are > unix/classes/sun/tools/attach/${OS}VirtualMachine.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > unix/classes/sun/tools/attach/${OS}AttachProvider.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > > ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > > and also corresponding native files. > > Mandy > > From Alan.Bateman at oracle.com Tue Aug 26 07:26:37 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Aug 2014 08:26:37 +0100 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <53FC0D2F.9090002@oracle.com> References: <53FC0D2F.9090002@oracle.com> Message-ID: <53FC36AD.8040003@oracle.com> On 26/08/2014 05:29, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ > > This patch renames the class name of attach provider implementation class > to be the same for all platforms. This simplifies the build logic and > removes the need for generating the service config file at build time. This looks good, nice to see the benefits of the new layout. -Alan. From chris.hegarty at oracle.com Tue Aug 26 07:41:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Aug 2014 08:41:49 +0100 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <53FC36AD.8040003@oracle.com> References: <53FC0D2F.9090002@oracle.com> <53FC36AD.8040003@oracle.com> Message-ID: <24373EAB-28C5-4343-B8C2-C542B0437242@oracle.com> On 26 Aug 2014, at 08:26, Alan Bateman wrote: > On 26/08/2014 05:29, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ >> >> This patch renames the class name of attach provider implementation class >> to be the same for all platforms. This simplifies the build logic and >> removes the need for generating the service config file at build time. > This looks good, nice to see the benefits of the new layout. +1. Wow this is nice, and the knock on simplification in the build logic is a bonus. -Chris. > -Alan. From jaroslav.bachorik at oracle.com Tue Aug 26 08:15:23 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 26 Aug 2014 10:15:23 +0200 Subject: RFR 8037082: java/lang/instrument/NativeMethodPrefixAgent.java failing In-Reply-To: <9010C628-1EDA-4E73-9FAC-EE91DCD32AEC@oracle.com> References: <53FB6F5A.9030201@oracle.com> <9010C628-1EDA-4E73-9FAC-EE91DCD32AEC@oracle.com> Message-ID: <53FC421B.9080007@oracle.com> On 08/25/2014 08:37 PM, Staffan Larsen wrote: > Thanks for taking on this one! > > The code looks good. Just two small things below. > > Have you tested with -Xverify:all, just to see if there are any byte code problems? I've re-run the tests with -Xverify:all and fixed one problem in the generated bytecode. Thanks for reminding me. > > > Could fix the auto-naming of the params in this code? > 131 @Override > 132 public void visit(int i, int i1, String className, String string1, String string2, String[] strings) { > 133 this.className = className; > 134 super.visit(i, i1, className, string1, string2, strings); > 135 } Done ... > > nit: let?s ClassWriter to deal -> let ClassWriter deal > 163 mv.visitMaxs(1, 1); // dummy call; let's ClassWriter to deal with this ... and done. http://cr.openjdk.java.net/~jbachorik/8037082/webrev.01 Cheers, -JB- > > > Thanks, > /Staffan > > > On 25 aug 2014, at 19:16, Jaroslav Bachorik wrote: > >> Please, review the following test fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8037082 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8037082/webrev.00 >> >> As Staffan mentions in the issue comments - "The two tests NativeMethodPrefixAgent and RetransformAgent use their own byte code instrumentation library in jdk/test/java/lang/instrument/ilib/. These tests need to be rewritten to use ASM instead so that we don't have to maintain the ilib library." >> >> This patch is intended to remove the "ilib" library and replace the usages with an ASM5 alternative. Only the currently used features of the "ilib" library are being ported. >> >> Thanks, >> >> -JB- > From erik.joelsson at oracle.com Tue Aug 26 08:34:02 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Aug 2014 10:34:02 +0200 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <53FC0D2F.9090002@oracle.com> References: <53FC0D2F.9090002@oracle.com> Message-ID: <53FC467A.5060300@oracle.com> Nice! /Erik On 2014-08-26 06:29, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ > > This patch renames the class name of attach provider implementation class > to be the same for all platforms. This simplifies the build logic and > removes the need for generating the service config file at build time. > > The files renamed are > unix/classes/sun/tools/attach/${OS}VirtualMachine.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > unix/classes/sun/tools/attach/${OS}AttachProvider.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > > ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > > and also corresponding native files. > > Mandy > > From staffan.larsen at oracle.com Tue Aug 26 08:43:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Aug 2014 10:43:33 +0200 Subject: RFR 8037082: java/lang/instrument/NativeMethodPrefixAgent.java failing In-Reply-To: <53FC421B.9080007@oracle.com> References: <53FB6F5A.9030201@oracle.com> <9010C628-1EDA-4E73-9FAC-EE91DCD32AEC@oracle.com> <53FC421B.9080007@oracle.com> Message-ID: <45C03071-F283-4AE2-80FB-86362387C533@oracle.com> Looks good! Thanks, /Staffan On 26 aug 2014, at 10:15, Jaroslav Bachorik wrote: > On 08/25/2014 08:37 PM, Staffan Larsen wrote: >> Thanks for taking on this one! >> >> The code looks good. Just two small things below. >> >> Have you tested with -Xverify:all, just to see if there are any byte code problems? > > I've re-run the tests with -Xverify:all and fixed one problem in the generated bytecode. Thanks for reminding me. > >> >> >> Could fix the auto-naming of the params in this code? >> 131 @Override >> 132 public void visit(int i, int i1, String className, String string1, String string2, String[] strings) { >> 133 this.className = className; >> 134 super.visit(i, i1, className, string1, string2, strings); >> 135 } > > Done ... > >> >> nit: let?s ClassWriter to deal -> let ClassWriter deal >> 163 mv.visitMaxs(1, 1); // dummy call; let's ClassWriter to deal with this > > ... and done. > > http://cr.openjdk.java.net/~jbachorik/8037082/webrev.01 > > Cheers, > > -JB- > >> >> >> Thanks, >> /Staffan >> >> >> On 25 aug 2014, at 19:16, Jaroslav Bachorik wrote: >> >>> Please, review the following test fix. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8037082 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8037082/webrev.00 >>> >>> As Staffan mentions in the issue comments - "The two tests NativeMethodPrefixAgent and RetransformAgent use their own byte code instrumentation library in jdk/test/java/lang/instrument/ilib/. These tests need to be rewritten to use ASM instead so that we don't have to maintain the ilib library." >>> >>> This patch is intended to remove the "ilib" library and replace the usages with an ASM5 alternative. Only the currently used features of the "ilib" library are being ported. >>> >>> Thanks, >>> >>> -JB- >> > From bengt.rutisson at oracle.com Tue Aug 26 08:50:31 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Aug 2014 10:50:31 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FB7338.9030208@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> Message-ID: <53FC4A57.3030100@oracle.com> Hi all, Staffan sent me an updated webrev based on Erik's comments. I uploaded it here: http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/ Thanks, Bengt On 2014-08-25 19:32, Staffan Friberg wrote: > Hi Erik, > > No issue with naming the field class, since the event is similar to > the Allocation event I used that as a starting point and it also uses > class as name together with a couple of other events. > > Will go through the descriptions and remove periods. > > Object age is basically the how many times an object has been kept in > survivor region, it is incremented each time a YC happens and the > object is aged. > Will see how I can update the description to make it clearer. Calling > the field tenuringAge might help? > >> From the documentation, >> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >> >> -XX:MaxTenuringThreshold=/threshold/ >> >> Sets the maximum tenuring threshold for use in adaptive GC >> sizing. The largest value is 15. The default value is 15 for the >> parallel (throughput) collector, and 6 for the CMS collector. >> >> The following example shows how to set the maximum tenuring >> threshold to 10: >> >> -XX:MaxTenuringThreshold=10 >> >> >> -XX:+PrintTenuringDistribution >> >> Enables printing of tenuring age information. The following is an >> example of the output: >> >> Desired survivor size 48286924 bytes, new threshold 10 (max 10) >> - age 1: 28992024 bytes, 28992024 total >> - age 2: 1366864 bytes, 30358888 total >> - age 3: 1425912 bytes, 31784800 total >> ... >> >> Age 1 objects are the youngest survivors (they were created after >> the previous scavenge, survived the latest scavenge, and moved >> from eden to survivor space). Age 2 objects have survived two >> scavenges (during the second scavenge they were copied from one >> survivor space to the next). And so on. >> >> In the preceding example, 28 992 024 bytes survived one scavenge >> and were copied from eden to survivor space, 1 366 864 bytes are >> occupied by age 2 objects, etc. The third value in each row is >> the cumulative size of objects of age n or less. >> >> By default, this option is disabled. >> > > Thanks for the comments, > Staffan > > On 08/25/2014 09:55 AM, Erik Gahlin wrote: >> Did you manage to call the field "class"? It's a reserved word in >> C++, so we had to use "klass" in the past >> >> Descriptions with only one sentence shouldn't end with "." >> >> How is "Object Age" measured? >> >> As a user, I would expect the number to be in seconds/minutes/hours, >> but that is not the case. Perhaps an explanation in the description >> and/or a field name that better reflects what we really mean with age. >> >> Otherwise trace.xml looks good! >> >> Erik >> >> Staffan Friberg skrev 25/08/14 18:28: >>> Hi, >>> >>> Could I please get reviews for this RFE that adds a trace event for >>> aging and promotion for young collections in G1, CMS and Parallel GC. >>> It works similarly to allocation events, and generates the event on >>> the slow path when either a direct copy occurs or a new PLAB is >>> request. >>> >>> Since I'm adding an event I cc:ed the serviceability list in case >>> anyone has any comments on the event and changes to trace.xml. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>> >>> Bengt has been kind and agreed to both sponsor and host the the webrev. >>> >>> Thanks, >>> Staffan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From poonam.bajaj at oracle.com Tue Aug 26 10:27:13 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Tue, 26 Aug 2014 15:57:13 +0530 Subject: Review request: 8049303: Transient network problems cause JMX thread to fail silenty In-Reply-To: <53FBDB1A.2070501@oracle.com> References: <53FBDB1A.2070501@oracle.com> Message-ID: <53FC6101.4020501@oracle.com> Sending the review request to serviceability-dev list as well... ----------- Could I have reviews for this change: Bug: https://bugs.openjdk.java.net/browse/JDK-8049303 Webrev: http://cr.openjdk.java.net/~poonam/8049303/webrev.00/ Problem and fix: By default the JMX client side notification fetch timeout (jmx.remote.x.notification.fetch.timeout) is 1 minute and the default server connection timeout (jmx.remote.x.server.connection.timeout) is 2 minutes. If the client side connector thread makes a notification fetch request to the server, but a transient network problem prevents the server response from reaching the client, the client side connector will wait for a response until the timeout period (1 minute) has expired before throwing an IOException. The client side RMIConnector implementation handles the IOException, by re-checking the connection status to understand whether or not it is broken. If the connection is not available at that moment, the connector fails by re-throwing the initial IOException. The problem is that this re-check of the connection passes because the server side of the connection doesn't time out until 2 minutes has passed (by default), so the NotifFetcher thread dies without posting a failed notification, and the client application does not get a chance to recover. The fix is to forward the exception on the JMX client side before checking the connection status. Testing: All the jdk_jmx and jdk_management regression tests passed. The fix applies cleanly to 8u and 7u repos. Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Aug 26 10:36:05 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 26 Aug 2014 12:36:05 +0200 Subject: Review request: 8049303: Transient network problems cause JMX thread to fail silenty In-Reply-To: <53FC6101.4020501@oracle.com> References: <53FBDB1A.2070501@oracle.com> <53FC6101.4020501@oracle.com> Message-ID: <53FC6315.8080700@oracle.com> Hi Poonam, On 08/26/2014 12:27 PM, Poonam Bajaj wrote: > Sending the review request to serviceability-dev list as well... > ----------- > > Could I have reviews for this change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8049303 > Webrev: http://cr.openjdk.java.net/~poonam/8049303/webrev.00/ L1499-1504 can be completely removed. They serve no purpose now. Please, adjust the indentation to fit the original one. Thanks, -JB- > > Problem and fix: > By default the JMX client side notification fetch timeout > (jmx.remote.x.notification.fetch.timeout) is 1 minute and the default > server connection timeout (jmx.remote.x.server.connection.timeout) is 2 > minutes. > > If the client side connector thread makes a notification fetch request > to the server, but a transient network problem prevents the server > response from reaching the client, the client side connector will wait > for a response until the timeout period (1 minute) has expired before > throwing an IOException. > > The client side RMIConnector implementation handles the IOException, by > re-checking the connection status to understand whether or not it is > broken. If the connection is not available at that moment, the connector > fails by re-throwing the initial IOException. The problem is that this > re-check of the connection passes because the server side of the > connection doesn't time out until 2 minutes has passed (by default), so > the NotifFetcher thread > dies without posting a failed notification, and the client application > does not get a chance to recover. > > The fix is to forward the exception on the JMX client side before > checking the connection status. > > Testing: > All the jdk_jmx and jdk_management regression tests passed. > > The fix applies cleanly to 8u and 7u repos. > > > Thanks, > Poonam > > From daniel.fuchs at oracle.com Tue Aug 26 10:40:09 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 Aug 2014 12:40:09 +0200 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <53FC0D2F.9090002@oracle.com> References: <53FC0D2F.9090002@oracle.com> Message-ID: <53FC6409.3030601@oracle.com> Hi Mandy, I'm seeing some small differences in the various VirtualMachineImpl.java files, but if I'm not mistaken, all the new AttachProviderImpl.java look all the same. I wonder if the patch could be further simplified by moving AttachProviderImpl.java to jdk.attach/share/classes (unless there's a reason to keep all the different copies)... best regards, -- daniel On 8/26/14 6:29 AM, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ > > This patch renames the class name of attach provider implementation class > to be the same for all platforms. This simplifies the build logic and > removes the need for generating the service config file at build time. > > The files renamed are > unix/classes/sun/tools/attach/${OS}VirtualMachine.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > unix/classes/sun/tools/attach/${OS}AttachProvider.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > > ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java > -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java > > and also corresponding native files. > > Mandy > > From serguei.spitsyn at oracle.com Tue Aug 26 10:58:28 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Aug 2014 03:58:28 -0700 Subject: RFR(S): JDK-8054194 jstack crash: assert(handle != NULL) failed: JNI handle should not be null In-Reply-To: <56DA62BE-E0EF-4C17-AE77-0D67AB1297E4@oracle.com> References: <53F5EC60.9030800@oracle.com> <56DA62BE-E0EF-4C17-AE77-0D67AB1297E4@oracle.com> Message-ID: <53FC6854.2090702@oracle.com> Dmitry, I doubt, this webrev fixes the issue. At least, I can't see it yet. It looks like the assert is because the imagePath_ID or symbolPath_ID were not initialized properly. But there is clear explanation yet how this could happen. Maybe, the conclusion above was wrong, but some prove is needed and/or another possible root cause. Also, Staffan is right, about killing the remote process. The remote process has no relation to the fix. Thanks, Serguei On 8/25/14 3:58 AM, Staffan Larsen wrote: > Dmitry, > > Your changes look good (except missing spaces after commas). But what I do not understand is how this relates to the bug. The code in setImageAndSymbolPath() is not looking at the remote process, it?s just setting up data in the jstack process. How does killing the remote process affect this code? What am I missing? > > /Staffan > > On 21 aug 2014, at 14:56, Dmitry Samersoff wrote: > >> Hi Everyone, >> >> Please review small agent changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8054194/webrev.01/ >> >> Under windows, If jstack attempts to attach to java process that is >> being killed by someone else, GetStaticObjectField might return NULL. >> >> -Dmitry >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Aug 26 10:59:41 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Aug 2014 12:59:41 +0200 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <53FC6409.3030601@oracle.com> References: <53FC0D2F.9090002@oracle.com> <53FC6409.3030601@oracle.com> Message-ID: <10B63AB3-9E94-45DE-8422-DF6CD12C946C@oracle.com> There are some differences in the AttachProvideImpl files. Most notably the windows version is very different. Linux, Bsd and Aix are the same. The Solaris version has a minor difference in the ?public String type()? implementation. The Linux, Bsd, Aix and Solaris versions could probably be unified. /Staffan On 26 aug 2014, at 12:40, Daniel Fuchs wrote: > Hi Mandy, > > I'm seeing some small differences in the various VirtualMachineImpl.java > files, but if I'm not mistaken, all the new AttachProviderImpl.java look > all the same. I wonder if the patch could be further simplified by > moving AttachProviderImpl.java to jdk.attach/share/classes (unless > there's a reason to keep all the different copies)... > > best regards, > > -- daniel > > On 8/26/14 6:29 AM, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ >> >> This patch renames the class name of attach provider implementation class >> to be the same for all platforms. This simplifies the build logic and >> removes the need for generating the service config file at build time. >> >> The files renamed are >> unix/classes/sun/tools/attach/${OS}VirtualMachine.java >> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >> unix/classes/sun/tools/attach/${OS}AttachProvider.java >> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >> >> ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java >> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >> ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java >> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >> >> and also corresponding native files. >> >> Mandy >> >> > From poonam.bajaj at oracle.com Tue Aug 26 11:20:21 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Tue, 26 Aug 2014 16:50:21 +0530 Subject: Review request: 8049303: Transient network problems cause JMX thread to fail silenty In-Reply-To: <53FC6315.8080700@oracle.com> References: <53FBDB1A.2070501@oracle.com> <53FC6101.4020501@oracle.com> <53FC6315.8080700@oracle.com> Message-ID: <53FC6D75.90702@oracle.com> Hi Jaroslav, On 8/26/2014 4:06 PM, Jaroslav Bachorik wrote: > Hi Poonam, > > On 08/26/2014 12:27 PM, Poonam Bajaj wrote: >> Sending the review request to serviceability-dev list as well... >> ----------- >> >> Could I have reviews for this change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8049303 >> Webrev: http://cr.openjdk.java.net/~poonam/8049303/webrev.00/ > > L1499-1504 can be completely removed. They serve no purpose now. > Removed this piece of code. > Please, adjust the indentation to fit the original one. Corrected the indentation. Updated webrev: http://cr.openjdk.java.net/~poonam/8049303/webrev.01/ Thanks, Poonam > > Thanks, > > -JB- > >> >> Problem and fix: >> By default the JMX client side notification fetch timeout >> (jmx.remote.x.notification.fetch.timeout) is 1 minute and the default >> server connection timeout (jmx.remote.x.server.connection.timeout) is 2 >> minutes. >> >> If the client side connector thread makes a notification fetch request >> to the server, but a transient network problem prevents the server >> response from reaching the client, the client side connector will wait >> for a response until the timeout period (1 minute) has expired before >> throwing an IOException. >> >> The client side RMIConnector implementation handles the IOException, by >> re-checking the connection status to understand whether or not it is >> broken. If the connection is not available at that moment, the connector >> fails by re-throwing the initial IOException. The problem is that this >> re-check of the connection passes because the server side of the >> connection doesn't time out until 2 minutes has passed (by default), so >> the NotifFetcher thread >> dies without posting a failed notification, and the client application >> does not get a chance to recover. >> >> The fix is to forward the exception on the JMX client side before >> checking the connection status. >> >> Testing: >> All the jdk_jmx and jdk_management regression tests passed. >> >> The fix applies cleanly to 8u and 7u repos. >> >> >> Thanks, >> Poonam >> >> > From daniel.fuchs at oracle.com Tue Aug 26 11:30:04 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 Aug 2014 13:30:04 +0200 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <10B63AB3-9E94-45DE-8422-DF6CD12C946C@oracle.com> References: <53FC0D2F.9090002@oracle.com> <53FC6409.3030601@oracle.com> <10B63AB3-9E94-45DE-8422-DF6CD12C946C@oracle.com> Message-ID: <53FC6FBC.9000506@oracle.com> On 8/26/14 12:59 PM, Staffan Larsen wrote: > There are some differences in the AttachProvideImpl files. Most notably the windows version is very different. Linux, Bsd and Aix are the same. The Solaris version has a minor difference in the ?public String type()? implementation. The Linux, Bsd, Aix and Solaris versions could probably be unified. Ah - right - I missed those. Forget my comment then! Thanks Staffan! -- daniel > > /Staffan > > On 26 aug 2014, at 12:40, Daniel Fuchs wrote: > >> Hi Mandy, >> >> I'm seeing some small differences in the various VirtualMachineImpl.java >> files, but if I'm not mistaken, all the new AttachProviderImpl.java look >> all the same. I wonder if the patch could be further simplified by >> moving AttachProviderImpl.java to jdk.attach/share/classes (unless >> there's a reason to keep all the different copies)... >> >> best regards, >> >> -- daniel >> >> On 8/26/14 6:29 AM, Mandy Chung wrote: >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ >>> >>> This patch renames the class name of attach provider implementation class >>> to be the same for all platforms. This simplifies the build logic and >>> removes the need for generating the service config file at build time. >>> >>> The files renamed are >>> unix/classes/sun/tools/attach/${OS}VirtualMachine.java >>> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >>> unix/classes/sun/tools/attach/${OS}AttachProvider.java >>> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java >>> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >>> ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java >>> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> and also corresponding native files. >>> >>> Mandy >>> >>> >> > From serguei.spitsyn at oracle.com Tue Aug 26 11:30:31 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Aug 2014 04:30:31 -0700 Subject: RFR(S): JDK-8054194 jstack crash: assert(handle != NULL) failed: JNI handle should not be null In-Reply-To: <53FC6854.2090702@oracle.com> References: <53F5EC60.9030800@oracle.com> <56DA62BE-E0EF-4C17-AE77-0D67AB1297E4@oracle.com> <53FC6854.2090702@oracle.com> Message-ID: <53FC6FD7.1040006@oracle.com> On 8/26/14 3:58 AM, serguei.spitsyn at oracle.com wrote: > Dmitry, > > I doubt, this webrev fixes the issue. > At least, I can't see it yet. > > It looks like the assert is because the imagePath_ID or symbolPath_ID > were not initialized properly. > But there is clear explanation yet how this could happen. Sorry, a typo above. Wanted to say: "But there is no clear explanation yet how this could happen." Thanks, Serguei > Maybe, the conclusion above was wrong, but some prove is needed and/or > another possible root cause. > > Also, Staffan is right, about killing the remote process. > The remote process has no relation to the fix. > > Thanks, > Serguei > > > On 8/25/14 3:58 AM, Staffan Larsen wrote: >> Dmitry, >> >> Your changes look good (except missing spaces after commas). But what I do not understand is how this relates to the bug. The code in setImageAndSymbolPath() is not looking at the remote process, it?s just setting up data in the jstack process. How does killing the remote process affect this code? What am I missing? >> >> /Staffan >> >> On 21 aug 2014, at 14:56, Dmitry Samersoff wrote: >> >>> Hi Everyone, >>> >>> Please review small agent changes: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8054194/webrev.01/ >>> >>> Under windows, If jstack attempts to attach to java process that is >>> being killed by someone else, GetStaticObjectField might return NULL. >>> >>> -Dmitry >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Aug 26 11:39:50 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Aug 2014 04:39:50 -0700 Subject: RFR(S): JDK-8031583: warnings from b03 for hotspot/agent/src/os/solaris/proc: JNI exception pending In-Reply-To: <53E8D9E0.4070607@oracle.com> References: <53E8D9E0.4070607@oracle.com> Message-ID: <53FC7206.5080909@oracle.com> Looks good. Thanks, Serguei On 8/11/14 7:57 AM, Dmitry Samersoff wrote: > Hi Everybody, > > Please, review small fix that adds more exception handling code > > http://cr.openjdk.java.net/~dsamersoff/JDK-8031583/webrev.01/ > > -Dmitry > From jaroslav.bachorik at oracle.com Tue Aug 26 11:41:49 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 26 Aug 2014 13:41:49 +0200 Subject: Review request: 8049303: Transient network problems cause JMX thread to fail silenty In-Reply-To: <53FC6D75.90702@oracle.com> References: <53FBDB1A.2070501@oracle.com> <53FC6101.4020501@oracle.com> <53FC6315.8080700@oracle.com> <53FC6D75.90702@oracle.com> Message-ID: <53FC727D.6070405@oracle.com> On 08/26/2014 01:20 PM, Poonam Bajaj wrote: > Hi Jaroslav, > > On 8/26/2014 4:06 PM, Jaroslav Bachorik wrote: >> Hi Poonam, >> >> On 08/26/2014 12:27 PM, Poonam Bajaj wrote: >>> Sending the review request to serviceability-dev list as well... >>> ----------- >>> >>> Could I have reviews for this change: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049303 >>> Webrev: http://cr.openjdk.java.net/~poonam/8049303/webrev.00/ >> >> L1499-1504 can be completely removed. They serve no purpose now. >> > Removed this piece of code. > >> Please, adjust the indentation to fit the original one. > > Corrected the indentation. > > Updated webrev: http://cr.openjdk.java.net/~poonam/8049303/webrev.01/ Looks good! -JB- > > Thanks, > Poonam > >> >> Thanks, >> >> -JB- >> >>> >>> Problem and fix: >>> By default the JMX client side notification fetch timeout >>> (jmx.remote.x.notification.fetch.timeout) is 1 minute and the default >>> server connection timeout (jmx.remote.x.server.connection.timeout) is 2 >>> minutes. >>> >>> If the client side connector thread makes a notification fetch request >>> to the server, but a transient network problem prevents the server >>> response from reaching the client, the client side connector will wait >>> for a response until the timeout period (1 minute) has expired before >>> throwing an IOException. >>> >>> The client side RMIConnector implementation handles the IOException, by >>> re-checking the connection status to understand whether or not it is >>> broken. If the connection is not available at that moment, the connector >>> fails by re-throwing the initial IOException. The problem is that this >>> re-check of the connection passes because the server side of the >>> connection doesn't time out until 2 minutes has passed (by default), so >>> the NotifFetcher thread >>> dies without posting a failed notification, and the client application >>> does not get a chance to recover. >>> >>> The fix is to forward the exception on the JMX client side before >>> checking the connection status. >>> >>> Testing: >>> All the jdk_jmx and jdk_management regression tests passed. >>> >>> The fix applies cleanly to 8u and 7u repos. >>> >>> >>> Thanks, >>> Poonam >>> >>> >> From erik.gahlin at oracle.com Tue Aug 26 12:26:27 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 26 Aug 2014 14:26:27 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FC4A57.3030100@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> Message-ID: <53FC7CF3.1010006@oracle.com> Looks good Bengt Rutisson skrev 2014-08-26 10:50: > > Hi all, > > Staffan sent me an updated webrev based on Erik's comments. I uploaded > it here: > http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/ > > Thanks, > Bengt > > > On 2014-08-25 19:32, Staffan Friberg wrote: >> Hi Erik, >> >> No issue with naming the field class, since the event is similar to >> the Allocation event I used that as a starting point and it also uses >> class as name together with a couple of other events. >> >> Will go through the descriptions and remove periods. >> >> Object age is basically the how many times an object has been kept in >> survivor region, it is incremented each time a YC happens and the >> object is aged. >> Will see how I can update the description to make it clearer. Calling >> the field tenuringAge might help? >> >>> From the documentation, >>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >>> >>> -XX:MaxTenuringThreshold=/threshold/ >>> >>> Sets the maximum tenuring threshold for use in adaptive GC >>> sizing. The largest value is 15. The default value is 15 for the >>> parallel (throughput) collector, and 6 for the CMS collector. >>> >>> The following example shows how to set the maximum tenuring >>> threshold to 10: >>> >>> -XX:MaxTenuringThreshold=10 >>> >>> >>> -XX:+PrintTenuringDistribution >>> >>> Enables printing of tenuring age information. The following is >>> an example of the output: >>> >>> Desired survivor size 48286924 bytes, new threshold 10 (max 10) >>> - age 1: 28992024 bytes, 28992024 total >>> - age 2: 1366864 bytes, 30358888 total >>> - age 3: 1425912 bytes, 31784800 total >>> ... >>> >>> Age 1 objects are the youngest survivors (they were created >>> after the previous scavenge, survived the latest scavenge, and >>> moved from eden to survivor space). Age 2 objects have survived >>> two scavenges (during the second scavenge they were copied from >>> one survivor space to the next). And so on. >>> >>> In the preceding example, 28 992 024 bytes survived one scavenge >>> and were copied from eden to survivor space, 1 366 864 bytes are >>> occupied by age 2 objects, etc. The third value in each row is >>> the cumulative size of objects of age n or less. >>> >>> By default, this option is disabled. >>> >> >> Thanks for the comments, >> Staffan >> >> On 08/25/2014 09:55 AM, Erik Gahlin wrote: >>> Did you manage to call the field "class"? It's a reserved word in >>> C++, so we had to use "klass" in the past >>> >>> Descriptions with only one sentence shouldn't end with "." >>> >>> How is "Object Age" measured? >>> >>> As a user, I would expect the number to be in seconds/minutes/hours, >>> but that is not the case. Perhaps an explanation in the description >>> and/or a field name that better reflects what we really mean with age. >>> >>> Otherwise trace.xml looks good! >>> >>> Erik >>> >>> Staffan Friberg skrev 25/08/14 18:28: >>>> Hi, >>>> >>>> Could I please get reviews for this RFE that adds a trace event for >>>> aging and promotion for young collections in G1, CMS and Parallel GC. >>>> It works similarly to allocation events, and generates the event on >>>> the slow path when either a direct copy occurs or a new PLAB is >>>> request. >>>> >>>> Since I'm adding an event I cc:ed the serviceability list in case >>>> anyone has any comments on the event and changes to trace.xml. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>>> >>>> Bengt has been kind and agreed to both sponsor and host the the >>>> webrev. >>>> >>>> Thanks, >>>> Staffan >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Aug 26 14:47:51 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 26 Aug 2014 18:47:51 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> Message-ID: <53FC9E17.1090902@oracle.com> Staffan, http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ After couple of experiments I end up with simple fix - don't coredump on AGENT_ERROR_TRANSPORT_INIT Current code don't propagate transport error to upper level, so if we need fine grained control I'll rewrite transport initialization. -Dmitry On 2014-08-25 15:53, Staffan Larsen wrote: > > On 25 aug 2014, at 13:33, Dmitry Samersoff > wrote: > >> Staffan, >> >> On 2014-08-25 15:26, Staffan Larsen wrote: >>> Dmitry, >>> >>> One problem with this fix is that debugInit_exit() is used from many >>> places in the JDWP code. For some of these I think it still does make >>> sense to receive a core dump for analysis. I agree that when parsing >>> options, we do not need a core dump. >> >> jdwp has explicit option to request a coredump at debugInit_exit(). >> >> Is it enough or I should create a more sophisticated fix ? > > I don?t think that is enough. Often a problem will happen and will not > be reproducible. > > Maybe this code: > > if ((arg.error != JDWP_ERROR(NONE)) && > (arg.startCount == 0) && > initOnStartup) { > EXIT_ERROR(map2jvmtiError(arg.error), "No transports initialized"); > } > > can use some variant of EXIT_ERROR that does not call fatalError() ? > > /Staffan > >> >> Actually, I don't think that coredump on every call to jni_FatalError() >> (see jni.cpp:726) is necessary but this hotspot code is here for 6 years >> and changing it probably out of scope of this fix. >> >> -Dmitry >> >> >>> >>> /Staffan >>> >>> >>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>> > wrote: >>> >>>> Serguei, >>>> >>>> After some additional testing I changed the fix a bit. Please take >>>> a look at new version. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>> >>>> New version reports JVMTI error to stderr. >>>> >>>> Also jniFatalError is not referenced any more so I remove it. >>>> >>>> -Dmitry >>>> >>>> >>>> >>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>> Ok. >>>>> >>>>> Thank you for the explanation! Serguei >>>>> >>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>> transport initialization behavior and invalid parameters >>>>>> handling. >>>>>> >>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>> to dt_socket transport to make sure that transport doesn't >>>>>> crash (one such crash was discovered and fixed) but just return >>>>>> non-zero exit code to upper level. >>>>>> >>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>> machine takes a time so harness kills the test by timeout. >>>>>> >>>>>> We can just increase timeout for this test but I don't think >>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>> transport. >>>>>> >>>>>> So there is the fix. >>>>>> >>>>>> 4. After the fix tests for negative parameters will return >>>>>> non-zero exit code as expected but will not dump the core. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>> transport parameters the test is still going to fail but >>>>>>> without crash, right? >>>>>>> >>>>>>> Thanks, Serguei >>>>>>> >>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>> Hi Everybody, >>>>>>>> >>>>>>>> Please review the fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>> >>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>> remove this code. >>>>>>>> >>>>>>>> -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. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- 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 dmitry.samersoff at oracle.com Tue Aug 26 15:25:13 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 26 Aug 2014 19:25:13 +0400 Subject: RFR(S): JDK-8054194 jstack crash: assert(handle != NULL) failed: JNI handle should not be null In-Reply-To: <53FC6854.2090702@oracle.com> References: <53F5EC60.9030800@oracle.com> <56DA62BE-E0EF-4C17-AE77-0D67AB1297E4@oracle.com> <53FC6854.2090702@oracle.com> Message-ID: <53FCA6D9.6020301@oracle.com> Serguei, On 2014-08-26 14:58, serguei.spitsyn at oracle.com wrote: > Dmitry, > > I doubt, this webrev fixes the issue. > At least, I can't see it yet. > > It looks like the assert is because the imagePath_ID or symbolPath_ID > were not initialized properly. If imagePath_ID or symbolPath_ID is NULL we get a crash, not assert. Assert happens if (and only if) path is NULL on call to env->GetStringUTFChars(path, &isCopy); at ll. 316, 321 I verified it manually by setting these variables to different values. > But there is no clear explanation yet how this could happen. > Maybe, the conclusion above was wrong, but some prove is needed and/or > another possible root cause. > > Also, Staffan is right, about killing the remote process. > The remote process has no relation to the fix. I can reproduce the problem (intermittently, once in couple of hours) by two scripts running in two separate windows - first script runs and kills Java2D demo second one runs jps and jstack -F against Java2D demo. After the fix, problem is not reproducible anymore. But I'll put more efforts to understand what is going wrong with jstack process. -Dmitry > > Thanks, > Serguei > > > On 8/25/14 3:58 AM, Staffan Larsen wrote: >> Dmitry, >> >> Your changes look good (except missing spaces after commas). But what I do not understand is how this relates to the bug. The code in setImageAndSymbolPath() is not looking at the remote process, it?s just setting up data in the jstack process. How does killing the remote process affect this code? What am I missing? >> >> /Staffan >> >> On 21 aug 2014, at 14:56, Dmitry Samersoff wrote: >> >>> Hi Everyone, >>> >>> Please review small agent changes: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8054194/webrev.01/ >>> >>> Under windows, If jstack attempts to attach to java process that is >>> being killed by someone else, GetStaticObjectField might return NULL. >>> >>> -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. > -- 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 mandy.chung at oracle.com Tue Aug 26 15:53:07 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 Aug 2014 08:53:07 -0700 Subject: Review request: 8055230: Rename attach provider implementation class In-Reply-To: <10B63AB3-9E94-45DE-8422-DF6CD12C946C@oracle.com> References: <53FC0D2F.9090002@oracle.com> <53FC6409.3030601@oracle.com> <10B63AB3-9E94-45DE-8422-DF6CD12C946C@oracle.com> Message-ID: <53FCAD63.2090806@oracle.com> On 8/26/2014 3:59 AM, Staffan Larsen wrote: > There are some differences in the AttachProvideImpl files. Most notably the windows version is very different. Linux, Bsd and Aix are the same. The Solaris version has a minor difference in the ?public String type()? implementation. The Linux, Bsd, Aix and Solaris versions could probably be unified. I would leave this as it is and further unification can be done as future cleanup. Thanks for all the review. Mandy > > /Staffan > > On 26 aug 2014, at 12:40, Daniel Fuchs wrote: > >> Hi Mandy, >> >> I'm seeing some small differences in the various VirtualMachineImpl.java >> files, but if I'm not mistaken, all the new AttachProviderImpl.java look >> all the same. I wonder if the patch could be further simplified by >> moving AttachProviderImpl.java to jdk.attach/share/classes (unless >> there's a reason to keep all the different copies)... >> >> best regards, >> >> -- daniel >> >> On 8/26/14 6:29 AM, Mandy Chung wrote: >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ >>> >>> This patch renames the class name of attach provider implementation class >>> to be the same for all platforms. This simplifies the build logic and >>> removes the need for generating the service config file at build time. >>> >>> The files renamed are >>> unix/classes/sun/tools/attach/${OS}VirtualMachine.java >>> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >>> unix/classes/sun/tools/attach/${OS}AttachProvider.java >>> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java >>> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >>> ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java >>> -> ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> and also corresponding native files. >>> >>> Mandy >>> >>> From serguei.spitsyn at oracle.com Tue Aug 26 17:00:40 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Aug 2014 10:00:40 -0700 Subject: RFR(S): JDK-8054194 jstack crash: assert(handle != NULL) failed: JNI handle should not be null In-Reply-To: <53FCA6D9.6020301@oracle.com> References: <53F5EC60.9030800@oracle.com> <56DA62BE-E0EF-4C17-AE77-0D67AB1297E4@oracle.com> <53FC6854.2090702@oracle.com> <53FCA6D9.6020301@oracle.com> Message-ID: <53FCBD38.8060503@oracle.com> On 8/26/14 8:25 AM, Dmitry Samersoff wrote: > Serguei, > > On 2014-08-26 14:58, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> I doubt, this webrev fixes the issue. >> At least, I can't see it yet. >> >> It looks like the assert is because the imagePath_ID or symbolPath_ID >> were not initialized properly. > If imagePath_ID or symbolPath_ID is NULL we get a crash, not assert. > > Assert happens if (and only if) path is NULL on call to > env->GetStringUTFChars(path, &isCopy); at ll. 316, 321 > > I verified it manually by setting these variables to different values. Nice. But how do we get path == null from one of the statements below ? Is it because of the clazz value? path = (jstring) env->GetStaticObjectField(clazz, imagePath_ID); buf = env->GetStringUTFChars(path, &isCopy); <======== ??? CHECK_EXCEPTION_(false); AutoJavaString imagePath(env, path, buf); path = (jstring) env->GetStaticObjectField(clazz, symbolPath_ID); buf = env->GetStringUTFChars(path, &isCopy); <======== ??? CHECK_EXCEPTION_(false); > >> But there is no clear explanation yet how this could happen. >> Maybe, the conclusion above was wrong, but some prove is needed and/or >> another possible root cause. >> >> Also, Staffan is right, about killing the remote process. >> The remote process has no relation to the fix. > I can reproduce the problem (intermittently, once in couple of hours) by > two scripts running in two separate windows - first script runs and > kills Java2D demo second one runs jps and jstack -F against Java2D demo. > > After the fix, problem is not reproducible anymore. > > But I'll put more efforts to understand what is going wrong with jstack > process. Good. Thanks, Serguei > > -Dmitry > >> Thanks, >> Serguei >> >> >> On 8/25/14 3:58 AM, Staffan Larsen wrote: >>> Dmitry, >>> >>> Your changes look good (except missing spaces after commas). But what I do not understand is how this relates to the bug. The code in setImageAndSymbolPath() is not looking at the remote process, it?s just setting up data in the jstack process. How does killing the remote process affect this code? What am I missing? >>> >>> /Staffan >>> >>> On 21 aug 2014, at 14:56, Dmitry Samersoff wrote: >>> >>>> Hi Everyone, >>>> >>>> Please review small agent changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8054194/webrev.01/ >>>> >>>> Under windows, If jstack attempts to attach to java process that is >>>> being killed by someone else, GetStaticObjectField might return NULL. >>>> >>>> -Dmitry >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Aug 26 17:35:58 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Aug 2014 10:35:58 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FC9E17.1090902@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> Message-ID: <53FCC57E.5030706@oracle.com> Dmitry, This looks good in general. But what error code will be returned in the case of AGENT_ERROR_TRANSPORT_INIT ? Is it Ok to return whatever exit_code we already have or we better return some special error code? Probably, it is Ok to keep the comment at the line 1315 as it is. Thanks, Serguei On 8/26/14 7:47 AM, Dmitry Samersoff wrote: > Staffan, > > http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ > > After couple of experiments I end up with simple fix - don't coredump on > AGENT_ERROR_TRANSPORT_INIT > > Current code don't propagate transport error to upper level, so if we > need fine grained control I'll rewrite transport initialization. > > -Dmitry > > > On 2014-08-25 15:53, Staffan Larsen wrote: >> On 25 aug 2014, at 13:33, Dmitry Samersoff > > wrote: >> >>> Staffan, >>> >>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>> Dmitry, >>>> >>>> One problem with this fix is that debugInit_exit() is used from many >>>> places in the JDWP code. For some of these I think it still does make >>>> sense to receive a core dump for analysis. I agree that when parsing >>>> options, we do not need a core dump. >>> jdwp has explicit option to request a coredump at debugInit_exit(). >>> >>> Is it enough or I should create a more sophisticated fix ? >> I don?t think that is enough. Often a problem will happen and will not >> be reproducible. >> >> Maybe this code: >> >> if ((arg.error != JDWP_ERROR(NONE)) && >> (arg.startCount == 0) && >> initOnStartup) { >> EXIT_ERROR(map2jvmtiError(arg.error), "No transports initialized"); >> } >> >> can use some variant of EXIT_ERROR that does not call fatalError() ? >> >> /Staffan >> >>> Actually, I don't think that coredump on every call to jni_FatalError() >>> (see jni.cpp:726) is necessary but this hotspot code is here for 6 years >>> and changing it probably out of scope of this fix. >>> >>> -Dmitry >>> >>> >>>> /Staffan >>>> >>>> >>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>> > wrote: >>>> >>>>> Serguei, >>>>> >>>>> After some additional testing I changed the fix a bit. Please take >>>>> a look at new version. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>> >>>>> New version reports JVMTI error to stderr. >>>>> >>>>> Also jniFatalError is not referenced any more so I remove it. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> >>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>> Ok. >>>>>> >>>>>> Thank you for the explanation! Serguei >>>>>> >>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>> Serguei, >>>>>>> >>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>> transport initialization behavior and invalid parameters >>>>>>> handling. >>>>>>> >>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>> crash (one such crash was discovered and fixed) but just return >>>>>>> non-zero exit code to upper level. >>>>>>> >>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>> >>>>>>> We can just increase timeout for this test but I don't think >>>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>>> transport. >>>>>>> >>>>>>> So there is the fix. >>>>>>> >>>>>>> 4. After the fix tests for negative parameters will return >>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>> transport parameters the test is still going to fail but >>>>>>>> without crash, right? >>>>>>>> >>>>>>>> Thanks, Serguei >>>>>>>> >>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>> Hi Everybody, >>>>>>>>> >>>>>>>>> Please review the fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>> >>>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>>> remove this code. >>>>>>>>> >>>>>>>>> -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. >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Aug 26 17:46:13 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 26 Aug 2014 21:46:13 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FCC57E.5030706@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> Message-ID: <53FCC7E5.2010305@oracle.com> Serguei, exit_code set to 1 at ll. 1288 I thought of refactoring this code for better readability but finally decide to keep changes minimal. -Dmitry On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: > Dmitry, > > This looks good in general. > But what error code will be returned in the case of > AGENT_ERROR_TRANSPORT_INIT ? > Is it Ok to return whatever exit_code we already have or we better > return some special error code? > > Probably, it is Ok to keep the comment at the line 1315 as it is. > > > Thanks, > Serguei > > On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >> Staffan, >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >> >> After couple of experiments I end up with simple fix - don't coredump on >> AGENT_ERROR_TRANSPORT_INIT >> >> Current code don't propagate transport error to upper level, so if we >> need fine grained control I'll rewrite transport initialization. >> >> -Dmitry >> >> >> On 2014-08-25 15:53, Staffan Larsen wrote: >>> On 25 aug 2014, at 13:33, Dmitry Samersoff >> > wrote: >>> >>>> Staffan, >>>> >>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>> Dmitry, >>>>> >>>>> One problem with this fix is that debugInit_exit() is used from many >>>>> places in the JDWP code. For some of these I think it still does make >>>>> sense to receive a core dump for analysis. I agree that when parsing >>>>> options, we do not need a core dump. >>>> jdwp has explicit option to request a coredump at debugInit_exit(). >>>> >>>> Is it enough or I should create a more sophisticated fix ? >>> I don?t think that is enough. Often a problem will happen and will not >>> be reproducible. >>> >>> Maybe this code: >>> >>> if ((arg.error != JDWP_ERROR(NONE)) && >>> (arg.startCount == 0) && >>> initOnStartup) { >>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports initialized"); >>> } >>> >>> can use some variant of EXIT_ERROR that does not call fatalError() ? >>> >>> /Staffan >>> >>>> Actually, I don't think that coredump on every call to jni_FatalError() >>>> (see jni.cpp:726) is necessary but this hotspot code is here for 6 years >>>> and changing it probably out of scope of this fix. >>>> >>>> -Dmitry >>>> >>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>> > wrote: >>>>> >>>>>> Serguei, >>>>>> >>>>>> After some additional testing I changed the fix a bit. Please take >>>>>> a look at new version. >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>> >>>>>> New version reports JVMTI error to stderr. >>>>>> >>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> >>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>> Ok. >>>>>>> >>>>>>> Thank you for the explanation! Serguei >>>>>>> >>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>> Serguei, >>>>>>>> >>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>> transport initialization behavior and invalid parameters >>>>>>>> handling. >>>>>>>> >>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>> crash (one such crash was discovered and fixed) but just return >>>>>>>> non-zero exit code to upper level. >>>>>>>> >>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>> >>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>>>> transport. >>>>>>>> >>>>>>>> So there is the fix. >>>>>>>> >>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>> without crash, right? >>>>>>>>> >>>>>>>>> Thanks, Serguei >>>>>>>>> >>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>> Hi Everybody, >>>>>>>>>> >>>>>>>>>> Please review the fix: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>> >>>>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>>>> remove this code. >>>>>>>>>> >>>>>>>>>> -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. >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Tue Aug 26 20:22:27 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Aug 2014 13:22:27 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FCC7E5.2010305@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> Message-ID: <53FCEC83.2040009@oracle.com> Dmitry, It makes sense to consider a special exit code for transport init error. Other than that it looks good. No need to re-review. Thanks, Serguei On 8/26/14 10:46 AM, Dmitry Samersoff wrote: > Serguei, > > exit_code set to 1 at ll. 1288 > > I thought of refactoring this code for better readability but finally > decide to keep changes minimal. > > -Dmitry > > > On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> This looks good in general. >> But what error code will be returned in the case of >> AGENT_ERROR_TRANSPORT_INIT ? >> Is it Ok to return whatever exit_code we already have or we better >> return some special error code? >> >> Probably, it is Ok to keep the comment at the line 1315 as it is. >> >> >> Thanks, >> Serguei >> >> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>> Staffan, >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>> >>> After couple of experiments I end up with simple fix - don't coredump on >>> AGENT_ERROR_TRANSPORT_INIT >>> >>> Current code don't propagate transport error to upper level, so if we >>> need fine grained control I'll rewrite transport initialization. >>> >>> -Dmitry >>> >>> >>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>> > wrote: >>>> >>>>> Staffan, >>>>> >>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>> Dmitry, >>>>>> >>>>>> One problem with this fix is that debugInit_exit() is used from many >>>>>> places in the JDWP code. For some of these I think it still does make >>>>>> sense to receive a core dump for analysis. I agree that when parsing >>>>>> options, we do not need a core dump. >>>>> jdwp has explicit option to request a coredump at debugInit_exit(). >>>>> >>>>> Is it enough or I should create a more sophisticated fix ? >>>> I don?t think that is enough. Often a problem will happen and will not >>>> be reproducible. >>>> >>>> Maybe this code: >>>> >>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>> (arg.startCount == 0) && >>>> initOnStartup) { >>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports initialized"); >>>> } >>>> >>>> can use some variant of EXIT_ERROR that does not call fatalError() ? >>>> >>>> /Staffan >>>> >>>>> Actually, I don't think that coredump on every call to jni_FatalError() >>>>> (see jni.cpp:726) is necessary but this hotspot code is here for 6 years >>>>> and changing it probably out of scope of this fix. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>> > wrote: >>>>>> >>>>>>> Serguei, >>>>>>> >>>>>>> After some additional testing I changed the fix a bit. Please take >>>>>>> a look at new version. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>> >>>>>>> New version reports JVMTI error to stderr. >>>>>>> >>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>>> Ok. >>>>>>>> >>>>>>>> Thank you for the explanation! Serguei >>>>>>>> >>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>> Serguei, >>>>>>>>> >>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>> handling. >>>>>>>>> >>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>> crash (one such crash was discovered and fixed) but just return >>>>>>>>> non-zero exit code to upper level. >>>>>>>>> >>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>> >>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>>>>> transport. >>>>>>>>> >>>>>>>>> So there is the fix. >>>>>>>>> >>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>> without crash, right? >>>>>>>>>> >>>>>>>>>> Thanks, Serguei >>>>>>>>>> >>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>> Hi Everybody, >>>>>>>>>>> >>>>>>>>>>> Please review the fix: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>> >>>>>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>>>>> remove this code. >>>>>>>>>>> >>>>>>>>>>> -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. >>>>> -- >>>>> 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 dmitry.samersoff at oracle.com Wed Aug 27 07:36:44 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Aug 2014 11:36:44 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FCEC83.2040009@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> <53FCEC83.2040009@oracle.com> Message-ID: <53FD8A8C.4050808@oracle.com> Serguei, http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.04/ I refactored the debugInit_exit function. Now we have separate exit code for transport error and better readable code. -Dmitry On 2014-08-27 00:22, serguei.spitsyn at oracle.com wrote: > Dmitry, > > It makes sense to consider a special exit code for transport init error. > Other than that it looks good. > No need to re-review. > > Thanks, > Serguei > > On 8/26/14 10:46 AM, Dmitry Samersoff wrote: >> Serguei, >> >> exit_code set to 1 at ll. 1288 >> >> I thought of refactoring this code for better readability but finally >> decide to keep changes minimal. >> >> -Dmitry >> >> >> On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> This looks good in general. >>> But what error code will be returned in the case of >>> AGENT_ERROR_TRANSPORT_INIT ? >>> Is it Ok to return whatever exit_code we already have or we better >>> return some special error code? >>> >>> Probably, it is Ok to keep the comment at the line 1315 as it is. >>> >>> >>> Thanks, >>> Serguei >>> >>> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>>> Staffan, >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>>> >>>> After couple of experiments I end up with simple fix - don't >>>> coredump on >>>> AGENT_ERROR_TRANSPORT_INIT >>>> >>>> Current code don't propagate transport error to upper level, so if we >>>> need fine grained control I'll rewrite transport initialization. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>>>> >>>> > wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>>> Dmitry, >>>>>>> >>>>>>> One problem with this fix is that debugInit_exit() is used from many >>>>>>> places in the JDWP code. For some of these I think it still does >>>>>>> make >>>>>>> sense to receive a core dump for analysis. I agree that when parsing >>>>>>> options, we do not need a core dump. >>>>>> jdwp has explicit option to request a coredump at debugInit_exit(). >>>>>> >>>>>> Is it enough or I should create a more sophisticated fix ? >>>>> I don?t think that is enough. Often a problem will happen and will not >>>>> be reproducible. >>>>> >>>>> Maybe this code: >>>>> >>>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>>> (arg.startCount == 0) && >>>>> initOnStartup) { >>>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports >>>>> initialized"); >>>>> } >>>>> >>>>> can use some variant of EXIT_ERROR that does not call fatalError() ? >>>>> >>>>> /Staffan >>>>> >>>>>> Actually, I don't think that coredump on every call to >>>>>> jni_FatalError() >>>>>> (see jni.cpp:726) is necessary but this hotspot code is here for 6 >>>>>> years >>>>>> and changing it probably out of scope of this fix. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> Serguei, >>>>>>>> >>>>>>>> After some additional testing I changed the fix a bit. Please take >>>>>>>> a look at new version. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>>> >>>>>>>> New version reports JVMTI error to stderr. >>>>>>>> >>>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>> Thank you for the explanation! Serguei >>>>>>>>> >>>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>>> Serguei, >>>>>>>>>> >>>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>>> handling. >>>>>>>>>> >>>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>>> crash (one such crash was discovered and fixed) but just return >>>>>>>>>> non-zero exit code to upper level. >>>>>>>>>> >>>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>>> >>>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>>>>>> transport. >>>>>>>>>> >>>>>>>>>> So there is the fix. >>>>>>>>>> >>>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>>> without crash, right? >>>>>>>>>>> >>>>>>>>>>> Thanks, Serguei >>>>>>>>>>> >>>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>> >>>>>>>>>>>> Please review the fix: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>>> >>>>>>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>>>>>> remove this code. >>>>>>>>>>>> >>>>>>>>>>>> -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. >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the >>>>>> sources. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Aug 27 08:08:04 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 01:08:04 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FD8A8C.4050808@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> <53FCEC83.2040009@oracle.com> <53FD8A8C.4050808@oracle.com> Message-ID: <53FD91E4.3040807@oracle.com> This looks good. Could you, please, remove extra spaces in the following conditions ?: 1291 if (error != JVMTI_ERROR_NONE && docoredump ) { 1302 if ( gdata->jvmti != NULL ) { 1309 if ( error == JVMTI_ERROR_NONE ) { Thanks, Serguei On 8/27/14 12:36 AM, Dmitry Samersoff wrote: > Serguei, > > http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.04/ > > I refactored the debugInit_exit function. > > Now we have separate exit code for transport error and better readable > code. > > -Dmitry > > > On 2014-08-27 00:22, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> It makes sense to consider a special exit code for transport init error. >> Other than that it looks good. >> No need to re-review. >> >> Thanks, >> Serguei >> >> On 8/26/14 10:46 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> exit_code set to 1 at ll. 1288 >>> >>> I thought of refactoring this code for better readability but finally >>> decide to keep changes minimal. >>> >>> -Dmitry >>> >>> >>> On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: >>>> Dmitry, >>>> >>>> This looks good in general. >>>> But what error code will be returned in the case of >>>> AGENT_ERROR_TRANSPORT_INIT ? >>>> Is it Ok to return whatever exit_code we already have or we better >>>> return some special error code? >>>> >>>> Probably, it is Ok to keep the comment at the line 1315 as it is. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>>>> Staffan, >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>>>> >>>>> After couple of experiments I end up with simple fix - don't >>>>> coredump on >>>>> AGENT_ERROR_TRANSPORT_INIT >>>>> >>>>> Current code don't propagate transport error to upper level, so if we >>>>> need fine grained control I'll rewrite transport initialization. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>>>>> >>>>> > wrote: >>>>>> >>>>>>> Staffan, >>>>>>> >>>>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> One problem with this fix is that debugInit_exit() is used from many >>>>>>>> places in the JDWP code. For some of these I think it still does >>>>>>>> make >>>>>>>> sense to receive a core dump for analysis. I agree that when parsing >>>>>>>> options, we do not need a core dump. >>>>>>> jdwp has explicit option to request a coredump at debugInit_exit(). >>>>>>> >>>>>>> Is it enough or I should create a more sophisticated fix ? >>>>>> I don?t think that is enough. Often a problem will happen and will not >>>>>> be reproducible. >>>>>> >>>>>> Maybe this code: >>>>>> >>>>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>>>> (arg.startCount == 0) && >>>>>> initOnStartup) { >>>>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports >>>>>> initialized"); >>>>>> } >>>>>> >>>>>> can use some variant of EXIT_ERROR that does not call fatalError() ? >>>>>> >>>>>> /Staffan >>>>>> >>>>>>> Actually, I don't think that coredump on every call to >>>>>>> jni_FatalError() >>>>>>> (see jni.cpp:726) is necessary but this hotspot code is here for 6 >>>>>>> years >>>>>>> and changing it probably out of scope of this fix. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Serguei, >>>>>>>>> >>>>>>>>> After some additional testing I changed the fix a bit. Please take >>>>>>>>> a look at new version. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>>>> >>>>>>>>> New version reports JVMTI error to stderr. >>>>>>>>> >>>>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Ok. >>>>>>>>>> >>>>>>>>>> Thank you for the explanation! Serguei >>>>>>>>>> >>>>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>>>> Serguei, >>>>>>>>>>> >>>>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>>>> handling. >>>>>>>>>>> >>>>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>>>> crash (one such crash was discovered and fixed) but just return >>>>>>>>>>> non-zero exit code to upper level. >>>>>>>>>>> >>>>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>>>> >>>>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>>>>>>> transport. >>>>>>>>>>> >>>>>>>>>>> So there is the fix. >>>>>>>>>>> >>>>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>>>> without crash, right? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, Serguei >>>>>>>>>>>> >>>>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the fix: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>>>> >>>>>>>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>>>>>>> remove this code. >>>>>>>>>>>>> >>>>>>>>>>>>> -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. >>>>>>> -- >>>>>>> Dmitry Samersoff >>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>> * I would love to change the world, but they won't give me the >>>>>>> sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Aug 27 08:12:04 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 01:12:04 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FD91E4.3040807@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> <53FCEC83.2040009@oracle.com> <53FD8A8C.4050808@oracle.com> <53FD91E4.3040807@oracle.com> Message-ID: <53FD92D4.2040509@oracle.com> 1284 enum exit_codes { EXIT_NO_ERRORS = 0, EXIT_TRANSPORT_ERROR, EXIT_JVMTI_ERROR }; I'd suggest to swap the positions of EXIT_TRANSPORT_ERROR and EXIT_JVMTI_ERROR in the enum to keep this as compatible to previous behavior as possible. Thanks, Serguei On 8/27/14 1:08 AM, serguei.spitsyn at oracle.com wrote: > This looks good. > > Could you, please, remove extra spaces in the following conditions ?: > > 1291 if (error != JVMTI_ERROR_NONE && docoredump ) { > 1302 if ( gdata->jvmti != NULL ) { > 1309 if ( error == JVMTI_ERROR_NONE ) { > > Thanks, > Serguei > > > On 8/27/14 12:36 AM, Dmitry Samersoff wrote: >> Serguei, >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.04/ >> >> I refactored the debugInit_exit function. >> >> Now we have separate exit code for transport error and better readable >> code. >> >> -Dmitry >> >> >> On 2014-08-27 00:22,serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> It makes sense to consider a special exit code for transport init error. >>> Other than that it looks good. >>> No need to re-review. >>> >>> Thanks, >>> Serguei >>> >>> On 8/26/14 10:46 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> exit_code set to 1 at ll. 1288 >>>> >>>> I thought of refactoring this code for better readability but finally >>>> decide to keep changes minimal. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-08-26 21:35,serguei.spitsyn at oracle.com wrote: >>>>> Dmitry, >>>>> >>>>> This looks good in general. >>>>> But what error code will be returned in the case of >>>>> AGENT_ERROR_TRANSPORT_INIT ? >>>>> Is it Ok to return whatever exit_code we already have or we better >>>>> return some special error code? >>>>> >>>>> Probably, it is Ok to keep the comment at the line 1315 as it is. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>>>>> Staffan, >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>>>>> >>>>>> After couple of experiments I end up with simple fix - don't >>>>>> coredump on >>>>>> AGENT_ERROR_TRANSPORT_INIT >>>>>> >>>>>> Current code don't propagate transport error to upper level, so if we >>>>>> need fine grained control I'll rewrite transport initialization. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>>>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> Staffan, >>>>>>>> >>>>>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>>>>> Dmitry, >>>>>>>>> >>>>>>>>> One problem with this fix is that debugInit_exit() is used from many >>>>>>>>> places in the JDWP code. For some of these I think it still does >>>>>>>>> make >>>>>>>>> sense to receive a core dump for analysis. I agree that when parsing >>>>>>>>> options, we do not need a core dump. >>>>>>>> jdwp has explicit option to request a coredump at debugInit_exit(). >>>>>>>> >>>>>>>> Is it enough or I should create a more sophisticated fix ? >>>>>>> I don?t think that is enough. Often a problem will happen and will not >>>>>>> be reproducible. >>>>>>> >>>>>>> Maybe this code: >>>>>>> >>>>>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>>>>> (arg.startCount == 0) && >>>>>>> initOnStartup) { >>>>>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports >>>>>>> initialized"); >>>>>>> } >>>>>>> >>>>>>> can use some variant of EXIT_ERROR that does not call fatalError() ? >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>>> Actually, I don't think that coredump on every call to >>>>>>>> jni_FatalError() >>>>>>>> (see jni.cpp:726) is necessary but this hotspot code is here for 6 >>>>>>>> years >>>>>>>> and changing it probably out of scope of this fix. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Serguei, >>>>>>>>>> >>>>>>>>>> After some additional testing I changed the fix a bit. Please take >>>>>>>>>> a look at new version. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>>>>> >>>>>>>>>> New version reports JVMTI error to stderr. >>>>>>>>>> >>>>>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2014-08-20 12:08,serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Ok. >>>>>>>>>>> >>>>>>>>>>> Thank you for the explanation! Serguei >>>>>>>>>>> >>>>>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>>>>> Serguei, >>>>>>>>>>>> >>>>>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>>>>> handling. >>>>>>>>>>>> >>>>>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>>>>> crash (one such crash was discovered and fixed) but just return >>>>>>>>>>>> non-zero exit code to upper level. >>>>>>>>>>>> >>>>>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>>>>> >>>>>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>>>>>>>> transport. >>>>>>>>>>>> >>>>>>>>>>>> So there is the fix. >>>>>>>>>>>> >>>>>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> On 2014-08-20 00:54,serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>>>>> without crash, right? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the fix: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>>>>>>>> remove this code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -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. >>>>>>>> -- >>>>>>>> Dmitry Samersoff >>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>> sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Wed Aug 27 08:48:03 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 27 Aug 2014 10:48:03 +0200 Subject: RFR: 8056143: java/lang/management/MemoryMXBean/LowMemoryTest.java leaves running process on Windows Message-ID: <53FD9B43.2010004@oracle.com> Hi all, Please review this patch to put the LowMemoryTest.java test in the ProblemLists.txt. It currently hangs and leaves processes running after the test run has completed. http://cr.openjdk.java.net/~stefank/8056143/webrev.00/ thanks, StefanK From chris.hegarty at oracle.com Wed Aug 27 08:48:43 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Aug 2014 09:48:43 +0100 Subject: RFR: 8056143: java/lang/management/MemoryMXBean/LowMemoryTest.java leaves running process on Windows In-Reply-To: <53FD9B43.2010004@oracle.com> References: <53FD9B43.2010004@oracle.com> Message-ID: <53FD9B6B.8050007@oracle.com> Reviewed. -Chris. On 27/08/14 09:48, Stefan Karlsson wrote: > Hi all, > > Please review this patch to put the LowMemoryTest.java test in the > ProblemLists.txt. It currently hangs and leaves processes running after > the test run has completed. > > http://cr.openjdk.java.net/~stefank/8056143/webrev.00/ > > thanks, > StefanK From stefan.karlsson at oracle.com Wed Aug 27 08:53:38 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 27 Aug 2014 10:53:38 +0200 Subject: RFR: 8056143: java/lang/management/MemoryMXBean/LowMemoryTest.java leaves running process on Windows In-Reply-To: <53FD9B6B.8050007@oracle.com> References: <53FD9B43.2010004@oracle.com> <53FD9B6B.8050007@oracle.com> Message-ID: <53FD9C92.5000406@oracle.com> Thanks. StefanK On 27/08/14 10:48, Chris Hegarty wrote: > Reviewed. > > -Chris. > > On 27/08/14 09:48, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to put the LowMemoryTest.java test in the >> ProblemLists.txt. It currently hangs and leaves processes running after >> the test run has completed. >> >> http://cr.openjdk.java.net/~stefank/8056143/webrev.00/ >> >> thanks, >> StefanK From fredrik.arvidsson at oracle.com Wed Aug 27 09:01:27 2014 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Wed, 27 Aug 2014 11:01:27 +0200 Subject: RFR(XS) : 8055755: Information about loaded dynamic libraries is wrong on MacOSX Message-ID: <53FD9E67.3090309@oracle.com> Please help me review the following small patch: Review - http://cr.openjdk.java.net/~farvidsson/8055755/ Bug - https://bugs.openjdk.java.net/browse/JDK-8055755 There is information about the problem and the solution added to the bug as a comment. Cheers /Fredrik From dmitry.samersoff at oracle.com Wed Aug 27 09:03:29 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Aug 2014 13:03:29 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FD92D4.2040509@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> <53FCEC83.2040009@oracle.com> <53FD8A8C.4050808@oracle.com> <53FD91E4.3040807@oracle.com> <53FD92D4.2040509@oracle.com> Message-ID: <53FD9EE1.8090701@oracle.com> Serguei, Fixed (in-place, press shift reload) -Dmitry On 2014-08-27 12:12, serguei.spitsyn at oracle.com wrote: > 1284 enum exit_codes { EXIT_NO_ERRORS = 0, EXIT_TRANSPORT_ERROR, EXIT_JVMTI_ERROR }; > > > I'd suggest to swap the positions of EXIT_TRANSPORT_ERROR and > EXIT_JVMTI_ERROR > in the enum to keep this as compatible to previous behavior as possible. > > Thanks, > Serguei > > > > On 8/27/14 1:08 AM, serguei.spitsyn at oracle.com wrote: >> This looks good. >> >> Could you, please, remove extra spaces in the following conditions ?: >> >> 1291 if (error != JVMTI_ERROR_NONE && docoredump ) { >> 1302 if ( gdata->jvmti != NULL ) { >> 1309 if ( error == JVMTI_ERROR_NONE ) { >> >> Thanks, >> Serguei >> >> >> On 8/27/14 12:36 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.04/ >>> >>> I refactored the debugInit_exit function. >>> >>> Now we have separate exit code for transport error and better readable >>> code. >>> >>> -Dmitry >>> >>> >>> On 2014-08-27 00:22, serguei.spitsyn at oracle.com wrote: >>>> Dmitry, >>>> >>>> It makes sense to consider a special exit code for transport init error. >>>> Other than that it looks good. >>>> No need to re-review. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 8/26/14 10:46 AM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> exit_code set to 1 at ll. 1288 >>>>> >>>>> I thought of refactoring this code for better readability but finally >>>>> decide to keep changes minimal. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: >>>>>> Dmitry, >>>>>> >>>>>> This looks good in general. >>>>>> But what error code will be returned in the case of >>>>>> AGENT_ERROR_TRANSPORT_INIT ? >>>>>> Is it Ok to return whatever exit_code we already have or we better >>>>>> return some special error code? >>>>>> >>>>>> Probably, it is Ok to keep the comment at the line 1315 as it is. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>>>>>> Staffan, >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>>>>>> >>>>>>> After couple of experiments I end up with simple fix - don't >>>>>>> coredump on >>>>>>> AGENT_ERROR_TRANSPORT_INIT >>>>>>> >>>>>>> Current code don't propagate transport error to upper level, so if we >>>>>>> need fine grained control I'll rewrite transport initialization. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>>>>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Staffan, >>>>>>>>> >>>>>>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>>>>>> Dmitry, >>>>>>>>>> >>>>>>>>>> One problem with this fix is that debugInit_exit() is used from many >>>>>>>>>> places in the JDWP code. For some of these I think it still does >>>>>>>>>> make >>>>>>>>>> sense to receive a core dump for analysis. I agree that when parsing >>>>>>>>>> options, we do not need a core dump. >>>>>>>>> jdwp has explicit option to request a coredump at debugInit_exit(). >>>>>>>>> >>>>>>>>> Is it enough or I should create a more sophisticated fix ? >>>>>>>> I don?t think that is enough. Often a problem will happen and will not >>>>>>>> be reproducible. >>>>>>>> >>>>>>>> Maybe this code: >>>>>>>> >>>>>>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>>>>>> (arg.startCount == 0) && >>>>>>>> initOnStartup) { >>>>>>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports >>>>>>>> initialized"); >>>>>>>> } >>>>>>>> >>>>>>>> can use some variant of EXIT_ERROR that does not call fatalError() ? >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>>> Actually, I don't think that coredump on every call to >>>>>>>>> jni_FatalError() >>>>>>>>> (see jni.cpp:726) is necessary but this hotspot code is here for 6 >>>>>>>>> years >>>>>>>>> and changing it probably out of scope of this fix. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Serguei, >>>>>>>>>>> >>>>>>>>>>> After some additional testing I changed the fix a bit. Please take >>>>>>>>>>> a look at new version. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> New version reports JVMTI error to stderr. >>>>>>>>>>> >>>>>>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Ok. >>>>>>>>>>>> >>>>>>>>>>>> Thank you for the explanation! Serguei >>>>>>>>>>>> >>>>>>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>>>>>> Serguei, >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>>>>>> handling. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>>>>>> crash (one such crash was discovered and fixed) but just return >>>>>>>>>>>>> non-zero exit code to upper level. >>>>>>>>>>>>> >>>>>>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>>>>>> >>>>>>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>>>>>>>>> transport. >>>>>>>>>>>>> >>>>>>>>>>>>> So there is the fix. >>>>>>>>>>>>> >>>>>>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>>>>>> >>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>> >>>>>>>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>>>>>> without crash, right? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review the fix: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>>>>>>>>> remove this code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -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. >>>>>>>>> -- >>>>>>>>> Dmitry Samersoff >>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>> sources. >> > -- 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 stefan.karlsson at oracle.com Wed Aug 27 09:10:30 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 27 Aug 2014 11:10:30 +0200 Subject: RFR: 8056143: java/lang/management/MemoryMXBean/LowMemoryTest.java leaves running process on Windows In-Reply-To: <53FD9B43.2010004@oracle.com> References: <53FD9B43.2010004@oracle.com> Message-ID: <53FDA086.8080201@oracle.com> I revoke this RFR. Bengt pointed out that I shouldn't use 8056143 to updated the problem list. I've created a new bug JDK-8056148 and will send out a new RFR. thanks, StefanK On 27/08/14 10:48, Stefan Karlsson wrote: > Hi all, > > Please review this patch to put the LowMemoryTest.java test in the > ProblemLists.txt. It currently hangs and leaves processes running > after the test run has completed. > > http://cr.openjdk.java.net/~stefank/8056143/webrev.00/ > > thanks, > StefanK From stefan.karlsson at oracle.com Wed Aug 27 09:11:36 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 27 Aug 2014 11:11:36 +0200 Subject: 8056148: Add java/lang/management/MemoryMXBean/LowMemoryTest.java to ProblemList.txt Message-ID: <53FDA0C8.6040007@oracle.com> Hi all, Please review this patch to put the LowMemoryTest.java test in the ProblemLists.txt. It currently hangs and leaves processes running after the test run has completed. http://cr.openjdk.java.net/~stefank/8056148/webrev.00/ thanks, StefanK From chris.hegarty at oracle.com Wed Aug 27 09:18:28 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Aug 2014 10:18:28 +0100 Subject: 8056148: Add java/lang/management/MemoryMXBean/LowMemoryTest.java to ProblemList.txt In-Reply-To: <53FDA0C8.6040007@oracle.com> References: <53FDA0C8.6040007@oracle.com> Message-ID: <53FDA264.6030207@oracle.com> Looks ok to me. -Chris. On 27/08/14 10:11, Stefan Karlsson wrote: > Hi all, > > Please review this patch to put the LowMemoryTest.java test in the > ProblemLists.txt. It currently hangs and leaves processes running after > the test run has completed. > > http://cr.openjdk.java.net/~stefank/8056148/webrev.00/ > > thanks, > StefanK > From serguei.spitsyn at oracle.com Wed Aug 27 10:25:19 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 03:25:19 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FD9EE1.8090701@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> <53FCEC83.2040009@oracle.com> <53FD8A8C.4050808@oracle.com> <53FD91E4.3040807@oracle.com> <53FD92D4.2040509@oracle.com> <53FD9EE1.8090701@oracle.com> Message-ID: <53FDB20F.8020709@oracle.com> One more minor comment. The indent in this file must be 4. Could you fix it? Thanks, Serguei On 8/27/14 2:03 AM, Dmitry Samersoff wrote: > Serguei, > > Fixed (in-place, press shift reload) > > -Dmitry > > > On 2014-08-27 12:12, serguei.spitsyn at oracle.com wrote: >> 1284 enum exit_codes { EXIT_NO_ERRORS = 0, EXIT_TRANSPORT_ERROR, EXIT_JVMTI_ERROR }; >> >> >> I'd suggest to swap the positions of EXIT_TRANSPORT_ERROR and >> EXIT_JVMTI_ERROR >> in the enum to keep this as compatible to previous behavior as possible. >> >> Thanks, >> Serguei >> >> >> >> On 8/27/14 1:08 AM, serguei.spitsyn at oracle.com wrote: >>> This looks good. >>> >>> Could you, please, remove extra spaces in the following conditions ?: >>> >>> 1291 if (error != JVMTI_ERROR_NONE && docoredump ) { >>> 1302 if ( gdata->jvmti != NULL ) { >>> 1309 if ( error == JVMTI_ERROR_NONE ) { >>> >>> Thanks, >>> Serguei >>> >>> >>> On 8/27/14 12:36 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.04/ >>>> >>>> I refactored the debugInit_exit function. >>>> >>>> Now we have separate exit code for transport error and better readable >>>> code. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-08-27 00:22, serguei.spitsyn at oracle.com wrote: >>>>> Dmitry, >>>>> >>>>> It makes sense to consider a special exit code for transport init error. >>>>> Other than that it looks good. >>>>> No need to re-review. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 8/26/14 10:46 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> exit_code set to 1 at ll. 1288 >>>>>> >>>>>> I thought of refactoring this code for better readability but finally >>>>>> decide to keep changes minimal. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: >>>>>>> Dmitry, >>>>>>> >>>>>>> This looks good in general. >>>>>>> But what error code will be returned in the case of >>>>>>> AGENT_ERROR_TRANSPORT_INIT ? >>>>>>> Is it Ok to return whatever exit_code we already have or we better >>>>>>> return some special error code? >>>>>>> >>>>>>> Probably, it is Ok to keep the comment at the line 1315 as it is. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>>>>>>> Staffan, >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>>>>>>> >>>>>>>> After couple of experiments I end up with simple fix - don't >>>>>>>> coredump on >>>>>>>> AGENT_ERROR_TRANSPORT_INIT >>>>>>>> >>>>>>>> Current code don't propagate transport error to upper level, so if we >>>>>>>> need fine grained control I'll rewrite transport initialization. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>>>>>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Staffan, >>>>>>>>>> >>>>>>>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>>>>>>> Dmitry, >>>>>>>>>>> >>>>>>>>>>> One problem with this fix is that debugInit_exit() is used from many >>>>>>>>>>> places in the JDWP code. For some of these I think it still does >>>>>>>>>>> make >>>>>>>>>>> sense to receive a core dump for analysis. I agree that when parsing >>>>>>>>>>> options, we do not need a core dump. >>>>>>>>>> jdwp has explicit option to request a coredump at debugInit_exit(). >>>>>>>>>> >>>>>>>>>> Is it enough or I should create a more sophisticated fix ? >>>>>>>>> I don?t think that is enough. Often a problem will happen and will not >>>>>>>>> be reproducible. >>>>>>>>> >>>>>>>>> Maybe this code: >>>>>>>>> >>>>>>>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>>>>>>> (arg.startCount == 0) && >>>>>>>>> initOnStartup) { >>>>>>>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports >>>>>>>>> initialized"); >>>>>>>>> } >>>>>>>>> >>>>>>>>> can use some variant of EXIT_ERROR that does not call fatalError() ? >>>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>>> Actually, I don't think that coredump on every call to >>>>>>>>>> jni_FatalError() >>>>>>>>>> (see jni.cpp:726) is necessary but this hotspot code is here for 6 >>>>>>>>>> years >>>>>>>>>> and changing it probably out of scope of this fix. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Serguei, >>>>>>>>>>>> >>>>>>>>>>>> After some additional testing I changed the fix a bit. Please take >>>>>>>>>>>> a look at new version. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>>>>>>> >>>>>>>>>>>> New version reports JVMTI error to stderr. >>>>>>>>>>>> >>>>>>>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Ok. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for the explanation! Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>>>>>>> Serguei, >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>>>>>>> handling. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>>>>>>> tests to OptionTest.java - these tests pass invalid parameters >>>>>>>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>>>>>>> crash (one such crash was discovered and fixed) but just return >>>>>>>>>>>>>> non-zero exit code to upper level. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>>>>>>> transport cause VM to coredump. Dumping multiple cores on busy >>>>>>>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>>>>>>> it's a good idea to dump core when invalid parameters passed to >>>>>>>>>>>>>> transport. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So there is the fix. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>>>>>>> without crash, right? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, Serguei >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review the fix: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> JDWP call jniFatalError if transport can't be initialized (e.g. wrong >>>>>>>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I see no reason for debugInit_exit to call jniFatalError so >>>>>>>>>>>>>>>> remove this code. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -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. >>>>>>>>>> -- >>>>>>>>>> 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 dmitry.samersoff at oracle.com Wed Aug 27 10:51:23 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Aug 2014 14:51:23 +0400 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FDB20F.8020709@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> <53FCEC83.2040009@oracle.com> <53FD8A8C.4050808@oracle.com> <53FD91E4.3040807@oracle.com> <53FD92D4.2040509@oracle.com> <53FD9EE1.8090701@oracle.com> <53FDB20F.8020709@oracle.com> Message-ID: <53FDB82B.1030808@oracle.com> Serguei, Fixed (in-place, press shift reload) -Dmitry On 2014-08-27 14:25, serguei.spitsyn at oracle.com wrote: > One more minor comment. > The indent in this file must be 4. > Could you fix it? > > Thanks, > Serguei > > On 8/27/14 2:03 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Fixed (in-place, press shift reload) >> >> -Dmitry >> >> >> On 2014-08-27 12:12, serguei.spitsyn at oracle.com wrote: >>> 1284 enum exit_codes { EXIT_NO_ERRORS = 0, EXIT_TRANSPORT_ERROR, >>> EXIT_JVMTI_ERROR }; >>> >>> >>> I'd suggest to swap the positions of EXIT_TRANSPORT_ERROR and >>> EXIT_JVMTI_ERROR >>> in the enum to keep this as compatible to previous behavior as possible. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 8/27/14 1:08 AM, serguei.spitsyn at oracle.com wrote: >>>> This looks good. >>>> >>>> Could you, please, remove extra spaces in the following conditions ?: >>>> >>>> 1291 if (error != JVMTI_ERROR_NONE && docoredump ) { >>>> 1302 if ( gdata->jvmti != NULL ) { >>>> 1309 if ( error == JVMTI_ERROR_NONE ) { >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 8/27/14 12:36 AM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.04/ >>>>> >>>>> I refactored the debugInit_exit function. >>>>> >>>>> Now we have separate exit code for transport error and better readable >>>>> code. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-08-27 00:22, serguei.spitsyn at oracle.com wrote: >>>>>> Dmitry, >>>>>> >>>>>> It makes sense to consider a special exit code for transport init >>>>>> error. >>>>>> Other than that it looks good. >>>>>> No need to re-review. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 8/26/14 10:46 AM, Dmitry Samersoff wrote: >>>>>>> Serguei, >>>>>>> >>>>>>> exit_code set to 1 at ll. 1288 >>>>>>> >>>>>>> I thought of refactoring this code for better readability but >>>>>>> finally >>>>>>> decide to keep changes minimal. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: >>>>>>>> Dmitry, >>>>>>>> >>>>>>>> This looks good in general. >>>>>>>> But what error code will be returned in the case of >>>>>>>> AGENT_ERROR_TRANSPORT_INIT ? >>>>>>>> Is it Ok to return whatever exit_code we already have or we better >>>>>>>> return some special error code? >>>>>>>> >>>>>>>> Probably, it is Ok to keep the comment at the line 1315 as it is. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>>>>>>>> Staffan, >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>>>>>>>> >>>>>>>>> After couple of experiments I end up with simple fix - don't >>>>>>>>> coredump on >>>>>>>>> AGENT_ERROR_TRANSPORT_INIT >>>>>>>>> >>>>>>>>> Current code don't propagate transport error to upper level, so >>>>>>>>> if we >>>>>>>>> need fine grained control I'll rewrite transport initialization. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>>>>>>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Staffan, >>>>>>>>>>> >>>>>>>>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>>>>>>>> Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> One problem with this fix is that debugInit_exit() is used >>>>>>>>>>>> from many >>>>>>>>>>>> places in the JDWP code. For some of these I think it still >>>>>>>>>>>> does >>>>>>>>>>>> make >>>>>>>>>>>> sense to receive a core dump for analysis. I agree that when >>>>>>>>>>>> parsing >>>>>>>>>>>> options, we do not need a core dump. >>>>>>>>>>> jdwp has explicit option to request a coredump at >>>>>>>>>>> debugInit_exit(). >>>>>>>>>>> >>>>>>>>>>> Is it enough or I should create a more sophisticated fix ? >>>>>>>>>> I don?t think that is enough. Often a problem will happen and >>>>>>>>>> will not >>>>>>>>>> be reproducible. >>>>>>>>>> >>>>>>>>>> Maybe this code: >>>>>>>>>> >>>>>>>>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>>>>>>>> (arg.startCount == 0) && >>>>>>>>>> initOnStartup) { >>>>>>>>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports >>>>>>>>>> initialized"); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> can use some variant of EXIT_ERROR that does not call >>>>>>>>>> fatalError() ? >>>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>>> Actually, I don't think that coredump on every call to >>>>>>>>>>> jni_FatalError() >>>>>>>>>>> (see jni.cpp:726) is necessary but this hotspot code is here >>>>>>>>>>> for 6 >>>>>>>>>>> years >>>>>>>>>>> and changing it probably out of scope of this fix. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> /Staffan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Serguei, >>>>>>>>>>>>> >>>>>>>>>>>>> After some additional testing I changed the fix a bit. >>>>>>>>>>>>> Please take >>>>>>>>>>>>> a look at new version. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>>>>>>>> >>>>>>>>>>>>> New version reports JVMTI error to stderr. >>>>>>>>>>>>> >>>>>>>>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>>>>>>>> >>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>> Ok. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for the explanation! Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>>>>>>>> Serguei, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>>>>>>>> handling. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>>>>>>>> tests to OptionTest.java - these tests pass invalid >>>>>>>>>>>>>>> parameters >>>>>>>>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>>>>>>>> crash (one such crash was discovered and fixed) but just >>>>>>>>>>>>>>> return >>>>>>>>>>>>>>> non-zero exit code to upper level. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>>>>>>>> transport cause VM to coredump. Dumping multiple cores on >>>>>>>>>>>>>>> busy >>>>>>>>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>>>>>>>> it's a good idea to dump core when invalid parameters >>>>>>>>>>>>>>> passed to >>>>>>>>>>>>>>> transport. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So there is the fix. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>>>>>>>> without crash, right? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, Serguei >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review the fix: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>> JDWP call jniFatalError if transport can't be initialized >>>>>>>>>>> (e.g. wrong >>>>>>>>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I see no reason for debugInit_exit to call >>>>>>>>>>>>>>>>> jniFatalError so >>>>>>>>>>>>>>>>> remove this code. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -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. >>>>>>>>>>> -- >>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>> sources. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Aug 27 10:53:09 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 03:53:09 -0700 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FDB82B.1030808@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> <53FCEC83.2040009@oracle.com> <53FD8A8C.4050808@oracle.com> <53FD91E4.3040807@oracle.com> <53FD92D4.2040509@oracle.com> <53FD9EE1.8090701@oracle.com> <53FDB20F.8020709@oracle.com> <53FDB82B.1030808@oracle.com> Message-ID: <53FDB895.5070108@oracle.com> Thanks! Serguei On 8/27/14 3:51 AM, Dmitry Samersoff wrote: > Serguei, > > Fixed (in-place, press shift reload) > > -Dmitry > > > On 2014-08-27 14:25, serguei.spitsyn at oracle.com wrote: >> One more minor comment. >> The indent in this file must be 4. >> Could you fix it? >> >> Thanks, >> Serguei >> >> On 8/27/14 2:03 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Fixed (in-place, press shift reload) >>> >>> -Dmitry >>> >>> >>> On 2014-08-27 12:12, serguei.spitsyn at oracle.com wrote: >>>> 1284 enum exit_codes { EXIT_NO_ERRORS = 0, EXIT_TRANSPORT_ERROR, >>>> EXIT_JVMTI_ERROR }; >>>> >>>> >>>> I'd suggest to swap the positions of EXIT_TRANSPORT_ERROR and >>>> EXIT_JVMTI_ERROR >>>> in the enum to keep this as compatible to previous behavior as possible. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 8/27/14 1:08 AM, serguei.spitsyn at oracle.com wrote: >>>>> This looks good. >>>>> >>>>> Could you, please, remove extra spaces in the following conditions ?: >>>>> >>>>> 1291 if (error != JVMTI_ERROR_NONE && docoredump ) { >>>>> 1302 if ( gdata->jvmti != NULL ) { >>>>> 1309 if ( error == JVMTI_ERROR_NONE ) { >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 8/27/14 12:36 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.04/ >>>>>> >>>>>> I refactored the debugInit_exit function. >>>>>> >>>>>> Now we have separate exit code for transport error and better readable >>>>>> code. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-08-27 00:22, serguei.spitsyn at oracle.com wrote: >>>>>>> Dmitry, >>>>>>> >>>>>>> It makes sense to consider a special exit code for transport init >>>>>>> error. >>>>>>> Other than that it looks good. >>>>>>> No need to re-review. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 8/26/14 10:46 AM, Dmitry Samersoff wrote: >>>>>>>> Serguei, >>>>>>>> >>>>>>>> exit_code set to 1 at ll. 1288 >>>>>>>> >>>>>>>> I thought of refactoring this code for better readability but >>>>>>>> finally >>>>>>>> decide to keep changes minimal. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Dmitry, >>>>>>>>> >>>>>>>>> This looks good in general. >>>>>>>>> But what error code will be returned in the case of >>>>>>>>> AGENT_ERROR_TRANSPORT_INIT ? >>>>>>>>> Is it Ok to return whatever exit_code we already have or we better >>>>>>>>> return some special error code? >>>>>>>>> >>>>>>>>> Probably, it is Ok to keep the comment at the line 1315 as it is. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>>>>>>>>> Staffan, >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>>>>>>>>> >>>>>>>>>> After couple of experiments I end up with simple fix - don't >>>>>>>>>> coredump on >>>>>>>>>> AGENT_ERROR_TRANSPORT_INIT >>>>>>>>>> >>>>>>>>>> Current code don't propagate transport error to upper level, so >>>>>>>>>> if we >>>>>>>>>> need fine grained control I'll rewrite transport initialization. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>>>>>>>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Staffan, >>>>>>>>>>>> >>>>>>>>>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>>>>>>>>> Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> One problem with this fix is that debugInit_exit() is used >>>>>>>>>>>>> from many >>>>>>>>>>>>> places in the JDWP code. For some of these I think it still >>>>>>>>>>>>> does >>>>>>>>>>>>> make >>>>>>>>>>>>> sense to receive a core dump for analysis. I agree that when >>>>>>>>>>>>> parsing >>>>>>>>>>>>> options, we do not need a core dump. >>>>>>>>>>>> jdwp has explicit option to request a coredump at >>>>>>>>>>>> debugInit_exit(). >>>>>>>>>>>> >>>>>>>>>>>> Is it enough or I should create a more sophisticated fix ? >>>>>>>>>>> I don?t think that is enough. Often a problem will happen and >>>>>>>>>>> will not >>>>>>>>>>> be reproducible. >>>>>>>>>>> >>>>>>>>>>> Maybe this code: >>>>>>>>>>> >>>>>>>>>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>>>>>>>>> (arg.startCount == 0) && >>>>>>>>>>> initOnStartup) { >>>>>>>>>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports >>>>>>>>>>> initialized"); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> can use some variant of EXIT_ERROR that does not call >>>>>>>>>>> fatalError() ? >>>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>>> Actually, I don't think that coredump on every call to >>>>>>>>>>>> jni_FatalError() >>>>>>>>>>>> (see jni.cpp:726) is necessary but this hotspot code is here >>>>>>>>>>>> for 6 >>>>>>>>>>>> years >>>>>>>>>>>> and changing it probably out of scope of this fix. >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> /Staffan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Serguei, >>>>>>>>>>>>>> >>>>>>>>>>>>>> After some additional testing I changed the fix a bit. >>>>>>>>>>>>>> Please take >>>>>>>>>>>>>> a look at new version. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> New version reports JVMTI error to stderr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>> Ok. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for the explanation! Serguei >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>>>>>>>>> Serguei, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>>>>>>>>> handling. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>>>>>>>>> tests to OptionTest.java - these tests pass invalid >>>>>>>>>>>>>>>> parameters >>>>>>>>>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>>>>>>>>> crash (one such crash was discovered and fixed) but just >>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>> non-zero exit code to upper level. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>>>>>>>>> transport cause VM to coredump. Dumping multiple cores on >>>>>>>>>>>>>>>> busy >>>>>>>>>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>>>>>>>>> it's a good idea to dump core when invalid parameters >>>>>>>>>>>>>>>> passed to >>>>>>>>>>>>>>>> transport. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So there is the fix. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>>>>>>>>> without crash, right? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, Serguei >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please review the fix: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> JDWP call jniFatalError if transport can't be initialized >>>>>>>>>>>> (e.g. wrong >>>>>>>>>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I see no reason for debugInit_exit to call >>>>>>>>>>>>>>>>>> jniFatalError so >>>>>>>>>>>>>>>>>> remove this code. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -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. >>>>>>>>>>>> -- >>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>>> sources. > From serguei.spitsyn at oracle.com Wed Aug 27 11:29:36 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 04:29:36 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F5233E.2070508@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F5233E.2070508@oracle.com> Message-ID: <53FDC120.5060203@oracle.com> Dan, Sorry for the big delay in reply... It is because I did not have my arguments ready. :( Please, see below. On 8/20/14 3:37 PM, Daniel D. Daugherty wrote: > On 8/20/14 9:54 AM, Coleen Phillimore wrote: >> >> Hi, it appears that my code is wrong and maybe the existing code is >> wrong also. I have a spec question below. > > Rely embedded below... > > >> >> On 8/19/14, 7:52 PM, serguei.spitsyn at oracle.com wrote: >>> On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: >>>> >>>> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >>>>> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>>>>> Summary: Use scratch_class to find EMCP methods for breakpoints >>>>>> if the old methods are still running >>>>>> >>>>>> See bug for more details. This fix also includes a change to >>>>>> nmethod::metadata_do() to not walk the _method multiple times >>>>>> (the _method is added to the metadata section of the nmethod), >>>>>> and an attempt to help the sweeper clean up these scratch_class >>>>>> instance classes sooner. >>>>>> >>>>>> Tested with nsk tests, java/lang/instrument tests and jck tests >>>>>> (which include some jvmti tests). >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >>>>> >>>>> src/share/vm/oops/instanceKlass.hpp >>>>> line 1047 // RedefineClass support >>>>> Should be 'RedefineClasses'. >>>>> >>>>> line 1049: void mark_newly_obsolete_methods(Array* >>>>> old_methods, >>>>> int emcp_method_count); >>>>> The 'obsolete' part of the function name does not match with >>>>> the 'emcp' part of the parameter name. EMCP methods are >>>>> 'old', >>>>> but not 'obsolete'. >>>>> >>>>> Update: OK, I think I get it. We want to mark methods that >>>>> are >>>>> newly transitioning from EMCP -> obsolete and the >>>>> emcp_method_count >>>>> parameter tells us if there is any work to do. >>>>> >>>>> src/share/vm/oops/instanceKlass.cpp >>>>> line 3023: } // pvw is cleaned up >>>>> 'pvw' no longer exists so comment is stale. >>>>> >>>>> line 3455: // check the previous versions array >>>>> This comment should move above this line: >>>>> >>>>> 3453 for (; pv_node != NULL; ) { >>>>> >>>>> and 'array' should change to 'list'. >>>>> >>>>> Sorry for the bad placement of the original comment. >>>>> >>>>> line 3463: last->link_previous_versions(pv_node); >>>>> So now we've overwritten the previous value of >>>>> last->previous_versions. How does that InstanceKlass >>>>> get freed? Maybe a short comment? >>>>> >>>>> line 3484: // Mark the emcp method as obsolete if it's not >>>>> executing >>>>> I'm not sure about whether this is a good idea. When we had a >>>>> redefine make a method obsolete before, we knew that we could >>>>> make all older but previously EMCP methods obsolete because >>>>> the new method version did make them obsolete. >>>>> >>>>> With this optimization, we're saying that no thread is >>>>> executing >>>>> the method so we're going to make it obsolete even if the >>>>> current >>>>> redefine did not do so. I worry about a method call that >>>>> is in >>>>> the early stages of assembling the call stack being caught >>>>> calling a method that is now obsolete but not because of a >>>>> redefine made it obsolete. Just FYI, one of the tracing flags >>>>> catches unexpected calls to obsolete methods today and it >>>>> does >>>>> catch the current system's legitimate race. >>>> >>>> JVM/TI has an isMethodObsolete() API: >>>> >>>> jvmtiError >>>> IsMethodObsolete(jvmtiEnv* env, >>>> jmethodID method, >>>> jboolean* is_obsolete_ptr) >>>> >>>> It would be possible for an agent to observe a method changing from >>>> not obsolete to obsolete when that's not expected. I suspect that >>>> this would be a spec violation. >>> >>> I agree that this looks like a spec violation. >>> The emcp methods by definition are non-obsolete, >>> or in opposite, the obsolete methods are non-emcp: >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods >>> >>> Old method versions may become obsolete, not emcp: >>> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses >>> >>> But maybe I'm missing something... >> >> If an EMCP method is not running, should we save it on a previous >> version list anyway so that we can make it obsolete if it's redefined >> and made obsolete? > > Interesting question. The problem with an EMCP method is that it might > not be running right now, but we could have a Java thread that's in > the process of invoking it that is stopped on a safepoint. We resume > the world and the Java thread finishes calling the EMCP method... > > It's really hard to catch in-progress uses of jmethodIDs and make > sure that the in-progress use switches from the EMCP method to the > latest version of the method. A rarely seen race, but it does happen... It has to be invariant that if an EMCP is not running at redefinition time then it has to be gone and can not become running in the future. Otherwise, everything becomes overcomplicated. This also means that non-running EMCP method can never be made obsolete. The JVMTI spec is clear about the jmethodIDs and obsolete methods: Obsolete Methods The functions |RetransformClasses| and |RedefineClasses| can cause new versions of methods to be installed. An original version of a method is considered equivalent to the new version if: * their bytecodes are the same except for indices into the constant pool and * the referenced constants are equal. An original method version which is not equivalent to the new method version is called obsolete and is assigned a new method ID; the original method ID now refers to the new method version. A method ID can be tested for obsolescence with |IsMethodObsolete| . From the above, it seems that the EMCP methods do not get new jmethodIDs. It means that any use of jmethodID that referred to the EMCP method before the redefinition after redefinition should refer to the new (non-EMCP) method version. We must treat it as a bug if this invariant is broken. However, if an EMCP method is already running (there is a frame on the stack) then it can not be replaced with the new method version. Next redefinition can make such EMCP method to become obsolete, and so, it should get new methodID if it is still running. > > >> Currently we don't save previous versions of methods that are not >> running. We didn't before permgen elimination either. If GC didn't >> find the EMCP method, we would remove the entry. > > Not quite true for the pre-PermGen-Removal (PGR) world. We used to > save weak refs for all of the EMCP methods in the previous version > info. As the EMCP methods became collectible we removed them from > the previous version info. This means if GC could find the EMCP > method anywhere (stack, jmethodID, JNI handle, etc), then it stayed > alive. This means that even if no thread was currently executing > an EMCP method, an in-progress call to that method could still > complete and poof now we have the EMCP method back on a stack > somewhere... Do we have any test that demonstrate this behavior? Should we treat this behavior as a bug? If we decide to treat it as a bug then is it possible to fix such issues? Thanks, Serguei > > Dan > > >> >> Thanks, >> Coleen >> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> line 3527: // clear out any matching EMCP method entries the >>>>> hard way. >>>>> Perhaps "mark" instead of "clear out"? >>>>> >>>>> old line 3659: if (!method->is_obsolete() && >>>>> new line 3546: if (method->is_emcp() && >>>>> The old code is correct. The old code won't remark a >>>>> method that >>>>> was already made obsolete so there won't be more than one >>>>> trace >>>>> message for that operation. >>>>> >>>>> line 3581: // stack, and set emcp methods on the stack. >>>>> In comments 'emcp' should be 'EMCP'. We did not do that in >>>>> the >>>>> code because of HotSpot's variable name style. >>>>> >>>>> Also, set what on EMCP methods on the stack? >>>>> >>>>> line 3591: ... If emcp method from >>>>> line 3592: // a previous redefinition may be made obsolete by >>>>> this redefinition. >>>>> Having trouble parsing this comment. >>>>> >>>>> src/share/vm/oops/method.hpp >>>>> line 693: // emcp methods (equivalent method except constant >>>>> pool is different) >>>>> line 694: // that are old but not obsolete or deleted. >>>>> Perhaps: >>>>> >>>>> // EMCP methods are old but not obsolete or deleted. >>>>> Equivalent >>>>> // Modulo Constant Pool means the method is equivalent except >>>>> // the constant pool and instructions that access the >>>>> constant >>>>> // pool might be different. >>>>> >>>>> src/share/vm/prims/jvmtiImpl.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/code/nmethod.cpp >>>>> So in the original code f(_method) was being called two extra >>>>> times? (once in the while-loop and once at the end) So I'm >>>>> guessing that f(_method) is properly called when the rest of >>>>> the metadata is handled in the nmethod (line 2085)? >>>>> >>>>> src/share/vm/memory/universe.cpp >>>>> No comments (resisting 'The Walking Dead' ref...) >>>>> >>>>> test/runtime/RedefineTests/RedefineFinalizer.java >>>>> No comments. >>>>> >>>>> test/runtime/RedefineTests/RedefineRunningMethods.java >>>>> line 44: " while (!stop) { count2++; }" + >>>>> line 53: while (!stop) { count1++; } >>>>> line 56: while (!stop) { count2++; } >>>>> >>>>> These may not behave well on OSes with bad threading >>>>> models. You might want to add a helper function that >>>>> sleeps for 10ms and have each of these loops call it >>>>> so the test more well behaved. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Aug 27 11:40:44 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 04:40:44 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F52521.1080309@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> Message-ID: <53FDC3BC.3030605@oracle.com> On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: > On 8/20/14 2:01 PM, Coleen Phillimore wrote: >> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>> If an EMCP method is not running, should we save it on a previous >>>> version list anyway so that we can make it obsolete if it's >>>> redefined and made obsolete? >>> >>> I hope, Dan will catch me if I'm wrong... >>> >>> I think, we should not. >>> An EMCP method can not be made obsolete if it is not running. >>> >> >> >> It should be this way otherwise we'd have to hang onto things forever. > > An EMCP method should only be made obsolete if a RedefineClasses() or > RetransformClasses() operation made it so. We should not be leveraging > off the obsolete-ness attribute to solve a life-cycle problem. > > In the pre-PGR world, we could trust GC to make a completely unused > EMCP method collectible and eventually our weak reference would go > away. Just because an EMCP method is not on a stack does not mean > that it is not used so we need a different way to determine whether > it is OK to no longer track an EMCP method. Most likely, you are right. But I'm not convinced yet. Sorry. A convincing point would be a test that shows this behavior. I understand that it is not an easy task to write such a test though. However, such a test would serve nicely if we want a different way to determine whether it is OK to no longer track an EMCP method. Thanks, Serguei > > >> >>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>> switch to updated webrev after it is ready. >> >> Yes, this is a good idea. I figured out why I made emcp methods >> obsolete, and I'm fixing that as well as Dan's comments. Thanks! > > Cool! I'm looking forward to the next review. > > Dan > > >> >> Coleen >> >>> >>> Thanks, >>> Serguei >> > From dmitry.samersoff at oracle.com Wed Aug 27 12:07:30 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Aug 2014 16:07:30 +0400 Subject: RFR(S): JDK-8054066 com/sun/jdi/DoubleAgentTest.java fails with timeout Message-ID: <53FDCA02.9060804@oracle.com> Please review testfix. http://cr.openjdk.java.net/~dsamersoff/JDK-8054066/webrev.01/ The test is rewritten to use testlibrary instead of custom code. -- 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 staffan.larsen at oracle.com Wed Aug 27 12:12:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 27 Aug 2014 14:12:07 +0200 Subject: RFR(XS) : 8055755: Information about loaded dynamic libraries is wrong on MacOSX In-Reply-To: <53FD9E67.3090309@oracle.com> References: <53FD9E67.3090309@oracle.com> Message-ID: <39A25BB0-2F9D-46BC-9519-60B7553EAB54@oracle.com> Looks good! Thanks, /Staffan On 27 aug 2014, at 11:01, Fredrik Arvidsson wrote: > Please help me review the following small patch: > > Review - http://cr.openjdk.java.net/~farvidsson/8055755/ > Bug - https://bugs.openjdk.java.net/browse/JDK-8055755 > > There is information about the problem and the solution added to the bug as a comment. > > Cheers > > /Fredrik From staffan.larsen at oracle.com Wed Aug 27 12:53:17 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 27 Aug 2014 14:53:17 +0200 Subject: RFR(S): JDK-8054066 com/sun/jdi/DoubleAgentTest.java fails with timeout In-Reply-To: <53FDCA02.9060804@oracle.com> References: <53FDCA02.9060804@oracle.com> Message-ID: <679A3869-4075-4C48-AFFD-862FA89102D8@oracle.com> Looks good! Thanks, /Staffan On 27 aug 2014, at 14:07, Dmitry Samersoff wrote: > Please review testfix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8054066/webrev.01/ > > The test is rewritten to use testlibrary instead of custom code. > > -- > 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 staffan.larsen at oracle.com Wed Aug 27 13:00:29 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 27 Aug 2014 15:00:29 +0200 Subject: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again In-Reply-To: <53FDB82B.1030808@oracle.com> References: <53F3A101.4050506@oracle.com> <53F3B99E.7090203@oracle.com> <53F455DA.7070405@oracle.com> <53F45797.4040509@oracle.com> <53F4C4DC.9090903@oracle.com> <5C6603EB-A5FC-4015-868E-ECB92D81FFAA@oracle.com> <53FB1F12.7090407@oracle.com> <86BB55CF-662B-4BA4-9159-9A387F4E15CA@oracle.com> <53FC9E17.1090902@oracle.com> <53FCC57E.5030706@oracle.com> <53FCC7E5.2010305@oracle.com> <53FCEC83.2040009@oracle.com> <53FD8A8C.4050808@oracle.com> <53FD91E4.3040807@oracle.com> <53FD92D4.2040509@oracle.com> <53FD9EE1.8090701@oracle.com> <53FDB20F.8020709@oracle.com> <53FDB82B.1030808@oracle.com> Message-ID: This version looks good. Reviewed. /Staffan On 27 aug 2014, at 12:51, Dmitry Samersoff wrote: > Serguei, > > Fixed (in-place, press shift reload) > > -Dmitry > > > On 2014-08-27 14:25, serguei.spitsyn at oracle.com wrote: >> One more minor comment. >> The indent in this file must be 4. >> Could you fix it? >> >> Thanks, >> Serguei >> >> On 8/27/14 2:03 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Fixed (in-place, press shift reload) >>> >>> -Dmitry >>> >>> >>> On 2014-08-27 12:12, serguei.spitsyn at oracle.com wrote: >>>> 1284 enum exit_codes { EXIT_NO_ERRORS = 0, EXIT_TRANSPORT_ERROR, >>>> EXIT_JVMTI_ERROR }; >>>> >>>> >>>> I'd suggest to swap the positions of EXIT_TRANSPORT_ERROR and >>>> EXIT_JVMTI_ERROR >>>> in the enum to keep this as compatible to previous behavior as possible. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 8/27/14 1:08 AM, serguei.spitsyn at oracle.com wrote: >>>>> This looks good. >>>>> >>>>> Could you, please, remove extra spaces in the following conditions ?: >>>>> >>>>> 1291 if (error != JVMTI_ERROR_NONE && docoredump ) { >>>>> 1302 if ( gdata->jvmti != NULL ) { >>>>> 1309 if ( error == JVMTI_ERROR_NONE ) { >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 8/27/14 12:36 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.04/ >>>>>> >>>>>> I refactored the debugInit_exit function. >>>>>> >>>>>> Now we have separate exit code for transport error and better readable >>>>>> code. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-08-27 00:22, serguei.spitsyn at oracle.com wrote: >>>>>>> Dmitry, >>>>>>> >>>>>>> It makes sense to consider a special exit code for transport init >>>>>>> error. >>>>>>> Other than that it looks good. >>>>>>> No need to re-review. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 8/26/14 10:46 AM, Dmitry Samersoff wrote: >>>>>>>> Serguei, >>>>>>>> >>>>>>>> exit_code set to 1 at ll. 1288 >>>>>>>> >>>>>>>> I thought of refactoring this code for better readability but >>>>>>>> finally >>>>>>>> decide to keep changes minimal. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-08-26 21:35, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Dmitry, >>>>>>>>> >>>>>>>>> This looks good in general. >>>>>>>>> But what error code will be returned in the case of >>>>>>>>> AGENT_ERROR_TRANSPORT_INIT ? >>>>>>>>> Is it Ok to return whatever exit_code we already have or we better >>>>>>>>> return some special error code? >>>>>>>>> >>>>>>>>> Probably, it is Ok to keep the comment at the line 1315 as it is. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 8/26/14 7:47 AM, Dmitry Samersoff wrote: >>>>>>>>>> Staffan, >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.03/ >>>>>>>>>> >>>>>>>>>> After couple of experiments I end up with simple fix - don't >>>>>>>>>> coredump on >>>>>>>>>> AGENT_ERROR_TRANSPORT_INIT >>>>>>>>>> >>>>>>>>>> Current code don't propagate transport error to upper level, so >>>>>>>>>> if we >>>>>>>>>> need fine grained control I'll rewrite transport initialization. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2014-08-25 15:53, Staffan Larsen wrote: >>>>>>>>>>> On 25 aug 2014, at 13:33, Dmitry Samersoff >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Staffan, >>>>>>>>>>>> >>>>>>>>>>>> On 2014-08-25 15:26, Staffan Larsen wrote: >>>>>>>>>>>>> Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> One problem with this fix is that debugInit_exit() is used >>>>>>>>>>>>> from many >>>>>>>>>>>>> places in the JDWP code. For some of these I think it still >>>>>>>>>>>>> does >>>>>>>>>>>>> make >>>>>>>>>>>>> sense to receive a core dump for analysis. I agree that when >>>>>>>>>>>>> parsing >>>>>>>>>>>>> options, we do not need a core dump. >>>>>>>>>>>> jdwp has explicit option to request a coredump at >>>>>>>>>>>> debugInit_exit(). >>>>>>>>>>>> >>>>>>>>>>>> Is it enough or I should create a more sophisticated fix ? >>>>>>>>>>> I don?t think that is enough. Often a problem will happen and >>>>>>>>>>> will not >>>>>>>>>>> be reproducible. >>>>>>>>>>> >>>>>>>>>>> Maybe this code: >>>>>>>>>>> >>>>>>>>>>> if ((arg.error != JDWP_ERROR(NONE)) && >>>>>>>>>>> (arg.startCount == 0) && >>>>>>>>>>> initOnStartup) { >>>>>>>>>>> EXIT_ERROR(map2jvmtiError(arg.error), "No transports >>>>>>>>>>> initialized"); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> can use some variant of EXIT_ERROR that does not call >>>>>>>>>>> fatalError() ? >>>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>>> Actually, I don't think that coredump on every call to >>>>>>>>>>>> jni_FatalError() >>>>>>>>>>>> (see jni.cpp:726) is necessary but this hotspot code is here >>>>>>>>>>>> for 6 >>>>>>>>>>>> years >>>>>>>>>>>> and changing it probably out of scope of this fix. >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> /Staffan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 20 aug 2014, at 17:55, Dmitry Samersoff >>>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Serguei, >>>>>>>>>>>>>> >>>>>>>>>>>>>> After some additional testing I changed the fix a bit. >>>>>>>>>>>>>> Please take >>>>>>>>>>>>>> a look at new version. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> New version reports JVMTI error to stderr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also jniFatalError is not referenced any more so I remove it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2014-08-20 12:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>> Ok. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for the explanation! Serguei >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 8/20/14 1:01 AM, Dmitry Samersoff wrote: >>>>>>>>>>>>>>>> Serguei, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. Historically JDI test-suite had no tests for failed >>>>>>>>>>>>>>>> transport initialization behavior and invalid parameters >>>>>>>>>>>>>>>> handling. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2. As a part of JDWP hardening work I added couple of such >>>>>>>>>>>>>>>> tests to OptionTest.java - these tests pass invalid >>>>>>>>>>>>>>>> parameters >>>>>>>>>>>>>>>> to dt_socket transport to make sure that transport doesn't >>>>>>>>>>>>>>>> crash (one such crash was discovered and fixed) but just >>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>> non-zero exit code to upper level. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3. After fix for JDK-6694099 any non-zero exit code from >>>>>>>>>>>>>>>> transport cause VM to coredump. Dumping multiple cores on >>>>>>>>>>>>>>>> busy >>>>>>>>>>>>>>>> machine takes a time so harness kills the test by timeout. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We can just increase timeout for this test but I don't think >>>>>>>>>>>>>>>> it's a good idea to dump core when invalid parameters >>>>>>>>>>>>>>>> passed to >>>>>>>>>>>>>>>> transport. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So there is the fix. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 4. After the fix tests for negative parameters will return >>>>>>>>>>>>>>>> non-zero exit code as expected but will not dump the core. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2014-08-20 00:54, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The fix seems to be Ok. Just want to make it clear... This >>>>>>>>>>>>>>>>> fix just changes the bug pattern. It a case of incorrect >>>>>>>>>>>>>>>>> transport parameters the test is still going to fail but >>>>>>>>>>>>>>>>> without crash, right? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, Serguei >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 8/19/14 12:09 PM, Dmitry Samersoff wrote: >>>>>>>>>>>>>>>>>> Hi Everybody, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please review the fix: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> JDWP call jniFatalError if transport can't be initialized >>>>>>>>>>>> (e.g. wrong >>>>>>>>>>>>>>>>>> parameters) and jniFatalError call os::abort(). Therefor >>>>>>>>>>>>>>>>>> all transport initialization errors cause vm to coredump. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I see no reason for debugInit_exit to call >>>>>>>>>>>>>>>>>> jniFatalError so >>>>>>>>>>>>>>>>>> remove this code. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -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. >>>>>>>>>>>> -- >>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>>> sources. >>> >> > > > -- > 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 daniel.daugherty at oracle.com Wed Aug 27 13:54:57 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 Aug 2014 07:54:57 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FDC3BC.3030605@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53FDC3BC.3030605@oracle.com> Message-ID: <53FDE331.9050502@oracle.com> On 8/27/14 5:40 AM, serguei.spitsyn at oracle.com wrote: > On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: >> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> If an EMCP method is not running, should we save it on a previous >>>>> version list anyway so that we can make it obsolete if it's >>>>> redefined and made obsolete? >>>> >>>> I hope, Dan will catch me if I'm wrong... >>>> >>>> I think, we should not. >>>> An EMCP method can not be made obsolete if it is not running. >>>> >>> >>> >>> It should be this way otherwise we'd have to hang onto things forever. >> >> An EMCP method should only be made obsolete if a RedefineClasses() or >> RetransformClasses() operation made it so. We should not be leveraging >> off the obsolete-ness attribute to solve a life-cycle problem. >> >> In the pre-PGR world, we could trust GC to make a completely unused >> EMCP method collectible and eventually our weak reference would go >> away. Just because an EMCP method is not on a stack does not mean >> that it is not used so we need a different way to determine whether >> it is OK to no longer track an EMCP method. > > Most likely, you are right. > But I'm not convinced yet. Sorry. > A convincing point would be a test that shows this behavior. > I understand that it is not an easy task to write such a test though. > However, such a test would serve nicely if we want a different way > to determine whether it is OK to no longer track an EMCP method. Running the Serviceability stack of tests with the following -XX:TraceRedefineClasses=NN flags: // 0x00001000 | 4096 - detect calls to obsolete methods // 0x00002000 | 8192 - fail a guarantee() in addition to detection will show failures of the guarantee(). I used to do this periodically and then chase down the failures to make sure only the "legitimate" races were happening. The reason that we had to add these flags was to find all the places where folks were caching methods in the VM. I think the last place I found and fixed was in reflection. Dan > > > Thanks, > Serguei > >> >> >>> >>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>> switch to updated webrev after it is ready. >>> >>> Yes, this is a good idea. I figured out why I made emcp methods >>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >> >> Cool! I'm looking forward to the next review. >> >> Dan >> >> >>> >>> Coleen >>> >>>> >>>> Thanks, >>>> Serguei >>> >> > From bengt.rutisson at oracle.com Wed Aug 27 14:15:21 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 27 Aug 2014 16:15:21 +0200 Subject: 8056148: Add java/lang/management/MemoryMXBean/LowMemoryTest.java to ProblemList.txt In-Reply-To: <53FDA0C8.6040007@oracle.com> References: <53FDA0C8.6040007@oracle.com> Message-ID: <53FDE7F9.7010101@oracle.com> Hi Stefan, Thanks for fixing the separate bug. Looks good. Bengt On 8/27/14 11:11 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to put the LowMemoryTest.java test in the > ProblemLists.txt. It currently hangs and leaves processes running > after the test run has completed. > > http://cr.openjdk.java.net/~stefank/8056148/webrev.00/ > > thanks, > StefanK > From bengt.rutisson at oracle.com Wed Aug 27 14:28:37 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 27 Aug 2014 16:28:37 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FC4A57.3030100@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> Message-ID: <53FDEB15.2070102@oracle.com> Hi Staffan, Overall I think this change looks fine. I know that Erik Helin has some thoughts on the naming of the events. I'll let him communicate those thoughts. Apart from Erik's comments and the missing test case (that I know you are working on) I think the change looks good. Thanks, Bengt On 8/26/14 10:50 AM, Bengt Rutisson wrote: > > Hi all, > > Staffan sent me an updated webrev based on Erik's comments. I uploaded > it here: > http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/ > > Thanks, > Bengt > > > On 2014-08-25 19:32, Staffan Friberg wrote: >> Hi Erik, >> >> No issue with naming the field class, since the event is similar to >> the Allocation event I used that as a starting point and it also uses >> class as name together with a couple of other events. >> >> Will go through the descriptions and remove periods. >> >> Object age is basically the how many times an object has been kept in >> survivor region, it is incremented each time a YC happens and the >> object is aged. >> Will see how I can update the description to make it clearer. Calling >> the field tenuringAge might help? >> >>> From the documentation, >>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >>> >>> -XX:MaxTenuringThreshold=/threshold/ >>> >>> Sets the maximum tenuring threshold for use in adaptive GC >>> sizing. The largest value is 15. The default value is 15 for the >>> parallel (throughput) collector, and 6 for the CMS collector. >>> >>> The following example shows how to set the maximum tenuring >>> threshold to 10: >>> >>> -XX:MaxTenuringThreshold=10 >>> >>> >>> -XX:+PrintTenuringDistribution >>> >>> Enables printing of tenuring age information. The following is >>> an example of the output: >>> >>> Desired survivor size 48286924 bytes, new threshold 10 (max 10) >>> - age 1: 28992024 bytes, 28992024 total >>> - age 2: 1366864 bytes, 30358888 total >>> - age 3: 1425912 bytes, 31784800 total >>> ... >>> >>> Age 1 objects are the youngest survivors (they were created >>> after the previous scavenge, survived the latest scavenge, and >>> moved from eden to survivor space). Age 2 objects have survived >>> two scavenges (during the second scavenge they were copied from >>> one survivor space to the next). And so on. >>> >>> In the preceding example, 28 992 024 bytes survived one scavenge >>> and were copied from eden to survivor space, 1 366 864 bytes are >>> occupied by age 2 objects, etc. The third value in each row is >>> the cumulative size of objects of age n or less. >>> >>> By default, this option is disabled. >>> >> >> Thanks for the comments, >> Staffan >> >> On 08/25/2014 09:55 AM, Erik Gahlin wrote: >>> Did you manage to call the field "class"? It's a reserved word in >>> C++, so we had to use "klass" in the past >>> >>> Descriptions with only one sentence shouldn't end with "." >>> >>> How is "Object Age" measured? >>> >>> As a user, I would expect the number to be in seconds/minutes/hours, >>> but that is not the case. Perhaps an explanation in the description >>> and/or a field name that better reflects what we really mean with age. >>> >>> Otherwise trace.xml looks good! >>> >>> Erik >>> >>> Staffan Friberg skrev 25/08/14 18:28: >>>> Hi, >>>> >>>> Could I please get reviews for this RFE that adds a trace event for >>>> aging and promotion for young collections in G1, CMS and Parallel GC. >>>> It works similarly to allocation events, and generates the event on >>>> the slow path when either a direct copy occurs or a new PLAB is >>>> request. >>>> >>>> Since I'm adding an event I cc:ed the serviceability list in case >>>> anyone has any comments on the event and changes to trace.xml. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>>> >>>> Bengt has been kind and agreed to both sponsor and host the the >>>> webrev. >>>> >>>> Thanks, >>>> Staffan >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.fazunenko at oracle.com Wed Aug 27 11:08:03 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 27 Aug 2014 15:08:03 +0400 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FB6432.1010501@oracle.com> References: <53FB6432.1010501@oracle.com> Message-ID: <53FDBC13.9030209@oracle.com> Hi Staffan, Thanks for submitting RFE and implementing it! This event seems to be used widely. So it's very important to design it correctly. May I ask you to provide some extra information: - format of event (this could be included in the CR description) - regression tests for that event will be also required - please include hotspot-dev on CC Thanks, Dima On 25.08.2014 20:28, Staffan Friberg wrote: > Hi, > > Could I please get reviews for this RFE that adds a trace event for > aging and promotion for young collections in G1, CMS and Parallel GC. > It works similarly to allocation events, and generates the event on > the slow path when either a direct copy occurs or a new PLAB is request. > > Since I'm adding an event I cc:ed the serviceability list in case > anyone has any comments on the event and changes to trace.xml. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 > Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 > > Bengt has been kind and agreed to both sponsor and host the the webrev. > > Thanks, > Staffan > From gerard.ziemski at oracle.com Wed Aug 27 16:27:49 2014 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 27 Aug 2014 11:27:49 -0500 Subject: RFR(XS) : 8055755: Information about loaded dynamic libraries is wrong on MacOSX In-Reply-To: <53FD9E67.3090309@oracle.com> References: <53FD9E67.3090309@oracle.com> Message-ID: <53FE0705.2080404@oracle.com> Thank you for fixing this. Please consider it reviewed (with lowercase r) cheers On 8/27/2014 4:01 AM, Fredrik Arvidsson wrote: > Please help me review the following small patch: > > Review - http://cr.openjdk.java.net/~farvidsson/8055755/ > Bug - https://bugs.openjdk.java.net/browse/JDK-8055755 > > There is information about the problem and the solution added to the > bug as a comment. > > Cheers > > /Fredrik > From staffan.friberg at oracle.com Wed Aug 27 16:52:26 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Wed, 27 Aug 2014 09:52:26 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FDBC13.9030209@oracle.com> References: <53FB6432.1010501@oracle.com> <53FDBC13.9030209@oracle.com> Message-ID: <53FE0CCA.6000208@oracle.com> HI Dima, The event is specified in trace.xml as all other events, please see the updated webrev as some changes was made to the descriptions. http://cr.openjdk.java.net/~brutisso/8055845/webrev.01 I'm in the process of writing regression tests, but they will be a separate webrev as they will be located in a separate repository. Regards, Staffan On 08/27/2014 04:08 AM, Dmitry Fazunenko wrote: > Hi Staffan, > > Thanks for submitting RFE and implementing it! This event seems to be > used widely. > So it's very important to design it correctly. > May I ask you to provide some extra information: > - format of event > (this could be included in the CR description) > - regression tests for that event will be also required > - please include hotspot-dev on CC > > Thanks, > Dima > > On 25.08.2014 20:28, Staffan Friberg wrote: >> Hi, >> >> Could I please get reviews for this RFE that adds a trace event for >> aging and promotion for young collections in G1, CMS and Parallel GC. >> It works similarly to allocation events, and generates the event on >> the slow path when either a direct copy occurs or a new PLAB is request. >> >> Since I'm adding an event I cc:ed the serviceability list in case >> anyone has any comments on the event and changes to trace.xml. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >> >> Bengt has been kind and agreed to both sponsor and host the the webrev. >> >> Thanks, >> Staffan >> > From dmitry.fazunenko at oracle.com Wed Aug 27 16:59:59 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 27 Aug 2014 20:59:59 +0400 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FE0CCA.6000208@oracle.com> References: <53FB6432.1010501@oracle.com> <53FDBC13.9030209@oracle.com> <53FE0CCA.6000208@oracle.com> Message-ID: <53FE0E8F.30501@oracle.com> Staffan, Yes, I saw trace.xml. But I think this event not specified there, but implemented ) I will appreciate if you copy it in the message, people might review that and decide if the event contain all the necessary fields. And thank you for working on tests! -- Dima On 27.08.2014 20:52, Staffan Friberg wrote: > HI Dima, > > The event is specified in trace.xml as all other events, please see > the updated webrev as some changes was made to the descriptions. > http://cr.openjdk.java.net/~brutisso/8055845/webrev.01 > > I'm in the process of writing regression tests, but they will be a > separate webrev as they will be located in a separate repository. > > Regards, > Staffan > > On 08/27/2014 04:08 AM, Dmitry Fazunenko wrote: >> Hi Staffan, >> >> Thanks for submitting RFE and implementing it! This event seems to be >> used widely. >> So it's very important to design it correctly. >> May I ask you to provide some extra information: >> - format of event >> (this could be included in the CR description) >> - regression tests for that event will be also required >> - please include hotspot-dev on CC >> >> Thanks, >> Dima >> >> On 25.08.2014 20:28, Staffan Friberg wrote: >>> Hi, >>> >>> Could I please get reviews for this RFE that adds a trace event for >>> aging and promotion for young collections in G1, CMS and Parallel GC. >>> It works similarly to allocation events, and generates the event on >>> the slow path when either a direct copy occurs or a new PLAB is >>> request. >>> >>> Since I'm adding an event I cc:ed the serviceability list in case >>> anyone has any comments on the event and changes to trace.xml. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>> >>> Bengt has been kind and agreed to both sponsor and host the the webrev. >>> >>> Thanks, >>> Staffan >>> >> > From serguei.spitsyn at oracle.com Wed Aug 27 18:41:28 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 11:41:28 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FDE331.9050502@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53FDC3BC.3030605@oracle.com> <53FDE331.9050502@oracle.com> Message-ID: <53FE2658.1090302@oracle.com> On 8/27/14 6:54 AM, Daniel D. Daugherty wrote: > > On 8/27/14 5:40 AM, serguei.spitsyn at oracle.com wrote: >> On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: >>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>> If an EMCP method is not running, should we save it on a previous >>>>>> version list anyway so that we can make it obsolete if it's >>>>>> redefined and made obsolete? >>>>> >>>>> I hope, Dan will catch me if I'm wrong... >>>>> >>>>> I think, we should not. >>>>> An EMCP method can not be made obsolete if it is not running. >>>>> >>>> >>>> >>>> It should be this way otherwise we'd have to hang onto things forever. >>> >>> An EMCP method should only be made obsolete if a RedefineClasses() or >>> RetransformClasses() operation made it so. We should not be leveraging >>> off the obsolete-ness attribute to solve a life-cycle problem. >>> >>> In the pre-PGR world, we could trust GC to make a completely unused >>> EMCP method collectible and eventually our weak reference would go >>> away. Just because an EMCP method is not on a stack does not mean >>> that it is not used so we need a different way to determine whether >>> it is OK to no longer track an EMCP method. >> >> Most likely, you are right. >> But I'm not convinced yet. Sorry. >> A convincing point would be a test that shows this behavior. >> I understand that it is not an easy task to write such a test though. >> However, such a test would serve nicely if we want a different way >> to determine whether it is OK to no longer track an EMCP method. > > Running the Serviceability stack of tests with the following > -XX:TraceRedefineClasses=NN flags: > > // 0x00001000 | 4096 - detect calls to obsolete methods > // 0x00002000 | 8192 - fail a guarantee() in addition to > detection > > will show failures of the guarantee(). I used to do this > periodically and then chase down the failures to make sure > only the "legitimate" races were happening. The reason that > we had to add these flags was to find all the places where > folks were caching methods in the VM. I think the last place > I found and fixed was in reflection. Ok, thanks. We threat this as buggy behavior, right? Thanks, Serguei > > Dan > > >> >> >> Thanks, >> Serguei >> >>> >>> >>>> >>>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>>> switch to updated webrev after it is ready. >>>> >>>> Yes, this is a good idea. I figured out why I made emcp methods >>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>> >>> Cool! I'm looking forward to the next review. >>> >>> Dan >>> >>> >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >> > From daniel.daugherty at oracle.com Wed Aug 27 19:33:43 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 Aug 2014 13:33:43 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FE2658.1090302@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53FDC3BC.3030605@oracle.com> <53FDE331.9050502@oracle.com> <53FE2658.1090302@oracle.com> Message-ID: <53FE3297.6000006@oracle.com> On 8/27/14 12:41 PM, serguei.spitsyn at oracle.com wrote: > On 8/27/14 6:54 AM, Daniel D. Daugherty wrote: >> >> On 8/27/14 5:40 AM, serguei.spitsyn at oracle.com wrote: >>> On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: >>>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> If an EMCP method is not running, should we save it on a >>>>>>> previous version list anyway so that we can make it obsolete if >>>>>>> it's redefined and made obsolete? >>>>>> >>>>>> I hope, Dan will catch me if I'm wrong... >>>>>> >>>>>> I think, we should not. >>>>>> An EMCP method can not be made obsolete if it is not running. >>>>>> >>>>> >>>>> >>>>> It should be this way otherwise we'd have to hang onto things >>>>> forever. >>>> >>>> An EMCP method should only be made obsolete if a RedefineClasses() or >>>> RetransformClasses() operation made it so. We should not be leveraging >>>> off the obsolete-ness attribute to solve a life-cycle problem. >>>> >>>> In the pre-PGR world, we could trust GC to make a completely unused >>>> EMCP method collectible and eventually our weak reference would go >>>> away. Just because an EMCP method is not on a stack does not mean >>>> that it is not used so we need a different way to determine whether >>>> it is OK to no longer track an EMCP method. >>> >>> Most likely, you are right. >>> But I'm not convinced yet. Sorry. >>> A convincing point would be a test that shows this behavior. >>> I understand that it is not an easy task to write such a test though. >>> However, such a test would serve nicely if we want a different way >>> to determine whether it is OK to no longer track an EMCP method. >> >> Running the Serviceability stack of tests with the following >> -XX:TraceRedefineClasses=NN flags: >> >> // 0x00001000 | 4096 - detect calls to obsolete methods >> // 0x00002000 | 8192 - fail a guarantee() in addition to >> detection >> >> will show failures of the guarantee(). I used to do this >> periodically and then chase down the failures to make sure >> only the "legitimate" races were happening. The reason that >> we had to add these flags was to find all the places where >> folks were caching methods in the VM. I think the last place >> I found and fixed was in reflection. > > Ok, thanks. > We threat this as buggy behavior, right? Not necessarily. If it's because of a cached method that didn't get updated to the new version, then that's a bug. However, if it's because of a call that is in progress, then we have not considered that a bug in the past. I don't remember the exact details, but the dance is something like this: - jmethodID converted to methodHandle - call to methodHandle prepared: - methodHandle -> methodOop - parameters marshalled - methodOop converted to method impl - method called - somewhere in the middle of call sequence the method is redefined - jmethodID and methodHandle are updated to refer to the new method, but we already converted to the methodOop and the underlying method implementation for the final stages of the call - when we've actually called the now obsolete method, the guarantee() mentioned above fires and we have a false positive for the tracing code Of course, now that we don't have methodOops, maybe this doesn't happen anymore. I haven't done a test run with the above flags enabled in quite some time... Dan > > Thanks, > Serguei > >> >> Dan >> >> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> >>>>> >>>>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>>>> switch to updated webrev after it is ready. >>>>> >>>>> Yes, this is a good idea. I figured out why I made emcp methods >>>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>>> >>>> Cool! I'm looking forward to the next review. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>>> >>> >> > From fredrik.arvidsson at oracle.com Wed Aug 27 21:01:24 2014 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Wed, 27 Aug 2014 23:01:24 +0200 Subject: RFR(XS) : 8055755: Information about loaded dynamic libraries is wrong on MacOSX In-Reply-To: <53FE0705.2080404@oracle.com> References: <53FD9E67.3090309@oracle.com> <53FE0705.2080404@oracle.com> Message-ID: <53FE4724.9030109@oracle.com> Great guys and thanks. /Fredrik On 2014-08-27 18:27, Gerard Ziemski wrote: > Thank you for fixing this. Please consider it reviewed (with lowercase r) > > cheers > > On 8/27/2014 4:01 AM, Fredrik Arvidsson wrote: >> Please help me review the following small patch: >> >> Review - http://cr.openjdk.java.net/~farvidsson/8055755/ >> Bug - https://bugs.openjdk.java.net/browse/JDK-8055755 >> >> There is information about the problem and the solution added to the >> bug as a comment. >> >> Cheers >> >> /Fredrik >> > From coleen.phillimore at oracle.com Wed Aug 27 21:16:14 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Aug 2014 17:16:14 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FE3297.6000006@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53FDC3BC.3030605@oracle.com> <53FDE331.9050502@oracle.com> <53FE2658.1090302@oracle.com> <53FE3297.6000006@oracle.com> Message-ID: <53FE4A9E.8000903@oracle.com> On 8/27/14, 3:33 PM, Daniel D. Daugherty wrote: > On 8/27/14 12:41 PM, serguei.spitsyn at oracle.com wrote: >> On 8/27/14 6:54 AM, Daniel D. Daugherty wrote: >>> >>> On 8/27/14 5:40 AM, serguei.spitsyn at oracle.com wrote: >>>> On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: >>>>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> >>>>>>>> If an EMCP method is not running, should we save it on a >>>>>>>> previous version list anyway so that we can make it obsolete if >>>>>>>> it's redefined and made obsolete? >>>>>>> >>>>>>> I hope, Dan will catch me if I'm wrong... >>>>>>> >>>>>>> I think, we should not. >>>>>>> An EMCP method can not be made obsolete if it is not running. >>>>>>> >>>>>> >>>>>> >>>>>> It should be this way otherwise we'd have to hang onto things >>>>>> forever. >>>>> >>>>> An EMCP method should only be made obsolete if a RedefineClasses() or >>>>> RetransformClasses() operation made it so. We should not be >>>>> leveraging >>>>> off the obsolete-ness attribute to solve a life-cycle problem. >>>>> >>>>> In the pre-PGR world, we could trust GC to make a completely unused >>>>> EMCP method collectible and eventually our weak reference would go >>>>> away. Just because an EMCP method is not on a stack does not mean >>>>> that it is not used so we need a different way to determine whether >>>>> it is OK to no longer track an EMCP method. >>>> >>>> Most likely, you are right. >>>> But I'm not convinced yet. Sorry. >>>> A convincing point would be a test that shows this behavior. >>>> I understand that it is not an easy task to write such a test though. >>>> However, such a test would serve nicely if we want a different way >>>> to determine whether it is OK to no longer track an EMCP method. >>> >>> Running the Serviceability stack of tests with the following >>> -XX:TraceRedefineClasses=NN flags: >>> >>> // 0x00001000 | 4096 - detect calls to obsolete methods >>> // 0x00002000 | 8192 - fail a guarantee() in addition to >>> detection >>> >>> will show failures of the guarantee(). I used to do this >>> periodically and then chase down the failures to make sure >>> only the "legitimate" races were happening. The reason that >>> we had to add these flags was to find all the places where >>> folks were caching methods in the VM. I think the last place >>> I found and fixed was in reflection. >> >> Ok, thanks. >> We threat this as buggy behavior, right? > > Not necessarily. If it's because of a cached method that didn't > get updated to the new version, then that's a bug. However, if > it's because of a call that is in progress, then we have not > considered that a bug in the past. > > I don't remember the exact details, but the dance is something > like this: > > - jmethodID converted to methodHandle > - call to methodHandle prepared: > - methodHandle -> methodOop > - parameters marshalled > - methodOop converted to method impl > - method called > - somewhere in the middle of call sequence the > method is redefined > - jmethodID and methodHandle are updated to refer to the > new method, but we already converted to the methodOop > and the underlying method implementation for the final > stages of the call > - when we've actually called the now obsolete method, > the guarantee() mentioned above fires and we have a > false positive for the tracing code > > Of course, now that we don't have methodOops, maybe this > doesn't happen anymore. I haven't done a test run with the > above flags enabled in quite some time... Do you mean methodHandle or MethodHandle above? Or java_lang_reflect_Method? The methodOop in little m methodHandles are not updated to refer to the new method, and Method* isn't either, so that really hasn't changed. I'm not following the call sequence above. But yes, I believe we could get into javaCalls::call() with an method, stop for a safepoint, and end up calling an obsolete method. But that obsolete method is considered already running at that stage because the methodHandle logic marks it as such, so it's not considered a bug. I ran the tests with the -XX:TraceRedefineClasses=0x2000 and didn't get the guarantee though, but that doesn't mean much. I'm reading these mails in reverse... Thanks, Coleen > > Dan > > >> >> Thanks, >> Serguei >> >>> >>> Dan >>> >>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> >>>>>> >>>>>>> BTW, I'm reviewing the webrev too, but probably it'd be better >>>>>>> to switch to updated webrev after it is ready. >>>>>> >>>>>> Yes, this is a good idea. I figured out why I made emcp methods >>>>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>>>> >>>>> Cool! I'm looking forward to the next review. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > From erik.helin at oracle.com Thu Aug 28 09:27:16 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 28 Aug 2014 11:27:16 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FDEB15.2070102@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> Message-ID: <53FEF5F4.5060509@oracle.com> Hi Staffan, thanks for the patch, looks like a useful event! A few initial comments: - Aren't the events for promotion to the tenured generation (SerialOld) and the CMS generation missing? - We try to keep the trace dependency (the header file) in gcTraceSend.cpp, see the pattern for all the other events in gcTrace.cpp (they all have a "report" and a "send" function). - Would it make sense to differentiate, either by separate events or by a field in a event, between promotions to to-space and to the old generation? - The are two events for TLAB allocations, java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. What do you think about using two events for PLAB allocations as well: - java/object_alloc_in_new_PLAB - java/object_alloc_outside_PLAB - In PSPromotionManager, instead of utilizing the C++ friendship with PSScavenge, should we add a getter function for the gc_tracer? Thanks, Erik On 2014-08-27 16:28, Bengt Rutisson wrote: > > > Hi Staffan, > > Overall I think this change looks fine. I know that Erik Helin has some > thoughts on the naming of the events. I'll let him communicate those > thoughts. > > Apart from Erik's comments and the missing test case (that I know you > are working on) I think the change looks good. > > Thanks, > Bengt > > On 8/26/14 10:50 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Staffan sent me an updated webrev based on Erik's comments. I uploaded >> it here: >> http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/ >> >> Thanks, >> Bengt >> >> >> On 2014-08-25 19:32, Staffan Friberg wrote: >>> Hi Erik, >>> >>> No issue with naming the field class, since the event is similar to >>> the Allocation event I used that as a starting point and it also uses >>> class as name together with a couple of other events. >>> >>> Will go through the descriptions and remove periods. >>> >>> Object age is basically the how many times an object has been kept in >>> survivor region, it is incremented each time a YC happens and the >>> object is aged. >>> Will see how I can update the description to make it clearer. Calling >>> the field tenuringAge might help? >>> >>>> From the documentation, >>>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >>>> >>>> -XX:MaxTenuringThreshold=/threshold/ >>>> >>>> Sets the maximum tenuring threshold for use in adaptive GC >>>> sizing. The largest value is 15. The default value is 15 for the >>>> parallel (throughput) collector, and 6 for the CMS collector. >>>> >>>> The following example shows how to set the maximum tenuring >>>> threshold to 10: >>>> >>>> -XX:MaxTenuringThreshold=10 >>>> >>>> >>>> -XX:+PrintTenuringDistribution >>>> >>>> Enables printing of tenuring age information. The following is >>>> an example of the output: >>>> >>>> Desired survivor size 48286924 bytes, new threshold 10 (max 10) >>>> - age 1: 28992024 bytes, 28992024 total >>>> - age 2: 1366864 bytes, 30358888 total >>>> - age 3: 1425912 bytes, 31784800 total >>>> ... >>>> >>>> Age 1 objects are the youngest survivors (they were created >>>> after the previous scavenge, survived the latest scavenge, and >>>> moved from eden to survivor space). Age 2 objects have survived >>>> two scavenges (during the second scavenge they were copied from >>>> one survivor space to the next). And so on. >>>> >>>> In the preceding example, 28 992 024 bytes survived one scavenge >>>> and were copied from eden to survivor space, 1 366 864 bytes are >>>> occupied by age 2 objects, etc. The third value in each row is >>>> the cumulative size of objects of age n or less. >>>> >>>> By default, this option is disabled. >>>> >>> >>> Thanks for the comments, >>> Staffan >>> >>> On 08/25/2014 09:55 AM, Erik Gahlin wrote: >>>> Did you manage to call the field "class"? It's a reserved word in >>>> C++, so we had to use "klass" in the past >>>> >>>> Descriptions with only one sentence shouldn't end with "." >>>> >>>> How is "Object Age" measured? >>>> >>>> As a user, I would expect the number to be in seconds/minutes/hours, >>>> but that is not the case. Perhaps an explanation in the description >>>> and/or a field name that better reflects what we really mean with age. >>>> >>>> Otherwise trace.xml looks good! >>>> >>>> Erik >>>> >>>> Staffan Friberg skrev 25/08/14 18:28: >>>>> Hi, >>>>> >>>>> Could I please get reviews for this RFE that adds a trace event for >>>>> aging and promotion for young collections in G1, CMS and Parallel GC. >>>>> It works similarly to allocation events, and generates the event on >>>>> the slow path when either a direct copy occurs or a new PLAB is >>>>> request. >>>>> >>>>> Since I'm adding an event I cc:ed the serviceability list in case >>>>> anyone has any comments on the event and changes to trace.xml. >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>>>> >>>>> Bengt has been kind and agreed to both sponsor and host the the >>>>> webrev. >>>>> >>>>> Thanks, >>>>> Staffan >>>>> >>>> >>> >> > From fredrik.arvidsson at oracle.com Thu Aug 28 13:54:32 2014 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 28 Aug 2014 15:54:32 +0200 Subject: RFR (S): JDK-8056242: Add function to return structured information about loaded libraries. Message-ID: <53FF3498.70600@oracle.com> Hi Please help me review this small enhancement. Webrev: http://cr.openjdk.java.net/~farvidsson/8056242/webrev.00/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8056242 Cheers /F From staffan.larsen at oracle.com Thu Aug 28 14:21:25 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 28 Aug 2014 16:21:25 +0200 Subject: RFR (S): JDK-8056242: Add function to return structured information about loaded libraries. In-Reply-To: <53FF3498.70600@oracle.com> References: <53FF3498.70600@oracle.com> Message-ID: <6A0CFAF8-C21F-4284-ACB2-AF9AA9DE8E52@oracle.com> Hi Fredrik, A couple of comments: - I would prefer if the new callback was unified with the one that exists on Windows so that we have only on callback-based API for listing dynamic libraries. - If you do that, then would you also clean up enumerate_modules() on windows to get rid of the non-NT support? - Smaller: I think ?address? is a better type to use instead of ?u8?. Thanks /Staffan On 28 aug 2014, at 15:54, Fredrik Arvidsson wrote: > Hi > > Please help me review this small enhancement. > > Webrev: http://cr.openjdk.java.net/~farvidsson/8056242/webrev.00/index.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8056242 > > Cheers > /F From jaroslav.bachorik at oracle.com Thu Aug 28 15:57:43 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 28 Aug 2014 17:57:43 +0200 Subject: jmx-dev Review request: 8049303: Transient network problems cause JMX thread to fail silenty In-Reply-To: <53FBDB1A.2070501@oracle.com> References: <53FBDB1A.2070501@oracle.com> Message-ID: <53FF5177.7000700@oracle.com> I have taken over this issue from Poonam since she will be unavailable for the next month or so. Could I have reviews for this change: Bug: https://bugs.openjdk.java.net/browse/JDK-8049303 Webrev: http://cr.openjdk.java.net/~jbachorik/8049303/webrev.00 Problem and fix: By default the JMX client side notification fetch timeout (jmx.remote.x.notification.fetch.timeout) is 1 minute and the default server connection timeout (jmx.remote.x.server.connection.timeout) is 2 minutes. If the client side connector thread makes a notification fetch request to the server, but a transient network problem prevents the server response from reaching the client, the client side connector will wait for a response until the timeout period (1 minute) has expired before throwing an IOException. The client side RMIConnector implementation handles the IOException, by re-checking the connection status to understand whether or not it is broken. If the connection is not available at that moment, the connector fails by re-throwing the initial IOException. The problem is that this re-check of the connection passes because the server side of the connection doesn't time out until 2 minutes has passed (by default), so the NotifFetcher thread dies without posting a failed notification, and the client application does not get a chance to recover. The fix is to forward the non connection-related exceptions on the JMX client side instead of checking the connection status. The connection-related exceptions will cause closing the session as an unsuccessful connection check would have done. Testing: All the jdk_jmx and jdk_management regression tests passed. All the related JCK tests passed. The fix applies cleanly to 8u and 7u repos. Thanks, -JB- From staffan.friberg at oracle.com Thu Aug 28 21:15:44 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Thu, 28 Aug 2014 14:15:44 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FEF5F4.5060509@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> Message-ID: <53FF9C00.5040306@oracle.com> Hi Erik, Thanks for the comments. > - Aren't the events for promotion to the tenured generation (SerialOld) > and the CMS generation missing? The reason for leaving out these two, Serial completely and CMS promotion, was due to that neither as far as I understand make use of PLABs. So without a good sampling type of event it would end up being an event for each aging and/or promotion that happened in the GC. As this would be a very large number of events so I decided not to support those cases due to performance concerns. If you have a good idea on how to support it please let me know. I would see CMS as the priority of the two, client workloads can usually be analyzed with a different collector which might not be the case for a latency sensitive application. > - We try to keep the trace dependency (the header file) in > gcTraceSend.cpp, see the pattern for all the other events in > gcTrace.cpp (they all have a "report" and a "send" function). Will update it to follow that pattern. > - Would it make sense to differentiate, either by separate events or by > a field in a event, between promotions to to-space and to the old > generation? > - The are two events for TLAB allocations, > java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. > What do you think about using two events for PLAB allocations as well: > - java/object_alloc_in_new_PLAB > - java/object_alloc_outside_PLAB I think this is a matter of taste and probably how similar we want the event to be to the existing allocation event. I personally prefer a single event but if the GC team and serviceability team feel it would be better to have two I can certainly rewrite. The reason for me preferring a single event is just ease of analysis, you can easily filter a list of events on a field, it is harder to merge two different events with different fields and work with them in an straight forward fashion. Any general preference for having a single or multiple events? > - In PSPromotionManager, instead of utilizing the C++ friendship with > PSScavenge, should we add a getter function for the gc_tracer? Created a getter function. Will upload a new webrev shortly. //Staffan On 08/28/2014 02:27 AM, Erik Helin wrote: > Hi Staffan, > > thanks for the patch, looks like a useful event! > > A few initial comments: > - Aren't the events for promotion to the tenured generation (SerialOld) > and the CMS generation missing? > - We try to keep the trace dependency (the header file) in > gcTraceSend.cpp, see the pattern for all the other events in > gcTrace.cpp (they all have a "report" and a "send" function). > - Would it make sense to differentiate, either by separate events or by > a field in a event, between promotions to to-space and to the old > generation? > - The are two events for TLAB allocations, > java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. > What do you think about using two events for PLAB allocations as well: > - java/object_alloc_in_new_PLAB > - java/object_alloc_outside_PLAB > - In PSPromotionManager, instead of utilizing the C++ friendship with > PSScavenge, should we add a getter function for the gc_tracer? > > Thanks, > Erik > > On 2014-08-27 16:28, Bengt Rutisson wrote: >> >> >> Hi Staffan, >> >> Overall I think this change looks fine. I know that Erik Helin has some >> thoughts on the naming of the events. I'll let him communicate those >> thoughts. >> >> Apart from Erik's comments and the missing test case (that I know you >> are working on) I think the change looks good. >> >> Thanks, >> Bengt >> >> On 8/26/14 10:50 AM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Staffan sent me an updated webrev based on Erik's comments. I uploaded >>> it here: >>> http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/ >>> >>> Thanks, >>> Bengt >>> >>> >>> On 2014-08-25 19:32, Staffan Friberg wrote: >>>> Hi Erik, >>>> >>>> No issue with naming the field class, since the event is similar to >>>> the Allocation event I used that as a starting point and it also uses >>>> class as name together with a couple of other events. >>>> >>>> Will go through the descriptions and remove periods. >>>> >>>> Object age is basically the how many times an object has been kept in >>>> survivor region, it is incremented each time a YC happens and the >>>> object is aged. >>>> Will see how I can update the description to make it clearer. Calling >>>> the field tenuringAge might help? >>>> >>>>> From the documentation, >>>>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >>>>> >>>>> -XX:MaxTenuringThreshold=/threshold/ >>>>> >>>>> Sets the maximum tenuring threshold for use in adaptive GC >>>>> sizing. The largest value is 15. The default value is 15 for the >>>>> parallel (throughput) collector, and 6 for the CMS collector. >>>>> >>>>> The following example shows how to set the maximum tenuring >>>>> threshold to 10: >>>>> >>>>> -XX:MaxTenuringThreshold=10 >>>>> >>>>> >>>>> -XX:+PrintTenuringDistribution >>>>> >>>>> Enables printing of tenuring age information. The following is >>>>> an example of the output: >>>>> >>>>> Desired survivor size 48286924 bytes, new threshold 10 (max 10) >>>>> - age 1: 28992024 bytes, 28992024 total >>>>> - age 2: 1366864 bytes, 30358888 total >>>>> - age 3: 1425912 bytes, 31784800 total >>>>> ... >>>>> >>>>> Age 1 objects are the youngest survivors (they were created >>>>> after the previous scavenge, survived the latest scavenge, and >>>>> moved from eden to survivor space). Age 2 objects have survived >>>>> two scavenges (during the second scavenge they were copied from >>>>> one survivor space to the next). And so on. >>>>> >>>>> In the preceding example, 28 992 024 bytes survived one scavenge >>>>> and were copied from eden to survivor space, 1 366 864 bytes are >>>>> occupied by age 2 objects, etc. The third value in each row is >>>>> the cumulative size of objects of age n or less. >>>>> >>>>> By default, this option is disabled. >>>>> >>>> >>>> Thanks for the comments, >>>> Staffan >>>> >>>> On 08/25/2014 09:55 AM, Erik Gahlin wrote: >>>>> Did you manage to call the field "class"? It's a reserved word in >>>>> C++, so we had to use "klass" in the past >>>>> >>>>> Descriptions with only one sentence shouldn't end with "." >>>>> >>>>> How is "Object Age" measured? >>>>> >>>>> As a user, I would expect the number to be in seconds/minutes/hours, >>>>> but that is not the case. Perhaps an explanation in the description >>>>> and/or a field name that better reflects what we really mean with >>>>> age. >>>>> >>>>> Otherwise trace.xml looks good! >>>>> >>>>> Erik >>>>> >>>>> Staffan Friberg skrev 25/08/14 18:28: >>>>>> Hi, >>>>>> >>>>>> Could I please get reviews for this RFE that adds a trace event for >>>>>> aging and promotion for young collections in G1, CMS and Parallel >>>>>> GC. >>>>>> It works similarly to allocation events, and generates the event on >>>>>> the slow path when either a direct copy occurs or a new PLAB is >>>>>> request. >>>>>> >>>>>> Since I'm adding an event I cc:ed the serviceability list in case >>>>>> anyone has any comments on the event and changes to trace.xml. >>>>>> >>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>>>>> >>>>>> Bengt has been kind and agreed to both sponsor and host the the >>>>>> webrev. >>>>>> >>>>>> Thanks, >>>>>> Staffan >>>>>> >>>>> >>>> >>> >> From staffan.friberg at oracle.com Thu Aug 28 21:42:25 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Thu, 28 Aug 2014 14:42:25 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FF9C00.5040306@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> Message-ID: <53FFA241.5090303@oracle.com> Hi, I uploaded a new webrev here, http://cr.openjdk.java.net/~sfriberg/8055845/webrev.02 Uploaded under my own account since my key got updated, but kept the revision number going from the earlier uploads from Bengt (Thank You!). It contains suggested changes from Erik, as well as a bug fix in the G1 path where the age could be higher than the tenuring threshold due to a forwarding pointer having overwritten the field. This was not causing any issue in G1 as the object would never be copied in the end, but it made the tracing event look strange. Cheers, Staffan On 08/28/2014 02:15 PM, Staffan Friberg wrote: > Hi Erik, > > Thanks for the comments. >> - Aren't the events for promotion to the tenured generation (SerialOld) >> and the CMS generation missing? > The reason for leaving out these two, Serial completely and CMS > promotion, was due to that neither as far as I understand make use of > PLABs. So without a good sampling type of event it would end up being > an event for each aging and/or promotion that happened in the GC. As > this would be a very large number of events so I decided not to > support those cases due to performance concerns. If you have a good > idea on how to support it please let me know. I would see CMS as the > priority of the two, client workloads can usually be analyzed with a > different collector which might not be the case for a latency > sensitive application. > >> - We try to keep the trace dependency (the header file) in >> gcTraceSend.cpp, see the pattern for all the other events in >> gcTrace.cpp (they all have a "report" and a "send" function). > Will update it to follow that pattern. > >> - Would it make sense to differentiate, either by separate events or by >> a field in a event, between promotions to to-space and to the old >> generation? >> - The are two events for TLAB allocations, >> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >> What do you think about using two events for PLAB allocations as well: >> - java/object_alloc_in_new_PLAB >> - java/object_alloc_outside_PLAB > I think this is a matter of taste and probably how similar we want the > event to be to the existing allocation event. I personally prefer a > single event but if the GC team and serviceability team feel it would > be better to have two I can certainly rewrite. The reason for me > preferring a single event is just ease of analysis, you can easily > filter a list of events on a field, it is harder to merge two > different events with different fields and work with them in an > straight forward fashion. > > Any general preference for having a single or multiple events? > >> - In PSPromotionManager, instead of utilizing the C++ friendship with >> PSScavenge, should we add a getter function for the gc_tracer? > Created a getter function. > > Will upload a new webrev shortly. > > //Staffan > > On 08/28/2014 02:27 AM, Erik Helin wrote: >> Hi Staffan, >> >> thanks for the patch, looks like a useful event! >> >> A few initial comments: >> - Aren't the events for promotion to the tenured generation (SerialOld) >> and the CMS generation missing? >> - We try to keep the trace dependency (the header file) in >> gcTraceSend.cpp, see the pattern for all the other events in >> gcTrace.cpp (they all have a "report" and a "send" function). >> - Would it make sense to differentiate, either by separate events or by >> a field in a event, between promotions to to-space and to the old >> generation? >> - The are two events for TLAB allocations, >> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >> What do you think about using two events for PLAB allocations as well: >> - java/object_alloc_in_new_PLAB >> - java/object_alloc_outside_PLAB >> - In PSPromotionManager, instead of utilizing the C++ friendship with >> PSScavenge, should we add a getter function for the gc_tracer? >> >> Thanks, >> Erik >> >> On 2014-08-27 16:28, Bengt Rutisson wrote: >>> >>> >>> Hi Staffan, >>> >>> Overall I think this change looks fine. I know that Erik Helin has some >>> thoughts on the naming of the events. I'll let him communicate those >>> thoughts. >>> >>> Apart from Erik's comments and the missing test case (that I know you >>> are working on) I think the change looks good. >>> >>> Thanks, >>> Bengt >>> >>> On 8/26/14 10:50 AM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Staffan sent me an updated webrev based on Erik's comments. I uploaded >>>> it here: >>>> http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/ >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 2014-08-25 19:32, Staffan Friberg wrote: >>>>> Hi Erik, >>>>> >>>>> No issue with naming the field class, since the event is similar to >>>>> the Allocation event I used that as a starting point and it also uses >>>>> class as name together with a couple of other events. >>>>> >>>>> Will go through the descriptions and remove periods. >>>>> >>>>> Object age is basically the how many times an object has been kept in >>>>> survivor region, it is incremented each time a YC happens and the >>>>> object is aged. >>>>> Will see how I can update the description to make it clearer. Calling >>>>> the field tenuringAge might help? >>>>> >>>>>> From the documentation, >>>>>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >>>>>> >>>>>> -XX:MaxTenuringThreshold=/threshold/ >>>>>> >>>>>> Sets the maximum tenuring threshold for use in adaptive GC >>>>>> sizing. The largest value is 15. The default value is 15 for the >>>>>> parallel (throughput) collector, and 6 for the CMS collector. >>>>>> >>>>>> The following example shows how to set the maximum tenuring >>>>>> threshold to 10: >>>>>> >>>>>> -XX:MaxTenuringThreshold=10 >>>>>> >>>>>> >>>>>> -XX:+PrintTenuringDistribution >>>>>> >>>>>> Enables printing of tenuring age information. The following is >>>>>> an example of the output: >>>>>> >>>>>> Desired survivor size 48286924 bytes, new threshold 10 (max 10) >>>>>> - age 1: 28992024 bytes, 28992024 total >>>>>> - age 2: 1366864 bytes, 30358888 total >>>>>> - age 3: 1425912 bytes, 31784800 total >>>>>> ... >>>>>> >>>>>> Age 1 objects are the youngest survivors (they were created >>>>>> after the previous scavenge, survived the latest scavenge, and >>>>>> moved from eden to survivor space). Age 2 objects have survived >>>>>> two scavenges (during the second scavenge they were copied from >>>>>> one survivor space to the next). And so on. >>>>>> >>>>>> In the preceding example, 28 992 024 bytes survived one scavenge >>>>>> and were copied from eden to survivor space, 1 366 864 bytes are >>>>>> occupied by age 2 objects, etc. The third value in each row is >>>>>> the cumulative size of objects of age n or less. >>>>>> >>>>>> By default, this option is disabled. >>>>>> >>>>> >>>>> Thanks for the comments, >>>>> Staffan >>>>> >>>>> On 08/25/2014 09:55 AM, Erik Gahlin wrote: >>>>>> Did you manage to call the field "class"? It's a reserved word in >>>>>> C++, so we had to use "klass" in the past >>>>>> >>>>>> Descriptions with only one sentence shouldn't end with "." >>>>>> >>>>>> How is "Object Age" measured? >>>>>> >>>>>> As a user, I would expect the number to be in seconds/minutes/hours, >>>>>> but that is not the case. Perhaps an explanation in the description >>>>>> and/or a field name that better reflects what we really mean with >>>>>> age. >>>>>> >>>>>> Otherwise trace.xml looks good! >>>>>> >>>>>> Erik >>>>>> >>>>>> Staffan Friberg skrev 25/08/14 18:28: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please get reviews for this RFE that adds a trace event for >>>>>>> aging and promotion for young collections in G1, CMS and >>>>>>> Parallel GC. >>>>>>> It works similarly to allocation events, and generates the event on >>>>>>> the slow path when either a direct copy occurs or a new PLAB is >>>>>>> request. >>>>>>> >>>>>>> Since I'm adding an event I cc:ed the serviceability list in case >>>>>>> anyone has any comments on the event and changes to trace.xml. >>>>>>> >>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>>>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>>>>>> >>>>>>> Bengt has been kind and agreed to both sponsor and host the the >>>>>>> webrev. >>>>>>> >>>>>>> Thanks, >>>>>>> Staffan >>>>>>> >>>>>> >>>>> >>>> >>> > From erik.helin at oracle.com Fri Aug 29 06:34:39 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 29 Aug 2014 08:34:39 +0200 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <53FF9C00.5040306@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> Message-ID: <54001EFF.3030802@oracle.com> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in this thread, I'm adding it back) On 2014-08-28 23:15, Staffan Friberg wrote: > Hi Erik, > > Thanks for the comments. >> - Aren't the events for promotion to the tenured generation (SerialOld) >> and the CMS generation missing? > The reason for leaving out these two, Serial completely and CMS > promotion, was due to that neither as far as I understand make use of > PLABs. I might be wrong here, but looking at the function TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks to me like SerialOld is using PLABs when ParNew is promoting objects from young to old. As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote (in concurrentMarkSweepGeneration.cpp) it seems like each CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local Allocation Buffer) that is a thread-local allocation buffer. See compactibleFreeListSpace.{hpp,cpp} for more details. Given this, I think we should add events for Serial and CMS as well. On 2014-08-28 23:15, Staffan Friberg wrote: > So without a good sampling type of event it would end up being an > event for each aging and/or promotion that happened in the GC. As this > would be a very large number of events so I decided not to support those > cases due to performance concerns. If you have a good idea on how to > support it please let me know. I would see CMS as the priority of the > two, client workloads can usually be analyzed with a different collector > which might not be the case for a latency sensitive application. > >> - We try to keep the trace dependency (the header file) in >> gcTraceSend.cpp, see the pattern for all the other events in >> gcTrace.cpp (they all have a "report" and a "send" function). > Will update it to follow that pattern. Thanks! On 2014-08-28 23:15, Staffan Friberg wrote: >> - Would it make sense to differentiate, either by separate events or by >> a field in a event, between promotions to to-space and to the old >> generation? >> - The are two events for TLAB allocations, >> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >> What do you think about using two events for PLAB allocations as well: >> - java/object_alloc_in_new_PLAB >> - java/object_alloc_outside_PLAB > I think this is a matter of taste and probably how similar we want the > event to be to the existing allocation event. I personally prefer a > single event but if the GC team and serviceability team feel it would be > better to have two I can certainly rewrite. The reason for me preferring > a single event is just ease of analysis, you can easily filter a list of > events on a field, it is harder to merge two different events with > different fields and work with them in an straight forward fashion. > > Any general preference for having a single or multiple events? I would prefer to have two events in this case and try to follow the existing allocation events as much as possible (both in naming and in style). Keeping the tenured field (I missed it the first time I read the patch) is good. On 2014-08-28 23:15, Staffan Friberg wrote: >> - In PSPromotionManager, instead of utilizing the C++ friendship with >> PSScavenge, should we add a getter function for the gc_tracer? > Created a getter function. Thanks! If you make report_promotion_sample const, then the getter can return a const ParallelScavengeTracer*, right? Thanks, Erik > Will upload a new webrev shortly. > > //Staffan > > On 08/28/2014 02:27 AM, Erik Helin wrote: >> Hi Staffan, >> >> thanks for the patch, looks like a useful event! >> >> A few initial comments: >> - Aren't the events for promotion to the tenured generation (SerialOld) >> and the CMS generation missing? >> - We try to keep the trace dependency (the header file) in >> gcTraceSend.cpp, see the pattern for all the other events in >> gcTrace.cpp (they all have a "report" and a "send" function). >> - Would it make sense to differentiate, either by separate events or by >> a field in a event, between promotions to to-space and to the old >> generation? >> - The are two events for TLAB allocations, >> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >> What do you think about using two events for PLAB allocations as well: >> - java/object_alloc_in_new_PLAB >> - java/object_alloc_outside_PLAB >> - In PSPromotionManager, instead of utilizing the C++ friendship with >> PSScavenge, should we add a getter function for the gc_tracer? >> >> Thanks, >> Erik >> >> On 2014-08-27 16:28, Bengt Rutisson wrote: >>> >>> >>> Hi Staffan, >>> >>> Overall I think this change looks fine. I know that Erik Helin has some >>> thoughts on the naming of the events. I'll let him communicate those >>> thoughts. >>> >>> Apart from Erik's comments and the missing test case (that I know you >>> are working on) I think the change looks good. >>> >>> Thanks, >>> Bengt >>> >>> On 8/26/14 10:50 AM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Staffan sent me an updated webrev based on Erik's comments. I uploaded >>>> it here: >>>> http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/ >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 2014-08-25 19:32, Staffan Friberg wrote: >>>>> Hi Erik, >>>>> >>>>> No issue with naming the field class, since the event is similar to >>>>> the Allocation event I used that as a starting point and it also uses >>>>> class as name together with a couple of other events. >>>>> >>>>> Will go through the descriptions and remove periods. >>>>> >>>>> Object age is basically the how many times an object has been kept in >>>>> survivor region, it is incremented each time a YC happens and the >>>>> object is aged. >>>>> Will see how I can update the description to make it clearer. Calling >>>>> the field tenuringAge might help? >>>>> >>>>>> From the documentation, >>>>>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >>>>>> >>>>>> -XX:MaxTenuringThreshold=/threshold/ >>>>>> >>>>>> Sets the maximum tenuring threshold for use in adaptive GC >>>>>> sizing. The largest value is 15. The default value is 15 for the >>>>>> parallel (throughput) collector, and 6 for the CMS collector. >>>>>> >>>>>> The following example shows how to set the maximum tenuring >>>>>> threshold to 10: >>>>>> >>>>>> -XX:MaxTenuringThreshold=10 >>>>>> >>>>>> >>>>>> -XX:+PrintTenuringDistribution >>>>>> >>>>>> Enables printing of tenuring age information. The following is >>>>>> an example of the output: >>>>>> >>>>>> Desired survivor size 48286924 bytes, new threshold 10 (max 10) >>>>>> - age 1: 28992024 bytes, 28992024 total >>>>>> - age 2: 1366864 bytes, 30358888 total >>>>>> - age 3: 1425912 bytes, 31784800 total >>>>>> ... >>>>>> >>>>>> Age 1 objects are the youngest survivors (they were created >>>>>> after the previous scavenge, survived the latest scavenge, and >>>>>> moved from eden to survivor space). Age 2 objects have survived >>>>>> two scavenges (during the second scavenge they were copied from >>>>>> one survivor space to the next). And so on. >>>>>> >>>>>> In the preceding example, 28 992 024 bytes survived one scavenge >>>>>> and were copied from eden to survivor space, 1 366 864 bytes are >>>>>> occupied by age 2 objects, etc. The third value in each row is >>>>>> the cumulative size of objects of age n or less. >>>>>> >>>>>> By default, this option is disabled. >>>>>> >>>>> >>>>> Thanks for the comments, >>>>> Staffan >>>>> >>>>> On 08/25/2014 09:55 AM, Erik Gahlin wrote: >>>>>> Did you manage to call the field "class"? It's a reserved word in >>>>>> C++, so we had to use "klass" in the past >>>>>> >>>>>> Descriptions with only one sentence shouldn't end with "." >>>>>> >>>>>> How is "Object Age" measured? >>>>>> >>>>>> As a user, I would expect the number to be in seconds/minutes/hours, >>>>>> but that is not the case. Perhaps an explanation in the description >>>>>> and/or a field name that better reflects what we really mean with >>>>>> age. >>>>>> >>>>>> Otherwise trace.xml looks good! >>>>>> >>>>>> Erik >>>>>> >>>>>> Staffan Friberg skrev 25/08/14 18:28: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please get reviews for this RFE that adds a trace event for >>>>>>> aging and promotion for young collections in G1, CMS and Parallel >>>>>>> GC. >>>>>>> It works similarly to allocation events, and generates the event on >>>>>>> the slow path when either a direct copy occurs or a new PLAB is >>>>>>> request. >>>>>>> >>>>>>> Since I'm adding an event I cc:ed the serviceability list in case >>>>>>> anyone has any comments on the event and changes to trace.xml. >>>>>>> >>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>>>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>>>>>> >>>>>>> Bengt has been kind and agreed to both sponsor and host the the >>>>>>> webrev. >>>>>>> >>>>>>> Thanks, >>>>>>> Staffan >>>>>>> >>>>>> >>>>> >>>> >>> > From daniel.fuchs at oracle.com Fri Aug 29 09:25:51 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 Aug 2014 11:25:51 +0200 Subject: jmx-dev Review request: 8049303: Transient network problems cause JMX thread to fail silenty In-Reply-To: <53FF5177.7000700@oracle.com> References: <53FBDB1A.2070501@oracle.com> <53FF5177.7000700@oracle.com> Message-ID: <5400471F.3050802@oracle.com> Hi Jaroslav, I am not sure to understand how this solves the problem. The old code first checked the connection, and if that failed, sent the FAILED notification, closed the connector, and rethrew the exception. The new code directly throws the exception without checking the connection, and therefore without closing the connection and sending the FAILED notification. So is the fix a change of behavior by which the RMIConnector will - in some cases - not try to autoclose the connection but instead simply wait for the caller to explicitely call close()? I'd be interested to hear what Shanliang has to say... best regards, -- daniel On 8/28/14 5:57 PM, Jaroslav Bachorik wrote: > I have taken over this issue from Poonam since she will be unavailable > for the next month or so. > > Could I have reviews for this change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8049303 > Webrev: http://cr.openjdk.java.net/~jbachorik/8049303/webrev.00 > > Problem and fix: > By default the JMX client side notification fetch timeout > (jmx.remote.x.notification.fetch.timeout) is 1 minute and the default > server connection timeout (jmx.remote.x.server.connection.timeout) is 2 > minutes. > > If the client side connector thread makes a notification fetch request > to the server, but a transient network problem prevents the server > response from reaching the client, the client side connector will wait > for a response until the timeout period (1 minute) has expired before > throwing an IOException. > > The client side RMIConnector implementation handles the IOException, by > re-checking the connection status to understand whether or not it is > broken. If the connection is not available at that moment, the connector > fails by re-throwing the initial IOException. The problem is that this > re-check of the connection passes because the server side of the > connection doesn't time out until 2 minutes has passed (by default), so > the NotifFetcher thread > dies without posting a failed notification, and the client application > does not get a chance to recover. > > The fix is to forward the non connection-related exceptions on the JMX > client side instead of checking the connection status. The > connection-related exceptions will cause closing the session as an > unsuccessful connection check would have done. > > Testing: > All the jdk_jmx and jdk_management regression tests passed. > All the related JCK tests passed. > > The fix applies cleanly to 8u and 7u repos. > > > Thanks, > -JB- > > From jaroslav.bachorik at oracle.com Fri Aug 29 09:41:30 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 29 Aug 2014 11:41:30 +0200 Subject: jmx-dev Review request: 8049303: Transient network problems cause JMX thread to fail silenty In-Reply-To: <5400471F.3050802@oracle.com> References: <53FBDB1A.2070501@oracle.com> <53FF5177.7000700@oracle.com> <5400471F.3050802@oracle.com> Message-ID: <54004ACA.4040802@oracle.com> On 08/29/2014 11:25 AM, Daniel Fuchs wrote: > Hi Jaroslav, > > I am not sure to understand how this solves the problem. > The old code first checked the connection, and if that failed, > sent the FAILED notification, closed the connector, and rethrew > the exception. This problem seems to have something to do with the way RMI works - the customer had problems with one set of ties/stubs while the other set of ties/stubs worked just fine. Seems like in cases of transient network failures the connection check was not reliable. > > The new code directly throws the exception without > checking the connection, and therefore without closing > the connection and sending the FAILED notification. It only does so for the cases where the connection itself is not the culprit - error while executing the method on the server, marshalling problems etc. > > So is the fix a change of behavior by which the RMIConnector > will - in some cases - not try to autoclose the connection but > instead simply wait for the caller to explicitely call close()? Not really - the change is in relying on the RMI providing the information whether the connection is still usable or not. The code didn't autoclose the connection when "connection.getDefaultDomain(null)" didn't throw IOException either. > > I'd be interested to hear what Shanliang has to say... Yep. The code does a lot of things at once and without any spec for handling failures and recovery we can only rely on the tests. -JB- > > best regards, > > -- daniel > > > On 8/28/14 5:57 PM, Jaroslav Bachorik wrote: >> I have taken over this issue from Poonam since she will be unavailable >> for the next month or so. >> >> Could I have reviews for this change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8049303 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8049303/webrev.00 >> >> Problem and fix: >> By default the JMX client side notification fetch timeout >> (jmx.remote.x.notification.fetch.timeout) is 1 minute and the default >> server connection timeout (jmx.remote.x.server.connection.timeout) is 2 >> minutes. >> >> If the client side connector thread makes a notification fetch request >> to the server, but a transient network problem prevents the server >> response from reaching the client, the client side connector will wait >> for a response until the timeout period (1 minute) has expired before >> throwing an IOException. >> >> The client side RMIConnector implementation handles the IOException, by >> re-checking the connection status to understand whether or not it is >> broken. If the connection is not available at that moment, the connector >> fails by re-throwing the initial IOException. The problem is that this >> re-check of the connection passes because the server side of the >> connection doesn't time out until 2 minutes has passed (by default), so >> the NotifFetcher thread >> dies without posting a failed notification, and the client application >> does not get a chance to recover. >> >> The fix is to forward the non connection-related exceptions on the JMX >> client side instead of checking the connection status. The >> connection-related exceptions will cause closing the session as an >> unsuccessful connection check would have done. >> >> Testing: >> All the jdk_jmx and jdk_management regression tests passed. >> All the related JCK tests passed. >> >> The fix applies cleanly to 8u and 7u repos. >> >> >> Thanks, >> -JB- >> >> > From staffan.friberg at oracle.com Fri Aug 29 22:32:15 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Fri, 29 Aug 2014 15:32:15 -0700 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <54001EFF.3030802@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> Message-ID: <5400FF6F.5040203@oracle.com> Hi Erik, On 08/28/2014 11:34 PM, Erik Helin wrote: > (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in > this thread, I'm adding it back) > > On 2014-08-28 23:15, Staffan Friberg wrote: >> Hi Erik, >> >> Thanks for the comments. >>> - Aren't the events for promotion to the tenured generation (SerialOld) >>> and the CMS generation missing? >> The reason for leaving out these two, Serial completely and CMS >> promotion, was due to that neither as far as I understand make use of >> PLABs. > > I might be wrong here, but looking at the function > TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks to > me like SerialOld is using PLABs when ParNew is promoting objects from > young to old. > > As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote (in > concurrentMarkSweepGeneration.cpp) it seems like each > CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local > Allocation Buffer) that is a thread-local allocation buffer. See > compactibleFreeListSpace.{hpp,cpp} for more details. > > Given this, I think we should add events for Serial and CMS as well. > Ok I see what you mean with CMS, basically the equivalent to getting a PLAB would be when we refill the CFLS_LAB in the alloc function. It still does the allocation to a small memory (~ size of object) area from the freelist, but at least we did extra work to refill the local CFLS_LAB. Need to do some analysis to see how often we refill so the overhead doesn't get too high. The only issue I run into is how I can in a nice way get access to the ParNewTracer from ParNewGeneration to call the report function. Let's sync up next week and see how it can be solved. The tenured GC requires something similar to be supported, however since ParNewGC is deprecated for usage without CMS in JDK 8 we might want to skip that combination. > > On 2014-08-28 23:15, Staffan Friberg wrote: >>> - Would it make sense to differentiate, either by separate events or by >>> a field in a event, between promotions to to-space and to the old >>> generation? >>> - The are two events for TLAB allocations, >>> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >>> What do you think about using two events for PLAB allocations as >>> well: >>> - java/object_alloc_in_new_PLAB >>> - java/object_alloc_outside_PLAB >> I think this is a matter of taste and probably how similar we want the >> event to be to the existing allocation event. I personally prefer a >> single event but if the GC team and serviceability team feel it would be >> better to have two I can certainly rewrite. The reason for me preferring >> a single event is just ease of analysis, you can easily filter a list of >> events on a field, it is harder to merge two different events with >> different fields and work with them in an straight forward fashion. >> >> Any general preference for having a single or multiple events? > > I would prefer to have two events in this case and try to follow the > existing allocation events as much as possible (both in naming and in > style). Keeping the tenured field (I missed it the first time I read > the patch) is good. > Yes, tenured would be independent of having two events, only PLAB size and directAllocation would be affected when having two event types. *Erik Gahlin*, any preference from your end? > On 2014-08-28 23:15, Staffan Friberg wrote: >>> - In PSPromotionManager, instead of utilizing the C++ friendship with >>> PSScavenge, should we add a getter function for the gc_tracer? >> Created a getter function. > > Thanks! If you make report_promotion_sample const, then the getter can > return a const ParallelScavengeTracer*, right? > Done //Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: