From mikhailo.seledtsov at oracle.com Fri Mar 1 22:53:21 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 1 Mar 2019 14:53:21 -0800 Subject: RFR(S): 8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info Message-ID: Please review this new test that verifies that certain JFR events report correct data when JVM is run inside a Docker container. The test has 3 test cases, testing the following events: CPUInformation, PhysicalMemory and SystemProcess. The test launches Docker containers with resource parameters that are limited and less than available on the host system, and verifies that events report resource values based on container data, not the host data. ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8219997 ??? Webrev: http://cr.openjdk.java.net/~mseledtsov/8219997.01/ ??? Testing: ran the test 50 times on Linux-x64 - All PASS Thank you, Misha From mikhailo.seledtsov at oracle.com Mon Mar 4 01:24:56 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Sun, 3 Mar 2019 17:24:56 -0800 Subject: RFR(S): 8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash In-Reply-To: <5C76DCFF.9080407@oracle.com> References: <02ed0567-9465-7a55-85dc-46d504fd9b3b@oracle.com> <6071CEE0-C0B1-4818-BB94-F6A460A8D58E@oracle.com> <5C76DCFF.9080407@oracle.com> Message-ID: <9f83302c-27b0-6ec9-eec7-0897723ec729@oracle.com> I removed the sleeps, and the test still works well. I ran it 25 times on 4 different platforms. Here is the updated webrev: http://cr.openjdk.java.net/~mseledtsov/8213448.01/ Misha On 2/27/19 10:54 AM, Mikhailo Seledtsov wrote: > Hi Erik, > > ? I will look into getting rid of thread sleep. > > Thank you, > Misha > > On 2/27/19, 5:26 AM, Erik Gahlin wrote: >> Hi Misha, >> >> Is there some way we could avoid the thread sleeps? >> >> Thanks >> Erik >> >> >>> On 26 Feb 2019, at 03:37, mikhailo.seledtsov at oracle.com wrote: >>> >>> Please review this change that added these enhancements to the test: >>> ?? - added 2 more crash scenarios: crasher via System.halt() and via >>> sending a signal >>> ?? - removed dumponexit=true from the test, since emergency >>> recording should be generated regardless >>> ?? - removed -Xint from test cases, thus testing the default >>> configuration >>> ?? - simplified the logic of identifying the name of the recording file >>> ?? - added diagnostic info to the test >>> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8213448 >>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8213448.00/ >>> Testing: >>> ???? 1. Locally: exercised the test locally on Linux-x64: PASS >>> ???? 2. Test System: ran 20 times on multiple platforms - All PASS >>> >>> Thank you, >>> Misha >>> From erik.gahlin at oracle.com Wed Mar 6 21:38:53 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 6 Mar 2019 22:38:53 +0100 Subject: RFR(S): 8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash In-Reply-To: <9f83302c-27b0-6ec9-eec7-0897723ec729@oracle.com> References: <02ed0567-9465-7a55-85dc-46d504fd9b3b@oracle.com> <6071CEE0-C0B1-4818-BB94-F6A460A8D58E@oracle.com> <5C76DCFF.9080407@oracle.com> <9f83302c-27b0-6ec9-eec7-0897723ec729@oracle.com> Message-ID: <411D6E68-6810-4771-A2DB-D580088686E9@oracle.com> OK, thanks for fixing. My only worry with the test, in general, is that the JVM will be in a state that we can?t recover/dump from, leading to intermittent failures that happens once in a month, or so. It may make sense to add a mechanism, so it is sufficient if the test succeeds in one out of two/three attempts. The crash dump is a best effort, not a guarantee. That said, it?s early in the release and we may gain some insight into how often those intermittent failures happens if we run it as is. Erik > On 4 Mar 2019, at 02:24, mikhailo.seledtsov at oracle.com wrote: > > I removed the sleeps, and the test still works well. I ran it 25 times on 4 different platforms. > > Here is the updated webrev: http://cr.openjdk.java.net/~mseledtsov/8213448.01/ > > > Misha > > > On 2/27/19 10:54 AM, Mikhailo Seledtsov wrote: >> Hi Erik, >> >> I will look into getting rid of thread sleep. >> >> Thank you, >> Misha >> >> On 2/27/19, 5:26 AM, Erik Gahlin wrote: >>> Hi Misha, >>> >>> Is there some way we could avoid the thread sleeps? >>> >>> Thanks >>> Erik >>> >>> >>>> On 26 Feb 2019, at 03:37, mikhailo.seledtsov at oracle.com wrote: >>>> >>>> Please review this change that added these enhancements to the test: >>>> - added 2 more crash scenarios: crasher via System.halt() and via sending a signal >>>> - removed dumponexit=true from the test, since emergency recording should be generated regardless >>>> - removed -Xint from test cases, thus testing the default configuration >>>> - simplified the logic of identifying the name of the recording file >>>> - added diagnostic info to the test >>>> >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8213448 >>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8213448.00/ >>>> Testing: >>>> 1. Locally: exercised the test locally on Linux-x64: PASS >>>> 2. Test System: ran 20 times on multiple platforms - All PASS >>>> >>>> Thank you, >>>> Misha >>>> > From mikhailo.seledtsov at oracle.com Wed Mar 6 22:27:55 2019 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Wed, 06 Mar 2019 14:27:55 -0800 Subject: RFR(S): 8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash In-Reply-To: <411D6E68-6810-4771-A2DB-D580088686E9@oracle.com> References: <02ed0567-9465-7a55-85dc-46d504fd9b3b@oracle.com> <6071CEE0-C0B1-4818-BB94-F6A460A8D58E@oracle.com> <5C76DCFF.9080407@oracle.com> <9f83302c-27b0-6ec9-eec7-0897723ec729@oracle.com> <411D6E68-6810-4771-A2DB-D580088686E9@oracle.com> Message-ID: <5C80496B.9090904@oracle.com> Erik, Thank you for review. On 3/6/19, 1:38 PM, Erik Gahlin wrote: > OK, thanks for fixing. > > My only worry with the test, in general, is that the JVM will be in a state that we can?t recover/dump from, leading to intermittent failures that happens once in a month, or so. > > It may make sense to add a mechanism, so it is sufficient if the test succeeds in one out of two/three attempts. The crash dump is a best effort, not a guarantee. That said, it?s early in the release and we may gain some insight into how often those intermittent failures happens if we run it as is. I agree. Let's see what we can find out in our testing. If it is a bit unstable, I will add the multiple attempt mechanism, requiring only one attempt to succeed. Thank you, Misha > > Erik > >> On 4 Mar 2019, at 02:24, mikhailo.seledtsov at oracle.com wrote: >> >> I removed the sleeps, and the test still works well. I ran it 25 times on 4 different platforms. >> >> Here is the updated webrev: http://cr.openjdk.java.net/~mseledtsov/8213448.01/ >> >> >> Misha >> >> >> On 2/27/19 10:54 AM, Mikhailo Seledtsov wrote: >>> Hi Erik, >>> >>> I will look into getting rid of thread sleep. >>> >>> Thank you, >>> Misha >>> >>> On 2/27/19, 5:26 AM, Erik Gahlin wrote: >>>> Hi Misha, >>>> >>>> Is there some way we could avoid the thread sleeps? >>>> >>>> Thanks >>>> Erik >>>> >>>> >>>>> On 26 Feb 2019, at 03:37, mikhailo.seledtsov at oracle.com wrote: >>>>> >>>>> Please review this change that added these enhancements to the test: >>>>> - added 2 more crash scenarios: crasher via System.halt() and via sending a signal >>>>> - removed dumponexit=true from the test, since emergency recording should be generated regardless >>>>> - removed -Xint from test cases, thus testing the default configuration >>>>> - simplified the logic of identifying the name of the recording file >>>>> - added diagnostic info to the test >>>>> >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8213448 >>>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8213448.00/ >>>>> Testing: >>>>> 1. Locally: exercised the test locally on Linux-x64: PASS >>>>> 2. Test System: ran 20 times on multiple platforms - All PASS >>>>> >>>>> Thank you, >>>>> Misha >>>>> From erik.gahlin at oracle.com Thu Mar 7 14:23:17 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 7 Mar 2019 15:23:17 +0100 Subject: RFR(S): 8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info In-Reply-To: References: Message-ID: <5C812955.5020800@oracle.com> Looks reasonable. Erik > Please review this new test that verifies that certain JFR events > report correct data when JVM is run inside a Docker container. The > test has 3 test cases, testing the following events: CPUInformation, > PhysicalMemory and SystemProcess. The test launches Docker containers > with resource parameters that are limited and less than available on > the host system, and verifies that events report resource values based > on container data, not the host data. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219997 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8219997.01/ > Testing: ran the test 50 times on Linux-x64 - All PASS > > Thank you, > Misha > From mikhailo.seledtsov at oracle.com Thu Mar 7 15:43:48 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Thu, 7 Mar 2019 07:43:48 -0800 Subject: RFR(S): 8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info In-Reply-To: <5C812955.5020800@oracle.com> References: <5C812955.5020800@oracle.com> Message-ID: <55a3b3ba-6f4e-4874-e731-b12b009ffbe6@oracle.com> Thank you for review, Misha On 3/7/19 6:23 AM, Erik Gahlin wrote: > Looks reasonable. > > Erik > >> Please review this new test that verifies that certain JFR events >> report correct data when JVM is run inside a Docker container. The >> test has 3 test cases, testing the following events: CPUInformation, >> PhysicalMemory and SystemProcess. The test launches Docker containers >> with resource parameters that are limited and less than available on >> the host system, and verifies that events report resource values >> based on container data, not the host data. >> >> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8219997 >> ??? Webrev: http://cr.openjdk.java.net/~mseledtsov/8219997.01/ >> ??? Testing: ran the test 50 times on Linux-x64 - All PASS >> >> Thank you, >> Misha >> > From yasuenag at gmail.com Fri Mar 8 12:52:09 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 8 Mar 2019 21:52:09 +0900 Subject: PING: RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero In-Reply-To: <59ed9471-45a5-5707-8356-367ae35a7829@gmail.com> References: <6D0A14CC-3EBA-4A01-AFFC-F2987F3C4DFD@oracle.com> <59ed9471-45a5-5707-8356-367ae35a7829@gmail.com> Message-ID: <19551e1b-b9e8-62e1-6fab-7dd6e100f50a@gmail.com> PING: Could you review it? >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ If you have any questions, please tell me. Thanks, Yasumasa On 2019/02/27 22:46, Yasumasa Suenaga wrote: > Hi Erik, > > On 2019/02/27 22:30, Erik Gahlin wrote: >> Hi Yasumasa, >> >> Could you explain a little about the bug? >> >> Why should stack traces be collected if MaxJavaStackTraceDepth is set to 0. > > "0" in MaxJavaStackTraceDepth means all exception stack traces > will be shown. > > http://hg.openjdk.java.net/jdk/jdk/file/72ce7dd54939/src/hotspot/share/runtime/globals.hpp#l1553 > > JDK-7179701 reports similar issue. > I think we can take similar approach for JDK-8219566. > > > Thanks, > > Yasumasa > > >> Thanks >> Erik >> >>> On 22 Feb 2019, at 07:48, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> Please review this change: >>> >>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>> >>> JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero. >>> This bug is similar to JDK-7179701. >>> >>> This change passed tests on submit repo and :jdk_jfr jtreg tests. >>> >>> >>> Thanks, >>> >>> Yasumasa >> From erik.gahlin at oracle.com Fri Mar 8 15:37:28 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 8 Mar 2019 16:37:28 +0100 Subject: PING: RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero In-Reply-To: <19551e1b-b9e8-62e1-6fab-7dd6e100f50a@gmail.com> References: <6D0A14CC-3EBA-4A01-AFFC-F2987F3C4DFD@oracle.com> <59ed9471-45a5-5707-8356-367ae35a7829@gmail.com> <19551e1b-b9e8-62e1-6fab-7dd6e100f50a@gmail.com> Message-ID: <5C828C38.1090506@oracle.com> JFR imposes a limit on how many frames that can be recorded, set to 64 by default but configurable up to 2048 using -XX:FlightRecorderOptions, so setting the value to 0 will still not mean all frames. That said, if you still want to fix it. It may make sense to set loop_max to INT_MAX, if MaxJavaStackTraceDepth is zero, i.e int loop_max = MaxJavaStackTraceDepth == 0 ? INT_MAX : MaxJavaStackTraceDepth * 2; and avoid evaluating it for every frame. Even if the compiler is able to hoist the comparison, it makes the code easier to read. Thanks Erik > PING: Could you review it? > >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ > > > If you have any questions, please tell me. > > > Thanks, > > Yasumasa > > > On 2019/02/27 22:46, Yasumasa Suenaga wrote: >> Hi Erik, >> >> On 2019/02/27 22:30, Erik Gahlin wrote: >>> Hi Yasumasa, >>> >>> Could you explain a little about the bug? >>> >>> Why should stack traces be collected if MaxJavaStackTraceDepth is >>> set to 0. >> >> "0" in MaxJavaStackTraceDepth means all exception stack traces >> will be shown. >> >> http://hg.openjdk.java.net/jdk/jdk/file/72ce7dd54939/src/hotspot/share/runtime/globals.hpp#l1553 >> >> >> JDK-7179701 reports similar issue. >> I think we can take similar approach for JDK-8219566. >> >> >> Thanks, >> >> Yasumasa >> >> >>> Thanks >>> Erik >>> >>>> On 22 Feb 2019, at 07:48, Yasumasa Suenaga wrote: >>>> >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>>> >>>> JFR did not collect call stacks when MaxJavaStackTraceDepth is set >>>> to zero. >>>> This bug is similar to JDK-7179701. >>>> >>>> This change passed tests on submit repo and :jdk_jfr jtreg tests. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>> From yasuenag at gmail.com Sat Mar 9 11:47:37 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 9 Mar 2019 20:47:37 +0900 Subject: PING: RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero In-Reply-To: <5C828C38.1090506@oracle.com> References: <6D0A14CC-3EBA-4A01-AFFC-F2987F3C4DFD@oracle.com> <59ed9471-45a5-5707-8356-367ae35a7829@gmail.com> <19551e1b-b9e8-62e1-6fab-7dd6e100f50a@gmail.com> <5C828C38.1090506@oracle.com> Message-ID: <47d27b56-0933-c173-55c1-7e225218ead8@gmail.com> Hi Erik, Reading your email, I think we should use JfrOptionSet::stackdepth() rather than MaxJavaStackTraceDepth. I created new webrev, and it passed jdk_jfr jtreg tests on my Linux x64 box. http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.01/ However it has not yet passed tests on submit repo (mach5-one-ysuenaga-JDK-8219566-20190309-0909-1079793). It seems to be failed at build phase which includes Linux. (I can build with this change on Fedora 29 x64). Could you help if this webrev is ok? Thanks, Yasumasa On 2019/03/09 0:37, Erik Gahlin wrote: > JFR imposes a limit on how many frames that can be recorded, set to 64 by default but configurable up to 2048 using -XX:FlightRecorderOptions, so setting the value to 0 will still not mean all frames. > > That said, if you still want to fix it. It may make sense to set loop_max to INT_MAX, if MaxJavaStackTraceDepth is zero, i.e > > int loop_max = MaxJavaStackTraceDepth == 0 ? INT_MAX : MaxJavaStackTraceDepth * 2; > > and avoid evaluating it for every frame. Even if the compiler is able to hoist the comparison, it makes the code easier to read. > > Thanks > Erik > > >> PING: Could you review it? >> >>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >> >> >> If you have any questions, please tell me. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/02/27 22:46, Yasumasa Suenaga wrote: >>> Hi Erik, >>> >>> On 2019/02/27 22:30, Erik Gahlin wrote: >>>> Hi Yasumasa, >>>> >>>> Could you explain a little about the bug? >>>> >>>> Why should stack traces be collected if MaxJavaStackTraceDepth is set to 0. >>> >>> "0" in MaxJavaStackTraceDepth means all exception stack traces >>> will be shown. >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/72ce7dd54939/src/hotspot/share/runtime/globals.hpp#l1553 >>> >>> JDK-7179701 reports similar issue. >>> I think we can take similar approach for JDK-8219566. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> Thanks >>>> Erik >>>> >>>>> On 22 Feb 2019, at 07:48, Yasumasa Suenaga wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>>>> >>>>> JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero. >>>>> This bug is similar to JDK-7179701. >>>>> >>>>> This change passed tests on submit repo and :jdk_jfr jtreg tests. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>> > From yasuenag at gmail.com Mon Mar 11 05:49:15 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Mar 2019 14:49:15 +0900 Subject: PING: RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero In-Reply-To: <47d27b56-0933-c173-55c1-7e225218ead8@gmail.com> References: <6D0A14CC-3EBA-4A01-AFFC-F2987F3C4DFD@oracle.com> <59ed9471-45a5-5707-8356-367ae35a7829@gmail.com> <19551e1b-b9e8-62e1-6fab-7dd6e100f50a@gmail.com> <5C828C38.1090506@oracle.com> <47d27b56-0933-c173-55c1-7e225218ead8@gmail.com> Message-ID: 2019?3?9?(?) 20:47 Yasumasa Suenaga : > > Hi Erik, > > Reading your email, I think we should use JfrOptionSet::stackdepth() rather than MaxJavaStackTraceDepth. > I created new webrev, and it passed jdk_jfr jtreg tests on my Linux x64 box. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.01/ > > However it has not yet passed tests on submit repo (mach5-one-ysuenaga-JDK-8219566-20190309-0909-1079793). > It seems to be failed at build phase which includes Linux. > (I can build with this change on Fedora 29 x64). > > Could you help if this webrev is ok? I found 1 warning, and I fixed it. This webrev works fine with :jdk_jfr jtreg tests on my Linux box, and submit repo test (mach5-one-ysuenaga-JDK-8219566-20190311-0150-1121570). Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.02/ Thanks, Yasumasa > Thanks, > > Yasumasa > > > > On 2019/03/09 0:37, Erik Gahlin wrote: > > JFR imposes a limit on how many frames that can be recorded, set to 64 by default but configurable up to 2048 using -XX:FlightRecorderOptions, so setting the value to 0 will still not mean all frames. > > > > That said, if you still want to fix it. It may make sense to set loop_max to INT_MAX, if MaxJavaStackTraceDepth is zero, i.e > > > > int loop_max = MaxJavaStackTraceDepth == 0 ? INT_MAX : MaxJavaStackTraceDepth * 2; > > > > and avoid evaluating it for every frame. Even if the compiler is able to hoist the comparison, it makes the code easier to read. > > > > Thanks > > Erik > > > > > >> PING: Could you review it? > >> > >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 > >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ > >> > >> > >> If you have any questions, please tell me. > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >> On 2019/02/27 22:46, Yasumasa Suenaga wrote: > >>> Hi Erik, > >>> > >>> On 2019/02/27 22:30, Erik Gahlin wrote: > >>>> Hi Yasumasa, > >>>> > >>>> Could you explain a little about the bug? > >>>> > >>>> Why should stack traces be collected if MaxJavaStackTraceDepth is set to 0. > >>> > >>> "0" in MaxJavaStackTraceDepth means all exception stack traces > >>> will be shown. > >>> > >>> http://hg.openjdk.java.net/jdk/jdk/file/72ce7dd54939/src/hotspot/share/runtime/globals.hpp#l1553 > >>> > >>> JDK-7179701 reports similar issue. > >>> I think we can take similar approach for JDK-8219566. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>>> Thanks > >>>> Erik > >>>> > >>>>> On 22 Feb 2019, at 07:48, Yasumasa Suenaga wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Please review this change: > >>>>> > >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 > >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ > >>>>> > >>>>> JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero. > >>>>> This bug is similar to JDK-7179701. > >>>>> > >>>>> This change passed tests on submit repo and :jdk_jfr jtreg tests. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>> > > From Alan.Bateman at oracle.com Tue Mar 12 12:30:55 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2019 12:30:55 +0000 Subject: 8220493: Prepare Socket/ServerSocket for alternative platform SocketImpl Message-ID: We have a branch in the sandbox named "niosocketimpl-branch" with a replacement for the underlying implementation used by java.net.Socket and ServerSocket. I've mentioned this in previous mails [1]. We also have a draft JEP [2]. I'd like to get the changes that allow for the platform SocketImpl to be replaced into jdk/jdk in advance of the JEP. The reasoning is to reduce the size of the overall patch, make the changes easier to review, and get some of the narly behavior changes out of the way before the main event. To that end, I've created JDK-8220493 [3] to bring the "preparatory changes" into jdk/jdk. A summary of the changes is: - ServerSocket is changed to use a platform SocketImpl by default, it used to use the SOCKS SocketImpl. - Socket use a SOCKS SocketImpl by default. The SOCKS SocketImpl now delegates to a platform SocketImpl rather than extending it. The HTTP SocketImpl is also changed to delegate to a platform SocketImpl. - ServerSocket.accept has been overhauled to disallow nonsensical combinations of SocketImpl. For example, it is nuts to create a ServerSocket using a custom SocketImpl and have it try to accept a connection with a platform SocketImpl. There is a big matrix of possible scenarios that are tested with a new combinations test. Chris, Michael and I spent time on a white board going through all the possible scenarios to make sure that all sane scenarios work as before, only the nonsensical comminations are disallowed. - Socket has been changed to wrap the input/output streams returned by the underlying SocketImpl so that closing of these streams will close the socket. This is important to allow for socket implementations outside of the java.net package but it requires changes to JFR as it instruments these changes. I've created a CSR [4] to document the subtle behavior changes. The webrev with the corresponding changes is here: ? http://cr.openjdk.java.net/~alanb/8220493/0/webrev/ -Alan [1] https://mail.openjdk.java.net/pipermail/net-dev/2019-January/012135.html [2] http://openjdk.java.net/jeps/8218559 [3] https://bugs.openjdk.java.net/browse/JDK-8220493 [4] https://bugs.openjdk.java.net/browse/JDK-8220494 From yasuenag at gmail.com Wed Mar 13 07:46:56 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 13 Mar 2019 16:46:56 +0900 Subject: RFR: 8220555: JFR tool shows incorrect message when it cannot access the file Message-ID: Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8220555 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220555/webrev.00/ JFR tool shows error message as "could not find file" when it receives FileNotFoundException from ctor of RandomAccessFile. According to Javadoc of RandomAccessFile [1], FileNotFoundException will be thrown when we do not be granted to access the file. Therefore, the error message misleads the user. All tests on submit repo seems to be succeeded (mach5-one-ysuenaga-JDK-8220555-20190313-0612-1175783). Also it passed :jdk_jfr jtreg tests on my Linux box. Thanks, Yasumasa [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html#%3Cinit%3E(java.io.File,java.lang.String) From erik.gahlin at oracle.com Wed Mar 13 18:07:05 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 13 Mar 2019 19:07:05 +0100 Subject: RFR: 8220555: JFR tool shows incorrect message when it cannot access the file In-Reply-To: References: Message-ID: <32D9D9D3-CFCA-410F-B271-FD7DAF1F7A32@oracle.com> Looks good. According to the bug report, the following error message will printed if the file can?t be found. $ jfr print hs_err_pid4390.jfr jfr print: could not open file /home/ysuenaga/OpenJDK/jdk/hs_err_pid4390.jfr (No such file or directory) Which is reasonable. Could you also describe what the the error message will be, if the the user lacks permission to access the file. Thanks Erik > On 13 Mar 2019, at 08:46, Yasumasa Suenaga wrote: > > Hi all, > > Please review this change: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220555 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220555/webrev.00/ > > JFR tool shows error message as "could not find file" when it receives > FileNotFoundException from ctor of RandomAccessFile. > According to Javadoc of RandomAccessFile [1], FileNotFoundException > will be thrown when we do not be granted to access the file. > Therefore, the error message misleads the user. > > All tests on submit repo seems to be succeeded > (mach5-one-ysuenaga-JDK-8220555-20190313-0612-1175783). > Also it passed :jdk_jfr jtreg tests on my Linux box. > > > Thanks, > > Yasumasa > > > [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html#%3Cinit%3E(java.io.File,java.lang.String) From yasuenag at gmail.com Thu Mar 14 02:34:17 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 14 Mar 2019 11:34:17 +0900 Subject: RFR: 8220555: JFR tool shows incorrect message when it cannot access the file In-Reply-To: <32D9D9D3-CFCA-410F-B271-FD7DAF1F7A32@oracle.com> References: <32D9D9D3-CFCA-410F-B271-FD7DAF1F7A32@oracle.com> Message-ID: Hi Erik, Thank you for your review. I will push it when I get another reviewer(s). I added the message to JBS in case of the user lacks permission. $ ls -l /tmp/hs_err_pid4390.jfr --w------- 1 yasuenag yasuenag 407637 Mar 14 11:25 /tmp/hs_err_pid4390.jfr $ jfr print /tmp/hs_err_pid4390.jfr jfr print: could not open file /tmp/hs_err_pid4390.jfr (Permission denied) Yasumasa 2019?3?14?(?) 3:07 Erik Gahlin : > > Looks good. > > According to the bug report, the following error message will printed if the file can?t be found. > > $ jfr print hs_err_pid4390.jfr > jfr print: could not open file /home/ysuenaga/OpenJDK/jdk/hs_err_pid4390.jfr (No such file or directory) > > Which is reasonable. > > Could you also describe what the the error message will be, if the the user lacks permission to access the file. > > Thanks > Erik > > > > On 13 Mar 2019, at 08:46, Yasumasa Suenaga wrote: > > > > Hi all, > > > > Please review this change: > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220555 > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220555/webrev.00/ > > > > JFR tool shows error message as "could not find file" when it receives > > FileNotFoundException from ctor of RandomAccessFile. > > According to Javadoc of RandomAccessFile [1], FileNotFoundException > > will be thrown when we do not be granted to access the file. > > Therefore, the error message misleads the user. > > > > All tests on submit repo seems to be succeeded > > (mach5-one-ysuenaga-JDK-8220555-20190313-0612-1175783). > > Also it passed :jdk_jfr jtreg tests on my Linux box. > > > > > > Thanks, > > > > Yasumasa > > > > > > [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html#%3Cinit%3E(java.io.File,java.lang.String) > From yasuenag at gmail.com Fri Mar 15 08:52:37 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 15 Mar 2019 17:52:37 +0900 Subject: RFR: 8220657: JFR.dump does not work when filename is set Message-ID: Hi all, Please review this change. JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.00/ The user might not get flight record via JFR.dump if JFR is started with filename option on target process. Please see JBS if you want to know how to reproduce. Thanks, Yasumasa From mikhailo.seledtsov at oracle.com Fri Mar 15 17:29:09 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 15 Mar 2019 10:29:09 -0700 Subject: RFR: 8220555: JFR tool shows incorrect message when it cannot access the file In-Reply-To: References: <32D9D9D3-CFCA-410F-B271-FD7DAF1F7A32@oracle.com> Message-ID: Looks good to me, Misha On 3/13/19 7:34 PM, Yasumasa Suenaga wrote: > Hi Erik, > > Thank you for your review. > I will push it when I get another reviewer(s). > > I added the message to JBS in case of the user lacks permission. > > $ ls -l /tmp/hs_err_pid4390.jfr > --w------- 1 yasuenag yasuenag 407637 Mar 14 11:25 /tmp/hs_err_pid4390.jfr > $ jfr print /tmp/hs_err_pid4390.jfr > jfr print: could not open file /tmp/hs_err_pid4390.jfr (Permission denied) > > > Yasumasa > > 2019?3?14?(?) 3:07 Erik Gahlin : >> Looks good. >> >> According to the bug report, the following error message will printed if the file can?t be found. >> >> $ jfr print hs_err_pid4390.jfr >> jfr print: could not open file /home/ysuenaga/OpenJDK/jdk/hs_err_pid4390.jfr (No such file or directory) >> >> Which is reasonable. >> >> Could you also describe what the the error message will be, if the the user lacks permission to access the file. >> >> Thanks >> Erik >> >> >>> On 13 Mar 2019, at 08:46, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> Please review this change: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8220555 >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220555/webrev.00/ >>> >>> JFR tool shows error message as "could not find file" when it receives >>> FileNotFoundException from ctor of RandomAccessFile. >>> According to Javadoc of RandomAccessFile [1], FileNotFoundException >>> will be thrown when we do not be granted to access the file. >>> Therefore, the error message misleads the user. >>> >>> All tests on submit repo seems to be succeeded >>> (mach5-one-ysuenaga-JDK-8220555-20190313-0612-1175783). >>> Also it passed :jdk_jfr jtreg tests on my Linux box. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/RandomAccessFile.html#%3Cinit%3E(java.io.File,java.lang.String) From yasuenag at gmail.com Tue Mar 19 12:05:36 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 19 Mar 2019 21:05:36 +0900 Subject: PING: RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero In-Reply-To: References: <6D0A14CC-3EBA-4A01-AFFC-F2987F3C4DFD@oracle.com> <59ed9471-45a5-5707-8356-367ae35a7829@gmail.com> <19551e1b-b9e8-62e1-6fab-7dd6e100f50a@gmail.com> <5C828C38.1090506@oracle.com> <47d27b56-0933-c173-55c1-7e225218ead8@gmail.com> Message-ID: <0b31693a-a8d4-1fdf-c830-8752f3ec379e@gmail.com> PING: Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.02/ This change has passed :jdk_jfr tests and submit repo. Thanks, Yasumasa On 2019/03/11 14:49, Yasumasa Suenaga wrote: > 2019?3?9?(?) 20:47 Yasumasa Suenaga : >> >> Hi Erik, >> >> Reading your email, I think we should use JfrOptionSet::stackdepth() rather than MaxJavaStackTraceDepth. >> I created new webrev, and it passed jdk_jfr jtreg tests on my Linux x64 box. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.01/ >> >> However it has not yet passed tests on submit repo (mach5-one-ysuenaga-JDK-8219566-20190309-0909-1079793). >> It seems to be failed at build phase which includes Linux. >> (I can build with this change on Fedora 29 x64). >> >> Could you help if this webrev is ok? > > I found 1 warning, and I fixed it. > This webrev works fine with :jdk_jfr jtreg tests on my Linux box, and > submit repo test > (mach5-one-ysuenaga-JDK-8219566-20190311-0150-1121570). > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.02/ > > > Thanks, > > Yasumasa > > >> Thanks, >> >> Yasumasa >> >> >> >> On 2019/03/09 0:37, Erik Gahlin wrote: >>> JFR imposes a limit on how many frames that can be recorded, set to 64 by default but configurable up to 2048 using -XX:FlightRecorderOptions, so setting the value to 0 will still not mean all frames. >>> >>> That said, if you still want to fix it. It may make sense to set loop_max to INT_MAX, if MaxJavaStackTraceDepth is zero, i.e >>> >>> int loop_max = MaxJavaStackTraceDepth == 0 ? INT_MAX : MaxJavaStackTraceDepth * 2; >>> >>> and avoid evaluating it for every frame. Even if the compiler is able to hoist the comparison, it makes the code easier to read. >>> >>> Thanks >>> Erik >>> >>> >>>> PING: Could you review it? >>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>>> >>>> >>>> If you have any questions, please tell me. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/02/27 22:46, Yasumasa Suenaga wrote: >>>>> Hi Erik, >>>>> >>>>> On 2019/02/27 22:30, Erik Gahlin wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Could you explain a little about the bug? >>>>>> >>>>>> Why should stack traces be collected if MaxJavaStackTraceDepth is set to 0. >>>>> >>>>> "0" in MaxJavaStackTraceDepth means all exception stack traces >>>>> will be shown. >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/72ce7dd54939/src/hotspot/share/runtime/globals.hpp#l1553 >>>>> >>>>> JDK-7179701 reports similar issue. >>>>> I think we can take similar approach for JDK-8219566. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> Thanks >>>>>> Erik >>>>>> >>>>>>> On 22 Feb 2019, at 07:48, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change: >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>>>>>> >>>>>>> JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero. >>>>>>> This bug is similar to JDK-7179701. >>>>>>> >>>>>>> This change passed tests on submit repo and :jdk_jfr jtreg tests. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>> >>> From yasuenag at gmail.com Tue Mar 19 12:10:17 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 19 Mar 2019 21:10:17 +0900 Subject: PING: RFR: 8217362: Emergency dump does not work when disk=false is set In-Reply-To: <8ae3f49a-7066-4f06-9b6a-5cf4814c529e@default> References: <0f8d53fa-fa3e-b984-5dec-9c130046835c@gmail.com> <75eabe9d-d4cd-4388-9019-4ce6bf9930fa@default> <6b838f82-f34f-44a9-9a45-cc8bed24e1cd@default> <23f55383-7b7b-424d-bcea-ea17a338d87b@default> <427a58fc-63c1-a679-cb98-f0421f8a774f@gmail.com> <8ae3f49a-7066-4f06-9b6a-5cf4814c529e@default> Message-ID: <71c0d6be-8223-1cec-2563-19d551ca760f@gmail.com> Hi Markus, Can you push this change? >> http://cr.openjdk.java.net/~mgronlun/8217362/webrev03/ It has been reviewed by Erik [1] and me [2]. I can help you if you are busy. Yasumasa [1] https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2019-February/000434.html [2] https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2019-February/000436.html On 2019/02/18 21:55, Markus Gronlund wrote: > Thank you Yasumasa-san! > > Markus > > -----Original Message----- > From: Yasumasa Suenaga > Sent: den 16 februari 2019 03:29 > To: Markus Gronlund > Cc: hotspot-jfr-dev at openjdk.java.net > Subject: Re: PING: RFR: 8217362: Emergency dump does not work when disk=false is set > > Hi Markus, > > On 2019/02/15 21:23, Markus Gronlund wrote: >> Hi again Yasumasa, >> >> Thanks for the feedback, I have updated and incorporated your suggestion on JVM_MAXPATHLEN. >> >> Rebased webrev: >> http://cr.openjdk.java.net/~mgronlun/8217362/webrev03/ > > Looks good! > > >> I have also taken ownership of the bug and will put you down as a contributor on this changeset - that ok? > > No problem. > > > Thanks, > > Yasumasa > > >> Thanks >> Markus >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: den 15 februari 2019 02:52 >> To: Markus Gronlund >> Cc: hotspot-jfr-dev at openjdk.java.net >> Subject: Re: PING: RFR: 8217362: Emergency dump does not work when >> disk=false is set >> >> Hi Markus, >> >> I have two comments for your change. >> >> - jfrEmergencyDump.cpp: L262: >> You use O_BUFLEN for dump path. It might be not enough for it. >> Can you use JVM_MAXPATHLEN? >> >> - I could not apply your change straightly to current HEAD of jdk/jdk. >> It seems to be caused by the change of 8218935. >> Can you update your change? >> >> In addition, may I change assignee of 8217362 to you? >> >> >> Thanks, >> >> Yasumasa >> >> 2019?2?15?(?) 2:04 Markus Gronlund : >>> >>> Hi again Yasumasa, >>> >>> Thank you for finding and reporting this. Looks like I managed to introduce this bug in the attempt to modularize for the open source effort. >>> >>> Your patch reminded me of another patch I had been working on with the intent to move the remaining emergency dump logic from jfrRepository into jfrEmergencyDump proper. >>> >>> I suggest we take the opportunity to fix this in a unified way under this bug (retaining the modified test to test for the in memory emergency case - thanks). >>> >>> Here is a suggestion: >>> >>> http://cr.openjdk.java.net/~mgronlun/8217362/webrev02/ >>> >>> Thanks >>> Markus >>> >>> -----Original Message----- >>> From: Markus Gronlund >>> Sent: den 14 februari 2019 11:33 >>> To: Yasumasa Suenaga >>> Cc: hotspot-jfr-dev at openjdk.java.net >>> Subject: RE: PING: RFR: 8217362: Emergency dump does not work when >>> disk=false is set >>> >>> Hi Yasumasa, >>> >>> Sorry for the delay on this, I will take a look and get back to you. >>> >>> Thanks >>> Markus >>> >>> -----Original Message----- >>> From: Yasumasa Suenaga >>> Sent: den 13 februari 2019 15:41 >>> To: hotspot-jfr-dev at openjdk.java.net >>> Subject: PING: RFR: 8217362: Emergency dump does not work when >>> disk=false is set >>> >>> PING: Could you review? >>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217362 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217362/webrev.00/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/02/02 14:01, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217362 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217362/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/01/18 16:25, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217362 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217362/webrev.00/ >>>>> >>>>> We cannot get emergency dump of flight record if disk=false is >>>>> passed to HotSpot. >>>>> This change works fine on all tests on submit repo and jdk_jfr jtreg tests. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> From erik.gahlin at oracle.com Tue Mar 19 13:04:09 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 19 Mar 2019 14:04:09 +0100 Subject: RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: References: Message-ID: <5C90E8C9.3010008@oracle.com> This looks a bit hackish. The real issue seems to be that the method PlatformRecording#newSnapshotClone incorrectly sets the destination in the clone, which then triggers a dump prematurely (when stop is called). Purpose of that method is just to take a snapshot of existing chunks in the disk repository (or from memory). and then let dumpStopped(path) do the actual dump (copy out the data from the disk repository). To make it work, some other changes would be needed as well, but I don't have time to investigate. Erik > Hi all, > > Please review this change. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.00/ > > The user might not get flight record via JFR.dump if JFR is started > with filename option on target process. > > Please see JBS if you want to know how to reproduce. > > > Thanks, > > Yasumasa From yasuenag at gmail.com Tue Mar 19 14:43:11 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 19 Mar 2019 23:43:11 +0900 Subject: RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: <5C90E8C9.3010008@oracle.com> References: <5C90E8C9.3010008@oracle.com> Message-ID: <14c04f3a-1fc0-af3b-714f-e35fa18d6a1b@gmail.com> Hi Erik, Thank you for your reply. How about this changeset? http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.01/ I think PlatformRecording#newSnapshotClone() should not dump. So I removed `setDestination()` from this. Yasumasa On 2019/03/19 22:04, Erik Gahlin wrote: > This looks a bit hackish. > > The real issue seems to be that the method > PlatformRecording#newSnapshotClone incorrectly sets the destination in > the clone, which then triggers a dump prematurely (when stop is called). > > Purpose of that method is just to take a snapshot of existing chunks in > the disk repository (or from memory). and then let dumpStopped(path) do > the actual dump (copy out the data from the disk repository). > > To make it work, some other changes would be needed as well, but I don't > have time to investigate. > > Erik > >> Hi all, >> >> Please review this change. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.00/ >> >> The user might not get flight record via JFR.dump if JFR is started >> with filename option on target process. >> >> Please see JBS if you want to know how to reproduce. >> >> >> Thanks, >> >> Yasumasa From erik.gahlin at oracle.com Tue Mar 19 14:59:42 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 19 Mar 2019 15:59:42 +0100 Subject: RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: <14c04f3a-1fc0-af3b-714f-e35fa18d6a1b@gmail.com> References: <5C90E8C9.3010008@oracle.com> <14c04f3a-1fc0-af3b-714f-e35fa18d6a1b@gmail.com> Message-ID: <5C9103DE.4040304@oracle.com> Yes, but then you would lose the original destination in other scenarios Maybe I can look at this next week. Erik > Hi Erik, > > Thank you for your reply. > > How about this changeset? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.01/ > > I think PlatformRecording#newSnapshotClone() should not dump. > So I removed `setDestination()` from this. > > > Yasumasa > > > On 2019/03/19 22:04, Erik Gahlin wrote: >> This looks a bit hackish. >> >> The real issue seems to be that the method >> PlatformRecording#newSnapshotClone incorrectly sets the destination in >> the clone, which then triggers a dump prematurely (when stop is called). >> >> Purpose of that method is just to take a snapshot of existing chunks in >> the disk repository (or from memory). and then let dumpStopped(path) do >> the actual dump (copy out the data from the disk repository). >> >> To make it work, some other changes would be needed as well, but I don't >> have time to investigate. >> >> Erik >> >>> Hi all, >>> >>> Please review this change. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.00/ >>> >>> The user might not get flight record via JFR.dump if JFR is started >>> with filename option on target process. >>> >>> Please see JBS if you want to know how to reproduce. >>> >>> >>> Thanks, >>> >>> Yasumasa From yasuenag at gmail.com Wed Mar 20 01:37:39 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 20 Mar 2019 10:37:39 +0900 Subject: RFR: 8220657: JFR.dump does not work when filename is set In-Reply-To: <5C9103DE.4040304@oracle.com> References: <5C90E8C9.3010008@oracle.com> <14c04f3a-1fc0-af3b-714f-e35fa18d6a1b@gmail.com> <5C9103DE.4040304@oracle.com> Message-ID: Hi Erik, I think this change does not affect other scenarios. :jdk_jfr jtreg tests and submit repo have passed with this change. newSnapshotClone() is called by PlatformRecording::dump and DCmdDump::newSnapshot. Both methods are related to user-requested dump. What scenarios do you think? I want to check them. Thanks, Yasumasa 2019?3?19?(?) 23:59 Erik Gahlin : > > Yes, but then you would lose the original destination in other scenarios > > Maybe I can look at this next week. > > Erik > > > Hi Erik, > > > > Thank you for your reply. > > > > How about this changeset? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.01/ > > > > I think PlatformRecording#newSnapshotClone() should not dump. > > So I removed `setDestination()` from this. > > > > > > Yasumasa > > > > > > On 2019/03/19 22:04, Erik Gahlin wrote: > >> This looks a bit hackish. > >> > >> The real issue seems to be that the method > >> PlatformRecording#newSnapshotClone incorrectly sets the destination in > >> the clone, which then triggers a dump prematurely (when stop is called). > >> > >> Purpose of that method is just to take a snapshot of existing chunks in > >> the disk repository (or from memory). and then let dumpStopped(path) do > >> the actual dump (copy out the data from the disk repository). > >> > >> To make it work, some other changes would be needed as well, but I don't > >> have time to investigate. > >> > >> Erik > >> > >>> Hi all, > >>> > >>> Please review this change. > >>> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 > >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220657/webrev.00/ > >>> > >>> The user might not get flight record via JFR.dump if JFR is started > >>> with filename option on target process. > >>> > >>> Please see JBS if you want to know how to reproduce. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > From erik.gahlin at oracle.com Fri Mar 22 19:25:15 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 22 Mar 2019 20:25:15 +0100 Subject: PING: RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero In-Reply-To: <0b31693a-a8d4-1fdf-c830-8752f3ec379e@gmail.com> References: <6D0A14CC-3EBA-4A01-AFFC-F2987F3C4DFD@oracle.com> <59ed9471-45a5-5707-8356-367ae35a7829@gmail.com> <19551e1b-b9e8-62e1-6fab-7dd6e100f50a@gmail.com> <5C828C38.1090506@oracle.com> <47d27b56-0933-c173-55c1-7e225218ead8@gmail.com> <0b31693a-a8d4-1fdf-c830-8752f3ec379e@gmail.com> Message-ID: <5C95369B.8030404@oracle.com> To me, it seems that the purpose of the method is to find the first valid frame on the stack (the top frame). This is orthogonal to the number of frames that should be recorded by JFR. Erik > PING: Could you review it? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.02/ > > This change has passed :jdk_jfr tests and submit repo. > > > Thanks, > > Yasumasa > > > On 2019/03/11 14:49, Yasumasa Suenaga wrote: >> 2019?3?9?(?) 20:47 Yasumasa Suenaga : >>> >>> Hi Erik, >>> >>> Reading your email, I think we should use JfrOptionSet::stackdepth() >>> rather than MaxJavaStackTraceDepth. >>> I created new webrev, and it passed jdk_jfr jtreg tests on my Linux >>> x64 box. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.01/ >>> >>> However it has not yet passed tests on submit repo >>> (mach5-one-ysuenaga-JDK-8219566-20190309-0909-1079793). >>> It seems to be failed at build phase which includes Linux. >>> (I can build with this change on Fedora 29 x64). >>> >>> Could you help if this webrev is ok? >> >> I found 1 warning, and I fixed it. >> This webrev works fine with :jdk_jfr jtreg tests on my Linux box, and >> submit repo test >> (mach5-one-ysuenaga-JDK-8219566-20190311-0150-1121570). >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.02/ >> >> >> Thanks, >> >> Yasumasa >> >> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> On 2019/03/09 0:37, Erik Gahlin wrote: >>>> JFR imposes a limit on how many frames that can be recorded, set to >>>> 64 by default but configurable up to 2048 using >>>> -XX:FlightRecorderOptions, so setting the value to 0 will still not >>>> mean all frames. >>>> >>>> That said, if you still want to fix it. It may make sense to set >>>> loop_max to INT_MAX, if MaxJavaStackTraceDepth is zero, i.e >>>> >>>> int loop_max = MaxJavaStackTraceDepth == 0 ? INT_MAX : >>>> MaxJavaStackTraceDepth * 2; >>>> >>>> and avoid evaluating it for every frame. Even if the compiler is >>>> able to hoist the comparison, it makes the code easier to read. >>>> >>>> Thanks >>>> Erik >>>> >>>> >>>>> PING: Could you review it? >>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>>>> >>>>> >>>>> If you have any questions, please tell me. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2019/02/27 22:46, Yasumasa Suenaga wrote: >>>>>> Hi Erik, >>>>>> >>>>>> On 2019/02/27 22:30, Erik Gahlin wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Could you explain a little about the bug? >>>>>>> >>>>>>> Why should stack traces be collected if MaxJavaStackTraceDepth >>>>>>> is set to 0. >>>>>> >>>>>> "0" in MaxJavaStackTraceDepth means all exception stack traces >>>>>> will be shown. >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/72ce7dd54939/src/hotspot/share/runtime/globals.hpp#l1553 >>>>>> >>>>>> >>>>>> JDK-7179701 reports similar issue. >>>>>> I think we can take similar approach for JDK-8219566. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> Erik >>>>>>> >>>>>>>> On 22 Feb 2019, at 07:48, Yasumasa Suenaga >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this change: >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>>>>>>> >>>>>>>> JFR did not collect call stacks when MaxJavaStackTraceDepth is >>>>>>>> set to zero. >>>>>>>> This bug is similar to JDK-7179701. >>>>>>>> >>>>>>>> This change passed tests on submit repo and :jdk_jfr jtreg tests. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>> >>>> From yasuenag at gmail.com Sat Mar 23 12:03:05 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 23 Mar 2019 21:03:05 +0900 Subject: PING: RFR: 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero In-Reply-To: <5C95369B.8030404@oracle.com> References: <6D0A14CC-3EBA-4A01-AFFC-F2987F3C4DFD@oracle.com> <59ed9471-45a5-5707-8356-367ae35a7829@gmail.com> <19551e1b-b9e8-62e1-6fab-7dd6e100f50a@gmail.com> <5C828C38.1090506@oracle.com> <47d27b56-0933-c173-55c1-7e225218ead8@gmail.com> <0b31693a-a8d4-1fdf-c830-8752f3ec379e@gmail.com> <5C95369B.8030404@oracle.com> Message-ID: <7c203381-0091-f9a9-6e76-1b09d0e92c88@gmail.com> Hi Erik, MaxJavaStackTraceDepth do not only affect finding top stack but also stack walking. JfrGetCallTrace::find_top_frame() uses MaxJavaStackTraceDepth to find top frame as you say. OTOH vframeStreamSamples::samples_next() uses it to find next valid frame. Anyway thread stack should be collected even if MaxJavaStackTraceDepth is set to zero. Thanks, Yasumasa On 2019/03/23 4:25, Erik Gahlin wrote: > To me, it seems that the purpose of the method is to find the first > valid frame on the stack (the top frame). This is orthogonal to the > number of frames that should be recorded by JFR. > > Erik > >> PING: Could you review it? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.02/ >> >> This change has passed :jdk_jfr tests and submit repo. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/03/11 14:49, Yasumasa Suenaga wrote: >>> 2019?3?9?(?) 20:47 Yasumasa Suenaga : >>>> >>>> Hi Erik, >>>> >>>> Reading your email, I think we should use JfrOptionSet::stackdepth() >>>> rather than MaxJavaStackTraceDepth. >>>> I created new webrev, and it passed jdk_jfr jtreg tests on my Linux >>>> x64 box. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.01/ >>>> >>>> However it has not yet passed tests on submit repo >>>> (mach5-one-ysuenaga-JDK-8219566-20190309-0909-1079793). >>>> It seems to be failed at build phase which includes Linux. >>>> (I can build with this change on Fedora 29 x64). >>>> >>>> Could you help if this webrev is ok? >>> >>> I found 1 warning, and I fixed it. >>> This webrev works fine with :jdk_jfr jtreg tests on my Linux box, and >>> submit repo test >>> (mach5-one-ysuenaga-JDK-8219566-20190311-0150-1121570). >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.02/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> On 2019/03/09 0:37, Erik Gahlin wrote: >>>>> JFR imposes a limit on how many frames that can be recorded, set to >>>>> 64 by default but configurable up to 2048 using >>>>> -XX:FlightRecorderOptions, so setting the value to 0 will still not >>>>> mean all frames. >>>>> >>>>> That said, if you still want to fix it. It may make sense to set >>>>> loop_max to INT_MAX, if MaxJavaStackTraceDepth is zero, i.e >>>>> >>>>> int loop_max = MaxJavaStackTraceDepth == 0 ? INT_MAX : >>>>> MaxJavaStackTraceDepth * 2; >>>>> >>>>> and avoid evaluating it for every frame. Even if the compiler is >>>>> able to hoist the comparison, it makes the code easier to read. >>>>> >>>>> Thanks >>>>> Erik >>>>> >>>>> >>>>>> PING: Could you review it? >>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>>>>> >>>>>> >>>>>> If you have any questions, please tell me. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2019/02/27 22:46, Yasumasa Suenaga wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> On 2019/02/27 22:30, Erik Gahlin wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> Could you explain a little about the bug? >>>>>>>> >>>>>>>> Why should stack traces be collected if MaxJavaStackTraceDepth >>>>>>>> is set to 0. >>>>>>> >>>>>>> "0" in MaxJavaStackTraceDepth means all exception stack traces >>>>>>> will be shown. >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/72ce7dd54939/src/hotspot/share/runtime/globals.hpp#l1553 >>>>>>> >>>>>>> >>>>>>> JDK-7179701 reports similar issue. >>>>>>> I think we can take similar approach for JDK-8219566. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> Erik >>>>>>>> >>>>>>>>> On 22 Feb 2019, at 07:48, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this change: >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219566 >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8219566/webrev.00/ >>>>>>>>> >>>>>>>>> JFR did not collect call stacks when MaxJavaStackTraceDepth is >>>>>>>>> set to zero. >>>>>>>>> This bug is similar to JDK-7179701. >>>>>>>>> >>>>>>>>> This change passed tests on submit repo and :jdk_jfr jtreg tests. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>> >>>>> >