From jaroslav.bachorik at oracle.com Mon Feb 2 10:33:31 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 02 Feb 2015 11:33:31 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54B7148D.8000406@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> <54AC5B14.1020001@oracle.com> <54AF4203.6040000@oracle.com> <54AFC6EA.8080708@oracle.com> <54B7148D.8000406@oracle.com> Message-ID: <54CF527B.7090902@oracle.com> Hi Stuart, On 15.1.2015 02:14, Stuart Marks wrote: > On 1/9/15 4:17 AM, Jaroslav Bachorik wrote: >> I've changed the PortAllocator to allocate an array of unique random >> ports >> instead of letting ServerSocket to take care of it. >> >> I ran the test 200x in a tight loop without a failure. >> >> I hope this will resolve this test's intermittent failures due to port >> conflicts >> once and for all. >> >> Update: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.03 > > Hi Jaroslav, > > Good to hear that the test seems to be running more reliably. (I'm > assuming that you'd see failures before if you ran it 200x in a tight > loop.) This is probably because you're avoiding the open/close/reopen > approach that we've now thoroughly discredited. :-) > > That said, it still looks to me like the code is more complex than it > needs to be. You're the one who's going to be maintaining it, but if it > were me, I'd put more effort into simplifying it. Here are a few > approaches I'd suggest. > > 1) It looks like occupyPort() is used only once. This is I think the > only place in PortAllocator that actually opens a socket. It's used in > test_09 where it looks like the intent is to keep a port busy by opening > a socket, and then making sure that the JMX stuff in the child process > does the right thing when it encounters a busy port. > > Since this is the only place that needs a real socket, you might as well > move the ServerSocket creation stuff out of PortAllocator and create it > directly here with new ServerSocket(0). This should never fail with a > BindException, so you needn't worry about retries. Then get the local > port, and pass it to the subprocess. You should put this within a > try-with-resources in test_09 so that the socket will be closed properly. > > 2) If you do this, then PortAllocator gets a lot simpler. There's no > need to keep a collection of sockets, so release() can go away, and the > finally-block of withAllocatedPorts can go away too. > > 3) Now PortAllocator's only instance state is the array of random port > numbers. But once this is generated, the only reason PortAllocator stays > around is to host the getter for array elements; basically it's just a > wrapper for the array. And the reset() method regenerates the array. The > essence of this is now just a function that returns an array of N random > port numbers. You can pass the array directly to the Task and it can > just use the ports from the array, instead of calling a getter. If > there's a BindException and a "reset" needs to be done, this is just > another call to the function to generate another array. So there's > really no longer a need to have PortAllocator instances. > > These is a bit farther afield from this particular change, but there are > some other opportunities for simplification: > > 4) Each of the test_NN methods consists entirely of a println followed > by a withAllocatedPorts() call which is passed a long multi-line lambda. > (In my book, multi-line lambdas are a bit of a code smell.) The > withAllocatedPorts() method essentially implements the > retry-on-BindException policy. Since each test_NN method is invoked > reflectively by a mini-framework in the test, you could merge that logic > into the mini-framework. In turn, each test method would then call the > random port generator method and get an array of the requested number of > ports, and just use them. This would removing a level of nesting and a > few lines of vertical space from every test method. > > 5) Most (but not all) of the tests call doSomething and then follow it > with a try/finally block that calls stop(). It seems like this > commonality could be extracted somehow, but it eludes me at the moment. > > 6) The internal jcmd() methods all have a void return value, but some of > them take a Consumer, which is usually passed a lambda argument that > performs some test and then sets an AtomicBoolean as a side effect. > (This is another code smell. Sometimes it's necessary, but only > sometimes.) This parameter really wants to be a Predicate. The jcmd() > method can just call the predicate and keep track of the results, and > return a final result boolean that, for example, indicates whether the > predicate had ever returend true. I'm not sure that's exactly the > semantic you want. But a preferable idiom is to return a value instead > of calling a lambda that performs side effects on captured locals. > I've applied your comments and the code is a tad simpler now. I also ironed out a few more corner cases. I ran the test 500x in a tight loop and no failure, yay! Update: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.04 -JB- From jaroslav.bachorik at oracle.com Mon Feb 2 13:41:10 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 02 Feb 2015 14:41:10 +0100 Subject: RFR 8064331: JavaSecurityAccess.doIntersectionPrivilege() drops the information about the domain combiner of the stack ACC Message-ID: <54CF7E76.7020103@oracle.com> Please, review the following change to j.s.ProtectionDomain Issue : https://bugs.openjdk.java.net/browse/JDK-8064331 Webrev: http://cr.openjdk.java.net/~jbachorik/8064331/webrev.01 This issue was reported against the JMX functionality. When a user tries to do the following ``` AccessControlContext acc = AccessController.getContext(); Subject subject = Subject.getSubject(acc); ``` the subject is always null even though it should contain the currently authenticated Subject. The reason for this is the combination of the facts that JMX is using JavaSecurityAccess.doIntersectionPrivilege(actin, stackACC, savedACC) to invoke a code in the combined access control context and this method just drops the information about the domain combiner of the stack ACC. In turn, Subject.getSubject(acc) relies on a correct domain container used in the current ACC and fails. The fix is to make the JavaSecurityAccess.doIntersectionPrivilege(action, stackACC, savedACC) to pay attention to the domain combiner of the stackACC. Thanks, -JB- From mikael.auno at oracle.com Mon Feb 2 15:40:01 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Mon, 02 Feb 2015 16:40:01 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) In-Reply-To: <54CBE74B.7040104@oracle.com> References: <54CB527B.4060503@oracle.com> <54CB5A60.8020401@oracle.com> <54CBDC4E.2010002@oracle.com> <54CBE022.20502@oracle.com> <54CBE74B.7040104@oracle.com> Message-ID: <54CF9A51.8090309@oracle.com> Thanks everyone for the reviews. This has now been pushed. Mikael On 2015-01-30 21:19, Mikael Auno wrote: > Thanks Jaroslav! > > I'll leave this open for further comments if someone else has them until > Monday afternoon (CET). If there are no more comments by then I'll get > it pushed at that time. > > Mikael > > On 2015-01-30 20:48, Jaroslav Bachorik wrote: >> Nice! For me it's good to go. >> >> -JB- >> >> On 30.1.2015 20:32, Mikael Auno wrote: >>> Jaroslav, >>> >>> First of all, thanks for the quick response and sorry for my slow one >>> (your message didn't sort into the mail folder I expected, so didn't see >>> it until now). >>> >>> Secondly, all good comments; all fixed. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.02/ >>> >>> Thanks, >>> Mikael >>> >>> On 2015-01-30 11:18, Jaroslav Bachorik wrote: >>>> Hi Mikael, >>>> >>>> it's great to see this moving forward! >>>> >>>> Comments follow: >>>> >>>> * instead of throwing a RuntimeException from within the test classes >>>> you could use o.testng.Assert.fail(...) method >>>> >>>> * all the newly introduced tests are missing @summary >>>> >>>> * test/serviceability/dcmd/compiler/CodelistTest.java >>>> L43 - unused import >>>> L68 - an unused, commented out, line >>>> >>>> * test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java >>>> L436-438 - use Arrays.asList() >>>> >>>> * test/serviceability/dcmd/vm/UptimeTest.java >>>> L44 - spurious wakeups may cause the test fail intermittently; should >>>> make sure the wait was at least 'someUptime' seconds long >>>> >>>> >>>> -JB- >>>> >>>> On 30.1.2015 10:44, Mikael Auno wrote: >>>>> Hi, could I please some reviews for this test port? >>>>> >>>>> Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 >>>>> https://bugs.openjdk.java.net/browse/JDK-8071909 >>>>> Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ >>>>> >>>>> Read on for the rationale on a few questions that might arise. >>>>> >>>>> * Why two issues? >>>>> >>>>> These changes are mainly a port of the Diagnostic Command (DCMD) tests >>>>> and corresponding framework/utility classes from an internal (non-open) >>>>> test framework to jtreg. The reason for the two issues is that the >>>>> changes depend on a few modifications to testlibrary that are available >>>>> in jdk/test but not yet in hotspot/test, as well as a small new >>>>> addition >>>>> to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD >>>>> tests). To keep the history as clean and coherent as possible, those >>>>> changes will go in under JDK-8071909 while the new tests and >>>>> DCMD-related additions to testlibrary go in under JDK-8071908. >>>>> >>>>> * Isn't there already utility classes for calling Diagnostic Commands? >>>>> >>>>> The main idea with the new utility classes in testlibrary is to provide >>>>> a single interface to call Diagnostic Commands from tests, >>>>> regardless of >>>>> the transport used (e.g. jcmd or JMX). There are a few tests scattered >>>>> around jdk/test and hotspot/test today that already utilize Diagnostic >>>>> Commands in some way, but they either use different utility classes for >>>>> this in different places or just do it directly in the test. Also, some >>>>> of these utility classes or tests go through jcmd and some through JMX >>>>> (most often without any real requirement for one transport over the >>>>> other in the test). All this means that there are, today, numerous >>>>> different implementations for calling Diagnostic Commands, and >>>>> consequently a lot of code duplication. These utility classes are meant >>>>> to replace all of these implementations, and with a single interface >>>>> regardless of the transport at that. >>>>> >>>>> * You've missed this or that test using one of the existing utility >>>>> classes! >>>>> >>>>> This is "by design". In order to keep the change at a more manageable >>>>> size and to get the core of this change in sooner, we've chosen to do >>>>> this transition in multiple steps. The first of those steps is what is >>>>> in this review request; the core utility classes, the tests ported from >>>>> the internal test framework and the adaption of the tests already in >>>>> hotspot/test/serviceability/dcmd (since they happened to reside in the >>>>> directory where we wanted to put the ported tests). When this is >>>>> integrated and have gone a few rounds through nightly testing, the >>>>> adaption of other tests in hotspot/test will follow, and after that >>>>> jdk/test. >>>>> >>>>> Thanks, >>>>> Mikael >>>>> >>>> >>> >> > From yasuenag at gmail.com Mon Feb 2 15:51:13 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 Feb 2015 00:51:13 +0900 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> <54C86A16.8070200@gmail.com> <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> Message-ID: Hi, I need more reviewer. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ Thanks, Yasumasa 2015/01/28 17:24 "Staffan Larsen" : > Looks good! > > Thanks, > /Staffan > > > On 28 jan 2015, at 05:48, Yasumasa Suenaga wrote: > > > > Hi Staffan, Kirk, > > > > I agree to set "Diagnostic Command" to GCCause. > > So I applied it to new patch. > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > > > Could you review it again? > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2015/01/28 5:06, Kirk Pepperdine wrote: > >> Hi Staffan, > >> > >>>> > >>>> Anyway, it?s a record in a GC log so I don?t see the value of GC.run. > Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the > context. > >>> > >>> Let?s go with ?Diagnostic Command?, then. > >> > >> Thank you! > >> > >> Regards, > >> Kirk > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Mon Feb 2 15:59:05 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 02 Feb 2015 16:59:05 +0100 Subject: RFR 8069286: Unexpected count of notification in LowMemoryTest Message-ID: <54CF9EC9.7000909@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8069286 Webrev: http://cr.openjdk.java.net/~jbachorik/8069286/webrev.00 In JDK-8034263 the conditions on the number of notifications were relaxed for the cases when running with CMS GC. Due to the nature of CMS we can assert only that at least the required number of notifications was fired. The fix omitted the fact that the assertion should be relaxed also on the gc count passed in the notifications. This patch takes care of the omission. Thanks, -JB- From poonam.bajaj at oracle.com Mon Feb 2 20:23:36 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Mon, 02 Feb 2015 12:23:36 -0800 Subject: Review request: Backport of JDK-8046282 to 8u In-Reply-To: <54CA8D1C.6010408@oracle.com> References: <54CA8D1C.6010408@oracle.com> Message-ID: <54CFDCC8.6050108@oracle.com> Hello, Could I have reviews for these backported changes, please. Thanks, Poonam On 1/29/2015 11:42 AM, Poonam Bajaj Parhar wrote: > Hello, > > Review request for the backport of 8046282 to 8u: > > Bug: JDK-8046282 SA > update > Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ > > Thanks, > Poonam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Mon Feb 2 22:09:04 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 02 Feb 2015 14:09:04 -0800 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54CF527B.7090902@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> <54AC5B14.1020001@oracle.com> <54AF4203.6040000@oracle.com> <54AFC6EA.8080708@oracle.com> <54B7148D.8000406@oracle.com> <54CF527B.7090902@oracle.com> Message-ID: <54CFF580.7050607@oracle.com> On 2/2/15 2:33 AM, Jaroslav Bachorik wrote: > I've applied your comments and the code is a tad simpler now. I also ironed out > a few more corner cases. I ran the test 500x in a tight loop and no failure, yay! > > Update: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.04 Hi Jaroslav, Looks quite a bit more straightforward now. I'm pretty much OK with this if you're OK with it; I think I've reviewed it enough times already. :-) I have a couple comments on test_09 that you might want to address before you push or sometime in the future. Line 714 typo "hugging" => "hogging" But I'm not convinced this retry logic in the while-loop from lines 716-723 is necessary. If you've already opened a server socket on a port, I've never seen a case where opening the same port *again* will succeed, so why bother? I'd suggest simply opening ServerSocket(0) and then getting the port via getLocalPort(). I've never seen this fail. This case should work since you actually want to open up some random port, instead of generating a random port number for somebody else (the subprocess) to open. You can then allocate one fewer random port. You might want to have a little loop to check that the random port number isn't a duplicate of the actual port that you just opened. I think this lets the code boil down a bit further: ServerSocket ss = new ServerSocket(0); try { int localPort = ss.getLocalPort(); int[] ports; do { ports = PortAllocator.allocatePorts(1); } while (localPort != ports[0]); AtomicBoolean checks = new AtomicBoolean(false); ... } finally { ss.close(); s.stop(); } s'marks From dean.long at oracle.com Mon Feb 2 22:46:39 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Feb 2015 14:46:39 -0800 Subject: RFR(XS) 8069030: support new PTRACE_GETREGSET In-Reply-To: <54C9899A.2070206@oracle.com> References: <54C70F7D.3010003@oracle.com> <54C9899A.2070206@oracle.com> Message-ID: <54CFFE4F.7020007@oracle.com> Ping. I'm still waiting for a second review on this. thanks, dl On 1/28/2015 5:15 PM, Dean Long wrote: > Adding serviceability-dev at openjdk.java.net. Can I get another review > for this please? > > thanks, > > dl > > On 1/26/2015 11:02 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >>> On 27 jan 2015, at 05:09, Dean Long wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8069030 >>> >>> http://cr.openjdk.java.net/~dlong/8069030/webrev.00/ >>> >>> Testing on linux x86 by temporarily undefining PTRACE_GETREGS_REQ so >>> that the new code >>> would get triggered, then stepping through "jstack -m " with >>> gdb to make sure the new >>> code executed correctly. >>> >>> dl >>> > From joe.darcy at oracle.com Tue Feb 3 00:18:46 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 02 Feb 2015 16:18:46 -0800 Subject: JDK 9 RFR of JDK-8072371: Add two failing svc tests to the problem list Message-ID: <54D013E6.3060303@oracle.com> Hello, We've observed two serviceability tests failing on mac platforms; I'd like to put those tests on the problem list while the underlying causes are under investigation: http://cr.openjdk.java.net/~darcy/8072371.0/ Patch below. Thanks, -Joe --- old/test/ProblemList.txt 2015-02-02 16:14:34.644778488 -0800 +++ new/test/ProblemList.txt 2015-02-02 16:14:34.476778493 -0800 @@ -132,6 +132,9 @@ java/lang/instrument/RedefineBigClass.sh generic-all java/lang/instrument/RetransformBigClass.sh generic-all +# 8072130 +java/lang/instrument/BootClassPath/BootClassPathTest.sh macosx-all + ############################################################################ # jdk_management @@ -320,6 +323,9 @@ # 8031482 sun/tools/jcmd/TestJcmdSanity.java windows-all +# 8072131 +sun/tools/jmap/heapconfig/JMapHeapConfigTest.java macosx-all + # 8027668 sun/tools/jstatd/TestJstatdDefaults.java generic-all sun/tools/jstatd/TestJstatdServer.java generic-all From lance.andersen at oracle.com Tue Feb 3 00:20:05 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 2 Feb 2015 19:20:05 -0500 Subject: JDK 9 RFR of JDK-8072371: Add two failing svc tests to the problem list In-Reply-To: <54D013E6.3060303@oracle.com> References: <54D013E6.3060303@oracle.com> Message-ID: <65A891F7-06A5-4BF3-AF48-C39B4E7295D5@oracle.com> loos fine joe On Feb 2, 2015, at 7:18 PM, joe darcy wrote: > Hello, > > We've observed two serviceability tests failing on mac platforms; I'd like to put those tests on the problem list while the underlying causes are under investigation: > > http://cr.openjdk.java.net/~darcy/8072371.0/ > > Patch below. > > Thanks, > > -Joe > > --- old/test/ProblemList.txt 2015-02-02 16:14:34.644778488 -0800 > +++ new/test/ProblemList.txt 2015-02-02 16:14:34.476778493 -0800 > @@ -132,6 +132,9 @@ > java/lang/instrument/RedefineBigClass.sh generic-all > java/lang/instrument/RetransformBigClass.sh generic-all > > +# 8072130 > +java/lang/instrument/BootClassPath/BootClassPathTest.sh macosx-all > + > ############################################################################ > > # jdk_management > @@ -320,6 +323,9 @@ > # 8031482 > sun/tools/jcmd/TestJcmdSanity.java windows-all > > +# 8072131 > +sun/tools/jmap/heapconfig/JMapHeapConfigTest.java macosx-all > + > # 8027668 > sun/tools/jstatd/TestJstatdDefaults.java generic-all > sun/tools/jstatd/TestJstatdServer.java generic-all > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From david.holmes at oracle.com Tue Feb 3 01:07:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Feb 2015 11:07:32 +1000 Subject: RFR(XS) 8069030: support new PTRACE_GETREGSET In-Reply-To: <54CFFE4F.7020007@oracle.com> References: <54C70F7D.3010003@oracle.com> <54C9899A.2070206@oracle.com> <54CFFE4F.7020007@oracle.com> Message-ID: <54D01F54.9050601@oracle.com> Looks good. Thanks, David On 3/02/2015 8:46 AM, Dean Long wrote: > Ping. I'm still waiting for a second review on this. > > thanks, > > dl > > On 1/28/2015 5:15 PM, Dean Long wrote: >> Adding serviceability-dev at openjdk.java.net. Can I get another review >> for this please? >> >> thanks, >> >> dl >> >> On 1/26/2015 11:02 PM, Staffan Larsen wrote: >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>>> On 27 jan 2015, at 05:09, Dean Long wrote: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8069030 >>>> >>>> http://cr.openjdk.java.net/~dlong/8069030/webrev.00/ >>>> >>>> Testing on linux x86 by temporarily undefining PTRACE_GETREGS_REQ so >>>> that the new code >>>> would get triggered, then stepping through "jstack -m " with >>>> gdb to make sure the new >>>> code executed correctly. >>>> >>>> dl >>>> >> > From dean.long at oracle.com Tue Feb 3 04:31:40 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Feb 2015 20:31:40 -0800 Subject: RFR(XS) 8069030: support new PTRACE_GETREGSET In-Reply-To: <54D01F54.9050601@oracle.com> References: <54C70F7D.3010003@oracle.com> <54C9899A.2070206@oracle.com> <54CFFE4F.7020007@oracle.com> <54D01F54.9050601@oracle.com> Message-ID: <54D04F2C.60405@oracle.com> Thanks David and Staffan for the reviews. dl On 2/2/2015 5:07 PM, David Holmes wrote: > Looks good. > > Thanks, > David > > On 3/02/2015 8:46 AM, Dean Long wrote: >> Ping. I'm still waiting for a second review on this. >> >> thanks, >> >> dl >> >> On 1/28/2015 5:15 PM, Dean Long wrote: >>> Adding serviceability-dev at openjdk.java.net. Can I get another review >>> for this please? >>> >>> thanks, >>> >>> dl >>> >>> On 1/26/2015 11:02 PM, Staffan Larsen wrote: >>>> Looks good! >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 27 jan 2015, at 05:09, Dean Long wrote: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8069030 >>>>> >>>>> http://cr.openjdk.java.net/~dlong/8069030/webrev.00/ >>>>> >>>>> Testing on linux x86 by temporarily undefining PTRACE_GETREGS_REQ so >>>>> that the new code >>>>> would get triggered, then stepping through "jstack -m " with >>>>> gdb to make sure the new >>>>> code executed correctly. >>>>> >>>>> dl >>>>> >>> >> From jaroslav.bachorik at oracle.com Tue Feb 3 08:35:02 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Feb 2015 09:35:02 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54CFF580.7050607@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> <54AC5B14.1020001@oracle.com> <54AF4203.6040000@oracle.com> <54AFC6EA.8080708@oracle.com> <54B7148D.8000406@oracle.com> <54CF527B.7090902@oracle.com> <54CFF580.7050607@oracle.com> Message-ID: <54D08836.30709@oracle.com> On 2.2.2015 23:09, Stuart Marks wrote: > > > On 2/2/15 2:33 AM, Jaroslav Bachorik wrote: >> I've applied your comments and the code is a tad simpler now. I also >> ironed out >> a few more corner cases. I ran the test 500x in a tight loop and no >> failure, yay! >> >> Update: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.04 > > Hi Jaroslav, > > Looks quite a bit more straightforward now. I'm pretty much OK with this > if you're OK with it; I think I've reviewed it enough times already. :-) > > I have a couple comments on test_09 that you might want to address > before you push or sometime in the future. > > Line 714 typo "hugging" => "hogging" D'oh. Thanks. > > But I'm not convinced this retry logic in the while-loop from lines > 716-723 is necessary. If you've already opened a server socket on a > port, I've never seen a case where opening the same port *again* will > succeed, so why bother? I saw the test failing without this retry logic. The purpose is to make sure that the port is really taken before the test continues. > > I'd suggest simply opening ServerSocket(0) and then getting the port via > getLocalPort(). I've never seen this fail. This case should work since > you actually want to open up some random port, instead of generating a > random port number for somebody else (the subprocess) to open. You can > then allocate one fewer random port. You might want to have a little > loop to check that the random port number isn't a duplicate of the > actual port that you just opened. I think this lets the code boil down a > bit further: > > ServerSocket ss = new ServerSocket(0); > try { > int localPort = ss.getLocalPort(); > int[] ports; > do { > ports = PortAllocator.allocatePorts(1); > } while (localPort != ports[0]); > > AtomicBoolean checks = new AtomicBoolean(false); > ... > } finally { > ss.close(); > s.stop(); > } I'll give it a try and see how this behaves. Thanks, -JB- > > > s'marks > From kirk at kodewerk.com Tue Feb 3 09:57:41 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 3 Feb 2015 10:57:41 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> <54C86A16.8070200@gmail.com> <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> Message-ID: Hi, Not an official review but it?s a simple patch that looks good. Kind regards, Kirk On Feb 2, 2015, at 4:51 PM, Yasumasa Suenaga wrote: > Hi, > > I need more reviewer. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > Thanks, > > Yasumasa > > 2015/01/28 17:24 "Staffan Larsen" : > Looks good! > > Thanks, > /Staffan > > > On 28 jan 2015, at 05:48, Yasumasa Suenaga wrote: > > > > Hi Staffan, Kirk, > > > > I agree to set "Diagnostic Command" to GCCause. > > So I applied it to new patch. > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > > > Could you review it again? > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2015/01/28 5:06, Kirk Pepperdine wrote: > >> Hi Staffan, > >> > >>>> > >>>> Anyway, it?s a record in a GC log so I don?t see the value of GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the context. > >>> > >>> Let?s go with ?Diagnostic Command?, then. > >> > >> Thank you! > >> > >> Regards, > >> Kirk > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dmitry.samersoff at oracle.com Tue Feb 3 10:35:52 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 03 Feb 2015 13:35:52 +0300 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54AFC6EA.8080708@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> <54AC5B14.1020001@oracle.com> <54AF4203.6040000@oracle.com> <54AFC6EA.8080708@oracle.com> Message-ID: <54D0A488.4030805@oracle.com> Jaroslav, Looks good for me! > I've changed the PortAllocator to allocate an array of unique random > ports instead of letting ServerSocket to take care of it. > > I ran the test 200x in a tight loop without a failure. > > I hope this will resolve this test's intermittent failures due to port > conflicts once and for all. > > Update: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.03 > -Dmitry On 2015-01-09 15:17, Jaroslav Bachorik wrote: > Thank you all for the valuable input! > > On 9.1.2015 03:50, Stuart Marks wrote: >> Hi Jaroslav, >> >> I'm distant enough from this code that I don't think I'm in a position >> to say "no you can't check this in," and I'm mindful of the fact that >> this bug is a high priority and you want to get a fix in. But having >> said that I think there's a surprising amount of complexity here for >> what it does. >> >> Implementing a retry-on-BindException policy seems to be fairly >> sensible, since I assume it would be fairly invasive to modify the code >> in the JVMs being forked to use an ephemeral port and send that >> information back to the test. >> >> My conjecture is however that the open/close/reopen logic is the primary >> cause of the BindExceptions that occur. If you're going to retry on >> BindException, you might as well choose a random port number instead of >> doing the open/close to get a port number from the system. >> >> The range that Dmitry suggests is reasonable, though I note that the >> actual ephemeral port range used by the kernel will differ from OS to OS >> and even from system to system. I don't know if that's really >> significant though. If you end up choosing a port outside the ephemeral >> range for some system, does it really matter? >> >> If you do decide to have PortAllocator open and close a ServerSocket (in >> order to find a previously unused port) I'd suggest removing the logic >> that leaves the socket open until the first call to get(). That logic >> reduces the possibility that some other process will open the socket >> after the close but before the reopen. In my experience that's not >> what's causing the BindExceptions. It could still happen, though, but >> you're protected by the retry logic anyway. Leaving the socket open >> longer actually hurts, I think, because it increases the chance that the >> kernel won't have cleaned up the port by the time the test wants to >> reopen it. >> >> If you change PortAllocator to close the socket immediately, you can get >> rid of the need to call release() in a finally-block of the caller. You >> could also change the type of the functional interface to be >> >> int[] -> void >> >> since the PortAllocator doesn't hold onto any resources that need to be >> cleaned up. It just calls the execute() method and passes an array of n >> port numbers. >> >> It's probably necessary to have the socket close() call in a retry loop. >> The socket is always closed immediately from the user process point of >> view, so isClosed() will always return true immediately after the >> close() call returns. You can verify this easily by looking in the >> ServerSocket.java source code. I believe the state that prevents the >> port from being reused immediately is private to the kernel and cannot >> be observed from a user process, at least not without attempting to >> reopen the socket. >> >> Side note: one of the jcmd() overloads says that parameter 'c' (a >> Consumer) may be null. It doesn't look like this is handled. If you >> really want to support this, I'd assign () -> { } to it if it's null so >> that it can be called unconditionally. (Or just disallow null.) > > I've changed the PortAllocator to allocate an array of unique random > ports instead of letting ServerSocket to take care of it. > > I ran the test 200x in a tight loop without a failure. > > I hope this will resolve this test's intermittent failures due to port > conflicts once and for all. > > Update: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.03 > > Thanks, > > -JB- > > >> >> s'marks >> >> >> On 1/6/15 2:00 PM, Dmitry Samersoff wrote: >>> Jaroslav, >>> >>> It might be better to just choose a random digit between 49152?65535 >>> and attempt to use it. >>> >>> -Dmitry >>> >>> >>> On 2014-12-18 17:29, Jaroslav Bachorik wrote: >>>> On 12/11/2014 03:43 PM, Dmitry Samersoff wrote: >>>>> Jaroslav, >>>>> >>>>> You can set SO_LINGER to zero, in this case socket will be closed >>>>> immediately without waiting in TIME_WAIT >>>>> >>>>> But there are no reliable way to predict whether you can take this >>>>> port >>>>> or not after you close it. >>>>> >>>>> So the only valid solution is to try to connect to a random port >>>>> and if >>>>> this attempt fails try another random port. Everything else will cause >>>>> more or less frequent intermittent failures. >>>> >>>> Thanks for all the suggestions! >>>> >>>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.02 >>>> >>>> I've enhanced the original patch with the retry logic using different >>>> random port if starting the JMX agent on the provided port fails with >>>> BindException. >>>> >>>> I'm keeping there the changes for properly closing the ports opened for >>>> the test purposes and also setting the SO_REUSEADDR - anyway, it does >>>> not make sense to reuse the ephemeral test ports. >>>> >>>> I've split the original "test_06" test case in order to keep it >>>> readable >>>> even with the new retry logic - and also to make each test case to test >>>> just one scenario. >>>> >>>> Cheers, >>>> >>>> -JB- >>>> >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-12-11 17:06, Jaroslav Bachorik wrote: >>>>>> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >>>>>>> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>>>>>>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>>>>>>> Please, review the following test change >>>>>>>>> >>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>>>>>>> >>>>>>>>> The test fails very intermittently when RMI registry is trying to >>>>>>>>> bind >>>>>>>>> to a port >>>>>>>>> previously used in the test (via ServerSocket). >>>>>>>>> >>>>>>>>> This seems to be caused by the sockets created via `new >>>>>>>>> ServerSocket(0)` and >>>>>>>>> being in reusable mode. The fix attempts to prevent this by >>>>>>>>> explicitly >>>>>>>>> forbidding the reusable mode. >>>>>>>> >>>>>>>> Hi Jaroslav, >>>>>>>> >>>>>>>> I happened to see this fly by, and there are (I think) some similar >>>>>>>> issues going on in the RMI tests. >>>>>>>> >>>>>>>> But first I'll note that I don't think setReuseAddress() will >>>>>>>> have the >>>>>>>> effect that you want. Typically it's set to true before binding a >>>>>>>> socket, so that a subsequent bind operation will succeed even if >>>>>>>> the >>>>>>>> address/port is already in use. ServerSockets created with new >>>>>>>> ServerSocket(0) are already bound, and I'm not sure what calling >>>>>>>> setReuseAddress(false) will do on such sockets. The spec says >>>>>>>> behavior >>>>>>>> is undefined, but my bet is that it does nothing. >>>>>>>> >>>>>>>> I guess it doesn't hurt to try this out to see if it makes a >>>>>>>> difference, >>>>>>>> but I don't have much confidence it will help. >>>>>>>> >>>>>>>> The potential similarity to the RMI tests is exemplified by >>>>>>>> JDK-8049202 >>>>>>>> (sorry, this bug report isn't open) but briefly this tests the RMI >>>>>>>> registry as follows: >>>>>>>> >>>>>>>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the >>>>>>>> default >>>>>>>> RMI registry port] in order to ensure that 1099 isn't in >>>>>>>> use by >>>>>>>> something else already; >>>>>>>> >>>>>>>> 2. If this succeeds, it immediately closes the ServerSocket. >>>>>>>> >>>>>>>> 3. Then it creates a new RMI registry on port 1099. >>>>>>>> >>>>>>>> In principle, this should succeed, yet it fails around 10% of the >>>>>>>> time >>>>>>>> on some systems. The error is "port already in use". My best >>>>>>>> theory is >>>>>>>> that even though the socket has just been closed by a user program, >>>>>>>> the >>>>>>>> kernel has to run the socket through some of the socket states >>>>>>>> such as >>>>>>>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually >>>>>>>> closed >>>>>>>> and is available for reuse. If a program -- even the same one -- >>>>>>>> attempts to open a socket on the same port before the socket has >>>>>>>> reached >>>>>>>> its final state, it will get an "already in use error". >>>>>>>> >>>>>>>> If this is true I don't believe that setting SO_REUSEADDR will >>>>>>>> work if >>>>>>>> the socket is in one of these final states. (I remember reading >>>>>>>> this >>>>>>>> somewhere but I'm not sure where at the moment. I can try to dig >>>>>>>> it up >>>>>>>> if there is interest.) >>>>>>>> >>>>>>>> I admit this is just a theory and I'm open to alternatives, and I'm >>>>>>>> also >>>>>>>> open to hearing about ways to deal with this problem. >>>>>>>> >>>>>>>> Could something similar be going on with this JMX test? >>>>>>> >>>>>>> Hm, this is exactly what happened with this test :( >>>>>>> >>>>>>> The problem is that the port is reported as available while it is >>>>>>> still >>>>>>> occupied and RMI registry attempts to start using that port. >>>>>>> >>>>>>> If setting SO_REUSEADDR does not work then the only solution would >>>>>>> be to >>>>>>> retry the test case when this exception occurs. >>>>>> >>>>>> Further investigation shows that the problem was rather the client >>>>>> connecting to a socket being shut down. >>>>>> >>>>>> It sounds like setting SO_REUSEADDR to false should prevent this >>>>>> failure. >>>>>> >>>>>> From the ServerSocket javadoc: >>>>>> "When a TCP connection is closed the connection may remain in a >>>>>> timeout >>>>>> state for a period of time after the connection is closed (typically >>>>>> known as the TIME_WAIT state or 2MSL wait state). For applications >>>>>> using >>>>>> a well known socket address or port it may not be possible to bind a >>>>>> socket to the required SocketAddress if there is a connection in the >>>>>> timeout state involving the socket address or port." >>>>>> >>>>>> It also turns out that the test does not close the server sockets >>>>>> properly so there might be several sockets being opened or timed out >>>>>> dangling around. >>>>>> >>>>>> I've updated the test so it is setting SO_REUSEADDR for all the new >>>>>> ServerSockets instances + introduced the mechanism to run the test >>>>>> code >>>>>> while properly cleaning up any allocated ports. >>>>>> >>>>>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> s'marks >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> > -- 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 Feb 3 13:01:06 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 03 Feb 2015 16:01:06 +0300 Subject: RFR(S, testonly): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting Message-ID: <54D0C692.1090706@oracle.com> Everyone, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.01/ 1. I was wrong in my assumption that the test can't run more than an hour of physical machine time when wrote the test. This check is removed. 2. Added sanity check for common environment pitfalls to have better diagnostic in case of a fail 3. The test kept disabled on Mac OS X until the problem with attach permissions for non-root users is solved. -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 shanliang.jiang at oracle.com Tue Feb 3 13:16:28 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 03 Feb 2015 14:16:28 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CBC1A6.8090302@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> Message-ID: <54D0CA2C.4070201@oracle.com> Hi, Hope this is last time :) http://cr.openjdk.java.net/~sjiang/JDK-8065213/02/ 1) Mandy Chung wrote: > You may want to consider using limited doPrivileged (that can be done > in the second phase). Done as in ManagementFactory: 878 // get all providers 879 List providers 880 = AccessController.doPrivileged((PrivilegedAction>) () -> { 881 List all = new ArrayList<>(); 882 for (PlatformMBeanProvider provider : ServiceLoader.loadInstalled(PlatformMBeanProvider.class)) { 883 all.add(provider); 884 } 885 all.add(new DefaultPlatformMBeanProvider()); 886 return all; 887 }, 888 null, 889 new FilePermission("<>", "read"), 890 new RuntimePermission("sun.management.spi.PlatformMBeanProvider")); 2) The modification to Flag is removed, we get another solution to know whether commercial feature is enabled. 3) some mis minors modifications. Thanks, Shanliang From daniel.fuchs at oracle.com Tue Feb 3 13:26:55 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 03 Feb 2015 14:26:55 +0100 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54D0CA2C.4070201@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> <54D0CA2C.4070201@oracle.com> Message-ID: <54D0CC9F.5090304@oracle.com> Looks good to me Shanliang. -- daniel On 03/02/15 14:16, shanliang wrote: > Hi, > > Hope this is last time :) > http://cr.openjdk.java.net/~sjiang/JDK-8065213/02/ > > 1) > Mandy Chung wrote: >> You may want to consider using limited doPrivileged (that can be done >> in the second phase). > Done as in ManagementFactory: > 878 // get all providers > 879 List providers > 880 = > AccessController.doPrivileged((PrivilegedAction>) > () -> { > 881 List all = new > ArrayList<>(); > 882 for (PlatformMBeanProvider provider : > ServiceLoader.loadInstalled(PlatformMBeanProvider.class)) { > 883 all.add(provider); > 884 } > 885 all.add(new DefaultPlatformMBeanProvider()); > 886 return all; > 887 }, > 888 null, > 889 new FilePermission("<>", "read"), > 890 new > RuntimePermission("sun.management.spi.PlatformMBeanProvider")); > > 2) > The modification to Flag is removed, we get another solution to know > whether commercial feature is enabled. > > 3) some mis minors modifications. > > Thanks, > Shanliang > > From mikael.auno at oracle.com Tue Feb 3 15:27:09 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Tue, 03 Feb 2015 16:27:09 +0100 Subject: RFR(XS): 8072401, 8072403, 8072405: Small fixes to newly added DCMD tests Message-ID: <54D0E8CD.4030905@oracle.com> Hi, could I please have some reviews for these very small fixes. Webrev: http://cr.openjdk.java.net/~miauno/8072401_8072403_8072405/webrev.00/ Issues: Some of the newly added DCMD tests fail due to lack of -XX:+UsePerfData https://bugs.openjdk.java.net/browse/JDK-8072401 HeapDumpTest and HeapDumpAllTest fails to find jhat in non-JDK runs https://bugs.openjdk.java.net/browse/JDK-8072403 DCMD tests needs at least compact3 profile https://bugs.openjdk.java.net/browse/JDK-8072405 Thanks, Mikael From jaroslav.bachorik at oracle.com Tue Feb 3 15:44:16 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Feb 2015 16:44:16 +0100 Subject: RFR(XS): 8072401, 8072403, 8072405: Small fixes to newly added DCMD tests In-Reply-To: <54D0E8CD.4030905@oracle.com> References: <54D0E8CD.4030905@oracle.com> Message-ID: <54D0ECD0.8010704@oracle.com> Looks good. -JB- On 3.2.2015 16:27, Mikael Auno wrote: > Hi, could I please have some reviews for these very small fixes. > > Webrev: > http://cr.openjdk.java.net/~miauno/8072401_8072403_8072405/webrev.00/ > > Issues: > > Some of the newly added DCMD tests fail due to lack of -XX:+UsePerfData > https://bugs.openjdk.java.net/browse/JDK-8072401 > > HeapDumpTest and HeapDumpAllTest fails to find jhat in non-JDK runs > https://bugs.openjdk.java.net/browse/JDK-8072403 > > DCMD tests needs at least compact3 profile > https://bugs.openjdk.java.net/browse/JDK-8072405 > > Thanks, > Mikael > From mikael.auno at oracle.com Tue Feb 3 16:08:31 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Tue, 03 Feb 2015 17:08:31 +0100 Subject: RFR(XS): 8072401, 8072403, 8072405: Small fixes to newly added DCMD tests In-Reply-To: <54D0ECD0.8010704@oracle.com> References: <54D0E8CD.4030905@oracle.com> <54D0ECD0.8010704@oracle.com> Message-ID: <54D0F27F.5030008@oracle.com> Thanks for the review. Could you help push this for me? The exported changsets are attached. Thanks, Mikael On 2015-02-03 16:44, Jaroslav Bachorik wrote: > Looks good. > > -JB- > > On 3.2.2015 16:27, Mikael Auno wrote: >> Hi, could I please have some reviews for these very small fixes. >> >> Webrev: >> http://cr.openjdk.java.net/~miauno/8072401_8072403_8072405/webrev.00/ >> >> Issues: >> >> Some of the newly added DCMD tests fail due to lack of -XX:+UsePerfData >> https://bugs.openjdk.java.net/browse/JDK-8072401 >> >> HeapDumpTest and HeapDumpAllTest fails to find jhat in non-JDK runs >> https://bugs.openjdk.java.net/browse/JDK-8072403 >> >> DCMD tests needs at least compact3 profile >> https://bugs.openjdk.java.net/browse/JDK-8072405 >> >> Thanks, >> Mikael >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8072401_8072403_8072405.patch Type: text/x-patch Size: 3277 bytes Desc: not available URL: From staffan.larsen at oracle.com Tue Feb 3 16:12:29 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 3 Feb 2015 17:12:29 +0100 Subject: RFR(XS): 8072401, 8072403, 8072405: Small fixes to newly added DCMD tests In-Reply-To: <54D0E8CD.4030905@oracle.com> References: <54D0E8CD.4030905@oracle.com> Message-ID: <286F1E44-95A6-4FC0-BF87-C18FB2F4F8A4@oracle.com> Looks good! Thanks, /Staffan > On 3 feb 2015, at 16:27, Mikael Auno wrote: > > Hi, could I please have some reviews for these very small fixes. > > Webrev: > http://cr.openjdk.java.net/~miauno/8072401_8072403_8072405/webrev.00/ > > Issues: > > Some of the newly added DCMD tests fail due to lack of -XX:+UsePerfData > https://bugs.openjdk.java.net/browse/JDK-8072401 > > HeapDumpTest and HeapDumpAllTest fails to find jhat in non-JDK runs > https://bugs.openjdk.java.net/browse/JDK-8072403 > > DCMD tests needs at least compact3 profile > https://bugs.openjdk.java.net/browse/JDK-8072405 > > Thanks, > Mikael From mandy.chung at oracle.com Tue Feb 3 17:50:18 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Feb 2015 09:50:18 -0800 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54D0CA2C.4070201@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> <54D0CA2C.4070201@oracle.com> Message-ID: <54D10A5A.3030109@oracle.com> On 2/3/15 5:16 AM, shanliang wrote: > Hi, > > Hope this is last time :) > http://cr.openjdk.java.net/~sjiang/JDK-8065213/02/ Looks good. Some lines are quite long that are better to reformat (no need to send a new webrev). Mandy From varming at gmail.com Tue Feb 3 19:00:57 2015 From: varming at gmail.com (Carsten Varming) Date: Tue, 3 Feb 2015 14:00:57 -0500 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: References: Message-ID: Greetings all, I was recently introduced to the deadlock described in JDK-8047720 and fixed in JDK9. The fix seems a little messy to me, and it looks like it left some very short races in the code. So I decided to clean up the code. See attached diff. The change takes a step back and acquires PeriodicTask_lock in WatcherThread::stop (like before the fix in JDK9), but this time safepoints are allowed to proceed when acquiring PeriodicTask_lock, preventing the deadlock. Let me know what you think, Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 1541 bytes Desc: not available URL: From daniel.daugherty at oracle.com Tue Feb 3 22:16:47 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 03 Feb 2015 15:16:47 -0700 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: References: Message-ID: <54D148CF.7070801@oracle.com> Carsten, I've filed the following new bug to track this potential issue: JDK-8072439 fix for 8047720 may need more work https://bugs.openjdk.java.net/browse/JDK-8072439 Dan On 2/3/15 12:00 PM, Carsten Varming wrote: > Greetings all, > > I was recently introduced to the deadlock described in JDK-8047720 and > fixed in JDK9. The fix seems a little messy to me, and it looks like > it left some very short races in the code. So I decided to clean up > the code. See attached diff. > > The change takes a step back and acquires PeriodicTask_lock in > WatcherThread::stop (like before the fix in JDK9), but this time > safepoints are allowed to proceed when acquiring PeriodicTask_lock, > preventing the deadlock. > > Let me know what you think, > Carsten > From david.holmes at oracle.com Wed Feb 4 02:38:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Feb 2015 12:38:20 +1000 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: References: Message-ID: <54D1861C.1020309@oracle.com> On 4/02/2015 5:00 AM, Carsten Varming wrote: > Greetings all, > > I was recently introduced to the deadlock described in JDK-8047720 and > fixed in JDK9. The fix seems a little messy to me, and it looks like it > left some very short races in the code. So I decided to clean up the > code. See attached diff. > > The change takes a step back and acquires PeriodicTask_lock in > WatcherThread::stop (like before the fix in JDK9), but this time > safepoints are allowed to proceed when acquiring PeriodicTask_lock, > preventing the deadlock. It isn't obvious that blocking for a safepoint whilst in this method will always be a safe thing to do. That would need to be examined in detail - potential interactions can be very subtle. David > Let me know what you think, > Carsten > From varming at gmail.com Wed Feb 4 03:28:23 2015 From: varming at gmail.com (Carsten Varming) Date: Tue, 3 Feb 2015 22:28:23 -0500 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: <54D1861C.1020309@oracle.com> References: <54D1861C.1020309@oracle.com> Message-ID: Dear David Holmes, Please see inline response, On Tue, Feb 3, 2015 at 9:38 PM, David Holmes wrote: > On 4/02/2015 5:00 AM, Carsten Varming wrote: > >> Greetings all, >> >> I was recently introduced to the deadlock described in JDK-8047720 and >> fixed in JDK9. The fix seems a little messy to me, and it looks like it >> left some very short races in the code. So I decided to clean up the >> code. See attached diff. >> >> The change takes a step back and acquires PeriodicTask_lock in >> WatcherThread::stop (like before the fix in JDK9), but this time >> safepoints are allowed to proceed when acquiring PeriodicTask_lock, >> preventing the deadlock. >> > > It isn't obvious that blocking for a safepoint whilst in this method will > always be a safe thing to do. That would need to be examined in detail - > potential interactions can be very subtle. Absolutely true. For reference, the pattern is repeated with the Terminator_lock a few lines below. The pattern is also used in Threads::destroy_vm before and after calling before_exit, and the java shutdown hooks are called right before the call to before_exit. So there is a lot of evidence that safepoints are allowed to happen in this context. Thank you for taking your time to look at this, Carsten > > David > > > Let me know what you think, >> Carsten >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Feb 4 04:28:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Feb 2015 14:28:40 +1000 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: References: <54D1861C.1020309@oracle.com> Message-ID: <54D19FF8.9060901@oracle.com> On 4/02/2015 1:28 PM, Carsten Varming wrote: > Dear David Holmes, > > Please see inline response, > > On Tue, Feb 3, 2015 at 9:38 PM, David Holmes > wrote: > > On 4/02/2015 5:00 AM, Carsten Varming wrote: > > Greetings all, > > I was recently introduced to the deadlock described in > JDK-8047720 and > fixed in JDK9. The fix seems a little messy to me, and it looks > like it > left some very short races in the code. So I decided to clean up the > code. See attached diff. > > The change takes a step back and acquires PeriodicTask_lock in > WatcherThread::stop (like before the fix in JDK9), but this time > safepoints are allowed to proceed when acquiring PeriodicTask_lock, > preventing the deadlock. > > > It isn't obvious that blocking for a safepoint whilst in this method > will always be a safe thing to do. That would need to be examined in > detail - potential interactions can be very subtle. > > > Absolutely true. For reference, the pattern is repeated with the > Terminator_lock a few lines below. The pattern is also used in > Threads::destroy_vm before and after calling before_exit, and the java > shutdown hooks are called right before the call to before_exit. So there > is a lot of evidence that safepoints are allowed to happen in this context. The thread calling before_exit is a JavaThread so of course it participates in safepoints. The issue is whether the interaction between that thread and the WatcherThread, via the PeriodicTask_lock, can allow for the JavaThread blocking at a safepoint whilst owning that lock. If another JavaThread can try to lock it without a safepoint check then we can get a deadlock. Cheers, David > Thank you for taking your time to look at this, > Carsten > > > David > > > Let me know what you think, > Carsten > > From dmitry.samersoff at oracle.com Wed Feb 4 09:53:37 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 04 Feb 2015 12:53:37 +0300 Subject: RFR(S, testonly): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting In-Reply-To: <54D0C692.1090706@oracle.com> References: <54D0C692.1090706@oracle.com> Message-ID: <54D1EC21.8010806@oracle.com> Staffan, Are you OK to push the changes? -Dmitry On 2015-02-03 16:01, Dmitry Samersoff wrote: > Everyone, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.01/ > > 1. I was wrong in my assumption that the test can't run more than an > hour of physical machine time when wrote the test. This check is removed. > > 2. Added sanity check for common environment pitfalls to have better > diagnostic in case of a fail > > 3. The test kept disabled on Mac OS X until the problem with attach > permissions for non-root users is solved. > > -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 roland.westrelin at oracle.com Wed Feb 4 15:04:00 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 04 Feb 2015 16:04:00 +0100 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception Message-ID: <877fvxhg67.fsf@oracle.com> buildreplayjars sometimes fail with an exception and I think that's caused by the lack of support for default methods when the SA dumps classes. This change fixes it at least partially. It may not be the cleanest way to support default methods but it already proved useful when investigating a compiler crash so unless someone has a better fix I would like to push it. http://cr.openjdk.java.net/~roland/8071999/webrev.00/ Roland. From mikael.auno at oracle.com Wed Feb 4 15:13:15 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Wed, 04 Feb 2015 16:13:15 +0100 Subject: RFR(XXS): 8072472: serviceability/dcmd/framework/* should be quarantined Message-ID: <54D2370B.30504@oracle.com> Hi, could I have a review for this small change to ignore three tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8072472 Webrev: http://cr.openjdk.java.net/~miauno/8072472/webrev.00/ Thanks, Mikael From dmitry.samersoff at oracle.com Wed Feb 4 15:13:21 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 04 Feb 2015 18:13:21 +0300 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <877fvxhg67.fsf@oracle.com> References: <877fvxhg67.fsf@oracle.com> Message-ID: <54D23711.3060100@oracle.com> Roland, Looks good for me! (not a reviewer) Thank you for doing it. -Dmitry On 2015-02-04 18:04, Roland Westrelin wrote: > > buildreplayjars sometimes fail with an exception and I think that's > caused by the lack of support for default methods when the SA dumps > classes. This change fixes it at least partially. It may not be the > cleanest way to support default methods but it already proved useful > when investigating a compiler crash so unless someone has a better fix > I would like to push it. > > http://cr.openjdk.java.net/~roland/8071999/webrev.00/ > > Roland. > -- 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 vladimir.x.ivanov at oracle.com Wed Feb 4 15:50:36 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 04 Feb 2015 16:50:36 +0100 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <877fvxhg67.fsf@oracle.com> References: <877fvxhg67.fsf@oracle.com> Message-ID: <54D23FCC.9030707@oracle.com> Looks good. Best regards, Vladimir Ivanov On 2/4/15 4:04 PM, Roland Westrelin wrote: > > buildreplayjars sometimes fail with an exception and I think that's > caused by the lack of support for default methods when the SA dumps > classes. This change fixes it at least partially. It may not be the > cleanest way to support default methods but it already proved useful > when investigating a compiler crash so unless someone has a better fix > I would like to push it. > > http://cr.openjdk.java.net/~roland/8071999/webrev.00/ > > Roland. > From christian.thalinger at oracle.com Wed Feb 4 16:16:51 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 4 Feb 2015 08:16:51 -0800 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <877fvxhg67.fsf@oracle.com> References: <877fvxhg67.fsf@oracle.com> Message-ID: <19091E69-AB1E-4CEF-9491-790D593C8E68@oracle.com> Since you?re saying it only fixes it partially should we file a followup bug and maybe leave a comment behind? > On Feb 4, 2015, at 7:04 AM, Roland Westrelin wrote: > > > buildreplayjars sometimes fail with an exception and I think that's > caused by the lack of support for default methods when the SA dumps > classes. This change fixes it at least partially. It may not be the > cleanest way to support default methods but it already proved useful > when investigating a compiler crash so unless someone has a better fix > I would like to push it. > > http://cr.openjdk.java.net/~roland/8071999/webrev.00/ > > Roland. From yiyeguhu at gmail.com Tue Feb 3 16:53:19 2015 From: yiyeguhu at gmail.com (Tao Mao) Date: Tue, 3 Feb 2015 08:53:19 -0800 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> <54C86A16.8070200@gmail.com> <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> Message-ID: Looks good. -Tao (tamao) On Mon, Feb 2, 2015 at 7:51 AM, Yasumasa Suenaga wrote: > Hi, > > I need more reviewer. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > Thanks, > > Yasumasa > 2015/01/28 17:24 "Staffan Larsen" : > > Looks good! >> >> Thanks, >> /Staffan >> >> > On 28 jan 2015, at 05:48, Yasumasa Suenaga wrote: >> > >> > Hi Staffan, Kirk, >> > >> > I agree to set "Diagnostic Command" to GCCause. >> > So I applied it to new patch. >> > >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ >> > >> > Could you review it again? >> > >> > >> > Thanks, >> > >> > Yasumasa >> > >> > >> > On 2015/01/28 5:06, Kirk Pepperdine wrote: >> >> Hi Staffan, >> >> >> >>>> >> >>>> Anyway, it?s a record in a GC log so I don?t see the value of >> GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient >> given the context. >> >>> >> >>> Let?s go with ?Diagnostic Command?, then. >> >> >> >> Thank you! >> >> >> >> Regards, >> >> Kirk >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Wed Feb 4 16:27:03 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 04 Feb 2015 17:27:03 +0100 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <19091E69-AB1E-4CEF-9491-790D593C8E68@oracle.com> References: <877fvxhg67.fsf@oracle.com> <19091E69-AB1E-4CEF-9491-790D593C8E68@oracle.com> Message-ID: <54D24857.1020108@oracle.com> On 04.02.2015 17:16, Christian Thalinger wrote: > Since you?re saying it only fixes it partially should we file a followup bug and maybe leave a comment behind? I think this one is related: https://bugs.openjdk.java.net/browse/JDK-8015848 Best, Tobias > >> On Feb 4, 2015, at 7:04 AM, Roland Westrelin wrote: >> >> >> buildreplayjars sometimes fail with an exception and I think that's >> caused by the lack of support for default methods when the SA dumps >> classes. This change fixes it at least partially. It may not be the >> cleanest way to support default methods but it already proved useful >> when investigating a compiler crash so unless someone has a better fix >> I would like to push it. >> >> http://cr.openjdk.java.net/~roland/8071999/webrev.00/ >> >> Roland. > From jaroslav.bachorik at oracle.com Wed Feb 4 16:55:08 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Feb 2015 17:55:08 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code Message-ID: <54D24EEC.4090303@oracle.com> Hi, this is a round 2 review of the proposed solution. Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 This patch is a precursor for implementing https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). Here, the code related to manipulating JVM flags is extracted to a separate WritableFlags class and the codebease is adjusted to use this class. I didn't touch the original (nonstandard) handling of the DTrace specific flags in the Solaris specific attachListener.cpp implementation to keep the change simple and focused. Thanks, -JB- From jaroslav.bachorik at oracle.com Wed Feb 4 16:56:18 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Feb 2015 17:56:18 +0100 Subject: RFR(XXS): 8072472: serviceability/dcmd/framework/* should be quarantined In-Reply-To: <54D2370B.30504@oracle.com> References: <54D2370B.30504@oracle.com> Message-ID: <54D24F32.7050604@oracle.com> Looks good! -JB- On 4.2.2015 16:13, Mikael Auno wrote: > Hi, could I have a review for this small change to ignore three tests. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8072472 > Webrev: http://cr.openjdk.java.net/~miauno/8072472/webrev.00/ > > Thanks, > Mikael > From mikael.auno at oracle.com Wed Feb 4 17:04:55 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Wed, 04 Feb 2015 18:04:55 +0100 Subject: RFR(XXS): 8072472: serviceability/dcmd/framework/* should be quarantined In-Reply-To: <54D24F32.7050604@oracle.com> References: <54D2370B.30504@oracle.com> <54D24F32.7050604@oracle.com> Message-ID: <54D25137.4080206@oracle.com> Thanks for the review. Would you help me push this (exported changeset attached)? Thanks, Mikael On 2015-02-04 17:56, Jaroslav Bachorik wrote: > Looks good! > > -JB- > > On 4.2.2015 16:13, Mikael Auno wrote: >> Hi, could I have a review for this small change to ignore three tests. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8072472 >> Webrev: http://cr.openjdk.java.net/~miauno/8072472/webrev.00/ >> >> Thanks, >> Mikael >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8072472.patch Type: text/x-patch Size: 1850 bytes Desc: not available URL: From varming at gmail.com Wed Feb 4 17:54:39 2015 From: varming at gmail.com (Carsten Varming) Date: Wed, 4 Feb 2015 12:54:39 -0500 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: <54D19FF8.9060901@oracle.com> References: <54D1861C.1020309@oracle.com> <54D19FF8.9060901@oracle.com> Message-ID: Dear David, I took a look at all occurrences of PeriodicTask_lock. We are in luck: PeriodicTask::enroll and PeriodicTask::disenroll check for safepoints when acquiring PeriodicTask_lock. PeriodicTask::time_to_wait and PeriodicTask::real_time_tick are called only by the watcher thread. WatcherThread::unpark is used only in contexts where PeriodicTask_lock is owned by the caller. WatcherThread::sleep is called only by the watcher thread. I took another look at WatcherThread::sleep and realized that there is a path from acquiring PeriodicTask_lock to waiting on the lock where _should_terminate is not checked. I added that to the minimal fix attached. Looking at these methods made me want to clean up a little more. See better.patch attached. I feel pretty good about the patch with the limited usage of no_safepoint_check_flag with PeriodicTask_lock. Carsten On Tue, Feb 3, 2015 at 11:28 PM, David Holmes wrote: > On 4/02/2015 1:28 PM, Carsten Varming wrote: > >> Dear David Holmes, >> >> Please see inline response, >> >> On Tue, Feb 3, 2015 at 9:38 PM, David Holmes > > wrote: >> >> On 4/02/2015 5:00 AM, Carsten Varming wrote: >> >> Greetings all, >> >> I was recently introduced to the deadlock described in >> JDK-8047720 and >> fixed in JDK9. The fix seems a little messy to me, and it looks >> like it >> left some very short races in the code. So I decided to clean up >> the >> code. See attached diff. >> >> The change takes a step back and acquires PeriodicTask_lock in >> WatcherThread::stop (like before the fix in JDK9), but this time >> safepoints are allowed to proceed when acquiring >> PeriodicTask_lock, >> preventing the deadlock. >> >> >> It isn't obvious that blocking for a safepoint whilst in this method >> will always be a safe thing to do. That would need to be examined in >> detail - potential interactions can be very subtle. >> >> >> Absolutely true. For reference, the pattern is repeated with the >> Terminator_lock a few lines below. The pattern is also used in >> Threads::destroy_vm before and after calling before_exit, and the java >> shutdown hooks are called right before the call to before_exit. So there >> is a lot of evidence that safepoints are allowed to happen in this >> context. >> > > The thread calling before_exit is a JavaThread so of course it > participates in safepoints. The issue is whether the interaction between > that thread and the WatcherThread, via the PeriodicTask_lock, can allow for > the JavaThread blocking at a safepoint whilst owning that lock. If another > JavaThread can try to lock it without a safepoint check then we can get a > deadlock. > > Cheers, > David > > > Thank you for taking your time to look at this, >> Carsten >> >> >> David >> >> >> Let me know what you think, >> Carsten >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: better.patch Type: text/x-patch Size: 3171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minimal.patch Type: text/x-patch Size: 1834 bytes Desc: not available URL: From goetz.lindenmaier at sap.com Wed Feb 4 19:14:44 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Feb 2015 19:14:44 +0000 Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF70D2F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF6DE04@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF6FAFC@DEWDFEMB12A.global.corp.sap> <54B9970B.7040502@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF70D2F@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF92467@DEWDFEMB12A.global.corp.sap> This is obsolete, it stuck in the queue waiting moderator approval. Sorry, Goetz. -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Wednesday, January 21, 2015 11:40 AM To: hotspot-dev at openjdk.java.net; serviceability-dev Subject: RE: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available Hi, could please somebody from servicability sponsor this tiny change? Thanks, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Freitag, 16. Januar 2015 23:56 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available This seems fine. Someone from the serviceability group should probably sponsor. Thanks, Coleen On 1/16/15, 6:15 AM, Lindenmaier, Goetz wrote: > Hi, > > could I please get a review for this small fix? I also please need a sponsor. > > Thanks, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Montag, 12. Januar 2015 09:23 > To: hotspot-dev at openjdk.java.net > Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available > > Hi, > > This test uses SA, thus fails on platforms where that's not implemented. > I see problems on mac and aix. > Call Platform.shouldSAAttach() to check whether SA should work. > > Please review this small fix. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8068778-jtregSA/webrev.01/ > > Best regards, > Goetz. From david.holmes at oracle.com Thu Feb 5 06:52:28 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Feb 2015 16:52:28 +1000 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <877fvxhg67.fsf@oracle.com> References: <877fvxhg67.fsf@oracle.com> Message-ID: <54D3132C.1090107@oracle.com> Hi Roland, On 5/02/2015 1:04 AM, Roland Westrelin wrote: > > buildreplayjars sometimes fail with an exception and I think that's > caused by the lack of support for default methods when the SA dumps > classes. This change fixes it at least partially. It may not be the > cleanest way to support default methods but it already proved useful > when investigating a compiler crash so unless someone has a better fix > I would like to push it. > > http://cr.openjdk.java.net/~roland/8071999/webrev.00/ I wouldn't say it "supports default methods" rather it ignores them so they don't trigger exceptions. I'm still puzzling over why default methods have a zero _codeIndex as that seems to be the real cause of the trouble. ?? As a quick workaround it may be okay but it appears that SA is seriously lagging in its language support. :( Cheers, David > Roland. > From dmitry.samersoff at oracle.com Thu Feb 5 08:29:55 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 05 Feb 2015 11:29:55 +0300 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <54D3132C.1090107@oracle.com> References: <877fvxhg67.fsf@oracle.com> <54D3132C.1090107@oracle.com> Message-ID: <54D32A03.9020907@oracle.com> David, > As a quick workaround it may be okay but it appears that SA is > seriously lagging in its language support. :( Unfortunately, SA ClassWriter is broken in many places. We plan to fix it but it's time consuming and not a top priority for today. -Dmitry On 2015-02-05 09:52, David Holmes wrote: > Hi Roland, > > On 5/02/2015 1:04 AM, Roland Westrelin wrote: >> >> buildreplayjars sometimes fail with an exception and I think that's >> caused by the lack of support for default methods when the SA dumps >> classes. This change fixes it at least partially. It may not be the >> cleanest way to support default methods but it already proved useful >> when investigating a compiler crash so unless someone has a better fix >> I would like to push it. >> >> http://cr.openjdk.java.net/~roland/8071999/webrev.00/ > > I wouldn't say it "supports default methods" rather it ignores them so > they don't trigger exceptions. I'm still puzzling over why default > methods have a zero _codeIndex as that seems to be the real cause of the > trouble. ?? > > As a quick workaround it may be okay but it appears that SA is seriously > lagging in its language support. :( > > Cheers, > David > >> Roland. >> -- 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 Feb 5 09:16:28 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 10:16:28 +0100 Subject: RFR 8062303: Remove com.sun.tracing API Message-ID: <54D334EC.6050207@oracle.com> Please, review the following removal of functionality Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 This API was introduced in JDK7 and immediately made proprietary/unsupported [1]. It didn't see any uptake since then. It'll not be accessible when it moves to modules. The proposed solution is to drop this proprietary API completely. Thanks, -JB- From Alan.Bateman at oracle.com Thu Feb 5 09:26:31 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Feb 2015 09:26:31 +0000 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D334EC.6050207@oracle.com> References: <54D334EC.6050207@oracle.com> Message-ID: <54D33747.1070900@oracle.com> On 05/02/2015 09:16, Jaroslav Bachorik wrote: > Please, review the following removal of functionality > > Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 > Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 > > This API was introduced in JDK7 and immediately made > proprietary/unsupported [1]. It didn't see any uptake since then. > It'll not be accessible when it moves to modules. > > The proposed solution is to drop this proprietary API completely. > This looks okay, you can also drop com/sun/tracing/BasicWithSecurityMgr.java from the exclude list (ProblemList.txt) as part of this. -Alan From david.holmes at oracle.com Thu Feb 5 09:26:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Feb 2015 19:26:57 +1000 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D334EC.6050207@oracle.com> References: <54D334EC.6050207@oracle.com> Message-ID: <54D33761.50906@oracle.com> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: > Please, review the following removal of functionality > > Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 > Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 > > This API was introduced in JDK7 and immediately made > proprietary/unsupported [1]. It didn't see any uptake since then. It'll > not be accessible when it moves to modules. > > The proposed solution is to drop this proprietary API completely. The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT removal. Is it included by mistake? Otherwise seems like a complete removal from the OpenJDK sources. Thanks, David > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Thu Feb 5 09:39:36 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 10:39:36 +0100 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D33761.50906@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> Message-ID: <54D33A58.4030900@oracle.com> On 5.2.2015 10:26, David Holmes wrote: > On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >> Please, review the following removal of functionality >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >> >> This API was introduced in JDK7 and immediately made >> proprietary/unsupported [1]. It didn't see any uptake since then. It'll >> not be accessible when it moves to modules. >> >> The proposed solution is to drop this proprietary API completely. > > The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT > removal. Is it included by mistake? No. The JSDT implementation depends on com.sun.tracing API (it implements it) and it must be removed together with the API. The request for the removal of the hotspot JSDT integration was reviewed in http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html -JB- > > Otherwise seems like a complete removal from the OpenJDK sources. > > Thanks, > David > >> Thanks, >> >> -JB- From jaroslav.bachorik at oracle.com Thu Feb 5 09:41:49 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 10:41:49 +0100 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D33747.1070900@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33747.1070900@oracle.com> Message-ID: <54D33ADD.9080207@oracle.com> On 5.2.2015 10:26, Alan Bateman wrote: > On 05/02/2015 09:16, Jaroslav Bachorik wrote: >> Please, review the following removal of functionality >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >> >> This API was introduced in JDK7 and immediately made >> proprietary/unsupported [1]. It didn't see any uptake since then. >> It'll not be accessible when it moves to modules. >> >> The proposed solution is to drop this proprietary API completely. >> > This looks okay, you can also drop > com/sun/tracing/BasicWithSecurityMgr.java from the exclude list > (ProblemList.txt) as part of this. With updated ProblemList.txt : http://cr.openjdk.java.net/~jbachorik/8062303/webrev.01 -JB- > > -Alan From david.holmes at oracle.com Thu Feb 5 09:48:01 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Feb 2015 19:48:01 +1000 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D33A58.4030900@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> Message-ID: <54D33C51.8050808@oracle.com> On 5/02/2015 7:39 PM, Jaroslav Bachorik wrote: > On 5.2.2015 10:26, David Holmes wrote: >> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >>> Please, review the following removal of functionality >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >>> >>> This API was introduced in JDK7 and immediately made >>> proprietary/unsupported [1]. It didn't see any uptake since then. It'll >>> not be accessible when it moves to modules. >>> >>> The proposed solution is to drop this proprietary API completely. >> >> The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT >> removal. Is it included by mistake? > > No. The JSDT implementation depends on com.sun.tracing API (it > implements it) and it must be removed together with the API. Ah I see. In that case you seem to have overlooked the removal of: jdk/src/jdk.runtime/unix/native/libjsdt/jvm_symbols_md.c jdk/src/jdk.runtime/windows/native/libjsdt/jvm_symbols_md.c Thanks, David > The request for the removal of the hotspot JSDT integration was reviewed > in > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html > > -JB- > >> >> Otherwise seems like a complete removal from the OpenJDK sources. >> >> Thanks, >> David >> >>> Thanks, >>> >>> -JB- > From staffan.larsen at oracle.com Thu Feb 5 13:55:10 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 5 Feb 2015 14:55:10 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54D24EEC.4090303@oracle.com> References: <54D24EEC.4090303@oracle.com> Message-ID: <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> Jaroslav, This looks good, just a few small comments: writableFlags.hpp: L25 #ifndef WritableFlags_HPP L26 #define WritableFlags_HPP L96 #endif /* WritableFlags_HPP */ Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer ?SUCCESS? instead. writableFlags.cpp: L25: #include statements should be in alphabetical order if possible L166: (nit) missing empty line L155: I notice the Flag class uses ?writeable? (with an ?e?) and this class uses ?writable? (without ?e?) - My english isn?t good enough to tell if there is any difference. L194: Unused variable ?succeed" Thanks, /Staffan > On 4 feb 2015, at 17:55, Jaroslav Bachorik wrote: > > Hi, this is a round 2 review of the proposed solution. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 > Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 > > This patch is a precursor for implementing https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). > > Here, the code related to manipulating JVM flags is extracted to a separate WritableFlags class and the codebease is adjusted to use this class. > > I didn't touch the original (nonstandard) handling of the DTrace specific flags in the Solaris specific attachListener.cpp implementation to keep the change simple and focused. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Thu Feb 5 15:06:08 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 16:06:08 +0100 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D33C51.8050808@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> <54D33C51.8050808@oracle.com> Message-ID: <54D386E0.1090507@oracle.com> On 5.2.2015 10:48, David Holmes wrote: > On 5/02/2015 7:39 PM, Jaroslav Bachorik wrote: >> On 5.2.2015 10:26, David Holmes wrote: >>> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >>>> Please, review the following removal of functionality >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >>>> >>>> This API was introduced in JDK7 and immediately made >>>> proprietary/unsupported [1]. It didn't see any uptake since then. It'll >>>> not be accessible when it moves to modules. >>>> >>>> The proposed solution is to drop this proprietary API completely. >>> >>> The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT >>> removal. Is it included by mistake? >> >> No. The JSDT implementation depends on com.sun.tracing API (it >> implements it) and it must be removed together with the API. > > Ah I see. In that case you seem to have overlooked the removal of: > > jdk/src/jdk.runtime/unix/native/libjsdt/jvm_symbols_md.c > jdk/src/jdk.runtime/windows/native/libjsdt/jvm_symbols_md.c ... and they are gone - http://cr.openjdk.java.net/~jbachorik/8062303/webrev.02/ I re-ran the tests successfully. -JB- > > Thanks, > David > >> The request for the removal of the hotspot JSDT integration was reviewed >> in >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html >> >> >> -JB- >> >>> >>> Otherwise seems like a complete removal from the OpenJDK sources. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> >>>> -JB- >> From jaroslav.bachorik at oracle.com Thu Feb 5 15:17:53 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 16:17:53 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> References: <54D24EEC.4090303@oracle.com> <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> Message-ID: <54D389A1.2010104@oracle.com> On 5.2.2015 14:55, Staffan Larsen wrote: > Jaroslav, > > This looks good, just a few small comments: > > writableFlags.hpp: > > L25 #ifndef WritableFlags_HPP > L26 #define WritableFlags_HPP > L96 #endif /* WritableFlags_HPP */ > Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP > > L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer ?SUCCESS? instead. > > writableFlags.cpp: > > L25: #include statements should be in alphabetical order if possible > L166: (nit) missing empty line > L155: I notice the Flag class uses ?writeable? (with an ?e?) and this class uses ?writable? (without ?e?) - My english isn?t good enough to tell if there is any difference. They should be equal in meaning. According to GooglBattle [1] the form 'writable' is far wider spread but I would leave the decision to a native speaker. [1] http://www.googlebattle.com/index.php?domain=writeable&domain2=writable&submit=Go! > L194: Unused variable ?succeed" The rest of the comments will be addressed. I will wait for eg. David to comment on 'writable' vs. 'writeable' before regenerating the webrev. -JB- > > > Thanks, > /Staffan > >> On 4 feb 2015, at 17:55, Jaroslav Bachorik wrote: >> >> Hi, this is a round 2 review of the proposed solution. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 >> >> This patch is a precursor for implementing https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >> >> Here, the code related to manipulating JVM flags is extracted to a separate WritableFlags class and the codebease is adjusted to use this class. >> >> I didn't touch the original (nonstandard) handling of the DTrace specific flags in the Solaris specific attachListener.cpp implementation to keep the change simple and focused. >> >> Thanks, >> >> -JB- > From mandy.chung at oracle.com Thu Feb 5 16:01:46 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Feb 2015 08:01:46 -0800 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D386E0.1090507@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> <54D33C51.8050808@oracle.com> <54D386E0.1090507@oracle.com> Message-ID: <54D393EA.9040005@oracle.com> On 2/5/2015 7:06 AM, Jaroslav Bachorik wrote: > > http://cr.openjdk.java.net/~jbachorik/8062303/webrev.02/ > > I re-ran the tests successfully. Looks good. thanks Mandy From staffan.larsen at oracle.com Thu Feb 5 16:20:50 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 5 Feb 2015 17:20:50 +0100 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D386E0.1090507@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> <54D33C51.8050808@oracle.com> <54D386E0.1090507@oracle.com> Message-ID: <0DB3E710-77AC-497B-BBE2-3A61E90629D2@oracle.com> Looks good! Thanks, /Staffan > On 5 feb 2015, at 16:06, Jaroslav Bachorik wrote: > > On 5.2.2015 10:48, David Holmes wrote: >> On 5/02/2015 7:39 PM, Jaroslav Bachorik wrote: >>> On 5.2.2015 10:26, David Holmes wrote: >>>> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following removal of functionality >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >>>>> >>>>> This API was introduced in JDK7 and immediately made >>>>> proprietary/unsupported [1]. It didn't see any uptake since then. It'll >>>>> not be accessible when it moves to modules. >>>>> >>>>> The proposed solution is to drop this proprietary API completely. >>>> >>>> The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT >>>> removal. Is it included by mistake? >>> >>> No. The JSDT implementation depends on com.sun.tracing API (it >>> implements it) and it must be removed together with the API. >> >> Ah I see. In that case you seem to have overlooked the removal of: >> >> jdk/src/jdk.runtime/unix/native/libjsdt/jvm_symbols_md.c >> jdk/src/jdk.runtime/windows/native/libjsdt/jvm_symbols_md.c > > ... and they are gone - http://cr.openjdk.java.net/~jbachorik/8062303/webrev.02/ > > I re-ran the tests successfully. > > -JB- > >> >> Thanks, >> David >> >>> The request for the removal of the hotspot JSDT integration was reviewed >>> in >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html >>> >>> >>> -JB- >>> >>>> >>>> Otherwise seems like a complete removal from the OpenJDK sources. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Feb 5 20:13:10 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Feb 2015 06:13:10 +1000 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D386E0.1090507@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> <54D33C51.8050808@oracle.com> <54D386E0.1090507@oracle.com> Message-ID: <54D3CED6.1060603@oracle.com> Looks good! Thanks, David On 6/02/2015 1:06 AM, Jaroslav Bachorik wrote: > On 5.2.2015 10:48, David Holmes wrote: >> On 5/02/2015 7:39 PM, Jaroslav Bachorik wrote: >>> On 5.2.2015 10:26, David Holmes wrote: >>>> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following removal of functionality >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >>>>> >>>>> This API was introduced in JDK7 and immediately made >>>>> proprietary/unsupported [1]. It didn't see any uptake since then. >>>>> It'll >>>>> not be accessible when it moves to modules. >>>>> >>>>> The proposed solution is to drop this proprietary API completely. >>>> >>>> The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT >>>> removal. Is it included by mistake? >>> >>> No. The JSDT implementation depends on com.sun.tracing API (it >>> implements it) and it must be removed together with the API. >> >> Ah I see. In that case you seem to have overlooked the removal of: >> >> jdk/src/jdk.runtime/unix/native/libjsdt/jvm_symbols_md.c >> jdk/src/jdk.runtime/windows/native/libjsdt/jvm_symbols_md.c > > ... and they are gone - > http://cr.openjdk.java.net/~jbachorik/8062303/webrev.02/ > > I re-ran the tests successfully. > > -JB- > >> >> Thanks, >> David >> >>> The request for the removal of the hotspot JSDT integration was reviewed >>> in >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html >>> >>> >>> >>> -JB- >>> >>>> >>>> Otherwise seems like a complete removal from the OpenJDK sources. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> > From chris.plummer at oracle.com Fri Feb 6 02:49:36 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 05 Feb 2015 18:49:36 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54ADC152.6000706@oracle.com> References: <54ADC152.6000706@oracle.com> Message-ID: <54D42BC0.3010502@oracle.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- $> jcmd NeverExit help VM.class_hierarchy 25101: VM.class_hierarchy Print a list of all loaded classes, indented to show the class hiearchy. Impact: Medium: Depends on number of loaded classes. Syntax : VM.class_hierarchy [options] [] Arguments: classname : [optional] Name of class whose hierarchy should be printed. If not specified, all class hierarchies are printed. (STRING, no default value) Options: (options must be specified using the or = syntax) -i : [optional] Inherited interfaces should be printed. (BOOLEAN, false) -s : [optional] If a classname is specified, print its subclasses. Otherwise only it superclasses are printed. (BOOLEAN, false) $> jcmd NeverExit VM.class_hierarchy java.lang.Error 25101: java.lang.Object (0x080609c8) |--java.lang.Throwable (0x080609c8) | |--java.lang.Error (0x080609c8) $> jcmd NeverExit VM.class_hierarchy java.lang.Error -i 25101: java.lang.Object (0x080609c8) |--java.lang.Throwable (0x080609c8) | implements java.io.Serializable (declared intf) | |--java.lang.Error (0x080609c8) | | implements java.io.Serializable (transitive intf) $> jcmd NeverExit VM.class_hierarchy java.lang.Error -s 25101: java.lang.Object (0x080609c8) |--java.lang.Throwable (0x080609c8) | |--java.lang.Error (0x080609c8) | | |--java.lang.VirtualMachineError (0x080609c8) | | | |--java.lang.StackOverflowError (0x080609c8) | | | |--java.lang.OutOfMemoryError (0x080609c8) | | |--java.lang.LinkageError (0x080609c8) | | | |--java.lang.IncompatibleClassChangeError (0x080609c8) | | | | |--java.lang.NoSuchMethodError (0x080609c8) | | | |--java.lang.BootstrapMethodError (0x080609c8) | | | |--java.lang.NoClassDefFoundError (0x080609c8) | | |--java.lang.ThreadDeath (0x080609c8) $> jcmd NeverExit VM.class_hierarchy java.lang.Error -s -i 25101: java.lang.Object (0x080609c8) |--java.lang.Throwable (0x080609c8) | implements java.io.Serializable (declared intf) | |--java.lang.Error (0x080609c8) | | implements java.io.Serializable (transitive intf) | | |--java.lang.VirtualMachineError (0x080609c8) | | | implements java.io.Serializable (transitive intf) | | | |--java.lang.StackOverflowError (0x080609c8) | | | | implements java.io.Serializable (transitive intf) | | | |--java.lang.OutOfMemoryError (0x080609c8) | | | | implements java.io.Serializable (transitive intf) | | |--java.lang.LinkageError (0x080609c8) | | | implements java.io.Serializable (transitive intf) | | | |--java.lang.IncompatibleClassChangeError (0x080609c8) | | | | implements java.io.Serializable (transitive intf) | | | | |--java.lang.NoSuchMethodError (0x080609c8) | | | | | implements java.io.Serializable (transitive intf) | | | |--java.lang.BootstrapMethodError (0x080609c8) | | | | implements java.io.Serializable (transitive intf) | | | |--java.lang.NoClassDefFoundError (0x080609c8) | | | | implements java.io.Serializable (transitive intf) | | |--java.lang.ThreadDeath (0x080609c8) | | | implements java.io.Serializable (transitive intf) yolanda:/myws/hotspot/jdk9/hs-rt/hotspot> jcmd NeverExit VM.class_hierarchy 25101: java.lang.Object (0x080609c8) |--java.net.Parts (0x080609c8) |--java.nio.charset.spi.CharsetProvider (0x080609c8) | |--sun.nio.cs.FastCharsetProvider (0x080609c8) | | |--sun.nio.cs.StandardCharsets (0x080609c8) |--java.lang.Number (0x080609c8) | |--java.lang.Float (0x080609c8) | |--java.lang.Long (0x080609c8) | |--java.util.concurrent.atomic.AtomicLong (0x080609c8) | |--java.lang.Integer (0x080609c8) | |--java.util.concurrent.atomic.AtomicInteger (0x080609c8) | |--java.lang.Short (0x080609c8) | |--java.lang.Byte (0x080609c8) | |--java.lang.Double (0x080609c8) |--java.nio.channels.spi.AbstractInterruptibleChannel (0x080609c8) | |--java.nio.channels.FileChannel (0x080609c8) | | |--sun.nio.ch.FileChannelImpl (0x080609c8) |--java.nio.file.Path (0x080609c8, intf) |--java.lang.reflect.Parameter (0x080609c8) |--java.nio.channels.InterruptibleChannel (0x080609c8, intf) |--sun.misc.SharedSecrets (0x080609c8) |--java.lang.invoke.CallSite (0x080609c8) | |--java.lang.invoke.VolatileCallSite (0x080609c8) | |--java.lang.invoke.MutableCallSite (0x080609c8) | |--java.lang.invoke.ConstantCallSite (0x080609c8) |--java.util.concurrent.atomic.AtomicReferenceFieldUpdater (0x080609c8) | |--java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl (0x080609c8) |--sun.nio.cs.ArrayDecoder (0x080609c8, intf) |--java.nio.file.Watchable (0x080609c8, intf) |--sun.misc.PerfCounter$CoreCounters (0x080609c8) |--java.lang.invoke.MethodHandle (0x080609c8) | |--java.lang.invoke.DirectMethodHandle (0x080609c8) |--sun.misc.Perf (0x080609c8) |--java.lang.Enum (0x080609c8) | |--sun.launcher.LauncherHelper (0x080609c8) | |--java.io.File$PathStatus (0x080609c8) |--java.lang.CharacterData (0x080609c8) | |--java.lang.CharacterDataLatin1 (0x080609c8) |--java.nio.channels.ScatteringByteChannel (0x080609c8, intf) |--java.lang.StringCoding$StringDecoder (0x080609c8) |--java.lang.Character (0x080609c8) |--java.nio.channels.GatheringByteChannel (0x080609c8, intf) |--java.lang.reflect.ReflectAccess (0x080609c8) |--java.nio.channels.SeekableByteChannel (0x080609c8, intf) |--java.lang.ref.Reference$1 (0x080609c8) |--java.util.BitSet (0x080609c8) |--sun.misc.Launcher$AppClassLoader$1 (0x080609c8) |--java.lang.ref.Reference (0x080609c8) | |--java.lang.ref.PhantomReference (0x080609c8) | | |--sun.misc.Cleaner (0x080609c8) | |--java.lang.ref.FinalReference (0x080609c8) | | |--java.lang.ref.Finalizer (0x080609c8) | |--java.lang.ref.WeakReference (0x080609c8) | | |--java.lang.ThreadLocal$ThreadLocalMap$Entry (0x080609c8) | | |--java.lang.ClassValue$Entry (0x080609c8) | | |--java.util.WeakHashMap$Entry (0x080609c8) | |--java.lang.ref.SoftReference (0x080609c8) | | |--sun.util.locale.LocaleObjectCache$CacheEntry (0x080609c8) |--java.lang.String$CaseInsensitiveComparator (0x080609c8) |--sun.misc.JavaLangRefAccess (0x080609c8, intf) |--java.nio.channels.ByteChannel (0x080609c8, intf) |--java.lang.ref.Reference$Lock (0x080609c8) |--java.nio.channels.WritableByteChannel (0x080609c8, intf) |--java.util.Comparator (0x080609c8, intf) |--java.io.InputStream (0x080609c8) | |--java.io.FilterInputStream (0x080609c8) | | |--java.io.BufferedInputStream (0x080609c8) | |--java.io.ByteArrayInputStream (0x080609c8) | |--java.io.FileInputStream (0x080609c8) |--java.nio.channels.ReadableByteChannel (0x080609c8, intf) |--java.lang.Cloneable (0x080609c8, intf) |--java.lang.ref.ReferenceQueue$Lock (0x080609c8) |--sun.reflect.LangReflectAccess (0x080609c8, intf) |--java.lang.invoke.MethodType (0x080609c8) |--java.nio.channels.Channel (0x080609c8, intf) |--java.nio.charset.Charset (0x080609c8) | |--sun.nio.cs.Unicode (0x080609c8) | | |--sun.nio.cs.UTF_8 (0x080609c8) |--sun.misc.Perf$GetPerfAction (0x080609c8) |--java.lang.Class (0x080609c8) |--sun.reflect.ReflectionFactory (0x080609c8) |--sun.misc.PostVMInitHook (0x080609c8) |--java.lang.Readable (0x080609c8, intf) |--java.lang.ThreadLocal$ThreadLocalMap (0x080609c8) |--java.io.Closeable (0x080609c8, intf) |--sun.misc.PerfCounter (0x080609c8) |--sun.util.locale.LocaleUtils (0x080609c8) |--java.lang.AutoCloseable (0x080609c8, intf) |--java.lang.ref.ReferenceQueue (0x080609c8) | |--java.lang.ref.ReferenceQueue$Null (0x080609c8) |--java.lang.reflect.Modifier (0x080609c8) |--java.util.concurrent.ConcurrentMap (0x080609c8, intf) |--java.lang.Void (0x080609c8) |--java.io.OutputStream (0x080609c8) | |--java.io.FileOutputStream (0x080609c8) | |--java.io.FilterOutputStream (0x080609c8) | | |--java.io.BufferedOutputStream (0x080609c8) | | |--java.io.PrintStream (0x080609c8) |--java.util.Collections$SynchronizedMap (0x080609c8) |--java.io.Flushable (0x080609c8, intf) |--sun.misc.Unsafe (0x080609c8) |--java.lang.reflect.Member (0x080609c8, intf) |--java.io.FileInputStream$1 (0x080609c8) |--java.lang.Class$MethodArray (0x080609c8) |--java.lang.invoke.MethodHandleStatics$1 (0x080609c8) |--java.io.ObjectStreamField (0x080609c8) |--sun.nio.ByteBuffered (0x080609c8, intf) |--java.util.Locale$LocaleKey (0x080609c8) |--java.security.Principal (0x080609c8, intf) |--java.lang.invoke.MethodHandleStatics (0x080609c8) |--sun.misc.Resource (0x080609c8) | |--sun.misc.URLClassPath$FileLoader$1 (0x080609c8) |--java.lang.reflect.AccessibleObject (0x080609c8) | |--java.lang.reflect.Field (0x080609c8) | |--java.lang.reflect.Executable (0x080609c8) | | |--java.lang.reflect.Constructor (0x080609c8) | | |--java.lang.reflect.Method (0x080609c8) |--java.lang.StringCoding (0x080609c8) |--java.security.ProtectionDomain$Key (0x080609c8) |--java.util.Collections$UnmodifiableCollection (0x080609c8) | |--java.util.Collections$UnmodifiableList (0x080609c8) | | |--java.util.Collections$UnmodifiableRandomAccessList (0x080609c8) |--java.io.ExpiringCache (0x080609c8) |--sun.util.locale.BaseLocale$Key (0x080609c8) |--java.util.concurrent.atomic.AtomicBoolean (0x080609c8) |--java.security.ProtectionDomain$3 (0x080609c8) |--sun.misc.JavaSecurityProtectionDomainAccess (0x080609c8, intf) |--java.lang.Math (0x080609c8) |--java.util.ArrayList$Itr (0x080609c8) |--java.security.ProtectionDomain$1 (0x080609c8) |--java.lang.invoke.MemberName$Factory (0x080609c8) |--java.security.AccessControlContext (0x080609c8) |--sun.misc.JavaSecurityAccess (0x080609c8, intf) |--java.util.Dictionary (0x080609c8) | |--java.util.Hashtable (0x080609c8) | | |--java.util.Properties (0x080609c8) |--sun.net.www.ParseUtil (0x080609c8) |--java.io.FileDescriptor$1 (0x080609c8) |--java.util.AbstractCollection (0x080609c8) | |--java.util.AbstractList (0x080609c8) | | |--java.util.Vector (0x080609c8) | | | |--java.util.Stack (0x080609c8) | | |--java.util.Collections$EmptyList (0x080609c8) | | |--java.util.ArrayList (0x080609c8) | |--java.util.AbstractSet (0x080609c8) | | |--java.util.WeakHashMap$KeySet (0x080609c8) | | |--java.util.Collections$SetFromMap (0x080609c8) | | |--java.util.HashSet (0x080609c8) | | |--java.util.Collections$EmptySet (0x080609c8) | | |--java.util.Hashtable$EntrySet (0x080609c8) |--sun.util.locale.LocaleObjectCache (0x080609c8) | |--java.util.Locale$Cache (0x080609c8) | |--sun.util.locale.BaseLocale$Cache (0x080609c8) |--java.nio.charset.CharsetEncoder (0x080609c8) | |--sun.nio.cs.UTF_8$Encoder (0x080609c8) |--java.io.FileSystem (0x080609c8) | |--java.io.UnixFileSystem (0x080609c8) |--sun.misc.Launcher$ExtClassLoader$1 (0x080609c8) |--sun.misc.JavaIOFileDescriptorAccess (0x080609c8, intf) |--java.lang.Boolean (0x080609c8) |--java.net.URLClassLoader$7 (0x080609c8) |--java.io.FileDescriptor (0x080609c8) |--sun.misc.JavaNetAccess (0x080609c8, intf) |--sun.util.locale.BaseLocale (0x080609c8) |--java.lang.invoke.LambdaForm (0x080609c8) |--java.util.concurrent.locks.AbstractQueuedSynchronizer$Node (0x080609c8) |--java.lang.ClassValue$Version (0x080609c8) |--java.util.AbstractMap (0x080609c8) | |--java.util.WeakHashMap (0x080609c8) | | |--java.lang.ClassValue$ClassValueMap (0x080609c8) | |--java.util.Collections$EmptyMap (0x080609c8) | |--java.util.HashMap (0x080609c8) | | |--java.util.LinkedHashMap (0x080609c8) | | | |--java.io.ExpiringCache$1 (0x080609c8) | |--java.util.concurrent.ConcurrentHashMap (0x080609c8) | |--sun.util.PreHashedMap (0x080609c8) | | |--sun.nio.cs.StandardCharsets$Cache (0x080609c8) | | |--sun.nio.cs.StandardCharsets$Classes (0x080609c8) | | |--sun.nio.cs.StandardCharsets$Aliases (0x080609c8) |--sun.reflect.ReflectionFactory$1 (0x080609c8) |--java.nio.Buffer (0x080609c8) | |--java.nio.CharBuffer (0x080609c8) | | |--java.nio.HeapCharBuffer (0x080609c8) | |--java.nio.ByteBuffer (0x080609c8) | | |--java.nio.MappedByteBuffer (0x080609c8) | | | |--java.nio.DirectByteBuffer (0x080609c8) | | | | |--java.nio.DirectByteBufferR (0x080609c8) | | |--java.nio.HeapByteBuffer (0x080609c8) | |--java.nio.IntBuffer (0x080609c8) | | |--java.nio.ByteBufferAsIntBufferB (0x080609c8) | | |--java.nio.DirectIntBufferU (0x080609c8) | | | |--java.nio.DirectIntBufferRU (0x080609c8) | |--java.nio.LongBuffer (0x080609c8) | | |--java.nio.DirectLongBufferU (0x080609c8) |--java.lang.ClassValue$Identity (0x080609c8) |--java.util.Locale (0x080609c8) |--sun.reflect.CallerSensitive (0x080609c8, intf) |--java.lang.annotation.Annotation (0x080609c8, intf) |--java.lang.Class$1 (0x080609c8) |--sun.nio.ch.DirectBuffer (0x080609c8, intf) |--java.security.ProtectionDomain (0x080609c8) |--java.util.concurrent.locks.AbstractOwnableSynchronizer (0x080609c8) | |--java.util.concurrent.locks.AbstractQueuedSynchronizer (0x080609c8) | | |--java.util.concurrent.locks.ReentrantLock$Sync (0x080609c8) | | | |--java.util.concurrent.locks.ReentrantLock$NonfairSync (0x080609c8) |--jdk.internal.jimage.concurrent.ConcurrentPReader$TemporaryBuffer (0x080609c8) |--java.lang.StackTraceElement (0x080609c8) |--java.lang.ClassValue (0x080609c8) | |--java.lang.invoke.MethodHandleImpl$4 (0x080609c8) |--sun.reflect.annotation.AnnotationType (0x080609c8) |--sun.nio.ch.Util$4 (0x080609c8) |--sun.nio.cs.ArrayEncoder (0x080609c8, intf) |--sun.reflect.FieldAccessor (0x080609c8, intf) |--java.lang.reflect.Type (0x080609c8, intf) |--java.io.DefaultFileSystem (0x080609c8) |--jdk.internal.jimage.PReader (0x080609c8) | |--jdk.internal.jimage.concurrent.ConcurrentPReader (0x080609c8) |--sun.nio.cs.HistoricallyNamedCharset (0x080609c8, intf) |--sun.misc.MetaIndex (0x080609c8) |--java.util.Hashtable$Entry (0x080609c8) |--sun.misc.Version (0x080609c8) |--java.util.Map (0x080609c8, intf) |--java.security.CodeSource (0x080609c8) |--java.lang.reflect.GenericDeclaration (0x080609c8, intf) |--sun.security.action.GetPropertyAction (0x080609c8) |--jdk.internal.jimage.ImageLocation (0x080609c8) |--java.lang.reflect.AnnotatedElement (0x080609c8, intf) |--java.io.FilePermission$1 (0x080609c8) |--java.lang.SecurityManager (0x080609c8) |--sun.nio.ch.Util (0x080609c8) |--java.lang.Class$AnnotationData (0x080609c8) |--jdk.internal.jimage.UTF8String (0x080609c8) |--java.lang.invoke.MethodHandleImpl$3 (0x080609c8) |--java.util.concurrent.ConcurrentHashMap$CollectionView (0x080609c8) | |--java.util.concurrent.ConcurrentHashMap$EntrySetView (0x080609c8) | |--java.util.concurrent.ConcurrentHashMap$ValuesView (0x080609c8) | |--java.util.concurrent.ConcurrentHashMap$KeySetView (0x080609c8) |--sun.reflect.generics.repository.AbstractRepository (0x080609c8) | |--sun.reflect.generics.repository.GenericDeclRepository (0x080609c8) | | |--sun.reflect.generics.repository.ClassRepository (0x080609c8) |--java.lang.ClassLoader$ParallelLoaders (0x080609c8) |--java.lang.invoke.MethodHandleImpl$2 (0x080609c8) |--java.util.function.Function (0x080609c8, intf) |--sun.misc.VM (0x080609c8) |--java.lang.Runtime (0x080609c8) |--sun.security.util.Debug (0x080609c8) |--java.nio.Bits$1 (0x080609c8) |--sun.misc.Launcher (0x080609c8) |--java.util.RandomAccess (0x080609c8, intf) |--sun.nio.ch.FileChannelImpl$Unmapper (0x080609c8) |--java.util.Arrays (0x080609c8) |--java.lang.invoke.MethodHandleImpl$1 (0x080609c8) |--java.util.List (0x080609c8, intf) |--sun.misc.JavaNioAccess (0x080609c8, intf) |--sun.misc.Launcher$BootClassPathHolder$1 (0x080609c8) |--java.util.Set (0x080609c8, intf) |--sun.reflect.ConstantPool (0x080609c8) |--jdk.internal.jimage.PackageModuleMap (0x080609c8) |--sun.nio.ch.NativeThread (0x080609c8) |--sun.misc.Launcher$BootClassPathHolder (0x080609c8) |--java.lang.String (0x080609c8) |--sun.net.www.MessageHeader (0x080609c8) |--java.lang.Class$Atomic (0x080609c8) |--java.util.jar.Manifest (0x080609c8) |--java.util.concurrent.ConcurrentHashMap$CounterCell (0x080609c8) |--java.nio.channels.spi.AbstractInterruptibleChannel$1 (0x080609c8) |--java.io.Writer (0x080609c8) | |--java.io.BufferedWriter (0x080609c8) | |--sun.nio.cs.StreamEncoder (0x080609c8) | |--java.io.OutputStreamWriter (0x080609c8) |--java.util.Collection (0x080609c8, intf) |--jdk.internal.jimage.ImageStream (0x080609c8) |--sun.nio.ch.Interruptible (0x080609c8, intf) |--java.util.concurrent.ConcurrentHashMap$Node (0x080609c8) |--java.lang.invoke.MethodHandleImpl (0x080609c8) |--jdk.internal.jimage.BasicImageReader (0x080609c8) | |--jdk.internal.jimage.ImageReader (0x080609c8) |--java.lang.AbstractStringBuilder (0x080609c8) | |--java.lang.StringBuilder (0x080609c8) | |--java.lang.StringBuffer (0x080609c8) |--java.lang.Class$ReflectionData (0x080609c8) |--java.nio.channels.FileChannel$MapMode (0x080609c8) |--java.util.Hashtable$Enumerator (0x080609c8) |--java.util.HashMap$Node (0x080609c8) | |--java.util.LinkedHashMap$Entry (0x080609c8) | | |--java.util.HashMap$TreeNode (0x080609c8) |--java.lang.Iterable (0x080609c8, intf) |--java.lang.Class$3 (0x080609c8) |--java.lang.System$2 (0x080609c8) |--java.nio.ByteOrder (0x080609c8) |--jdk.internal.jimage.ImageHeader (0x080609c8) |--java.util.Iterator (0x080609c8, intf) |--java.util.Map$Entry (0x080609c8, intf) |--sun.reflect.ConstructorAccessor (0x080609c8, intf) |--java.net.URL (0x080609c8) |--java.util.concurrent.locks.ReentrantLock (0x080609c8) | |--java.util.concurrent.ConcurrentHashMap$Segment (0x080609c8) |--java.util.Collections (0x080609c8) |--java.util.Enumeration (0x080609c8, intf) |--sun.misc.Launcher$Factory (0x080609c8) |--java.util.concurrent.CopyOnWriteArrayList (0x080609c8) |--sun.reflect.MethodAccessor (0x080609c8, intf) |--java.lang.ThreadGroup (0x080609c8) |--sun.misc.JavaLangAccess (0x080609c8, intf) |--sun.reflect.MagicAccessorImpl (0x080609c8) | |--sun.reflect.FieldAccessorImpl (0x080609c8) | | |--sun.reflect.UnsafeFieldAccessorImpl (0x080609c8) | | | |--sun.reflect.UnsafeStaticFieldAccessorImpl (0x080609c8) | |--sun.reflect.ConstructorAccessorImpl (0x080609c8) | | |--sun.reflect.DelegatingConstructorAccessorImpl (0x080609c8) | | |--sun.reflect.NativeConstructorAccessorImpl (0x080609c8) | |--sun.reflect.MethodAccessorImpl (0x080609c8) |--java.net.URLStreamHandlerFactory (0x080609c8, intf) |--java.util.Objects (0x080609c8) |--java.nio.Bits (0x080609c8) |--java.lang.Throwable (0x080609c8) | |--java.lang.Exception (0x080609c8) | | |--java.lang.InterruptedException (0x080609c8) | | |--java.lang.ReflectiveOperationException (0x080609c8) | | | |--java.lang.ClassNotFoundException (0x080609c8) | | |--java.io.IOException (0x080609c8) | | |--java.lang.RuntimeException (0x080609c8) | | | |--java.lang.IllegalMonitorStateException (0x080609c8) | | | |--java.lang.ArrayStoreException (0x080609c8) | | | |--java.lang.ClassCastException (0x080609c8) | | | |--java.lang.ArithmeticException (0x080609c8) | | | |--java.lang.NullPointerException (0x080609c8) | | | |--java.lang.IllegalArgumentException (0x080609c8) | |--java.lang.Error (0x080609c8) | | |--java.lang.VirtualMachineError (0x080609c8) | | | |--java.lang.StackOverflowError (0x080609c8) | | | |--java.lang.OutOfMemoryError (0x080609c8) | | |--java.lang.LinkageError (0x080609c8) | | | |--java.lang.IncompatibleClassChangeError (0x080609c8) | | | | |--java.lang.NoSuchMethodError (0x080609c8) | | | |--java.lang.BootstrapMethodError (0x080609c8) | | | |--java.lang.NoClassDefFoundError (0x080609c8) | | |--java.lang.ThreadDeath (0x080609c8) |--jdk.internal.jimage.ImageStrings (0x080609c8) |--java.security.cert.Certificate (0x080609c8) |--java.util.concurrent.locks.Lock (0x080609c8, intf) |--java.lang.invoke.MethodHandleNatives (0x080609c8) |--sun.nio.ch.NativeDispatcher (0x080609c8) | |--sun.nio.ch.FileDispatcher (0x080609c8) | | |--sun.nio.ch.FileDispatcherImpl (0x080609c8) |--sun.misc.URLClassPath (0x080609c8) |--java.lang.ThreadLocal (0x080609c8) | |--jdk.internal.jimage.concurrent.ConcurrentPReader$TemporaryBuffer$1 (0x080609c8) | |--sun.nio.ch.Util$1 (0x080609c8) |--sun.misc.OSEnvironment (0x080609c8) |--sun.reflect.ReflectionFactory$GetReflectionFactoryAction (0x080609c8) |--java.util.Collections$SynchronizedCollection (0x080609c8) | |--java.util.Collections$SynchronizedSet (0x080609c8) |--java.io.ObjectStreamClass (0x080609c8) |--java.security.PrivilegedAction (0x080609c8, intf) |--java.lang.Integer$IntegerCache (0x080609c8) |--java.lang.Appendable (0x080609c8, intf) |--sun.misc.NativeSignalHandler (0x080609c8) |--java.lang.System (0x080609c8) |--java.lang.Thread$UncaughtExceptionHandler (0x080609c8, intf) |--sun.misc.Signal (0x080609c8) |--java.security.PermissionCollection (0x080609c8) | |--java.security.BasicPermissionCollection (0x080609c8) | |--java.io.FilePermissionCollection (0x080609c8) | |--java.security.Permissions (0x080609c8) |--sun.nio.ch.NativeThreadSet (0x080609c8) |--sun.misc.URLClassPath$Loader (0x080609c8) | |--sun.misc.URLClassPath$FileLoader (0x080609c8) | |--sun.misc.URLClassPath$JImageLoader (0x080609c8) |--java.lang.Thread (0x080609c8) | |--java.lang.ref.Reference$ReferenceHandler (0x080609c8) | |--java.lang.ref.Finalizer$FinalizerThread (0x080609c8) | |--sun.misc.InnocuousThread (0x080609c8) |--NeverExit (0xa533bfe0) |--java.net.URLStreamHandler (0x080609c8) | |--sun.net.www.protocol.jar.Handler (0x080609c8) | |--sun.net.www.protocol.file.Handler (0x080609c8) |--java.lang.invoke.MemberName (0x080609c8) |--NE2 (0xa533bfe0, intf) |--NE1 (0xa533bfe0, intf) |--java.lang.Terminator$1 (0x080609c8) |--sun.nio.ch.IOUtil$1 (0x080609c8) |--sun.misc.SignalHandler (0x080609c8, intf) |--java.lang.CharSequence (0x080609c8, intf) |--java.lang.Terminator (0x080609c8) |--java.nio.charset.CodingErrorAction (0x080609c8) |--java.nio.charset.CoderResult$Cache (0x080609c8) | |--java.nio.charset.CoderResult$2 (0x080609c8) | |--java.nio.charset.CoderResult$1 (0x080609c8) |--sun.nio.ch.IOUtil (0x080609c8) |--sun.net.www.protocol.jrt.JavaRuntimeURLConnection$ResourceFinder (0x080609c8, intf) |--java.lang.Comparable (0x080609c8, intf) |--java.security.AccessController (0x080609c8) |--java.io.Serializable (0x080609c8, intf) |--java.lang.ClassLoader (0x080609c8) | |--java.security.SecureClassLoader (0x080609c8) | | |--java.net.URLClassLoader (0x080609c8) | | | |--sun.misc.Launcher$AppClassLoader (0x080609c8) | | | |--sun.misc.Launcher$ExtClassLoader (0x080609c8) | |--sun.reflect.DelegatingClassLoader (0x080609c8) |--java.io.ExpiringCache$Entry (0x080609c8) |--java.nio.charset.CoderResult (0x080609c8) |--sun.reflect.misc.ReflectUtil (0x080609c8) |--sun.misc.URLClassPath$3 (0x080609c8) |--java.nio.charset.CharsetDecoder (0x080609c8) | |--sun.nio.cs.UTF_8$Decoder (0x080609c8) |--java.net.URLConnection (0x080609c8) | |--sun.net.www.URLConnection (0x080609c8) | | |--sun.net.www.protocol.file.FileURLConnection (0x080609c8) | | |--sun.net.www.protocol.jrt.JavaRuntimeURLConnection (0x080609c8) |--sun.net.util.URLUtil (0x080609c8) |--java.io.File (0x080609c8) |--java.lang.ClassLoader$3 (0x080609c8) |--sun.reflect.Reflection (0x080609c8) |--java.net.URLClassLoader$1 (0x080609c8) |--java.util.StringTokenizer (0x080609c8) |--java.lang.StringCoding$StringEncoder (0x080609c8) |--java.nio.file.attribute.FileAttribute (0x080609c8, intf) |--java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl$1 (0x080609c8) |--java.security.Permission (0x080609c8) | |--java.security.UnresolvedPermission (0x080609c8) | |--java.security.AllPermission (0x080609c8) | |--java.io.FilePermission (0x080609c8) | |--java.security.BasicPermission (0x080609c8) | | |--java.lang.reflect.ReflectPermission (0x080609c8) | | |--java.lang.RuntimePermission (0x080609c8) |--java.security.PrivilegedExceptionAction (0x080609c8, intf) |--sun.nio.ch.IOStatus (0x080609c8) |--java.lang.Runnable (0x080609c8, intf) |--java.security.Guard (0x080609c8, intf) |--java.lang.SystemClassLoaderAction (0x080609c8) |--java.lang.ClassLoader$NativeLibrary (0x080609c8) From chris.plummer at oracle.com Fri Feb 6 03:01:35 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 05 Feb 2015 19:01:35 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D42BC0.3010502@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> Message-ID: <54D42E8F.9030003@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Feb 6 04:49:12 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 05 Feb 2015 20:49:12 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D42BC0.3010502@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> Message-ID: <54D447C8.4010107@oracle.com> [Hmm. My previous email somehow included the attachment with the dcmd output, but not the body of the message, so here it is again.] Hey Folks, Sorry about the delay in getting the next webrev for this out. I was sidetracked by a few other things, including being out sick of almost a week, and there were also quite a few changes to make. I'm ready for review with an updated webrev, but thought first I'd have you look at and comment on the output. Please see the attached file. It now supports: printing the hierarchy for a single class optionally including all subclasses of the specified class (-s) for each class, also list all of its interfaces (-i) The hex value in the output is the address of the ClassLoaderData for the ClassLoader of the class. I did not include the address of the Klass, but could if you think it would be useful. Changing the format of what comes after the classname is easy. Just let me know what you think is best. I have not updated any other dcmds to be consistent with how classes are uniquely identified. A separate bug should be filed for that. Actually I thought one was, but I looked through this thread's history and could not find mention of it. I also have not implemented the reverse hierarchy dcmd. JDK-8068830 has already been filed for that, but there are no plans to work on it in the near term. thanks, Chris From david.holmes at oracle.com Fri Feb 6 05:16:22 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Feb 2015 15:16:22 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54D389A1.2010104@oracle.com> References: <54D24EEC.4090303@oracle.com> <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> <54D389A1.2010104@oracle.com> Message-ID: <54D44E26.9010500@oracle.com> On 6/02/2015 1:17 AM, Jaroslav Bachorik wrote: > On 5.2.2015 14:55, Staffan Larsen wrote: >> Jaroslav, >> >> This looks good, just a few small comments: >> >> writableFlags.hpp: >> >> L25 #ifndef WritableFlags_HPP >> L26 #define WritableFlags_HPP >> L96 #endif /* WritableFlags_HPP */ >> Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP >> >> L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer >> ?SUCCESS? instead. >> >> writableFlags.cpp: >> >> L25: #include statements should be in alphabetical order if possible >> L166: (nit) missing empty line >> L155: I notice the Flag class uses ?writeable? (with an ?e?) and this >> class uses ?writable? (without ?e?) - My english isn?t good enough to >> tell if there is any difference. > > They should be equal in meaning. According to GooglBattle [1] the form > 'writable' is far wider spread but I would leave the decision to a > native speaker. > > [1] > http://www.googlebattle.com/index.php?domain=writeable&domain2=writable&submit=Go! > > >> L194: Unused variable ?succeed" > > The rest of the comments will be addressed. I will wait for eg. David to > comment on 'writable' vs. 'writeable' before regenerating the webrev. Take your pick. Both are used in the hotspot sources eg globals.hpp contains is_writeable() and check_writable() :( It is on my TODO list to review this ASAP. David > -JB- > >> >> >> Thanks, >> /Staffan >> >>> On 4 feb 2015, at 17:55, Jaroslav Bachorik >>> wrote: >>> >>> Hi, this is a round 2 review of the proposed solution. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 >>> >>> This patch is a precursor for implementing >>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>> part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>> >>> Here, the code related to manipulating JVM flags is extracted to a >>> separate WritableFlags class and the codebease is adjusted to use >>> this class. >>> >>> I didn't touch the original (nonstandard) handling of the DTrace >>> specific flags in the Solaris specific attachListener.cpp >>> implementation to keep the change simple and focused. >>> >>> Thanks, >>> >>> -JB- >> > From staffan.larsen at oracle.com Fri Feb 6 08:52:33 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 6 Feb 2015 09:52:33 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D447C8.4010107@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> Message-ID: I think this looks good! Perhaps we should give a hint as to what the hex value is? I don?t know if it is best to print this as part of a ?header? printed before the rest of the output or if we should include it as part of each line ?(classloaderdata*=0x080609c8)?. /Staffan > On 6 feb 2015, at 05:49, Chris Plummer wrote: > > [Hmm. My previous email somehow included the attachment with the dcmd output, but not the body of the message, so here it is again.] > > Hey Folks, > > Sorry about the delay in getting the next webrev for this out. I was sidetracked by a few other things, including being out sick of almost a week, and there were also quite a few changes to make. > > I'm ready for review with an updated webrev, but thought first I'd have you look at and comment on the output. Please see the attached file. It now supports: > > printing the hierarchy for a single class > optionally including all subclasses of the specified class (-s) > for each class, also list all of its interfaces (-i) > > The hex value in the output is the address of the ClassLoaderData for the ClassLoader of the class. I did not include the address of the Klass, but could if you think it would be useful. Changing the format of what comes after the classname is easy. Just let me know what you think is best. > > I have not updated any other dcmds to be consistent with how classes are uniquely identified. A separate bug should be filed for that. Actually I thought one was, but I looked through this thread's history and could not find mention of it. I also have not implemented the reverse hierarchy dcmd. JDK-8068830 has already been filed for that, but there are no plans to work on it in the near term. > > thanks, > > Chris From roland.westrelin at oracle.com Fri Feb 6 10:42:23 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 6 Feb 2015 11:42:23 +0100 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <19091E69-AB1E-4CEF-9491-790D593C8E68@oracle.com> References: <877fvxhg67.fsf@oracle.com> <19091E69-AB1E-4CEF-9491-790D593C8E68@oracle.com> Message-ID: Hi Chris, > Since you?re saying it only fixes it partially should we file a followup bug and maybe leave a comment behind? Actually I don?t know if it?s partial or not. I don?t understand default methods enough to be sure. Roland. From jaroslav.bachorik at oracle.com Fri Feb 6 11:54:32 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 06 Feb 2015 12:54:32 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54D44E26.9010500@oracle.com> References: <54D24EEC.4090303@oracle.com> <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> <54D389A1.2010104@oracle.com> <54D44E26.9010500@oracle.com> Message-ID: <54D4AB78.3060300@oracle.com> On 6.2.2015 06:16, David Holmes wrote: > On 6/02/2015 1:17 AM, Jaroslav Bachorik wrote: >> On 5.2.2015 14:55, Staffan Larsen wrote: >>> Jaroslav, >>> >>> This looks good, just a few small comments: >>> >>> writableFlags.hpp: >>> >>> L25 #ifndef WritableFlags_HPP >>> L26 #define WritableFlags_HPP >>> L96 #endif /* WritableFlags_HPP */ >>> Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP >>> >>> L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer >>> ?SUCCESS? instead. >>> >>> writableFlags.cpp: >>> >>> L25: #include statements should be in alphabetical order if possible >>> L166: (nit) missing empty line >>> L155: I notice the Flag class uses ?writeable? (with an ?e?) and this >>> class uses ?writable? (without ?e?) - My english isn?t good enough to >>> tell if there is any difference. >> >> They should be equal in meaning. According to GooglBattle [1] the form >> 'writable' is far wider spread but I would leave the decision to a >> native speaker. >> >> [1] >> http://www.googlebattle.com/index.php?domain=writeable&domain2=writable&submit=Go! >> >> >> >>> L194: Unused variable ?succeed" >> >> The rest of the comments will be addressed. I will wait for eg. David to >> comment on 'writable' vs. 'writeable' before regenerating the webrev. > > Take your pick. Both are used in the hotspot sources eg globals.hpp > contains is_writeable() and check_writable() :( > > It is on my TODO list to review this ASAP. Taffan's comments addressed - http://cr.openjdk.java.net/~jbachorik/8067447/webrev.03 -JB- > > David > > > >> -JB- >> >>> >>> >>> Thanks, >>> /Staffan >>> >>>> On 4 feb 2015, at 17:55, Jaroslav Bachorik >>>> wrote: >>>> >>>> Hi, this is a round 2 review of the proposed solution. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 >>>> >>>> This patch is a precursor for implementing >>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>> part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>> >>>> Here, the code related to manipulating JVM flags is extracted to a >>>> separate WritableFlags class and the codebease is adjusted to use >>>> this class. >>>> >>>> I didn't touch the original (nonstandard) handling of the DTrace >>>> specific flags in the Solaris specific attachListener.cpp >>>> implementation to keep the change simple and focused. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> From staffan.larsen at oracle.com Fri Feb 6 12:10:25 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 6 Feb 2015 13:10:25 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54D4AB78.3060300@oracle.com> References: <54D24EEC.4090303@oracle.com> <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> <54D389A1.2010104@oracle.com> <54D44E26.9010500@oracle.com> <54D4AB78.3060300@oracle.com> Message-ID: <8D46B50E-C266-4414-B2C0-261B3CA236A4@oracle.com> > On 6 feb 2015, at 12:54, Jaroslav Bachorik wrote: > > On 6.2.2015 06:16, David Holmes wrote: >> On 6/02/2015 1:17 AM, Jaroslav Bachorik wrote: >>> On 5.2.2015 14:55, Staffan Larsen wrote: >>>> Jaroslav, >>>> >>>> This looks good, just a few small comments: >>>> >>>> writableFlags.hpp: >>>> >>>> L25 #ifndef WritableFlags_HPP >>>> L26 #define WritableFlags_HPP >>>> L96 #endif /* WritableFlags_HPP */ >>>> Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP >>>> >>>> L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer >>>> ?SUCCESS? instead. >>>> >>>> writableFlags.cpp: >>>> >>>> L25: #include statements should be in alphabetical order if possible >>>> L166: (nit) missing empty line >>>> L155: I notice the Flag class uses ?writeable? (with an ?e?) and this >>>> class uses ?writable? (without ?e?) - My english isn?t good enough to >>>> tell if there is any difference. >>> >>> They should be equal in meaning. According to GooglBattle [1] the form >>> 'writable' is far wider spread but I would leave the decision to a >>> native speaker. >>> >>> [1] >>> http://www.googlebattle.com/index.php?domain=writeable&domain2=writable&submit=Go! >>> >>> >>> >>>> L194: Unused variable ?succeed" >>> >>> The rest of the comments will be addressed. I will wait for eg. David to >>> comment on 'writable' vs. 'writeable' before regenerating the webrev. >> >> Take your pick. Both are used in the hotspot sources eg globals.hpp >> contains is_writeable() and check_writable() :( >> >> It is on my TODO list to review this ASAP. > > Taffan's comments addressed - http://cr.openjdk.java.net/~jbachorik/8067447/webrev.03 (First time I?m called that :-) ) Looks good. I realize now that precompiled.hpp is special and should be included before anything else. I don?t need to see the fix before you push. Thanks, /Staffan > > -JB- > >> >> David >> >> >> >>> -JB- >>> >>>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 4 feb 2015, at 17:55, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>> Hi, this is a round 2 review of the proposed solution. >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 >>>>> >>>>> This patch is a precursor for implementing >>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>> part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>> >>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>> separate WritableFlags class and the codebease is adjusted to use >>>>> this class. >>>>> >>>>> I didn't touch the original (nonstandard) handling of the DTrace >>>>> specific flags in the Solaris specific attachListener.cpp >>>>> implementation to keep the change simple and focused. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Fri Feb 6 13:01:55 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 6 Feb 2015 14:01:55 +0100 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <54D3132C.1090107@oracle.com> References: <877fvxhg67.fsf@oracle.com> <54D3132C.1090107@oracle.com> Message-ID: Hi David, > I wouldn't say it "supports default methods" rather it ignores them so they don't trigger exceptions. I'm still puzzling over why default methods have a zero _codeIndex as that seems to be the real cause of the trouble. ?? I took another look and it turns out the test on _codeIndex is not required (at least with the core file I?m working on). Not sure why I found it was needed. So here is a new webrev that removes it: http://cr.openjdk.java.net/~roland/8071999/webrev.01/ That?s what I will push unless someone objects. Roland. From jaroslav.bachorik at oracle.com Fri Feb 6 14:54:21 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 06 Feb 2015 15:54:21 +0100 Subject: RFR 8071657:JDI ObjectReferenceImpl.invokeMethod() validation fails for virtual invocations of method with declaring type being an interface Message-ID: <54D4D59D.2080807@oracle.com> Please, review the following change in JDI implementation Issue : https://bugs.openjdk.java.net/browse/JDK-8071657 Webrev: http://cr.openjdk.java.net/~jbachorik/8071657/webrev.00 After JDK-8042123 has been integrated it became possible to make non-virtual calls to interface default or static methods via JDI. Unfortunately, when a virtual invocation of a method with its declaring type being an interface is attempted it fails validation. The code fails to distinguish virtual and non-virtual calls and always fails for non-default methods. The solution is to check to check for the call being non-virtual before enforcing the method to be default. Thanks, -JB- From chris.plummer at oracle.com Fri Feb 6 20:15:15 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 06 Feb 2015 12:15:15 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> Message-ID: <54D520D3.3070804@oracle.com> An HTML attachment was scrubbed... URL: From karen.kinnear at oracle.com Fri Feb 6 21:21:14 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 6 Feb 2015 16:21:14 -0500 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D520D3.3070804@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> <54D520D3.3070804@oracle.com> Message-ID: Chris, So I was curious - I was thinking you would printing the hex address of the j.l.ClassLoader class rather than the cld so that if folks were to look at a heap dump later it might be meaningful to them. Is it unlikely that they would ever want to correlate those? On Feb 6, 2015, at 3:15 PM, Chris Plummer wrote: > I was also thinking it might be a good idea to indicate what the hex value is, although still have figured out the best way of doing this. Maybe just a simple comment before the output. Keep in mind that eventually other DCMDS will also include the cld to help uniquiely identify classes across dcmd output. Also keep in mind your earlier suggestion: > > java.lang.Object/0x12345600 > |--java.io.Serializable/0x12345601 > |--java.util.RandomAccess/0x12345602 > |--java.lang.Iterable/0x12345603 > | |--java.util.Collection/0x12345604 > | | |--java.util.List/0x12345605 > |--java.util.AbstractCollection/0x12345606 > | | implements java.util.Collection/0x12345604 > | | implements java.lang.Iterable/0x12345603 > | |--java.util.AbstractList/0x12345607 > | | implements java.util.List/0x12345605 > | | |--java.util.Arrays$ArrayList/0x12345608 > | | | implements java.io.Serializable/0x12345601 > | | | implements java.util.RandomAccess/0x12345602 > > With additions to GC.class_stats: > > Index Super ClassLoader ClassName > 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 > 2 1 0x00000007c0034c48 java.util.List/0x12345605 > 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 > > And GC.class_histogram: > > num #instances #bytes class name > ---------------------------------------------- > 1: 945 117736 java.lang.Object/0x12345600 > 2: 442 50352 java.util.List/0x12345605 > 3: 499 25288 java.util.AbstractList/0x12345607 > > I think in your case you assumed we would create a unique identifier for each class, but then we settled on just classname + ClassLoader identifier of some sort, and the CLD* works for that. So replace your hex class ID in the above with the hex CLD*. > > Also something Karen had said is just now starting to sink in and make sense to me: > > |-sun.misc.Launcher$AppClassLoader/null (0xyyy) > |-myapp/0xyyy > > I think the idea here is that when printing a ClassLoader subclass, you include two CLDs. The first is for the ClassLoader that loaded the class, and the second is the CLD for the ClassLoader subclass itself. Thus the above indicates that myapp was loaded by 0xyyy, which is the sun.misc.Launcher$AppClassLoader, which was loaded by the null ClassLoader. I apologize - I don't remember what I said. But I am not sure we need that level of complexity. I think I was asking that one of the dcmds that gives information could print information like 0xabc "a sun.misc.Launcher$AppClassLoader" or "a WLS.blah.GenericClassLoader" if we don't want to include that everywhere. Mostly people want to know the name of the class loader. Since they don't yet have names, they want to know the type of the classloader. So that string "a MyClassLoader" would be more meaningful than the 0xabc - except that if they have 5 of those they need the uniqueness. So personally I think I was proposing the java.base, 0xA/"a MyClassLoader", iface). But I would defer to Staffan if he suggests something else. thanks for your patience, Karen > > With regard to the '/' format, keep in mind that we also need an indicator of whether or not it's an interface, and there's also a request to include the module name when that becomes available. At one point you requested the following, which is what I was aiming for: > > java.lang.Object > |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) > |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) > > So maybe I can do: > > java.lang.Object > |--java.io.Serializable/0x00000007c00375f8 (java.base, intf) > |--java.util.RandomAccess/0x00000007c00375f8 (java.base, intf) > ... > |-sun.misc.Launcher$AppClassLoader/0x00000007c00375f8 (java.base, CLD=0x000000087654320) > |-myapp/0x000000087654320 > > So now the classname and its classloader id (which is the CLD*) are grouped together to make it easy to strip out or to search for in more than one dcmd output. I think this is probably what you were striving when you proposed using '/', and other DCMDs can eventually be changed to do the same. Also, once you know the CLD of the ClassLoader, you can find out the name of the ClassLoader class by looking for CLD= > > I can go with "null" for the null ClassLoader if you want. I used it's ClassLoaderData* to be consistent with the other ClassLoaders. Just let me know which you prefer. > > thanks, > > Chris > > On 2/6/15 12:52 AM, Staffan Larsen wrote: >> I think this looks good! Perhaps we should give a hint as to what the hex value is? I don?t know if it is best to print this as part of a ?header? printed before the rest of the output or if we should include it as part of each line ?(classloaderdata*=0x080609c8)?. >> >> /Staffan >> >>> On 6 feb 2015, at 05:49, Chris Plummer wrote: >>> >>> [Hmm. My previous email somehow included the attachment with the dcmd output, but not the body of the message, so here it is again.] >>> >>> Hey Folks, >>> >>> Sorry about the delay in getting the next webrev for this out. I was sidetracked by a few other things, including being out sick of almost a week, and there were also quite a few changes to make. >>> >>> I'm ready for review with an updated webrev, but thought first I'd have you look at and comment on the output. Please see the attached file. It now supports: >>> >>> printing the hierarchy for a single class >>> optionally including all subclasses of the specified class (-s) >>> for each class, also list all of its interfaces (-i) >>> >>> The hex value in the output is the address of the ClassLoaderData for the ClassLoader of the class. I did not include the address of the Klass, but could if you think it would be useful. Changing the format of what comes after the classname is easy. Just let me know what you think is best. >>> >>> I have not updated any other dcmds to be consistent with how classes are uniquely identified. A separate bug should be filed for that. Actually I thought one was, but I looked through this thread's history and could not find mention of it. I also have not implemented the reverse hierarchy dcmd. JDK-8068830 has already been filed for that, but there are no plans to work on it in the near term. >>> >>> thanks, >>> >>> Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Feb 6 22:09:11 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 06 Feb 2015 14:09:11 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> <54D520D3.3070804@oracle.com> Message-ID: <54D53B87.5090304@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Feb 6 22:47:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 06 Feb 2015 14:47:35 -0800 Subject: RFR 8071657:JDI ObjectReferenceImpl.invokeMethod() validation fails for virtual invocations of method with declaring type being an interface In-Reply-To: <54D4D59D.2080807@oracle.com> References: <54D4D59D.2080807@oracle.com> Message-ID: <54D54487.3000706@oracle.com> The fix looks good. Thanks, Serguei On 2/6/15 6:54 AM, Jaroslav Bachorik wrote: > Please, review the following change in JDI implementation > > Issue : https://bugs.openjdk.java.net/browse/JDK-8071657 > Webrev: http://cr.openjdk.java.net/~jbachorik/8071657/webrev.00 > > After JDK-8042123 has been integrated it became possible to make > non-virtual calls to interface default or static methods via JDI. > > Unfortunately, when a virtual invocation of a method with its > declaring type being an interface is attempted it fails validation. > The code fails to distinguish virtual and non-virtual calls and always > fails for non-default methods. > > The solution is to check to check for the call being non-virtual > before enforcing the method to be default. > > Thanks, > > -JB- From david.holmes at oracle.com Sun Feb 8 01:01:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Sun, 08 Feb 2015 11:01:52 +1000 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: References: <877fvxhg67.fsf@oracle.com> <54D3132C.1090107@oracle.com> Message-ID: <54D6B580.70408@oracle.com> On 6/02/2015 11:01 PM, Roland Westrelin wrote: > Hi David, > >> I wouldn't say it "supports default methods" rather it ignores them so they don't trigger exceptions. I'm still puzzling over why default methods have a zero _codeIndex as that seems to be the real cause of the trouble. ?? > > I took another look and it turns out the test on _codeIndex is not required (at least with the core file I?m working on). Not sure why I found it was needed. So here is a new webrev that removes it: > > http://cr.openjdk.java.net/~roland/8071999/webrev.01/ So it isn't default methods that are the problem but bridge methods? David > That?s what I will push unless someone objects. > > Roland. > From david.holmes at oracle.com Sun Feb 8 23:13:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Feb 2015 09:13:52 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54D4AB78.3060300@oracle.com> References: <54D24EEC.4090303@oracle.com> <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> <54D389A1.2010104@oracle.com> <54D44E26.9010500@oracle.com> <54D4AB78.3060300@oracle.com> Message-ID: <54D7EDB0.6080801@oracle.com> Hi Jaroslav, On 6/02/2015 9:54 PM, Jaroslav Bachorik wrote: > On 6.2.2015 06:16, David Holmes wrote: >> On 6/02/2015 1:17 AM, Jaroslav Bachorik wrote: >>> On 5.2.2015 14:55, Staffan Larsen wrote: >>>> Jaroslav, >>>> >>>> This looks good, just a few small comments: >>>> >>>> writableFlags.hpp: >>>> >>>> L25 #ifndef WritableFlags_HPP >>>> L26 #define WritableFlags_HPP >>>> L96 #endif /* WritableFlags_HPP */ >>>> Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP >>>> >>>> L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer >>>> ?SUCCESS? instead. >>>> >>>> writableFlags.cpp: >>>> >>>> L25: #include statements should be in alphabetical order if possible >>>> L166: (nit) missing empty line >>>> L155: I notice the Flag class uses ?writeable? (with an ?e?) and this >>>> class uses ?writable? (without ?e?) - My english isn?t good enough to >>>> tell if there is any difference. >>> >>> They should be equal in meaning. According to GooglBattle [1] the form >>> 'writable' is far wider spread but I would leave the decision to a >>> native speaker. >>> >>> [1] >>> http://www.googlebattle.com/index.php?domain=writeable&domain2=writable&submit=Go! >>> >>>> L194: Unused variable ?succeed" >>> >>> The rest of the comments will be addressed. I will wait for eg. David to >>> comment on 'writable' vs. 'writeable' before regenerating the webrev. >> >> Take your pick. Both are used in the hotspot sources eg globals.hpp >> contains is_writeable() and check_writable() :( >> >> It is on my TODO list to review this ASAP. > > Taffan's comments addressed - > http://cr.openjdk.java.net/~jbachorik/8067447/webrev.03 src/share/vm/services/writableFlags.cpp precompiled.hpp must be first in the include list. 73 int WritableFlags::set_uintx_flag(const char* name, uintx value, Flag::Flags origin, FormatBuffer<80>& err_msg) { 74 if (strncmp(name, "MaxHeapFreeRatio", 17) == 0) { Strikes me that this flag specific validation does not belong in this logic (nor does it belong where it currently is today). Maybe the work being done on argument validation will allow this to be cleaned up in the near future? 154 // only writable flags are allowed to be set 155 if (f->is_writeable()) { This tells me you maybe made the wrong choice for the spelling issue :) If we already have writeable associated with flags then maybe stick with it? Otherwise seem okay. Thanks, David > -JB- > >> >> David >> >> >> >>> -JB- >>> >>>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 4 feb 2015, at 17:55, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>> Hi, this is a round 2 review of the proposed solution. >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 >>>>> >>>>> This patch is a precursor for implementing >>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>> part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>> >>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>> separate WritableFlags class and the codebease is adjusted to use >>>>> this class. >>>>> >>>>> I didn't touch the original (nonstandard) handling of the DTrace >>>>> specific flags in the Solaris specific attachListener.cpp >>>>> implementation to keep the change simple and focused. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> > From staffan.larsen at oracle.com Mon Feb 9 08:30:49 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 Feb 2015 09:30:49 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54D7EDB0.6080801@oracle.com> References: <54D24EEC.4090303@oracle.com> <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> <54D389A1.2010104@oracle.com> <54D44E26.9010500@oracle.com> <54D4AB78.3060300@oracle.com> <54D7EDB0.6080801@oracle.com> Message-ID: <2F680DCA-4896-4961-8903-CF9BA7594972@oracle.com> > On 9 feb 2015, at 00:13, David Holmes wrote: > > Hi Jaroslav, > > On 6/02/2015 9:54 PM, Jaroslav Bachorik wrote: >> On 6.2.2015 06:16, David Holmes wrote: >>> On 6/02/2015 1:17 AM, Jaroslav Bachorik wrote: >>>> On 5.2.2015 14:55, Staffan Larsen wrote: >>>>> Jaroslav, >>>>> >>>>> This looks good, just a few small comments: >>>>> >>>>> writableFlags.hpp: >>>>> >>>>> L25 #ifndef WritableFlags_HPP >>>>> L26 #define WritableFlags_HPP >>>>> L96 #endif /* WritableFlags_HPP */ >>>>> Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP >>>>> >>>>> L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer >>>>> ?SUCCESS? instead. >>>>> >>>>> writableFlags.cpp: >>>>> >>>>> L25: #include statements should be in alphabetical order if possible >>>>> L166: (nit) missing empty line >>>>> L155: I notice the Flag class uses ?writeable? (with an ?e?) and this >>>>> class uses ?writable? (without ?e?) - My english isn?t good enough to >>>>> tell if there is any difference. >>>> >>>> They should be equal in meaning. According to GooglBattle [1] the form >>>> 'writable' is far wider spread but I would leave the decision to a >>>> native speaker. >>>> >>>> [1] >>>> http://www.googlebattle.com/index.php?domain=writeable&domain2=writable&submit=Go! >>>> >>>>> L194: Unused variable ?succeed" >>>> >>>> The rest of the comments will be addressed. I will wait for eg. David to >>>> comment on 'writable' vs. 'writeable' before regenerating the webrev. >>> >>> Take your pick. Both are used in the hotspot sources eg globals.hpp >>> contains is_writeable() and check_writable() :( >>> >>> It is on my TODO list to review this ASAP. >> >> Taffan's comments addressed - >> http://cr.openjdk.java.net/~jbachorik/8067447/webrev.03 > > src/share/vm/services/writableFlags.cpp > > precompiled.hpp must be first in the include list. > > 73 int WritableFlags::set_uintx_flag(const char* name, uintx value, Flag::Flags origin, FormatBuffer<80>& err_msg) { > 74 if (strncmp(name, "MaxHeapFreeRatio", 17) == 0) { > > Strikes me that this flag specific validation does not belong in this logic (nor does it belong where it currently is today). Maybe the work being done on argument validation will allow this to be cleaned up in the near future? At least now the logic is only in two places (writableFlags.cpp and arguments.cpp) instead of three places (management.cpp, attachListener.cpp and arguments.cpp). I, too, hope we can reduce this further. /Staffan > > > 154 // only writable flags are allowed to be set > 155 if (f->is_writeable()) { > > This tells me you maybe made the wrong choice for the spelling issue :) > If we already have writeable associated with flags then maybe stick with it? > > Otherwise seem okay. > > Thanks, > David > >> -JB- >> >>> >>> David >>> >>> >>> >>>> -JB- >>>> >>>>> >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>>> On 4 feb 2015, at 17:55, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>> Hi, this is a round 2 review of the proposed solution. >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 >>>>>> >>>>>> This patch is a precursor for implementing >>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>> part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>> >>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>> separate WritableFlags class and the codebease is adjusted to use >>>>>> this class. >>>>>> >>>>>> I didn't touch the original (nonstandard) handling of the DTrace >>>>>> specific flags in the Solaris specific attachListener.cpp >>>>>> implementation to keep the change simple and focused. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >> From roland.westrelin at oracle.com Mon Feb 9 09:10:44 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 9 Feb 2015 10:10:44 +0100 Subject: RFR(S): 8071999: SA's buildreplayjars fail with exception In-Reply-To: <54D6B580.70408@oracle.com> References: <877fvxhg67.fsf@oracle.com> <54D3132C.1090107@oracle.com> <54D6B580.70408@oracle.com> Message-ID: > So it isn't default methods that are the problem but bridge methods? Yes, it looks like it. Roland. From staffan.larsen at oracle.com Mon Feb 9 09:43:56 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 Feb 2015 10:43:56 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D520D3.3070804@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> <54D520D3.3070804@oracle.com> Message-ID: > On 6 feb 2015, at 21:15, Chris Plummer wrote: > > I was also thinking it might be a good idea to indicate what the hex value is, although still have figured out the best way of doing this. Maybe just a simple comment before the output. Keep in mind that eventually other DCMDS will also include the cld to help uniquiely identify classes across dcmd output. Also keep in mind your earlier suggestion: > > java.lang.Object/0x12345600 > |--java.io.Serializable/0x12345601 > |--java.util.RandomAccess/0x12345602 > |--java.lang.Iterable/0x12345603 > | |--java.util.Collection/0x12345604 > | | |--java.util.List/0x12345605 > |--java.util.AbstractCollection/0x12345606 > | | implements java.util.Collection/0x12345604 > | | implements java.lang.Iterable/0x12345603 > | |--java.util.AbstractList/0x12345607 > | | implements java.util.List/0x12345605 > | | |--java.util.Arrays$ArrayList/0x12345608 > | | | implements java.io.Serializable/0x12345601 > | | | implements java.util.RandomAccess/0x12345602 > > With additions to GC.class_stats: > > Index Super ClassLoader ClassName > 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 > 2 1 0x00000007c0034c48 java.util.List/0x12345605 > 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 > > And GC.class_histogram: > > num #instances #bytes class name > ---------------------------------------------- > 1: 945 117736 java.lang.Object/0x12345600 > 2: 442 50352 java.util.List/0x12345605 > 3: 499 25288 java.util.AbstractList/0x12345607 > > I think in your case you assumed we would create a unique identifier for each class, but then we settled on just classname + ClassLoader identifier of some sort, and the CLD* works for that. So replace your hex class ID in the above with the hex CLD*. > > Also something Karen had said is just now starting to sink in and make sense to me: > > |-sun.misc.Launcher$AppClassLoader/null (0xyyy) > |-myapp/0xyyy > > I think the idea here is that when printing a ClassLoader subclass, you include two CLDs. The first is for the ClassLoader that loaded the class, and the second is the CLD for the ClassLoader subclass itself. Thus the above indicates that myapp was loaded by 0xyyy, which is the sun.misc.Launcher$AppClassLoader, which was loaded by the null ClassLoader. > > With regard to the '/' format, keep in mind that we also need an indicator of whether or not it's an interface, and there's also a request to include the module name when that becomes available. At one point you requested the following, which is what I was aiming for: > > java.lang.Object > |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) > |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) > > So maybe I can do: > > java.lang.Object > |--java.io.Serializable/0x00000007c00375f8 (java.base, intf) > |--java.util.RandomAccess/0x00000007c00375f8 (java.base, intf) This looks good to me. > ... > |-sun.misc.Launcher$AppClassLoader/0x00000007c00375f8 (java.base, CLD=0x000000087654320) > |-myapp/0x000000087654320 > > So now the classname and its classloader id (which is the CLD*) are grouped together to make it easy to strip out or to search for in more than one dcmd output. I think this is probably what you were striving when you proposed using '/', and other DCMDs can eventually be changed to do the same. Also, once you know the CLD of the ClassLoader, you can find out the name of the ClassLoader class by looking for CLD= > > I can go with "null" for the null ClassLoader if you want. I used it's ClassLoaderData* to be consistent with the other ClassLoaders. Just let me know which you prefer. If we change the CLD* to the ?Klass of the j.l.ClassLoader?, then it will become ?null?. If someone wants to find the CLD* for the null ClassLoader, then the VM.classloader_stats command will get that. /Staffan > > thanks, > > Chris > > On 2/6/15 12:52 AM, Staffan Larsen wrote: >> I think this looks good! Perhaps we should give a hint as to what the hex value is? I don?t know if it is best to print this as part of a ?header? printed before the rest of the output or if we should include it as part of each line ?(classloaderdata*=0x080609c8)?. >> >> /Staffan >> >>> On 6 feb 2015, at 05:49, Chris Plummer wrote: >>> >>> [Hmm. My previous email somehow included the attachment with the dcmd output, but not the body of the message, so here it is again.] >>> >>> Hey Folks, >>> >>> Sorry about the delay in getting the next webrev for this out. I was sidetracked by a few other things, including being out sick of almost a week, and there were also quite a few changes to make. >>> >>> I'm ready for review with an updated webrev, but thought first I'd have you look at and comment on the output. Please see the attached file. It now supports: >>> >>> printing the hierarchy for a single class >>> optionally including all subclasses of the specified class (-s) >>> for each class, also list all of its interfaces (-i) >>> >>> The hex value in the output is the address of the ClassLoaderData for the ClassLoader of the class. I did not include the address of the Klass, but could if you think it would be useful. Changing the format of what comes after the classname is easy. Just let me know what you think is best. >>> >>> I have not updated any other dcmds to be consistent with how classes are uniquely identified. A separate bug should be filed for that. Actually I thought one was, but I looked through this thread's history and could not find mention of it. I also have not implemented the reverse hierarchy dcmd. JDK-8068830 has already been filed for that, but there are no plans to work on it in the near term. >>> >>> thanks, >>> >>> Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Feb 9 09:46:48 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 Feb 2015 10:46:48 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> <54D520D3.3070804@oracle.com> Message-ID: <6EC2DA98-7E82-436D-AD07-32785FB37636@oracle.com> > On 6 feb 2015, at 22:21, Karen Kinnear wrote: > > Chris, > > So I was curious - I was thinking you would printing the hex address of the j.l.ClassLoader class rather than the cld so that if folks were to look > at a heap dump later it might be meaningful to them. Is it unlikely that they would ever want to correlate those? > > > On Feb 6, 2015, at 3:15 PM, Chris Plummer wrote: > >> I was also thinking it might be a good idea to indicate what the hex value is, although still have figured out the best way of doing this. Maybe just a simple comment before the output. Keep in mind that eventually other DCMDS will also include the cld to help uniquiely identify classes across dcmd output. Also keep in mind your earlier suggestion: >> >> java.lang.Object/0x12345600 >> |--java.io.Serializable/0x12345601 >> |--java.util.RandomAccess/0x12345602 >> |--java.lang.Iterable/0x12345603 >> | |--java.util.Collection/0x12345604 >> | | |--java.util.List/0x12345605 >> |--java.util.AbstractCollection/0x12345606 >> | | implements java.util.Collection/0x12345604 >> | | implements java.lang.Iterable/0x12345603 >> | |--java.util.AbstractList/0x12345607 >> | | implements java.util.List/0x12345605 >> | | |--java.util.Arrays$ArrayList/0x12345608 >> | | | implements java.io.Serializable/0x12345601 >> | | | implements java.util.RandomAccess/0x12345602 >> >> With additions to GC.class_stats: >> >> Index Super ClassLoader ClassName >> 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 >> 2 1 0x00000007c0034c48 java.util.List/0x12345605 >> 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 >> >> And GC.class_histogram: >> >> num #instances #bytes class name >> ---------------------------------------------- >> 1: 945 117736 java.lang.Object/0x12345600 >> 2: 442 50352 java.util.List/0x12345605 >> 3: 499 25288 java.util.AbstractList/0x12345607 >> >> I think in your case you assumed we would create a unique identifier for each class, but then we settled on just classname + ClassLoader identifier of some sort, and the CLD* works for that. So replace your hex class ID in the above with the hex CLD*. >> >> Also something Karen had said is just now starting to sink in and make sense to me: >> >> |-sun.misc.Launcher$AppClassLoader/null (0xyyy) >> |-myapp/0xyyy >> >> I think the idea here is that when printing a ClassLoader subclass, you include two CLDs. The first is for the ClassLoader that loaded the class, and the second is the CLD for the ClassLoader subclass itself. Thus the above indicates that myapp was loaded by 0xyyy, which is the sun.misc.Launcher$AppClassLoader, which was loaded by the null ClassLoader. > I apologize - I don't remember what I said. But I am not sure we need that level of complexity. I think I was asking that one of the dcmds that gives > information could print information like 0xabc "a sun.misc.Launcher$AppClassLoader" or "a WLS.blah.GenericClassLoader" if we don't want to include > that everywhere. Mostly people want to know the name of the class loader. Since they don't yet have names, they want to know the type of the > classloader. So that string "a MyClassLoader" would be more meaningful than the 0xabc - except that if they > have 5 of those they need the uniqueness. So personally I think I was proposing the > java.base, 0xA/"a MyClassLoader", iface). > > But I would defer to Staffan if he suggests something else. The mapping from ?Klass of the j.l.ClassLoader? to ?type of the ClassLoader? is available in the VM.classloader_stats command: ClassLoader Parent CLD* Classes ChunkSz BlockSz Type 0x00000007c0038d10 0x00000007c0036240 0x00007faf7843d8f0 1 6144 1496 sun.misc.Launcher$AppClassLoader 0x00000007c0036240 0x0000000000000000 0x0000000000000000 0 0 0 sun.misc.Launcher$ExtClassLoader 0x0000000000000000 0x0000000000000000 0x00007faf7852ffd0 432 4587520 2851696 Total = 3 433 4593664 2853192 ChunkSz: Total size of all allocated metaspace chunks BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks) I think that having the mapping in one place is enough. /Staffan > > thanks for your patience, > Karen >> >> With regard to the '/' format, keep in mind that we also need an indicator of whether or not it's an interface, and there's also a request to include the module name when that becomes available. At one point you requested the following, which is what I was aiming for: >> >> java.lang.Object >> |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) >> |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) >> >> So maybe I can do: >> >> java.lang.Object >> |--java.io.Serializable/0x00000007c00375f8 (java.base, intf) >> |--java.util.RandomAccess/0x00000007c00375f8 (java.base, intf) >> ... >> |-sun.misc.Launcher$AppClassLoader/0x00000007c00375f8 (java.base, CLD=0x000000087654320) >> |-myapp/0x000000087654320 >> >> So now the classname and its classloader id (which is the CLD*) are grouped together to make it easy to strip out or to search for in more than one dcmd output. I think this is probably what you were striving when you proposed using '/', and other DCMDs can eventually be changed to do the same. Also, once you know the CLD of the ClassLoader, you can find out the name of the ClassLoader class by looking for CLD= >> >> I can go with "null" for the null ClassLoader if you want. I used it's ClassLoaderData* to be consistent with the other ClassLoaders. Just let me know which you prefer. >> >> thanks, >> >> Chris >> >> On 2/6/15 12:52 AM, Staffan Larsen wrote: >>> I think this looks good! Perhaps we should give a hint as to what the hex value is? I don?t know if it is best to print this as part of a ?header? printed before the rest of the output or if we should include it as part of each line ?(classloaderdata*=0x080609c8)?. >>> >>> /Staffan >>> >>>> On 6 feb 2015, at 05:49, Chris Plummer wrote: >>>> >>>> [Hmm. My previous email somehow included the attachment with the dcmd output, but not the body of the message, so here it is again.] >>>> >>>> Hey Folks, >>>> >>>> Sorry about the delay in getting the next webrev for this out. I was sidetracked by a few other things, including being out sick of almost a week, and there were also quite a few changes to make. >>>> >>>> I'm ready for review with an updated webrev, but thought first I'd have you look at and comment on the output. Please see the attached file. It now supports: >>>> >>>> printing the hierarchy for a single class >>>> optionally including all subclasses of the specified class (-s) >>>> for each class, also list all of its interfaces (-i) >>>> >>>> The hex value in the output is the address of the ClassLoaderData for the ClassLoader of the class. I did not include the address of the Klass, but could if you think it would be useful. Changing the format of what comes after the classname is easy. Just let me know what you think is best. >>>> >>>> I have not updated any other dcmds to be consistent with how classes are uniquely identified. A separate bug should be filed for that. Actually I thought one was, but I looked through this thread's history and could not find mention of it. I also have not implemented the reverse hierarchy dcmd. JDK-8068830 has already been filed for that, but there are no plans to work on it in the near term. >>>> >>>> thanks, >>>> >>>> Chris >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Mon Feb 9 10:48:29 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 09 Feb 2015 11:48:29 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54D7EDB0.6080801@oracle.com> References: <54D24EEC.4090303@oracle.com> <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> <54D389A1.2010104@oracle.com> <54D44E26.9010500@oracle.com> <54D4AB78.3060300@oracle.com> <54D7EDB0.6080801@oracle.com> Message-ID: <54D8907D.5020803@oracle.com> On 9.2.2015 00:13, David Holmes wrote: > Hi Jaroslav, > > On 6/02/2015 9:54 PM, Jaroslav Bachorik wrote: >> On 6.2.2015 06:16, David Holmes wrote: >>> On 6/02/2015 1:17 AM, Jaroslav Bachorik wrote: >>>> On 5.2.2015 14:55, Staffan Larsen wrote: >>>>> Jaroslav, >>>>> >>>>> This looks good, just a few small comments: >>>>> >>>>> writableFlags.hpp: >>>>> >>>>> L25 #ifndef WritableFlags_HPP >>>>> L26 #define WritableFlags_HPP >>>>> L96 #endif /* WritableFlags_HPP */ >>>>> Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP >>>>> >>>>> L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer >>>>> ?SUCCESS? instead. >>>>> >>>>> writableFlags.cpp: >>>>> >>>>> L25: #include statements should be in alphabetical order if possible >>>>> L166: (nit) missing empty line >>>>> L155: I notice the Flag class uses ?writeable? (with an ?e?) and this >>>>> class uses ?writable? (without ?e?) - My english isn?t good enough to >>>>> tell if there is any difference. >>>> >>>> They should be equal in meaning. According to GooglBattle [1] the form >>>> 'writable' is far wider spread but I would leave the decision to a >>>> native speaker. >>>> >>>> [1] >>>> http://www.googlebattle.com/index.php?domain=writeable&domain2=writable&submit=Go! >>>> >>>> >>>>> L194: Unused variable ?succeed" >>>> >>>> The rest of the comments will be addressed. I will wait for eg. >>>> David to >>>> comment on 'writable' vs. 'writeable' before regenerating the webrev. >>> >>> Take your pick. Both are used in the hotspot sources eg globals.hpp >>> contains is_writeable() and check_writable() :( >>> >>> It is on my TODO list to review this ASAP. >> >> Taffan's comments addressed - >> http://cr.openjdk.java.net/~jbachorik/8067447/webrev.03 > > src/share/vm/services/writableFlags.cpp > > precompiled.hpp must be first in the include list. done. > > 73 int WritableFlags::set_uintx_flag(const char* name, uintx value, > Flag::Flags origin, FormatBuffer<80>& err_msg) { > 74 if (strncmp(name, "MaxHeapFreeRatio", 17) == 0) { > > Strikes me that this flag specific validation does not belong in this > logic (nor does it belong where it currently is today). Maybe the work > being done on argument validation will allow this to be cleaned up in > the near future? i hope so. slowly getting there - instead of 3 different places performing this validation we have 2 now. > > > 154 // only writable flags are allowed to be set > 155 if (f->is_writeable()) { > > This tells me you maybe made the wrong choice for the spelling issue :) > If we already have writeable associated with flags then maybe stick with > it? renamed to 'writeable' http://cr.openjdk.java.net/~jbachorik/8067447/webrev.04 -JB- > > Otherwise seem okay. > > Thanks, > David > >> -JB- >> >>> >>> David >>> >>> >>> >>>> -JB- >>>> >>>>> >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>>> On 4 feb 2015, at 17:55, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>> Hi, this is a round 2 review of the proposed solution. >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 >>>>>> >>>>>> This patch is a precursor for implementing >>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>> part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>> >>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>> separate WritableFlags class and the codebease is adjusted to use >>>>>> this class. >>>>>> >>>>>> I didn't touch the original (nonstandard) handling of the DTrace >>>>>> specific flags in the Solaris specific attachListener.cpp >>>>>> implementation to keep the change simple and focused. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >> From david.holmes at oracle.com Mon Feb 9 11:17:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Feb 2015 21:17:26 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54D8907D.5020803@oracle.com> References: <54D24EEC.4090303@oracle.com> <5DB6E18F-0206-4A6A-A904-4A8F51748AB9@oracle.com> <54D389A1.2010104@oracle.com> <54D44E26.9010500@oracle.com> <54D4AB78.3060300@oracle.com> <54D7EDB0.6080801@oracle.com> <54D8907D.5020803@oracle.com> Message-ID: <54D89746.5040603@oracle.com> Hi Jaroslav, // a writable flag Still a few changes needed in writeable.hpp and writeable.cpp But no need for a new webrev. Thanks, David On 9/02/2015 8:48 PM, Jaroslav Bachorik wrote: > On 9.2.2015 00:13, David Holmes wrote: >> Hi Jaroslav, >> >> On 6/02/2015 9:54 PM, Jaroslav Bachorik wrote: >>> On 6.2.2015 06:16, David Holmes wrote: >>>> On 6/02/2015 1:17 AM, Jaroslav Bachorik wrote: >>>>> On 5.2.2015 14:55, Staffan Larsen wrote: >>>>>> Jaroslav, >>>>>> >>>>>> This looks good, just a few small comments: >>>>>> >>>>>> writableFlags.hpp: >>>>>> >>>>>> L25 #ifndef WritableFlags_HPP >>>>>> L26 #define WritableFlags_HPP >>>>>> L96 #endif /* WritableFlags_HPP */ >>>>>> Should be SHARE_VM_SERVICES_WRITABLEFLAG_HPP >>>>>> >>>>>> L32: I don?t like inverted logic such as ?NO_ERR?. I would prefer >>>>>> ?SUCCESS? instead. >>>>>> >>>>>> writableFlags.cpp: >>>>>> >>>>>> L25: #include statements should be in alphabetical order if possible >>>>>> L166: (nit) missing empty line >>>>>> L155: I notice the Flag class uses ?writeable? (with an ?e?) and this >>>>>> class uses ?writable? (without ?e?) - My english isn?t good enough to >>>>>> tell if there is any difference. >>>>> >>>>> They should be equal in meaning. According to GooglBattle [1] the form >>>>> 'writable' is far wider spread but I would leave the decision to a >>>>> native speaker. >>>>> >>>>> [1] >>>>> http://www.googlebattle.com/index.php?domain=writeable&domain2=writable&submit=Go! >>>>> >>>>> >>>>> >>>>>> L194: Unused variable ?succeed" >>>>> >>>>> The rest of the comments will be addressed. I will wait for eg. >>>>> David to >>>>> comment on 'writable' vs. 'writeable' before regenerating the webrev. >>>> >>>> Take your pick. Both are used in the hotspot sources eg globals.hpp >>>> contains is_writeable() and check_writable() :( >>>> >>>> It is on my TODO list to review this ASAP. >>> >>> Taffan's comments addressed - >>> http://cr.openjdk.java.net/~jbachorik/8067447/webrev.03 >> >> src/share/vm/services/writableFlags.cpp >> >> precompiled.hpp must be first in the include list. > > done. > >> >> 73 int WritableFlags::set_uintx_flag(const char* name, uintx value, >> Flag::Flags origin, FormatBuffer<80>& err_msg) { >> 74 if (strncmp(name, "MaxHeapFreeRatio", 17) == 0) { >> >> Strikes me that this flag specific validation does not belong in this >> logic (nor does it belong where it currently is today). Maybe the work >> being done on argument validation will allow this to be cleaned up in >> the near future? > > i hope so. slowly getting there - instead of 3 different places > performing this validation we have 2 now. > >> >> >> 154 // only writable flags are allowed to be set >> 155 if (f->is_writeable()) { >> >> This tells me you maybe made the wrong choice for the spelling issue :) >> If we already have writeable associated with flags then maybe stick with >> it? > > renamed to 'writeable' > > http://cr.openjdk.java.net/~jbachorik/8067447/webrev.04 > > -JB- > >> >> Otherwise seem okay. >> >> Thanks, >> David >> >>> -JB- >>> >>>> >>>> David >>>> >>>> >>>> >>>>> -JB- >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>>> On 4 feb 2015, at 17:55, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>> Hi, this is a round 2 review of the proposed solution. >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 >>>>>>> >>>>>>> This patch is a precursor for implementing >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>>> part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>>> >>>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>>> separate WritableFlags class and the codebease is adjusted to use >>>>>>> this class. >>>>>>> >>>>>>> I didn't touch the original (nonstandard) handling of the DTrace >>>>>>> specific flags in the Solaris specific attachListener.cpp >>>>>>> implementation to keep the change simple and focused. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>> >>> > From dean.long at oracle.com Mon Feb 9 21:16:57 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 09 Feb 2015 13:16:57 -0800 Subject: Request for approval: Backport of 8069030 Message-ID: <54D923C9.3090107@oracle.com> I would like to backport 8069030 to 8u60: https://bugs.openjdk.java.net/browse/JDK-8069030 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5960a65b0f54 The patch applied cleanly. dl From jeremymanson at google.com Tue Feb 10 00:51:22 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 9 Feb 2015 16:51:22 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> Message-ID: Thanks for taking a look, Staffan. Sorry about the delay. I've gone ahead and made a test: http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ Can anyone drive the API process? It's such a minor change that I can't imagine it wouldn't go through easily. Of course, I have no idea what's involved. Jeremy On Mon, Jan 12, 2015 at 11:10 PM, Staffan Larsen wrote: > > > On 13 jan 2015, at 06:28, David Holmes wrote: > > > > Hi Jeremy, > > > > On 13/01/2015 4:32 AM, Jeremy Manson wrote: > >> Hi folks, > >> > >> This was long forgotten, seems to have been lost in the shuffle. I've > >> done it, since we could use it, too: > >> > >> https://bugs.openjdk.java.net/browse/JDK-6588467 > >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.00/ > > > > Codewise this all appears fine to me. > > Thanks for doing this. I have only scanned the code, but did not see any > test. Could you please add tests for the new API? > > >> Since it is an API change (albeit an uncontroversial one), it will have > >> to go through whatever the super-secret API change review process is > >> that you folks do. > > > > Not sure if this just needs an API tweak or a JMX spec revision. If the > latter then this might be a big deal. But I'll leave that to the official > serviceability folk :) > > No spec revision is needed, same process as for all API changes. > Unfortunately I don?t have the time to drive that, so hoping someone else > can jump in. > > /Staffan > > > > > Cheers, > > David > > > >> Thanks! > >> > >> Jeremy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Feb 10 01:45:42 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 09 Feb 2015 17:45:42 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D42BC0.3010502@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> Message-ID: <54D962C6.1060505@oracle.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- $> jcmd NeverExit help VM.class_hierarchy 7836: VM.class_hierarchy Print a list of all loaded classes, indented to show the class hiearchy. The name of each classes is followed by the Klass* of its ClassLoader, or "null" if loaded by the bootstrap class loader. Impact: Medium: Depends on number of loaded classes. Syntax : VM.class_hierarchy [options] [] Arguments: classname : [optional] Name of class whose hierarchy should be printed. If not specified, all class hierarchies are printed. (STRING, no default value) Options: (options must be specified using the or = syntax) -i : [optional] Inherited interfaces should be printed. (BOOLEAN, false) -s : [optional] If a classname is specified, print its subclasses. Otherwise only its superclasses are printed. (BOOLEAN, false) $> jcmd NeverExit VM.class_hierarchy NeverExit -i -s 7836: java.lang.Object/null |--NeverExit/0xa5b37ea0 | implements NE2/0xa5b37ea0 (declared intf) | implements NE1/0xa5b37ea0 (transitive intf) $> jcmd NeverExit VM.class_hierarchy java.lang.Error 7836: java.lang.Object/null |--java.lang.Throwable/null | |--java.lang.Error/null $> jcmd NeverExit VM.class_hierarchy java.lang.Error -i 7836: java.lang.Object/null |--java.lang.Throwable/null | implements java.io.Serializable/null (declared intf) | |--java.lang.Error/null | | implements java.io.Serializable/null (transitive intf) $> jcmd NeverExit VM.class_hierarchy java.lang.Error -s 7836: java.lang.Object/null |--java.lang.Throwable/null | |--java.lang.Error/null | | |--java.lang.VirtualMachineError/null | | | |--java.lang.StackOverflowError/null | | | |--java.lang.OutOfMemoryError/null | | |--java.lang.LinkageError/null | | | |--java.lang.IncompatibleClassChangeError/null | | | | |--java.lang.NoSuchMethodError/null | | | |--java.lang.BootstrapMethodError/null | | | |--java.lang.NoClassDefFoundError/null | | |--java.lang.ThreadDeath/null $> jcmd NeverExit VM.class_hierarchy java.lang.Error -s -i 7836: java.lang.Object/null |--java.lang.Throwable/null | implements java.io.Serializable/null (declared intf) | |--java.lang.Error/null | | implements java.io.Serializable/null (transitive intf) | | |--java.lang.VirtualMachineError/null | | | implements java.io.Serializable/null (transitive intf) | | | |--java.lang.StackOverflowError/null | | | | implements java.io.Serializable/null (transitive intf) | | | |--java.lang.OutOfMemoryError/null | | | | implements java.io.Serializable/null (transitive intf) | | |--java.lang.LinkageError/null | | | implements java.io.Serializable/null (transitive intf) | | | |--java.lang.IncompatibleClassChangeError/null | | | | implements java.io.Serializable/null (transitive intf) | | | | |--java.lang.NoSuchMethodError/null | | | | | implements java.io.Serializable/null (transitive intf) | | | |--java.lang.BootstrapMethodError/null | | | | implements java.io.Serializable/null (transitive intf) | | | |--java.lang.NoClassDefFoundError/null | | | | implements java.io.Serializable/null (transitive intf) | | |--java.lang.ThreadDeath/null | | | implements java.io.Serializable/null (transitive intf) $> jcmd NeverExit VM.class_hierarchy 7836: java.lang.Object/null |--java.net.Parts/null |--java.nio.charset.spi.CharsetProvider/null | |--sun.nio.cs.FastCharsetProvider/null | | |--sun.nio.cs.StandardCharsets/null |--java.lang.Number/null | |--java.lang.Float/null | |--java.lang.Long/null | |--java.util.concurrent.atomic.AtomicLong/null | |--java.lang.Integer/null | |--java.util.concurrent.atomic.AtomicInteger/null | |--java.lang.Short/null | |--java.lang.Byte/null | |--java.lang.Double/null |--java.nio.channels.spi.AbstractInterruptibleChannel/null | |--java.nio.channels.FileChannel/null | | |--sun.nio.ch.FileChannelImpl/null |--java.nio.file.Path/null (intf) |--java.lang.reflect.Parameter/null |--java.nio.channels.InterruptibleChannel/null (intf) |--sun.misc.SharedSecrets/null |--java.lang.invoke.CallSite/null | |--java.lang.invoke.VolatileCallSite/null | |--java.lang.invoke.MutableCallSite/null | |--java.lang.invoke.ConstantCallSite/null |--java.util.concurrent.atomic.AtomicReferenceFieldUpdater/null | |--java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl/null |--sun.nio.cs.ArrayDecoder/null (intf) |--java.nio.file.Watchable/null (intf) |--sun.misc.PerfCounter$CoreCounters/null |--java.lang.invoke.MethodHandle/null | |--java.lang.invoke.DirectMethodHandle/null |--sun.misc.Perf/null |--java.lang.Enum/null | |--sun.launcher.LauncherHelper/null | |--java.io.File$PathStatus/null |--java.lang.CharacterData/null | |--java.lang.CharacterDataLatin1/null |--java.nio.channels.ScatteringByteChannel/null (intf) |--java.lang.StringCoding$StringDecoder/null |--java.lang.Character/null |--java.nio.channels.GatheringByteChannel/null (intf) |--java.lang.reflect.ReflectAccess/null |--java.nio.channels.SeekableByteChannel/null (intf) |--java.lang.ref.Reference$1/null |--java.util.BitSet/null |--sun.misc.Launcher$AppClassLoader$1/null |--java.lang.ref.Reference/null | |--java.lang.ref.PhantomReference/null | | |--sun.misc.Cleaner/null | |--java.lang.ref.FinalReference/null | | |--java.lang.ref.Finalizer/null | |--java.lang.ref.WeakReference/null | | |--java.lang.ThreadLocal$ThreadLocalMap$Entry/null | | |--java.lang.ClassValue$Entry/null | | |--java.util.WeakHashMap$Entry/null | |--java.lang.ref.SoftReference/null | | |--sun.util.locale.LocaleObjectCache$CacheEntry/null |--java.lang.String$CaseInsensitiveComparator/null |--sun.misc.JavaLangRefAccess/null (intf) |--java.nio.channels.ByteChannel/null (intf) |--java.lang.ref.Reference$Lock/null |--java.nio.channels.WritableByteChannel/null (intf) |--java.util.Comparator/null (intf) |--java.io.InputStream/null | |--java.io.FilterInputStream/null | | |--java.io.BufferedInputStream/null | |--java.io.ByteArrayInputStream/null | |--java.io.FileInputStream/null |--java.nio.channels.ReadableByteChannel/null (intf) |--java.lang.Cloneable/null (intf) |--java.lang.ref.ReferenceQueue$Lock/null |--sun.reflect.LangReflectAccess/null (intf) |--java.lang.invoke.MethodType/null |--java.nio.charset.Charset/null | |--sun.nio.cs.Unicode/null | | |--sun.nio.cs.UTF_8/null |--java.nio.channels.Channel/null (intf) |--sun.misc.Perf$GetPerfAction/null |--java.lang.Class/null |--sun.reflect.ReflectionFactory/null |--sun.misc.PostVMInitHook/null |--java.lang.Readable/null (intf) |--java.lang.ThreadLocal$ThreadLocalMap/null |--java.io.Closeable/null (intf) |--sun.misc.PerfCounter/null |--sun.util.locale.LocaleUtils/null |--java.lang.AutoCloseable/null (intf) |--java.lang.ref.ReferenceQueue/null | |--java.lang.ref.ReferenceQueue$Null/null |--java.lang.reflect.Modifier/null |--java.util.concurrent.ConcurrentMap/null (intf) |--java.lang.Void/null |--java.io.OutputStream/null | |--java.io.FileOutputStream/null | |--java.io.FilterOutputStream/null | | |--java.io.BufferedOutputStream/null | | |--java.io.PrintStream/null |--java.util.Collections$SynchronizedMap/null |--java.io.Flushable/null (intf) |--sun.misc.Unsafe/null |--java.lang.reflect.Member/null (intf) |--java.io.FileInputStream$1/null |--java.lang.Class$MethodArray/null |--java.lang.invoke.MethodHandleStatics$1/null |--java.io.ObjectStreamField/null |--sun.nio.ByteBuffered/null (intf) |--java.util.Locale$LocaleKey/null |--java.security.Principal/null (intf) |--java.lang.invoke.MethodHandleStatics/null |--sun.misc.Resource/null | |--sun.misc.URLClassPath$FileLoader$1/null |--java.lang.reflect.AccessibleObject/null | |--java.lang.reflect.Field/null | |--java.lang.reflect.Executable/null | | |--java.lang.reflect.Constructor/null | | |--java.lang.reflect.Method/null |--java.lang.StringCoding/null |--java.security.ProtectionDomain$Key/null |--java.util.Collections$UnmodifiableCollection/null | |--java.util.Collections$UnmodifiableList/null | | |--java.util.Collections$UnmodifiableRandomAccessList/null |--java.io.ExpiringCache/null |--sun.util.locale.BaseLocale$Key/null |--java.util.concurrent.atomic.AtomicBoolean/null |--java.security.ProtectionDomain$3/null |--sun.misc.JavaSecurityProtectionDomainAccess/null (intf) |--java.lang.Math/null |--java.util.ArrayList$Itr/null |--java.security.ProtectionDomain$1/null |--java.lang.invoke.MemberName$Factory/null |--java.security.AccessControlContext/null |--sun.misc.JavaSecurityAccess/null (intf) |--java.util.Dictionary/null | |--java.util.Hashtable/null | | |--java.util.Properties/null |--sun.net.www.ParseUtil/null |--java.io.FileDescriptor$1/null |--java.util.AbstractCollection/null | |--java.util.AbstractList/null | | |--java.util.Vector/null | | | |--java.util.Stack/null | | |--java.util.Collections$EmptyList/null | | |--java.util.ArrayList/null | |--java.util.AbstractSet/null | | |--java.util.WeakHashMap$KeySet/null | | |--java.util.Collections$SetFromMap/null | | |--java.util.HashSet/null | | |--java.util.Collections$EmptySet/null | | |--java.util.Hashtable$EntrySet/null |--sun.util.locale.LocaleObjectCache/null | |--java.util.Locale$Cache/null | |--sun.util.locale.BaseLocale$Cache/null |--java.nio.charset.CharsetEncoder/null | |--sun.nio.cs.UTF_8$Encoder/null |--java.io.FileSystem/null | |--java.io.UnixFileSystem/null |--sun.misc.Launcher$ExtClassLoader$1/null |--sun.misc.JavaIOFileDescriptorAccess/null (intf) |--java.lang.Boolean/null |--java.net.URLClassLoader$7/null |--java.io.FileDescriptor/null |--sun.misc.JavaNetAccess/null (intf) |--sun.util.locale.BaseLocale/null |--java.lang.invoke.LambdaForm/null |--java.util.concurrent.locks.AbstractQueuedSynchronizer$Node/null |--java.lang.ClassValue$Version/null |--java.util.AbstractMap/null | |--java.util.WeakHashMap/null | | |--java.lang.ClassValue$ClassValueMap/null | |--java.util.Collections$EmptyMap/null | |--java.util.HashMap/null | | |--java.util.LinkedHashMap/null | | | |--java.io.ExpiringCache$1/null | |--java.util.concurrent.ConcurrentHashMap/null | |--sun.util.PreHashedMap/null | | |--sun.nio.cs.StandardCharsets$Cache/null | | |--sun.nio.cs.StandardCharsets$Classes/null | | |--sun.nio.cs.StandardCharsets$Aliases/null |--sun.reflect.ReflectionFactory$1/null |--java.nio.Buffer/null | |--java.nio.CharBuffer/null | | |--java.nio.HeapCharBuffer/null | |--java.nio.ByteBuffer/null | | |--java.nio.MappedByteBuffer/null | | | |--java.nio.DirectByteBuffer/null | | | | |--java.nio.DirectByteBufferR/null | | |--java.nio.HeapByteBuffer/null | |--java.nio.IntBuffer/null | | |--java.nio.ByteBufferAsIntBufferB/null | | |--java.nio.DirectIntBufferU/null | | | |--java.nio.DirectIntBufferRU/null | |--java.nio.LongBuffer/null | | |--java.nio.DirectLongBufferU/null |--java.lang.ClassValue$Identity/null |--java.util.Locale/null |--sun.reflect.CallerSensitive/null (intf) |--java.lang.annotation.Annotation/null (intf) |--java.lang.Class$1/null |--sun.nio.ch.DirectBuffer/null (intf) |--java.security.ProtectionDomain/null |--java.util.concurrent.locks.AbstractOwnableSynchronizer/null | |--java.util.concurrent.locks.AbstractQueuedSynchronizer/null | | |--java.util.concurrent.locks.ReentrantLock$Sync/null | | | |--java.util.concurrent.locks.ReentrantLock$NonfairSync/null |--jdk.internal.jimage.concurrent.ConcurrentPReader$TemporaryBuffer/null |--java.lang.StackTraceElement/null |--java.lang.ClassValue/null | |--java.lang.invoke.MethodHandleImpl$4/null |--sun.reflect.annotation.AnnotationType/null |--sun.nio.ch.Util$4/null |--sun.nio.cs.ArrayEncoder/null (intf) |--sun.reflect.FieldAccessor/null (intf) |--java.lang.reflect.Type/null (intf) |--java.io.DefaultFileSystem/null |--jdk.internal.jimage.PReader/null | |--jdk.internal.jimage.concurrent.ConcurrentPReader/null |--sun.nio.cs.HistoricallyNamedCharset/null (intf) |--sun.misc.MetaIndex/null |--java.util.Hashtable$Entry/null |--sun.misc.Version/null |--java.util.Map/null (intf) |--java.security.CodeSource/null |--java.lang.reflect.GenericDeclaration/null (intf) |--sun.security.action.GetPropertyAction/null |--jdk.internal.jimage.ImageLocation/null |--java.lang.reflect.AnnotatedElement/null (intf) |--java.io.FilePermission$1/null |--java.lang.SecurityManager/null |--sun.nio.ch.Util/null |--java.lang.Class$AnnotationData/null |--jdk.internal.jimage.UTF8String/null |--java.lang.invoke.MethodHandleImpl$3/null |--java.util.concurrent.ConcurrentHashMap$CollectionView/null | |--java.util.concurrent.ConcurrentHashMap$EntrySetView/null | |--java.util.concurrent.ConcurrentHashMap$ValuesView/null | |--java.util.concurrent.ConcurrentHashMap$KeySetView/null |--sun.reflect.generics.repository.AbstractRepository/null | |--sun.reflect.generics.repository.GenericDeclRepository/null | | |--sun.reflect.generics.repository.ClassRepository/null |--java.lang.ClassLoader$ParallelLoaders/null |--java.lang.invoke.MethodHandleImpl$2/null |--java.util.function.Function/null (intf) |--sun.misc.VM/null |--java.lang.Runtime/null |--sun.security.util.Debug/null |--java.nio.Bits$1/null |--sun.misc.Launcher/null |--java.util.RandomAccess/null (intf) |--sun.nio.ch.FileChannelImpl$Unmapper/null |--java.util.Arrays/null |--java.lang.invoke.MethodHandleImpl$1/null |--java.util.List/null (intf) |--sun.misc.JavaNioAccess/null (intf) |--sun.misc.Launcher$BootClassPathHolder$1/null |--java.util.Set/null (intf) |--sun.reflect.ConstantPool/null |--jdk.internal.jimage.PackageModuleMap/null |--sun.nio.ch.NativeThread/null |--sun.misc.Launcher$BootClassPathHolder/null |--java.lang.String/null |--sun.net.www.MessageHeader/null |--java.lang.Class$Atomic/null |--java.util.jar.Manifest/null |--java.util.concurrent.ConcurrentHashMap$CounterCell/null |--java.nio.channels.spi.AbstractInterruptibleChannel$1/null |--java.io.Writer/null | |--java.io.BufferedWriter/null | |--sun.nio.cs.StreamEncoder/null | |--java.io.OutputStreamWriter/null |--java.util.Collection/null (intf) |--jdk.internal.jimage.ImageStream/null |--sun.nio.ch.Interruptible/null (intf) |--java.util.concurrent.ConcurrentHashMap$Node/null |--java.lang.invoke.MethodHandleImpl/null |--jdk.internal.jimage.BasicImageReader/null | |--jdk.internal.jimage.ImageReader/null |--java.lang.AbstractStringBuilder/null | |--java.lang.StringBuilder/null | |--java.lang.StringBuffer/null |--java.lang.Class$ReflectionData/null |--java.nio.channels.FileChannel$MapMode/null |--java.util.Hashtable$Enumerator/null |--java.util.HashMap$Node/null | |--java.util.LinkedHashMap$Entry/null | | |--java.util.HashMap$TreeNode/null |--java.lang.Iterable/null (intf) |--java.lang.Class$3/null |--java.lang.System$2/null |--java.nio.ByteOrder/null |--jdk.internal.jimage.ImageHeader/null |--java.util.Iterator/null (intf) |--java.util.Map$Entry/null (intf) |--sun.reflect.ConstructorAccessor/null (intf) |--java.net.URL/null |--java.util.concurrent.locks.ReentrantLock/null | |--java.util.concurrent.ConcurrentHashMap$Segment/null |--java.util.Collections/null |--java.util.Enumeration/null (intf) |--sun.misc.Launcher$Factory/null |--java.util.concurrent.CopyOnWriteArrayList/null |--sun.reflect.MethodAccessor/null (intf) |--java.lang.ThreadGroup/null |--sun.misc.JavaLangAccess/null (intf) |--sun.reflect.MagicAccessorImpl/null | |--sun.reflect.FieldAccessorImpl/null | | |--sun.reflect.UnsafeFieldAccessorImpl/null | | | |--sun.reflect.UnsafeStaticFieldAccessorImpl/null | |--sun.reflect.ConstructorAccessorImpl/null | | |--sun.reflect.DelegatingConstructorAccessorImpl/null | | |--sun.reflect.NativeConstructorAccessorImpl/null | |--sun.reflect.MethodAccessorImpl/null |--java.net.URLStreamHandlerFactory/null (intf) |--java.util.Objects/null |--java.nio.Bits/null |--java.lang.Throwable/null | |--java.lang.Exception/null | | |--java.lang.InterruptedException/null | | |--java.lang.ReflectiveOperationException/null | | | |--java.lang.ClassNotFoundException/null | | |--java.io.IOException/null | | |--java.lang.RuntimeException/null | | | |--java.lang.IllegalMonitorStateException/null | | | |--java.lang.ArrayStoreException/null | | | |--java.lang.ClassCastException/null | | | |--java.lang.ArithmeticException/null | | | |--java.lang.NullPointerException/null | | | |--java.lang.IllegalArgumentException/null | |--java.lang.Error/null | | |--java.lang.VirtualMachineError/null | | | |--java.lang.StackOverflowError/null | | | |--java.lang.OutOfMemoryError/null | | |--java.lang.LinkageError/null | | | |--java.lang.IncompatibleClassChangeError/null | | | | |--java.lang.NoSuchMethodError/null | | | |--java.lang.BootstrapMethodError/null | | | |--java.lang.NoClassDefFoundError/null | | |--java.lang.ThreadDeath/null |--jdk.internal.jimage.ImageStrings/null |--java.security.cert.Certificate/null |--java.util.concurrent.locks.Lock/null (intf) |--java.lang.invoke.MethodHandleNatives/null |--sun.nio.ch.NativeDispatcher/null | |--sun.nio.ch.FileDispatcher/null | | |--sun.nio.ch.FileDispatcherImpl/null |--sun.misc.URLClassPath/null |--java.lang.ThreadLocal/null | |--jdk.internal.jimage.concurrent.ConcurrentPReader$TemporaryBuffer$1/null | |--sun.nio.ch.Util$1/null |--sun.misc.OSEnvironment/null |--sun.reflect.ReflectionFactory$GetReflectionFactoryAction/null |--java.util.Collections$SynchronizedCollection/null | |--java.util.Collections$SynchronizedSet/null |--java.io.ObjectStreamClass/null |--java.security.PrivilegedAction/null (intf) |--java.lang.Integer$IntegerCache/null |--java.lang.Appendable/null (intf) |--sun.misc.NativeSignalHandler/null |--java.lang.System/null |--java.lang.Thread$UncaughtExceptionHandler/null (intf) |--sun.misc.Signal/null |--java.security.PermissionCollection/null | |--java.security.BasicPermissionCollection/null | |--java.io.FilePermissionCollection/null | |--java.security.Permissions/null |--sun.nio.ch.NativeThreadSet/null |--sun.misc.URLClassPath$Loader/null | |--sun.misc.URLClassPath$FileLoader/null | |--sun.misc.URLClassPath$JImageLoader/null |--java.lang.Thread/null | |--java.lang.ref.Reference$ReferenceHandler/null | |--java.lang.ref.Finalizer$FinalizerThread/null | |--sun.misc.InnocuousThread/null |--NeverExit/0xa5b37ea0 |--java.net.URLStreamHandler/null | |--sun.net.www.protocol.jar.Handler/null | |--sun.net.www.protocol.file.Handler/null |--java.lang.invoke.MemberName/null |--NE2/0xa5b37ea0 (intf) |--NE1/0xa5b37ea0 (intf) |--java.lang.Terminator$1/null |--sun.nio.ch.IOUtil$1/null |--sun.misc.SignalHandler/null (intf) |--java.lang.CharSequence/null (intf) |--java.lang.Terminator/null |--java.nio.charset.CodingErrorAction/null |--java.nio.charset.CoderResult$Cache/null | |--java.nio.charset.CoderResult$2/null | |--java.nio.charset.CoderResult$1/null |--sun.nio.ch.IOUtil/null |--sun.net.www.protocol.jrt.JavaRuntimeURLConnection$ResourceFinder/null (intf) |--java.lang.Comparable/null (intf) |--java.security.AccessController/null |--java.io.Serializable/null (intf) |--java.lang.ClassLoader/null | |--java.security.SecureClassLoader/null | | |--java.net.URLClassLoader/null | | | |--sun.misc.Launcher$AppClassLoader/null | | | |--sun.misc.Launcher$ExtClassLoader/null | |--sun.reflect.DelegatingClassLoader/null |--java.io.ExpiringCache$Entry/null |--java.nio.charset.CoderResult/null |--sun.reflect.misc.ReflectUtil/null |--sun.misc.URLClassPath$3/null |--java.nio.charset.CharsetDecoder/null | |--sun.nio.cs.UTF_8$Decoder/null |--java.net.URLConnection/null | |--sun.net.www.URLConnection/null | | |--sun.net.www.protocol.file.FileURLConnection/null | | |--sun.net.www.protocol.jrt.JavaRuntimeURLConnection/null |--sun.net.util.URLUtil/null |--java.io.File/null |--java.lang.ClassLoader$3/null |--sun.reflect.Reflection/null |--java.net.URLClassLoader$1/null |--java.util.StringTokenizer/null |--java.lang.StringCoding$StringEncoder/null |--java.nio.file.attribute.FileAttribute/null (intf) |--java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl$1/null |--java.security.Permission/null | |--java.security.UnresolvedPermission/null | |--java.security.AllPermission/null | |--java.io.FilePermission/null | |--java.security.BasicPermission/null | | |--java.lang.reflect.ReflectPermission/null | | |--java.lang.RuntimePermission/null |--java.security.PrivilegedExceptionAction/null (intf) |--sun.nio.ch.IOStatus/null |--java.lang.Runnable/null (intf) |--java.security.Guard/null (intf) |--java.lang.SystemClassLoaderAction/null |--java.lang.ClassLoader$NativeLibrary/null From chris.plummer at oracle.com Tue Feb 10 01:56:34 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 09 Feb 2015 17:56:34 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> <54D520D3.3070804@oracle.com> <54D849E2.2040106@oracle.com> <54D8EFFE.6040209@oracle.com> Message-ID: <54D96552.1000606@oracle.com> Arrg. Just noticed these emails after I sent my webrev. They got snagged by my openjdk filter for later viewing. I had been expecting all replies to CC me and be in my inbox. serviceability-dev at openjdk.java.net also got removed, so they've been re-added. Anyway, good point on both j.l.ClassLoader address suffering from objects moving (which is why I went with Klass*), and good point that more than one ClassLoader instance can have the same Klass*. I will change back to using the CLD*, but still use null for the bootstrap classloader since that makes it easier to read the output. Please still review the webrev I just sent out. The change to CLD* will be pretty simple and not impact the existing logic. I can send out an incremental webrev to cover changes for it and any addition work that may still be needed. thanks, Chris On 2/9/15 11:33 AM, Staffan Larsen wrote: > Very good point! Let?s go with ClassLoaderData. > > /Staffan > >> On 9 feb 2015, at 18:35, Ioi Lam wrote: >> >> Hmm, you may have two instances of the same j.l.ClassLoader type, and their Klass will have the same value. This means you can't distinguish between the ClassLoader instances. >> >> So, maybe we should change all the jcmd code to print a unique identifier for each ClassLoader instance. ClassLoaderData seems a good choice :-) >> >> - Ioi >> >> >> On 2/9/15, 1:40 AM, Staffan Larsen wrote: >>> Using the address of the Klass of the j.l.ClassLoader is good. It is also printed by VM.classloader_stats so allows for correlation there too. (Note that printing address of the j.l.ClassLoader itself is not a good idea since that can change during the lifetime of the JVM). >>> >>> /Staffan >>> >>>> On 9 feb 2015, at 06:47, Ioi Lam wrote: >>>> >>>> I agree that we should use the address of the j.l.ClassLoader. This way, we can match the output with that of GC.class_stats, which prints out the class loader as: >>>> >>>> class loader 0x00007fc09c11d3d0a 'sun/misc/Launcher$AppClassLoader' >>>> >>>> Thanks >>>> - Ioi >>>> >>>> On 2/6/15, 1:21 PM, Karen Kinnear wrote: >>>>> Chris, >>>>> >>>>> So I was curious - I was thinking you would printing the hex address of the j.l.ClassLoader class rather than the cld so that if folks were to look >>>>> at a heap dump later it might be meaningful to them. Is it unlikely that they would ever want to correlate those? >>>>> >>>>> >>>>> On Feb 6, 2015, at 3:15 PM, Chris Plummer wrote: >>>>> >>>>>> I was also thinking it might be a good idea to indicate what the hex value is, although still have figured out the best way of doing this. Maybe just a simple comment before the output. Keep in mind that eventually other DCMDS will also include the cld to help uniquiely identify classes across dcmd output. Also keep in mind your earlier suggestion: >>>>>> >>>>>> java.lang.Object/0x12345600 >>>>>> |--java.io.Serializable/0x12345601 >>>>>> |--java.util.RandomAccess/0x12345602 >>>>>> |--java.lang.Iterable/0x12345603 >>>>>> | |--java.util.Collection/0x12345604 >>>>>> | | |--java.util.List/0x12345605 >>>>>> |--java.util.AbstractCollection/0x12345606 >>>>>> | | implements java.util.Collection/0x12345604 >>>>>> | | implements java.lang.Iterable/0x12345603 >>>>>> | |--java.util.AbstractList/0x12345607 >>>>>> | | implements java.util.List/0x12345605 >>>>>> | | |--java.util.Arrays$ArrayList/0x12345608 >>>>>> | | | implements java.io.Serializable/0x12345601 >>>>>> | | | implements java.util.RandomAccess/0x12345602 >>>>>> >>>>>> With additions to GC.class_stats: >>>>>> >>>>>> Index Super ClassLoader ClassName >>>>>> 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 >>>>>> 2 1 0x00000007c0034c48 java.util.List/0x12345605 >>>>>> 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 >>>>>> >>>>>> And GC.class_histogram: >>>>>> >>>>>> num #instances #bytes class name >>>>>> ---------------------------------------------- >>>>>> 1: 945 117736 java.lang.Object/0x12345600 >>>>>> 2: 442 50352 java.util.List/0x12345605 >>>>>> 3: 499 25288 java.util.AbstractList/0x12345607 >>>>>> >>>>>> I think in your case you assumed we would create a unique identifier for each class, but then we settled on just classname + ClassLoader identifier of some sort, and the CLD* works for that. So replace your hex class ID in the above with the hex CLD*. >>>>>> >>>>>> Also something Karen had said is just now starting to sink in and make sense to me: >>>>>> >>>>>> |-sun.misc.Launcher$AppClassLoader/null (0xyyy) >>>>>> |-myapp/0xyyy >>>>>> >>>>>> I think the idea here is that when printing a ClassLoader subclass, you include two CLDs. The first is for the ClassLoader that loaded the class, and the second is the CLD for the ClassLoader subclass itself. Thus the above indicates that myapp was loaded by 0xyyy, which is the sun.misc.Launcher$AppClassLoader, which was loaded by the null ClassLoader. >>>>> I apologize - I don't remember what I said. But I am not sure we need that level of complexity. I think I was asking that one of the dcmds that gives >>>>> information could print information like 0xabc "a sun.misc.Launcher$AppClassLoader" or "a WLS.blah.GenericClassLoader" if we don't want to include >>>>> that everywhere. Mostly people want to know the name of the class loader. Since they don't yet have names, they want to know the type of the >>>>> classloader. So that string "a MyClassLoader" would be more meaningful than the 0xabc - except that if they >>>>> have 5 of those they need the uniqueness. So personally I think I was proposing the >>>>> java.base, 0xA/"a MyClassLoader", iface). >>>>> >>>>> But I would defer to Staffan if he suggests something else. >>>>> >>>>> thanks for your patience, >>>>> Karen >>>>>> With regard to the '/' format, keep in mind that we also need an indicator of whether or not it's an interface, and there's also a request to include the module name when that becomes available. At one point you requested the following, which is what I was aiming for: >>>>>> >>>>>> java.lang.Object >>>>>> |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) >>>>>> |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) >>>>>> >>>>>> So maybe I can do: >>>>>> >>>>>> java.lang.Object >>>>>> |--java.io.Serializable/0x00000007c00375f8 (java.base, intf) >>>>>> |--java.util.RandomAccess/0x00000007c00375f8 (java.base, intf) >>>>>> ... >>>>>> |-sun.misc.Launcher$AppClassLoader/0x00000007c00375f8 (java.base, CLD=0x000000087654320) >>>>>> |-myapp/0x000000087654320 >>>>>> >>>>>> So now the classname and its classloader id (which is the CLD*) are grouped together to make it easy to strip out or to search for in more than one dcmd output. I think this is probably what you were striving when you proposed using '/', and other DCMDs can eventually be changed to do the same. Also, once you know the CLD of the ClassLoader, you can find out the name of the ClassLoader class by looking for CLD= >>>>>> >>>>>> I can go with "null" for the null ClassLoader if you want. I used it's ClassLoaderData* to be consistent with the other ClassLoaders. Just let me know which you prefer. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 2/6/15 12:52 AM, Staffan Larsen wrote: >>>>>>> I think this looks good! Perhaps we should give a hint as to what the hex value is? I don?t know if it is best to print this as part of a ?header? printed before the rest of the output or if we should include it as part of each line ?(classloaderdata*=0x080609c8)?. >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>>> On 6 feb 2015, at 05:49, Chris Plummer wrote: >>>>>>>> >>>>>>>> [Hmm. My previous email somehow included the attachment with the dcmd output, but not the body of the message, so here it is again.] >>>>>>>> >>>>>>>> Hey Folks, >>>>>>>> >>>>>>>> Sorry about the delay in getting the next webrev for this out. I was sidetracked by a few other things, including being out sick of almost a week, and there were also quite a few changes to make. >>>>>>>> >>>>>>>> I'm ready for review with an updated webrev, but thought first I'd have you look at and comment on the output. Please see the attached file. It now supports: >>>>>>>> >>>>>>>> printing the hierarchy for a single class >>>>>>>> optionally including all subclasses of the specified class (-s) >>>>>>>> for each class, also list all of its interfaces (-i) >>>>>>>> >>>>>>>> The hex value in the output is the address of the ClassLoaderData for the ClassLoader of the class. I did not include the address of the Klass, but could if you think it would be useful. Changing the format of what comes after the classname is easy. Just let me know what you think is best. >>>>>>>> >>>>>>>> I have not updated any other dcmds to be consistent with how classes are uniquely identified. A separate bug should be filed for that. Actually I thought one was, but I looked through this thread's history and could not find mention of it. I also have not implemented the reverse hierarchy dcmd. JDK-8068830 has already been filed for that, but there are no plans to work on it in the near term. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris From chris.plummer at oracle.com Tue Feb 10 02:00:51 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 09 Feb 2015 18:00:51 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D962C6.1060505@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> Message-ID: <54D96653.1010502@oracle.com> [Once again the attachment went out but the main body was stripped. Not too sure what's going on, but here it is again. Sorry if you are getting this twice.] I've attached updated output: ? I now use the Klass* of the ClassLoader instead of the CLD*, and this is documented in the help output. ? The Klass* of the ClassLoader now immediately follows the class name, and is also included when printing interface names. The webrevs can be found at: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.01/ http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00-01/ The first is the full webrev. The 2nd is what's changed since the last webrev that was reviewed. Changes since then include: ? Support for printing the hierarchy of just one class. ? -s option for optionally including subclasses when printing one class. ? -i option for optionally including interfaces implemented by a class. ? Output formatting changes. ? Fixed some comment typos as requested. ? I moved a couple of KlassInfoEntry methods out of the .hpp file and into the .cpp file as requested. ? No longer keep track of the stack of superclasses when processing all the classes as requested. This also means the super_index field I added is no longer needed. ? Moved some code within an already existing " #if INCLUDE_SERVICES" block as requested. thanks, Chris From jaroslav.bachorik at oracle.com Tue Feb 10 09:22:25 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 10 Feb 2015 10:22:25 +0100 Subject: [ping] Re: RFR 8069286: Unexpected count of notification in LowMemoryTest In-Reply-To: <54CF9EC9.7000909@oracle.com> References: <54CF9EC9.7000909@oracle.com> Message-ID: <54D9CDD1.1040709@oracle.com> On 2.2.2015 16:59, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8069286 > Webrev: http://cr.openjdk.java.net/~jbachorik/8069286/webrev.00 > > In JDK-8034263 the conditions on the number of notifications were > relaxed for the cases when running with CMS GC. Due to the nature of CMS > we can assert only that at least the required number of notifications > was fired. The fix omitted the fact that the assertion should be relaxed > also on the gc count passed in the notifications. This patch takes care > of the omission. > > Thanks, > > -JB- From staffan.larsen at oracle.com Tue Feb 10 12:19:24 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Feb 2015 13:19:24 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D96653.1010502@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> Message-ID: <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> Chris, In general I think this looks very good. Simple and well-commented code to follow. I am missing a test, though. Please look at the hotspot/test/serviceability/dcmd set of tests. A couple of smaller comments: Are Unsafe.defineAnonymousClass classes included? Should they be? I think ClassHierarchyDCmd should include this code as well to restrict remote access: static const JavaPermission permission() { JavaPermission p = {"java.lang.management.ManagementPermission", "monitor", NULL}; return p; } diagnosticCommand.hpp:278: Missing ?if? in the comment vm_operations.hpp: Spelling error in ?VM_PrintClassHierachry? and ?PrintClassHierachry? vm_operations.hpp:461: Should the complete class be surrounded by "#if INCLUDE_SERVICES? ? heapInspection.hpp:272: The constructor and destructor does not seem to be used. Because of that you should also change it to a AllStatic class. heapInspection.cpp:339: Shouldn?t this be labeled as an ?error?? Thanks, /Staffan > On 10 feb 2015, at 03:00, Chris Plummer wrote: > > [Once again the attachment went out but the main body was stripped. Not too sure what's going on, but here it is again. Sorry if you are getting this twice.] > > I've attached updated output: > > ? I now use the Klass* of the ClassLoader instead of the CLD*, and this is documented in the help output. > ? The Klass* of the ClassLoader now immediately follows the class name, and is also included when printing interface names. > > The webrevs can be found at: > > http://cr.openjdk.java.net/~cjplummer/8054888/webrev.01/ > http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00-01/ > > The first is the full webrev. The 2nd is what's changed since the last webrev that was reviewed. Changes since then include: > > ? Support for printing the hierarchy of just one class. > ? -s option for optionally including subclasses when printing one class. > ? -i option for optionally including interfaces implemented by a class. > ? Output formatting changes. > ? Fixed some comment typos as requested. > ? I moved a couple of KlassInfoEntry methods out of the .hpp file and into the .cpp file as requested. > ? No longer keep track of the stack of superclasses when processing all the classes as requested. This also means the super_index field I added is no longer needed. > ? Moved some code within an already existing " #if INCLUDE_SERVICES" block as requested. > > thanks, > > Chris > From dmitry.samersoff at oracle.com Tue Feb 10 15:39:18 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 10 Feb 2015 18:39:18 +0300 Subject: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match Message-ID: <54DA2626.6030308@oracle.com> Hi Everyone, Please review the changes: http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ if maximum heap size is not specified explicitly JVM might change this value and it wouldn't match one printed on start. The fix makes sure that LingeredApp starts with -Xmx option. -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 mandy.chung at oracle.com Tue Feb 10 17:09:53 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Feb 2015 09:09:53 -0800 Subject: [ping] Re: RFR 8069286: Unexpected count of notification in LowMemoryTest In-Reply-To: <54D9CDD1.1040709@oracle.com> References: <54CF9EC9.7000909@oracle.com> <54D9CDD1.1040709@oracle.com> Message-ID: <54DA3B61.9020407@oracle.com> On 2/10/15 1:22 AM, Jaroslav Bachorik wrote: > On 2.2.2015 16:59, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8069286 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8069286/webrev.00 >> 142 private boolean checkValue(long value, int target) { 143 if (isRelaxed) { 144 return value == target; 145 } else { 146 return value >= target; 147 } 148 } should line 143 be !isRelaxed? Mandy From staffan.larsen at oracle.com Tue Feb 10 19:45:03 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Feb 2015 20:45:03 +0100 Subject: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match In-Reply-To: <54DA2626.6030308@oracle.com> References: <54DA2626.6030308@oracle.com> Message-ID: <4ACF49CA-75E4-49A0-8C75-4CA7BC1B143F@oracle.com> I don?t think you need to respect -Xmx if it set from outside. We know that this test is not testing -Xmx, it is just using that flag to check that jmap works. You can override the value of -Xmx in two ways: 1) either set your value before or after the other value (I don?t know which value takes precedence) so that your value is the one that is used, or 2) use Utils.getFilteredTestJavaOpts() to remove any -Xmx flags from the VM options before adding yours. desiredMaxHeapSize should say ?-Xmx128? not ?-Xms128?. /Staffan > On 10 feb 2015, at 16:39, Dmitry Samersoff wrote: > > Hi Everyone, > > Please review the changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ > > if maximum heap size is not specified explicitly JVM might change this > value and it wouldn't match one printed on start. > > The fix makes sure that LingeredApp starts with -Xmx option. > > -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 Tue Feb 10 19:52:58 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 10 Feb 2015 22:52:58 +0300 Subject: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match In-Reply-To: <4ACF49CA-75E4-49A0-8C75-4CA7BC1B143F@oracle.com> References: <54DA2626.6030308@oracle.com> <4ACF49CA-75E4-49A0-8C75-4CA7BC1B143F@oracle.com> Message-ID: <54DA619A.3090503@oracle.com> Staffan, > I don?t think you need to respect -Xmx if it set from outside. Embedded systems can have special requirements like 2mb heap that is not possible to set on a big machine. If it is not the case - I'll change the code to use Utils.getFilteredTestJavaOpts() -Dmitry On 2015-02-10 22:45, Staffan Larsen wrote: > I don?t think you need to respect -Xmx if it set from outside. We > know that this test is not testing -Xmx, it is just using that flag > to check that jmap works. You can override the value of -Xmx in two > ways: 1) either set your value before or after the other value (I > don?t know which value takes precedence) so that your value is the > one that is used, or 2) use Utils.getFilteredTestJavaOpts() to remove > any -Xmx flags from the VM options before adding yours. > > desiredMaxHeapSize should say ?-Xmx128? not ?-Xms128?. > > /Staffan > >> On 10 feb 2015, at 16:39, Dmitry Samersoff >> wrote: >> >> Hi Everyone, >> >> Please review the changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ >> >> if maximum heap size is not specified explicitly JVM might change >> this value and it wouldn't match one printed on start. >> >> The fix makes sure that LingeredApp starts with -Xmx option. >> >> -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 staffan.larsen at oracle.com Tue Feb 10 19:59:56 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Feb 2015 20:59:56 +0100 Subject: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match In-Reply-To: <54DA619A.3090503@oracle.com> References: <54DA2626.6030308@oracle.com> <4ACF49CA-75E4-49A0-8C75-4CA7BC1B143F@oracle.com> <54DA619A.3090503@oracle.com> Message-ID: <438FD2C1-A379-4D7F-85ED-1EF660C9A871@oracle.com> > On 10 feb 2015, at 20:52, Dmitry Samersoff wrote: > > Staffan, > >> I don?t think you need to respect -Xmx if it set from outside. > > Embedded systems can have special requirements like 2mb heap that is not > possible to set on a big machine. That is a good point. Leave the logic you have in there, but change the loop to: List jvmOptions = Utils.getVmOptions(); for (String option : jvmOptions) { if (option.startsWith("-Xmx")) { System.out.println("INFO: maximum heap size set by JTREG as " + option); mx_found = true; break; } } /S > > If it is not the case - I'll change the code to use > Utils.getFilteredTestJavaOpts() > > -Dmitry > > On 2015-02-10 22:45, Staffan Larsen wrote: >> I don?t think you need to respect -Xmx if it set from outside. We >> know that this test is not testing -Xmx, it is just using that flag >> to check that jmap works. You can override the value of -Xmx in two >> ways: 1) either set your value before or after the other value (I >> don?t know which value takes precedence) so that your value is the >> one that is used, or 2) use Utils.getFilteredTestJavaOpts() to remove >> any -Xmx flags from the VM options before adding yours. >> >> desiredMaxHeapSize should say ?-Xmx128? not ?-Xms128?. >> >> /Staffan >> >>> On 10 feb 2015, at 16:39, Dmitry Samersoff >>> wrote: >>> >>> Hi Everyone, >>> >>> Please review the changes: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ >>> >>> if maximum heap size is not specified explicitly JVM might change >>> this value and it wouldn't match one printed on start. >>> >>> The fix makes sure that LingeredApp starts with -Xmx option. >>> >>> -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 Tue Feb 10 20:02:55 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 10 Feb 2015 23:02:55 +0300 Subject: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match In-Reply-To: <438FD2C1-A379-4D7F-85ED-1EF660C9A871@oracle.com> References: <54DA2626.6030308@oracle.com> <4ACF49CA-75E4-49A0-8C75-4CA7BC1B143F@oracle.com> <54DA619A.3090503@oracle.com> <438FD2C1-A379-4D7F-85ED-1EF660C9A871@oracle.com> Message-ID: <54DA63EF.3060205@oracle.com> Staffan, OK. Will do. -Dmitry On 2015-02-10 22:59, Staffan Larsen wrote: > >> On 10 feb 2015, at 20:52, Dmitry Samersoff wrote: >> >> Staffan, >> >>> I don?t think you need to respect -Xmx if it set from outside. >> >> Embedded systems can have special requirements like 2mb heap that is not >> possible to set on a big machine. > > That is a good point. Leave the logic you have in there, but change the loop to: > > List jvmOptions = Utils.getVmOptions(); > for (String option : jvmOptions) { > if (option.startsWith("-Xmx")) { > System.out.println("INFO: maximum heap size set by JTREG as " + option); > mx_found = true; > break; > } > } > > /S > >> >> If it is not the case - I'll change the code to use >> Utils.getFilteredTestJavaOpts() >> >> -Dmitry >> >> On 2015-02-10 22:45, Staffan Larsen wrote: >>> I don?t think you need to respect -Xmx if it set from outside. We >>> know that this test is not testing -Xmx, it is just using that flag >>> to check that jmap works. You can override the value of -Xmx in two >>> ways: 1) either set your value before or after the other value (I >>> don?t know which value takes precedence) so that your value is the >>> one that is used, or 2) use Utils.getFilteredTestJavaOpts() to remove >>> any -Xmx flags from the VM options before adding yours. >>> >>> desiredMaxHeapSize should say ?-Xmx128? not ?-Xms128?. >>> >>> /Staffan >>> >>>> On 10 feb 2015, at 16:39, Dmitry Samersoff >>>> wrote: >>>> >>>> Hi Everyone, >>>> >>>> Please review the changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ >>>> >>>> if maximum heap size is not specified explicitly JVM might change >>>> this value and it wouldn't match one printed on start. >>>> >>>> The fix makes sure that LingeredApp starts with -Xmx option. >>>> >>>> -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 Feb 10 20:07:31 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 10 Feb 2015 23:07:31 +0300 Subject: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match In-Reply-To: <438FD2C1-A379-4D7F-85ED-1EF660C9A871@oracle.com> References: <54DA2626.6030308@oracle.com> <4ACF49CA-75E4-49A0-8C75-4CA7BC1B143F@oracle.com> <54DA619A.3090503@oracle.com> <438FD2C1-A379-4D7F-85ED-1EF660C9A871@oracle.com> Message-ID: <54DA6503.2010604@oracle.com> Staffan, Changed in-place (press shift-reload) -Dmitry On 2015-02-10 22:59, Staffan Larsen wrote: > >> On 10 feb 2015, at 20:52, Dmitry Samersoff wrote: >> >> Staffan, >> >>> I don?t think you need to respect -Xmx if it set from outside. >> >> Embedded systems can have special requirements like 2mb heap that is not >> possible to set on a big machine. > > That is a good point. Leave the logic you have in there, but change the loop to: > > List jvmOptions = Utils.getVmOptions(); > for (String option : jvmOptions) { > if (option.startsWith("-Xmx")) { > System.out.println("INFO: maximum heap size set by JTREG as " + option); > mx_found = true; > break; > } > } > > /S > >> >> If it is not the case - I'll change the code to use >> Utils.getFilteredTestJavaOpts() >> >> -Dmitry >> >> On 2015-02-10 22:45, Staffan Larsen wrote: >>> I don?t think you need to respect -Xmx if it set from outside. We >>> know that this test is not testing -Xmx, it is just using that flag >>> to check that jmap works. You can override the value of -Xmx in two >>> ways: 1) either set your value before or after the other value (I >>> don?t know which value takes precedence) so that your value is the >>> one that is used, or 2) use Utils.getFilteredTestJavaOpts() to remove >>> any -Xmx flags from the VM options before adding yours. >>> >>> desiredMaxHeapSize should say ?-Xmx128? not ?-Xms128?. >>> >>> /Staffan >>> >>>> On 10 feb 2015, at 16:39, Dmitry Samersoff >>>> wrote: >>>> >>>> Hi Everyone, >>>> >>>> Please review the changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ >>>> >>>> if maximum heap size is not specified explicitly JVM might change >>>> this value and it wouldn't match one printed on start. >>>> >>>> The fix makes sure that LingeredApp starts with -Xmx option. >>>> >>>> -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 martinrb at google.com Tue Feb 10 21:08:28 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Feb 2015 13:08:28 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> Message-ID: I'm not a serviceability engineer, but I reviewed this change and it seems fine to me. Can someone from Oracle please shepherd through CCC? On Mon, Feb 9, 2015 at 4:51 PM, Jeremy Manson wrote: > Thanks for taking a look, Staffan. Sorry about the delay. I've gone > ahead and made a test: > > http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ > > Can anyone drive the API process? It's such a minor change that I can't > imagine it wouldn't go through easily. Of course, I have no idea what's > involved. > > Jeremy > > On Mon, Jan 12, 2015 at 11:10 PM, Staffan Larsen < > staffan.larsen at oracle.com> wrote: > >> >> > On 13 jan 2015, at 06:28, David Holmes wrote: >> > >> > Hi Jeremy, >> > >> > On 13/01/2015 4:32 AM, Jeremy Manson wrote: >> >> Hi folks, >> >> >> >> This was long forgotten, seems to have been lost in the shuffle. I've >> >> done it, since we could use it, too: >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-6588467 >> >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.00/ >> > >> > Codewise this all appears fine to me. >> >> Thanks for doing this. I have only scanned the code, but did not see any >> test. Could you please add tests for the new API? >> >> >> Since it is an API change (albeit an uncontroversial one), it will have >> >> to go through whatever the super-secret API change review process is >> >> that you folks do. >> > >> > Not sure if this just needs an API tweak or a JMX spec revision. If the >> latter then this might be a big deal. But I'll leave that to the official >> serviceability folk :) >> >> No spec revision is needed, same process as for all API changes. >> Unfortunately I don?t have the time to drive that, so hoping someone else >> can jump in. >> >> /Staffan >> >> > >> > Cheers, >> > David >> > >> >> Thanks! >> >> >> >> Jeremy >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varming at gmail.com Tue Feb 10 22:18:00 2015 From: varming at gmail.com (Carsten Varming) Date: Tue, 10 Feb 2015 17:18:00 -0500 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: References: <54D1861C.1020309@oracle.com> <54D19FF8.9060901@oracle.com> Message-ID: Dear David, Any news regarding this fix? Anything I can do to help? Best wishes, Carsten On Wed, Feb 4, 2015 at 12:54 PM, Carsten Varming wrote: > Dear David, > > I took a look at all occurrences of PeriodicTask_lock. We are in luck: > > PeriodicTask::enroll and PeriodicTask::disenroll check for safepoints when > acquiring PeriodicTask_lock. > > PeriodicTask::time_to_wait and PeriodicTask::real_time_tick are called > only by the watcher thread. > > WatcherThread::unpark is used only in contexts where PeriodicTask_lock is > owned by the caller. > > WatcherThread::sleep is called only by the watcher thread. > > I took another look at WatcherThread::sleep and realized that there is a > path from acquiring PeriodicTask_lock to waiting on the lock where > _should_terminate is not checked. I added that to the minimal fix attached. > > Looking at these methods made me want to clean up a little more. See > better.patch attached. > > I feel pretty good about the patch with the limited usage of > no_safepoint_check_flag with PeriodicTask_lock. > > Carsten > > > On Tue, Feb 3, 2015 at 11:28 PM, David Holmes > wrote: > >> On 4/02/2015 1:28 PM, Carsten Varming wrote: >> >>> Dear David Holmes, >>> >>> Please see inline response, >>> >>> On Tue, Feb 3, 2015 at 9:38 PM, David Holmes >> > wrote: >>> >>> On 4/02/2015 5:00 AM, Carsten Varming wrote: >>> >>> Greetings all, >>> >>> I was recently introduced to the deadlock described in >>> JDK-8047720 and >>> fixed in JDK9. The fix seems a little messy to me, and it looks >>> like it >>> left some very short races in the code. So I decided to clean up >>> the >>> code. See attached diff. >>> >>> The change takes a step back and acquires PeriodicTask_lock in >>> WatcherThread::stop (like before the fix in JDK9), but this time >>> safepoints are allowed to proceed when acquiring >>> PeriodicTask_lock, >>> preventing the deadlock. >>> >>> >>> It isn't obvious that blocking for a safepoint whilst in this method >>> will always be a safe thing to do. That would need to be examined in >>> detail - potential interactions can be very subtle. >>> >>> >>> Absolutely true. For reference, the pattern is repeated with the >>> Terminator_lock a few lines below. The pattern is also used in >>> Threads::destroy_vm before and after calling before_exit, and the java >>> shutdown hooks are called right before the call to before_exit. So there >>> is a lot of evidence that safepoints are allowed to happen in this >>> context. >>> >> >> The thread calling before_exit is a JavaThread so of course it >> participates in safepoints. The issue is whether the interaction between >> that thread and the WatcherThread, via the PeriodicTask_lock, can allow for >> the JavaThread blocking at a safepoint whilst owning that lock. If another >> JavaThread can try to lock it without a safepoint check then we can get a >> deadlock. >> >> Cheers, >> David >> >> >> Thank you for taking your time to look at this, >>> Carsten >>> >>> >>> David >>> >>> >>> Let me know what you think, >>> Carsten >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Feb 11 00:47:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Feb 2015 10:47:23 +1000 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: References: <54D1861C.1020309@oracle.com> <54D19FF8.9060901@oracle.com> Message-ID: <54DAA69B.6040701@oracle.com> Hi Carsten, On 11/02/2015 8:18 AM, Carsten Varming wrote: > Dear David, > > Any news regarding this fix? Anything I can do to help? The bug has been assigned to Dan Daugherty so it depends on his workload. Verifying the safety of the change is a time consuming task. Thanks, David > Best wishes, > Carsten > > On Wed, Feb 4, 2015 at 12:54 PM, Carsten Varming > wrote: > > Dear David, > > I took a look at all occurrences of PeriodicTask_lock. We are in luck: > > PeriodicTask::enroll and PeriodicTask::disenroll check for > safepoints when acquiring PeriodicTask_lock. > > PeriodicTask::time_to_wait and PeriodicTask::real_time_tick are > called only by the watcher thread. > > WatcherThread::unpark is used only in contexts where > PeriodicTask_lock is owned by the caller. > > WatcherThread::sleep is called only by the watcher thread. > > I took another look at WatcherThread::sleep and realized that there > is a path from acquiring PeriodicTask_lock to waiting on the lock > where _should_terminate is not checked. I added that to the minimal > fix attached. > > Looking at these methods made me want to clean up a little more. See > better.patch attached. > > I feel pretty good about the patch with the limited usage of > no_safepoint_check_flag with PeriodicTask_lock. > > Carsten > > > On Tue, Feb 3, 2015 at 11:28 PM, David Holmes > > wrote: > > On 4/02/2015 1:28 PM, Carsten Varming wrote: > > Dear David Holmes, > > Please see inline response, > > On Tue, Feb 3, 2015 at 9:38 PM, David Holmes > > >> wrote: > > On 4/02/2015 5:00 AM, Carsten Varming wrote: > > Greetings all, > > I was recently introduced to the deadlock described in > JDK-8047720 and > fixed in JDK9. The fix seems a little messy to me, > and it looks > like it > left some very short races in the code. So I > decided to clean up the > code. See attached diff. > > The change takes a step back and acquires > PeriodicTask_lock in > WatcherThread::stop (like before the fix in JDK9), > but this time > safepoints are allowed to proceed when acquiring > PeriodicTask_lock, > preventing the deadlock. > > > It isn't obvious that blocking for a safepoint whilst > in this method > will always be a safe thing to do. That would need to > be examined in > detail - potential interactions can be very subtle. > > > Absolutely true. For reference, the pattern is repeated with the > Terminator_lock a few lines below. The pattern is also used in > Threads::destroy_vm before and after calling before_exit, > and the java > shutdown hooks are called right before the call to > before_exit. So there > is a lot of evidence that safepoints are allowed to happen > in this context. > > > The thread calling before_exit is a JavaThread so of course it > participates in safepoints. The issue is whether the interaction > between that thread and the WatcherThread, via the > PeriodicTask_lock, can allow for the JavaThread blocking at a > safepoint whilst owning that lock. If another JavaThread can try > to lock it without a safepoint check then we can get a deadlock. > > Cheers, > David > > > Thank you for taking your time to look at this, > Carsten > > > David > > > Let me know what you think, > Carsten > > > > From david.holmes at oracle.com Wed Feb 11 01:02:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Feb 2015 11:02:08 +1000 Subject: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match In-Reply-To: <54DA6503.2010604@oracle.com> References: <54DA2626.6030308@oracle.com> <4ACF49CA-75E4-49A0-8C75-4CA7BC1B143F@oracle.com> <54DA619A.3090503@oracle.com> <438FD2C1-A379-4D7F-85ED-1EF660C9A871@oracle.com> <54DA6503.2010604@oracle.com> Message-ID: <54DAAA10.9000401@oracle.com> Looks okay to me. David On 11/02/2015 6:07 AM, Dmitry Samersoff wrote: > Staffan, > > Changed in-place (press shift-reload) > > -Dmitry > > On 2015-02-10 22:59, Staffan Larsen wrote: >> >>> On 10 feb 2015, at 20:52, Dmitry Samersoff wrote: >>> >>> Staffan, >>> >>>> I don?t think you need to respect -Xmx if it set from outside. >>> >>> Embedded systems can have special requirements like 2mb heap that is not >>> possible to set on a big machine. >> >> That is a good point. Leave the logic you have in there, but change the loop to: >> >> List jvmOptions = Utils.getVmOptions(); >> for (String option : jvmOptions) { >> if (option.startsWith("-Xmx")) { >> System.out.println("INFO: maximum heap size set by JTREG as " + option); >> mx_found = true; >> break; >> } >> } >> >> /S >> >>> >>> If it is not the case - I'll change the code to use >>> Utils.getFilteredTestJavaOpts() >>> >>> -Dmitry >>> >>> On 2015-02-10 22:45, Staffan Larsen wrote: >>>> I don?t think you need to respect -Xmx if it set from outside. We >>>> know that this test is not testing -Xmx, it is just using that flag >>>> to check that jmap works. You can override the value of -Xmx in two >>>> ways: 1) either set your value before or after the other value (I >>>> don?t know which value takes precedence) so that your value is the >>>> one that is used, or 2) use Utils.getFilteredTestJavaOpts() to remove >>>> any -Xmx flags from the VM options before adding yours. >>>> >>>> desiredMaxHeapSize should say ?-Xmx128? not ?-Xms128?. >>>> >>>> /Staffan >>>> >>>>> On 10 feb 2015, at 16:39, Dmitry Samersoff >>>>> wrote: >>>>> >>>>> Hi Everyone, >>>>> >>>>> Please review the changes: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ >>>>> >>>>> if maximum heap size is not specified explicitly JVM might change >>>>> this value and it wouldn't match one printed on start. >>>>> >>>>> The fix makes sure that LingeredApp starts with -Xmx option. >>>>> >>>>> -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 chris.plummer at oracle.com Wed Feb 11 03:13:37 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 10 Feb 2015 19:13:37 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> Message-ID: <54DAC8E1.3000608@oracle.com> Hi Staffan, Thanks for your feedback. A new incremental webrev can be found at: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.01-02/ Most changes are discussed inline below. Here are a couple of additional changes: - Changed "transitive interface" to "inherited interface" in the output. - Went back to using the CLD* instead of the Klass*, except still use "null" for the bootstrap ClassLoader. On 2/10/15 4:19 AM, Staffan Larsen wrote: > Chris, > > In general I think this looks very good. Simple and well-commented code to follow. I am missing a test, though. Please look at the hotspot/test/serviceability/dcmd set of tests. Added. > > > A couple of smaller comments: > > > Are Unsafe.defineAnonymousClass classes included? Should they be? I didn't really understand what you were talking about at first, but then when I started looking at ClassLoaderStatsTest.java, I saw the following: class TestClass { static { // force creation of anonymous class (for the lambdaform) Runnable r = () -> System.out.println("Hello"); r.run(); } } I added something similar to my test case and found a whole bunch of lines like the following are suddenly added to the output: |--java.lang.invoke.LambdaForm$MH/11440528/null And there is one that seems specifically for the test case: |--DcmdTestClass$$Lambda$1/4081552/0xa529fbb0 So I think they answer is yes they are added. As for whether or not they should be, I really don't know. That's probably up to you. GC.class_stats does include them however. BTW, I do not include array classes. They are intentionally stripped out since they don't really have relevance in a Class hierarchy analysis. I can easily add them back in if you want. > I think ClassHierarchyDCmd should include this code as well to restrict remote access: > static const JavaPermission permission() { > JavaPermission p = {"java.lang.management.ManagementPermission", > "monitor", NULL}; > return p; > } Ok. I was a bit unclear as to when this was really needed. > diagnosticCommand.hpp:278: Missing ???if??? in the comment Ok. > vm_operations.hpp: Spelling error in ???VM_PrintClassHierachry??? and ???PrintClassHierachry??? Ok. > vm_operations.hpp:461: Should the complete class be surrounded by "#if INCLUDE_SERVICES??? ? Yes, but I can't do anything about the reference in the VM_OPS_DO macro, at least not in a straight forward manner. I think that part is benign, but will find out when I do a minimal VM build. > heapInspection.hpp:272: The constructor and destructor does not seem to be used. Because of that you should also change it to a AllStatic class. Yeah, old code copied from HeapInspection class. I made it AllStatic and removed the constructor and destructor. However, my lack of C++ experience is showing here, and I haven't been happy about the existence of this KlassHierarchy class. It's static with just one public API. It's purpose in life is just to allow a VM operation to call that public method, but it just as easily could have been a regular C function call. Likewise the two private static methods in KlassHierarchy could have been C functions. There is no encapsulation or subclassing going on here. If you have recommendations for further improvement I'm open to suggestions. Otherwise I'll leave it with just the changes mentioned. > heapInspection.cpp:339: Shouldn???t this be labeled as an ???error???? That would probably be better. I had copied it from line 742. Should I make that one an ERROR also to be consistent? thanks, Chris > > Thanks, > /Staffan > > > > >> On 10 feb 2015, at 03:00, Chris Plummer wrote: >> >> [Once again the attachment went out but the main body was stripped. Not too sure what's going on, but here it is again. Sorry if you are getting this twice.] >> >> I've attached updated output: >> >> ??? I now use the Klass* of the ClassLoader instead of the CLD*, and this is documented in the help output. >> ??? The Klass* of the ClassLoader now immediately follows the class name, and is also included when printing interface names. >> >> The webrevs can be found at: >> >> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.01/ >> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00-01/ >> >> The first is the full webrev. The 2nd is what's changed since the last webrev that was reviewed. Changes since then include: >> >> ??? Support for printing the hierarchy of just one class. >> ??? -s option for optionally including subclasses when printing one class. >> ??? -i option for optionally including interfaces implemented by a class. >> ??? Output formatting changes. >> ??? Fixed some comment typos as requested. >> ??? I moved a couple of KlassInfoEntry methods out of the .hpp file and into the .cpp file as requested. >> ??? No longer keep track of the stack of superclasses when processing all the classes as requested. This also means the super_index field I added is no longer needed. >> ??? Moved some code within an already existing " #if INCLUDE_SERVICES" block as requested. >> >> thanks, >> >> Chris >> From staffan.larsen at oracle.com Wed Feb 11 07:46:41 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Feb 2015 08:46:41 +0100 Subject: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match In-Reply-To: <54DA6503.2010604@oracle.com> References: <54DA2626.6030308@oracle.com> <4ACF49CA-75E4-49A0-8C75-4CA7BC1B143F@oracle.com> <54DA619A.3090503@oracle.com> <438FD2C1-A379-4D7F-85ED-1EF660C9A871@oracle.com> <54DA6503.2010604@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 10 feb 2015, at 21:07, Dmitry Samersoff wrote: > > Staffan, > > Changed in-place (press shift-reload) > > -Dmitry > > On 2015-02-10 22:59, Staffan Larsen wrote: >> >>> On 10 feb 2015, at 20:52, Dmitry Samersoff wrote: >>> >>> Staffan, >>> >>>> I don?t think you need to respect -Xmx if it set from outside. >>> >>> Embedded systems can have special requirements like 2mb heap that is not >>> possible to set on a big machine. >> >> That is a good point. Leave the logic you have in there, but change the loop to: >> >> List jvmOptions = Utils.getVmOptions(); >> for (String option : jvmOptions) { >> if (option.startsWith("-Xmx")) { >> System.out.println("INFO: maximum heap size set by JTREG as " + option); >> mx_found = true; >> break; >> } >> } >> >> /S >> >>> >>> If it is not the case - I'll change the code to use >>> Utils.getFilteredTestJavaOpts() >>> >>> -Dmitry >>> >>> On 2015-02-10 22:45, Staffan Larsen wrote: >>>> I don?t think you need to respect -Xmx if it set from outside. We >>>> know that this test is not testing -Xmx, it is just using that flag >>>> to check that jmap works. You can override the value of -Xmx in two >>>> ways: 1) either set your value before or after the other value (I >>>> don?t know which value takes precedence) so that your value is the >>>> one that is used, or 2) use Utils.getFilteredTestJavaOpts() to remove >>>> any -Xmx flags from the VM options before adding yours. >>>> >>>> desiredMaxHeapSize should say ?-Xmx128? not ?-Xms128?. >>>> >>>> /Staffan >>>> >>>>> On 10 feb 2015, at 16:39, Dmitry Samersoff >>>>> wrote: >>>>> >>>>> Hi Everyone, >>>>> >>>>> Please review the changes: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ >>>>> >>>>> if maximum heap size is not specified explicitly JVM might change >>>>> this value and it wouldn't match one printed on start. >>>>> >>>>> The fix makes sure that LingeredApp starts with -Xmx option. >>>>> >>>>> -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 Wed Feb 11 08:04:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Feb 2015 09:04:53 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54DAC8E1.3000608@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> <54DAC8E1.3000608@oracle.com> Message-ID: This version looks good to me! Small comments inline. > On 11 feb 2015, at 04:13, Chris Plummer wrote: > > Hi Staffan, > > Thanks for your feedback. A new incremental webrev can be found at: > > http://cr.openjdk.java.net/~cjplummer/8054888/webrev.01-02/ > > Most changes are discussed inline below. Here are a couple of additional changes: > > - Changed "transitive interface" to "inherited interface" in the output. > - Went back to using the CLD* instead of the Klass*, except still use "null" for the bootstrap ClassLoader. Good. > > On 2/10/15 4:19 AM, Staffan Larsen wrote: >> Chris, >> >> In general I think this looks very good. Simple and well-commented code to follow. I am missing a test, though. Please look at the hotspot/test/serviceability/dcmd set of tests. > Added. Thanks! >> >> >> A couple of smaller comments: >> >> >> Are Unsafe.defineAnonymousClass classes included? Should they be? > I didn't really understand what you were talking about at first, but then when I started looking at ClassLoaderStatsTest.java, I saw the following: > > class TestClass { > static { > // force creation of anonymous class (for the lambdaform) > Runnable r = () -> System.out.println("Hello"); > r.run(); > } > } > > I added something similar to my test case and found a whole bunch of lines like the following are suddenly added to the output: > > |--java.lang.invoke.LambdaForm$MH/11440528/null > > And there is one that seems specifically for the test case: > > |--DcmdTestClass$$Lambda$1/4081552/0xa529fbb0 > > So I think they answer is yes they are added. As for whether or not they should be, I really don't know. That's probably up to you. GC.class_stats does include them however. I like to include them. > > BTW, I do not include array classes. They are intentionally stripped out since they don't really have relevance in a Class hierarchy analysis. I can easily add them back in if you want. I?m fine with skipping array classes. >> I think ClassHierarchyDCmd should include this code as well to restrict remote access: >> static const JavaPermission permission() { >> JavaPermission p = {"java.lang.management.ManagementPermission", >> "monitor", NULL}; >> return p; >> } > Ok. I was a bit unclear as to when this was really needed. >> diagnosticCommand.hpp:278: Missing ???if??? in the comment > Ok. >> vm_operations.hpp: Spelling error in ???VM_PrintClassHierachry??? and ???PrintClassHierachry??? > Ok. >> vm_operations.hpp:461: Should the complete class be surrounded by "#if INCLUDE_SERVICES??? ? > Yes, but I can't do anything about the reference in the VM_OPS_DO macro, at least not in a straight forward manner. I think that part is benign, but will find out when I do a minimal VM build. >> heapInspection.hpp:272: The constructor and destructor does not seem to be used. Because of that you should also change it to a AllStatic class. > Yeah, old code copied from HeapInspection class. I made it AllStatic and removed the constructor and destructor. However, my lack of C++ experience is showing here, and I haven't been happy about the existence of this KlassHierarchy class. It's static with just one public API. It's purpose in life is just to allow a VM operation to call that public method, but it just as easily could have been a regular C function call. Likewise the two private static methods in KlassHierarchy could have been C functions. There is no encapsulation or subclassing going on here. If you have recommendations for further improvement I'm open to suggestions. Otherwise I'll leave it with just the changes mentioned. I come from a C background as well, so I don?t have much to add here. I think this looks reasonable. >> heapInspection.cpp:339: Shouldn???t this be labeled as an ???error???? > That would probably be better. I had copied it from line 742. Should I make that one an ERROR also to be consistent? Yes, please. Thanks, /Staffan > > thanks, > > Chris >> >> Thanks, >> /Staffan >> >> >> >> >>> On 10 feb 2015, at 03:00, Chris Plummer wrote: >>> >>> [Once again the attachment went out but the main body was stripped. Not too sure what's going on, but here it is again. Sorry if you are getting this twice.] >>> >>> I've attached updated output: >>> >>> ??? I now use the Klass* of the ClassLoader instead of the CLD*, and this is documented in the help output. >>> ??? The Klass* of the ClassLoader now immediately follows the class name, and is also included when printing interface names. >>> >>> The webrevs can be found at: >>> >>> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.01/ >>> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00-01/ >>> >>> The first is the full webrev. The 2nd is what's changed since the last webrev that was reviewed. Changes since then include: >>> >>> ??? Support for printing the hierarchy of just one class. >>> ??? -s option for optionally including subclasses when printing one class. >>> ??? -i option for optionally including interfaces implemented by a class. >>> ??? Output formatting changes. >>> ??? Fixed some comment typos as requested. >>> ??? I moved a couple of KlassInfoEntry methods out of the .hpp file and into the .cpp file as requested. >>> ??? No longer keep track of the stack of superclasses when processing all the classes as requested. This also means the super_index field I added is no longer needed. >>> ??? Moved some code within an already existing " #if INCLUDE_SERVICES" block as requested. >>> >>> thanks, >>> >>> Chris >>> > > From mikael.auno at oracle.com Wed Feb 11 10:12:45 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Wed, 11 Feb 2015 11:12:45 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54DAC8E1.3000608@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> <54DAC8E1.3000608@oracle.com> Message-ID: <54DB2B1D.6000102@oracle.com> On 2015-02-11 04:13, Chris Plummer wrote: >> In general I think this looks very good. Simple and well-commented >> code to follow. I am missing a test, though. Please look at the >> hotspot/test/serviceability/dcmd set of tests. > Added. Your test is based on DcmdUtil.java which was removed last week (see [0]). If you pull new changes from hs-rt/hotspot, you'll see plenty of tests using the new DCMD utility classes in testlibrary. Also, the new tests are divided in different subdirectories depending on the commands, so as your test exercises VM.class_hierarchy it should go in .../dcmd/vm/ as opposed to just .../dcmd/. Thanks, Mikael [0] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/tip/test/serviceability/dcmd From dmitry.samersoff at oracle.com Wed Feb 11 10:41:00 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 11 Feb 2015 13:41:00 +0300 Subject: RFR(M): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting In-Reply-To: <6AF9CDB8-74D2-4FA0-B637-BE6D740189D2@oracle.com> References: <54D0C692.1090706@oracle.com> <54D10ABF.2050704@oracle.com> <54D210CF.206@oracle.com> <54D9F99D.2090603@oracle.com> <54DA1358.3090301@oracle.com> <848B5DCB-16A4-463C-BA83-C6DCAAE7DC6C@oracle.com> <54DA63A9.60207@oracle.com> <54DA773C.80805@oracle.com> <54DA7F84.7050106@oracle.com> <54DB090F.7050601@oracle.com> <6AF9CDB8-74D2-4FA0-B637-BE6D740189D2@oracle.com> Message-ID: <54DB31BC.9060105@oracle.com> Hi Everybody, Please review the changes: http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ 1. Removed lock age test, because LingeredApp can run more than one hour of machine time. 2. Added code to check for common environment pitfalls and produce meaningful diagnostic 3. Testlibrary method canPtraceAttachLinux refactored, fixed yama ptrace_scope check. 4. Sync Platfrom.java in hotspot and jdk testlibraries -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 Wed Feb 11 11:04:59 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Feb 2015 12:04:59 +0100 Subject: [ping] Re: RFR 8069286: Unexpected count of notification in LowMemoryTest In-Reply-To: <54DA3B61.9020407@oracle.com> References: <54CF9EC9.7000909@oracle.com> <54D9CDD1.1040709@oracle.com> <54DA3B61.9020407@oracle.com> Message-ID: <54DB375B.4080702@oracle.com> On 10.2.2015 18:09, Mandy Chung wrote: > On 2/10/15 1:22 AM, Jaroslav Bachorik wrote: >> On 2.2.2015 16:59, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8069286 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8069286/webrev.00 >>> > > 142 private boolean checkValue(long value, int target) { > 143 if (isRelaxed) { > 144 return value == target; > 145 } else { > 146 return value >= target; > 147 } > 148 } > > should line 143 be !isRelaxed? Oh, right - http://cr.openjdk.java.net/~jbachorik/8069286/webrev.01 -JB- > > Mandy > > From yasuenag at gmail.com Wed Feb 11 14:02:59 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 11 Feb 2015 23:02:59 +0900 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() Message-ID: <54DB6113.4080104@gmail.com> Hi all, I've committed JDK-8068589 to add new GCCause - Diagnostic Command. However, it has been backouted because test is failed [1] and it is not considered about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. I've created patch for this enhancement. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ I'm jdk9 committer, but I'm not employee at Oracle. So I need a Sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html From jaroslav.bachorik at oracle.com Wed Feb 11 16:10:03 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Feb 2015 17:10:03 +0100 Subject: RFR 8072932: Test fails with java.security.AccessControlException: access denied ("java.security.SecurityPermission" "getDomainCombiner") Message-ID: <54DB7EDB.3040506@oracle.com> Please, review the following simple change. Issue : https://bugs.openjdk.java.net/browse/JDK-8072932 Webrev: http://cr.openjdk.java.net/~jbachorik/8072932/webrev.00 This patch is about replacing the j.s.AccessControlContext.getDomainCombiner() with the package-private version j.s.AccessControlContext.getCombiner() to prevent the unnecessary privilege check done by the public getDomainCombiner() method. Thanks, -JB- From yekaterina.kantserova at oracle.com Wed Feb 11 16:42:01 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 11 Feb 2015 17:42:01 +0100 Subject: 8072856: Eliminate ProcessTools.getProcessId dependency on sun.management.VMManagement Message-ID: <54DB8659.7090106@oracle.com> Hi, Could I please have a review of this small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8072856 webrev: http://cr.openjdk.java.net/~ykantser/8072856/webrev.00/ Thanks, Katja From jaroslav.bachorik at oracle.com Wed Feb 11 16:54:53 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Feb 2015 17:54:53 +0100 Subject: 8072856: Eliminate ProcessTools.getProcessId dependency on sun.management.VMManagement In-Reply-To: <54DB8659.7090106@oracle.com> References: <54DB8659.7090106@oracle.com> Message-ID: <54DB895D.9050600@oracle.com> Looks good! -JB- On 11.2.2015 17:42, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8072856 > webrev: http://cr.openjdk.java.net/~ykantser/8072856/webrev.00/ > > Thanks, > Katja From daniel.fuchs at oracle.com Wed Feb 11 16:57:41 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 Feb 2015 17:57:41 +0100 Subject: 8072856: Eliminate ProcessTools.getProcessId dependency on sun.management.VMManagement In-Reply-To: <54DB8659.7090106@oracle.com> References: <54DB8659.7090106@oracle.com> Message-ID: <54DB8A05.1030601@oracle.com> Looks good to me too. JEP 102 Process Updates will provide an easier way to get the current process PID but we don't have that yet :-) best regards, -- daniel On 11/02/15 17:42, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8072856 > webrev: http://cr.openjdk.java.net/~ykantser/8072856/webrev.00/ > > Thanks, > Katja From mandy.chung at oracle.com Wed Feb 11 17:06:17 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Feb 2015 09:06:17 -0800 Subject: 8072856: Eliminate ProcessTools.getProcessId dependency on sun.management.VMManagement In-Reply-To: <54DB8A05.1030601@oracle.com> References: <54DB8659.7090106@oracle.com> <54DB8A05.1030601@oracle.com> Message-ID: <54DB8C09.2010207@oracle.com> +1 This is temporary. When the Process API is available, we can convert to use the new public API. Mandy On 2/11/2015 8:57 AM, Daniel Fuchs wrote: > Looks good to me too. > > JEP 102 Process Updates will provide an easier way to get the > current process PID but we don't have that yet :-) > > best regards, > > -- daniel > > On 11/02/15 17:42, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8072856 >> webrev: http://cr.openjdk.java.net/~ykantser/8072856/webrev.00/ >> >> Thanks, >> Katja > From chris.plummer at oracle.com Wed Feb 11 17:38:18 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 11 Feb 2015 09:38:18 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54DB2B1D.6000102@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> <54DAC8E1.3000608@oracle.com> <54DB2B1D.6000102@oracle.com> Message-ID: <54DB938A.7000002@oracle.com> On 2/11/15 2:12 AM, Mikael Auno wrote: > On 2015-02-11 04:13, Chris Plummer wrote: >>> In general I think this looks very good. Simple and well-commented >>> code to follow. I am missing a test, though. Please look at the >>> hotspot/test/serviceability/dcmd set of tests. >> Added. > Your test is based on DcmdUtil.java which was removed last week (see > [0]). If you pull new changes from hs-rt/hotspot, you'll see plenty of > tests using the new DCMD utility classes in testlibrary. Also, the new > tests are divided in different subdirectories depending on the commands, > so as your test exercises VM.class_hierarchy it should go in > .../dcmd/vm/ as opposed to just .../dcmd/. > > Thanks, > Mikael > > [0] > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/tip/test/serviceability/dcmd Ok. I'll pull the latest hs-rt and update the test. Thanks for pointing that out. Chris From dean.long at oracle.com Wed Feb 11 21:00:34 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 11 Feb 2015 13:00:34 -0800 Subject: Request for approval: Backport of 8069030 In-Reply-To: <54D923C9.3090107@oracle.com> References: <54D923C9.3090107@oracle.com> Message-ID: <54DBC2F2.7070105@oracle.com> Ping. Is there a different alias I should sent this to? dl On 2/9/2015 1:16 PM, Dean Long wrote: > I would like to backport 8069030 to 8u60: > > https://bugs.openjdk.java.net/browse/JDK-8069030 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5960a65b0f54 > > The patch applied cleanly. > > dl From karen.kinnear at oracle.com Wed Feb 11 22:11:47 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 11 Feb 2015 17:11:47 -0500 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54D53B87.5090304@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> <54D520D3.3070804@oracle.com> <54D53B87.5090304@oracle.com> Message-ID: <12AA4EDA-B054-4F12-A094-7D1C1C813BBF@oracle.com> Chris, Just saw this. I was thinking the instance in the heap since you might have multiple instances of a single subclass. Good point that it might change and so the correlation would be gone. thanks, Karen On Feb 6, 2015, at 5:09 PM, Chris Plummer wrote: > Hi Karen, > > Can you clarify what you mean by "address of the j.l.ClassLoader class". Is that the Klass* for the ClassLoader subclass, or the actual address of the ClassLoader instance in the heap, which can change. > > Chris > > On 2/6/15 1:21 PM, Karen Kinnear wrote: >> Chris, >> >> So I was curious - I was thinking you would printing the hex address of the j.l.ClassLoader class rather than the cld so that if folks were to look >> at a heap dump later it might be meaningful to them. Is it unlikely that they would ever want to correlate those? >> >> >> On Feb 6, 2015, at 3:15 PM, Chris Plummer wrote: >> >>> I was also thinking it might be a good idea to indicate what the hex value is, although still have figured out the best way of doing this. Maybe just a simple comment before the output. Keep in mind that eventually other DCMDS will also include the cld to help uniquiely identify classes across dcmd output. Also keep in mind your earlier suggestion: >>> >>> java.lang.Object/0x12345600 >>> |--java.io.Serializable/0x12345601 >>> |--java.util.RandomAccess/0x12345602 >>> |--java.lang.Iterable/0x12345603 >>> | |--java.util.Collection/0x12345604 >>> | | |--java.util.List/0x12345605 >>> |--java.util.AbstractCollection/0x12345606 >>> | | implements java.util.Collection/0x12345604 >>> | | implements java.lang.Iterable/0x12345603 >>> | |--java.util.AbstractList/0x12345607 >>> | | implements java.util.List/0x12345605 >>> | | |--java.util.Arrays$ArrayList/0x12345608 >>> | | | implements java.io.Serializable/0x12345601 >>> | | | implements java.util.RandomAccess/0x12345602 >>> >>> With additions to GC.class_stats: >>> >>> Index Super ClassLoader ClassName >>> 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 >>> 2 1 0x00000007c0034c48 java.util.List/0x12345605 >>> 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 >>> >>> And GC.class_histogram: >>> >>> num #instances #bytes class name >>> ---------------------------------------------- >>> 1: 945 117736 java.lang.Object/0x12345600 >>> 2: 442 50352 java.util.List/0x12345605 >>> 3: 499 25288 java.util.AbstractList/0x12345607 >>> >>> I think in your case you assumed we would create a unique identifier for each class, but then we settled on just classname + ClassLoader identifier of some sort, and the CLD* works for that. So replace your hex class ID in the above with the hex CLD*. >>> >>> Also something Karen had said is just now starting to sink in and make sense to me: >>> >>> |-sun.misc.Launcher$AppClassLoader/null (0xyyy) >>> |-myapp/0xyyy >>> >>> I think the idea here is that when printing a ClassLoader subclass, you include two CLDs. The first is for the ClassLoader that loaded the class, and the second is the CLD for the ClassLoader subclass itself. Thus the above indicates that myapp was loaded by 0xyyy, which is the sun.misc.Launcher$AppClassLoader, which was loaded by the null ClassLoader. >> I apologize - I don't remember what I said. But I am not sure we need that level of complexity. I think I was asking that one of the dcmds that gives >> information could print information like 0xabc "a sun.misc.Launcher$AppClassLoader" or "a WLS.blah.GenericClassLoader" if we don't want to include >> that everywhere. Mostly people want to know the name of the class loader. Since they don't yet have names, they want to know the type of the >> classloader. So that string "a MyClassLoader" would be more meaningful than the 0xabc - except that if they >> have 5 of those they need the uniqueness. So personally I think I was proposing the >> java.base, 0xA/"a MyClassLoader", iface). >> >> But I would defer to Staffan if he suggests something else. >> >> thanks for your patience, >> Karen >>> >>> With regard to the '/' format, keep in mind that we also need an indicator of whether or not it's an interface, and there's also a request to include the module name when that becomes available. At one point you requested the following, which is what I was aiming for: >>> >>> java.lang.Object >>> |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) >>> |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) >>> >>> So maybe I can do: >>> >>> java.lang.Object >>> |--java.io.Serializable/0x00000007c00375f8 (java.base, intf) >>> |--java.util.RandomAccess/0x00000007c00375f8 (java.base, intf) >>> ... >>> |-sun.misc.Launcher$AppClassLoader/0x00000007c00375f8 (java.base, CLD=0x000000087654320) >>> |-myapp/0x000000087654320 >>> >>> So now the classname and its classloader id (which is the CLD*) are grouped together to make it easy to strip out or to search for in more than one dcmd output. I think this is probably what you were striving when you proposed using '/', and other DCMDs can eventually be changed to do the same. Also, once you know the CLD of the ClassLoader, you can find out the name of the ClassLoader class by looking for CLD= >>> >>> I can go with "null" for the null ClassLoader if you want. I used it's ClassLoaderData* to be consistent with the other ClassLoaders. Just let me know which you prefer. >>> >>> thanks, >>> >>> Chris >>> >>> On 2/6/15 12:52 AM, Staffan Larsen wrote: >>>> I think this looks good! Perhaps we should give a hint as to what the hex value is? I don?t know if it is best to print this as part of a ?header? printed before the rest of the output or if we should include it as part of each line ?(classloaderdata*=0x080609c8)?. >>>> >>>> /Staffan >>>> >>>>> On 6 feb 2015, at 05:49, Chris Plummer wrote: >>>>> >>>>> [Hmm. My previous email somehow included the attachment with the dcmd output, but not the body of the message, so here it is again.] >>>>> >>>>> Hey Folks, >>>>> >>>>> Sorry about the delay in getting the next webrev for this out. I was sidetracked by a few other things, including being out sick of almost a week, and there were also quite a few changes to make. >>>>> >>>>> I'm ready for review with an updated webrev, but thought first I'd have you look at and comment on the output. Please see the attached file. It now supports: >>>>> >>>>> printing the hierarchy for a single class >>>>> optionally including all subclasses of the specified class (-s) >>>>> for each class, also list all of its interfaces (-i) >>>>> >>>>> The hex value in the output is the address of the ClassLoaderData for the ClassLoader of the class. I did not include the address of the Klass, but could if you think it would be useful. Changing the format of what comes after the classname is easy. Just let me know what you think is best. >>>>> >>>>> I have not updated any other dcmds to be consistent with how classes are uniquely identified. A separate bug should be filed for that. Actually I thought one was, but I looked through this thread's history and could not find mention of it. I also have not implemented the reverse hierarchy dcmd. JDK-8068830 has already been filed for that, but there are no plans to work on it in the near term. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karen.kinnear at oracle.com Wed Feb 11 22:14:27 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 11 Feb 2015 17:14:27 -0500 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> <54DAC8E1.3000608@oracle.com> Message-ID: <6EB96F78-67A8-43AA-AC3E-F1651209914D@oracle.com> So I am in agreement on the CLD* - sorry for the earlier suggestion. thanks, Karen On Feb 11, 2015, at 3:04 AM, Staffan Larsen wrote: > This version looks good to me! > > Small comments inline. > >> On 11 feb 2015, at 04:13, Chris Plummer wrote: >> >> Hi Staffan, >> >> Thanks for your feedback. A new incremental webrev can be found at: >> >> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.01-02/ >> >> Most changes are discussed inline below. Here are a couple of additional changes: >> >> - Changed "transitive interface" to "inherited interface" in the output. >> - Went back to using the CLD* instead of the Klass*, except still use "null" for the bootstrap ClassLoader. > > Good. > >> >> On 2/10/15 4:19 AM, Staffan Larsen wrote: >>> Chris, >>> >>> In general I think this looks very good. Simple and well-commented code to follow. I am missing a test, though. Please look at the hotspot/test/serviceability/dcmd set of tests. >> Added. > > Thanks! > >>> >>> >>> A couple of smaller comments: >>> >>> >>> Are Unsafe.defineAnonymousClass classes included? Should they be? >> I didn't really understand what you were talking about at first, but then when I started looking at ClassLoaderStatsTest.java, I saw the following: >> >> class TestClass { >> static { >> // force creation of anonymous class (for the lambdaform) >> Runnable r = () -> System.out.println("Hello"); >> r.run(); >> } >> } >> >> I added something similar to my test case and found a whole bunch of lines like the following are suddenly added to the output: >> >> |--java.lang.invoke.LambdaForm$MH/11440528/null >> >> And there is one that seems specifically for the test case: >> >> |--DcmdTestClass$$Lambda$1/4081552/0xa529fbb0 >> >> So I think they answer is yes they are added. As for whether or not they should be, I really don't know. That's probably up to you. GC.class_stats does include them however. > > I like to include them. > >> >> BTW, I do not include array classes. They are intentionally stripped out since they don't really have relevance in a Class hierarchy analysis. I can easily add them back in if you want. > > I?m fine with skipping array classes. > >>> I think ClassHierarchyDCmd should include this code as well to restrict remote access: >>> static const JavaPermission permission() { >>> JavaPermission p = {"java.lang.management.ManagementPermission", >>> "monitor", NULL}; >>> return p; >>> } >> Ok. I was a bit unclear as to when this was really needed. >>> diagnosticCommand.hpp:278: Missing ???if??? in the comment >> Ok. >>> vm_operations.hpp: Spelling error in ???VM_PrintClassHierachry??? and ???PrintClassHierachry??? >> Ok. >>> vm_operations.hpp:461: Should the complete class be surrounded by "#if INCLUDE_SERVICES??? ? >> Yes, but I can't do anything about the reference in the VM_OPS_DO macro, at least not in a straight forward manner. I think that part is benign, but will find out when I do a minimal VM build. >>> heapInspection.hpp:272: The constructor and destructor does not seem to be used. Because of that you should also change it to a AllStatic class. >> Yeah, old code copied from HeapInspection class. I made it AllStatic and removed the constructor and destructor. However, my lack of C++ experience is showing here, and I haven't been happy about the existence of this KlassHierarchy class. It's static with just one public API. It's purpose in life is just to allow a VM operation to call that public method, but it just as easily could have been a regular C function call. Likewise the two private static methods in KlassHierarchy could have been C functions. There is no encapsulation or subclassing going on here. If you have recommendations for further improvement I'm open to suggestions. Otherwise I'll leave it with just the changes mentioned. > > I come from a C background as well, so I don?t have much to add here. I think this looks reasonable. > >>> heapInspection.cpp:339: Shouldn???t this be labeled as an ???error???? >> That would probably be better. I had copied it from line 742. Should I make that one an ERROR also to be consistent? > > Yes, please. > > Thanks, > /Staffan > >> >> thanks, >> >> Chris >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> >>>> On 10 feb 2015, at 03:00, Chris Plummer wrote: >>>> >>>> [Once again the attachment went out but the main body was stripped. Not too sure what's going on, but here it is again. Sorry if you are getting this twice.] >>>> >>>> I've attached updated output: >>>> >>>> ??? I now use the Klass* of the ClassLoader instead of the CLD*, and this is documented in the help output. >>>> ??? The Klass* of the ClassLoader now immediately follows the class name, and is also included when printing interface names. >>>> >>>> The webrevs can be found at: >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.01/ >>>> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00-01/ >>>> >>>> The first is the full webrev. The 2nd is what's changed since the last webrev that was reviewed. Changes since then include: >>>> >>>> ??? Support for printing the hierarchy of just one class. >>>> ??? -s option for optionally including subclasses when printing one class. >>>> ??? -i option for optionally including interfaces implemented by a class. >>>> ??? Output formatting changes. >>>> ??? Fixed some comment typos as requested. >>>> ??? I moved a couple of KlassInfoEntry methods out of the .hpp file and into the .cpp file as requested. >>>> ??? No longer keep track of the stack of superclasses when processing all the classes as requested. This also means the super_index field I added is no longer needed. >>>> ??? Moved some code within an already existing " #if INCLUDE_SERVICES" block as requested. >>>> >>>> thanks, >>>> >>>> Chris >>>> >> >> > From chris.plummer at oracle.com Wed Feb 11 22:16:24 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 11 Feb 2015 14:16:24 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <12AA4EDA-B054-4F12-A094-7D1C1C813BBF@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D447C8.4010107@oracle.com> <54D520D3.3070804@oracle.com> <54D53B87.5090304@oracle.com> <12AA4EDA-B054-4F12-A094-7D1C1C813BBF@oracle.com> Message-ID: <54DBD4B8.3050305@oracle.com> An HTML attachment was scrubbed... URL: From jeremymanson at google.com Wed Feb 11 22:27:16 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 11 Feb 2015 14:27:16 -0800 Subject: gdb and OpenJDK Message-ID: Hey folks, I think I've mentioned to some of the people on this list that we (and by we, I mean Sasha Smundak) have been working on interoperability between gdb and Java. Basically, what we have now allows us to get a backtrace in gdb that includes Java frames with parameter values (no local variables yet). Needless to say, this has been terribly, terribly helpful in our JVM and JNI debugging. Support for this feature is basically two parts: First, gdb needed to be extended to support the ability to plug in a frame unwinder. The process of submitting this to gdb (which has been ongoing for quite a while) is finally starting to make reasonable progress. Next, we need a plugin for OpenJDK. We have a plugin written that calls out to the serviceability agent. (It's written in Python, per gdb's requirements). Pending the gdb support being finalized, we'd love to contribute the plugin to OpenJDK. What should we do make that happen? Write a JEP and submit it to this list? Technically, neither of us are committers (which you need to be to submit a JEP), but I imagine we can work around that. Here's the gdb patch, for anyone interested: https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html Thanks! Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.walls at oracle.com Wed Feb 11 22:38:28 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 11 Feb 2015 22:38:28 +0000 Subject: RFR(M): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting In-Reply-To: <54DB31BC.9060105@oracle.com> References: <54D0C692.1090706@oracle.com> <54D10ABF.2050704@oracle.com> <54D210CF.206@oracle.com> <54D9F99D.2090603@oracle.com> <54DA1358.3090301@oracle.com> <848B5DCB-16A4-463C-BA83-C6DCAAE7DC6C@oracle.com> <54DA63A9.60207@oracle.com> <54DA773C.80805@oracle.com> <54DA7F84.7050106@oracle.com> <54DB090F.7050601@oracle.com> <6AF9CDB8-74D2-4FA0-B637-BE6D740189D2@oracle.com> <54DB31BC.9060105@oracle.com> Message-ID: <54DBD9E4.9020204@oracle.com> Hi Dmitry - like it, and particularly like getting shouldSAAttach() in both jdk and hotspot. Yes you're very efficient in just reading that one byte from those one-byte files! 8-) Sorry one more thing... JMapHeapConfigTest.java throws an exception when it doesn't think it will have permission to attach - other tests I think that know they aren't going to work, just print a message and return from main, they don't count this as a failure. I'll leave that for you to decide!... Thanks Kevin On 11/02/2015 10:41, Dmitry Samersoff wrote: > Hi Everybody, > > Please review the changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ > > > 1. Removed lock age test, because LingeredApp can run more than one hour > of machine time. > > 2. Added code to check for common environment pitfalls and produce > meaningful diagnostic > > 3. Testlibrary method canPtraceAttachLinux refactored, fixed yama > ptrace_scope check. > > 4. Sync Platfrom.java in hotspot and jdk testlibraries > > -Dmitry > From david.holmes at oracle.com Wed Feb 11 23:33:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Feb 2015 09:33:11 +1000 Subject: Request for approval: Backport of 8069030 In-Reply-To: <54DBC2F2.7070105@oracle.com> References: <54D923C9.3090107@oracle.com> <54DBC2F2.7070105@oracle.com> Message-ID: <54DBE6B7.4090304@oracle.com> I have no issue with this backport. David On 12/02/2015 7:00 AM, Dean Long wrote: > Ping. Is there a different alias I should sent this to? > > dl > > On 2/9/2015 1:16 PM, Dean Long wrote: >> I would like to backport 8069030 to 8u60: >> >> https://bugs.openjdk.java.net/browse/JDK-8069030 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5960a65b0f54 >> >> The patch applied cleanly. >> >> dl > From dean.long at oracle.com Thu Feb 12 00:13:51 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 11 Feb 2015 16:13:51 -0800 Subject: Request for approval: Backport of 8069030 In-Reply-To: <54DBE6B7.4090304@oracle.com> References: <54D923C9.3090107@oracle.com> <54DBC2F2.7070105@oracle.com> <54DBE6B7.4090304@oracle.com> Message-ID: <54DBF03F.6080708@oracle.com> Thanks David. dl On 2/11/2015 3:33 PM, David Holmes wrote: > I have no issue with this backport. > > David > > On 12/02/2015 7:00 AM, Dean Long wrote: >> Ping. Is there a different alias I should sent this to? >> >> dl >> >> On 2/9/2015 1:16 PM, Dean Long wrote: >>> I would like to backport 8069030 to 8u60: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8069030 >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5960a65b0f54 >>> >>> The patch applied cleanly. >>> >>> dl >> From mandy.chung at oracle.com Thu Feb 12 01:04:31 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 Feb 2015 17:04:31 -0800 Subject: [ping] Re: RFR 8069286: Unexpected count of notification in LowMemoryTest In-Reply-To: <54DB375B.4080702@oracle.com> References: <54CF9EC9.7000909@oracle.com> <54D9CDD1.1040709@oracle.com> <54DA3B61.9020407@oracle.com> <54DB375B.4080702@oracle.com> Message-ID: <54DBFC1E.2010303@oracle.com> On 2/11/2015 3:04 AM, Jaroslav Bachorik wrote: > On 10.2.2015 18:09, Mandy Chung wrote: >> >> 142 private boolean checkValue(long value, int target) { >> 143 if (isRelaxed) { >> 144 return value == target; >> 145 } else { >> 146 return value >= target; >> 147 } >> 148 } >> >> should line 143 be !isRelaxed? > > Oh, right - http://cr.openjdk.java.net/~jbachorik/8069286/webrev.01 Looks okay to me. Mandy From chris.plummer at oracle.com Thu Feb 12 08:28:20 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 12 Feb 2015 00:28:20 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54DB938A.7000002@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> <54DAC8E1.3000608@oracle.com> <54DB2B1D.6000102@oracle.com> <54DB938A.7000002@oracle.com> Message-ID: <54DC6424.9050109@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Feb 12 08:31:31 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 12 Feb 2015 00:31:31 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54DC6424.9050109@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> <54DAC8E1.3000608@oracle.com> <54DB2B1D.6000102@oracle.com> <54DB938A.7000002@oracle.com> <54DC6424.9050109@oracle.com> Message-ID: <54DC64E3.2010404@oracle.com> An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Feb 12 09:03:44 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Feb 2015 10:03:44 +0100 Subject: RFR(M): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting In-Reply-To: <54DBD9E4.9020204@oracle.com> References: <54D0C692.1090706@oracle.com> <54D10ABF.2050704@oracle.com> <54D210CF.206@oracle.com> <54D9F99D.2090603@oracle.com> <54DA1358.3090301@oracle.com> <848B5DCB-16A4-463C-BA83-C6DCAAE7DC6C@oracle.com> <54DA63A9.60207@oracle.com> <54DA773C.80805@oracle.com> <54DA7F84.7050106@oracle.com> <54DB090F.7050601@oracle.com> <6AF9CDB8-74D2-4FA0-B637-BE6D740189D2@oracle.com> <54DB31BC.9060105@oracle.com> <54DBD9E4.9020204@oracle.com> Message-ID: This looks good, except that I agree with Kevin that we should silently succeed if SA isn?t allowed to attach. Otherwise we will get lots of failures in the testing. Sorry I missed this in the last round of internal review. /Staffan > On 11 feb 2015, at 23:38, Kevin Walls wrote: > > > Hi Dmitry - like it, and particularly like getting shouldSAAttach() in both jdk and hotspot. Yes you're very efficient in just reading that one byte from those one-byte files! 8-) > > Sorry one more thing... JMapHeapConfigTest.java throws an exception when it doesn't think it will have permission to attach - other tests I think that know they aren't going to work, just print a message and return from main, they don't count this as a failure. I'll leave that for you to decide!... > > Thanks > Kevin > > > On 11/02/2015 10:41, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review the changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ >> >> >> 1. Removed lock age test, because LingeredApp can run more than one hour >> of machine time. >> >> 2. Added code to check for common environment pitfalls and produce >> meaningful diagnostic >> >> 3. Testlibrary method canPtraceAttachLinux refactored, fixed yama >> ptrace_scope check. >> >> 4. Sync Platfrom.java in hotspot and jdk testlibraries >> >> -Dmitry >> > From aph at redhat.com Thu Feb 12 09:15:20 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Feb 2015 09:15:20 +0000 Subject: gdb and OpenJDK In-Reply-To: References: Message-ID: <54DC6F28.8030505@redhat.com> On 11/02/15 22:27, Jeremy Manson wrote: > I think I've mentioned to some of the people on this list that we (and by > we, I mean Sasha Smundak) have been working on interoperability between gdb > and Java. Basically, what we have now allows us to get a backtrace in gdb > that includes Java frames with parameter values (no local variables yet). > > Needless to say, this has been terribly, terribly helpful in our JVM and > JNI debugging. Thanks, that's a great start. > Next, we need a plugin for OpenJDK. We have a plugin written that calls > out to the serviceability agent. (It's written in Python, per gdb's > requirements). That's an interesting approach. Andrew. From dmitry.samersoff at oracle.com Thu Feb 12 09:17:14 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 Feb 2015 12:17:14 +0300 Subject: RFR(M): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting In-Reply-To: References: <54D0C692.1090706@oracle.com> <54D10ABF.2050704@oracle.com> <54D210CF.206@oracle.com> <54D9F99D.2090603@oracle.com> <54DA1358.3090301@oracle.com> <848B5DCB-16A4-463C-BA83-C6DCAAE7DC6C@oracle.com> <54DA63A9.60207@oracle.com> <54DA773C.80805@oracle.com> <54DA7F84.7050106@oracle.com> <54DB090F.7050601@oracle.com> <6AF9CDB8-74D2-4FA0-B637-BE6D740189D2@oracle.com> <54DB31BC.9060105@oracle.com> <54DBD9E4.9020204@oracle.com> Message-ID: <54DC6F9A.1050803@oracle.com> Staffan, Fixed in place (press shift-reload) http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ -Dmitry On 2015-02-12 12:03, Staffan Larsen wrote: > This looks good, except that I agree with Kevin that we should > silently succeed if SA isn?t allowed to attach. Otherwise we will get > lots of failures in the testing. Sorry I missed this in the last > round of internal review. > > /Staffan > >> On 11 feb 2015, at 23:38, Kevin Walls >> wrote: >> >> >> Hi Dmitry - like it, and particularly like getting shouldSAAttach() >> in both jdk and hotspot. Yes you're very efficient in just reading >> that one byte from those one-byte files! 8-) >> >> Sorry one more thing... JMapHeapConfigTest.java throws an >> exception when it doesn't think it will have permission to attach - >> other tests I think that know they aren't going to work, just print >> a message and return from main, they don't count this as a failure. >> I'll leave that for you to decide!... >> >> Thanks Kevin >> >> >> On 11/02/2015 10:41, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review the changes: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ >>> >>> >>> 1. Removed lock age test, because LingeredApp can run more than >>> one hour of machine time. >>> >>> 2. Added code to check for common environment pitfalls and >>> produce meaningful diagnostic >>> >>> 3. Testlibrary method canPtraceAttachLinux refactored, fixed >>> yama ptrace_scope check. >>> >>> 4. Sync Platfrom.java in hotspot and jdk testlibraries >>> >>> -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 Thu Feb 12 09:19:11 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Feb 2015 10:19:11 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54DC64E3.2010404@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> <54DAC8E1.3000608@oracle.com> <54DB2B1D.6000102@oracle.com> <54DB938A.7000002@oracle.com> <54DC6424.9050109@oracle.com> <54DC64E3.2010404@oracle.com> Message-ID: <776B0873-7B7B-4537-B620-B32056723777@oracle.com> Looks good! Thanks for providing incremental webrevs - very helpful! Thanks, /Staffan > On 12 feb 2015, at 09:31, Chris Plummer wrote: > > I suppose it would be nice if I included links to the webrevs: > > http://cr.openjdk.java.net/~cjplummer/8054888/webrev.02-03/ > http://cr.openjdk.java.net/~cjplummer/8054888/webrev.03/ > > First one is just the latest changes described in the previous email. 2nd one includes all changes. > > thanks, > > Chris > > On 2/12/15 12:28 AM, Chris Plummer wrote: >> Ok, hopefully the last webrev. :) >> >> -JPRT found a compiler error on Solaris. classfile/systemDictionary.hpp needed to be included due to the reference to SystemDictionary::Object_klass(). I assume this turned up on Solaris because it doesn't use precompiled headers. >> >> -I noticed I had inadvertently removed a ResourceMark in KlassInfoHisto::print_class_stats(). I think maybe I had done a cut-n-paste rather than copy-n-paste. This was in webrev.01 but was pretty inconspicuous in the webrev so went noticed. >> >> -I changed another WARNING to ERROR as Staffan requested. >> >> -I updated to the latest JDK9 sources and made the needed changes to the DCMD test as Mikael requested. >> >> thanks, >> >> Chris >> >> On 2/11/15 9:38 AM, Chris Plummer wrote: >>> On 2/11/15 2:12 AM, Mikael Auno wrote: >>>> On 2015-02-11 04:13, Chris Plummer wrote: >>>>>> In general I think this looks very good. Simple and well-commented >>>>>> code to follow. I am missing a test, though. Please look at the >>>>>> hotspot/test/serviceability/dcmd set of tests. >>>>> Added. >>>> Your test is based on DcmdUtil.java which was removed last week (see >>>> [0]). If you pull new changes from hs-rt/hotspot, you'll see plenty of >>>> tests using the new DCMD utility classes in testlibrary. Also, the new >>>> tests are divided in different subdirectories depending on the commands, >>>> so as your test exercises VM.class_hierarchy it should go in >>>> .../dcmd/vm/ as opposed to just .../dcmd/. >>>> >>>> Thanks, >>>> Mikael >>>> >>>> [0] >>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/tip/test/serviceability/dcmd >>> Ok. I'll pull the latest hs-rt and update the test. Thanks for pointing that out. >>> >>> Chris >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Feb 12 09:20:17 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Feb 2015 10:20:17 +0100 Subject: RFR(M): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting In-Reply-To: <54DC6F9A.1050803@oracle.com> References: <54D0C692.1090706@oracle.com> <54D10ABF.2050704@oracle.com> <54D210CF.206@oracle.com> <54D9F99D.2090603@oracle.com> <54DA1358.3090301@oracle.com> <848B5DCB-16A4-463C-BA83-C6DCAAE7DC6C@oracle.com> <54DA63A9.60207@oracle.com> <54DA773C.80805@oracle.com> <54DA7F84.7050106@oracle.com> <54DB090F.7050601@oracle.com> <6AF9CDB8-74D2-4FA0-B637-BE6D740189D2@oracle.com> <54DB31BC.9060105@oracle.com> <54DBD9E4.9020204@oracle.com> <54DC6F9A.1050803@oracle.com> Message-ID: Looks good. Thanks, /Staffan > On 12 feb 2015, at 10:17, Dmitry Samersoff wrote: > > Staffan, > > Fixed in place (press shift-reload) > > http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ > > -Dmitry > > On 2015-02-12 12:03, Staffan Larsen wrote: >> This looks good, except that I agree with Kevin that we should >> silently succeed if SA isn?t allowed to attach. Otherwise we will get >> lots of failures in the testing. Sorry I missed this in the last >> round of internal review. >> >> /Staffan >> >>> On 11 feb 2015, at 23:38, Kevin Walls >>> wrote: >>> >>> >>> Hi Dmitry - like it, and particularly like getting shouldSAAttach() >>> in both jdk and hotspot. Yes you're very efficient in just reading >>> that one byte from those one-byte files! 8-) >>> >>> Sorry one more thing... JMapHeapConfigTest.java throws an >>> exception when it doesn't think it will have permission to attach - >>> other tests I think that know they aren't going to work, just print >>> a message and return from main, they don't count this as a failure. >>> I'll leave that for you to decide!... >>> >>> Thanks Kevin >>> >>> >>> On 11/02/2015 10:41, Dmitry Samersoff wrote: >>>> Hi Everybody, >>>> >>>> Please review the changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ >>>> >>>> >>>> 1. Removed lock age test, because LingeredApp can run more than >>>> one hour of machine time. >>>> >>>> 2. Added code to check for common environment pitfalls and >>>> produce meaningful diagnostic >>>> >>>> 3. Testlibrary method canPtraceAttachLinux refactored, fixed >>>> yama ptrace_scope check. >>>> >>>> 4. Sync Platfrom.java in hotspot and jdk testlibraries >>>> >>>> -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 kevin.walls at oracle.com Thu Feb 12 09:34:04 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 12 Feb 2015 09:34:04 +0000 Subject: RFR(M): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting In-Reply-To: References: <54D0C692.1090706@oracle.com> <54D10ABF.2050704@oracle.com> <54D210CF.206@oracle.com> <54D9F99D.2090603@oracle.com> <54DA1358.3090301@oracle.com> <848B5DCB-16A4-463C-BA83-C6DCAAE7DC6C@oracle.com> <54DA63A9.60207@oracle.com> <54DA773C.80805@oracle.com> <54DA7F84.7050106@oracle.com> <54DB090F.7050601@oracle.com> <6AF9CDB8-74D2-4FA0-B637-BE6D740189D2@oracle.com> <54DB31BC.9060105@oracle.com> <54DBD9E4.9020204@oracle.com> <54DC6F9A.1050803@oracle.com> Message-ID: <54DC738C.3040001@oracle.com> Thanks Dmitry, great! On 12/02/2015 09:20, Staffan Larsen wrote: > Looks good. > > Thanks, > /Staffan > >> On 12 feb 2015, at 10:17, Dmitry Samersoff wrote: >> >> Staffan, >> >> Fixed in place (press shift-reload) >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ >> >> -Dmitry >> >> On 2015-02-12 12:03, Staffan Larsen wrote: >>> This looks good, except that I agree with Kevin that we should >>> silently succeed if SA isn?t allowed to attach. Otherwise we will get >>> lots of failures in the testing. Sorry I missed this in the last >>> round of internal review. >>> >>> /Staffan >>> >>>> On 11 feb 2015, at 23:38, Kevin Walls >>>> wrote: >>>> >>>> >>>> Hi Dmitry - like it, and particularly like getting shouldSAAttach() >>>> in both jdk and hotspot. Yes you're very efficient in just reading >>>> that one byte from those one-byte files! 8-) >>>> >>>> Sorry one more thing... JMapHeapConfigTest.java throws an >>>> exception when it doesn't think it will have permission to attach - >>>> other tests I think that know they aren't going to work, just print >>>> a message and return from main, they don't count this as a failure. >>>> I'll leave that for you to decide!... >>>> >>>> Thanks Kevin >>>> >>>> >>>> On 11/02/2015 10:41, Dmitry Samersoff wrote: >>>>> Hi Everybody, >>>>> >>>>> Please review the changes: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.04/ >>>>> >>>>> >>>>> 1. Removed lock age test, because LingeredApp can run more than >>>>> one hour of machine time. >>>>> >>>>> 2. Added code to check for common environment pitfalls and >>>>> produce meaningful diagnostic >>>>> >>>>> 3. Testlibrary method canPtraceAttachLinux refactored, fixed >>>>> yama ptrace_scope check. >>>>> >>>>> 4. Sync Platfrom.java in hotspot and jdk testlibraries >>>>> >>>>> -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 volker.simonis at gmail.com Thu Feb 12 10:14:44 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 Feb 2015 11:14:44 +0100 Subject: gdb and OpenJDK In-Reply-To: References: Message-ID: Hi Jeremy, nice to see that somebody is working on this topic. Can you please detail a little bit on how this would work? As far as I understand you extend gdb to support "frame undwinder" plugins written in Python. One of these plugins, which you want to contribute to the OpenJDK, can be used to unwind native Java/HotSpot stack frames by calling out to the serviceability agent. Can you please explain how this could work? If you debug a Java process with gdb, gdb attaches to that process using "ptrace". The SA agent uses "ptrace" as well but as far as I know, only once process can attach to another process at the same time. So how is this callback from gdb to the SA agent supposed to work? Regards, Volker On Wed, Feb 11, 2015 at 11:27 PM, Jeremy Manson wrote: > Hey folks, > > I think I've mentioned to some of the people on this list that we (and by > we, I mean Sasha Smundak) have been working on interoperability between gdb > and Java. Basically, what we have now allows us to get a backtrace in gdb > that includes Java frames with parameter values (no local variables yet). > > Needless to say, this has been terribly, terribly helpful in our JVM and JNI > debugging. > > Support for this feature is basically two parts: > > First, gdb needed to be extended to support the ability to plug in a frame > unwinder. The process of submitting this to gdb (which has been ongoing for > quite a while) is finally starting to make reasonable progress. > > Next, we need a plugin for OpenJDK. We have a plugin written that calls out > to the serviceability agent. (It's written in Python, per gdb's > requirements). > > Pending the gdb support being finalized, we'd love to contribute the plugin > to OpenJDK. What should we do make that happen? Write a JEP and submit > it to this list? Technically, neither of us are committers (which you need > to be to submit a JEP), but I imagine we can work around that. > > Here's the gdb patch, for anyone interested: > > https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html > > Thanks! > > Jeremy From yekaterina.kantserova at oracle.com Thu Feb 12 10:51:52 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 12 Feb 2015 02:51:52 -0800 (PST) Subject: 8072856: Eliminate ProcessTools.getProcessId dependency on sun.management.VMManagement Message-ID: <228af8f2-c391-4062-917f-43511a84c1c2@default> Thanks everybody for the reviews! The fix is pushed. // Katja ----- Original Message ----- From: mandy.chung at oracle.com To: daniel.fuchs at oracle.com, yekaterina.kantserova at oracle.com, serviceability-dev at openjdk.java.net, Alan.Bateman at oracle.com Sent: Wednesday, February 11, 2015 6:06:18 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: 8072856: Eliminate ProcessTools.getProcessId dependency on sun.management.VMManagement +1 This is temporary. When the Process API is available, we can convert to use the new public API. Mandy On 2/11/2015 8:57 AM, Daniel Fuchs wrote: > Looks good to me too. > > JEP 102 Process Updates will provide an easier way to get the > current process PID but we don't have that yet :-) > > best regards, > > -- daniel > > On 11/02/15 17:42, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8072856 >> webrev: http://cr.openjdk.java.net/~ykantser/8072856/webrev.00/ >> >> Thanks, >> Katja > From sean.mullan at oracle.com Thu Feb 12 13:43:19 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Feb 2015 08:43:19 -0500 Subject: RFR 8072932: Test fails with java.security.AccessControlException: access denied ("java.security.SecurityPermission" "getDomainCombiner") In-Reply-To: <54DB7EDB.3040506@oracle.com> References: <54DB7EDB.3040506@oracle.com> Message-ID: <54DCADF7.1010107@oracle.com> Looks fine to me. Can you add a noreg-trivial label to the bug? --Sean On 02/11/2015 11:10 AM, Jaroslav Bachorik wrote: > Please, review the following simple change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8072932 > Webrev: http://cr.openjdk.java.net/~jbachorik/8072932/webrev.00 > > This patch is about replacing the > j.s.AccessControlContext.getDomainCombiner() with the package-private > version j.s.AccessControlContext.getCombiner() to prevent the > unnecessary privilege check done by the public getDomainCombiner() method. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Thu Feb 12 14:16:39 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 12 Feb 2015 15:16:39 +0100 Subject: RFR 8072908: 8072908: com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh fails on OS X with exit code 2 Message-ID: <54DCB5C7.3020808@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/rest/api/latest/issue/JDK-8072908 Webrev: http://cr.openjdk.java.net/~jbachorik/8072908/webrev.00 The existing shell test fails for MacOS when there is no swap configured due to the pattern processing problem. This patch converts the shell test to a plain Java one and makes sure the test does not break for zero size swap on MacOS (or any other OS for that matter) Thanks, -JB- From jaroslav.bachorik at oracle.com Thu Feb 12 14:23:13 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 12 Feb 2015 15:23:13 +0100 Subject: RFR 8072908: 8072908: com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh fails on OS X with exit code 2 In-Reply-To: <54DCB5C7.3020808@oracle.com> References: <54DCB5C7.3020808@oracle.com> Message-ID: <54DCB751.50200@oracle.com> On 12.2.2015 15:16, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/rest/api/latest/issue/JDK-8072908 Should be https://bugs.openjdk.java.net/browse/JDK-8072908 > Webrev: http://cr.openjdk.java.net/~jbachorik/8072908/webrev.00 > > The existing shell test fails for MacOS when there is no swap configured > due to the pattern processing problem. > > This patch converts the shell test to a plain Java one and makes sure > the test does not break for zero size swap on MacOS (or any other OS for > that matter) > > Thanks, > > -JB- From yasuenag at gmail.com Thu Feb 12 14:35:12 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 12 Feb 2015 23:35:12 +0900 Subject: gdb and OpenJDK In-Reply-To: References: Message-ID: <54DCBA20.8030101@gmail.com> Hi Jeremy, IcedTea OpenJDK, which is shipped from Linux Distros (e.g. Fedora) contains jstack.stp . jstack.stp is SystemTap tapset - it can parse Java and native frame from thread stack. You may use its implementation on GDB. Thanks, Yasumasa IcedTea Committer On 2015/02/12 7:27, Jeremy Manson wrote: > Hey folks, > > I think I've mentioned to some of the people on this list that we (and by > we, I mean Sasha Smundak) have been working on interoperability between gdb > and Java. Basically, what we have now allows us to get a backtrace in gdb > that includes Java frames with parameter values (no local variables yet). > > Needless to say, this has been terribly, terribly helpful in our JVM and > JNI debugging. > > Support for this feature is basically two parts: > > First, gdb needed to be extended to support the ability to plug in a frame > unwinder. The process of submitting this to gdb (which has been ongoing > for quite a while) is finally starting to make reasonable progress. > > Next, we need a plugin for OpenJDK. We have a plugin written that calls > out to the serviceability agent. (It's written in Python, per gdb's > requirements). > > Pending the gdb support being finalized, we'd love to contribute the plugin > to OpenJDK. What should we do make that happen? Write a JEP and submit > it to this list? Technically, neither of us are committers (which you need > to be to submit a JEP), but I imagine we can work around that. > > Here's the gdb patch, for anyone interested: > > https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html > > Thanks! > > Jeremy > From asmundak at google.com Thu Feb 12 21:29:05 2015 From: asmundak at google.com (Alexander Smundak) Date: Thu, 12 Feb 2015 13:29:05 -0800 Subject: gdb and OpenJDK In-Reply-To: References: Message-ID: It was the previous implementation that used the serviceability agent, sorry for the confusion. The new one replicates the necessary functionality of the serviceability agent instead. All the operations on the debuggee (catching events, reading writing to the debuggee memory, etc.) are performed by the GDB. The Python code consists of two "plugins". The first does "unwinding", that is, finding out the caller's frame for a given frame. JIT frames need unwinding because JIT code uses frame pointer as a general purpose register (I am speaking of x86_64), so GDB cannot unwind it. So the unwinding plugin locates nmethod instance containing given PC, fetches the frame size from it, and is thus able to locate the previous frame. The second plugin symbolizes Java frames (GDB already has the interface for that called FrameDecorators), and it requires sizable amount of code to traverse various JVM structures to do that. The Python module is currently about 2500 lines of code. About 10% of this code is platform-dependent (I have implementations for x86_64 and PowerPC64 and working on Aarch64). Sasha On Thu, Feb 12, 2015 at 2:14 AM, Volker Simonis wrote: > Hi Jeremy, > > nice to see that somebody is working on this topic. > > Can you please detail a little bit on how this would work? > As far as I understand you extend gdb to support "frame undwinder" > plugins written in Python. > > One of these plugins, which you want to contribute to the OpenJDK, can > be used to unwind native Java/HotSpot stack frames by calling out to > the serviceability agent. Can you please explain how this could work? > If you debug a Java process with gdb, gdb attaches to that process > using "ptrace". The SA agent uses "ptrace" as well but as far as I > know, only once process can attach to another process at the same > time. So how is this callback from gdb to the SA agent supposed to > work? > > Regards, > Volker > > > On Wed, Feb 11, 2015 at 11:27 PM, Jeremy Manson wrote: >> Hey folks, >> >> I think I've mentioned to some of the people on this list that we (and by >> we, I mean Sasha Smundak) have been working on interoperability between gdb >> and Java. Basically, what we have now allows us to get a backtrace in gdb >> that includes Java frames with parameter values (no local variables yet). >> >> Needless to say, this has been terribly, terribly helpful in our JVM and JNI >> debugging. >> >> Support for this feature is basically two parts: >> >> First, gdb needed to be extended to support the ability to plug in a frame >> unwinder. The process of submitting this to gdb (which has been ongoing for >> quite a while) is finally starting to make reasonable progress. >> >> Next, we need a plugin for OpenJDK. We have a plugin written that calls out >> to the serviceability agent. (It's written in Python, per gdb's >> requirements). >> >> Pending the gdb support being finalized, we'd love to contribute the plugin >> to OpenJDK. What should we do make that happen? Write a JEP and submit >> it to this list? Technically, neither of us are committers (which you need >> to be to submit a JEP), but I imagine we can work around that. >> >> Here's the gdb patch, for anyone interested: >> >> https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html >> >> Thanks! >> >> Jeremy From mark.reinhold at oracle.com Fri Feb 13 00:46:35 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Feb 2015 16:46:35 -0800 (PST) Subject: JEP 240: Remove the JVM TI hprof Agent Message-ID: <20150213004635.5F2514DB85@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/240 - Mark From mark.reinhold at oracle.com Fri Feb 13 01:07:47 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Feb 2015 17:07:47 -0800 (PST) Subject: JEP 241: Remove the jhat Tool Message-ID: <20150213010747.DBC184DB8D@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/241 - Mark From david.holmes at oracle.com Fri Feb 13 02:36:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Feb 2015 12:36:31 +1000 Subject: RFR 8072908: 8072908: com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh fails on OS X with exit code 2 In-Reply-To: <54DCB751.50200@oracle.com> References: <54DCB5C7.3020808@oracle.com> <54DCB751.50200@oracle.com> Message-ID: <54DD632F.60400@oracle.com> Hi Jaroslav, Looks reasonable - but I can't vouch for MacOSX commands. Minor nit: 111 // total used free shared buffers cached 112 // Mem: 16533540864 13638467584 2895073280 534040576 1630248960 6236909568 The labels in #111 need to move across. Thanks, David On 13/02/2015 12:23 AM, Jaroslav Bachorik wrote: > On 12.2.2015 15:16, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/rest/api/latest/issue/JDK-8072908 > > Should be https://bugs.openjdk.java.net/browse/JDK-8072908 > >> Webrev: http://cr.openjdk.java.net/~jbachorik/8072908/webrev.00 >> >> The existing shell test fails for MacOS when there is no swap configured >> due to the pattern processing problem. >> >> This patch converts the shell test to a plain Java one and makes sure >> the test does not break for zero size swap on MacOS (or any other OS for >> that matter) >> >> Thanks, >> >> -JB- > From david.holmes at oracle.com Fri Feb 13 02:39:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Feb 2015 12:39:30 +1000 Subject: RFR 8072932: Test fails with java.security.AccessControlException: access denied ("java.security.SecurityPermission" "getDomainCombiner") In-Reply-To: <54DB7EDB.3040506@oracle.com> References: <54DB7EDB.3040506@oracle.com> Message-ID: <54DD63E2.4080002@oracle.com> On 12/02/2015 2:10 AM, Jaroslav Bachorik wrote: > Please, review the following simple change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8072932 > Webrev: http://cr.openjdk.java.net/~jbachorik/8072932/webrev.00 > > This patch is about replacing the > j.s.AccessControlContext.getDomainCombiner() with the package-private > version j.s.AccessControlContext.getCombiner() to prevent the > unnecessary privilege check done by the public getDomainCombiner() method. Just wondering: would the original call succeed if placed in a doPrivileged? David > Thanks, > > -JB- From staffan.larsen at oracle.com Fri Feb 13 07:51:14 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Feb 2015 08:51:14 +0100 Subject: Review request: Backport of JDK-8046282 to 8u In-Reply-To: <54CA8D1C.6010408@oracle.com> References: <54CA8D1C.6010408@oracle.com> Message-ID: <3C1BF91B-1BC6-4CA0-A77D-62A4972C86D6@oracle.com> Hi Poonam, Did the changes apply cleanly? What tests have you run? /Staffan > On 29 jan 2015, at 20:42, Poonam Bajaj Parhar wrote: > > Hello, > > Review request for the backport of 8046282 to 8u: > > Bug: JDK-8046282 SA update > Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ > > Thanks, > Poonam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Fri Feb 13 08:17:05 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 13 Feb 2015 00:17:05 -0800 (PST) Subject: Review request: Backport of JDK-8046282 to 8u In-Reply-To: <54CFDCC8.6050108@oracle.com> References: <54CA8D1C.6010408@oracle.com> <54CFDCC8.6050108@oracle.com> Message-ID: Hi Poonam, ? Looks good, thanks for backporting this. ? Cheers Markus ? From: Poonam Bajaj Parhar Sent: den 2 februari 2015 21:24 To: serviceability-dev at openjdk.java.net Subject: Re: Review request: Backport of JDK-8046282 to 8u ? Hello, Could I have reviews for these backported changes, please. Thanks, Poonam On 1/29/2015 11:42 AM, Poonam Bajaj Parhar wrote: Hello, Review request for the backport of 8046282 to 8u: Bug:? HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8046282"JDK-8046282 SA update Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epoonam/8046282/webrev.00/"http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ Thanks, Poonam ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Fri Feb 13 08:58:07 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 13 Feb 2015 11:58:07 +0300 Subject: Review request: Backport of JDK-8046282 to 8u In-Reply-To: <54CA8D1C.6010408@oracle.com> References: <54CA8D1C.6010408@oracle.com> Message-ID: <54DDBC9F.3060303@oracle.com> Looks good for me! -Dmitry On 2015-01-29 22:42, Poonam Bajaj Parhar wrote: > Hello, > > Review request for the backport of 8046282 to 8u: > > Bug: JDK-8046282 SA > update > Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ > > Thanks, > Poonam > -- 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 erik.helin at oracle.com Fri Feb 13 09:40:25 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 13 Feb 2015 10:40:25 +0100 Subject: gdb and OpenJDK In-Reply-To: References: Message-ID: <20150213094025.GB23518@ehelin.jrpg.bea.com> On 2015-02-12, Alexander Smundak wrote: > It was the previous implementation that used the serviceability agent, > sorry for the confusion. The new one replicates the necessary > functionality of the serviceability agent instead. All the operations > on the debuggee (catching events, reading writing to the debuggee > memory, etc.) are performed by the GDB. > The Python code consists of two "plugins". The first does "unwinding", > that is, finding out the caller's frame for a given frame. JIT frames > need unwinding because JIT code uses frame pointer as a general > purpose register (I am speaking of x86_64), so GDB cannot unwind it. > So the unwinding plugin locates nmethod instance containing given PC, > fetches the frame size from it, and is thus able to locate the > previous frame. > The second plugin symbolizes Java frames (GDB already has the > interface for that called FrameDecorators), and it requires sizable > amount of code to traverse various JVM structures to do that. > The Python module is currently about 2500 lines of code. About 10% of > this code is platform-dependent (I have implementations for x86_64 and > PowerPC64 and working on Aarch64). First of all, thanks for putting work into this, having Java stacktraces in GDB would be really helpful. Just a quick question, instead of rewriting the stack walking code in Python, would it be possible to use gdbjit [0]? Apparently, this is used by LLVM MC JIT and I also think that V8 has some basic support for it. The benefit of using something like gdbjit would be to not have the stack walking code in multiple places: - the vm - SA - Python for gdb Thanks, Erik [0]: https://sourceware.org/gdb/onlinedocs/gdb/JIT-Interface.html > Sasha > > On Thu, Feb 12, 2015 at 2:14 AM, Volker Simonis > wrote: > > Hi Jeremy, > > > > nice to see that somebody is working on this topic. > > > > Can you please detail a little bit on how this would work? > > As far as I understand you extend gdb to support "frame undwinder" > > plugins written in Python. > > > > One of these plugins, which you want to contribute to the OpenJDK, can > > be used to unwind native Java/HotSpot stack frames by calling out to > > the serviceability agent. Can you please explain how this could work? > > If you debug a Java process with gdb, gdb attaches to that process > > using "ptrace". The SA agent uses "ptrace" as well but as far as I > > know, only once process can attach to another process at the same > > time. So how is this callback from gdb to the SA agent supposed to > > work? > > > > Regards, > > Volker > > > > > > On Wed, Feb 11, 2015 at 11:27 PM, Jeremy Manson wrote: > >> Hey folks, > >> > >> I think I've mentioned to some of the people on this list that we (and by > >> we, I mean Sasha Smundak) have been working on interoperability between gdb > >> and Java. Basically, what we have now allows us to get a backtrace in gdb > >> that includes Java frames with parameter values (no local variables yet). > >> > >> Needless to say, this has been terribly, terribly helpful in our JVM and JNI > >> debugging. > >> > >> Support for this feature is basically two parts: > >> > >> First, gdb needed to be extended to support the ability to plug in a frame > >> unwinder. The process of submitting this to gdb (which has been ongoing for > >> quite a while) is finally starting to make reasonable progress. > >> > >> Next, we need a plugin for OpenJDK. We have a plugin written that calls out > >> to the serviceability agent. (It's written in Python, per gdb's > >> requirements). > >> > >> Pending the gdb support being finalized, we'd love to contribute the plugin > >> to OpenJDK. What should we do make that happen? Write a JEP and submit > >> it to this list? Technically, neither of us are committers (which you need > >> to be to submit a JEP), but I imagine we can work around that. > >> > >> Here's the gdb patch, for anyone interested: > >> > >> https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html > >> > >> Thanks! > >> > >> Jeremy From jaroslav.bachorik at oracle.com Fri Feb 13 09:40:48 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 13 Feb 2015 10:40:48 +0100 Subject: RFR 8072908: 8072908: com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh fails on OS X with exit code 2 In-Reply-To: <54DD632F.60400@oracle.com> References: <54DCB5C7.3020808@oracle.com> <54DCB751.50200@oracle.com> <54DD632F.60400@oracle.com> Message-ID: <54DDC6A0.7050601@oracle.com> On 13.2.2015 03:36, David Holmes wrote: > Hi Jaroslav, > > Looks reasonable - but I can't vouch for MacOSX commands. I am not a lucky Mac owner neither. I confirmed the format running the test on the test farm Mac machines only. > > Minor nit: > > 111 // total used free shared buffers > cached > 112 // Mem: 16533540864 13638467584 2895073280 > 534040576 1630248960 6236909568 > > The labels in #111 need to move across. Ah, will move it :) Thanks -JB- > > Thanks, > David > > On 13/02/2015 12:23 AM, Jaroslav Bachorik wrote: >> On 12.2.2015 15:16, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/rest/api/latest/issue/JDK-8072908 >> >> Should be https://bugs.openjdk.java.net/browse/JDK-8072908 >> >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8072908/webrev.00 >>> >>> The existing shell test fails for MacOS when there is no swap configured >>> due to the pattern processing problem. >>> >>> This patch converts the shell test to a plain Java one and makes sure >>> the test does not break for zero size swap on MacOS (or any other OS for >>> that matter) >>> >>> Thanks, >>> >>> -JB- >> From erik.helin at oracle.com Fri Feb 13 10:02:01 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 13 Feb 2015 11:02:01 +0100 Subject: gdb and OpenJDK In-Reply-To: <20150213094025.GB23518@ehelin.jrpg.bea.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> Message-ID: <20150213100201.GD23518@ehelin.jrpg.bea.com> On 2015-02-13, Erik Helin wrote: > On 2015-02-12, Alexander Smundak wrote: > > It was the previous implementation that used the serviceability agent, > > sorry for the confusion. The new one replicates the necessary > > functionality of the serviceability agent instead. All the operations > > on the debuggee (catching events, reading writing to the debuggee > > memory, etc.) are performed by the GDB. > > The Python code consists of two "plugins". The first does "unwinding", > > that is, finding out the caller's frame for a given frame. JIT frames > > need unwinding because JIT code uses frame pointer as a general > > purpose register (I am speaking of x86_64), so GDB cannot unwind it. > > So the unwinding plugin locates nmethod instance containing given PC, > > fetches the frame size from it, and is thus able to locate the > > previous frame. > > The second plugin symbolizes Java frames (GDB already has the > > interface for that called FrameDecorators), and it requires sizable > > amount of code to traverse various JVM structures to do that. > > The Python module is currently about 2500 lines of code. About 10% of > > this code is platform-dependent (I have implementations for x86_64 and > > PowerPC64 and working on Aarch64). > > First of all, thanks for putting work into this, having Java stacktraces in > GDB would be really helpful. > > Just a quick question, instead of rewriting the stack walking code in > Python, would it be possible to use gdbjit [0]? Apparently, this is used > by LLVM MC JIT and I also think that V8 has some basic support for it. > The benefit of using something like gdbjit would be to not have the > stack walking code in multiple places: > - the vm > - SA > - Python for gdb I just had a discussion with Staffan about this, and I just want to clarify my comment: instead of rewriting the stack walking code in multiple places, can we add some code in the VM that aids the development of tools like these? We will of course require platform/tool specific code, and probably some duplication, but how little duplication can we get away with? gdbjit seems like it can consume a custom debug info format, maybe we can design a very lightweight debug info format that then can be picked up by a variety of tools (lldb, windbg, gdb, SA, etc...)? Thanks, Erik > Thanks, > Erik > > [0]: https://sourceware.org/gdb/onlinedocs/gdb/JIT-Interface.html > > > Sasha > > > > On Thu, Feb 12, 2015 at 2:14 AM, Volker Simonis > > wrote: > > > Hi Jeremy, > > > > > > nice to see that somebody is working on this topic. > > > > > > Can you please detail a little bit on how this would work? > > > As far as I understand you extend gdb to support "frame undwinder" > > > plugins written in Python. > > > > > > One of these plugins, which you want to contribute to the OpenJDK, can > > > be used to unwind native Java/HotSpot stack frames by calling out to > > > the serviceability agent. Can you please explain how this could work? > > > If you debug a Java process with gdb, gdb attaches to that process > > > using "ptrace". The SA agent uses "ptrace" as well but as far as I > > > know, only once process can attach to another process at the same > > > time. So how is this callback from gdb to the SA agent supposed to > > > work? > > > > > > Regards, > > > Volker > > > > > > > > > On Wed, Feb 11, 2015 at 11:27 PM, Jeremy Manson wrote: > > >> Hey folks, > > >> > > >> I think I've mentioned to some of the people on this list that we (and by > > >> we, I mean Sasha Smundak) have been working on interoperability between gdb > > >> and Java. Basically, what we have now allows us to get a backtrace in gdb > > >> that includes Java frames with parameter values (no local variables yet). > > >> > > >> Needless to say, this has been terribly, terribly helpful in our JVM and JNI > > >> debugging. > > >> > > >> Support for this feature is basically two parts: > > >> > > >> First, gdb needed to be extended to support the ability to plug in a frame > > >> unwinder. The process of submitting this to gdb (which has been ongoing for > > >> quite a while) is finally starting to make reasonable progress. > > >> > > >> Next, we need a plugin for OpenJDK. We have a plugin written that calls out > > >> to the serviceability agent. (It's written in Python, per gdb's > > >> requirements). > > >> > > >> Pending the gdb support being finalized, we'd love to contribute the plugin > > >> to OpenJDK. What should we do make that happen? Write a JEP and submit > > >> it to this list? Technically, neither of us are committers (which you need > > >> to be to submit a JEP), but I imagine we can work around that. > > >> > > >> Here's the gdb patch, for anyone interested: > > >> > > >> https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html > > >> > > >> Thanks! > > >> > > >> Jeremy From mikael.gerdin at oracle.com Fri Feb 13 12:33:36 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 13 Feb 2015 13:33:36 +0100 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54DB6113.4080104@gmail.com> References: <54DB6113.4080104@gmail.com> Message-ID: <54DDEF20.6010501@oracle.com> Hi Yasumasa, On 2015-02-11 15:02, Yasumasa Suenaga wrote: > Hi all, > > I've committed JDK-8068589 to add new GCCause - Diagnostic Command. > However, it has been backouted because test is failed [1] and it is not considered > about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. > > I've created patch for this enhancement. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run Given that the documentation of the GC.run command is: "GC.run Call java.lang.System.gc(). Impact: Medium: Depends on Java heap size and content. Syntax: GC.run" I interpret the documentation that the GC is supposed to be (for all intents and purposes) equivalent to the application invoking System.gc(). This would also require updates to other places where we refer to the _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. /Mikael > > > I'm jdk9 committer, but I'm not employee at Oracle. > So I need a Sponsor. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html > [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html > From poonam.bajaj at oracle.com Fri Feb 13 19:44:38 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Fri, 13 Feb 2015 11:44:38 -0800 Subject: Review request: Backport of JDK-8046282 to 8u In-Reply-To: <3C1BF91B-1BC6-4CA0-A77D-62A4972C86D6@oracle.com> References: <54CA8D1C.6010408@oracle.com> <3C1BF91B-1BC6-4CA0-A77D-62A4972C86D6@oracle.com> Message-ID: <54DE5426.4090409@oracle.com> Hello Staffan, Yes, the changes apply cleanly. I have also included the changes for JDK-8049881: jstack not working on core files which was a regression introduced in jdk9 with the changes of 8046282. Testing: JPRT, jstack with core and live process Thanks, Poonam On 2/12/2015 11:51 PM, Staffan Larsen wrote: > Hi Poonam, > > Did the changes apply cleanly? What tests have you run? > > /Staffan > >> On 29 jan 2015, at 20:42, Poonam Bajaj Parhar >> > wrote: >> >> Hello, >> >> Review request for the backport of 8046282 to 8u: >> >> Bug: JDK-8046282 >> SA update >> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ >> >> Thanks, >> Poonam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Feb 13 19:49:41 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 13 Feb 2015 11:49:41 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <776B0873-7B7B-4537-B620-B32056723777@oracle.com> References: <54ADC152.6000706@oracle.com> <54D42BC0.3010502@oracle.com> <54D962C6.1060505@oracle.com> <54D96653.1010502@oracle.com> <025C5545-95F5-4B7A-83A3-E0822E9ED979@oracle.com> <54DAC8E1.3000608@oracle.com> <54DB2B1D.6000102@oracle.com> <54DB938A.7000002@oracle.com> <54DC6424.9050109@oracle.com> <54DC64E3.2010404@oracle.com> <776B0873-7B7B-4537-B620-B32056723777@oracle.com> Message-ID: <54DE5555.3010701@oracle.com> An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Feb 13 20:00:10 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Feb 2015 21:00:10 +0100 Subject: Review request: Backport of JDK-8046282 to 8u In-Reply-To: <54DE5426.4090409@oracle.com> References: <54CA8D1C.6010408@oracle.com> <3C1BF91B-1BC6-4CA0-A77D-62A4972C86D6@oracle.com> <54DE5426.4090409@oracle.com> Message-ID: <5DA05229-E695-4E5A-A404-232359EFFC82@oracle.com> Looks good! Thanks, /Staffan > On 13 feb 2015, at 20:44, Poonam Bajaj Parhar wrote: > > Hello Staffan, > > Yes, the changes apply cleanly. > > I have also included the changes for > JDK-8049881: jstack not working on core files > > which was a regression introduced in jdk9 with the changes of 8046282. > > Testing: JPRT, jstack with core and live process > > Thanks, > Poonam > > On 2/12/2015 11:51 PM, Staffan Larsen wrote: >> Hi Poonam, >> >> Did the changes apply cleanly? What tests have you run? >> >> /Staffan >> >>> On 29 jan 2015, at 20:42, Poonam Bajaj Parhar > wrote: >>> >>> Hello, >>> >>> Review request for the backport of 8046282 to 8u: >>> >>> Bug: JDK-8046282 SA update >>> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ >>> >>> Thanks, >>> Poonam >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brendan.d.gregg at gmail.com Fri Feb 13 22:26:58 2015 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Fri, 13 Feb 2015 14:26:58 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <54B7FDC9.8020103@oracle.com> References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> <54B68056.3090706@oracle.com> <54B7A0C4.6040009@oracle.com> <54B7FDC9.8020103@oracle.com> Message-ID: Thanks Bertrand and John for explaining the invokedynamic issue, and Vladimir for filing the bug. I'll reply here (I don't have a JBS account; I would like one!). The profilers I'm using (Linux perf, and Solaris DTrace) can already handle a broken RBP, and we see this all the time when profiling OracleJDK today (eg, as a flame graph: http://www.slideshare.net/brendangregg/netflix-from-clouds-to-roots/66). Including an option (eg, -XX:+NoOmitFramePointer, or -XX:+ReduceOmitFramePointer, or -XX:+MoreFramePointer) which improved RBP profiling (like my patch) would have great value for us. I'm fine with a profiler not working 100% of the time, provided we understand that there is an error margin and why (Bertrand and John's descriptions) for when interpreting the profiles. Any of these options could also be improved as follow-on changes, if and when needed. I haven't had a chance yet to prototype more (eg, option processing). There's also work happening in Linux (two projects on lkml this week, one by Stephane Eranian and another by Carl Love) for improving Java JIT symbol support in perf_events. I think there will be more demand for system stack walking, as perf gets more symbol translation options. Brendan On Thu, Jan 15, 2015 at 9:50 AM, Vladimir Kozlov wrote: > Thank you, Bertrand and John > > I added this conversation to the bug report. > > Thanks, > Vladimir > > > On 1/15/15 3:13 AM, Bertrand Delsart wrote: > >> On 14/01/2015 20:12, John Rose wrote: >> >>> On Jan 14, 2015, at 6:42 AM, Bertrand Delsart >>> > >>> wrote: >>> >>>> >>>> I would not prevent the JITs from using RBP as long as the changeset >>>> is not sufficient to guarantee the profiling will work... and IMHO >>>> solving the JSR292 issue will be much more intrusive (impacting >>>> HotSpot stack walking code). >>>> >>> >>> Here are some thoughts on that. >>> >>> SPARC uses L7 (L7_mh_SP_save) for the same purpose of method handle >>> support as x86 uses RBP (rbp_mh_SP_save). So there's not a hard >>> requirement for x86 to take over RBP. >>> >>> (Deep background: This purpose, in method handle support, is to allow >>> an adapter to make changes to the caller's SP. The adapter is the >>> initial callee from the caller, but may change argument shape, and >>> tail-calls the ultimate callee. Because it is a tail-call, the original >>> caller must have a spot where his original SP can be preserved. The >>> preservation works because the original caller knows he is calling a >>> MH.invoke method, which requires the extra argument preservation. The >>> repertoire of argument shape changes is quite small, actually; it is not >>> a very general mechanism since the LF machinery was put in. Perhaps the >>> whole thing could be removed somehow, by finding alternative techniques >>> for the few remaining changes. OTOH, this SP-restoring mechanism may be >>> helpful in doing more a general tail-call mechanism, and perhaps in >>> managing int/comp mode changes more cleanly, so I'd like us to keep it. >>> And document it better.) >>> >>> Any register or stack slot will do for this purpose, as long as (i) its >>> value can be recovered after the MH.invoke call returns to the caller, >>> and (ii) its value can be dug up somehow during stack walking. There >>> are only a couple of places where stack walking code needs to sample the >>> value, so they should be adjustable. >>> >>> Both x86 and SPARC use registers which are callee-save (or "non-volatile >>> across calls") which satisfy properties (i) and (ii). A standard stack >>> slot (addressed based on caller's RBP) would probably also satisfy those >>> properties. >>> >>> A variably-positioned stack slot would also work, which would require >>> registering the position in each CodeBlob. That's unpleasant extra >>> detail, but it would align somewhat with the current logic which allows >>> each CodeBlob (nmethod, actually) to advertise which call sites need the >>> special processing (see the function is_method_handle_return( >>> caller_pc)). >>> >>> I recommend reserving a dead word of space in every stack frame that >>> makes MH.invoke calls, at a fixed position relative to that frame's RBP. >>> >>> ? John >>> >> >> I perfectly agree that it is doable (and with your proposed approach). >> >> I just wanted to be sure people were aware that the RFE is more complex >> than what the current changeset may suggest. We are not just taking >> about reviewing and integrating a complete changeset contributed by the >> community. There is more work needed, either by the community or by >> Oracle. This will require changes at least in C1 and C2 call sequences, >> in the stack walking, in the creation and sizing of compiled frames... >> >> Regards, >> >> Bertrand. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brendan.d.gregg at gmail.com Fri Feb 13 22:28:01 2015 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Fri, 13 Feb 2015 14:28:01 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <54B8307B.5040208@oracle.com> References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> <54B68056.3090706@oracle.com> <54B7A0C4.6040009@oracle.com> <54B8307B.5040208@oracle.com> Message-ID: G'Day Serguei, On Thu, Jan 15, 2015 at 1:26 PM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > On 1/15/15 3:13 AM, Bertrand Delsart wrote: > >> On 14/01/2015 20:12, John Rose wrote: >> >>> On Jan 14, 2015, at 6:42 AM, Bertrand Delsart >>> > >>> wrote: >>> >>>> >>>> I would not prevent the JITs from using RBP as long as the changeset >>>> is not sufficient to guarantee the profiling will work... and IMHO >>>> solving the JSR292 issue will be much more intrusive (impacting >>>> HotSpot stack walking code). >>>> >>> >>> Here are some thoughts on that. >>> >>> SPARC uses L7 (L7_mh_SP_save) for the same purpose of method handle >>> support as x86 uses RBP (rbp_mh_SP_save). So there's not a hard >>> requirement for x86 to take over RBP. >>> >>> (Deep background: This purpose, in method handle support, is to allow >>> an adapter to make changes to the caller's SP. The adapter is the >>> initial callee from the caller, but may change argument shape, and >>> tail-calls the ultimate callee. Because it is a tail-call, the original >>> caller must have a spot where his original SP can be preserved. The >>> preservation works because the original caller knows he is calling a >>> MH.invoke method, which requires the extra argument preservation. The >>> repertoire of argument shape changes is quite small, actually; it is not >>> a very general mechanism since the LF machinery was put in. Perhaps the >>> whole thing could be removed somehow, by finding alternative techniques >>> for the few remaining changes. OTOH, this SP-restoring mechanism may be >>> helpful in doing more a general tail-call mechanism, and perhaps in >>> managing int/comp mode changes more cleanly, so I'd like us to keep it. >>> And document it better.) >>> >>> Any register or stack slot will do for this purpose, as long as (i) its >>> value can be recovered after the MH.invoke call returns to the caller, >>> and (ii) its value can be dug up somehow during stack walking. There >>> are only a couple of places where stack walking code needs to sample the >>> value, so they should be adjustable. >>> >>> Both x86 and SPARC use registers which are callee-save (or "non-volatile >>> across calls") which satisfy properties (i) and (ii). A standard stack >>> slot (addressed based on caller's RBP) would probably also satisfy those >>> properties. >>> >>> A variably-positioned stack slot would also work, which would require >>> registering the position in each CodeBlob. That's unpleasant extra >>> detail, but it would align somewhat with the current logic which allows >>> each CodeBlob (nmethod, actually) to advertise which call sites need the >>> special processing (see the function is_method_handle_return( >>> caller_pc)). >>> >>> I recommend reserving a dead word of space in every stack frame that >>> makes MH.invoke calls, at a fixed position relative to that frame's RBP. >>> >>> ? John >>> >> >> I perfectly agree that it is doable (and with your proposed approach). >> >> I just wanted to be sure people were aware that the RFE is more complex >> than what the current changeset may suggest. We are not just taking about >> reviewing and integrating a complete changeset contributed by the >> community. There is more work needed, either by the community or by Oracle. >> This will require changes at least in C1 and C2 call sequences, in the >> stack walking, in the creation and sizing of compiled frames... >> > > Just want to note about the stack walking... > It also impacts some places that people are normally unaware of: > - SA-based stack walking (jstack utility) > - Solaris-specific: jhelper.d (dtrace jstack action support) and > libjvm_db.so (pstack utility support) > > Were these broken by the reuse of RBP as well? (I suspect so; I never tested my RBP fix with DTrace jstack()). Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Feb 13 22:49:24 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Feb 2015 14:49:24 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> <54B68056.3090706@oracle.com> <54B7A0C4.6040009@oracle.com> <54B8307B.5040208@oracle.com> Message-ID: <54DE7F74.4050803@oracle.com> On 2/13/15 2:28 PM, Brendan Gregg wrote: > G'Day Serguei, > > On Thu, Jan 15, 2015 at 1:26 PM, serguei.spitsyn at oracle.com > > wrote: > > On 1/15/15 3:13 AM, Bertrand Delsart wrote: > > On 14/01/2015 20:12, John Rose wrote: > > On Jan 14, 2015, at 6:42 AM, Bertrand Delsart > > >> wrote: > > > I would not prevent the JITs from using RBP as long as > the changeset > is not sufficient to guarantee the profiling will > work... and IMHO > solving the JSR292 issue will be much more intrusive > (impacting > HotSpot stack walking code). > > > Here are some thoughts on that. > > SPARC uses L7 (L7_mh_SP_save) for the same purpose of > method handle > support as x86 uses RBP (rbp_mh_SP_save). So there's not > a hard > requirement for x86 to take over RBP. > > (Deep background: This purpose, in method handle support, > is to allow > an adapter to make changes to the caller's SP. The adapter > is the > initial callee from the caller, but may change argument > shape, and > tail-calls the ultimate callee. Because it is a > tail-call, the original > caller must have a spot where his original SP can be > preserved. The > preservation works because the original caller knows he is > calling a > MH.invoke method, which requires the extra argument > preservation. The > repertoire of argument shape changes is quite small, > actually; it is not > a very general mechanism since the LF machinery was put > in. Perhaps the > whole thing could be removed somehow, by finding > alternative techniques > for the few remaining changes. OTOH, this SP-restoring > mechanism may be > helpful in doing more a general tail-call mechanism, and > perhaps in > managing int/comp mode changes more cleanly, so I'd like > us to keep it. > And document it better.) > > Any register or stack slot will do for this purpose, as > long as (i) its > value can be recovered after the MH.invoke call returns to > the caller, > and (ii) its value can be dug up somehow during stack > walking. There > are only a couple of places where stack walking code needs > to sample the > value, so they should be adjustable. > > Both x86 and SPARC use registers which are callee-save (or > "non-volatile > across calls") which satisfy properties (i) and (ii). A > standard stack > slot (addressed based on caller's RBP) would probably also > satisfy those > properties. > > A variably-positioned stack slot would also work, which > would require > registering the position in each CodeBlob. That's > unpleasant extra > detail, but it would align somewhat with the current logic > which allows > each CodeBlob (nmethod, actually) to advertise which call > sites need the > special processing (see the function > is_method_handle_return(caller_pc)). > > I recommend reserving a dead word of space in every stack > frame that > makes MH.invoke calls, at a fixed position relative to > that frame's RBP. > > ? John > > > I perfectly agree that it is doable (and with your proposed > approach). > > I just wanted to be sure people were aware that the RFE is > more complex than what the current changeset may suggest. We > are not just taking about reviewing and integrating a complete > changeset contributed by the community. There is more work > needed, either by the community or by Oracle. This will > require changes at least in C1 and C2 call sequences, in the > stack walking, in the creation and sizing of compiled frames... > > > Just want to note about the stack walking... > It also impacts some places that people are normally unaware of: > - SA-based stack walking (jstack utility) > - Solaris-specific: jhelper.d (dtrace jstack action support) and > libjvm_db.so (pstack utility support) > > > Were these broken by the reuse of RBP as well? (I suspect so; I never > tested my RBP fix with DTrace jstack()). I'd not be surprised if these are broken while there is a chance they are not. My point is that the impact is bigger than normally expected and so, need to be tested. We do not have yet good automated tests for jhelper.d and libjvm_db.so. Thanks, Serguei > > Brendan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmundak at google.com Fri Feb 13 23:13:36 2015 From: asmundak at google.com (Alexander Smundak) Date: Fri, 13 Feb 2015 15:13:36 -0800 Subject: gdb and OpenJDK In-Reply-To: <20150213100201.GD23518@ehelin.jrpg.bea.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> Message-ID: You have to solve two problems to be able to use GDB to debug mixed language applications: how to walk the stack, and how to symbolize the frames. And, it has to work on core dumps, so it cannot rely on executing the code in debuggee. You can use JIT reader interface to walk the stack (that was my first attempt), but there is no binary interface to symbolize the frames, it can be achieved only via Python plugin. Having two pieces of code, a binary (shared object) containing JIT reader written in C or C++, and a Python module for symbolizing frames, is really inconvenient. GDB is very much set on using Python as extension language, it exposes quite sizable piece of its internals to it: you can programmatically issue commands, implement new CLI commands, inspect debuggee, programmatically respond to debuggee signals (will prove to be quite handy for JVM, Python code can handle SIGSEGV intelligently by passing it to JVM to handle null pointer exception if it happens in Java code). IMHO it's a fairly good trade-off, despite the understandable reluctance to use yet another language. On Fri, Feb 13, 2015 at 2:02 AM, Erik Helin wrote: > On 2015-02-13, Erik Helin wrote: >> On 2015-02-12, Alexander Smundak wrote: >> > It was the previous implementation that used the serviceability agent, >> > sorry for the confusion. The new one replicates the necessary >> > functionality of the serviceability agent instead. All the operations >> > on the debuggee (catching events, reading writing to the debuggee >> > memory, etc.) are performed by the GDB. >> > The Python code consists of two "plugins". The first does "unwinding", >> > that is, finding out the caller's frame for a given frame. JIT frames >> > need unwinding because JIT code uses frame pointer as a general >> > purpose register (I am speaking of x86_64), so GDB cannot unwind it. >> > So the unwinding plugin locates nmethod instance containing given PC, >> > fetches the frame size from it, and is thus able to locate the >> > previous frame. >> > The second plugin symbolizes Java frames (GDB already has the >> > interface for that called FrameDecorators), and it requires sizable >> > amount of code to traverse various JVM structures to do that. >> > The Python module is currently about 2500 lines of code. About 10% of >> > this code is platform-dependent (I have implementations for x86_64 and >> > PowerPC64 and working on Aarch64). >> >> First of all, thanks for putting work into this, having Java stacktraces in >> GDB would be really helpful. >> >> Just a quick question, instead of rewriting the stack walking code in >> Python, would it be possible to use gdbjit [0]? Apparently, this is used >> by LLVM MC JIT and I also think that V8 has some basic support for it. >> The benefit of using something like gdbjit would be to not have the >> stack walking code in multiple places: >> - the vm >> - SA >> - Python for gdb > > I just had a discussion with Staffan about this, and I just want to > clarify my comment: instead of rewriting the stack walking code in > multiple places, can we add some code in the VM that aids the > development of tools like these? We will of course require platform/tool > specific code, and probably some duplication, but how little duplication > can we get away with? gdbjit seems like it can consume a custom debug > info format, maybe we can design a very lightweight debug info format > that then can be picked up by a variety of tools (lldb, windbg, gdb, > SA, etc...)? > > Thanks, > Erik > >> Thanks, >> Erik >> >> [0]: https://sourceware.org/gdb/onlinedocs/gdb/JIT-Interface.html >> >> > Sasha >> > >> > On Thu, Feb 12, 2015 at 2:14 AM, Volker Simonis >> > wrote: >> > > Hi Jeremy, >> > > >> > > nice to see that somebody is working on this topic. >> > > >> > > Can you please detail a little bit on how this would work? >> > > As far as I understand you extend gdb to support "frame undwinder" >> > > plugins written in Python. >> > > >> > > One of these plugins, which you want to contribute to the OpenJDK, can >> > > be used to unwind native Java/HotSpot stack frames by calling out to >> > > the serviceability agent. Can you please explain how this could work? >> > > If you debug a Java process with gdb, gdb attaches to that process >> > > using "ptrace". The SA agent uses "ptrace" as well but as far as I >> > > know, only once process can attach to another process at the same >> > > time. So how is this callback from gdb to the SA agent supposed to >> > > work? >> > > >> > > Regards, >> > > Volker >> > > >> > > >> > > On Wed, Feb 11, 2015 at 11:27 PM, Jeremy Manson wrote: >> > >> Hey folks, >> > >> >> > >> I think I've mentioned to some of the people on this list that we (and by >> > >> we, I mean Sasha Smundak) have been working on interoperability between gdb >> > >> and Java. Basically, what we have now allows us to get a backtrace in gdb >> > >> that includes Java frames with parameter values (no local variables yet). >> > >> >> > >> Needless to say, this has been terribly, terribly helpful in our JVM and JNI >> > >> debugging. >> > >> >> > >> Support for this feature is basically two parts: >> > >> >> > >> First, gdb needed to be extended to support the ability to plug in a frame >> > >> unwinder. The process of submitting this to gdb (which has been ongoing for >> > >> quite a while) is finally starting to make reasonable progress. >> > >> >> > >> Next, we need a plugin for OpenJDK. We have a plugin written that calls out >> > >> to the serviceability agent. (It's written in Python, per gdb's >> > >> requirements). >> > >> >> > >> Pending the gdb support being finalized, we'd love to contribute the plugin >> > >> to OpenJDK. What should we do make that happen? Write a JEP and submit >> > >> it to this list? Technically, neither of us are committers (which you need >> > >> to be to submit a JEP), but I imagine we can work around that. >> > >> >> > >> Here's the gdb patch, for anyone interested: >> > >> >> > >> https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html >> > >> >> > >> Thanks! >> > >> >> > >> Jeremy From yasuenag at gmail.com Sat Feb 14 13:10:46 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 14 Feb 2015 22:10:46 +0900 Subject: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54DDEF20.6010501@oracle.com> References: <54DB6113.4080104@gmail.com> <54DDEF20.6010501@oracle.com> Message-ID: <54DF4956.7030709@gmail.com> Hi Mikael, > I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run Can I add _dcmd_gc_run to GCCause::is_user_requested_gc() ? This function is used with GCCause::is_serviceability_requested_gc() . CMSCollector::is_external_interruption() and AdaptiveSizePolicy::check_gc_overhead_limit() is_user_requested_gc() and is_serviceability_requested_gc() checkes _jvmti_force_gc is selected. So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run to it. > A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. We can use GCCause::is_user_requested_gc() if the proposal in above is accepted. Thanks Yasumasa On 2015/02/13 21:33, Mikael Gerdin wrote: > Hi Yasumasa, > > On 2015-02-11 15:02, Yasumasa Suenaga wrote: >> Hi all, >> >> I've committed JDK-8068589 to add new GCCause - Diagnostic Command. >> However, it has been backouted because test is failed [1] and it is not considered >> about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2]. >> >> I've created patch for this enhancement. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/ > > I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run > > Given that the documentation of the GC.run command is: > "GC.run > Call java.lang.System.gc(). > > Impact: Medium: Depends on Java heap size and content. > > Syntax: GC.run" > > I interpret the documentation that the GC is supposed to be (for all intents and purposes) equivalent to the application invoking System.gc(). > > This would also require updates to other places where we refer to the _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC > > A "grep" for _java_lang_system_gc should yield more places where updates may be necessary. > > /Mikael > >> >> >> I'm jdk9 committer, but I'm not employee at Oracle. >> So I need a Sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html >> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html >> From staffan.larsen at oracle.com Sun Feb 15 19:55:58 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sun, 15 Feb 2015 20:55:58 +0100 Subject: gdb and OpenJDK In-Reply-To: References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> Message-ID: Alexandre, I think what Erik suggested was if there was some way the JVM could expose data in a format that is easy to interpret by other tools (such as the python gdb plugin, but also plugins for other debuggers, or SA). Of course this would have to be data, not code, so that it would be available in core files as well. I haven?t seen the python module you have written so I don?t know how complex is it, but we should think of ways to make such code even simpler if possible. If we had data exposed in an easy-to-read format it would perhaps make maintenance of these tools simpler. We have a problem with SA today that it is way to dependent on the code in the JVM - a small change in data structures in the JVM will break SA, something we hare looking for solutions to. Thanks, /Staffan > On 14 feb 2015, at 00:13, Alexander Smundak wrote: > > You have to solve two problems to be able to use GDB to debug mixed language > applications: how to walk the stack, and how to symbolize the frames. > And, it has > to work on core dumps, so it cannot rely on executing the code in debuggee. > You can use JIT reader interface to walk the stack (that was my first attempt), > but there is no binary interface to symbolize the frames, it can be > achieved only > via Python plugin. Having two pieces of code, a binary (shared object) > containing JIT reader written in C or C++, and a Python module for symbolizing > frames, is really inconvenient. > > GDB is very much set on using Python as extension language, it exposes quite > sizable piece of its internals to it: you can programmatically issue commands, > implement new CLI commands, inspect debuggee, programmatically respond > to debuggee signals (will prove to be quite handy for JVM, Python code can > handle SIGSEGV intelligently by passing it to JVM to handle null > pointer exception > if it happens in Java code). > IMHO it's a fairly good trade-off, despite the understandable reluctance to use > yet another language. > > On Fri, Feb 13, 2015 at 2:02 AM, Erik Helin wrote: >> On 2015-02-13, Erik Helin wrote: >>> On 2015-02-12, Alexander Smundak wrote: >>>> It was the previous implementation that used the serviceability agent, >>>> sorry for the confusion. The new one replicates the necessary >>>> functionality of the serviceability agent instead. All the operations >>>> on the debuggee (catching events, reading writing to the debuggee >>>> memory, etc.) are performed by the GDB. >>>> The Python code consists of two "plugins". The first does "unwinding", >>>> that is, finding out the caller's frame for a given frame. JIT frames >>>> need unwinding because JIT code uses frame pointer as a general >>>> purpose register (I am speaking of x86_64), so GDB cannot unwind it. >>>> So the unwinding plugin locates nmethod instance containing given PC, >>>> fetches the frame size from it, and is thus able to locate the >>>> previous frame. >>>> The second plugin symbolizes Java frames (GDB already has the >>>> interface for that called FrameDecorators), and it requires sizable >>>> amount of code to traverse various JVM structures to do that. >>>> The Python module is currently about 2500 lines of code. About 10% of >>>> this code is platform-dependent (I have implementations for x86_64 and >>>> PowerPC64 and working on Aarch64). >>> >>> First of all, thanks for putting work into this, having Java stacktraces in >>> GDB would be really helpful. >>> >>> Just a quick question, instead of rewriting the stack walking code in >>> Python, would it be possible to use gdbjit [0]? Apparently, this is used >>> by LLVM MC JIT and I also think that V8 has some basic support for it. >>> The benefit of using something like gdbjit would be to not have the >>> stack walking code in multiple places: >>> - the vm >>> - SA >>> - Python for gdb >> >> I just had a discussion with Staffan about this, and I just want to >> clarify my comment: instead of rewriting the stack walking code in >> multiple places, can we add some code in the VM that aids the >> development of tools like these? We will of course require platform/tool >> specific code, and probably some duplication, but how little duplication >> can we get away with? gdbjit seems like it can consume a custom debug >> info format, maybe we can design a very lightweight debug info format >> that then can be picked up by a variety of tools (lldb, windbg, gdb, >> SA, etc...)? >> >> Thanks, >> Erik >> >>> Thanks, >>> Erik >>> >>> [0]: https://sourceware.org/gdb/onlinedocs/gdb/JIT-Interface.html >>> >>>> Sasha >>>> >>>> On Thu, Feb 12, 2015 at 2:14 AM, Volker Simonis >>>> wrote: >>>>> Hi Jeremy, >>>>> >>>>> nice to see that somebody is working on this topic. >>>>> >>>>> Can you please detail a little bit on how this would work? >>>>> As far as I understand you extend gdb to support "frame undwinder" >>>>> plugins written in Python. >>>>> >>>>> One of these plugins, which you want to contribute to the OpenJDK, can >>>>> be used to unwind native Java/HotSpot stack frames by calling out to >>>>> the serviceability agent. Can you please explain how this could work? >>>>> If you debug a Java process with gdb, gdb attaches to that process >>>>> using "ptrace". The SA agent uses "ptrace" as well but as far as I >>>>> know, only once process can attach to another process at the same >>>>> time. So how is this callback from gdb to the SA agent supposed to >>>>> work? >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Wed, Feb 11, 2015 at 11:27 PM, Jeremy Manson wrote: >>>>>> Hey folks, >>>>>> >>>>>> I think I've mentioned to some of the people on this list that we (and by >>>>>> we, I mean Sasha Smundak) have been working on interoperability between gdb >>>>>> and Java. Basically, what we have now allows us to get a backtrace in gdb >>>>>> that includes Java frames with parameter values (no local variables yet). >>>>>> >>>>>> Needless to say, this has been terribly, terribly helpful in our JVM and JNI >>>>>> debugging. >>>>>> >>>>>> Support for this feature is basically two parts: >>>>>> >>>>>> First, gdb needed to be extended to support the ability to plug in a frame >>>>>> unwinder. The process of submitting this to gdb (which has been ongoing for >>>>>> quite a while) is finally starting to make reasonable progress. >>>>>> >>>>>> Next, we need a plugin for OpenJDK. We have a plugin written that calls out >>>>>> to the serviceability agent. (It's written in Python, per gdb's >>>>>> requirements). >>>>>> >>>>>> Pending the gdb support being finalized, we'd love to contribute the plugin >>>>>> to OpenJDK. What should we do make that happen? Write a JEP and submit >>>>>> it to this list? Technically, neither of us are committers (which you need >>>>>> to be to submit a JEP), but I imagine we can work around that. >>>>>> >>>>>> Here's the gdb patch, for anyone interested: >>>>>> >>>>>> https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jeremy From staffan.larsen at oracle.com Mon Feb 16 08:02:01 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Feb 2015 09:02:01 +0100 Subject: RFR 8072908: 8072908: com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh fails on OS X with exit code 2 In-Reply-To: <54DDC6A0.7050601@oracle.com> References: <54DCB5C7.3020808@oracle.com> <54DCB751.50200@oracle.com> <54DD632F.60400@oracle.com> <54DDC6A0.7050601@oracle.com> Message-ID: <74F62003-8280-4A27-B95E-EE7CDFC1C388@oracle.com> Looks good! (And verified on my mac) Thanks, /Staffan > On 13 feb 2015, at 10:40, Jaroslav Bachorik wrote: > > On 13.2.2015 03:36, David Holmes wrote: >> Hi Jaroslav, >> >> Looks reasonable - but I can't vouch for MacOSX commands. > > I am not a lucky Mac owner neither. I confirmed the format running the test on the test farm Mac machines only. > >> >> Minor nit: >> >> 111 // total used free shared buffers >> cached >> 112 // Mem: 16533540864 13638467584 2895073280 >> 534040576 1630248960 6236909568 >> >> The labels in #111 need to move across. > > Ah, will move it :) Thanks > > -JB- > >> >> Thanks, >> David >> >> On 13/02/2015 12:23 AM, Jaroslav Bachorik wrote: >>> On 12.2.2015 15:16, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/rest/api/latest/issue/JDK-8072908 >>> >>> Should be https://bugs.openjdk.java.net/browse/JDK-8072908 >>> >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8072908/webrev.00 >>>> >>>> The existing shell test fails for MacOS when there is no swap configured >>>> due to the pattern processing problem. >>>> >>>> This patch converts the shell test to a plain Java one and makes sure >>>> the test does not break for zero size swap on MacOS (or any other OS for >>>> that matter) >>>> >>>> Thanks, >>>> >>>> -JB- >>> > From staffan.larsen at oracle.com Mon Feb 16 08:21:40 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Feb 2015 09:21:40 +0100 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> Message-ID: <7C45C216-082C-4020-8A40-E831FD181BBC@oracle.com> I have submitted the CCC request. Will get back to this thread with the results. /Staffan > On 10 feb 2015, at 22:08, Martin Buchholz wrote: > > I'm not a serviceability engineer, but I reviewed this change and it seems fine to me. Can someone from Oracle please shepherd through CCC? > > On Mon, Feb 9, 2015 at 4:51 PM, Jeremy Manson > wrote: > Thanks for taking a look, Staffan. Sorry about the delay. I've gone ahead and made a test: > > http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ > > Can anyone drive the API process? It's such a minor change that I can't imagine it wouldn't go through easily. Of course, I have no idea what's involved. > > Jeremy > > On Mon, Jan 12, 2015 at 11:10 PM, Staffan Larsen > wrote: > > > On 13 jan 2015, at 06:28, David Holmes > wrote: > > > > Hi Jeremy, > > > > On 13/01/2015 4:32 AM, Jeremy Manson wrote: > >> Hi folks, > >> > >> This was long forgotten, seems to have been lost in the shuffle. I've > >> done it, since we could use it, too: > >> > >> https://bugs.openjdk.java.net/browse/JDK-6588467 > >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.00/ > > > > Codewise this all appears fine to me. > > Thanks for doing this. I have only scanned the code, but did not see any test. Could you please add tests for the new API? > > >> Since it is an API change (albeit an uncontroversial one), it will have > >> to go through whatever the super-secret API change review process is > >> that you folks do. > > > > Not sure if this just needs an API tweak or a JMX spec revision. If the latter then this might be a big deal. But I'll leave that to the official serviceability folk :) > > No spec revision is needed, same process as for all API changes. Unfortunately I don?t have the time to drive that, so hoping someone else can jump in. > > /Staffan > > > > > Cheers, > > David > > > >> Thanks! > >> > >> Jeremy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Mon Feb 16 08:35:25 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 16 Feb 2015 09:35:25 +0100 Subject: DTraceAllocProbes bug in interpreter In-Reply-To: References: Message-ID: <54E1ABCD.5010308@oracle.com> Hi Jungwoo, The DTrace probes are part of the serviceability support, bcc:ing gc-dev and redirecting to serviceability-dev. /Mikael On 2015-02-14 02:21, Jungwoo Ha wrote: > I am not sure if DTraceAllocProbes is a live code, but I think this is a > bug. > dtrace_object_alloc has changed to receive size argument in JDK8. > This code only passes oop to dtrace_object_alloc. RDX has the size but > it needs to be saved. > I don't use DTrace, but it looks broken. If someone sponsor this is a > right fix, I'll create a webrev. > > diff -r f06c7b654d63 src/cpu/x86/vm/templateTable_x86_32.cpp > --- a/src/cpu/x86/vm/templateTable_x86_32.cppThu Jul 31 09:58:53 2014 +0100 > +++ b/src/cpu/x86/vm/templateTable_x86_32.cppFri Feb 13 17:14:57 2015 -0800 > @@ -3288,6 +3288,7 @@ > // The object is initialized before the header. If the object size is > // zero, go directly to the header initialization. > __ bind(initialize_object); > + __ push(rdx); // save object size > __ decrement(rdx, sizeof(oopDesc)); > __ jcc(Assembler::zero, initialize_header); > @@ -3328,13 +3329,14 @@ > __ pop(rcx); // get saved klass back in the register. > } > __ store_klass(rax, rcx); // klass > + __ pop(rdx); // restore object size to rdx > { > SkipIfEqual skip_if(_masm, &DTraceAllocProbes, 0); > // Trigger dtrace event for fastpath > __ push(atos); > __ call_VM_leaf( > - CAST_FROM_FN_PTR(address, > SharedRuntime::dtrace_object_alloc), rax); > + CAST_FROM_FN_PTR(address, > SharedRuntime::dtrace_object_alloc), rax, rdx); > __ pop(atos); > } > diff -r f06c7b654d63 src/cpu/x86/vm/templateTable_x86_64.cpp > --- a/src/cpu/x86/vm/templateTable_x86_64.cppThu Jul 31 09:58:53 2014 +0100 > +++ b/src/cpu/x86/vm/templateTable_x86_64.cppFri Feb 13 17:14:57 2015 -0800 > @@ -3352,6 +3352,7 @@ > // The object is initialized before the header. If the object size is > // zero, go directly to the header initialization. > __ bind(initialize_object); > + __ movl(rbx, rdx); // save object size to rbx > __ decrementl(rdx, sizeof(oopDesc)); > __ jcc(Assembler::zero, initialize_header); > @@ -3386,7 +3387,7 @@ > // Trigger dtrace event for fastpath > __ push(atos); // save the return value > __ call_VM_leaf( > - CAST_FROM_FN_PTR(address, > SharedRuntime::dtrace_object_alloc), rax); > + CAST_FROM_FN_PTR(address, > SharedRuntime::dtrace_object_alloc), rax, rbx); > __ pop(atos); // restore the return value > } > From aph at redhat.com Mon Feb 16 09:40:26 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Feb 2015 09:40:26 +0000 Subject: gdb and OpenJDK In-Reply-To: References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> Message-ID: <54E1BB0A.50405@redhat.com> On 15/02/15 19:55, Staffan Larsen wrote: > I think what Erik suggested was if there was some way the JVM could > expose data in a format that is easy to interpret by other tools > (such as the python gdb plugin, but also plugins for other > debuggers, or SA). Of course this would have to be data, not code, > so that it would be available in core files as well. I haven?t seen > the python module you have written so I don?t know how complex is > it, but we should think of ways to make such code even simpler if > possible. If we had data exposed in an easy-to-read format it would > perhaps make maintenance of these tools simpler. We have a problem > with SA today that it is way to dependent on the code in the JVM - a > small change in data structures in the JVM will break SA, something > we hare looking for solutions to. I'm sure that's true, but let's not allow the Best to be the enemy of the Good Enough; this is a contribution that we can use today. Andrew. From volker.simonis at gmail.com Mon Feb 16 10:43:41 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Feb 2015 11:43:41 +0100 Subject: gdb and OpenJDK In-Reply-To: <54E1BB0A.50405@redhat.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> Message-ID: Hi everybody, I really don't want to prevent the "Good Enough" solution and as far as I understand, this solution doesn't require any code changes to HotSpot, right? It will just add an additional Python artifact to the OpenJDK delivery which will be used by gdb. But in general I have to agree with Erik and Staffan. Getting a mixed stack trace of a running Java process or a core file is notoriously hard. The best we have today is the native, built-in stack walking code in HotSpot which is used for hs_err files and which can be also called from within gdb (see print_native_stack() in src/share/vm/utilities/debug.cpp). If you look at that code (and at the functions it calls like frame.sender(), os::get_sender_for_C_frame(&fr), fraame.is_java_frame(), frame.is_native_frame(), frame.is_runtime_frame(), etc...) you will see that there are a lot of special cases to handle. And even that code is not perfect. I can easily show you examples where it doesn't work (mostly at the beginning of methods/stubs when the new frame is being set up but still not complete). All this complicated (and platform dependent) code is replicated in Java in the SA agent. You can easily verify that it isn't 100% perfect by running "jstack -m -F " against a running Java VM. Besides the problem of having frames in inconsistent state another big problem is the fact that we can only reliably unwind inlined Java frames from a native frame at safepoints. But that's of course not guaranteed if we use "jstack -F" or if we ask for a stack-trace in gdb at an arbitrary PC. Now if we replicate this SA code one more time in a Python library for GDB, you'll probably agree that it can't work more reliably than the original SA code. This may be good enough for some use cases, but it won't be perfect. I'm not a gdb/DWARF expert but I think what we really need is to generate debug information for all the generated code. We need to know for every single PC of generated code the corresponding frame information and how to get to the previous frame. I know it's possible and I know that gdb has callbacks to consume this debug information which is generated at runtime (see [1]) although I've never programmed it myself. LLVM seems to use this technique and has some documentation available ([2,3]). I suppose this is the direction Erik wanted to go and I think that would be the right way. Regards, Volker [1] https://sourceware.org/gdb/onlinedocs/gdb/JIT-Interface.html [2] http://llvm.org/docs/DebuggingJITedCode.html [3] http://llvm.org/releases/2.9/docs/DebuggingJITedCode.html On Mon, Feb 16, 2015 at 10:40 AM, Andrew Haley wrote: > On 15/02/15 19:55, Staffan Larsen wrote: > >> I think what Erik suggested was if there was some way the JVM could >> expose data in a format that is easy to interpret by other tools >> (such as the python gdb plugin, but also plugins for other >> debuggers, or SA). Of course this would have to be data, not code, >> so that it would be available in core files as well. I haven?t seen >> the python module you have written so I don?t know how complex is >> it, but we should think of ways to make such code even simpler if >> possible. If we had data exposed in an easy-to-read format it would >> perhaps make maintenance of these tools simpler. We have a problem >> with SA today that it is way to dependent on the code in the JVM - a >> small change in data structures in the JVM will break SA, something >> we hare looking for solutions to. > > I'm sure that's true, but let's not allow the Best to be the enemy of > the Good Enough; this is a contribution that we can use today. > > Andrew. From aph at redhat.com Mon Feb 16 10:52:45 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Feb 2015 10:52:45 +0000 Subject: gdb and OpenJDK In-Reply-To: References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> Message-ID: <54E1CBFD.7000001@redhat.com> On 02/16/2015 10:43 AM, Volker Simonis wrote: > Now if we replicate this SA code one more time in a Python library for > GDB, you'll probably agree that it can't work more reliably than the > original SA code. This may be good enough for some use cases, but it > won't be perfect. I'm not a gdb/DWARF expert but I think what we > really need is to generate debug information for all the generated > code. We need to know for every single PC of generated code the > corresponding frame information and how to get to the previous frame. It would be nice. We don't actually need it, given that we've done without for years, and generating e.g. full DWARF unwinder data for every instruction is something that even GCC doesn't always attempt to do. (And, of course, there's a lot of hand-written assembly code in HotSpot. Annotating this is a significant effort.) > I know it's possible and I know that gdb has callbacks to consume this > debug information which is generated at runtime (see [1]) although > I've never programmed it myself. LLVM seems to use this technique and > has some documentation available ([2,3]). I suppose this is the > direction Erik wanted to go and I think that would be the right way. It would be, long term. I've been discussing this with Red Hat's GDB group and I'm hoping to come up with a proposal and hopefully some working code. Andrew. From dmitry.samersoff at oracle.com Mon Feb 16 11:50:47 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 16 Feb 2015 14:50:47 +0300 Subject: gdb and OpenJDK In-Reply-To: <54E1CBFD.7000001@redhat.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> <54E1CBFD.7000001@redhat.com> Message-ID: <54E1D997.2040102@oracle.com> Andrew, One of possible solution is to make gdb to support native plugins, than re-use existing hotspot code as much as possible. I have a patch for gdb and can send it across if anybody interesting in it. With this patch we can do something like: (gdb) load-plugin libgdbjvm.so (gdb) attach PID (gdb) jvm show -Dmitry On 2015-02-16 13:52, Andrew Haley wrote: > On 02/16/2015 10:43 AM, Volker Simonis wrote: >> Now if we replicate this SA code one more time in a Python library for >> GDB, you'll probably agree that it can't work more reliably than the >> original SA code. This may be good enough for some use cases, but it >> won't be perfect. I'm not a gdb/DWARF expert but I think what we >> really need is to generate debug information for all the generated >> code. We need to know for every single PC of generated code the >> corresponding frame information and how to get to the previous frame. > > It would be nice. We don't actually need it, given that we've done > without for years, and generating e.g. full DWARF unwinder data for > every instruction is something that even GCC doesn't always attempt to > do. (And, of course, there's a lot of hand-written assembly code in > HotSpot. Annotating this is a significant effort.) > >> I know it's possible and I know that gdb has callbacks to consume this >> debug information which is generated at runtime (see [1]) although >> I've never programmed it myself. LLVM seems to use this technique and >> has some documentation available ([2,3]). I suppose this is the >> direction Erik wanted to go and I think that would be the right way. > > It would be, long term. I've been discussing this with Red Hat's GDB > group and I'm hoping to come up with a proposal and hopefully some > working code. > > Andrew. > -- 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 erik.helin at oracle.com Mon Feb 16 12:06:53 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 16 Feb 2015 13:06:53 +0100 Subject: gdb and OpenJDK In-Reply-To: <54E1CBFD.7000001@redhat.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> <54E1CBFD.7000001@redhat.com> Message-ID: <20150216120653.GG23518@ehelin.jrpg.bea.com> On 2015-02-16, Andrew Haley wrote: > On 02/16/2015 10:43 AM, Volker Simonis wrote: > > Now if we replicate this SA code one more time in a Python library for > > GDB, you'll probably agree that it can't work more reliably than the > > original SA code. This may be good enough for some use cases, but it > > won't be perfect. I'm not a gdb/DWARF expert but I think what we > > really need is to generate debug information for all the generated > > code. We need to know for every single PC of generated code the > > corresponding frame information and how to get to the previous frame. > > It would be nice. We don't actually need it, given that we've done > without for years, and generating e.g. full DWARF unwinder data for > every instruction is something that even GCC doesn't always attempt to > do. (And, of course, there's a lot of hand-written assembly code in > HotSpot. Annotating this is a significant effort.) Do we really need to use DWARF though? The gdbjit interface seems to support a custom debug format if you also implement a reader for your custom debug format. I've never done this, so I can't say if there is something missing from the gdbjit API that HotSpot requires. > On 02/16/2015 10:43 AM, Volker Simonis wrote: > > I know it's possible and I know that gdb has callbacks to consume this > > debug information which is generated at runtime (see [1]) although > > I've never programmed it myself. LLVM seems to use this technique and > > has some documentation available ([2,3]). I suppose this is the > > direction Erik wanted to go and I think that would be the right way. Yes, this is the idea I tried to explain. On 2015-02-16, Andrew Haley wrote: > It would be, long term. I've been discussing this with Red Hat's GDB > group and I'm hoping to come up with a proposal and hopefully some > working code. That would be great, I would really like to see how far we can get with a solution based on gdbjit (or something similar). Thanks for putting time into this! Thanks, Erik > Andrew. From aph at redhat.com Mon Feb 16 12:15:59 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Feb 2015 12:15:59 +0000 Subject: gdb and OpenJDK In-Reply-To: <20150216120653.GG23518@ehelin.jrpg.bea.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> <54E1CBFD.7000001@redhat.com> <20150216120653.GG23518@ehelin.jrpg.bea.com> Message-ID: <54E1DF7F.7060508@redhat.com> On 02/16/2015 12:06 PM, Erik Helin wrote: > On 2015-02-16, Andrew Haley wrote: >> On 02/16/2015 10:43 AM, Volker Simonis wrote: >>> Now if we replicate this SA code one more time in a Python library for >>> GDB, you'll probably agree that it can't work more reliably than the >>> original SA code. This may be good enough for some use cases, but it >>> won't be perfect. I'm not a gdb/DWARF expert but I think what we >>> really need is to generate debug information for all the generated >>> code. We need to know for every single PC of generated code the >>> corresponding frame information and how to get to the previous frame. >> >> It would be nice. We don't actually need it, given that we've done >> without for years, and generating e.g. full DWARF unwinder data for >> every instruction is something that even GCC doesn't always attempt to >> do. (And, of course, there's a lot of hand-written assembly code in >> HotSpot. Annotating this is a significant effort.) > > Do we really need to use DWARF though? The gdbjit interface seems to > support a custom debug format if you also implement a reader for > your custom debug format. I've never done this, so I can't say if > there is something missing from the gdbjit API that HotSpot requires. Well, it would have to be able to convey the same information as DWARF unwinder data; the GDB people tell me that generating some DWARF is the right way to do it. But of course I'm not wedded to any particular format. Andrew. From fweimer at redhat.com Mon Feb 16 12:47:58 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 16 Feb 2015 13:47:58 +0100 Subject: JEP 240: Remove the JVM TI hprof Agent In-Reply-To: <20150213004635.5F2514DB85@eggemoggin.niobe.net> References: <20150213004635.5F2514DB85@eggemoggin.niobe.net> Message-ID: <54E1E6FE.8030706@redhat.com> On 02/13/2015 01:46 AM, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/240 Removal of the hprof agent interferes with my TLS performance work. I'm not complaining (removing cruft is always a good idea), I'm just providing a data point. If I understand VisualVM correctly, it is GUI-only, so it will not work in headless deployments. I'm not convinced that many production systems allow remote management access (direct support for SSH tunneling might address this concern, though). It's sometimes a challenge to get additional software installed in a production environment?and hprof is just a command line option away. I understand that hprof is not the best JVM profiler out there, but it has been pretty useful to me. -- Florian Weimer / Red Hat Product Security From erik.helin at oracle.com Mon Feb 16 12:48:24 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 16 Feb 2015 13:48:24 +0100 Subject: gdb and OpenJDK In-Reply-To: <54E1DF7F.7060508@redhat.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> <54E1CBFD.7000001@redhat.com> <20150216120653.GG23518@ehelin.jrpg.bea.com> <54E1DF7F.7060508@redhat.com> Message-ID: <20150216124824.GH23518@ehelin.jrpg.bea.com> On 2015-02-16, Andrew Haley wrote: > On 02/16/2015 12:06 PM, Erik Helin wrote: > > On 2015-02-16, Andrew Haley wrote: > >> On 02/16/2015 10:43 AM, Volker Simonis wrote: > >>> Now if we replicate this SA code one more time in a Python library for > >>> GDB, you'll probably agree that it can't work more reliably than the > >>> original SA code. This may be good enough for some use cases, but it > >>> won't be perfect. I'm not a gdb/DWARF expert but I think what we > >>> really need is to generate debug information for all the generated > >>> code. We need to know for every single PC of generated code the > >>> corresponding frame information and how to get to the previous frame. > >> > >> It would be nice. We don't actually need it, given that we've done > >> without for years, and generating e.g. full DWARF unwinder data for > >> every instruction is something that even GCC doesn't always attempt to > >> do. (And, of course, there's a lot of hand-written assembly code in > >> HotSpot. Annotating this is a significant effort.) > > > > Do we really need to use DWARF though? The gdbjit interface seems to > > support a custom debug format if you also implement a reader for > > your custom debug format. I've never done this, so I can't say if > > there is something missing from the gdbjit API that HotSpot requires. > > Well, it would have to be able to convey the same information as DWARF > unwinder data; the GDB people tell me that generating some DWARF is > the right way to do it. But of course I'm not wedded to any > particular format. I agree that DWARF would be a very nice thing to have, it would (most likely) allow us to print names of variables, arguments etc in a frame. However, as you mentioned, making HotSpot output DWARF in-memory for the assembly it produces would be a massive effort. I guess what I wonder is, how little debug information can we get away with if we only want to traverse the stack and print the name of each frame? This is why I was interested in the support from gdbjit for a custom debug format. An alternative to using gdbjit, as mentioned earlier in this thread, would be to generate data structures (structs) at a well-known symbol/address that can easily be consumed from various plugins/tools. The reason for using such approach is to try to keep the maintenance work for each plugin/tool as low as possible. Thanks, Erik From fweimer at redhat.com Mon Feb 16 12:56:14 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 16 Feb 2015 13:56:14 +0100 Subject: gdb and OpenJDK In-Reply-To: References: Message-ID: <54E1E8EE.3060006@redhat.com> On 02/11/2015 11:27 PM, Jeremy Manson wrote: > First, gdb needed to be extended to support the ability to plug in a frame > unwinder. The process of submitting this to gdb (which has been ongoing > for quite a while) is finally starting to make reasonable progress. > > Next, we need a plugin for OpenJDK. We have a plugin written that calls > out to the serviceability agent. (It's written in Python, per gdb's > requirements). Has the license issue already come up? OpenJDK is GPL version 2 only, GDB is GPL version 3 or later. Those two are not compatible. It's typically fine if such processes communicate which each others over a pipe, but direct linking within the same address space might not be okay. I don't know enough about the technology involved here to say if this is going to cause any real problems, but I want to avoid future disappointment. -- Florian Weimer / Red Hat Product Security From neugens.limasoftware at gmail.com Mon Feb 16 15:23:50 2015 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 16 Feb 2015 16:23:50 +0100 Subject: JEP 240: Remove the JVM TI hprof Agent In-Reply-To: <54E1E6FE.8030706@redhat.com> References: <20150213004635.5F2514DB85@eggemoggin.niobe.net> <54E1E6FE.8030706@redhat.com> Message-ID: 2015-02-16 13:47 GMT+01:00 Florian Weimer : > On 02/13/2015 01:46 AM, mark.reinhold at oracle.com wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/240 > > Removal of the hprof agent interferes with my TLS performance work. I'm > not complaining (removing cruft is always a good idea), I'm just > providing a data point. > > If I understand VisualVM correctly, it is GUI-only, so it will not work > in headless deployments. I'm not convinced that many production systems > allow remote management access (direct support for SSH tunneling might > address this concern, though). It's sometimes a challenge to get > additional software installed in a production environment?and hprof is > just a command line option away. Thermostat does support that natively with the CLI interface. Also I believe Visual VM can deal with saved and exported hprof dumps, likewise MAT (and Thermostat), which is probably the most advanced at this stage - so no need to install software really. I don't think keeping the hprof agent around is really so important, and unless I'm misreading this JEP this is all about removing the sampled code, not the other tools and neither changing the hprof format. Of course, your point about installing additional software is completely valid here, all those options are separate packages, but parsing a production system hprof on the system is very resource intensive, I think it's still much better to do it remotely. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From bertrand.delsart at oracle.com Mon Feb 16 16:08:12 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Mon, 16 Feb 2015 17:08:12 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> <54B68056.3090706@oracle.com> <54B7A0C4.6040009@oracle.com> <54B7FDC9.8020103@oracle.com> Message-ID: <54E215EC.1000507@oracle.com> On 13/02/2015 23:26, Brendan Gregg wrote: > Thanks Bertrand and John for explaining the invokedynamic issue, and > Vladimir for filing the bug. > > I'll reply here (I don't have a JBS account; I would like one!). > > The profilers I'm using (Linux perf, and Solaris DTrace) can already > handle a broken RBP, and we see this all the time when profiling > OracleJDK today (eg, as a flame graph: > http://www.slideshare.net/brendangregg/netflix-from-clouds-to-roots/66). > > Including an option (eg, -XX:+NoOmitFramePointer, or > -XX:+ReduceOmitFramePointer, or -XX:+MoreFramePointer) which improved > RBP profiling (like my patch) would have great value for us. I'm fine > with a profiler not working 100% of the time, provided we understand > that there is an error margin and why (Bertrand and John's descriptions) > for when interpreting the profiles. Any of these options could also be > improved as follow-on changes, if and when needed. As long as it is clear that RBP can be misleading and that trying to fix that would be an RFE, not a bug, I have no objection. I'll let official Reviewers see whether a command line option is necessary (e.g. whether there are concerns about possible performance regressions when RBP cannot be used by the register allocator). Regards, Bertrand. > > I haven't had a chance yet to prototype more (eg, option processing). > There's also work happening in Linux (two projects on lkml this week, > one by Stephane Eranian and another by Carl Love) for improving Java JIT > symbol support in perf_events. I think there will be more demand for > system stack walking, as perf gets more symbol translation options. > > Brendan > > > > On Thu, Jan 15, 2015 at 9:50 AM, Vladimir Kozlov > > wrote: > > Thank you, Bertrand and John > > I added this conversation to the bug report. > > Thanks, > Vladimir > > > On 1/15/15 3:13 AM, Bertrand Delsart wrote: > > On 14/01/2015 20:12, John Rose wrote: > > On Jan 14, 2015, at 6:42 AM, Bertrand Delsart > > >> wrote: > > > I would not prevent the JITs from using RBP as long as > the changeset > is not sufficient to guarantee the profiling will > work... and IMHO > solving the JSR292 issue will be much more intrusive > (impacting > HotSpot stack walking code). > > > Here are some thoughts on that. > > SPARC uses L7 (L7_mh_SP_save) for the same purpose of method > handle > support as x86 uses RBP (rbp_mh_SP_save). So there's not a hard > requirement for x86 to take over RBP. > > (Deep background: This purpose, in method handle support, > is to allow > an adapter to make changes to the caller's SP. The adapter > is the > initial callee from the caller, but may change argument > shape, and > tail-calls the ultimate callee. Because it is a tail-call, > the original > caller must have a spot where his original SP can be > preserved. The > preservation works because the original caller knows he is > calling a > MH.invoke method, which requires the extra argument > preservation. The > repertoire of argument shape changes is quite small, > actually; it is not > a very general mechanism since the LF machinery was put in. > Perhaps the > whole thing could be removed somehow, by finding alternative > techniques > for the few remaining changes. OTOH, this SP-restoring > mechanism may be > helpful in doing more a general tail-call mechanism, and > perhaps in > managing int/comp mode changes more cleanly, so I'd like us > to keep it. > And document it better.) > > Any register or stack slot will do for this purpose, as long > as (i) its > value can be recovered after the MH.invoke call returns to > the caller, > and (ii) its value can be dug up somehow during stack > walking. There > are only a couple of places where stack walking code needs > to sample the > value, so they should be adjustable. > > Both x86 and SPARC use registers which are callee-save (or > "non-volatile > across calls") which satisfy properties (i) and (ii). A > standard stack > slot (addressed based on caller's RBP) would probably also > satisfy those > properties. > > A variably-positioned stack slot would also work, which > would require > registering the position in each CodeBlob. That's > unpleasant extra > detail, but it would align somewhat with the current logic > which allows > each CodeBlob (nmethod, actually) to advertise which call > sites need the > special processing (see the function > is_method_handle_return(__caller_pc)). > > I recommend reserving a dead word of space in every stack > frame that > makes MH.invoke calls, at a fixed position relative to that > frame's RBP. > > ? John > > > I perfectly agree that it is doable (and with your proposed > approach). > > I just wanted to be sure people were aware that the RFE is more > complex > than what the current changeset may suggest. We are not just taking > about reviewing and integrating a complete changeset contributed > by the > community. There is more work needed, either by the community or by > Oracle. This will require changes at least in C1 and C2 call > sequences, > in the stack walking, in the creation and sizing of compiled > frames... > > Regards, > > Bertrand. > > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rainer.jung at kippdata.de Mon Feb 16 18:10:56 2015 From: rainer.jung at kippdata.de (Rainer Jung) Date: Mon, 16 Feb 2015 19:10:56 +0100 Subject: JEP 240: Remove the JVM TI hprof Agent In-Reply-To: <54E1E6FE.8030706@redhat.com> References: <20150213004635.5F2514DB85@eggemoggin.niobe.net> <54E1E6FE.8030706@redhat.com> Message-ID: <54E232B0.1090604@kippdata.de> Am 16.02.2015 um 13:47 schrieb Florian Weimer: > On 02/13/2015 01:46 AM, mark.reinhold at oracle.com wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/240 > > Removal of the hprof agent interferes with my TLS performance work. I'm > not complaining (removing cruft is always a good idea), I'm just > providing a data point. > > If I understand VisualVM correctly, it is GUI-only, so it will not work > in headless deployments. I'm not convinced that many production systems > allow remote management access (direct support for SSH tunneling might > address this concern, though). It's sometimes a challenge to get > additional software installed in a production environment?and hprof is > just a command line option away. > > I understand that hprof is not the best JVM profiler out there, but it > has been pretty useful to me. +1, that are exactly the reasons why I use hprof. It is just there (no need to install stuff), it doesn't need a guy and I can analyze the result using simple scripting tools. I did use it very successful e.g. to optimize allocation behavior of applications. Yes, most people will prefer a GUI, but some can do harder stuff with a commandline interface, textual output and scripting. BTW: that's how I also used jhat, scripting against the http interface. Maybe Eclipse MAT can be scripted as well and I just don't know how to do it. But that's the other JEP (241), so OT here. Regards, Rainer From mandy.chung at oracle.com Mon Feb 16 23:44:37 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 16 Feb 2015 15:44:37 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> Message-ID: <54E280E5.70609@oracle.com> Hi Jeremy, On 2/9/2015 4:51 PM, Jeremy Manson wrote: > http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ > > The change looks okay to me. Nit: It would be good for the new methods to replace ... with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . Similarly Thread#getPriority. thanks Mandy From jeremymanson at google.com Tue Feb 17 17:31:41 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 17 Feb 2015 09:31:41 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <54E280E5.70609@oracle.com> References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> Message-ID: Hey Mandy, Thanks for taking a look. Are we okay making those changes even though none of the other methods in ThreadInfo follow those conventions? Not sure whether consistency matters more or less than doing it right. Jeremy On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung wrote: > Hi Jeremy, > > On 2/9/2015 4:51 PM, Jeremy Manson wrote: > >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ < >> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/> >> >> > The change looks okay to me. > > Nit: It would be good for the new methods to replace ... with > {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add > {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . > Similarly Thread#getPriority. > > thanks > Mandy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Feb 17 17:43:52 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 17 Feb 2015 10:43:52 -0700 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: References: <54D1861C.1020309@oracle.com> <54D19FF8.9060901@oracle.com> Message-ID: <54E37DD8.4050900@oracle.com> Carsten. I've started diving into this issue. Please see the updates that I've been making to: JDK-8072439 fix for 8047720 may need more work https://bugs.openjdk.java.net/browse/JDK-8072439 Dan On 2/10/15 3:18 PM, Carsten Varming wrote: > Dear David, > > Any news regarding this fix? Anything I can do to help? > > Best wishes, > Carsten > > On Wed, Feb 4, 2015 at 12:54 PM, Carsten Varming > wrote: > > Dear David, > > I took a look at all occurrences of PeriodicTask_lock. We are in luck: > > PeriodicTask::enroll and PeriodicTask::disenroll check for > safepoints when acquiring PeriodicTask_lock. > > PeriodicTask::time_to_wait and PeriodicTask::real_time_tick are > called only by the watcher thread. > > WatcherThread::unpark is used only in contexts where > PeriodicTask_lock is owned by the caller. > > WatcherThread::sleep is called only by the watcher thread. > > I took another look at WatcherThread::sleep and realized that > there is a path from acquiring PeriodicTask_lock to waiting on the > lock where _should_terminate is not checked. I added that to the > minimal fix attached. > > Looking at these methods made me want to clean up a little more. > See better.patch attached. > > I feel pretty good about the patch with the limited usage of > no_safepoint_check_flag with PeriodicTask_lock. > > Carsten > > > On Tue, Feb 3, 2015 at 11:28 PM, David Holmes > > wrote: > > On 4/02/2015 1:28 PM, Carsten Varming wrote: > > Dear David Holmes, > > Please see inline response, > > On Tue, Feb 3, 2015 at 9:38 PM, David Holmes > > >> wrote: > > On 4/02/2015 5:00 AM, Carsten Varming wrote: > > Greetings all, > > I was recently introduced to the deadlock described in > JDK-8047720 and > fixed in JDK9. The fix seems a little messy to me, > and it looks > like it > left some very short races in the code. So I > decided to clean up the > code. See attached diff. > > The change takes a step back and acquires > PeriodicTask_lock in > WatcherThread::stop (like before the fix in JDK9), > but this time > safepoints are allowed to proceed when acquiring > PeriodicTask_lock, > preventing the deadlock. > > > It isn't obvious that blocking for a safepoint whilst > in this method > will always be a safe thing to do. That would need to > be examined in > detail - potential interactions can be very subtle. > > > Absolutely true. For reference, the pattern is repeated > with the > Terminator_lock a few lines below. The pattern is also used in > Threads::destroy_vm before and after calling before_exit, > and the java > shutdown hooks are called right before the call to > before_exit. So there > is a lot of evidence that safepoints are allowed to happen > in this context. > > > The thread calling before_exit is a JavaThread so of course it > participates in safepoints. The issue is whether the > interaction between that thread and the WatcherThread, via the > PeriodicTask_lock, can allow for the JavaThread blocking at a > safepoint whilst owning that lock. If another JavaThread can > try to lock it without a safepoint check then we can get a > deadlock. > > Cheers, > David > > > Thank you for taking your time to look at this, > Carsten > > > David > > > Let me know what you think, > Carsten > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varming at gmail.com Tue Feb 17 18:09:08 2015 From: varming at gmail.com (Carsten Varming) Date: Tue, 17 Feb 2015 13:09:08 -0500 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: <54E37DD8.4050900@oracle.com> References: <54D1861C.1020309@oracle.com> <54D19FF8.9060901@oracle.com> <54E37DD8.4050900@oracle.com> Message-ID: Dear Daniel, Great news. I was reading your comments on JDK-8072439 and just want to point out the other race that my patch fixed: WatcherThread::run sees !_should_terminate, and calls sleep. WatcherThread::stop takes PeriodicTask_lock, sets _should_terminate, notify PeriodicTask_lock, and release the lock. Sleep wait forever on PeriodicTask_lock. Notice that the wait forever happens only if there are no periodic tasks scheduled, so this might not be reproducible (even with suitable sleeps), yet it is a lurking bug. Let me know if there is anything I can do to help, Carsten On Tue, Feb 17, 2015 at 12:43 PM, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Carsten. > > I've started diving into this issue. Please see the updates > that I've been making to: > > JDK-8072439 fix for 8047720 may need more work > https://bugs.openjdk.java.net/browse/JDK-8072439 > > Dan > > > On 2/10/15 3:18 PM, Carsten Varming wrote: > > Dear David, > > Any news regarding this fix? Anything I can do to help? > > Best wishes, > Carsten > > On Wed, Feb 4, 2015 at 12:54 PM, Carsten Varming > wrote: > >> Dear David, >> >> I took a look at all occurrences of PeriodicTask_lock. We are in luck: >> >> PeriodicTask::enroll and PeriodicTask::disenroll check for safepoints >> when acquiring PeriodicTask_lock. >> >> PeriodicTask::time_to_wait and PeriodicTask::real_time_tick are called >> only by the watcher thread. >> >> WatcherThread::unpark is used only in contexts where PeriodicTask_lock >> is owned by the caller. >> >> WatcherThread::sleep is called only by the watcher thread. >> >> I took another look at WatcherThread::sleep and realized that there is >> a path from acquiring PeriodicTask_lock to waiting on the lock where >> _should_terminate is not checked. I added that to the minimal fix attached. >> >> Looking at these methods made me want to clean up a little more. See >> better.patch attached. >> >> I feel pretty good about the patch with the limited usage of >> no_safepoint_check_flag with PeriodicTask_lock. >> >> Carsten >> >> >> On Tue, Feb 3, 2015 at 11:28 PM, David Holmes >> wrote: >> >>> On 4/02/2015 1:28 PM, Carsten Varming wrote: >>> >>>> Dear David Holmes, >>>> >>>> Please see inline response, >>>> >>>> On Tue, Feb 3, 2015 at 9:38 PM, David Holmes >>> > wrote: >>>> >>>> On 4/02/2015 5:00 AM, Carsten Varming wrote: >>>> >>>> Greetings all, >>>> >>>> I was recently introduced to the deadlock described in >>>> JDK-8047720 and >>>> fixed in JDK9. The fix seems a little messy to me, and it looks >>>> like it >>>> left some very short races in the code. So I decided to clean >>>> up the >>>> code. See attached diff. >>>> >>>> The change takes a step back and acquires PeriodicTask_lock in >>>> WatcherThread::stop (like before the fix in JDK9), but this time >>>> safepoints are allowed to proceed when acquiring >>>> PeriodicTask_lock, >>>> preventing the deadlock. >>>> >>>> >>>> It isn't obvious that blocking for a safepoint whilst in this method >>>> will always be a safe thing to do. That would need to be examined in >>>> detail - potential interactions can be very subtle. >>>> >>>> >>>> Absolutely true. For reference, the pattern is repeated with the >>>> Terminator_lock a few lines below. The pattern is also used in >>>> Threads::destroy_vm before and after calling before_exit, and the java >>>> shutdown hooks are called right before the call to before_exit. So there >>>> is a lot of evidence that safepoints are allowed to happen in this >>>> context. >>>> >>> >>> The thread calling before_exit is a JavaThread so of course it >>> participates in safepoints. The issue is whether the interaction between >>> that thread and the WatcherThread, via the PeriodicTask_lock, can allow for >>> the JavaThread blocking at a safepoint whilst owning that lock. If another >>> JavaThread can try to lock it without a safepoint check then we can get a >>> deadlock. >>> >>> Cheers, >>> David >>> >>> >>> Thank you for taking your time to look at this, >>>> Carsten >>>> >>>> >>>> David >>>> >>>> >>>> Let me know what you think, >>>> Carsten >>>> >>>> >>>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Feb 17 18:34:31 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 17 Feb 2015 11:34:31 -0700 Subject: Fwd: Patch: Clean up fix for JDK-8047720 In-Reply-To: References: <54D1861C.1020309@oracle.com> <54D19FF8.9060901@oracle.com> <54E37DD8.4050900@oracle.com> Message-ID: <54E389B7.1000909@oracle.com> Carsten, I believe I have all the changes that you recommended in your better.patch file. Not 100% byte-for-byte, but I think we're covered. Dan On 2/17/15 11:09 AM, Carsten Varming wrote: > Dear Daniel, > > Great news. > > I was reading your comments on JDK-8072439 and just want to point out > the other race that my patch fixed: > > WatcherThread::run sees !_should_terminate, and calls sleep. > WatcherThread::stop takes PeriodicTask_lock, sets _should_terminate, > notify PeriodicTask_lock, and release the lock. Sleep wait forever on > PeriodicTask_lock. Notice that the wait forever happens only if there > are no periodic tasks scheduled, so this might not be reproducible > (even with suitable sleeps), yet it is a lurking bug. > > Let me know if there is anything I can do to help, > Carsten > > On Tue, Feb 17, 2015 at 12:43 PM, Daniel D. Daugherty > > wrote: > > Carsten. > > I've started diving into this issue. Please see the updates > that I've been making to: > > JDK-8072439 fix for 8047720 may need more work > https://bugs.openjdk.java.net/browse/JDK-8072439 > > Dan > > > On 2/10/15 3:18 PM, Carsten Varming wrote: >> Dear David, >> >> Any news regarding this fix? Anything I can do to help? >> >> Best wishes, >> Carsten >> >> On Wed, Feb 4, 2015 at 12:54 PM, Carsten Varming >> > wrote: >> >> Dear David, >> >> I took a look at all occurrences of PeriodicTask_lock. We are >> in luck: >> >> PeriodicTask::enroll and PeriodicTask::disenroll check for >> safepoints when acquiring PeriodicTask_lock. >> >> PeriodicTask::time_to_wait and PeriodicTask::real_time_tick >> are called only by the watcher thread. >> >> WatcherThread::unpark is used only in contexts where >> PeriodicTask_lock is owned by the caller. >> >> WatcherThread::sleep is called only by the watcher thread. >> >> I took another look at WatcherThread::sleep and realized that >> there is a path from acquiring PeriodicTask_lock to waiting >> on the lock where _should_terminate is not checked. I added >> that to the minimal fix attached. >> >> Looking at these methods made me want to clean up a little >> more. See better.patch attached. >> >> I feel pretty good about the patch with the limited usage of >> no_safepoint_check_flag with PeriodicTask_lock. >> >> Carsten >> >> >> On Tue, Feb 3, 2015 at 11:28 PM, David Holmes >> > wrote: >> >> On 4/02/2015 1:28 PM, Carsten Varming wrote: >> >> Dear David Holmes, >> >> Please see inline response, >> >> On Tue, Feb 3, 2015 at 9:38 PM, David Holmes >> >> > >> wrote: >> >> On 4/02/2015 5:00 AM, Carsten Varming wrote: >> >> Greetings all, >> >> I was recently introduced to the deadlock >> described in >> JDK-8047720 and >> fixed in JDK9. The fix seems a little messy >> to me, and it looks >> like it >> left some very short races in the code. So I >> decided to clean up the >> code. See attached diff. >> >> The change takes a step back and acquires >> PeriodicTask_lock in >> WatcherThread::stop (like before the fix in >> JDK9), but this time >> safepoints are allowed to proceed when >> acquiring PeriodicTask_lock, >> preventing the deadlock. >> >> >> It isn't obvious that blocking for a safepoint >> whilst in this method >> will always be a safe thing to do. That would >> need to be examined in >> detail - potential interactions can be very subtle. >> >> >> Absolutely true. For reference, the pattern is >> repeated with the >> Terminator_lock a few lines below. The pattern is >> also used in >> Threads::destroy_vm before and after calling >> before_exit, and the java >> shutdown hooks are called right before the call to >> before_exit. So there >> is a lot of evidence that safepoints are allowed to >> happen in this context. >> >> >> The thread calling before_exit is a JavaThread so of >> course it participates in safepoints. The issue is >> whether the interaction between that thread and the >> WatcherThread, via the PeriodicTask_lock, can allow for >> the JavaThread blocking at a safepoint whilst owning that >> lock. If another JavaThread can try to lock it without a >> safepoint check then we can get a deadlock. >> >> Cheers, >> David >> >> >> Thank you for taking your time to look at this, >> Carsten >> >> >> David >> >> >> Let me know what you think, >> Carsten >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Feb 17 21:44:38 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 17 Feb 2015 14:44:38 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) Message-ID: <54E3B646.8050209@oracle.com> Greetings, My fix for the following bug: JDK-8047720 Xprof hangs on Solaris that was pushed to JDK9 last June needs to be cleaned up. Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten Varming (varming at gmail.com) for reporting the mess that I made in WatcherThread::stop() and for suggesting fixes. This code review is for a general cleanup pass on PeriodicTask_lock and some of the surrounding code. This is a targeted review in that I would like to hear from three groups of people: 1) The author and reviewers for: JDK-7127792 Add the ability to change an existing PeriodicTask's execution interval Rickard, David H, and Markus G. 2) The reviewers for: JDK-8047720 Xprof hangs on Solaris Markus G and Coleen 3) Alex and Carsten Here's the webrev URL: http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ I've attached the original RFR for JDK-8047720 that explains the original deadlock that was being fixed. Similar testing will be done with this fix. Dan -------------- next part -------------- An embedded message was scrubbed... From: "Daniel D. Daugherty" Subject: RFR (XS) fix for a safepoint deadlock (8047720) Date: Fri, 27 Jun 2014 10:18:17 -0600 Size: 3044 URL: From varming at gmail.com Tue Feb 17 22:22:16 2015 From: varming at gmail.com (Carsten Varming) Date: Tue, 17 Feb 2015 17:22:16 -0500 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E3B646.8050209@oracle.com> References: <54E3B646.8050209@oracle.com> Message-ID: Dear Daniel, Looks good to me. The line: "OrderAccess::fence(); // ensure WatcherThread sees update in main loop" seems unnecessary as the lock acts as a memory barrier. Carsten On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Greetings, > > My fix for the following bug: > > JDK-8047720 Xprof hangs on Solaris > > that was pushed to JDK9 last June needs to be cleaned up. > > Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten > Varming (varming at gmail.com) for reporting the mess that I made > in WatcherThread::stop() and for suggesting fixes. > > This code review is for a general cleanup pass on PeriodicTask_lock > and some of the surrounding code. This is a targeted review in that > I would like to hear from three groups of people: > > 1) The author and reviewers for: > > JDK-7127792 Add the ability to change an existing PeriodicTask's > execution interval > > Rickard, David H, and Markus G. > > 2) The reviewers for: > > JDK-8047720 Xprof hangs on Solaris > > Markus G and Coleen > > 3) Alex and Carsten > > > Here's the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ > > I've attached the original RFR for JDK-8047720 that explains > the original deadlock that was being fixed. Similar testing > will be done with this fix. > > Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Feb 17 22:35:01 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Feb 2015 14:35:01 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> Message-ID: <54E3C215.4030609@oracle.com> On 2/17/15 9:31 AM, Jeremy Manson wrote: > Hey Mandy, > > Thanks for taking a look. Are we okay making those changes even > though none of the other methods in ThreadInfo follow those > conventions? Not sure whether consistency matters more or less than > doing it right. I wont object and actually be grateful if you want to convert all ... to {@code ...}. Staffan may have a different opinion. Mandy > > Jeremy > > On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung > wrote: > > Hi Jeremy, > > On 2/9/2015 4:51 PM, Jeremy Manson wrote: > > http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ > > > > > The change looks okay to me. > > Nit: It would be good for the new methods to replace ... > with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be > good to add {@linkplain Thread#isDaemon daemon thread} or @see > Thread#isDaemon . Similarly Thread#getPriority. > > thanks > Mandy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Feb 17 22:42:01 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 17 Feb 2015 15:42:01 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: References: <54E3B646.8050209@oracle.com> Message-ID: <54E3C3B9.7040505@oracle.com> On 2/17/15 3:22 PM, Carsten Varming wrote: > Dear Daniel, > > Looks good to me. Thanks for the fast review. > The line: "OrderAccess::fence(); // ensure WatcherThread sees update > in main loop" seems unnecessary as the lock acts as a memory barrier. Yes, I keep looking at that line from the original work on JDK-7127792 and wonder why it's there... I'll chase that down with the original folks... Dan > > Carsten > > On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty > > wrote: > > Greetings, > > My fix for the following bug: > > JDK-8047720 Xprof hangs on Solaris > > that was pushed to JDK9 last June needs to be cleaned up. > > Thanks to Alex Garthwaite (agarthwaite at twitter.com > ) and Carsten > Varming (varming at gmail.com ) for > reporting the mess that I made > in WatcherThread::stop() and for suggesting fixes. > > This code review is for a general cleanup pass on PeriodicTask_lock > and some of the surrounding code. This is a targeted review in that > I would like to hear from three groups of people: > > 1) The author and reviewers for: > > JDK-7127792 Add the ability to change an existing PeriodicTask's > execution interval > > Rickard, David H, and Markus G. > > 2) The reviewers for: > > JDK-8047720 Xprof hangs on Solaris > > Markus G and Coleen > > 3) Alex and Carsten > > > Here's the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ > > I've attached the original RFR for JDK-8047720 that explains > the original deadlock that was being fixed. Similar testing > will be done with this fix. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Tue Feb 17 23:10:38 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 17 Feb 2015 15:10:38 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <54E3C215.4030609@oracle.com> References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> Message-ID: I don't think feature changes should be mixed with maintenance. Code janitor is the most honourable profession, and it would be awesome for a code janitor to convert the entire jdk to {@code but feature contributors should not be asked to do so. On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung wrote: > On 2/17/15 9:31 AM, Jeremy Manson wrote: > > Hey Mandy, > > Thanks for taking a look. Are we okay making those changes even though > none of the other methods in ThreadInfo follow those conventions? Not sure > whether consistency matters more or less than doing it right. > > > I wont object and actually be grateful if you want to convert all > ... to {@code ...}. Staffan may have a different opinion. > > Mandy > > > Jeremy > > On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung > wrote: > >> Hi Jeremy, >> >> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >> >>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ < >>> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/> >>> >>> >> The change looks okay to me. >> >> Nit: It would be good for the new methods to replace ... with >> {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add >> {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . >> Similarly Thread#getPriority. >> >> thanks >> Mandy >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Feb 17 23:55:39 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Feb 2015 15:55:39 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> Message-ID: <54E3D4FB.8080205@oracle.com> On 2/17/15 3:10 PM, Martin Buchholz wrote: > I don't think feature changes should be mixed with maintenance. > > Code janitor is the most honourable profession, and it would be > awesome for a code janitor to convert the entire jdk to {@code but > feature contributors should not be asked to do so. That's why I didn't ask at first :) I prefer the new javadoc to use {@code...} even though inconsistent with other methods as they were defined since 1.5. Mandy > > On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung > wrote: > > On 2/17/15 9:31 AM, Jeremy Manson wrote: >> Hey Mandy, >> >> Thanks for taking a look. Are we okay making those changes even >> though none of the other methods in ThreadInfo follow those >> conventions? Not sure whether consistency matters more or less >> than doing it right. > > I wont object and actually be grateful if you want to convert all > ... to {@code ...}. Staffan may have a different opinion. > > Mandy >> >> Jeremy >> >> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung >> > wrote: >> >> Hi Jeremy, >> >> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >> >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ >> >> >> >> The change looks okay to me. >> >> Nit: It would be good for the new methods to replace >> ... with {@code ...}. line 600, 603 {@code >> ThreadInfo}. It would be good to add {@linkplain >> Thread#isDaemon daemon thread} or @see Thread#isDaemon . >> Similarly Thread#getPriority. >> >> thanks >> Mandy >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Tue Feb 17 23:58:56 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 17 Feb 2015 15:58:56 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <54E3D4FB.8080205@oracle.com> References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> Message-ID: Since this is not my code, I will happily defer to the people whose code it is on these matters. I can very easily replace all of the instances, or just the new ones, or none at all. Just let me know. (My general preference in my own code is to separate feature changes and cleanup changes, just so that the history is more comprehensible, but I can certainly understand that you might not want to go that way when the cost of a checkin is so high.) Jeremy On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung wrote: > On 2/17/15 3:10 PM, Martin Buchholz wrote: > > I don't think feature changes should be mixed with maintenance. > > Code janitor is the most honourable profession, and it would be awesome > for a code janitor to convert the entire jdk to {@code but feature > contributors should not be asked to do so. > > > That's why I didn't ask at first :) > > I prefer the new javadoc to use {@code...} even though inconsistent with > other methods as they were defined since 1.5. > > Mandy > > > On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung > wrote: > >> On 2/17/15 9:31 AM, Jeremy Manson wrote: >> >> Hey Mandy, >> >> Thanks for taking a look. Are we okay making those changes even though >> none of the other methods in ThreadInfo follow those conventions? Not sure >> whether consistency matters more or less than doing it right. >> >> >> I wont object and actually be grateful if you want to convert all >> ... to {@code ...}. Staffan may have a different opinion. >> >> Mandy >> >> >> Jeremy >> >> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung >> wrote: >> >>> Hi Jeremy, >>> >>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>> >>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ < >>>> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/> >>>> >>>> >>> The change looks okay to me. >>> >>> Nit: It would be good for the new methods to replace ... with >>> {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add >>> {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . >>> Similarly Thread#getPriority. >>> >>> thanks >>> Mandy >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Feb 18 00:53:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Feb 2015 10:53:51 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E3C3B9.7040505@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> Message-ID: <54E3E29F.2010000@oracle.com> Hi Dan, A few comments, mainly on the comments :) On 18/02/2015 8:42 AM, Daniel D. Daugherty wrote: > On 2/17/15 3:22 PM, Carsten Varming wrote: >> Dear Daniel, >> >> Looks good to me. > > Thanks for the fast review. > >> The line: "OrderAccess::fence(); // ensure WatcherThread sees update >> in main loop" seems unnecessary as the lock acts as a memory barrier. > > Yes, I keep looking at that line from the original work on > JDK-7127792 and wonder why it's there... I'll chase that down > with the original folks... Only needed when using lock-free access, so can be removed now. java.cpp: Typo: likelyhood -> likelihood --- task.cpp 81 int PeriodicTask::time_to_wait() { 82 assert(Thread::current()->is_Watcher_thread(), "must be WatcherThread"); This is currently true but not sure it has to be true. If we are assuming/constraining a subset of the task API to only be callable by the WatcherThread then perhaps we should document that in task.hpp ? And as the WatcherThread is a friend, none of those methods need to be public - ie execute_if_pending and time_to_wait (realtime_tick is already private). 112 void PeriodicTask::enroll() { 113 // Follow normal safepoint aware lock enter protocol if the caller does 114 // not already own the PeriodicTask_lock. Otherwise, we don't try to 115 // enter it again to avoid deadlocking with a safepoint that started 116 // after the initial enter and before this enter. 117 // 118 MutexLockerEx ml(PeriodicTask_lock->owned_by_self() ? NULL 119 : PeriodicTask_lock); The deadlock is not with a safepoint interaction but the normal self-deadlock that would occur trying to lock() a Monitor/Mutex that you already own. (Monitors/Mutexes do not support recursive locking - in contrast to ObjectMonitors.) Ditto for disenroll. The original comment is the correct one with respect to acquiring with a safepoint check if not already locked: /* XXX could be called from a JavaThread, so we have to check for * safepoint when taking the lock to avoid deadlocking */ --- thread.cpp: 1198 int WatcherThread::sleep() const { 1199 // The WatcherThread does not honor the safepoint protocol for 1200 // PeriodicTask_lock in order to provide more consistent task 1201 // execution timing. Not sure that is really the correct characterisation. The WT doesn't need to honor the safepoint protocol because it isn't a JavaThread and so won't block even if a safepoint is in progress. So checking for a safepoint is simply a waste of time. 3565 MutexLocker ml(PeriodicTask_lock); Why did you allow for a safepoint check here? It would only be necessary if a JavaThread might concurrently acquire the PeriodicTask_lock and a safepoint is initiated - during VM initialization. Not completely impossible I guess but have never heard of this occurring, so would require some other startup change to trigger it. Thanks, David ----- > Dan > > >> >> Carsten >> >> On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty >> > wrote: >> >> Greetings, >> >> My fix for the following bug: >> >> JDK-8047720 Xprof hangs on Solaris >> >> that was pushed to JDK9 last June needs to be cleaned up. >> >> Thanks to Alex Garthwaite (agarthwaite at twitter.com >> ) and Carsten >> Varming (varming at gmail.com ) for >> reporting the mess that I made >> in WatcherThread::stop() and for suggesting fixes. >> >> This code review is for a general cleanup pass on PeriodicTask_lock >> and some of the surrounding code. This is a targeted review in that >> I would like to hear from three groups of people: >> >> 1) The author and reviewers for: >> >> JDK-7127792 Add the ability to change an existing PeriodicTask's >> execution interval >> >> Rickard, David H, and Markus G. >> >> 2) The reviewers for: >> >> JDK-8047720 Xprof hangs on Solaris >> >> Markus G and Coleen >> >> 3) Alex and Carsten >> >> >> Here's the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >> >> I've attached the original RFR for JDK-8047720 that explains >> the original deadlock that was being fixed. Similar testing >> will be done with this fix. >> >> Dan >> >> > From asmundak at google.com Wed Feb 18 04:15:04 2015 From: asmundak at google.com (Alexander Smundak) Date: Tue, 17 Feb 2015 20:15:04 -0800 Subject: gdb and OpenJDK In-Reply-To: <20150216124824.GH23518@ehelin.jrpg.bea.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> <54E1CBFD.7000001@redhat.com> <20150216120653.GG23518@ehelin.jrpg.bea.com> <54E1DF7F.7060508@redhat.com> <20150216124824.GH23518@ehelin.jrpg.bea.com> Message-ID: I considered and even implemented something similar to some of the proposals discussed (see https://sourceware.org/ml/gdb-patches/2013-12/msg00964.html for the attempt based on JIT reader; the discussion lasted until next June and patch was eventually rejected). It is definitely doable to generate DWARF unwind info, although it will cost you memory (about 7% of the emitted code), and DWARF symbol info, which is going to cost you a lot more memory (for the estimate, look at the size of the .debuginfo for libjvm.so). Note also that although Python has a number of drawbacks, verbosity is not one of them, so the implementation in C++ will require at least as much code. And this code not being essential for running HotSpot, its will eventually receive about as much love as SA; IMHO a better way to address this problem is to have unit tests, and this requires the same effort for Python as for SA. I will get back with the answer about license required tomorrow. On Mon, Feb 16, 2015 at 4:48 AM, Erik Helin wrote: > On 2015-02-16, Andrew Haley wrote: >> On 02/16/2015 12:06 PM, Erik Helin wrote: >> > On 2015-02-16, Andrew Haley wrote: >> >> On 02/16/2015 10:43 AM, Volker Simonis wrote: >> >>> Now if we replicate this SA code one more time in a Python library for >> >>> GDB, you'll probably agree that it can't work more reliably than the >> >>> original SA code. This may be good enough for some use cases, but it >> >>> won't be perfect. I'm not a gdb/DWARF expert but I think what we >> >>> really need is to generate debug information for all the generated >> >>> code. We need to know for every single PC of generated code the >> >>> corresponding frame information and how to get to the previous frame. >> >> >> >> It would be nice. We don't actually need it, given that we've done >> >> without for years, and generating e.g. full DWARF unwinder data for >> >> every instruction is something that even GCC doesn't always attempt to >> >> do. (And, of course, there's a lot of hand-written assembly code in >> >> HotSpot. Annotating this is a significant effort.) >> > >> > Do we really need to use DWARF though? The gdbjit interface seems to >> > support a custom debug format if you also implement a reader for >> > your custom debug format. I've never done this, so I can't say if >> > there is something missing from the gdbjit API that HotSpot requires. >> >> Well, it would have to be able to convey the same information as DWARF >> unwinder data; the GDB people tell me that generating some DWARF is >> the right way to do it. But of course I'm not wedded to any >> particular format. > > I agree that DWARF would be a very nice thing to have, it would (most > likely) allow us to print names of variables, arguments etc in a frame. > However, as you mentioned, making HotSpot output DWARF in-memory for the > assembly it produces would be a massive effort. > > I guess what I wonder is, how little debug information can we get away > with if we only want to traverse the stack and print the name of each > frame? This is why I was interested in the support from gdbjit for a > custom debug format. > > An alternative to using gdbjit, as mentioned earlier in this thread, > would be to generate data structures (structs) at a well-known > symbol/address that can easily be consumed from various plugins/tools. > The reason for using such approach is to try to keep the maintenance > work for each plugin/tool as low as possible. > > Thanks, > Erik From jaroslav.bachorik at oracle.com Wed Feb 18 08:46:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 18 Feb 2015 09:46:47 +0100 Subject: [ping] Re: RFR 8071657:JDI ObjectReferenceImpl.invokeMethod() validation fails for virtual invocations of method with declaring type being an interface In-Reply-To: <54D54487.3000706@oracle.com> References: <54D4D59D.2080807@oracle.com> <54D54487.3000706@oracle.com> Message-ID: <54E45177.1040906@oracle.com> Thanks, Serguei! May I have a (R)eviewer to take a look at this, please? -JB- On 6.2.2015 23:47, serguei.spitsyn at oracle.com wrote: > The fix looks good. > > Thanks, > Serguei > > On 2/6/15 6:54 AM, Jaroslav Bachorik wrote: >> Please, review the following change in JDI implementation >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8071657 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8071657/webrev.00 >> >> After JDK-8042123 has been integrated it became possible to make >> non-virtual calls to interface default or static methods via JDI. >> >> Unfortunately, when a virtual invocation of a method with its >> declaring type being an interface is attempted it fails validation. >> The code fails to distinguish virtual and non-virtual calls and always >> fails for non-default methods. >> >> The solution is to check to check for the call being non-virtual >> before enforcing the method to be default. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Wed Feb 18 09:09:48 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 18 Feb 2015 10:09:48 +0100 Subject: RFR 8071657:JDI ObjectReferenceImpl.invokeMethod() validation fails for virtual invocations of method with declaring type being an interface In-Reply-To: <54D4D59D.2080807@oracle.com> References: <54D4D59D.2080807@oracle.com> Message-ID: InterfaceMethodsTest.java:386 Is the ObjectReference.INVOKE_SINGLE_THREADED really needed or should you just pass 0 here? Thanks, /Staffan > On 6 feb 2015, at 15:54, Jaroslav Bachorik wrote: > > Please, review the following change in JDI implementation > > Issue : https://bugs.openjdk.java.net/browse/JDK-8071657 > Webrev: http://cr.openjdk.java.net/~jbachorik/8071657/webrev.00 > > After JDK-8042123 has been integrated it became possible to make non-virtual calls to interface default or static methods via JDI. > > Unfortunately, when a virtual invocation of a method with its declaring type being an interface is attempted it fails validation. The code fails to distinguish virtual and non-virtual calls and always fails for non-default methods. > > The solution is to check to check for the call being non-virtual before enforcing the method to be default. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Feb 18 09:23:30 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 18 Feb 2015 10:23:30 +0100 Subject: RFR 8071657:JDI ObjectReferenceImpl.invokeMethod() validation fails for virtual invocations of method with declaring type being an interface In-Reply-To: References: <54D4D59D.2080807@oracle.com> Message-ID: <54E45A12.5090808@oracle.com> On 18.2.2015 10:09, Staffan Larsen wrote: > InterfaceMethodsTest.java:386 Is the ObjectReference.INVOKE_SINGLE_THREADED really needed or should you just pass 0 here? The test is single-threaded so it shouldn't make a difference. But on the other hand this limitation to INVOKE_SINGLE_THREADED is not really necessary. -JB- > > Thanks, > /Staffan > >> On 6 feb 2015, at 15:54, Jaroslav Bachorik wrote: >> >> Please, review the following change in JDI implementation >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8071657 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8071657/webrev.00 >> >> After JDK-8042123 has been integrated it became possible to make non-virtual calls to interface default or static methods via JDI. >> >> Unfortunately, when a virtual invocation of a method with its declaring type being an interface is attempted it fails validation. The code fails to distinguish virtual and non-virtual calls and always fails for non-default methods. >> >> The solution is to check to check for the call being non-virtual before enforcing the method to be default. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Wed Feb 18 09:36:46 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 18 Feb 2015 10:36:46 +0100 Subject: RFR 8071657:JDI ObjectReferenceImpl.invokeMethod() validation fails for virtual invocations of method with declaring type being an interface In-Reply-To: <54E45A12.5090808@oracle.com> References: <54D4D59D.2080807@oracle.com> <54E45A12.5090808@oracle.com> Message-ID: > On 18 feb 2015, at 10:23, Jaroslav Bachorik wrote: > > On 18.2.2015 10:09, Staffan Larsen wrote: >> InterfaceMethodsTest.java:386 Is the ObjectReference.INVOKE_SINGLE_THREADED really needed or should you just pass 0 here? > > The test is single-threaded so it shouldn't make a difference. But on the other hand this limitation to INVOKE_SINGLE_THREADED is not really necessary. Yeah, I agree. It?s just confusing why the option is there in one case, but not in the other. Replace it will 0 and consider it reviewed! /Staffan > > -JB- > >> >> Thanks, >> /Staffan >> >>> On 6 feb 2015, at 15:54, Jaroslav Bachorik wrote: >>> >>> Please, review the following change in JDI implementation >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071657 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071657/webrev.00 >>> >>> After JDK-8042123 has been integrated it became possible to make non-virtual calls to interface default or static methods via JDI. >>> >>> Unfortunately, when a virtual invocation of a method with its declaring type being an interface is attempted it fails validation. The code fails to distinguish virtual and non-virtual calls and always fails for non-default methods. >>> >>> The solution is to check to check for the call being non-virtual before enforcing the method to be default. >>> >>> Thanks, >>> >>> -JB- >> > From staffan.larsen at oracle.com Wed Feb 18 09:49:58 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 18 Feb 2015 10:49:58 +0100 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> Message-ID: <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> > On 18 feb 2015, at 00:58, Jeremy Manson wrote: > > Since this is not my code, I will happily defer to the people whose code it is on these matters. I can very easily replace all of the instances, or just the new ones, or none at all. Just let me know. I would be grateful if you took the time to convert all of them, but I will also understand if you don?t want to. > > (My general preference in my own code is to separate feature changes and cleanup changes, just so that the history is more comprehensible, but I can certainly understand that you might not want to go that way when the cost of a checkin is so high.) Agree that cost of checkin is high? /Staffan > > Jeremy > > On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung > wrote: > On 2/17/15 3:10 PM, Martin Buchholz wrote: >> I don't think feature changes should be mixed with maintenance. >> >> Code janitor is the most honourable profession, and it would be awesome for a code janitor to convert the entire jdk to {@code but feature contributors should not be asked to do so. > > That's why I didn't ask at first :) > > I prefer the new javadoc to use {@code...} even though inconsistent with other methods as they were defined since 1.5. > > Mandy >> >> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung > wrote: >> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>> Hey Mandy, >>> >>> Thanks for taking a look. Are we okay making those changes even though none of the other methods in ThreadInfo follow those conventions? Not sure whether consistency matters more or less than doing it right. >> >> I wont object and actually be grateful if you want to convert all ... to {@code ...}. Staffan may have a different opinion. >> >> Mandy >>> >>> Jeremy >>> >>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung > wrote: >>> Hi Jeremy, >>> >>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ > >>> >>> >>> The change looks okay to me. >>> >>> Nit: It would be good for the new methods to replace ... with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . Similarly Thread#getPriority. >>> >>> thanks >>> Mandy >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Feb 18 16:28:37 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 18 Feb 2015 09:28:37 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E3E29F.2010000@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <54E3E29F.2010000@oracle.com> Message-ID: <54E4BDB5.8080305@oracle.com> David, Thanks for the fast review! Replies embedded below... On 2/17/15 5:53 PM, David Holmes wrote: > Hi Dan, > > A few comments, mainly on the comments :) Apropos since the changeset is mostly comments... > > On 18/02/2015 8:42 AM, Daniel D. Daugherty wrote: >> On 2/17/15 3:22 PM, Carsten Varming wrote: >>> Dear Daniel, >>> >>> Looks good to me. >> >> Thanks for the fast review. >> >>> The line: "OrderAccess::fence(); // ensure WatcherThread sees update >>> in main loop" seems unnecessary as the lock acts as a memory barrier. >> >> Yes, I keep looking at that line from the original work on >> JDK-7127792 and wonder why it's there... I'll chase that down >> with the original folks... > > Only needed when using lock-free access, so can be removed now. Yes, that will be the likely outcome. However, the original code added by JDK-7127792 wasn't lock-free so I still want to chase down the original thinking. > java.cpp: > > Typo: likelyhood -> likelihood Fixed. > --- > > task.cpp > > 81 int PeriodicTask::time_to_wait() { > 82 assert(Thread::current()->is_Watcher_thread(), "must be > WatcherThread"); > > This is currently true but not sure it has to be true. If we are > assuming/constraining a subset of the task API to only be callable by > the WatcherThread then perhaps we should document that in task.hpp ? > And as the WatcherThread is a friend, none of those methods need to be > public - ie execute_if_pending and time_to_wait (realtime_tick is > already private). I was too focused on adding asserts that enforced how it works today and not on how it might be used down the road. There's no reason to restrict the caller of time_to_wait() to the WatcherThread. I've deleted the assert on line 82 and I added a comment to task.hpp: // Requires the PeriodicTask_lock. static int time_to_wait(); By leaving time_to_wait() public, that allows code other than the WatcherThread to use it perhaps for debugging... > 112 void PeriodicTask::enroll() { > 113 // Follow normal safepoint aware lock enter protocol if the > caller does > 114 // not already own the PeriodicTask_lock. Otherwise, we don't > try to > 115 // enter it again to avoid deadlocking with a safepoint that > started > 116 // after the initial enter and before this enter. > 117 // > 118 MutexLockerEx ml(PeriodicTask_lock->owned_by_self() ? NULL > 119 : > PeriodicTask_lock); > > The deadlock is not with a safepoint interaction but the normal > self-deadlock that would occur trying to lock() a Monitor/Mutex that > you already own. (Monitors/Mutexes do not support recursive locking - > in contrast to ObjectMonitors.) Ditto for disenroll. I have been working on Java Monitors for waaaayyyy too long! In the header comment for src/share/vm/runtime/mutex.cpp: // Native Monitors do *not* support nesting or recursion but ... > The original comment is the correct one with respect to acquiring with > a safepoint check if not already locked: > > /* XXX could be called from a JavaThread, so we have to check for > * safepoint when taking the lock to avoid deadlocking */ I'm still not fond of that comment. Perhaps: // Follow normal safepoint aware lock enter protocol if the caller does // not already own the PeriodicTask_lock. Otherwise, we don't try to // enter it again because VM internal Mutexes do not support recursion. I'm trying to make it clear that we're following safepoint aware protocol even though we're using MutexLockerEx. I also wanted a clear statement about why we skipped the enter if we already owned the lock. I don't think that we could be called from a JavaThread to be the important part. > --- > > thread.cpp: > > 1198 int WatcherThread::sleep() const { > 1199 // The WatcherThread does not honor the safepoint protocol for > 1200 // PeriodicTask_lock in order to provide more consistent task > 1201 // execution timing. > > Not sure that is really the correct characterisation. The WT doesn't > need to honor the safepoint protocol because it isn't a JavaThread and > so won't block even if a safepoint is in progress. So checking for a > safepoint is simply a waste of time. Much better way of putting it. Thanks! How about: // The WatcherThread is not a JavaThread so we do not honor the // safepoint protocol for the PeriodicTask_lock. > > 3565 MutexLocker ml(PeriodicTask_lock); > > Why did you allow for a safepoint check here? It would only be > necessary if a JavaThread might concurrently acquire the > PeriodicTask_lock and a safepoint is initiated - during VM > initialization. Not completely impossible I guess but have never heard > of this occurring, so would require some other startup change to > trigger it. There's no good reason to use MutexLockerEx here and I didn't want to write a comment explaining why we were using one. Earlier code in Threads::create_vm() uses MutexLocker instead of MutexLockerEx. Thanks again for the very thorough review! Dan > > Thanks, > David > ----- > >> Dan >> >> >>> >>> Carsten >>> >>> On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty >>> > >>> wrote: >>> >>> Greetings, >>> >>> My fix for the following bug: >>> >>> JDK-8047720 Xprof hangs on Solaris >>> >>> that was pushed to JDK9 last June needs to be cleaned up. >>> >>> Thanks to Alex Garthwaite (agarthwaite at twitter.com >>> ) and Carsten >>> Varming (varming at gmail.com ) for >>> reporting the mess that I made >>> in WatcherThread::stop() and for suggesting fixes. >>> >>> This code review is for a general cleanup pass on PeriodicTask_lock >>> and some of the surrounding code. This is a targeted review in that >>> I would like to hear from three groups of people: >>> >>> 1) The author and reviewers for: >>> >>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>> execution interval >>> >>> Rickard, David H, and Markus G. >>> >>> 2) The reviewers for: >>> >>> JDK-8047720 Xprof hangs on Solaris >>> >>> Markus G and Coleen >>> >>> 3) Alex and Carsten >>> >>> >>> Here's the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>> >>> >>> I've attached the original RFR for JDK-8047720 that explains >>> the original deadlock that was being fixed. Similar testing >>> will be done with this fix. >>> >>> Dan >>> >>> >> From daniel.daugherty at oracle.com Wed Feb 18 17:00:37 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 18 Feb 2015 10:00:37 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E3B646.8050209@oracle.com> References: <54E3B646.8050209@oracle.com> Message-ID: <54E4C535.5060506@oracle.com> Greetings, Here is an updated webrev after addressing David H's comments: http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ Also, here is the bug's URL: JDK-8072439 fix for 8047720 may need more work https://bugs.openjdk.java.net/browse/JDK-8072439 Update for testing: I'm taking the new Remote Build and Test (RBT) system for a ride during its beta period so I won't be doing direct Aurora Adhoc jobs... Dan On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: > Greetings, > > My fix for the following bug: > > JDK-8047720 Xprof hangs on Solaris > > that was pushed to JDK9 last June needs to be cleaned up. > > Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten > Varming (varming at gmail.com) for reporting the mess that I made > in WatcherThread::stop() and for suggesting fixes. > > This code review is for a general cleanup pass on PeriodicTask_lock > and some of the surrounding code. This is a targeted review in that > I would like to hear from three groups of people: > > 1) The author and reviewers for: > > JDK-7127792 Add the ability to change an existing PeriodicTask's > execution interval > > Rickard, David H, and Markus G. > > 2) The reviewers for: > > JDK-8047720 Xprof hangs on Solaris > > Markus G and Coleen > > 3) Alex and Carsten > > > Here's the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ > > I've attached the original RFR for JDK-8047720 that explains > the original deadlock that was being fixed. Similar testing > will be done with this fix. > > Dan From jeremymanson at google.com Wed Feb 18 19:10:49 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 18 Feb 2015 11:10:49 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> Message-ID: Done. http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/ Jeremy On Wed, Feb 18, 2015 at 1:49 AM, Staffan Larsen wrote: > > On 18 feb 2015, at 00:58, Jeremy Manson wrote: > > Since this is not my code, I will happily defer to the people whose code > it is on these matters. I can very easily replace all of the > instances, or just the new ones, or none at all. Just let me know. > > > I would be grateful if you took the time to convert all of them, but I > will also understand if you don?t want to. > > > (My general preference in my own code is to separate feature changes and > cleanup changes, just so that the history is more comprehensible, but I can > certainly understand that you might not want to go that way when the cost > of a checkin is so high.) > > > Agree that cost of checkin is high? > > /Staffan > > > Jeremy > > On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung > wrote: > >> On 2/17/15 3:10 PM, Martin Buchholz wrote: >> >> I don't think feature changes should be mixed with maintenance. >> >> Code janitor is the most honourable profession, and it would be awesome >> for a code janitor to convert the entire jdk to {@code but feature >> contributors should not be asked to do so. >> >> >> That's why I didn't ask at first :) >> >> I prefer the new javadoc to use {@code...} even though inconsistent with >> other methods as they were defined since 1.5. >> >> Mandy >> >> >> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung >> wrote: >> >>> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>> >>> Hey Mandy, >>> >>> Thanks for taking a look. Are we okay making those changes even >>> though none of the other methods in ThreadInfo follow those conventions? >>> Not sure whether consistency matters more or less than doing it right. >>> >>> >>> I wont object and actually be grateful if you want to convert all >>> ... to {@code ...}. Staffan may have a different opinion. >>> >>> Mandy >>> >>> >>> Jeremy >>> >>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung >>> wrote: >>> >>>> Hi Jeremy, >>>> >>>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>>> >>>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ < >>>>> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/> >>>>> >>>>> >>>> The change looks okay to me. >>>> >>>> Nit: It would be good for the new methods to replace ... with >>>> {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add >>>> {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . >>>> Similarly Thread#getPriority. >>>> >>>> thanks >>>> Mandy >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Feb 19 02:02:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 12:02:45 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E4BDB5.8080305@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <54E3E29F.2010000@oracle.com> <54E4BDB5.8080305@oracle.com> Message-ID: <54E54445.4030506@oracle.com> Hi Dan, On 19/02/2015 2:28 AM, Daniel D. Daugherty wrote: > David, > > Thanks for the fast review! Replies embedded below... > > > On 2/17/15 5:53 PM, David Holmes wrote: >> Hi Dan, >> >> A few comments, mainly on the comments :) > > Apropos since the changeset is mostly comments... > > >> >> On 18/02/2015 8:42 AM, Daniel D. Daugherty wrote: >>> On 2/17/15 3:22 PM, Carsten Varming wrote: >>>> Dear Daniel, >>>> >>>> Looks good to me. >>> >>> Thanks for the fast review. >>> >>>> The line: "OrderAccess::fence(); // ensure WatcherThread sees update >>>> in main loop" seems unnecessary as the lock acts as a memory barrier. >>> >>> Yes, I keep looking at that line from the original work on >>> JDK-7127792 and wonder why it's there... I'll chase that down >>> with the original folks... >> >> Only needed when using lock-free access, so can be removed now. Oops - my bad! > Yes, that will be the likely outcome. > > However, the original code added by JDK-7127792 wasn't lock-free so > I still want to chase down the original thinking. The lock-free code was here: void WatcherThread::run() { assert(this == watcher_thread(), "just checking"); this->record_stack_base_and_size(); this->initialize_thread_local_storage(); this->set_active_handles(JNIHandleBlock::allocate_block()); while(!_should_terminate) { and of course you still have a lock-free access in the new code: 1300 if (_should_terminate) { 1301 // check for termination before posting the next tick 1302 break; 1303 } so the fence() could stay, but its omission would be harmless I think because not seeing the update immediately is no different to having the update happen just after the check - it's racy code. The only other option would be to always access _should_terminate with the PeriodicTask_lock held - but that is subverting the intent of the lock somewhat as _should_terminate is part of the WatcherThread state. Actually the more I look at this the more I think the lock has already been subverted to assist with the WT termination protocol. > >> java.cpp: >> >> Typo: likelyhood -> likelihood > > Fixed. > > >> --- >> >> task.cpp >> >> 81 int PeriodicTask::time_to_wait() { >> 82 assert(Thread::current()->is_Watcher_thread(), "must be >> WatcherThread"); >> >> This is currently true but not sure it has to be true. If we are >> assuming/constraining a subset of the task API to only be callable by >> the WatcherThread then perhaps we should document that in task.hpp ? >> And as the WatcherThread is a friend, none of those methods need to be >> public - ie execute_if_pending and time_to_wait (realtime_tick is >> already private). > > I was too focused on adding asserts that enforced how it works today > and not on how it might be used down the road. There's no reason to > restrict the caller of time_to_wait() to the WatcherThread. I've > deleted the assert on line 82 and I added a comment to task.hpp: > > // Requires the PeriodicTask_lock. > static int time_to_wait(); > > By leaving time_to_wait() public, that allows code other than the > WatcherThread to use it perhaps for debugging... Okay. I still think the API is somewhat confused about its public interface - execute_if_pending should be protected for use by WT only (and subclasses implement it of course). > >> 112 void PeriodicTask::enroll() { >> 113 // Follow normal safepoint aware lock enter protocol if the >> caller does >> 114 // not already own the PeriodicTask_lock. Otherwise, we don't >> try to >> 115 // enter it again to avoid deadlocking with a safepoint that >> started >> 116 // after the initial enter and before this enter. >> 117 // >> 118 MutexLockerEx ml(PeriodicTask_lock->owned_by_self() ? NULL >> 119 : >> PeriodicTask_lock); >> >> The deadlock is not with a safepoint interaction but the normal >> self-deadlock that would occur trying to lock() a Monitor/Mutex that >> you already own. (Monitors/Mutexes do not support recursive locking - >> in contrast to ObjectMonitors.) Ditto for disenroll. > > I have been working on Java Monitors for waaaayyyy too long! :) > In the header comment for src/share/vm/runtime/mutex.cpp: > > // Native Monitors do *not* support nesting or recursion but ... > > >> The original comment is the correct one with respect to acquiring with >> a safepoint check if not already locked: >> >> /* XXX could be called from a JavaThread, so we have to check for >> * safepoint when taking the lock to avoid deadlocking */ > > I'm still not fond of that comment. Perhaps: > > // Follow normal safepoint aware lock enter protocol if the caller does > // not already own the PeriodicTask_lock. Otherwise, we don't try to > // enter it again because VM internal Mutexes do not support recursion. > > I'm trying to make it clear that we're following safepoint aware protocol > even though we're using MutexLockerEx. I also wanted a clear statement > about why we skipped the enter if we already owned the lock. I don't > think that we could be called from a JavaThread to be the important part. Being a JavaThread is the only reason the safepoint protocol has to be considered - for non-JavaThreads we won't look at the safepoint state. The enroll() and disenroll() methods are called from the JavaThreads and they can not be considered "leaf" methods, so they must obey the safepoint protocol wrt the lock. Anyway your comment is fine. > >> --- >> >> thread.cpp: >> >> 1198 int WatcherThread::sleep() const { >> 1199 // The WatcherThread does not honor the safepoint protocol for >> 1200 // PeriodicTask_lock in order to provide more consistent task >> 1201 // execution timing. >> >> Not sure that is really the correct characterisation. The WT doesn't >> need to honor the safepoint protocol because it isn't a JavaThread and >> so won't block even if a safepoint is in progress. So checking for a >> safepoint is simply a waste of time. > > Much better way of putting it. Thanks! How about: > > // The WatcherThread is not a JavaThread so we do not honor the > // safepoint protocol for the PeriodicTask_lock. Ok. > >> >> 3565 MutexLocker ml(PeriodicTask_lock); >> >> Why did you allow for a safepoint check here? It would only be >> necessary if a JavaThread might concurrently acquire the >> PeriodicTask_lock and a safepoint is initiated - during VM >> initialization. Not completely impossible I guess but have never heard >> of this occurring, so would require some other startup change to >> trigger it. > > There's no good reason to use MutexLockerEx here and I didn't > want to write a comment explaining why we were using one. > Earlier code in Threads::create_vm() uses MutexLocker instead > of MutexLockerEx. Okay. Change is harmless. Cheers, David > > Thanks again for the very thorough review! > > Dan > > >> >> Thanks, >> David >> ----- >> >>> Dan >>> >>> >>>> >>>> Carsten >>>> >>>> On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty >>>> > >>>> wrote: >>>> >>>> Greetings, >>>> >>>> My fix for the following bug: >>>> >>>> JDK-8047720 Xprof hangs on Solaris >>>> >>>> that was pushed to JDK9 last June needs to be cleaned up. >>>> >>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com >>>> ) and Carsten >>>> Varming (varming at gmail.com ) for >>>> reporting the mess that I made >>>> in WatcherThread::stop() and for suggesting fixes. >>>> >>>> This code review is for a general cleanup pass on PeriodicTask_lock >>>> and some of the surrounding code. This is a targeted review in that >>>> I would like to hear from three groups of people: >>>> >>>> 1) The author and reviewers for: >>>> >>>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>>> execution interval >>>> >>>> Rickard, David H, and Markus G. >>>> >>>> 2) The reviewers for: >>>> >>>> JDK-8047720 Xprof hangs on Solaris >>>> >>>> Markus G and Coleen >>>> >>>> 3) Alex and Carsten >>>> >>>> >>>> Here's the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>> >>>> >>>> I've attached the original RFR for JDK-8047720 that explains >>>> the original deadlock that was being fixed. Similar testing >>>> will be done with this fix. >>>> >>>> Dan >>>> >>>> >>> > From asmundak at google.com Thu Feb 19 03:00:53 2015 From: asmundak at google.com (Alexander Smundak) Date: Wed, 18 Feb 2015 19:00:53 -0800 Subject: gdb and OpenJDK In-Reply-To: <54E1E8EE.3060006@redhat.com> References: <54E1E8EE.3060006@redhat.com> Message-ID: According to two people I talked to (one of them is GDB developer, another GCC developer with lawyer education), running Python code by the interpreter embedded in GDB does not constitute linking, so distributing Python plugin carrying GPLv2 copyright is OK. On Mon, Feb 16, 2015 at 4:56 AM, Florian Weimer wrote: > On 02/11/2015 11:27 PM, Jeremy Manson wrote: >> First, gdb needed to be extended to support the ability to plug in a frame >> unwinder. The process of submitting this to gdb (which has been ongoing >> for quite a while) is finally starting to make reasonable progress. >> >> Next, we need a plugin for OpenJDK. We have a plugin written that calls >> out to the serviceability agent. (It's written in Python, per gdb's >> requirements). > > Has the license issue already come up? OpenJDK is GPL version 2 only, > GDB is GPL version 3 or later. Those two are not compatible. It's > typically fine if such processes communicate which each others over a > pipe, but direct linking within the same address space might not be okay. > > I don't know enough about the technology involved here to say if this is > going to cause any real problems, but I want to avoid future disappointment. > > -- > Florian Weimer / Red Hat Product Security From serguei.spitsyn at oracle.com Thu Feb 19 05:45:40 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 18 Feb 2015 21:45:40 -0800 Subject: RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale Message-ID: <54E57884.8030200@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8046246 Open hotspot webrevs: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ Open jdk (new unit test) webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ Summary: This performance/scalability issue in class redefinition was reported by HP and the Enterprise Manager team. The following variants of the adjust_method_entries() functions do not scale: ConstantPoolCache::adjust_method_entries() klassVtable::adjust_method_entries() klassItable::adjust_method_entries() InstanceKlass::adjust_default_methods() The ConstantPoolCache::adjust_method_entries() is the most important. The approach is to use the holder->method_with_idnum() like this: Method* new_method = holder->method_with_idnum(old_method->orig_method_idnum()); if (old_method != new_method) { } New algorithm has effectiveness O(M) instead of original O(M^2), where M is count of methods in the class. The new test (see webrev above) was used to mesure CPU time consumed by the ConstantPoolCache::adjust_method_entries() in both original and new approach. The performance numbers are: --------------------------------------------------------------------------------------- Methods: ------ 1,000 --------------- 10,000 ----------------- 20,000 --------------------------------------------------------------------------------------- Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) 243,000,000 nsec (~400x) New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 nsec (~20x) --------------------------------------------------------------------------------------- Testing: In progress: VM SQE RedefineClasses tests, JTREG java/lang/instrument, com/sun/jdi tests Thanks, Serguei From kellyohair at gmail.com Thu Feb 19 16:47:13 2015 From: kellyohair at gmail.com (Kelly O'Hair) Date: Thu, 19 Feb 2015 08:47:13 -0800 Subject: gdb and OpenJDK In-Reply-To: References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> <54E1CBFD.7000001@redhat.com> <20150216120653.GG23518@ehelin.jrpg.bea.com> <54E1DF7F.7060508@redhat.com> <20150216124824.GH23518@ehelin.jrpg.bea.com> Message-ID: <6EED1F7A-E24C-4A2E-9022-A6EFA91F9EE4@gmail.com> I spent a great deal of time with native object file debugging formats. But the size of the Dwarf .debuginfo section of a .so file should not be used as a measure of the debug info size for a single object file. Back when I worked with the older Stabs debug format (a less structured format), the Dwarf format was generally smaller in a single object file (.o file) than Stabs. The Stabs format benefited from a link time compression that made the resulting shared object files smaller by merging together common type information coming from the .o files. I'm pretty sure that the equivalent compression for Dwarf at link time never materialized, but I may be wrong. In any case, using a standard format for debug info, like Dwarf, would probably yield benefits. The Dwarf format is also customizable, you can create your own tags/attributes, that any Dwarf parser will know how to parse, and ignore or interpret. Defining yet a new debugging format might sound like a fun project, but I think the Dwarf standard was created by quite a few smart debugging experts, and I would not dismiss it too quickly. Some kind of customized Dwarf format could provide benefits to any debugger that is capable of parsing Dwarf already. Just my 2 cents. -kto On Feb 17, 2015, at 8:15 PM, Alexander Smundak wrote: > I considered and even implemented something similar to some of the proposals > discussed (see https://sourceware.org/ml/gdb-patches/2013-12/msg00964.html > for the attempt based on JIT reader; the discussion lasted until next June and > patch was eventually rejected). > It is definitely doable to generate DWARF unwind info, although it will cost you > memory (about 7% of the emitted code), and DWARF symbol info, which is going > to cost you a lot more memory (for the estimate, look at the size of > the .debuginfo > for libjvm.so). > Note also that although Python has a number of drawbacks, verbosity is not one > of them, so the implementation in C++ will require at least as much > code. And this > code not being essential for running HotSpot, its will eventually > receive about as > much love as SA; IMHO a better way to address this problem is to have > unit tests, > and this requires the same effort for Python as for SA. > I will get back with the answer about license required tomorrow. > > On Mon, Feb 16, 2015 at 4:48 AM, Erik Helin wrote: >> On 2015-02-16, Andrew Haley wrote: >>> On 02/16/2015 12:06 PM, Erik Helin wrote: >>>> On 2015-02-16, Andrew Haley wrote: >>>>> On 02/16/2015 10:43 AM, Volker Simonis wrote: >>>>>> Now if we replicate this SA code one more time in a Python library for >>>>>> GDB, you'll probably agree that it can't work more reliably than the >>>>>> original SA code. This may be good enough for some use cases, but it >>>>>> won't be perfect. I'm not a gdb/DWARF expert but I think what we >>>>>> really need is to generate debug information for all the generated >>>>>> code. We need to know for every single PC of generated code the >>>>>> corresponding frame information and how to get to the previous frame. >>>>> >>>>> It would be nice. We don't actually need it, given that we've done >>>>> without for years, and generating e.g. full DWARF unwinder data for >>>>> every instruction is something that even GCC doesn't always attempt to >>>>> do. (And, of course, there's a lot of hand-written assembly code in >>>>> HotSpot. Annotating this is a significant effort.) >>>> >>>> Do we really need to use DWARF though? The gdbjit interface seems to >>>> support a custom debug format if you also implement a reader for >>>> your custom debug format. I've never done this, so I can't say if >>>> there is something missing from the gdbjit API that HotSpot requires. >>> >>> Well, it would have to be able to convey the same information as DWARF >>> unwinder data; the GDB people tell me that generating some DWARF is >>> the right way to do it. But of course I'm not wedded to any >>> particular format. >> >> I agree that DWARF would be a very nice thing to have, it would (most >> likely) allow us to print names of variables, arguments etc in a frame. >> However, as you mentioned, making HotSpot output DWARF in-memory for the >> assembly it produces would be a massive effort. >> >> I guess what I wonder is, how little debug information can we get away >> with if we only want to traverse the stack and print the name of each >> frame? This is why I was interested in the support from gdbjit for a >> custom debug format. >> >> An alternative to using gdbjit, as mentioned earlier in this thread, >> would be to generate data structures (structs) at a well-known >> symbol/address that can easily be consumed from various plugins/tools. >> The reason for using such approach is to try to keep the maintenance >> work for each plugin/tool as low as possible. >> >> Thanks, >> Erik From mandy.chung at oracle.com Thu Feb 19 19:01:49 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Feb 2015 11:01:49 -0800 Subject: Review Request: 8062750 Separate SNMP messages from sun.management.resources.agent Message-ID: <54E6331D.2040204@oracle.com> This removes the SNMP messages from the sun.management.resources.agent resource bundle: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8062750/webrev.00/ thanks Mandy From daniel.fuchs at oracle.com Thu Feb 19 19:15:14 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 19 Feb 2015 20:15:14 +0100 Subject: Review Request: 8062750 Separate SNMP messages from sun.management.resources.agent In-Reply-To: <54E6331D.2040204@oracle.com> References: <54E6331D.2040204@oracle.com> Message-ID: <54E63642.5010105@oracle.com> Looks good Mandy! -- daniel On 19/02/15 20:01, Mandy Chung wrote: > This removes the SNMP messages from the sun.management.resources.agent > resource bundle: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8062750/webrev.00/ > > thanks > Mandy From Alan.Bateman at oracle.com Thu Feb 19 19:23:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Feb 2015 19:23:50 +0000 Subject: Review Request: 8062750 Separate SNMP messages from sun.management.resources.agent In-Reply-To: <54E6331D.2040204@oracle.com> References: <54E6331D.2040204@oracle.com> Message-ID: <54E63846.2050504@oracle.com> On 19/02/2015 19:01, Mandy Chung wrote: > This removes the SNMP messages from the sun.management.resources.agent > resource bundle: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8062750/webrev.00/ > This looks good. -Alan From asmundak at google.com Thu Feb 19 19:47:26 2015 From: asmundak at google.com (Alexander Smundak) Date: Thu, 19 Feb 2015 11:47:26 -0800 Subject: gdb and OpenJDK In-Reply-To: <54E1CBFD.7000001@redhat.com> References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> <54E1CBFD.7000001@redhat.com> Message-ID: On Mon, Feb 16, 2015 at 2:52 AM, Andrew Haley wrote: > It would be, long term. I've been discussing this with Red Hat's GDB > group and I'm hoping to come up with a proposal and hopefully some > working code. I have the enabling patch to GDB being reviewed at a glacial pace (see https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html). Perhaps Red Hat's GDB group can respond there? From daniel.daugherty at oracle.com Thu Feb 19 23:03:22 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 19 Feb 2015 16:03:22 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E54445.4030506@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <54E3E29F.2010000@oracle.com> <54E4BDB5.8080305@oracle.com> <54E54445.4030506@oracle.com> Message-ID: <54E66BBA.80401@oracle.com> On 2/18/15 7:02 PM, David Holmes wrote: > Hi Dan, > > On 19/02/2015 2:28 AM, Daniel D. Daugherty wrote: >> David, >> >> Thanks for the fast review! Replies embedded below... >> >> >> On 2/17/15 5:53 PM, David Holmes wrote: >>> Hi Dan, >>> >>> A few comments, mainly on the comments :) >> >> Apropos since the changeset is mostly comments... >> >> >>> >>> On 18/02/2015 8:42 AM, Daniel D. Daugherty wrote: >>>> On 2/17/15 3:22 PM, Carsten Varming wrote: >>>>> Dear Daniel, >>>>> >>>>> Looks good to me. >>>> >>>> Thanks for the fast review. >>>> >>>>> The line: "OrderAccess::fence(); // ensure WatcherThread sees update >>>>> in main loop" seems unnecessary as the lock acts as a memory barrier. >>>> >>>> Yes, I keep looking at that line from the original work on >>>> JDK-7127792 and wonder why it's there... I'll chase that down >>>> with the original folks... >>> >>> Only needed when using lock-free access, so can be removed now. > > Oops - my bad! > >> Yes, that will be the likely outcome. >> >> However, the original code added by JDK-7127792 wasn't lock-free so >> I still want to chase down the original thinking. > > The lock-free code was here: > > void WatcherThread::run() { > assert(this == watcher_thread(), "just checking"); > > this->record_stack_base_and_size(); > this->initialize_thread_local_storage(); > this->set_active_handles(JNIHandleBlock::allocate_block()); > while(!_should_terminate) { > > and of course you still have a lock-free access in the new code: > > 1300 if (_should_terminate) { > 1301 // check for termination before posting the next tick > 1302 break; > 1303 } > > so the fence() could stay, but its omission would be harmless I think > because not seeing the update immediately is no different to having > the update happen just after the check - it's racy code. The only > other option would be to always access _should_terminate with the > PeriodicTask_lock held - but that is subverting the intent of the lock > somewhat as _should_terminate is part of the WatcherThread state. > Actually the more I look at this the more I think the lock has already > been subverted to assist with the WT termination protocol. Just to make sure we're on the same page I think Carsten was talking about this block (from 8072439): 1334 { 1335 // Follow normal safepoint aware lock enter protocol since the 1336 // WatcherThread is stopped by another JavaThread. 1337 MutexLocker ml(PeriodicTask_lock); 1338 _should_terminate = true; 1339 OrderAccess::fence(); // ensure WatcherThread sees update in main loop 1340 1341 WatcherThread* watcher = watcher_thread(); 1342 if (watcher != NULL) { 1343 // unpark the WatcherThread so it can see that it should terminate 1344 watcher->unpark(); 1345 } 1346 } where the fence() on line 1339 is not needed because when we drop the PeriodicTask_lock on line 1346 we get a fence() equivalent. This is the block before my fix for JDK-8047720: 1360 { 1361 MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); 1362 _should_terminate = true; 1363 OrderAccess::fence(); // ensure WatcherThread sees update in main loop 1364 1365 WatcherThread* watcher = watcher_thread(); 1366 if (watcher != NULL) 1367 watcher->unpark(); 1368 } It has the same fence() call and the same lock exit (on different line numbers) so I'm wondering about the original thinking here. I still haven't heard back from Rickard... > >> >>> java.cpp: >>> >>> Typo: likelyhood -> likelihood >> >> Fixed. >> >> >>> --- >>> >>> task.cpp >>> >>> 81 int PeriodicTask::time_to_wait() { >>> 82 assert(Thread::current()->is_Watcher_thread(), "must be >>> WatcherThread"); >>> >>> This is currently true but not sure it has to be true. If we are >>> assuming/constraining a subset of the task API to only be callable by >>> the WatcherThread then perhaps we should document that in task.hpp ? >>> And as the WatcherThread is a friend, none of those methods need to be >>> public - ie execute_if_pending and time_to_wait (realtime_tick is >>> already private). >> >> I was too focused on adding asserts that enforced how it works today >> and not on how it might be used down the road. There's no reason to >> restrict the caller of time_to_wait() to the WatcherThread. I've >> deleted the assert on line 82 and I added a comment to task.hpp: >> >> // Requires the PeriodicTask_lock. >> static int time_to_wait(); >> >> By leaving time_to_wait() public, that allows code other than the >> WatcherThread to use it perhaps for debugging... > > Okay. I still think the API is somewhat confused about its public > interface - execute_if_pending should be protected for use by WT only > (and subclasses implement it of course). Yes, but I think I'll leave that for another bug (probably to be fixed by someone else). > >> >>> 112 void PeriodicTask::enroll() { >>> 113 // Follow normal safepoint aware lock enter protocol if the >>> caller does >>> 114 // not already own the PeriodicTask_lock. Otherwise, we don't >>> try to >>> 115 // enter it again to avoid deadlocking with a safepoint that >>> started >>> 116 // after the initial enter and before this enter. >>> 117 // >>> 118 MutexLockerEx ml(PeriodicTask_lock->owned_by_self() ? NULL >>> 119 : >>> PeriodicTask_lock); >>> >>> The deadlock is not with a safepoint interaction but the normal >>> self-deadlock that would occur trying to lock() a Monitor/Mutex that >>> you already own. (Monitors/Mutexes do not support recursive locking - >>> in contrast to ObjectMonitors.) Ditto for disenroll. >> >> I have been working on Java Monitors for waaaayyyy too long! > > :) > >> In the header comment for src/share/vm/runtime/mutex.cpp: >> >> // Native Monitors do *not* support nesting or recursion but ... >> >> >>> The original comment is the correct one with respect to acquiring with >>> a safepoint check if not already locked: >>> >>> /* XXX could be called from a JavaThread, so we have to check for >>> * safepoint when taking the lock to avoid deadlocking */ >> >> I'm still not fond of that comment. Perhaps: >> >> // Follow normal safepoint aware lock enter protocol if the caller >> does >> // not already own the PeriodicTask_lock. Otherwise, we don't try to >> // enter it again because VM internal Mutexes do not support >> recursion. >> >> I'm trying to make it clear that we're following safepoint aware >> protocol >> even though we're using MutexLockerEx. I also wanted a clear statement >> about why we skipped the enter if we already owned the lock. I don't >> think that we could be called from a JavaThread to be the important >> part. > > Being a JavaThread is the only reason the safepoint protocol has to be > considered - for non-JavaThreads we won't look at the safepoint state. > > The enroll() and disenroll() methods are called from the JavaThreads > and they can not be considered "leaf" methods, so they must obey the > safepoint protocol wrt the lock. > > Anyway your comment is fine. Thanks. > >> >>> --- >>> >>> thread.cpp: >>> >>> 1198 int WatcherThread::sleep() const { >>> 1199 // The WatcherThread does not honor the safepoint protocol for >>> 1200 // PeriodicTask_lock in order to provide more consistent task >>> 1201 // execution timing. >>> >>> Not sure that is really the correct characterisation. The WT doesn't >>> need to honor the safepoint protocol because it isn't a JavaThread and >>> so won't block even if a safepoint is in progress. So checking for a >>> safepoint is simply a waste of time. >> >> Much better way of putting it. Thanks! How about: >> >> // The WatcherThread is not a JavaThread so we do not honor the >> // safepoint protocol for the PeriodicTask_lock. > > Ok. Thanks. > >> >>> >>> 3565 MutexLocker ml(PeriodicTask_lock); >>> >>> Why did you allow for a safepoint check here? It would only be >>> necessary if a JavaThread might concurrently acquire the >>> PeriodicTask_lock and a safepoint is initiated - during VM >>> initialization. Not completely impossible I guess but have never heard >>> of this occurring, so would require some other startup change to >>> trigger it. >> >> There's no good reason to use MutexLockerEx here and I didn't >> want to write a comment explaining why we were using one. >> Earlier code in Threads::create_vm() uses MutexLocker instead >> of MutexLockerEx. > > Okay. Change is harmless. Cool. I think we're on the same page. Thanks again for the reviews. Dan > > Cheers, > David > >> >> Thanks again for the very thorough review! >> >> Dan >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> Dan >>>> >>>> >>>>> >>>>> Carsten >>>>> >>>>> On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty >>>>> > >>>>> wrote: >>>>> >>>>> Greetings, >>>>> >>>>> My fix for the following bug: >>>>> >>>>> JDK-8047720 Xprof hangs on Solaris >>>>> >>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>> >>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com >>>>> ) and Carsten >>>>> Varming (varming at gmail.com ) for >>>>> reporting the mess that I made >>>>> in WatcherThread::stop() and for suggesting fixes. >>>>> >>>>> This code review is for a general cleanup pass on >>>>> PeriodicTask_lock >>>>> and some of the surrounding code. This is a targeted review in >>>>> that >>>>> I would like to hear from three groups of people: >>>>> >>>>> 1) The author and reviewers for: >>>>> >>>>> JDK-7127792 Add the ability to change an existing >>>>> PeriodicTask's >>>>> execution interval >>>>> >>>>> Rickard, David H, and Markus G. >>>>> >>>>> 2) The reviewers for: >>>>> >>>>> JDK-8047720 Xprof hangs on Solaris >>>>> >>>>> Markus G and Coleen >>>>> >>>>> 3) Alex and Carsten >>>>> >>>>> >>>>> Here's the webrev URL: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>> >>>>> >>>>> >>>>> I've attached the original RFR for JDK-8047720 that explains >>>>> the original deadlock that was being fixed. Similar testing >>>>> will be done with this fix. >>>>> >>>>> Dan >>>>> >>>>> >>>> >> From david.holmes at oracle.com Fri Feb 20 00:17:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Feb 2015 10:17:12 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E66BBA.80401@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <54E3E29F.2010000@oracle.com> <54E4BDB5.8080305@oracle.com> <54E54445.4030506@oracle.com> <54E66BBA.80401@oracle.com> Message-ID: <54E67D08.6010900@oracle.com> On 20/02/2015 9:03 AM, Daniel D. Daugherty wrote: > On 2/18/15 7:02 PM, David Holmes wrote: >> Hi Dan, >> >> On 19/02/2015 2:28 AM, Daniel D. Daugherty wrote: >>> David, >>> >>> Thanks for the fast review! Replies embedded below... >>> >>> >>> On 2/17/15 5:53 PM, David Holmes wrote: >>>> Hi Dan, >>>> >>>> A few comments, mainly on the comments :) >>> >>> Apropos since the changeset is mostly comments... >>> >>> >>>> >>>> On 18/02/2015 8:42 AM, Daniel D. Daugherty wrote: >>>>> On 2/17/15 3:22 PM, Carsten Varming wrote: >>>>>> Dear Daniel, >>>>>> >>>>>> Looks good to me. >>>>> >>>>> Thanks for the fast review. >>>>> >>>>>> The line: "OrderAccess::fence(); // ensure WatcherThread sees update >>>>>> in main loop" seems unnecessary as the lock acts as a memory barrier. >>>>> >>>>> Yes, I keep looking at that line from the original work on >>>>> JDK-7127792 and wonder why it's there... I'll chase that down >>>>> with the original folks... >>>> >>>> Only needed when using lock-free access, so can be removed now. >> >> Oops - my bad! >> >>> Yes, that will be the likely outcome. >>> >>> However, the original code added by JDK-7127792 wasn't lock-free so >>> I still want to chase down the original thinking. >> >> The lock-free code was here: >> >> void WatcherThread::run() { >> assert(this == watcher_thread(), "just checking"); >> >> this->record_stack_base_and_size(); >> this->initialize_thread_local_storage(); >> this->set_active_handles(JNIHandleBlock::allocate_block()); >> while(!_should_terminate) { >> >> and of course you still have a lock-free access in the new code: >> >> 1300 if (_should_terminate) { >> 1301 // check for termination before posting the next tick >> 1302 break; >> 1303 } >> >> so the fence() could stay, but its omission would be harmless I think >> because not seeing the update immediately is no different to having >> the update happen just after the check - it's racy code. The only >> other option would be to always access _should_terminate with the >> PeriodicTask_lock held - but that is subverting the intent of the lock >> somewhat as _should_terminate is part of the WatcherThread state. >> Actually the more I look at this the more I think the lock has already >> been subverted to assist with the WT termination protocol. > > Just to make sure we're on the same page I think Carsten was > talking about this block (from 8072439): > > 1334 { > 1335 // Follow normal safepoint aware lock enter protocol since the > 1336 // WatcherThread is stopped by another JavaThread. > 1337 MutexLocker ml(PeriodicTask_lock); > 1338 _should_terminate = true; > 1339 OrderAccess::fence(); // ensure WatcherThread sees update in > main loop > 1340 > 1341 WatcherThread* watcher = watcher_thread(); > 1342 if (watcher != NULL) { > 1343 // unpark the WatcherThread so it can see that it should > terminate > 1344 watcher->unpark(); > 1345 } > 1346 } > > where the fence() on line 1339 is not needed because when we drop > the PeriodicTask_lock on line 1346 we get a fence() equivalent. > > This is the block before my fix for JDK-8047720: > > 1360 { > 1361 MutexLockerEx ml(PeriodicTask_lock, > Mutex::_no_safepoint_check_flag); > 1362 _should_terminate = true; > 1363 OrderAccess::fence(); // ensure WatcherThread sees update in > main loop > 1364 > 1365 WatcherThread* watcher = watcher_thread(); > 1366 if (watcher != NULL) > 1367 watcher->unpark(); > 1368 } > > It has the same fence() call and the same lock exit (on different > line numbers) so I'm wondering about the original thinking here. > I still haven't heard back from Rickard... I think the fence was just a typical lock-free usage to try and make the write visible "immediately". I don't think it helps with any potential hangs due to the inherent race between the write and lock-free read. David > >> >>> >>>> java.cpp: >>>> >>>> Typo: likelyhood -> likelihood >>> >>> Fixed. >>> >>> >>>> --- >>>> >>>> task.cpp >>>> >>>> 81 int PeriodicTask::time_to_wait() { >>>> 82 assert(Thread::current()->is_Watcher_thread(), "must be >>>> WatcherThread"); >>>> >>>> This is currently true but not sure it has to be true. If we are >>>> assuming/constraining a subset of the task API to only be callable by >>>> the WatcherThread then perhaps we should document that in task.hpp ? >>>> And as the WatcherThread is a friend, none of those methods need to be >>>> public - ie execute_if_pending and time_to_wait (realtime_tick is >>>> already private). >>> >>> I was too focused on adding asserts that enforced how it works today >>> and not on how it might be used down the road. There's no reason to >>> restrict the caller of time_to_wait() to the WatcherThread. I've >>> deleted the assert on line 82 and I added a comment to task.hpp: >>> >>> // Requires the PeriodicTask_lock. >>> static int time_to_wait(); >>> >>> By leaving time_to_wait() public, that allows code other than the >>> WatcherThread to use it perhaps for debugging... >> >> Okay. I still think the API is somewhat confused about its public >> interface - execute_if_pending should be protected for use by WT only >> (and subclasses implement it of course). > > Yes, but I think I'll leave that for another bug (probably to > be fixed by someone else). > > >> >>> >>>> 112 void PeriodicTask::enroll() { >>>> 113 // Follow normal safepoint aware lock enter protocol if the >>>> caller does >>>> 114 // not already own the PeriodicTask_lock. Otherwise, we don't >>>> try to >>>> 115 // enter it again to avoid deadlocking with a safepoint that >>>> started >>>> 116 // after the initial enter and before this enter. >>>> 117 // >>>> 118 MutexLockerEx ml(PeriodicTask_lock->owned_by_self() ? NULL >>>> 119 : >>>> PeriodicTask_lock); >>>> >>>> The deadlock is not with a safepoint interaction but the normal >>>> self-deadlock that would occur trying to lock() a Monitor/Mutex that >>>> you already own. (Monitors/Mutexes do not support recursive locking - >>>> in contrast to ObjectMonitors.) Ditto for disenroll. >>> >>> I have been working on Java Monitors for waaaayyyy too long! >> >> :) >> >>> In the header comment for src/share/vm/runtime/mutex.cpp: >>> >>> // Native Monitors do *not* support nesting or recursion but ... >>> >>> >>>> The original comment is the correct one with respect to acquiring with >>>> a safepoint check if not already locked: >>>> >>>> /* XXX could be called from a JavaThread, so we have to check for >>>> * safepoint when taking the lock to avoid deadlocking */ >>> >>> I'm still not fond of that comment. Perhaps: >>> >>> // Follow normal safepoint aware lock enter protocol if the caller >>> does >>> // not already own the PeriodicTask_lock. Otherwise, we don't try to >>> // enter it again because VM internal Mutexes do not support >>> recursion. >>> >>> I'm trying to make it clear that we're following safepoint aware >>> protocol >>> even though we're using MutexLockerEx. I also wanted a clear statement >>> about why we skipped the enter if we already owned the lock. I don't >>> think that we could be called from a JavaThread to be the important >>> part. >> >> Being a JavaThread is the only reason the safepoint protocol has to be >> considered - for non-JavaThreads we won't look at the safepoint state. >> >> The enroll() and disenroll() methods are called from the JavaThreads >> and they can not be considered "leaf" methods, so they must obey the >> safepoint protocol wrt the lock. >> >> Anyway your comment is fine. > > Thanks. > > >> >>> >>>> --- >>>> >>>> thread.cpp: >>>> >>>> 1198 int WatcherThread::sleep() const { >>>> 1199 // The WatcherThread does not honor the safepoint protocol for >>>> 1200 // PeriodicTask_lock in order to provide more consistent task >>>> 1201 // execution timing. >>>> >>>> Not sure that is really the correct characterisation. The WT doesn't >>>> need to honor the safepoint protocol because it isn't a JavaThread and >>>> so won't block even if a safepoint is in progress. So checking for a >>>> safepoint is simply a waste of time. >>> >>> Much better way of putting it. Thanks! How about: >>> >>> // The WatcherThread is not a JavaThread so we do not honor the >>> // safepoint protocol for the PeriodicTask_lock. >> >> Ok. > > Thanks. > > >> >>> >>>> >>>> 3565 MutexLocker ml(PeriodicTask_lock); >>>> >>>> Why did you allow for a safepoint check here? It would only be >>>> necessary if a JavaThread might concurrently acquire the >>>> PeriodicTask_lock and a safepoint is initiated - during VM >>>> initialization. Not completely impossible I guess but have never heard >>>> of this occurring, so would require some other startup change to >>>> trigger it. >>> >>> There's no good reason to use MutexLockerEx here and I didn't >>> want to write a comment explaining why we were using one. >>> Earlier code in Threads::create_vm() uses MutexLocker instead >>> of MutexLockerEx. >> >> Okay. Change is harmless. > > Cool. I think we're on the same page. > > Thanks again for the reviews. > > Dan >> >> Cheers, >> David >> >>> >>> Thanks again for the very thorough review! >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Carsten >>>>>> >>>>>> On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Greetings, >>>>>> >>>>>> My fix for the following bug: >>>>>> >>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>> >>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>> >>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com >>>>>> ) and Carsten >>>>>> Varming (varming at gmail.com ) for >>>>>> reporting the mess that I made >>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>> >>>>>> This code review is for a general cleanup pass on >>>>>> PeriodicTask_lock >>>>>> and some of the surrounding code. This is a targeted review in >>>>>> that >>>>>> I would like to hear from three groups of people: >>>>>> >>>>>> 1) The author and reviewers for: >>>>>> >>>>>> JDK-7127792 Add the ability to change an existing >>>>>> PeriodicTask's >>>>>> execution interval >>>>>> >>>>>> Rickard, David H, and Markus G. >>>>>> >>>>>> 2) The reviewers for: >>>>>> >>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>> >>>>>> Markus G and Coleen >>>>>> >>>>>> 3) Alex and Carsten >>>>>> >>>>>> >>>>>> Here's the webrev URL: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>> >>>>>> >>>>>> >>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>> the original deadlock that was being fixed. Similar testing >>>>>> will be done with this fix. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>> >>> > From jeremymanson at google.com Fri Feb 20 00:48:14 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 19 Feb 2015 16:48:14 -0800 Subject: gdb and OpenJDK In-Reply-To: References: <20150213094025.GB23518@ehelin.jrpg.bea.com> <20150213100201.GD23518@ehelin.jrpg.bea.com> <54E1BB0A.50405@redhat.com> <54E1CBFD.7000001@redhat.com> Message-ID: Hey folks, I just want to make sure we are on the same page here: 1) Andrew is talking about using the gdbjit interface and generated DWARF information. I believe this wouldn't work for interpreted code, because there is no JIT information emitted for it. It would also require extra work to make it work for core dumps, because you would need some sort of post-mortem way of getting the DWARF information. 2) RedHat has a lot more sway over gdb than we do, especially this part of gdb. If you folks *don't* want our patch in gdb, please speak up soon! If you folks are going to go your own way with this, it will make our attempts to get this into gdb irrelevant. Also, if you *do* want our patch in gdb, please speak up soon! It would be great to hear from you, since we've been desperately trying to get the gdb community to accept this patch for the better part of a year, and we're having to beg, plead and cajole code reviews out of people. 3) If the community does like our approach, we still have no idea what we need to do to get it accepted in OpenJDK. As Sasha says, we believe the licenses are compatible, but we will still have to come to some agreement about what direction to go. Thanks! Jeremy On Thu, Feb 19, 2015 at 11:47 AM, Alexander Smundak wrote: > On Mon, Feb 16, 2015 at 2:52 AM, Andrew Haley wrote: > > It would be, long term. I've been discussing this with Red Hat's GDB > > group and I'm hoping to come up with a proposal and hopefully some > > working code. > I have the enabling patch to GDB being reviewed at a glacial pace (see > https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html). Perhaps > Red Hat's GDB group can respond there? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Feb 20 12:10:12 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 20 Feb 2015 13:10:12 +0100 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> Message-ID: <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> The CCC request was approved for this change, but there were a couple of comments: 1) "First, syntactically for the javadoc please use "{@code foo}" rather than "foo?.? I think you have covered this. 2) "You may want to say a bit more about the possible return values of ThreadInfo.getPriority. For example, are they bound to be within the range java.lang.Thread.{MIN_PRIORITY, MAX_PRIORITY}?? I think this would be good to cover, either by explicitly stating it or by linking to Thread.getPriorty(). 3) "Are there any other getFoo or isFoo methods from java.lang.Thread that should be replicated in ThreadInfo?? The only other method that makes sense is getThreadGroup(), but I don?t think we need to cover this here. JDK-8023908 has been filed a while back for that. Thanks, /Staffan > On 18 feb 2015, at 20:10, Jeremy Manson wrote: > > Done. > > http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/ > > Jeremy > > > On Wed, Feb 18, 2015 at 1:49 AM, Staffan Larsen > wrote: > >> On 18 feb 2015, at 00:58, Jeremy Manson > wrote: >> >> Since this is not my code, I will happily defer to the people whose code it is on these matters. I can very easily replace all of the instances, or just the new ones, or none at all. Just let me know. > > I would be grateful if you took the time to convert all of them, but I will also understand if you don?t want to. > >> >> (My general preference in my own code is to separate feature changes and cleanup changes, just so that the history is more comprehensible, but I can certainly understand that you might not want to go that way when the cost of a checkin is so high.) > > Agree that cost of checkin is high? > > /Staffan > >> >> Jeremy >> >> On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung > wrote: >> On 2/17/15 3:10 PM, Martin Buchholz wrote: >>> I don't think feature changes should be mixed with maintenance. >>> >>> Code janitor is the most honourable profession, and it would be awesome for a code janitor to convert the entire jdk to {@code but feature contributors should not be asked to do so. >> >> That's why I didn't ask at first :) >> >> I prefer the new javadoc to use {@code...} even though inconsistent with other methods as they were defined since 1.5. >> >> Mandy >>> >>> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung > wrote: >>> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>>> Hey Mandy, >>>> >>>> Thanks for taking a look. Are we okay making those changes even though none of the other methods in ThreadInfo follow those conventions? Not sure whether consistency matters more or less than doing it right. >>> >>> I wont object and actually be grateful if you want to convert all ... to {@code ...}. Staffan may have a different opinion. >>> >>> Mandy >>>> >>>> Jeremy >>>> >>>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung > wrote: >>>> Hi Jeremy, >>>> >>>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ > >>>> >>>> >>>> The change looks okay to me. >>>> >>>> Nit: It would be good for the new methods to replace ... with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . Similarly Thread#getPriority. >>>> >>>> thanks >>>> Mandy >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Fri Feb 20 15:59:01 2015 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 20 Feb 2015 16:59:01 +0100 Subject: JEP 240: Remove the JVM TI hprof Agent In-Reply-To: References: <20150213004635.5F2514DB85@eggemoggin.niobe.net> <54E1E6FE.8030706@redhat.com> Message-ID: <54E759C5.9040301@redhat.com> On 02/16/2015 04:23 PM, Mario Torre wrote: > Thermostat does support that natively with the CLI interface. Also I > believe Visual VM can deal with saved and exported hprof dumps, > likewise MAT (and Thermostat), which is probably the most advanced at > this stage - so no need to install software really. I believe you are talking about heap dumps here. As far as I understand it, traces from profiling will be gone completely if the hprof agent is removed, so there won't be any data you can analyze externally. -- Florian Weimer / Red Hat Product Security From pmuldoon at redhat.com Fri Feb 20 15:22:59 2015 From: pmuldoon at redhat.com (Phil Muldoon) Date: Fri, 20 Feb 2015 15:22:59 +0000 Subject: gdb and OpenJDK Message-ID: <54E75153.40400@redhat.com> >> On Mon, Feb 16, 2015 at 2:52 AM, Andrew Haley wrote: >> It would be, long term. I've been discussing this with Red Hat's GDB >> group and I'm hoping to come up with a proposal and hopefully some >> working code. > I have the enabling patch to GDB being reviewed at a glacial pace (see > https://sourceware.org/ml/gdb-patches/2014-12/msg00408.html). Perhaps > Red Hat's GDB group can respond there? Please accept my apologies for first posting out-of-thread. I did not have the original email context with headers to post in-thread. So, heads-up, I broke email threading in this reply. Second, again, apologies for the speed of the review. Christmas, and we've all been busy. I see Doug is looking at it now, and I have also asked some questions of the patch. I find the functionality very useful. Hopefully it will progress soon and be committed. Cheers Phil From coleen.phillimore at oracle.com Fri Feb 20 17:56:00 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 20 Feb 2015 12:56:00 -0500 Subject: RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E57884.8030200@oracle.com> References: <54E57884.8030200@oracle.com> Message-ID: <54E77530.5060104@oracle.com> Hi Serguei, This looks good but I have some comments: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/src/share/vm/oops/klassVtable.cpp.udiff.html How can (old_method == new_method) in adjust_method_entries? If old_method->is_old() then you're not updating the vtables or the itable? It should assert with check_no_old_or_obsolete_entries() at the end. http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/src/share/vm/oops/cpCache.cpp.udiff.html It looks like is_interesting_method_entry and get_interesting_method_entry are the same code only one returns bool and the other returns the Method*. Can you call is_interesting_method_entry and check for null return so there are not two copies of this code? thanks, Coleen On 2/19/15, 12:45 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8046246 > > > Open hotspot webrevs: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ > > > Open jdk (new unit test) webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ > > > > Summary: > > This performance/scalability issue in class redefinition was > reported by HP and the Enterprise Manager team. > The following variants of the adjust_method_entries() functions do > not scale: > ConstantPoolCache::adjust_method_entries() > klassVtable::adjust_method_entries() > klassItable::adjust_method_entries() > InstanceKlass::adjust_default_methods() > > The ConstantPoolCache::adjust_method_entries() is the most important. > > The approach is to use the holder->method_with_idnum() like this: > Method* new_method = > holder->method_with_idnum(old_method->orig_method_idnum()); > if (old_method != new_method) { > > } > > New algorithm has effectiveness O(M) instead of original O(M^2), > where M is count of methods in the class. > The new test (see webrev above) was used to mesure CPU time > consumed by the > ConstantPoolCache::adjust_method_entries() in both original and > new approach. > > The performance numbers are: > > --------------------------------------------------------------------------------------- > > Methods: ------ 1,000 --------------- 10,000 ----------------- > 20,000 > --------------------------------------------------------------------------------------- > > Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) > 243,000,000 nsec (~400x) > New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 > nsec (~20x) > --------------------------------------------------------------------------------------- > > > > > Testing: > In progress: VM SQE RedefineClasses tests, JTREG > java/lang/instrument, com/sun/jdi tests > > > Thanks, > Serguei > From jeremymanson at google.com Fri Feb 20 18:34:55 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 20 Feb 2015 10:34:55 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> Message-ID: Okay. Thanks for doing this, Staffan. I do have a "@see Thread#getPriority" there already. Can I just add "This is an integer between {@linkplain Thread#MIN_PRIORITY} and {@linkplain Thread#MAX_PRIORITY}, inclusive." to the getPriority javadoc? Jeremy On Fri, Feb 20, 2015 at 4:10 AM, Staffan Larsen wrote: > The CCC request was approved for this change, but there were a couple of > comments: > > 1) "First, syntactically for the javadoc please use "{@code foo}" rather > than "foo?.? > > I think you have covered this. > > 2) "You may want to say a bit more about the possible return values of > ThreadInfo.getPriority. For example, are they bound to be within the range > java.lang.Thread.{MIN_PRIORITY, MAX_PRIORITY}?? > > I think this would be good to cover, either by explicitly stating it or by > linking to Thread.getPriorty(). > > 3) "Are there any other getFoo or isFoo methods from java.lang.Thread that > should be replicated in ThreadInfo?? > > The only other method that makes sense is getThreadGroup(), but I don?t > think we need to cover this here. JDK-8023908 has been filed a while back > for that. > > Thanks, > /Staffan > > On 18 feb 2015, at 20:10, Jeremy Manson wrote: > > Done. > > http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/ > > Jeremy > > > On Wed, Feb 18, 2015 at 1:49 AM, Staffan Larsen > wrote: > >> >> On 18 feb 2015, at 00:58, Jeremy Manson wrote: >> >> Since this is not my code, I will happily defer to the people whose code >> it is on these matters. I can very easily replace all of the >> instances, or just the new ones, or none at all. Just let me know. >> >> >> I would be grateful if you took the time to convert all of them, but I >> will also understand if you don?t want to. >> >> >> (My general preference in my own code is to separate feature changes and >> cleanup changes, just so that the history is more comprehensible, but I can >> certainly understand that you might not want to go that way when the cost >> of a checkin is so high.) >> >> >> Agree that cost of checkin is high? >> >> /Staffan >> >> >> Jeremy >> >> On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung >> wrote: >> >>> On 2/17/15 3:10 PM, Martin Buchholz wrote: >>> >>> I don't think feature changes should be mixed with maintenance. >>> >>> Code janitor is the most honourable profession, and it would be >>> awesome for a code janitor to convert the entire jdk to {@code but feature >>> contributors should not be asked to do so. >>> >>> >>> That's why I didn't ask at first :) >>> >>> I prefer the new javadoc to use {@code...} even though inconsistent with >>> other methods as they were defined since 1.5. >>> >>> Mandy >>> >>> >>> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung >>> wrote: >>> >>>> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>>> >>>> Hey Mandy, >>>> >>>> Thanks for taking a look. Are we okay making those changes even >>>> though none of the other methods in ThreadInfo follow those conventions? >>>> Not sure whether consistency matters more or less than doing it right. >>>> >>>> >>>> I wont object and actually be grateful if you want to convert all >>>> ... to {@code ...}. Staffan may have a different opinion. >>>> >>>> Mandy >>>> >>>> >>>> Jeremy >>>> >>>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung >>>> wrote: >>>> >>>>> Hi Jeremy, >>>>> >>>>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ < >>>>>> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/> >>>>>> >>>>>> >>>>> The change looks okay to me. >>>>> >>>>> Nit: It would be good for the new methods to replace ... >>>>> with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to >>>>> add {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . >>>>> Similarly Thread#getPriority. >>>>> >>>>> thanks >>>>> Mandy >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Feb 20 19:19:03 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 20 Feb 2015 11:19:03 -0800 Subject: RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E77530.5060104@oracle.com> References: <54E57884.8030200@oracle.com> <54E77530.5060104@oracle.com> Message-ID: <54E788A7.1000103@oracle.com> Hi Coleen, On 2/20/15 9:56 AM, Coleen Phillimore wrote: > > Hi Serguei, This looks good but I have some comments: Thanks a lot for good suggestions and help in the internal review! > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/src/share/vm/oops/klassVtable.cpp.udiff.html > > > How can (old_method == new_method) in adjust_method_entries? If > old_method->is_old() then you're not updating the vtables or the > itable? It should assert with check_no_old_or_obsolete_entries() at > the end. Nice catch, fixed in all 4 places. > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/src/share/vm/oops/cpCache.cpp.udiff.html > > > It looks like is_interesting_method_entry and > get_interesting_method_entry are the same code only one returns bool > and the other returns the Method*. Can you call > is_interesting_method_entry and check for null return so there are not > two copies of this code? Nice catch as well, fixed. I'll post the updated webrev after some testing. Thanks, Serguei > > thanks, > Coleen > > On 2/19/15, 12:45 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8046246 >> >> >> Open hotspot webrevs: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> >> Summary: >> >> This performance/scalability issue in class redefinition was >> reported by HP and the Enterprise Manager team. >> The following variants of the adjust_method_entries() functions do >> not scale: >> ConstantPoolCache::adjust_method_entries() >> klassVtable::adjust_method_entries() >> klassItable::adjust_method_entries() >> InstanceKlass::adjust_default_methods() >> >> The ConstantPoolCache::adjust_method_entries() is the most important. >> >> The approach is to use the holder->method_with_idnum() like this: >> Method* new_method = >> holder->method_with_idnum(old_method->orig_method_idnum()); >> if (old_method != new_method) { >> >> } >> >> New algorithm has effectiveness O(M) instead of original O(M^2), >> where M is count of methods in the class. >> The new test (see webrev above) was used to mesure CPU time >> consumed by the >> ConstantPoolCache::adjust_method_entries() in both original and >> new approach. >> >> The performance numbers are: >> >> --------------------------------------------------------------------------------------- >> >> Methods: ------ 1,000 --------------- 10,000 ----------------- >> 20,000 >> --------------------------------------------------------------------------------------- >> >> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >> 243,000,000 nsec (~400x) >> New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 >> nsec (~20x) >> --------------------------------------------------------------------------------------- >> >> >> >> >> Testing: >> In progress: VM SQE RedefineClasses tests, JTREG >> java/lang/instrument, com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > From martinrb at google.com Fri Feb 20 19:22:55 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Feb 2015 11:22:55 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> Message-ID: In jsr166 we rarely use @see, regarding it as a vestige of a time when @link and @linkplain were not available. Just work a @linkplain into the javadoc. E.g. + /** + * Returns the {@linkplain Thread#priority() thread priority} of the thread associated with this + * {@code ThreadInfo}. + * + * @return The priority of the thread associated with this + * {@code ThreadInfo}. + * @since 1.9 + */ + public int getPriority() { On Fri, Feb 20, 2015 at 10:34 AM, Jeremy Manson wrote: > Okay. Thanks for doing this, Staffan. I do have a "@see > Thread#getPriority" there already. Can I just add "This is an integer > between {@linkplain Thread#MIN_PRIORITY} and {@linkplain > Thread#MAX_PRIORITY}, inclusive." to the getPriority javadoc? > > Jeremy > > On Fri, Feb 20, 2015 at 4:10 AM, Staffan Larsen > wrote: > >> The CCC request was approved for this change, but there were a couple of >> comments: >> >> 1) "First, syntactically for the javadoc please use "{@code foo}" rather >> than "foo?.? >> >> I think you have covered this. >> >> 2) "You may want to say a bit more about the possible return values of >> ThreadInfo.getPriority. For example, are they bound to be within the range >> java.lang.Thread.{MIN_PRIORITY, MAX_PRIORITY}?? >> >> I think this would be good to cover, either by explicitly stating it or >> by linking to Thread.getPriorty(). >> >> 3) "Are there any other getFoo or isFoo methods from java.lang.Thread >> that should be replicated in ThreadInfo?? >> >> The only other method that makes sense is getThreadGroup(), but I don?t >> think we need to cover this here. JDK-8023908 has been filed a while back >> for that. >> >> Thanks, >> /Staffan >> >> On 18 feb 2015, at 20:10, Jeremy Manson wrote: >> >> Done. >> >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/ >> >> Jeremy >> >> >> On Wed, Feb 18, 2015 at 1:49 AM, Staffan Larsen < >> staffan.larsen at oracle.com> wrote: >> >>> >>> On 18 feb 2015, at 00:58, Jeremy Manson wrote: >>> >>> Since this is not my code, I will happily defer to the people whose code >>> it is on these matters. I can very easily replace all of the >>> instances, or just the new ones, or none at all. Just let me know. >>> >>> >>> I would be grateful if you took the time to convert all of them, but I >>> will also understand if you don?t want to. >>> >>> >>> (My general preference in my own code is to separate feature changes and >>> cleanup changes, just so that the history is more comprehensible, but I can >>> certainly understand that you might not want to go that way when the cost >>> of a checkin is so high.) >>> >>> >>> Agree that cost of checkin is high? >>> >>> /Staffan >>> >>> >>> Jeremy >>> >>> On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung >>> wrote: >>> >>>> On 2/17/15 3:10 PM, Martin Buchholz wrote: >>>> >>>> I don't think feature changes should be mixed with maintenance. >>>> >>>> Code janitor is the most honourable profession, and it would be >>>> awesome for a code janitor to convert the entire jdk to {@code but feature >>>> contributors should not be asked to do so. >>>> >>>> >>>> That's why I didn't ask at first :) >>>> >>>> I prefer the new javadoc to use {@code...} even though inconsistent >>>> with other methods as they were defined since 1.5. >>>> >>>> Mandy >>>> >>>> >>>> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung >>>> wrote: >>>> >>>>> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>>>> >>>>> Hey Mandy, >>>>> >>>>> Thanks for taking a look. Are we okay making those changes even >>>>> though none of the other methods in ThreadInfo follow those conventions? >>>>> Not sure whether consistency matters more or less than doing it right. >>>>> >>>>> >>>>> I wont object and actually be grateful if you want to convert all >>>>> ... to {@code ...}. Staffan may have a different opinion. >>>>> >>>>> Mandy >>>>> >>>>> >>>>> Jeremy >>>>> >>>>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung >>>>> wrote: >>>>> >>>>>> Hi Jeremy, >>>>>> >>>>>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ < >>>>>>> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/> >>>>>>> >>>>>>> >>>>>> The change looks okay to me. >>>>>> >>>>>> Nit: It would be good for the new methods to replace ... >>>>>> with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to >>>>>> add {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . >>>>>> Similarly Thread#getPriority. >>>>>> >>>>>> thanks >>>>>> Mandy >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Fri Feb 20 19:39:09 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 20 Feb 2015 11:39:09 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> Message-ID: Staffan, would that be acceptable? Jeremy On Fri, Feb 20, 2015 at 11:22 AM, Martin Buchholz wrote: > In jsr166 we rarely use @see, regarding it as a vestige of a time when > @link and @linkplain were not available. Just work a @linkplain into the > javadoc. E.g. > > + /** > + * Returns the {@linkplain Thread#priority() thread priority} of the thread associated with this > + * {@code ThreadInfo}. > + * > + * @return The priority of the thread associated with this > + * {@code ThreadInfo}. > + * @since 1.9 > + */ > + public int getPriority() { > > > > On Fri, Feb 20, 2015 at 10:34 AM, Jeremy Manson > wrote: > >> Okay. Thanks for doing this, Staffan. I do have a "@see >> Thread#getPriority" there already. Can I just add "This is an integer >> between {@linkplain Thread#MIN_PRIORITY} and {@linkplain >> Thread#MAX_PRIORITY}, inclusive." to the getPriority javadoc? >> >> Jeremy >> >> On Fri, Feb 20, 2015 at 4:10 AM, Staffan Larsen < >> staffan.larsen at oracle.com> wrote: >> >>> The CCC request was approved for this change, but there were a couple of >>> comments: >>> >>> 1) "First, syntactically for the javadoc please use "{@code foo}" rather >>> than "foo?.? >>> >>> I think you have covered this. >>> >>> 2) "You may want to say a bit more about the possible return values of >>> ThreadInfo.getPriority. For example, are they bound to be within the range >>> java.lang.Thread.{MIN_PRIORITY, MAX_PRIORITY}?? >>> >>> I think this would be good to cover, either by explicitly stating it or >>> by linking to Thread.getPriorty(). >>> >>> 3) "Are there any other getFoo or isFoo methods from java.lang.Thread >>> that should be replicated in ThreadInfo?? >>> >>> The only other method that makes sense is getThreadGroup(), but I don?t >>> think we need to cover this here. JDK-8023908 has been filed a while back >>> for that. >>> >>> Thanks, >>> /Staffan >>> >>> On 18 feb 2015, at 20:10, Jeremy Manson wrote: >>> >>> Done. >>> >>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/ >>> >>> Jeremy >>> >>> >>> On Wed, Feb 18, 2015 at 1:49 AM, Staffan Larsen < >>> staffan.larsen at oracle.com> wrote: >>> >>>> >>>> On 18 feb 2015, at 00:58, Jeremy Manson >>>> wrote: >>>> >>>> Since this is not my code, I will happily defer to the people whose >>>> code it is on these matters. I can very easily replace all of the >>>> instances, or just the new ones, or none at all. Just let me know. >>>> >>>> >>>> I would be grateful if you took the time to convert all of them, but I >>>> will also understand if you don?t want to. >>>> >>>> >>>> (My general preference in my own code is to separate feature changes >>>> and cleanup changes, just so that the history is more comprehensible, but I >>>> can certainly understand that you might not want to go that way when the >>>> cost of a checkin is so high.) >>>> >>>> >>>> Agree that cost of checkin is high? >>>> >>>> /Staffan >>>> >>>> >>>> Jeremy >>>> >>>> On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung >>>> wrote: >>>> >>>>> On 2/17/15 3:10 PM, Martin Buchholz wrote: >>>>> >>>>> I don't think feature changes should be mixed with maintenance. >>>>> >>>>> Code janitor is the most honourable profession, and it would be >>>>> awesome for a code janitor to convert the entire jdk to {@code but feature >>>>> contributors should not be asked to do so. >>>>> >>>>> >>>>> That's why I didn't ask at first :) >>>>> >>>>> I prefer the new javadoc to use {@code...} even though inconsistent >>>>> with other methods as they were defined since 1.5. >>>>> >>>>> Mandy >>>>> >>>>> >>>>> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung >>>>> wrote: >>>>> >>>>>> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>>>>> >>>>>> Hey Mandy, >>>>>> >>>>>> Thanks for taking a look. Are we okay making those changes even >>>>>> though none of the other methods in ThreadInfo follow those conventions? >>>>>> Not sure whether consistency matters more or less than doing it right. >>>>>> >>>>>> >>>>>> I wont object and actually be grateful if you want to convert all >>>>>> ... to {@code ...}. Staffan may have a different opinion. >>>>>> >>>>>> Mandy >>>>>> >>>>>> >>>>>> Jeremy >>>>>> >>>>>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung >>>>>> wrote: >>>>>> >>>>>>> Hi Jeremy, >>>>>>> >>>>>>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ < >>>>>>>> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/> >>>>>>>> >>>>>>>> >>>>>>> The change looks okay to me. >>>>>>> >>>>>>> Nit: It would be good for the new methods to replace ... >>>>>>> with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to >>>>>>> add {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . >>>>>>> Similarly Thread#getPriority. >>>>>>> >>>>>>> thanks >>>>>>> Mandy >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Feb 20 21:32:44 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 20 Feb 2015 13:32:44 -0800 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E57884.8030200@oracle.com> References: <54E57884.8030200@oracle.com> Message-ID: <54E7A7FC.9090709@oracle.com> The hotspot webrev below addresses the Coleen's comments from the 1-st review round. Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ Open jdk (new unit test) webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ Thanks, Serguei On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8046246 > > > Open hotspot webrevs: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ > > > Open jdk (new unit test) webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ > > > > Summary: > > This performance/scalability issue in class redefinition was > reported by HP and the Enterprise Manager team. > The following variants of the adjust_method_entries() functions do > not scale: > ConstantPoolCache::adjust_method_entries() > klassVtable::adjust_method_entries() > klassItable::adjust_method_entries() > InstanceKlass::adjust_default_methods() > > The ConstantPoolCache::adjust_method_entries() is the most important. > > The approach is to use the holder->method_with_idnum() like this: > Method* new_method = > holder->method_with_idnum(old_method->orig_method_idnum()); > if (old_method != new_method) { > > } > > New algorithm has effectiveness O(M) instead of original O(M^2), > where M is count of methods in the class. > The new test (see webrev above) was used to mesure CPU time > consumed by the > ConstantPoolCache::adjust_method_entries() in both original and > new approach. > > The performance numbers are: > > --------------------------------------------------------------------------------------- > > Methods: ------ 1,000 --------------- 10,000 ----------------- > 20,000 > --------------------------------------------------------------------------------------- > > Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) > 243,000,000 nsec (~400x) > New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 > nsec (~20x) > --------------------------------------------------------------------------------------- > > > > > Testing: > In progress: VM SQE RedefineClasses tests, JTREG > java/lang/instrument, com/sun/jdi tests > > > Thanks, > Serguei > From coleen.phillimore at oracle.com Sat Feb 21 02:08:43 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 20 Feb 2015 21:08:43 -0500 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E7A7FC.9090709@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> Message-ID: <54E7E8AB.6000704@oracle.com> Serguei, Looks great. Thanks, Coleen On 2/20/15, 4:32 PM, serguei.spitsyn at oracle.com wrote: > The hotspot webrev below addresses the Coleen's comments from the 1-st > review round. > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ > > > Open jdk (new unit test) webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ > > > Thanks, > Serguei > > > On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8046246 >> >> >> Open hotspot webrevs: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> >> Summary: >> >> This performance/scalability issue in class redefinition was >> reported by HP and the Enterprise Manager team. >> The following variants of the adjust_method_entries() functions do >> not scale: >> ConstantPoolCache::adjust_method_entries() >> klassVtable::adjust_method_entries() >> klassItable::adjust_method_entries() >> InstanceKlass::adjust_default_methods() >> >> The ConstantPoolCache::adjust_method_entries() is the most important. >> >> The approach is to use the holder->method_with_idnum() like this: >> Method* new_method = >> holder->method_with_idnum(old_method->orig_method_idnum()); >> if (old_method != new_method) { >> >> } >> >> New algorithm has effectiveness O(M) instead of original O(M^2), >> where M is count of methods in the class. >> The new test (see webrev above) was used to mesure CPU time >> consumed by the >> ConstantPoolCache::adjust_method_entries() in both original and >> new approach. >> >> The performance numbers are: >> >> --------------------------------------------------------------------------------------- >> >> Methods: ------ 1,000 --------------- 10,000 ----------------- >> 20,000 >> --------------------------------------------------------------------------------------- >> >> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >> 243,000,000 nsec (~400x) >> New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 >> nsec (~20x) >> --------------------------------------------------------------------------------------- >> >> >> >> >> Testing: >> In progress: VM SQE RedefineClasses tests, JTREG >> java/lang/instrument, com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Sat Feb 21 06:27:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 20 Feb 2015 22:27:54 -0800 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E7E8AB.6000704@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> <54E7E8AB.6000704@oracle.com> Message-ID: <54E8256A.9060206@oracle.com> Thanks a lot, Coleen! Serguei On 2/20/15 6:08 PM, Coleen Phillimore wrote: > > Serguei, Looks great. > > Thanks, > Coleen > > On 2/20/15, 4:32 PM, serguei.spitsyn at oracle.com wrote: >> The hotspot webrev below addresses the Coleen's comments from the >> 1-st review round. >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> Thanks, >> Serguei >> >> >> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8046246 >>> >>> >>> Open hotspot webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >>> >>> >>> Open jdk (new unit test) webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >>> >>> >>> >>> Summary: >>> >>> This performance/scalability issue in class redefinition was >>> reported by HP and the Enterprise Manager team. >>> The following variants of the adjust_method_entries() functions >>> do not scale: >>> ConstantPoolCache::adjust_method_entries() >>> klassVtable::adjust_method_entries() >>> klassItable::adjust_method_entries() >>> InstanceKlass::adjust_default_methods() >>> >>> The ConstantPoolCache::adjust_method_entries() is the most >>> important. >>> >>> The approach is to use the holder->method_with_idnum() like this: >>> Method* new_method = >>> holder->method_with_idnum(old_method->orig_method_idnum()); >>> if (old_method != new_method) { >>> >>> } >>> >>> New algorithm has effectiveness O(M) instead of original O(M^2), >>> where M is count of methods in the class. >>> The new test (see webrev above) was used to mesure CPU time >>> consumed by the >>> ConstantPoolCache::adjust_method_entries() in both original and >>> new approach. >>> >>> The performance numbers are: >>> >>> --------------------------------------------------------------------------------------- >>> >>> Methods: ------ 1,000 --------------- 10,000 ----------------- >>> 20,000 >>> --------------------------------------------------------------------------------------- >>> >>> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >>> 243,000,000 nsec (~400x) >>> New: 16,000 nsec (1x) 178,000 nsec (~10x) >>> 355,000 nsec (~20x) >>> --------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Testing: >>> In progress: VM SQE RedefineClasses tests, JTREG >>> java/lang/instrument, com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From staffan.larsen at oracle.com Mon Feb 23 09:04:00 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Feb 2015 10:04:00 +0100 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> Message-ID: That looks good to me. /Staffan > On 20 feb 2015, at 20:39, Jeremy Manson wrote: > > Staffan, would that be acceptable? > > Jeremy > > On Fri, Feb 20, 2015 at 11:22 AM, Martin Buchholz > wrote: > In jsr166 we rarely use @see, regarding it as a vestige of a time when @link and @linkplain were not available. Just work a @linkplain into the javadoc. E.g. > > + /** > + * Returns the {@linkplain Thread#priority() thread priority} of the thread associated with this > + * {@code ThreadInfo}. > + * > + * @return The priority of the thread associated with this > + * {@code ThreadInfo}. > + * @since 1.9 > + */ > + public int getPriority() { > > > On Fri, Feb 20, 2015 at 10:34 AM, Jeremy Manson > wrote: > Okay. Thanks for doing this, Staffan. I do have a "@see Thread#getPriority" there already. Can I just add "This is an integer between {@linkplain Thread#MIN_PRIORITY} and {@linkplain Thread#MAX_PRIORITY}, inclusive." to the getPriority javadoc? > > Jeremy > > On Fri, Feb 20, 2015 at 4:10 AM, Staffan Larsen > wrote: > The CCC request was approved for this change, but there were a couple of comments: > > 1) "First, syntactically for the javadoc please use "{@code foo}" rather than "foo?.? > > I think you have covered this. > > 2) "You may want to say a bit more about the possible return values of ThreadInfo.getPriority. For example, are they bound to be within the range java.lang.Thread.{MIN_PRIORITY, MAX_PRIORITY}?? > > I think this would be good to cover, either by explicitly stating it or by linking to Thread.getPriorty(). > > 3) "Are there any other getFoo or isFoo methods from java.lang.Thread that should be replicated in ThreadInfo?? > > The only other method that makes sense is getThreadGroup(), but I don?t think we need to cover this here. JDK-8023908 has been filed a while back for that. > > Thanks, > /Staffan > >> On 18 feb 2015, at 20:10, Jeremy Manson > wrote: >> >> Done. >> >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/ >> >> Jeremy >> >> >> On Wed, Feb 18, 2015 at 1:49 AM, Staffan Larsen > wrote: >> >>> On 18 feb 2015, at 00:58, Jeremy Manson > wrote: >>> >>> Since this is not my code, I will happily defer to the people whose code it is on these matters. I can very easily replace all of the instances, or just the new ones, or none at all. Just let me know. >> >> I would be grateful if you took the time to convert all of them, but I will also understand if you don?t want to. >> >>> >>> (My general preference in my own code is to separate feature changes and cleanup changes, just so that the history is more comprehensible, but I can certainly understand that you might not want to go that way when the cost of a checkin is so high.) >> >> Agree that cost of checkin is high? >> >> /Staffan >> >>> >>> Jeremy >>> >>> On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung > wrote: >>> On 2/17/15 3:10 PM, Martin Buchholz wrote: >>>> I don't think feature changes should be mixed with maintenance. >>>> >>>> Code janitor is the most honourable profession, and it would be awesome for a code janitor to convert the entire jdk to {@code but feature contributors should not be asked to do so. >>> >>> That's why I didn't ask at first :) >>> >>> I prefer the new javadoc to use {@code...} even though inconsistent with other methods as they were defined since 1.5. >>> >>> Mandy >>>> >>>> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung > wrote: >>>> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>>>> Hey Mandy, >>>>> >>>>> Thanks for taking a look. Are we okay making those changes even though none of the other methods in ThreadInfo follow those conventions? Not sure whether consistency matters more or less than doing it right. >>>> >>>> I wont object and actually be grateful if you want to convert all ... to {@code ...}. Staffan may have a different opinion. >>>> >>>> Mandy >>>>> >>>>> Jeremy >>>>> >>>>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung > wrote: >>>>> Hi Jeremy, >>>>> >>>>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ > >>>>> >>>>> >>>>> The change looks okay to me. >>>>> >>>>> Nit: It would be good for the new methods to replace ... with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to add {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . Similarly Thread#getPriority. >>>>> >>>>> thanks >>>>> Mandy >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens.limasoftware at gmail.com Mon Feb 23 11:28:59 2015 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 23 Feb 2015 12:28:59 +0100 Subject: JEP 240: Remove the JVM TI hprof Agent In-Reply-To: <54E759C5.9040301@redhat.com> References: <20150213004635.5F2514DB85@eggemoggin.niobe.net> <54E1E6FE.8030706@redhat.com> <54E759C5.9040301@redhat.com> Message-ID: 2015-02-20 16:59 GMT+01:00 Florian Weimer : > On 02/16/2015 04:23 PM, Mario Torre wrote: >> Thermostat does support that natively with the CLI interface. Also I >> believe Visual VM can deal with saved and exported hprof dumps, >> likewise MAT (and Thermostat), which is probably the most advanced at >> this stage - so no need to install software really. > > I believe you are talking about heap dumps here. As far as I understand > it, traces from profiling will be gone completely if the hprof agent is > removed, so there won't be any data you can analyze externally. I see what you mean, I thought you were referring to heap analysis. I don't think there is an easy way to retrieve this information and indeed the tool the JEP 240 refers as part of the JDK distribution are specific to Oracle JDK (with is an interesting wording, I should say). On the other end I agree with the linked article regarding the shortcomings, and the main reason why we are going to great length to use the various stap/perf/oprofile tools instead. We could try to save those agents and bundle them within the IcedTea distribution if there is popular demand though. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From jeremymanson at google.com Mon Feb 23 19:49:38 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 23 Feb 2015 11:49:38 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <54B4ACF0.1000900@oracle.com> <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> Message-ID: Okey-doke: http://cr.openjdk.java.net/~jmanson/6588467/webrev.03/ On Mon, Feb 23, 2015 at 1:04 AM, Staffan Larsen wrote: > That looks good to me. > > /Staffan > > On 20 feb 2015, at 20:39, Jeremy Manson wrote: > > Staffan, would that be acceptable? > > Jeremy > > On Fri, Feb 20, 2015 at 11:22 AM, Martin Buchholz > wrote: > >> In jsr166 we rarely use @see, regarding it as a vestige of a time when >> @link and @linkplain were not available. Just work a @linkplain into the >> javadoc. E.g. >> >> + /** >> + * Returns the {@linkplain Thread#priority() thread priority} of the thread associated with this >> + * {@code ThreadInfo}. >> + * >> + * @return The priority of the thread associated with this >> + * {@code ThreadInfo}. >> + * @since 1.9 >> + */ >> + public int getPriority() { >> >> >> >> On Fri, Feb 20, 2015 at 10:34 AM, Jeremy Manson >> wrote: >> >>> Okay. Thanks for doing this, Staffan. I do have a "@see >>> Thread#getPriority" there already. Can I just add "This is an integer >>> between {@linkplain Thread#MIN_PRIORITY} and {@linkplain >>> Thread#MAX_PRIORITY}, inclusive." to the getPriority javadoc? >>> >>> Jeremy >>> >>> On Fri, Feb 20, 2015 at 4:10 AM, Staffan Larsen < >>> staffan.larsen at oracle.com> wrote: >>> >>>> The CCC request was approved for this change, but there were a couple >>>> of comments: >>>> >>>> 1) "First, syntactically for the javadoc please use "{@code foo}" >>>> rather than "foo?.? >>>> >>>> I think you have covered this. >>>> >>>> 2) "You may want to say a bit more about the possible return values of >>>> ThreadInfo.getPriority. For example, are they bound to be within the range >>>> java.lang.Thread.{MIN_PRIORITY, MAX_PRIORITY}?? >>>> >>>> I think this would be good to cover, either by explicitly stating it or >>>> by linking to Thread.getPriorty(). >>>> >>>> 3) "Are there any other getFoo or isFoo methods from java.lang.Thread >>>> that should be replicated in ThreadInfo?? >>>> >>>> The only other method that makes sense is getThreadGroup(), but I don?t >>>> think we need to cover this here. JDK-8023908 has been filed a while back >>>> for that. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 18 feb 2015, at 20:10, Jeremy Manson >>>> wrote: >>>> >>>> Done. >>>> >>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.02/ >>>> >>>> Jeremy >>>> >>>> >>>> On Wed, Feb 18, 2015 at 1:49 AM, Staffan Larsen < >>>> staffan.larsen at oracle.com> wrote: >>>> >>>>> >>>>> On 18 feb 2015, at 00:58, Jeremy Manson >>>>> wrote: >>>>> >>>>> Since this is not my code, I will happily defer to the people whose >>>>> code it is on these matters. I can very easily replace all of the >>>>> instances, or just the new ones, or none at all. Just let me know. >>>>> >>>>> >>>>> I would be grateful if you took the time to convert all of them, but I >>>>> will also understand if you don?t want to. >>>>> >>>>> >>>>> (My general preference in my own code is to separate feature changes >>>>> and cleanup changes, just so that the history is more comprehensible, but I >>>>> can certainly understand that you might not want to go that way when the >>>>> cost of a checkin is so high.) >>>>> >>>>> >>>>> Agree that cost of checkin is high? >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> Jeremy >>>>> >>>>> On Tue, Feb 17, 2015 at 3:55 PM, Mandy Chung >>>>> wrote: >>>>> >>>>>> On 2/17/15 3:10 PM, Martin Buchholz wrote: >>>>>> >>>>>> I don't think feature changes should be mixed with maintenance. >>>>>> >>>>>> Code janitor is the most honourable profession, and it would be >>>>>> awesome for a code janitor to convert the entire jdk to {@code but feature >>>>>> contributors should not be asked to do so. >>>>>> >>>>>> >>>>>> That's why I didn't ask at first :) >>>>>> >>>>>> I prefer the new javadoc to use {@code...} even though inconsistent >>>>>> with other methods as they were defined since 1.5. >>>>>> >>>>>> Mandy >>>>>> >>>>>> >>>>>> On Tue, Feb 17, 2015 at 2:35 PM, Mandy Chung >>>>>> wrote: >>>>>> >>>>>>> On 2/17/15 9:31 AM, Jeremy Manson wrote: >>>>>>> >>>>>>> Hey Mandy, >>>>>>> >>>>>>> Thanks for taking a look. Are we okay making those changes even >>>>>>> though none of the other methods in ThreadInfo follow those conventions? >>>>>>> Not sure whether consistency matters more or less than doing it right. >>>>>>> >>>>>>> >>>>>>> I wont object and actually be grateful if you want to convert all >>>>>>> ... to {@code ...}. Staffan may have a different opinion. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> >>>>>>> Jeremy >>>>>>> >>>>>>> On Mon, Feb 16, 2015 at 3:44 PM, Mandy Chung >>>>>> > wrote: >>>>>>> >>>>>>>> Hi Jeremy, >>>>>>>> >>>>>>>> On 2/9/2015 4:51 PM, Jeremy Manson wrote: >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~jmanson/6588467/webrev.01/ < >>>>>>>>> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.01/> >>>>>>>>> >>>>>>>>> >>>>>>>> The change looks okay to me. >>>>>>>> >>>>>>>> Nit: It would be good for the new methods to replace ... >>>>>>>> with {@code ...}. line 600, 603 {@code ThreadInfo}. It would be good to >>>>>>>> add {@linkplain Thread#isDaemon daemon thread} or @see Thread#isDaemon . >>>>>>>> Similarly Thread#getPriority. >>>>>>>> >>>>>>>> thanks >>>>>>>> Mandy >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Feb 24 01:29:17 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Feb 2015 17:29:17 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> Message-ID: <54EBD3ED.1020208@oracle.com> On 2/23/15 11:49 AM, Jeremy Manson wrote: > Okey-doke: > > http://cr.openjdk.java.net/~jmanson/6588467/webrev.03/ > > Looks good. Minor comment: @see Thread#isDaemon can be removed since you have it in @linkplain. No need for a new webrev. Thanks. Mandy From jeremymanson at google.com Tue Feb 24 04:58:07 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 23 Feb 2015 20:58:07 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <54EBD3ED.1020208@oracle.com> References: <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> <54EBD3ED.1020208@oracle.com> Message-ID: Thanks, Mandy. I guess it is time to submit. I don't have a committer bit. Any volunteers? Thanks to all for the review! Jeremy On Mon, Feb 23, 2015 at 5:29 PM, Mandy Chung wrote: > On 2/23/15 11:49 AM, Jeremy Manson wrote: > >> Okey-doke: >> >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.03/ < >> http://cr.openjdk.java.net/%7Ejmanson/6588467/webrev.03/> >> >> > Looks good. Minor comment: @see Thread#isDaemon can be removed since you > have it in @linkplain. No need for a new webrev. > > Thanks. > Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Feb 24 07:40:22 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 24 Feb 2015 08:40:22 +0100 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> <54E280E5.70609@oracle.com> <54E3C215.4030609@oracle.com> <54E3D4FB.8080205@oracle.com> <61E97234-C9DD-4DB6-B92B-698B0A9DC74B@oracle.com> <94A67578-927F-4D07-A971-183F9B47379D@oracle.com> ! <54EBD3ED.1020208@oracle.com> Message-ID: <75FE522E-4E33-4705-A849-7291A2BB3130@oracle.com> I can push this for you. Thanks! /Staffan > On 24 feb 2015, at 05:58, Jeremy Manson wrote: > > Thanks, Mandy. > > I guess it is time to submit. I don't have a committer bit. Any volunteers? > > Thanks to all for the review! > > Jeremy > > On Mon, Feb 23, 2015 at 5:29 PM, Mandy Chung > wrote: > On 2/23/15 11:49 AM, Jeremy Manson wrote: > Okey-doke: > > http://cr.openjdk.java.net/~jmanson/6588467/webrev.03/ > > > > Looks good. Minor comment: @see Thread#isDaemon can be removed since you have it in @linkplain. No need for a new webrev. > > Thanks. > Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Feb 24 08:13:13 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 Feb 2015 00:13:13 -0800 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E7E8AB.6000704@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> <54E7E8AB.6000704@oracle.com> Message-ID: <54EC3299.8060203@oracle.com> Hi Coleen, This is a new performance bug that targets another round of performance improvements per our discussion: https://bugs.openjdk.java.net/browse/JDK-8073705: more performance issues in class redefinition Feel free to update it if necessary. Hi Dan, I'd be happy if you have a chance to find cycles to look at the webrev below. Your opinion is always very valuable! No time pressure, just let me know about your intention. :) Thanks, Serguei On 2/20/15 6:08 PM, Coleen Phillimore wrote: > > Serguei, Looks great. > > Thanks, > Coleen > > On 2/20/15, 4:32 PM, serguei.spitsyn at oracle.com wrote: >> The hotspot webrev below addresses the Coleen's comments from the >> 1-st review round. >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> Thanks, >> Serguei >> >> >> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8046246 >>> >>> >>> Open hotspot webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >>> >>> >>> Open jdk (new unit test) webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >>> >>> >>> >>> Summary: >>> >>> This performance/scalability issue in class redefinition was >>> reported by HP and the Enterprise Manager team. >>> The following variants of the adjust_method_entries() functions >>> do not scale: >>> ConstantPoolCache::adjust_method_entries() >>> klassVtable::adjust_method_entries() >>> klassItable::adjust_method_entries() >>> InstanceKlass::adjust_default_methods() >>> >>> The ConstantPoolCache::adjust_method_entries() is the most >>> important. >>> >>> The approach is to use the holder->method_with_idnum() like this: >>> Method* new_method = >>> holder->method_with_idnum(old_method->orig_method_idnum()); >>> if (old_method != new_method) { >>> >>> } >>> >>> New algorithm has effectiveness O(M) instead of original O(M^2), >>> where M is count of methods in the class. >>> The new test (see webrev above) was used to mesure CPU time >>> consumed by the >>> ConstantPoolCache::adjust_method_entries() in both original and >>> new approach. >>> >>> The performance numbers are: >>> >>> --------------------------------------------------------------------------------------- >>> >>> Methods: ------ 1,000 --------------- 10,000 ----------------- >>> 20,000 >>> --------------------------------------------------------------------------------------- >>> >>> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >>> 243,000,000 nsec (~400x) >>> New: 16,000 nsec (1x) 178,000 nsec (~10x) >>> 355,000 nsec (~20x) >>> --------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Testing: >>> In progress: VM SQE RedefineClasses tests, JTREG >>> java/lang/instrument, com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From staffan.larsen at oracle.com Tue Feb 24 09:08:06 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 24 Feb 2015 10:08:06 +0100 Subject: RFR: 8073713 javadoc warnings in serviceability code Message-ID: Please review these small fixes to javadoc in some of the serviceability code. Thanks, /Staffan diff --git a/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java b/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java --- a/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java +++ b/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java @@ -45,7 +45,7 @@ * All methods throw a {@code NullPointerException} if any input argument is * {@code null} unless it's stated otherwise. * - * @see ManagementFactory#getPlatformMXBeans(Class) + * @see java.lang.management.ManagementFactory#getPlatformMXBeans(Class) */ @jdk.Exported public interface HotSpotDiagnosticMXBean extends PlatformManagedObject { diff --git a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java --- a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java +++ b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java @@ -46,7 +46,7 @@ * Constructs an AttachOperationFailedException with * the specified detail message. * - * @param s the detail message. + * @param message the detail message. */ public AttachOperationFailedException(String message) { super(message); diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java b/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java --- a/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java @@ -145,7 +145,7 @@ * not be done from the client's event handler thread. *

* The resumption of other threads during the invocation can be prevented - * by specifying the {@link #INVOKE_SINGLE_THREADED} + * by specifying the {@link ClassType#INVOKE_SINGLE_THREADED} * bit flag in the options argument; however, * there is no protection against or recovery from the deadlocks * described above, so this option should be used with great caution. From markus.gronlund at oracle.com Tue Feb 24 09:12:34 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 24 Feb 2015 01:12:34 -0800 (PST) Subject: RFR: 8073713 javadoc warnings in serviceability code In-Reply-To: References: Message-ID: <1ac63f64-d9fb-40dc-bd76-26b00af3763e@default> Looks good. /Markus -----Original Message----- From: Staffan Larsen Sent: den 24 februari 2015 10:08 To: serviceability-dev Subject: RFR: 8073713 javadoc warnings in serviceability code Please review these small fixes to javadoc in some of the serviceability code. Thanks, /Staffan diff --git a/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java b/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java --- a/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java +++ b/src/java.management/share/classes/com/sun/management/HotSpotDiagno +++ sticMXBean.java @@ -45,7 +45,7 @@ * All methods throw a {@code NullPointerException} if any input argument is * {@code null} unless it's stated otherwise. * - * @see ManagementFactory#getPlatformMXBeans(Class) + * @see + java.lang.management.ManagementFactory#getPlatformMXBeans(Class) */ @jdk.Exported public interface HotSpotDiagnosticMXBean extends PlatformManagedObject { diff --git a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java --- a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java +++ b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationF +++ ailedException.java @@ -46,7 +46,7 @@ * Constructs an AttachOperationFailedException with * the specified detail message. * - * @param s the detail message. + * @param message the detail message. */ public AttachOperationFailedException(String message) { super(message); diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java b/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java --- a/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java @@ -145,7 +145,7 @@ * not be done from the client's event handler thread. *

* The resumption of other threads during the invocation can be prevented - * by specifying the {@link #INVOKE_SINGLE_THREADED} + * by specifying the {@link ClassType#INVOKE_SINGLE_THREADED} * bit flag in the options argument; however, * there is no protection against or recovery from the deadlocks * described above, so this option should be used with great caution. From serguei.spitsyn at oracle.com Tue Feb 24 09:47:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 Feb 2015 01:47:35 -0800 Subject: RFR: 8073713 javadoc warnings in serviceability code In-Reply-To: <1ac63f64-d9fb-40dc-bd76-26b00af3763e@default> References: <1ac63f64-d9fb-40dc-bd76-26b00af3763e@default> Message-ID: <54EC48B7.6030102@oracle.com> +1 Thanks, Serguei On 2/24/15 1:12 AM, Markus Gronlund wrote: > Looks good. > > /Markus > > -----Original Message----- > From: Staffan Larsen > Sent: den 24 februari 2015 10:08 > To: serviceability-dev > Subject: RFR: 8073713 javadoc warnings in serviceability code > > Please review these small fixes to javadoc in some of the serviceability code. > > Thanks, > /Staffan > > diff --git a/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java b/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java > --- a/src/java.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java > +++ b/src/java.management/share/classes/com/sun/management/HotSpotDiagno > +++ sticMXBean.java > @@ -45,7 +45,7 @@ > * All methods throw a {@code NullPointerException} if any input argument is > * {@code null} unless it's stated otherwise. > * > - * @see ManagementFactory#getPlatformMXBeans(Class) > + * @see > + java.lang.management.ManagementFactory#getPlatformMXBeans(Class) > */ > @jdk.Exported > public interface HotSpotDiagnosticMXBean extends PlatformManagedObject { diff --git a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java > --- a/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationFailedException.java > +++ b/src/jdk.attach/share/classes/com/sun/tools/attach/AttachOperationF > +++ ailedException.java > @@ -46,7 +46,7 @@ > * Constructs an AttachOperationFailedException with > * the specified detail message. > * > - * @param s the detail message. > + * @param message the detail message. > */ > public AttachOperationFailedException(String message) { > super(message); > diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java b/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java > --- a/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/InterfaceType.java > @@ -145,7 +145,7 @@ > * not be done from the client's event handler thread. > *

> * The resumption of other threads during the invocation can be prevented > - * by specifying the {@link #INVOKE_SINGLE_THREADED} > + * by specifying the {@link ClassType#INVOKE_SINGLE_THREADED} > * bit flag in the options argument; however, > * there is no protection against or recovery from the deadlocks > * described above, so this option should be used with great caution. From Alan.Bateman at oracle.com Tue Feb 24 09:49:31 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Feb 2015 09:49:31 +0000 Subject: RFR: 8073713 javadoc warnings in serviceability code In-Reply-To: References: Message-ID: <54EC492B.9070908@oracle.com> On 24/02/2015 09:08, Staffan Larsen wrote: > Please review these small fixes to javadoc in some of the serviceability code. > > Looks good to me, nice to squash these issues. -Alan From staffan.larsen at oracle.com Tue Feb 24 09:58:32 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 24 Feb 2015 10:58:32 +0100 Subject: RFR: 8073713 javadoc warnings in serviceability code In-Reply-To: <54EC492B.9070908@oracle.com> References: <54EC492B.9070908@oracle.com> Message-ID: <9EED5930-3D71-4F02-894D-9B8122025B4A@oracle.com> Thanks all for the reviews. /Staffan > On 24 feb 2015, at 10:49, Alan Bateman wrote: > > On 24/02/2015 09:08, Staffan Larsen wrote: >> Please review these small fixes to javadoc in some of the serviceability code. >> >> > Looks good to me, nice to squash these issues. > > -Alan From markus.gronlund at oracle.com Tue Feb 24 15:13:22 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 24 Feb 2015 07:13:22 -0800 (PST) Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E3C3B9.7040505@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> Message-ID: <15fe75b0-820e-466a-b8a2-71012998103c@default> Hi Dan, ? I have taken a look with your suggested patch ? I think your suggestion looks very good. ? I guess the original hang happened because the PeriodicTask_lock was attempted to be acquired by a JavaThread, but the PeriodicTask_lock was still held by someone else. Since the PeriodicTask_lock was taken with ?Mutex::_no_safepoint_checks? it meant the JavaThread bypassed the callback for a potentially pending safepoint and instead called parked upon the PeriodicTask_lock straight away... ? I think this lock should definitely be taken the way you have done in the patch. ? I also think the placement of OrderAccess::fence() might have been due to some of the constructs being racy, take this for instance: ? void WatcherThread::start() { ? assert(PeriodicTask_lock->owned_by_self(), "PeriodicTask_lock required"); ? ? if (watcher_thread() == NULL && _startable) { _startable is visible since its the same thread ??? _should_terminate = false; <<----------------------------- this is set but will not be visible to the WatcherThread being launched (it?s? a 0 in the static initializer however, so it is still ?safe?) ??? // Create the single instance of WatcherThread ??? new WatcherThread(); ? // above the constructor for WatcherThread will start the thread, and the WatcherThread::run() might check _should_terminate before the launching thread releases the PeriodicTask_lock. Not that it will be an issue here, since _should_terminate is set to 0 in its static initializer. But thanks Dan for moving this _should_terminate lower in the loop, at least the WatcherThread will need now need a call to sleep() before reaching it (and sleep needs the PeriodicTask_lock) ? But for the construct in WatcherThread::stop(), there is no need (any more?) for the OrderAccess::fence(), I think it can be safely removed. ? Can you also remove the comment in thread.hpp : 704 that says: ? ? volatile static bool _should_terminate; // updated without holding lock ? As this is not the case any longer. ? Otherwise it looks good! ? Thanks for fixing this ? Cheers Markus ? ? ? ? ? ? ? From: Daniel D. Daugherty Sent: den 17 februari 2015 23:42 To: Carsten Varming Cc: Alexander Garthwaite; Rickard B?ckman; David Holmes; Markus Gr?nlund; Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) ? On 2/17/15 3:22 PM, Carsten Varming wrote: Dear Daniel, ? Looks good to me. Thanks for the fast review. The line: "OrderAccess::fence(); ?// ensure WatcherThread sees update in main loop" seems unnecessary as the lock acts as a memory barrier. Yes, I keep looking at that line from the original work on JDK-7127792 and wonder why it's there... I'll chase that down with the original folks... Dan ? Carsten ? On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty wrote: Greetings, My fix for the following bug: ? ? JDK-8047720 Xprof hangs on Solaris that was pushed to JDK9 last June needs to be cleaned up. Thanks to Alex Garthwaite (HYPERLINK "mailto:agarthwaite at twitter.com" \nagarthwaite at twitter.com) and Carsten Varming (HYPERLINK "mailto:varming at gmail.com" \nvarming at gmail.com) for reporting the mess that I made in WatcherThread::stop() and for suggesting fixes. This code review is for a general cleanup pass on PeriodicTask_lock and some of the surrounding code. This is a targeted review in that I would like to hear from three groups of people: 1) The author and reviewers for: ? ?JDK-7127792 Add the ability to change an existing PeriodicTask's ? ? ? ? ? ? ? ?execution interval ? ?Rickard, David H, and Markus G. 2) The reviewers for: ? ?JDK-8047720 Xprof hangs on Solaris ? ?Markus G and Coleen 3) Alex and Carsten Here's the webrev URL: HYPERLINK "http://cr.openjdk.java.net/%7Edcubed/8072439-webrev/0-for_jdk9_hs_rt/" \nhttp://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ I've attached the original RFR for JDK-8047720 that explains the original deadlock that was being fixed. Similar testing will be done with this fix. Dan ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Tue Feb 24 17:02:11 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 24 Feb 2015 09:02:11 -0800 (PST) Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <15fe75b0-820e-466a-b8a2-71012998103c@default> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <15fe75b0-820e-466a-b8a2-71012998103c@default> Message-ID: Actually thinking about this a bit more: ? I think we could make all uses of PeriodicTask_lock to be acquired with MutexLocker (not Ex), and avoid passing the Mutex::_no_safepoint_check flag (and lengthy comments): ? JavaThreads will (check for and) block for safepoints in WatcherThread::enroll/disenroll if the PeriodicTask_lock is being held by someone else. Same thing in before_exit(). ? Since the WatcherThread is not a JavaThread and will never check for a safepoint if there is a contended lock, it will call IWait() (to park) directly. ? This would also make it possible to change the PeriodicTask_lock from being asserted as a ?_safepoint_check_sometimes? to a ?_safepoint_check_always?. ? In order to do this however, we would need to rework Monitor::Wait(): ? The only place (currently) where there is a requirement to pass ?Mutex::_no_safepoint_check? is when the WatcherThread calls Wait() ? but this is because we have this in there: ? ? // !no_safepoint_check logically implies java_thread ? guarantee(no_safepoint_check || Self->is_Java_thread(), "invariant"); ? This does not make sense ? a WatcherThread should not need to explicitly say ?please go outside the safepoint protocol? - it is not a JavaThread so to it, there is no such thing as a safepoint. ? In Monitor::lock() we branch to a safepoint check based on the Self->isJavaThread(), but in Monitor::wait() we also allow for JavaThreads to circumvent the protocol if they pass in the correct flag. ? Maybe we can change Monitor::Wait() a wee bit (I know this is sensitive code), and still allow for arbitrary passings of ?no_safepoint_checks? for JavaThreads, but if there is nothing passed, we take the safepoint route if there is a JavaThread, and not if there is anything else (similar to Monitor::lock()). Callers which are not JavaThreads should not need to pass these options. Combining this with the lock assertion states, such as, ?_safepoint_check_always? will disallow anyone (any JavaThread) to circumvent the safepoint protocol for the PeriodicTask_lock. ? I will try some experiments, so Dan please go ahead with what you already have. ? Cheers Markus ? ? ? ? From: Markus Gronlund Sent: den 24 februari 2015 16:13 To: Daniel Daugherty Cc: Alexander Garthwaite; Rickard B?ckman; David Holmes; Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; Carsten Varming Subject: RE: RFR(XS) for PeriodicTask_lock cleanup (8072439) ? Hi Dan, ? I have taken a look with your suggested patch ? I think your suggestion looks very good. ? I guess the original hang happened because the PeriodicTask_lock was attempted to be acquired by a JavaThread, but the PeriodicTask_lock was still held by someone else. Since the PeriodicTask_lock was taken with ?Mutex::_no_safepoint_checks? it meant the JavaThread bypassed the callback for a potentially pending safepoint and instead called parked upon the PeriodicTask_lock straight away... ? I think this lock should definitely be taken the way you have done in the patch. ? I also think the placement of OrderAccess::fence() might have been due to some of the constructs being racy, take this for instance: ? void WatcherThread::start() { ? assert(PeriodicTask_lock->owned_by_self(), "PeriodicTask_lock required"); ? ? if (watcher_thread() == NULL && _startable) { _startable is visible since its the same thread ??? _should_terminate = false; <<----------------------------- this is set but will not be visible to the WatcherThread being launched (it?s? a 0 in the static initializer however, so it is still ?safe?) ??? // Create the single instance of WatcherThread ??? new WatcherThread(); ? // above the constructor for WatcherThread will start the thread, and the WatcherThread::run() might check _should_terminate before the launching thread releases the PeriodicTask_lock. Not that it will be an issue here, since _should_terminate is set to 0 in its static initializer. But thanks Dan for moving this _should_terminate lower in the loop, at least the WatcherThread will need now need a call to sleep() before reaching it (and sleep needs the PeriodicTask_lock) ? But for the construct in WatcherThread::stop(), there is no need (any more?) for the OrderAccess::fence(), I think it can be safely removed. ? Can you also remove the comment in thread.hpp : 704 that says: ? ? volatile static bool _should_terminate; // updated without holding lock ? As this is not the case any longer. ? Otherwise it looks good! ? Thanks for fixing this ? Cheers Markus ? ? ? ? ? ? ? From: Daniel D. Daugherty Sent: den 17 februari 2015 23:42 To: Carsten Varming Cc: Alexander Garthwaite; Rickard B?ckman; David Holmes; Markus Gr?nlund; Coleen Phillimore; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) ? On 2/17/15 3:22 PM, Carsten Varming wrote: Dear Daniel, ? Looks good to me. Thanks for the fast review. The line: "OrderAccess::fence(); ?// ensure WatcherThread sees update in main loop" seems unnecessary as the lock acts as a memory barrier. Yes, I keep looking at that line from the original work on JDK-7127792 and wonder why it's there... I'll chase that down with the original folks... Dan ? Carsten ? On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty wrote: Greetings, My fix for the following bug: ? ? JDK-8047720 Xprof hangs on Solaris that was pushed to JDK9 last June needs to be cleaned up. Thanks to Alex Garthwaite (HYPERLINK "mailto:agarthwaite at twitter.com" \nagarthwaite at twitter.com) and Carsten Varming (HYPERLINK "mailto:varming at gmail.com" \nvarming at gmail.com) for reporting the mess that I made in WatcherThread::stop() and for suggesting fixes. This code review is for a general cleanup pass on PeriodicTask_lock and some of the surrounding code. This is a targeted review in that I would like to hear from three groups of people: 1) The author and reviewers for: ? ?JDK-7127792 Add the ability to change an existing PeriodicTask's ? ? ? ? ? ? ? ?execution interval ? ?Rickard, David H, and Markus G. 2) The reviewers for: ? ?JDK-8047720 Xprof hangs on Solaris ? ?Markus G and Coleen 3) Alex and Carsten Here's the webrev URL: HYPERLINK "http://cr.openjdk.java.net/%7Edcubed/8072439-webrev/0-for_jdk9_hs_rt/" \nhttp://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ I've attached the original RFR for JDK-8047720 that explains the original deadlock that was being fixed. Similar testing will be done with this fix. Dan ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Feb 24 21:10:56 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 25 Feb 2015 00:10:56 +0300 Subject: RFR (S) : 8073607 : add trace events for inlining Message-ID: <54ECE8E0.2080201@oracle.com> Hi guys, could you please review the patch which adds trace events for inlining for c1/c2 compiler? An added event provides information about caller, callee, bci, inline status and message. webrev : http://cr.openjdk.java.net/~iignatyev/8073607/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8073607 -- Igor From daniel.daugherty at oracle.com Tue Feb 24 21:26:10 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 24 Feb 2015 14:26:10 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <15fe75b0-820e-466a-b8a2-71012998103c@default> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <15fe75b0-820e-466a-b8a2-71012998103c@default> Message-ID: <54ECEC72.4060708@oracle.com> Markus, Thanks for the review. Replies embedded below. On 2/24/15 8:13 AM, Markus Gronlund wrote: > > Hi Dan, > > I have taken a look with your suggested patch ? I think your > suggestion looks very good. > Thanks. > I guess the original hang happened because the PeriodicTask_lock was > attempted to be acquired by a JavaThread, but the PeriodicTask_lock > was still held by someone else. Since the PeriodicTask_lock was taken > with ?Mutex::_no_safepoint_checks? it meant the JavaThread bypassed > the callback for a potentially pending safepoint and instead called > parked upon the PeriodicTask_lock straight away... > Not sure which "original hang" you are referencing. There's lots of gory details about the hang I fixed in JDK-8047720. > I think this lock should definitely be taken the way you have done in > the patch. > Glad we're on the same page. > I also think the placement of OrderAccess::fence() might have been due > to some of the constructs being racy, take this for instance: > > void WatcherThread::start() { > > assert(PeriodicTask_lock->owned_by_self(), "PeriodicTask_lock > required"); > > if (watcher_thread() == NULL && _startable) { _startable is visible > since its the same thread > > _should_terminate = false; <<----------------------------- this is > set but will not be visible to the WatcherThread being launched (it?s > a 0 in the static initializer however, so it is still ?safe?) > > // Create the single instance of WatcherThread > > new WatcherThread(); > > // above the constructor for WatcherThread will start the thread, and > the WatcherThread::run() might check _should_terminate before the > launching thread releases the PeriodicTask_lock. Not that it will be > an issue here, since _should_terminate is set to 0 in its static > initializer. > The _should_terminate field is volatile and this is a "single writer" situation relative to the WatcherThread being a "single reader". Even if _should_terminate was initialized to 99 in the static initializer, this line: 1322 _should_terminate = false; should be visible to the newly created WatcherThread on these lines: 1324 new WatcherThread(); : (old) 1255 while (!_should_terminate) { > But thanks Dan for moving this _should_terminate lower in the loop, at > least the WatcherThread will need now need a call to sleep() before > reaching it (and sleep needs the PeriodicTask_lock) > This was one of Carsten's suggested changes which I picked upfor this work. > But for the construct in WatcherThread::stop(), there is no need (any > more?) for the OrderAccess::fence(), I think it can be safely removed. > Do you (or Rickard) know why it was there in the first place? Even in the original code for JDK-7127792 we should not have needed the fence()... > Can you also remove the comment in thread.hpp : 704 that says: > > volatile static bool _should_terminate; // updated without holding lock > > As this is not the case any longer. > How aboutthis instead: // volatile due to at least one lock-free read volatile static bool _should_terminate; > Otherwise it looks good! > Thanks! > Thanks for fixing this > I messed it up with my fix for JDK-8047720 so should clean that up... :-) Dan > Cheers > > Markus > > *From:*Daniel D. Daugherty > *Sent:* den 17 februari 2015 23:42 > *To:* Carsten Varming > *Cc:* Alexander Garthwaite; Rickard B?ckman; David Holmes; Markus > Gr?nlund; Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net; > serviceability-dev at openjdk.java.net > *Subject:* Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) > > On 2/17/15 3:22 PM, Carsten Varming wrote: > > Dear Daniel, > > Looks good to me. > > > Thanks for the fast review. > > > > The line: "OrderAccess::fence(); // ensure WatcherThread sees update > in main loop" seems unnecessary as the lock acts as a memory barrier. > > > Yes, I keep looking at that line from the original work on > JDK-7127792 and wonder why it's there... I'll chase that down > with the original folks... > > Dan > > > > Carsten > > On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty > > wrote: > > Greetings, > > My fix for the following bug: > > JDK-8047720 Xprof hangs on Solaris > > that was pushed to JDK9 last June needs to be cleaned up. > > Thanks to Alex Garthwaite (agarthwaite at twitter.com > ) and Carsten > Varming (varming at gmail.com ) for reporting > the mess that I made > in WatcherThread::stop() and for suggesting fixes. > > This code review is for a general cleanup pass on PeriodicTask_lock > and some of the surrounding code. This is a targeted review in that > I would like to hear from three groups of people: > > 1) The author and reviewers for: > > JDK-7127792 Add the ability to change an existing PeriodicTask's > execution interval > > Rickard, David H, and Markus G. > > 2) The reviewers for: > > JDK-8047720 Xprof hangs on Solaris > > Markus G and Coleen > > 3) Alex and Carsten > > > Here's the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ > > > I've attached the original RFR for JDK-8047720 that explains > the original deadlock that was being fixed. Similar testing > will be done with this fix. > > Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Feb 24 21:33:08 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 24 Feb 2015 14:33:08 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <15fe75b0-820e-466a-b8a2-71012998103c@default> Message-ID: <54ECEE14.1060603@oracle.com> More replies embedded below... On 2/24/15 10:02 AM, Markus Gronlund wrote: > > Actually thinking about this a bit more: > > I think we could make all uses of PeriodicTask_lock to be acquired > with MutexLocker (not Ex), and avoid passing the > Mutex::_no_safepoint_check flag (and lengthy comments): > > JavaThreads will (check for and) block for safepoints in > WatcherThread::enroll/disenroll if the PeriodicTask_lock is being held > by someone else. Same thing in before_exit(). > > Since the WatcherThread is not a JavaThread and will never check for a > safepoint if there is a contended lock, it will call IWait() (to park) > directly. > > This would also make it possible to change the PeriodicTask_lock from > being asserted as a ?_safepoint_check_sometimes? to a > ?_safepoint_check_always?. > Coleen (and Max) would like that... :-) > In order to do this however, we would need to rework Monitor::Wait(): > > The only place (currently) where there is a requirement to pass > ?Mutex::_no_safepoint_check? is when the WatcherThread calls Wait() ? > but this is because we have this in there: > > // !no_safepoint_check logically implies java_thread > > guarantee(no_safepoint_check || Self->is_Java_thread(), "invariant"); > > This does not make sense ? a WatcherThread should not need to > explicitly say ?please go outside the safepoint protocol? - it is not > a JavaThread so to it, there is no such thing as a safepoint. > That's why MutexLockerEx exists... but I see your point. We're evolving this area with the _safepoint_check_* stuff so why not make MutexLocker smarter... > In Monitor::lock() we branch to a safepoint check based on the > Self->isJavaThread(), but in Monitor::wait() we also allow for > JavaThreads to circumvent the protocol if they pass in the correct flag. > This is definitely a little inconsistent. > Maybe we can change Monitor::Wait() a wee bit (I know this is > sensitive code), and still allow for arbitrary passings of > ?no_safepoint_checks? for JavaThreads, but if there is nothing passed, > we take the safepoint route if there is a JavaThread, and not if there > is anything else (similar to Monitor::lock()). Callers which are not > JavaThreads should not need to pass these options. Combining this with > the lock assertion states, such as, ?_safepoint_check_always? will > disallow anyone (any JavaThread) to circumvent the safepoint protocol > for the PeriodicTask_lock. > Yes I agree this can likely be cleaned up a bit... > I will try some experiments, so Dan please go ahead with what you > already have. > So I'll leave the further cleanup to your experiment and a new bug. I'll move forward with the webrev plus the tweaks I identified in my reply to your first e-mail. Thanks againfor the reviews! Dan > Cheers > > Markus > > *From:*Markus Gronlund > *Sent:* den 24 februari 2015 16:13 > *To:* Daniel Daugherty > *Cc:* Alexander Garthwaite; Rickard B?ckman; David Holmes; Coleen > Phillimore; hotspot-runtime-dev at openjdk.java.net; > serviceability-dev at openjdk.java.net; Carsten Varming > *Subject:* RE: RFR(XS) for PeriodicTask_lock cleanup (8072439) > > Hi Dan, > > I have taken a look with your suggested patch ? I think your > suggestion looks very good. > > I guess the original hang happened because the PeriodicTask_lock was > attempted to be acquired by a JavaThread, but the PeriodicTask_lock > was still held by someone else. Since the PeriodicTask_lock was taken > with ?Mutex::_no_safepoint_checks? it meant the JavaThread bypassed > the callback for a potentially pending safepoint and instead called > parked upon the PeriodicTask_lock straight away... > > I think this lock should definitely be taken the way you have done in > the patch. > > I also think the placement of OrderAccess::fence() might have been due > to some of the constructs being racy, take this for instance: > > void WatcherThread::start() { > > assert(PeriodicTask_lock->owned_by_self(), "PeriodicTask_lock > required"); > > if (watcher_thread() == NULL && _startable) { _startable is visible > since its the same thread > > _should_terminate = false; <<----------------------------- this is > set but will not be visible to the WatcherThread being launched (it?s > a 0 in the static initializer however, so it is still ?safe?) > > // Create the single instance of WatcherThread > > new WatcherThread(); > > // above the constructor for WatcherThread will start the thread, and > the WatcherThread::run() might check _should_terminate before the > launching thread releases the PeriodicTask_lock. Not that it will be > an issue here, since _should_terminate is set to 0 in its static > initializer. But thanks Dan for moving this _should_terminate lower in > the loop, at least the WatcherThread will need now need a call to > sleep() before reaching it (and sleep needs the PeriodicTask_lock) > > But for the construct in WatcherThread::stop(), there is no need (any > more?) for the OrderAccess::fence(), I think it can be safely removed. > > Can you also remove the comment in thread.hpp : 704 that says: > > volatile static bool _should_terminate; // updated without holding lock > > As this is not the case any longer. > > Otherwise it looks good! > > Thanks for fixing this > > Cheers > > Markus > > *From:*Daniel D. Daugherty > *Sent:* den 17 februari 2015 23:42 > *To:* Carsten Varming > *Cc:* Alexander Garthwaite; Rickard B?ckman; David Holmes; Markus > Gr?nlund; Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net > ; > serviceability-dev at openjdk.java.net > > *Subject:* Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) > > On 2/17/15 3:22 PM, Carsten Varming wrote: > > Dear Daniel, > > Looks good to me. > > > Thanks for the fast review. > > > The line: "OrderAccess::fence(); // ensure WatcherThread sees update > in main loop" seems unnecessary as the lock acts as a memory barrier. > > > Yes, I keep looking at that line from the original work on > JDK-7127792 and wonder why it's there... I'll chase that down > with the original folks... > > Dan > > > Carsten > > On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty > > wrote: > > Greetings, > > My fix for the following bug: > > JDK-8047720 Xprof hangs on Solaris > > that was pushed to JDK9 last June needs to be cleaned up. > > Thanks to Alex Garthwaite (agarthwaite at twitter.com > ) and Carsten > Varming (varming at gmail.com ) for reporting > the mess that I made > in WatcherThread::stop() and for suggesting fixes. > > This code review is for a general cleanup pass on PeriodicTask_lock > and some of the surrounding code. This is a targeted review in that > I would like to hear from three groups of people: > > 1) The author and reviewers for: > > JDK-7127792 Add the ability to change an existing PeriodicTask's > execution interval > > Rickard, David H, and Markus G. > > 2) The reviewers for: > > JDK-8047720 Xprof hangs on Solaris > > Markus G and Coleen > > 3) Alex and Carsten > > > Here's the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ > > > I've attached the original RFR for JDK-8047720 that explains > the original deadlock that was being fixed. Similar testing > will be done with this fix. > > Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Tue Feb 24 23:42:43 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 24 Feb 2015 15:42:43 -0800 (PST) Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54ECEC72.4060708@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <15fe75b0-820e-466a-b8a2-71012998103c@default> <54ECEC72.4060708@oracle.com> Message-ID: <446bae09-78e8-44f4-904b-d225146096ba@default> Thanks again Dan, ? Added some comments, pls see below. ? /Markus ? ? From: Daniel D. Daugherty Sent: den 24 februari 2015 22:26 To: Markus Gronlund Cc: Alexander Garthwaite; Rickard B?ckman; David Holmes; Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; Carsten Varming Subject: Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) ? Markus, Thanks for the review. Replies embedded below. ? On 2/24/15 8:13 AM, Markus Gronlund wrote: Hi Dan, ? I have taken a look with your suggested patch ? I think your suggestion looks very good. ? Thanks. I guess the original hang happened because the PeriodicTask_lock was attempted to be acquired by a JavaThread, but the PeriodicTask_lock was still held by someone else. Since the PeriodicTask_lock was taken with ?Mutex::_no_safepoint_checks? it meant the JavaThread bypassed the callback for a potentially pending safepoint and instead called parked upon the PeriodicTask_lock straight away... ? Not sure which "original hang" you are referencing. There's lots of gory details about the hang I fixed in JDK-8047720. ? [MG] I meant the JDK-8047720 hang ? wouldn?t you say all hangs are a bit ?original? ? :) I think this lock should definitely be taken the way you have done in the patch. ? Glad we're on the same page. ? I also think the placement of OrderAccess::fence() might have been due to some of the constructs being racy, take this for instance: ? void WatcherThread::start() { ? assert(PeriodicTask_lock->owned_by_self(), "PeriodicTask_lock required"); ? ? if (watcher_thread() == NULL && _startable) { _startable is visible since its the same thread ??? _should_terminate = false; <<----------------------------- this is set but will not be visible to the WatcherThread being launched (it?s? a 0 in the static initializer however, so it is still ?safe?) ??? // Create the single instance of WatcherThread ??? new WatcherThread(); ? // above the constructor for WatcherThread will start the thread, and the WatcherThread::run() might check _should_terminate before the launching thread releases the PeriodicTask_lock. Not that it will be an issue here, since _should_terminate is set to 0 in its static initializer. ? The _should_terminate field is volatile and this is a "single writer" situation relative to the WatcherThread being a "single reader". Even if _should_terminate was initialized to 99 in the static initializer, this line: ????? 1322???? _should_terminate = false; should be visible to the newly created WatcherThread on these lines: ????? 1324???? new WatcherThread(); ????? : (old) 1255?? while (!_should_terminate) { ? [MG] I?m sorry, i overlooked the volatility of the variable ? thanks ? and I liked your updated comment regarding it (below). ? But thanks Dan for moving this _should_terminate lower in the loop, at least the WatcherThread will need now need a call to sleep() before reaching it (and sleep needs the PeriodicTask_lock) This was one of Carsten's suggested changes which I picked up for this work. Good work Carsten! But for the construct in WatcherThread::stop(), there is no need (any more?) for the OrderAccess::fence(), I think it can be safely removed. Do you (or Rickard) know why it was there in the first place? Even in the original code for JDK-7127792 we should not have needed the fence()... [MG] I honestly don?t remember ? as you point out it does not make any real sense in this context, so I can mostly assume a non-intentional change/something left in from previous experiments / lax reviewing on my part ? maybe Rickard remembers if there was a real need for this.. Can you also remove the comment in thread.hpp : 704 that says: ? ? volatile static bool _should_terminate; // updated without holding lock ? As this is not the case any longer. How about this instead: ? // volatile due to at least one lock-free read ? volatile static bool _should_terminate; ? [MG] yep. Good. Otherwise it looks good! ? Thanks! Thanks for fixing this I messed it up with my fix for JDK-8047720 so should clean that up... :-) Dan ? Cheers Markus ? ? ? ? ? ? ? From: Daniel D. Daugherty Sent: den 17 februari 2015 23:42 To: Carsten Varming Cc: Alexander Garthwaite; Rickard B?ckman; David Holmes; Markus Gr?nlund; Coleen Phillimore; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) ? On 2/17/15 3:22 PM, Carsten Varming wrote: Dear Daniel, ? Looks good to me. Thanks for the fast review. The line: "OrderAccess::fence(); ?// ensure WatcherThread sees update in main loop" seems unnecessary as the lock acts as a memory barrier. Yes, I keep looking at that line from the original work on JDK-7127792 and wonder why it's there... I'll chase that down with the original folks... Dan ? Carsten ? On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty wrote: Greetings, My fix for the following bug: ? ? JDK-8047720 Xprof hangs on Solaris that was pushed to JDK9 last June needs to be cleaned up. Thanks to Alex Garthwaite (HYPERLINK "mailto:agarthwaite at twitter.com" \nagarthwaite at twitter.com) and Carsten Varming (HYPERLINK "mailto:varming at gmail.com" \nvarming at gmail.com) for reporting the mess that I made in WatcherThread::stop() and for suggesting fixes. This code review is for a general cleanup pass on PeriodicTask_lock and some of the surrounding code. This is a targeted review in that I would like to hear from three groups of people: 1) The author and reviewers for: ? ?JDK-7127792 Add the ability to change an existing PeriodicTask's ? ? ? ? ? ? ? ?execution interval ? ?Rickard, David H, and Markus G. 2) The reviewers for: ? ?JDK-8047720 Xprof hangs on Solaris ? ?Markus G and Coleen 3) Alex and Carsten Here's the webrev URL: HYPERLINK "http://cr.openjdk.java.net/%7Edcubed/8072439-webrev/0-for_jdk9_hs_rt/" \nhttp://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ I've attached the original RFR for JDK-8047720 that explains the original deadlock that was being fixed. Similar testing will be done with this fix. Dan ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Feb 25 00:31:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Feb 2015 10:31:42 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E66BBA.80401@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <54E3E29F.2010000@oracle.com> <54E4BDB5.8080305@oracle.com> <54E54445.4030506@oracle.com> <54E66BBA.80401@oracle.com> Message-ID: <54ED17EE.5040108@oracle.com> Hi Dan, Just one follow up, the OrderAccess::fence was not added by 7127792 but was added as part of the embedded support code (for non-TSO systems) in JDK 7 under: 6953477: Increase portability and flexibility of building Hotspot https://bugs.openjdk.java.net/browse/JDK-6953477 That code also made _should_terminate volatile. There was no locking then, the WatcherThread::stop did: _should_terminate = true; OrderAccess::fence(); // ensure WatcherThread sees update in main loop Thread* watcher = watcher_thread(); if (watcher != NULL) watcher->_SleepEvent->unpark(); and the fence was used to ensure that the write to _should_terminate was visible to the WT after the unpark, as WT::run did: jlong prev_time = os::javaTimeNanos(); for (;;) { int res= _SleepEvent->park(time_to_wait); if (res == OS_TIMEOUT || _should_terminate) break; Cheers, David On 20/02/2015 9:03 AM, Daniel D. Daugherty wrote: > On 2/18/15 7:02 PM, David Holmes wrote: >> Hi Dan, >> >> On 19/02/2015 2:28 AM, Daniel D. Daugherty wrote: >>> David, >>> >>> Thanks for the fast review! Replies embedded below... >>> >>> >>> On 2/17/15 5:53 PM, David Holmes wrote: >>>> Hi Dan, >>>> >>>> A few comments, mainly on the comments :) >>> >>> Apropos since the changeset is mostly comments... >>> >>> >>>> >>>> On 18/02/2015 8:42 AM, Daniel D. Daugherty wrote: >>>>> On 2/17/15 3:22 PM, Carsten Varming wrote: >>>>>> Dear Daniel, >>>>>> >>>>>> Looks good to me. >>>>> >>>>> Thanks for the fast review. >>>>> >>>>>> The line: "OrderAccess::fence(); // ensure WatcherThread sees update >>>>>> in main loop" seems unnecessary as the lock acts as a memory barrier. >>>>> >>>>> Yes, I keep looking at that line from the original work on >>>>> JDK-7127792 and wonder why it's there... I'll chase that down >>>>> with the original folks... >>>> >>>> Only needed when using lock-free access, so can be removed now. >> >> Oops - my bad! >> >>> Yes, that will be the likely outcome. >>> >>> However, the original code added by JDK-7127792 wasn't lock-free so >>> I still want to chase down the original thinking. >> >> The lock-free code was here: >> >> void WatcherThread::run() { >> assert(this == watcher_thread(), "just checking"); >> >> this->record_stack_base_and_size(); >> this->initialize_thread_local_storage(); >> this->set_active_handles(JNIHandleBlock::allocate_block()); >> while(!_should_terminate) { >> >> and of course you still have a lock-free access in the new code: >> >> 1300 if (_should_terminate) { >> 1301 // check for termination before posting the next tick >> 1302 break; >> 1303 } >> >> so the fence() could stay, but its omission would be harmless I think >> because not seeing the update immediately is no different to having >> the update happen just after the check - it's racy code. The only >> other option would be to always access _should_terminate with the >> PeriodicTask_lock held - but that is subverting the intent of the lock >> somewhat as _should_terminate is part of the WatcherThread state. >> Actually the more I look at this the more I think the lock has already >> been subverted to assist with the WT termination protocol. > > Just to make sure we're on the same page I think Carsten was > talking about this block (from 8072439): > > 1334 { > 1335 // Follow normal safepoint aware lock enter protocol since the > 1336 // WatcherThread is stopped by another JavaThread. > 1337 MutexLocker ml(PeriodicTask_lock); > 1338 _should_terminate = true; > 1339 OrderAccess::fence(); // ensure WatcherThread sees update in > main loop > 1340 > 1341 WatcherThread* watcher = watcher_thread(); > 1342 if (watcher != NULL) { > 1343 // unpark the WatcherThread so it can see that it should > terminate > 1344 watcher->unpark(); > 1345 } > 1346 } > > where the fence() on line 1339 is not needed because when we drop > the PeriodicTask_lock on line 1346 we get a fence() equivalent. > > This is the block before my fix for JDK-8047720: > > 1360 { > 1361 MutexLockerEx ml(PeriodicTask_lock, > Mutex::_no_safepoint_check_flag); > 1362 _should_terminate = true; > 1363 OrderAccess::fence(); // ensure WatcherThread sees update in > main loop > 1364 > 1365 WatcherThread* watcher = watcher_thread(); > 1366 if (watcher != NULL) > 1367 watcher->unpark(); > 1368 } > > It has the same fence() call and the same lock exit (on different > line numbers) so I'm wondering about the original thinking here. > I still haven't heard back from Rickard... > > >> >>> >>>> java.cpp: >>>> >>>> Typo: likelyhood -> likelihood >>> >>> Fixed. >>> >>> >>>> --- >>>> >>>> task.cpp >>>> >>>> 81 int PeriodicTask::time_to_wait() { >>>> 82 assert(Thread::current()->is_Watcher_thread(), "must be >>>> WatcherThread"); >>>> >>>> This is currently true but not sure it has to be true. If we are >>>> assuming/constraining a subset of the task API to only be callable by >>>> the WatcherThread then perhaps we should document that in task.hpp ? >>>> And as the WatcherThread is a friend, none of those methods need to be >>>> public - ie execute_if_pending and time_to_wait (realtime_tick is >>>> already private). >>> >>> I was too focused on adding asserts that enforced how it works today >>> and not on how it might be used down the road. There's no reason to >>> restrict the caller of time_to_wait() to the WatcherThread. I've >>> deleted the assert on line 82 and I added a comment to task.hpp: >>> >>> // Requires the PeriodicTask_lock. >>> static int time_to_wait(); >>> >>> By leaving time_to_wait() public, that allows code other than the >>> WatcherThread to use it perhaps for debugging... >> >> Okay. I still think the API is somewhat confused about its public >> interface - execute_if_pending should be protected for use by WT only >> (and subclasses implement it of course). > > Yes, but I think I'll leave that for another bug (probably to > be fixed by someone else). > > >> >>> >>>> 112 void PeriodicTask::enroll() { >>>> 113 // Follow normal safepoint aware lock enter protocol if the >>>> caller does >>>> 114 // not already own the PeriodicTask_lock. Otherwise, we don't >>>> try to >>>> 115 // enter it again to avoid deadlocking with a safepoint that >>>> started >>>> 116 // after the initial enter and before this enter. >>>> 117 // >>>> 118 MutexLockerEx ml(PeriodicTask_lock->owned_by_self() ? NULL >>>> 119 : >>>> PeriodicTask_lock); >>>> >>>> The deadlock is not with a safepoint interaction but the normal >>>> self-deadlock that would occur trying to lock() a Monitor/Mutex that >>>> you already own. (Monitors/Mutexes do not support recursive locking - >>>> in contrast to ObjectMonitors.) Ditto for disenroll. >>> >>> I have been working on Java Monitors for waaaayyyy too long! >> >> :) >> >>> In the header comment for src/share/vm/runtime/mutex.cpp: >>> >>> // Native Monitors do *not* support nesting or recursion but ... >>> >>> >>>> The original comment is the correct one with respect to acquiring with >>>> a safepoint check if not already locked: >>>> >>>> /* XXX could be called from a JavaThread, so we have to check for >>>> * safepoint when taking the lock to avoid deadlocking */ >>> >>> I'm still not fond of that comment. Perhaps: >>> >>> // Follow normal safepoint aware lock enter protocol if the caller >>> does >>> // not already own the PeriodicTask_lock. Otherwise, we don't try to >>> // enter it again because VM internal Mutexes do not support >>> recursion. >>> >>> I'm trying to make it clear that we're following safepoint aware >>> protocol >>> even though we're using MutexLockerEx. I also wanted a clear statement >>> about why we skipped the enter if we already owned the lock. I don't >>> think that we could be called from a JavaThread to be the important >>> part. >> >> Being a JavaThread is the only reason the safepoint protocol has to be >> considered - for non-JavaThreads we won't look at the safepoint state. >> >> The enroll() and disenroll() methods are called from the JavaThreads >> and they can not be considered "leaf" methods, so they must obey the >> safepoint protocol wrt the lock. >> >> Anyway your comment is fine. > > Thanks. > > >> >>> >>>> --- >>>> >>>> thread.cpp: >>>> >>>> 1198 int WatcherThread::sleep() const { >>>> 1199 // The WatcherThread does not honor the safepoint protocol for >>>> 1200 // PeriodicTask_lock in order to provide more consistent task >>>> 1201 // execution timing. >>>> >>>> Not sure that is really the correct characterisation. The WT doesn't >>>> need to honor the safepoint protocol because it isn't a JavaThread and >>>> so won't block even if a safepoint is in progress. So checking for a >>>> safepoint is simply a waste of time. >>> >>> Much better way of putting it. Thanks! How about: >>> >>> // The WatcherThread is not a JavaThread so we do not honor the >>> // safepoint protocol for the PeriodicTask_lock. >> >> Ok. > > Thanks. > > >> >>> >>>> >>>> 3565 MutexLocker ml(PeriodicTask_lock); >>>> >>>> Why did you allow for a safepoint check here? It would only be >>>> necessary if a JavaThread might concurrently acquire the >>>> PeriodicTask_lock and a safepoint is initiated - during VM >>>> initialization. Not completely impossible I guess but have never heard >>>> of this occurring, so would require some other startup change to >>>> trigger it. >>> >>> There's no good reason to use MutexLockerEx here and I didn't >>> want to write a comment explaining why we were using one. >>> Earlier code in Threads::create_vm() uses MutexLocker instead >>> of MutexLockerEx. >> >> Okay. Change is harmless. > > Cool. I think we're on the same page. > > Thanks again for the reviews. > > Dan >> >> Cheers, >> David >> >>> >>> Thanks again for the very thorough review! >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Carsten >>>>>> >>>>>> On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Greetings, >>>>>> >>>>>> My fix for the following bug: >>>>>> >>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>> >>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>> >>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com >>>>>> ) and Carsten >>>>>> Varming (varming at gmail.com ) for >>>>>> reporting the mess that I made >>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>> >>>>>> This code review is for a general cleanup pass on >>>>>> PeriodicTask_lock >>>>>> and some of the surrounding code. This is a targeted review in >>>>>> that >>>>>> I would like to hear from three groups of people: >>>>>> >>>>>> 1) The author and reviewers for: >>>>>> >>>>>> JDK-7127792 Add the ability to change an existing >>>>>> PeriodicTask's >>>>>> execution interval >>>>>> >>>>>> Rickard, David H, and Markus G. >>>>>> >>>>>> 2) The reviewers for: >>>>>> >>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>> >>>>>> Markus G and Coleen >>>>>> >>>>>> 3) Alex and Carsten >>>>>> >>>>>> >>>>>> Here's the webrev URL: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>> >>>>>> >>>>>> >>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>> the original deadlock that was being fixed. Similar testing >>>>>> will be done with this fix. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>> >>> > From daniel.daugherty at oracle.com Wed Feb 25 02:59:18 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 24 Feb 2015 19:59:18 -0700 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E7A7FC.9090709@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> Message-ID: <54ED3A86.1050301@oracle.com> On 2/20/15 2:32 PM, serguei.spitsyn at oracle.com wrote: > The hotspot webrev below addresses the Coleen's comments from the 1-st > review round. > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ Thumbs up! src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/oops/instanceKlass.cpp InstanceKlass::adjust_default_methods() - so you drop the outer level of for-loop here by switching from parallel old_methods/new_methods arrays to looping on the target array (default methods) and only fetching the old_method candidate that's in parallel with the current default method _and_ only fetching the new method when you need it. So you've squashed a nested for-loop and you're only fetching the new method when you know you need it. Nicely done. src/share/vm/oops/cpCache.hpp line 482: void adjust_method_entries(InstanceKlass* holder, bool * trace_name_printed); Nit - this line (and the previous) one have a space between 'bool' and '*'. The other pointer params do not. Seems to be a common format difference in 'bool *' params. :-) src/share/vm/oops/cpCache.cpp No comments. src/share/vm/oops/klassVtable.hpp No comments. src/share/vm/oops/klassVtable.cpp klassVtable::adjust_method_entries() and klassItable::adjust_method_entries() have similar loop squashing. Again, nicely done. src/share/vm/prims/jvmtiRedefineClasses.cpp No comments. src/share/vm/classfile/defaultMethods.cpp No comments. src/share/vm/oops/constMethod.hpp Cool way of using a little bit of space to squash some loops. Surprised Coleen let you have a u2 though :-) src/share/vm/oops/method.hpp No comments. src/share/vm/oops/method.cpp No comments. Nit - double check copyright updates before you commit. Dan > Open jdk (new unit test) webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ > > > Thanks, > Serguei > > > On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8046246 >> >> >> Open hotspot webrevs: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> >> Summary: >> >> This performance/scalability issue in class redefinition was >> reported by HP and the Enterprise Manager team. >> The following variants of the adjust_method_entries() functions do >> not scale: >> ConstantPoolCache::adjust_method_entries() >> klassVtable::adjust_method_entries() >> klassItable::adjust_method_entries() >> InstanceKlass::adjust_default_methods() >> >> The ConstantPoolCache::adjust_method_entries() is the most important. >> >> The approach is to use the holder->method_with_idnum() like this: >> Method* new_method = >> holder->method_with_idnum(old_method->orig_method_idnum()); >> if (old_method != new_method) { >> >> } >> >> New algorithm has effectiveness O(M) instead of original O(M^2), >> where M is count of methods in the class. >> The new test (see webrev above) was used to mesure CPU time >> consumed by the >> ConstantPoolCache::adjust_method_entries() in both original and >> new approach. >> >> The performance numbers are: >> >> --------------------------------------------------------------------------------------- >> >> Methods: ------ 1,000 --------------- 10,000 ----------------- >> 20,000 >> --------------------------------------------------------------------------------------- >> >> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >> 243,000,000 nsec (~400x) >> New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 >> nsec (~20x) >> --------------------------------------------------------------------------------------- >> >> >> >> >> Testing: >> In progress: VM SQE RedefineClasses tests, JTREG >> java/lang/instrument, com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Wed Feb 25 03:15:42 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 Feb 2015 19:15:42 -0800 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54ED3A86.1050301@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> <54ED3A86.1050301@oracle.com> Message-ID: <54ED3E5E.90807@oracle.com> Dan, On 2/24/15 6:59 PM, Daniel D. Daugherty wrote: > On 2/20/15 2:32 PM, serguei.spitsyn at oracle.com wrote: >> The hotspot webrev below addresses the Coleen's comments from the >> 1-st review round. >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> > > Thumbs up! Thanks a lot! > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > InstanceKlass::adjust_default_methods() - so you drop the outer level > of for-loop here by switching from parallel old_methods/new_methods > arrays to looping on the target array (default methods) and only > fetching the old_method candidate that's in parallel with the > current default method _and_ only fetching the new method when you > need it. > > So you've squashed a nested for-loop and you're only fetching the > new method when you know you need it. Nicely done. Thanks > > src/share/vm/oops/cpCache.hpp > line 482: void adjust_method_entries(InstanceKlass* holder, bool * > trace_name_printed); > Nit - this line (and the previous) one have a space between > 'bool' and '*'. The other pointer params do not. Seems to be > a common format difference in 'bool *' params. :-) I agree, it is better to fix it as the line is touched anyway. > > src/share/vm/oops/cpCache.cpp > No comments. > > src/share/vm/oops/klassVtable.hpp > No comments. > > src/share/vm/oops/klassVtable.cpp > klassVtable::adjust_method_entries() and > klassItable::adjust_method_entries() have similar > loop squashing. Again, nicely done. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. I'm also thinking how to optimize this call: 3438 for (InstanceKlass* pv_node = ik->previous_versions(); 3439 pv_node != NULL; 3440 pv_node = pv_node->previous_versions()) { 3441 cp_cache = pv_node->constants()->cache(); 3442 if (cp_cache != NULL) { 3443 cp_cache->adjust_method_entries(_matching_old_methods, 3444 _matching_new_methods, 3445 _matching_methods_length, 3446 &trace_name_printed); 3447 } 3448 } But I left it for possible future improvement that is covered by new bug: https://bugs.openjdk.java.net/browse/JDK-8073705 > > src/share/vm/classfile/defaultMethods.cpp > No comments. > > src/share/vm/oops/constMethod.hpp > Cool way of using a little bit of space to squash > some loops. Surprised Coleen let you have a u2 though :-) Yes, I'm grateful to Coleen that she suggested it! :) > > src/share/vm/oops/method.hpp > No comments. > > src/share/vm/oops/method.cpp > No comments. > > Nit - double check copyright updates before you commit. Sure, that was my plan. Thanks! Serguei > > Dan > > > > >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> Thanks, >> Serguei >> >> >> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8046246 >>> >>> >>> Open hotspot webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >>> >>> >>> Open jdk (new unit test) webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >>> >>> >>> >>> Summary: >>> >>> This performance/scalability issue in class redefinition was >>> reported by HP and the Enterprise Manager team. >>> The following variants of the adjust_method_entries() functions >>> do not scale: >>> ConstantPoolCache::adjust_method_entries() >>> klassVtable::adjust_method_entries() >>> klassItable::adjust_method_entries() >>> InstanceKlass::adjust_default_methods() >>> >>> The ConstantPoolCache::adjust_method_entries() is the most >>> important. >>> >>> The approach is to use the holder->method_with_idnum() like this: >>> Method* new_method = >>> holder->method_with_idnum(old_method->orig_method_idnum()); >>> if (old_method != new_method) { >>> >>> } >>> >>> New algorithm has effectiveness O(M) instead of original O(M^2), >>> where M is count of methods in the class. >>> The new test (see webrev above) was used to mesure CPU time >>> consumed by the >>> ConstantPoolCache::adjust_method_entries() in both original and >>> new approach. >>> >>> The performance numbers are: >>> >>> --------------------------------------------------------------------------------------- >>> >>> Methods: ------ 1,000 --------------- 10,000 ----------------- >>> 20,000 >>> --------------------------------------------------------------------------------------- >>> >>> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >>> 243,000,000 nsec (~400x) >>> New: 16,000 nsec (1x) 178,000 nsec (~10x) >>> 355,000 nsec (~20x) >>> --------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Testing: >>> In progress: VM SQE RedefineClasses tests, JTREG >>> java/lang/instrument, com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at gmail.com Wed Feb 25 05:59:28 2015 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Wed, 25 Feb 2015 09:59:28 +0400 Subject: RFR (S) : 8073607 : add trace events for inlining In-Reply-To: <54ECE8E0.2080201@oracle.com> References: <54ECE8E0.2080201@oracle.com> Message-ID: Hi Igor, I guess that 'opto' in event's path stands for 'optimization', but it looks a bit confusing, because 'opto' is used as a C2's name elsewhere. Thanks, Filipp. On Wed, Feb 25, 2015 at 12:10 AM, Igor Ignatyev wrote: > Hi guys, > > could you please review the patch which adds trace events for inlining for > c1/c2 compiler? > > An added event provides information about caller, callee, bci, inline status > and message. > > webrev : http://cr.openjdk.java.net/~iignatyev/8073607/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8073607 > -- > Igor From daniel.daugherty at oracle.com Wed Feb 25 14:08:09 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Feb 2015 07:08:09 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54ED17EE.5040108@oracle.com> References: <54E3B646.8050209@oracle.com> <54E3C3B9.7040505@oracle.com> <54E3E29F.2010000@oracle.com> <54E4BDB5.8080305@oracle.com> <54E54445.4030506@oracle.com> <54E66BBA.80401@oracle.com> <54ED17EE.5040108@oracle.com> Message-ID: <54EDD749.1060907@oracle.com> David, Thanks for chasing this point to ground. My spelunking was faulty and I mistook the indent change on the fence() line made by 7127792 as origin. Dan On 2/24/15 5:31 PM, David Holmes wrote: > Hi Dan, > > Just one follow up, the OrderAccess::fence was not added by 7127792 > but was added as part of the embedded support code (for non-TSO > systems) in JDK 7 under: > > 6953477: Increase portability and flexibility of building Hotspot > > https://bugs.openjdk.java.net/browse/JDK-6953477 > > That code also made _should_terminate volatile. There was no locking > then, the WatcherThread::stop did: > > _should_terminate = true; > OrderAccess::fence(); // ensure WatcherThread sees update in main loop > Thread* watcher = watcher_thread(); > if (watcher != NULL) > watcher->_SleepEvent->unpark(); > > and the fence was used to ensure that the write to _should_terminate > was visible to the WT after the unpark, as WT::run did: > > jlong prev_time = os::javaTimeNanos(); > for (;;) { > int res= _SleepEvent->park(time_to_wait); > if (res == OS_TIMEOUT || _should_terminate) > break; > > Cheers, > David > > On 20/02/2015 9:03 AM, Daniel D. Daugherty wrote: >> On 2/18/15 7:02 PM, David Holmes wrote: >>> Hi Dan, >>> >>> On 19/02/2015 2:28 AM, Daniel D. Daugherty wrote: >>>> David, >>>> >>>> Thanks for the fast review! Replies embedded below... >>>> >>>> >>>> On 2/17/15 5:53 PM, David Holmes wrote: >>>>> Hi Dan, >>>>> >>>>> A few comments, mainly on the comments :) >>>> >>>> Apropos since the changeset is mostly comments... >>>> >>>> >>>>> >>>>> On 18/02/2015 8:42 AM, Daniel D. Daugherty wrote: >>>>>> On 2/17/15 3:22 PM, Carsten Varming wrote: >>>>>>> Dear Daniel, >>>>>>> >>>>>>> Looks good to me. >>>>>> >>>>>> Thanks for the fast review. >>>>>> >>>>>>> The line: "OrderAccess::fence(); // ensure WatcherThread sees >>>>>>> update >>>>>>> in main loop" seems unnecessary as the lock acts as a memory >>>>>>> barrier. >>>>>> >>>>>> Yes, I keep looking at that line from the original work on >>>>>> JDK-7127792 and wonder why it's there... I'll chase that down >>>>>> with the original folks... >>>>> >>>>> Only needed when using lock-free access, so can be removed now. >>> >>> Oops - my bad! >>> >>>> Yes, that will be the likely outcome. >>>> >>>> However, the original code added by JDK-7127792 wasn't lock-free so >>>> I still want to chase down the original thinking. >>> >>> The lock-free code was here: >>> >>> void WatcherThread::run() { >>> assert(this == watcher_thread(), "just checking"); >>> >>> this->record_stack_base_and_size(); >>> this->initialize_thread_local_storage(); >>> this->set_active_handles(JNIHandleBlock::allocate_block()); >>> while(!_should_terminate) { >>> >>> and of course you still have a lock-free access in the new code: >>> >>> 1300 if (_should_terminate) { >>> 1301 // check for termination before posting the next tick >>> 1302 break; >>> 1303 } >>> >>> so the fence() could stay, but its omission would be harmless I think >>> because not seeing the update immediately is no different to having >>> the update happen just after the check - it's racy code. The only >>> other option would be to always access _should_terminate with the >>> PeriodicTask_lock held - but that is subverting the intent of the lock >>> somewhat as _should_terminate is part of the WatcherThread state. >>> Actually the more I look at this the more I think the lock has already >>> been subverted to assist with the WT termination protocol. >> >> Just to make sure we're on the same page I think Carsten was >> talking about this block (from 8072439): >> >> 1334 { >> 1335 // Follow normal safepoint aware lock enter protocol since the >> 1336 // WatcherThread is stopped by another JavaThread. >> 1337 MutexLocker ml(PeriodicTask_lock); >> 1338 _should_terminate = true; >> 1339 OrderAccess::fence(); // ensure WatcherThread sees update in >> main loop >> 1340 >> 1341 WatcherThread* watcher = watcher_thread(); >> 1342 if (watcher != NULL) { >> 1343 // unpark the WatcherThread so it can see that it should >> terminate >> 1344 watcher->unpark(); >> 1345 } >> 1346 } >> >> where the fence() on line 1339 is not needed because when we drop >> the PeriodicTask_lock on line 1346 we get a fence() equivalent. >> >> This is the block before my fix for JDK-8047720: >> >> 1360 { >> 1361 MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> 1362 _should_terminate = true; >> 1363 OrderAccess::fence(); // ensure WatcherThread sees update in >> main loop >> 1364 >> 1365 WatcherThread* watcher = watcher_thread(); >> 1366 if (watcher != NULL) >> 1367 watcher->unpark(); >> 1368 } >> >> It has the same fence() call and the same lock exit (on different >> line numbers) so I'm wondering about the original thinking here. >> I still haven't heard back from Rickard... >> >> >>> >>>> >>>>> java.cpp: >>>>> >>>>> Typo: likelyhood -> likelihood >>>> >>>> Fixed. >>>> >>>> >>>>> --- >>>>> >>>>> task.cpp >>>>> >>>>> 81 int PeriodicTask::time_to_wait() { >>>>> 82 assert(Thread::current()->is_Watcher_thread(), "must be >>>>> WatcherThread"); >>>>> >>>>> This is currently true but not sure it has to be true. If we are >>>>> assuming/constraining a subset of the task API to only be callable by >>>>> the WatcherThread then perhaps we should document that in task.hpp ? >>>>> And as the WatcherThread is a friend, none of those methods need >>>>> to be >>>>> public - ie execute_if_pending and time_to_wait (realtime_tick is >>>>> already private). >>>> >>>> I was too focused on adding asserts that enforced how it works today >>>> and not on how it might be used down the road. There's no reason to >>>> restrict the caller of time_to_wait() to the WatcherThread. I've >>>> deleted the assert on line 82 and I added a comment to task.hpp: >>>> >>>> // Requires the PeriodicTask_lock. >>>> static int time_to_wait(); >>>> >>>> By leaving time_to_wait() public, that allows code other than the >>>> WatcherThread to use it perhaps for debugging... >>> >>> Okay. I still think the API is somewhat confused about its public >>> interface - execute_if_pending should be protected for use by WT only >>> (and subclasses implement it of course). >> >> Yes, but I think I'll leave that for another bug (probably to >> be fixed by someone else). >> >> >>> >>>> >>>>> 112 void PeriodicTask::enroll() { >>>>> 113 // Follow normal safepoint aware lock enter protocol if the >>>>> caller does >>>>> 114 // not already own the PeriodicTask_lock. Otherwise, we don't >>>>> try to >>>>> 115 // enter it again to avoid deadlocking with a safepoint that >>>>> started >>>>> 116 // after the initial enter and before this enter. >>>>> 117 // >>>>> 118 MutexLockerEx ml(PeriodicTask_lock->owned_by_self() ? NULL >>>>> 119 : >>>>> PeriodicTask_lock); >>>>> >>>>> The deadlock is not with a safepoint interaction but the normal >>>>> self-deadlock that would occur trying to lock() a Monitor/Mutex that >>>>> you already own. (Monitors/Mutexes do not support recursive locking - >>>>> in contrast to ObjectMonitors.) Ditto for disenroll. >>>> >>>> I have been working on Java Monitors for waaaayyyy too long! >>> >>> :) >>> >>>> In the header comment for src/share/vm/runtime/mutex.cpp: >>>> >>>> // Native Monitors do *not* support nesting or recursion but ... >>>> >>>> >>>>> The original comment is the correct one with respect to acquiring >>>>> with >>>>> a safepoint check if not already locked: >>>>> >>>>> /* XXX could be called from a JavaThread, so we have to check for >>>>> * safepoint when taking the lock to avoid deadlocking */ >>>> >>>> I'm still not fond of that comment. Perhaps: >>>> >>>> // Follow normal safepoint aware lock enter protocol if the caller >>>> does >>>> // not already own the PeriodicTask_lock. Otherwise, we don't >>>> try to >>>> // enter it again because VM internal Mutexes do not support >>>> recursion. >>>> >>>> I'm trying to make it clear that we're following safepoint aware >>>> protocol >>>> even though we're using MutexLockerEx. I also wanted a clear statement >>>> about why we skipped the enter if we already owned the lock. I don't >>>> think that we could be called from a JavaThread to be the important >>>> part. >>> >>> Being a JavaThread is the only reason the safepoint protocol has to be >>> considered - for non-JavaThreads we won't look at the safepoint state. >>> >>> The enroll() and disenroll() methods are called from the JavaThreads >>> and they can not be considered "leaf" methods, so they must obey the >>> safepoint protocol wrt the lock. >>> >>> Anyway your comment is fine. >> >> Thanks. >> >> >>> >>>> >>>>> --- >>>>> >>>>> thread.cpp: >>>>> >>>>> 1198 int WatcherThread::sleep() const { >>>>> 1199 // The WatcherThread does not honor the safepoint protocol for >>>>> 1200 // PeriodicTask_lock in order to provide more consistent task >>>>> 1201 // execution timing. >>>>> >>>>> Not sure that is really the correct characterisation. The WT doesn't >>>>> need to honor the safepoint protocol because it isn't a JavaThread >>>>> and >>>>> so won't block even if a safepoint is in progress. So checking for a >>>>> safepoint is simply a waste of time. >>>> >>>> Much better way of putting it. Thanks! How about: >>>> >>>> // The WatcherThread is not a JavaThread so we do not honor the >>>> // safepoint protocol for the PeriodicTask_lock. >>> >>> Ok. >> >> Thanks. >> >> >>> >>>> >>>>> >>>>> 3565 MutexLocker ml(PeriodicTask_lock); >>>>> >>>>> Why did you allow for a safepoint check here? It would only be >>>>> necessary if a JavaThread might concurrently acquire the >>>>> PeriodicTask_lock and a safepoint is initiated - during VM >>>>> initialization. Not completely impossible I guess but have never >>>>> heard >>>>> of this occurring, so would require some other startup change to >>>>> trigger it. >>>> >>>> There's no good reason to use MutexLockerEx here and I didn't >>>> want to write a comment explaining why we were using one. >>>> Earlier code in Threads::create_vm() uses MutexLocker instead >>>> of MutexLockerEx. >>> >>> Okay. Change is harmless. >> >> Cool. I think we're on the same page. >> >> Thanks again for the reviews. >> >> Dan >>> >>> Cheers, >>> David >>> >>>> >>>> Thanks again for the very thorough review! >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> Carsten >>>>>>> >>>>>>> On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> My fix for the following bug: >>>>>>> >>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>> >>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>> >>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com >>>>>>> ) and Carsten >>>>>>> Varming (varming at gmail.com ) for >>>>>>> reporting the mess that I made >>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>> >>>>>>> This code review is for a general cleanup pass on >>>>>>> PeriodicTask_lock >>>>>>> and some of the surrounding code. This is a targeted review in >>>>>>> that >>>>>>> I would like to hear from three groups of people: >>>>>>> >>>>>>> 1) The author and reviewers for: >>>>>>> >>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>> PeriodicTask's >>>>>>> execution interval >>>>>>> >>>>>>> Rickard, David H, and Markus G. >>>>>>> >>>>>>> 2) The reviewers for: >>>>>>> >>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>> >>>>>>> Markus G and Coleen >>>>>>> >>>>>>> 3) Alex and Carsten >>>>>>> >>>>>>> >>>>>>> Here's the webrev URL: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>> will be done with this fix. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>> >>>> >> From coleen.phillimore at oracle.com Wed Feb 25 14:31:23 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Feb 2015 09:31:23 -0500 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54ED3A86.1050301@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> <54ED3A86.1050301@oracle.com> Message-ID: <54EDDCBB.6070405@oracle.com> On 2/24/15, 9:59 PM, Daniel D. Daugherty wrote: > On 2/20/15 2:32 PM, serguei.spitsyn at oracle.com wrote: >> The hotspot webrev below addresses the Coleen's comments from the >> 1-st review round. >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> > > Thumbs up! > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > InstanceKlass::adjust_default_methods() - so you drop the outer level > of for-loop here by switching from parallel old_methods/new_methods > arrays to looping on the target array (default methods) and only > fetching the old_method candidate that's in parallel with the > current default method _and_ only fetching the new method when you > need it. > > So you've squashed a nested for-loop and you're only fetching the > new method when you know you need it. Nicely done. > > src/share/vm/oops/cpCache.hpp > line 482: void adjust_method_entries(InstanceKlass* holder, bool * > trace_name_printed); > Nit - this line (and the previous) one have a space between > 'bool' and '*'. The other pointer params do not. Seems to be > a common format difference in 'bool *' params. :-) > > src/share/vm/oops/cpCache.cpp > No comments. > > src/share/vm/oops/klassVtable.hpp > No comments. > > src/share/vm/oops/klassVtable.cpp > klassVtable::adjust_method_entries() and > klassItable::adjust_method_entries() have similar > loop squashing. Again, nicely done. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > src/share/vm/classfile/defaultMethods.cpp > No comments. > > src/share/vm/oops/constMethod.hpp > Cool way of using a little bit of space to squash > some loops. Surprised Coleen let you have a u2 though :-) I'm pretty sure it was an alignment gap on 64 bits and it needs to be u2. Coleen > > src/share/vm/oops/method.hpp > No comments. > > src/share/vm/oops/method.cpp > No comments. > > Nit - double check copyright updates before you commit. > > Dan > > > > >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> Thanks, >> Serguei >> >> >> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8046246 >>> >>> >>> Open hotspot webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >>> >>> >>> Open jdk (new unit test) webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >>> >>> >>> >>> Summary: >>> >>> This performance/scalability issue in class redefinition was >>> reported by HP and the Enterprise Manager team. >>> The following variants of the adjust_method_entries() functions >>> do not scale: >>> ConstantPoolCache::adjust_method_entries() >>> klassVtable::adjust_method_entries() >>> klassItable::adjust_method_entries() >>> InstanceKlass::adjust_default_methods() >>> >>> The ConstantPoolCache::adjust_method_entries() is the most >>> important. >>> >>> The approach is to use the holder->method_with_idnum() like this: >>> Method* new_method = >>> holder->method_with_idnum(old_method->orig_method_idnum()); >>> if (old_method != new_method) { >>> >>> } >>> >>> New algorithm has effectiveness O(M) instead of original O(M^2), >>> where M is count of methods in the class. >>> The new test (see webrev above) was used to mesure CPU time >>> consumed by the >>> ConstantPoolCache::adjust_method_entries() in both original and >>> new approach. >>> >>> The performance numbers are: >>> >>> --------------------------------------------------------------------------------------- >>> >>> Methods: ------ 1,000 --------------- 10,000 ----------------- >>> 20,000 >>> --------------------------------------------------------------------------------------- >>> >>> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >>> 243,000,000 nsec (~400x) >>> New: 16,000 nsec (1x) 178,000 nsec (~10x) >>> 355,000 nsec (~20x) >>> --------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Testing: >>> In progress: VM SQE RedefineClasses tests, JTREG >>> java/lang/instrument, com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From daniel.daugherty at oracle.com Wed Feb 25 17:00:21 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Feb 2015 10:00:21 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54E4C535.5060506@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> Message-ID: <54EDFFA5.9070407@oracle.com> This should be the last webrev: http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ Coleen, since you were one of my reviewers on JDK-8047720, I'd like to hear from you in this hopefully final round... Dan On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: > Greetings, > > Here is an updated webrev after addressing David H's comments: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ > > Also, here is the bug's URL: > > JDK-8072439 fix for 8047720 may need more work > https://bugs.openjdk.java.net/browse/JDK-8072439 > > Update for testing: I'm taking the new Remote Build and Test (RBT) > system for a ride during its beta period so I won't be doing direct > Aurora Adhoc jobs... > > Dan > > > On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> My fix for the following bug: >> >> JDK-8047720 Xprof hangs on Solaris >> >> that was pushed to JDK9 last June needs to be cleaned up. >> >> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >> Varming (varming at gmail.com) for reporting the mess that I made >> in WatcherThread::stop() and for suggesting fixes. >> >> This code review is for a general cleanup pass on PeriodicTask_lock >> and some of the surrounding code. This is a targeted review in that >> I would like to hear from three groups of people: >> >> 1) The author and reviewers for: >> >> JDK-7127792 Add the ability to change an existing PeriodicTask's >> execution interval >> >> Rickard, David H, and Markus G. >> >> 2) The reviewers for: >> >> JDK-8047720 Xprof hangs on Solaris >> >> Markus G and Coleen >> >> 3) Alex and Carsten >> >> >> Here's the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >> >> I've attached the original RFR for JDK-8047720 that explains >> the original deadlock that was being fixed. Similar testing >> will be done with this fix. >> >> Dan > > > From markus.gronlund at oracle.com Wed Feb 25 17:30:48 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 25 Feb 2015 09:30:48 -0800 (PST) Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EDFFA5.9070407@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> Message-ID: <5c1f2db5-b714-49a5-a8d7-f63017d25153@default> Thumbs up! Thanks Markus -----Original Message----- From: Daniel D. Daugherty Sent: den 25 februari 2015 18:00 To: Alexander Garthwaite; Carsten Varming; Rickard B?ckman; David Holmes; Markus Gr?nlund; Coleen Phillimore Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) This should be the last webrev: http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ Coleen, since you were one of my reviewers on JDK-8047720, I'd like to hear from you in this hopefully final round... Dan On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: > Greetings, > > Here is an updated webrev after addressing David H's comments: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ > > Also, here is the bug's URL: > > JDK-8072439 fix for 8047720 may need more work > https://bugs.openjdk.java.net/browse/JDK-8072439 > > Update for testing: I'm taking the new Remote Build and Test (RBT) > system for a ride during its beta period so I won't be doing direct > Aurora Adhoc jobs... > > Dan > > > On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> My fix for the following bug: >> >> JDK-8047720 Xprof hangs on Solaris >> >> that was pushed to JDK9 last June needs to be cleaned up. >> >> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >> Varming (varming at gmail.com) for reporting the mess that I made in >> WatcherThread::stop() and for suggesting fixes. >> >> This code review is for a general cleanup pass on PeriodicTask_lock >> and some of the surrounding code. This is a targeted review in that I >> would like to hear from three groups of people: >> >> 1) The author and reviewers for: >> >> JDK-7127792 Add the ability to change an existing PeriodicTask's >> execution interval >> >> Rickard, David H, and Markus G. >> >> 2) The reviewers for: >> >> JDK-8047720 Xprof hangs on Solaris >> >> Markus G and Coleen >> >> 3) Alex and Carsten >> >> >> Here's the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >> >> I've attached the original RFR for JDK-8047720 that explains the >> original deadlock that was being fixed. Similar testing will be done >> with this fix. >> >> Dan > > > From daniel.daugherty at oracle.com Wed Feb 25 18:25:22 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Feb 2015 11:25:22 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <5c1f2db5-b714-49a5-a8d7-f63017d25153@default> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <5c1f2db5-b714-49a5-a8d7-f63017d25153@default> Message-ID: <54EE1392.2060903@oracle.com> Thanks for the fast re-review! Dan On 2/25/15 10:30 AM, Markus Gronlund wrote: > Thumbs up! > > Thanks > Markus > > -----Original Message----- > From: Daniel D. Daugherty > Sent: den 25 februari 2015 18:00 > To: Alexander Garthwaite; Carsten Varming; Rickard B?ckman; David Holmes; Markus Gr?nlund; Coleen Phillimore > Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Subject: Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) > > This should be the last webrev: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ > > Coleen, since you were one of my reviewers on JDK-8047720, I'd like to hear from you in this hopefully final round... > > Dan > > > > On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Here is an updated webrev after addressing David H's comments: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >> >> Also, here is the bug's URL: >> >> JDK-8072439 fix for 8047720 may need more work >> https://bugs.openjdk.java.net/browse/JDK-8072439 >> >> Update for testing: I'm taking the new Remote Build and Test (RBT) >> system for a ride during its beta period so I won't be doing direct >> Aurora Adhoc jobs... >> >> Dan >> >> >> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> My fix for the following bug: >>> >>> JDK-8047720 Xprof hangs on Solaris >>> >>> that was pushed to JDK9 last June needs to be cleaned up. >>> >>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>> Varming (varming at gmail.com) for reporting the mess that I made in >>> WatcherThread::stop() and for suggesting fixes. >>> >>> This code review is for a general cleanup pass on PeriodicTask_lock >>> and some of the surrounding code. This is a targeted review in that I >>> would like to hear from three groups of people: >>> >>> 1) The author and reviewers for: >>> >>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>> execution interval >>> >>> Rickard, David H, and Markus G. >>> >>> 2) The reviewers for: >>> >>> JDK-8047720 Xprof hangs on Solaris >>> >>> Markus G and Coleen >>> >>> 3) Alex and Carsten >>> >>> >>> Here's the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>> >>> I've attached the original RFR for JDK-8047720 that explains the >>> original deadlock that was being fixed. Similar testing will be done >>> with this fix. >>> >>> Dan >> >> > From varming at gmail.com Wed Feb 25 19:56:11 2015 From: varming at gmail.com (Carsten Varming) Date: Wed, 25 Feb 2015 11:56:11 -0800 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EE1392.2060903@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <5c1f2db5-b714-49a5-a8d7-f63017d25153@default> <54EE1392.2060903@oracle.com> Message-ID: Still looking good to me. Carsten On Wed, Feb 25, 2015 at 10:25 AM, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Thanks for the fast re-review! > > Dan > > > > On 2/25/15 10:30 AM, Markus Gronlund wrote: > >> Thumbs up! >> >> Thanks >> Markus >> >> -----Original Message----- >> From: Daniel D. Daugherty >> Sent: den 25 februari 2015 18:00 >> To: Alexander Garthwaite; Carsten Varming; Rickard B?ckman; David Holmes; >> Markus Gr?nlund; Coleen Phillimore >> Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk. >> java.net >> Subject: Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) >> >> This should be the last webrev: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >> >> Coleen, since you were one of my reviewers on JDK-8047720, I'd like to >> hear from you in this hopefully final round... >> >> Dan >> >> >> >> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> Here is an updated webrev after addressing David H's comments: >>> >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>> >>> Also, here is the bug's URL: >>> >>> JDK-8072439 fix for 8047720 may need more work >>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>> >>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>> system for a ride during its beta period so I won't be doing direct >>> Aurora Adhoc jobs... >>> >>> Dan >>> >>> >>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> My fix for the following bug: >>>> >>>> JDK-8047720 Xprof hangs on Solaris >>>> >>>> that was pushed to JDK9 last June needs to be cleaned up. >>>> >>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>> Varming (varming at gmail.com) for reporting the mess that I made in >>>> WatcherThread::stop() and for suggesting fixes. >>>> >>>> This code review is for a general cleanup pass on PeriodicTask_lock >>>> and some of the surrounding code. This is a targeted review in that I >>>> would like to hear from three groups of people: >>>> >>>> 1) The author and reviewers for: >>>> >>>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>>> execution interval >>>> >>>> Rickard, David H, and Markus G. >>>> >>>> 2) The reviewers for: >>>> >>>> JDK-8047720 Xprof hangs on Solaris >>>> >>>> Markus G and Coleen >>>> >>>> 3) Alex and Carsten >>>> >>>> >>>> Here's the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>> >>>> I've attached the original RFR for JDK-8047720 that explains the >>>> original deadlock that was being fixed. Similar testing will be done >>>> with this fix. >>>> >>>> Dan >>>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Feb 25 20:07:46 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Feb 2015 13:07:46 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <5c1f2db5-b714-49a5-a8d7-f63017d25153@default> <54EE1392.2060903@oracle.com> Message-ID: <54EE2B92.9090701@oracle.com> Carsten, Thanks for the fast re-review. Dan On 2/25/15 12:56 PM, Carsten Varming wrote: > Still looking good to me. > > Carsten > > On Wed, Feb 25, 2015 at 10:25 AM, Daniel D. Daugherty > > wrote: > > Thanks for the fast re-review! > > Dan > > > > On 2/25/15 10:30 AM, Markus Gronlund wrote: > > Thumbs up! > > Thanks > Markus > > -----Original Message----- > From: Daniel D. Daugherty > Sent: den 25 februari 2015 18:00 > To: Alexander Garthwaite; Carsten Varming; Rickard B?ckman; > David Holmes; Markus Gr?nlund; Coleen Phillimore > Cc: hotspot-runtime-dev at openjdk.java.net > ; > serviceability-dev at openjdk.java.net > > Subject: Re: RFR(XS) for PeriodicTask_lock cleanup (8072439) > > This should be the last webrev: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ > > > Coleen, since you were one of my reviewers on JDK-8047720, I'd > like to hear from you in this hopefully final round... > > Dan > > > > On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: > > Greetings, > > Here is an updated webrev after addressing David H's comments: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ > > > Also, here is the bug's URL: > > JDK-8072439 fix for 8047720 may need more work > https://bugs.openjdk.java.net/browse/JDK-8072439 > > Update for testing: I'm taking the new Remote Build and > Test (RBT) > system for a ride during its beta period so I won't be > doing direct > Aurora Adhoc jobs... > > Dan > > > On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: > > Greetings, > > My fix for the following bug: > > JDK-8047720 Xprof hangs on Solaris > > that was pushed to JDK9 last June needs to be cleaned up. > > Thanks to Alex Garthwaite (agarthwaite at twitter.com > ) and Carsten > Varming (varming at gmail.com ) > for reporting the mess that I made in > WatcherThread::stop() and for suggesting fixes. > > This code review is for a general cleanup pass on > PeriodicTask_lock > and some of the surrounding code. This is a targeted > review in that I > would like to hear from three groups of people: > > 1) The author and reviewers for: > > JDK-7127792 Add the ability to change an existing > PeriodicTask's > execution interval > > Rickard, David H, and Markus G. > > 2) The reviewers for: > > JDK-8047720 Xprof hangs on Solaris > > Markus G and Coleen > > 3) Alex and Carsten > > > Here's the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ > > > I've attached the original RFR for JDK-8047720 that > explains the > original deadlock that was being fixed. Similar > testing will be done > with this fix. > > Dan > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Feb 26 03:44:54 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Feb 2015 22:44:54 -0500 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EDFFA5.9070407@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> Message-ID: <54EE96B6.7050409@oracle.com> Hi, I think you have better reviewer for this now but I did have a couple of questions. in http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html This comment is really confusing because I think you do in fact honor the safepoint protocol sometimes for the WatcherThread, true? 65 // The WatcherThread is not a JavaThread so we do not honor the 66 // safepoint protocol for the PeriodicTask_lock. 67 MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); Because WatcherThread::stop() does safepoint check. It's unclear whether enroll and disenroll can be called by the WatcherThread also. If so, should they have no_safepoint_check. The whole safepoint checking inconsistency still makes me nervous, but the comment seems misleading. I honestly don't know enough about the rest to review it. thanks, Coleen On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: > This should be the last webrev: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ > > Coleen, since you were one of my reviewers on JDK-8047720, I'd like > to hear from you in this hopefully final round... > > Dan > > > > On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Here is an updated webrev after addressing David H's comments: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >> >> Also, here is the bug's URL: >> >> JDK-8072439 fix for 8047720 may need more work >> https://bugs.openjdk.java.net/browse/JDK-8072439 >> >> Update for testing: I'm taking the new Remote Build and Test (RBT) >> system for a ride during its beta period so I won't be doing direct >> Aurora Adhoc jobs... >> >> Dan >> >> >> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> My fix for the following bug: >>> >>> JDK-8047720 Xprof hangs on Solaris >>> >>> that was pushed to JDK9 last June needs to be cleaned up. >>> >>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>> Varming (varming at gmail.com) for reporting the mess that I made >>> in WatcherThread::stop() and for suggesting fixes. >>> >>> This code review is for a general cleanup pass on PeriodicTask_lock >>> and some of the surrounding code. This is a targeted review in that >>> I would like to hear from three groups of people: >>> >>> 1) The author and reviewers for: >>> >>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>> execution interval >>> >>> Rickard, David H, and Markus G. >>> >>> 2) The reviewers for: >>> >>> JDK-8047720 Xprof hangs on Solaris >>> >>> Markus G and Coleen >>> >>> 3) Alex and Carsten >>> >>> >>> Here's the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>> >>> I've attached the original RFR for JDK-8047720 that explains >>> the original deadlock that was being fixed. Similar testing >>> will be done with this fix. >>> >>> Dan >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Feb 26 03:59:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 13:59:33 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EE96B6.7050409@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> Message-ID: <54EE9A25.1050808@oracle.com> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: > > Hi, I think you have better reviewer for this now but I did have a > couple of questions. > > in > http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html > > This comment is really confusing because I think you do in fact honor > the safepoint protocol sometimes for the WatcherThread, true? Depends what you mean by "honor the safepoint protocol". The WatcherThread will sometimes acquire locks that potentially check the safepoint state, but as it is not a JavaThread such paths are never actually taken. Hence we can call the code that will never consider taking them if the only caller of that code (as in this case) is a non-JavaThread. > 65 // The WatcherThread is not a JavaThread so we do not honor the > 66 // safepoint protocol for the PeriodicTask_lock. > 67 MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > > Because WatcherThread::stop() does safepoint check. It's unclear > whether enroll and disenroll can be called by the WatcherThread also. > If so, should they have no_safepoint_check. You can only use MutexLockerEx with _no_safepoint_check_flag if you never want to check for safepoints. If the only caller is a non-JavaThread then that is trivially true. If the caller can be a JavaThread then safepoint checking can only be elided under very specific circumstances (ie leaf methods with other constraints). If the lock is to be acquired by JavaThreads, as is the case with enrol/disenrol then we should check for safepoints (as the conditions for eliding safepoint checks for JavaThreads are not met by those methods). > The whole safepoint checking inconsistency still makes me nervous, but > the comment seems misleading. Hope it is clearer now. David > > I honestly don't know enough about the rest to review it. > > thanks, > Coleen > > On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >> This should be the last webrev: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >> >> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >> to hear from you in this hopefully final round... >> >> Dan >> >> >> >> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Here is an updated webrev after addressing David H's comments: >>> >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>> >>> Also, here is the bug's URL: >>> >>> JDK-8072439 fix for 8047720 may need more work >>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>> >>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>> system for a ride during its beta period so I won't be doing direct >>> Aurora Adhoc jobs... >>> >>> Dan >>> >>> >>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> My fix for the following bug: >>>> >>>> JDK-8047720 Xprof hangs on Solaris >>>> >>>> that was pushed to JDK9 last June needs to be cleaned up. >>>> >>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>> Varming (varming at gmail.com) for reporting the mess that I made >>>> in WatcherThread::stop() and for suggesting fixes. >>>> >>>> This code review is for a general cleanup pass on PeriodicTask_lock >>>> and some of the surrounding code. This is a targeted review in that >>>> I would like to hear from three groups of people: >>>> >>>> 1) The author and reviewers for: >>>> >>>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>>> execution interval >>>> >>>> Rickard, David H, and Markus G. >>>> >>>> 2) The reviewers for: >>>> >>>> JDK-8047720 Xprof hangs on Solaris >>>> >>>> Markus G and Coleen >>>> >>>> 3) Alex and Carsten >>>> >>>> >>>> Here's the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>> >>>> I've attached the original RFR for JDK-8047720 that explains >>>> the original deadlock that was being fixed. Similar testing >>>> will be done with this fix. >>>> >>>> Dan >>> >>> >>> >> > From coleen.phillimore at oracle.com Thu Feb 26 04:46:15 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Feb 2015 23:46:15 -0500 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EE9A25.1050808@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> Message-ID: <54EEA517.1040708@oracle.com> On 2/25/15, 10:59 PM, David Holmes wrote: > On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >> >> Hi, I think you have better reviewer for this now but I did have a >> couple of questions. >> >> in >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >> >> >> This comment is really confusing because I think you do in fact honor >> the safepoint protocol sometimes for the WatcherThread, true? > > Depends what you mean by "honor the safepoint protocol". The > WatcherThread will sometimes acquire locks that potentially check the > safepoint state, but as it is not a JavaThread such paths are never > actually taken. Hence we can call the code that will never consider > taking them if the only caller of that code (as in this case) is a > non-JavaThread. So you could theoretically have the watcher thread use the regular MutexLocker, which checks for safepoints, and somewhere behind the scenes, the safepoint check is elided. So the comment really doesn't explain what's going on, and leads one to believe that you need to be careful _not_ to take a safepoint check with the Watcher thread. I'll stop reading comments again. Thanks for the explanation though, the latter part I knew about. Coleen > >> 65 // The WatcherThread is not a JavaThread so we do not honor >> the >> 66 // safepoint protocol for the PeriodicTask_lock. >> 67 MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> >> Because WatcherThread::stop() does safepoint check. It's unclear >> whether enroll and disenroll can be called by the WatcherThread also. >> If so, should they have no_safepoint_check. > > You can only use MutexLockerEx with _no_safepoint_check_flag if you > never want to check for safepoints. If the only caller is a > non-JavaThread then that is trivially true. If the caller can be a > JavaThread then safepoint checking can only be elided under very > specific circumstances (ie leaf methods with other constraints). If > the lock is to be acquired by JavaThreads, as is the case with > enrol/disenrol then we should check for safepoints (as the conditions > for eliding safepoint checks for JavaThreads are not met by those > methods). > >> The whole safepoint checking inconsistency still makes me nervous, but >> the comment seems misleading. > > Hope it is clearer now. > > David > >> >> I honestly don't know enough about the rest to review it. >> >> thanks, >> Coleen >> >> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>> This should be the last webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>> >>> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >>> to hear from you in this hopefully final round... >>> >>> Dan >>> >>> >>> >>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Here is an updated webrev after addressing David H's comments: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>> >>>> Also, here is the bug's URL: >>>> >>>> JDK-8072439 fix for 8047720 may need more work >>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>> >>>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>>> system for a ride during its beta period so I won't be doing direct >>>> Aurora Adhoc jobs... >>>> >>>> Dan >>>> >>>> >>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> My fix for the following bug: >>>>> >>>>> JDK-8047720 Xprof hangs on Solaris >>>>> >>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>> >>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>> in WatcherThread::stop() and for suggesting fixes. >>>>> >>>>> This code review is for a general cleanup pass on PeriodicTask_lock >>>>> and some of the surrounding code. This is a targeted review in that >>>>> I would like to hear from three groups of people: >>>>> >>>>> 1) The author and reviewers for: >>>>> >>>>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>>>> execution interval >>>>> >>>>> Rickard, David H, and Markus G. >>>>> >>>>> 2) The reviewers for: >>>>> >>>>> JDK-8047720 Xprof hangs on Solaris >>>>> >>>>> Markus G and Coleen >>>>> >>>>> 3) Alex and Carsten >>>>> >>>>> >>>>> Here's the webrev URL: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>> >>>>> I've attached the original RFR for JDK-8047720 that explains >>>>> the original deadlock that was being fixed. Similar testing >>>>> will be done with this fix. >>>>> >>>>> Dan >>>> >>>> >>>> >>> >> From david.holmes at oracle.com Thu Feb 26 07:09:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 17:09:57 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EDFFA5.9070407@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> Message-ID: <54EEC6C5.7060903@oracle.com> On 26/02/2015 3:00 AM, Daniel D. Daugherty wrote: > This should be the last webrev: > > http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ Nothing further from me - looks good. Thanks, David > Coleen, since you were one of my reviewers on JDK-8047720, I'd like > to hear from you in this hopefully final round... > > Dan > > > > On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Here is an updated webrev after addressing David H's comments: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >> >> Also, here is the bug's URL: >> >> JDK-8072439 fix for 8047720 may need more work >> https://bugs.openjdk.java.net/browse/JDK-8072439 >> >> Update for testing: I'm taking the new Remote Build and Test (RBT) >> system for a ride during its beta period so I won't be doing direct >> Aurora Adhoc jobs... >> >> Dan >> >> >> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> My fix for the following bug: >>> >>> JDK-8047720 Xprof hangs on Solaris >>> >>> that was pushed to JDK9 last June needs to be cleaned up. >>> >>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>> Varming (varming at gmail.com) for reporting the mess that I made >>> in WatcherThread::stop() and for suggesting fixes. >>> >>> This code review is for a general cleanup pass on PeriodicTask_lock >>> and some of the surrounding code. This is a targeted review in that >>> I would like to hear from three groups of people: >>> >>> 1) The author and reviewers for: >>> >>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>> execution interval >>> >>> Rickard, David H, and Markus G. >>> >>> 2) The reviewers for: >>> >>> JDK-8047720 Xprof hangs on Solaris >>> >>> Markus G and Coleen >>> >>> 3) Alex and Carsten >>> >>> >>> Here's the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>> >>> I've attached the original RFR for JDK-8047720 that explains >>> the original deadlock that was being fixed. Similar testing >>> will be done with this fix. >>> >>> Dan >> >> >> > From david.holmes at oracle.com Thu Feb 26 07:13:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 17:13:55 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EEA517.1040708@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> Message-ID: <54EEC7B3.3070400@oracle.com> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: > > On 2/25/15, 10:59 PM, David Holmes wrote: >> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>> >>> Hi, I think you have better reviewer for this now but I did have a >>> couple of questions. >>> >>> in >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>> >>> >>> This comment is really confusing because I think you do in fact honor >>> the safepoint protocol sometimes for the WatcherThread, true? >> >> Depends what you mean by "honor the safepoint protocol". The >> WatcherThread will sometimes acquire locks that potentially check the >> safepoint state, but as it is not a JavaThread such paths are never >> actually taken. Hence we can call the code that will never consider >> taking them if the only caller of that code (as in this case) is a >> non-JavaThread. > > So you could theoretically have the watcher thread use the regular > MutexLocker, which checks for safepoints, and somewhere behind the > scenes, the safepoint check is elided. Yes, internally there is one path for JavaThreads and a different path for non-JavaThreads. JavaThreads perform thread-state transitions which form part of the safepoint protocol. > So the comment really doesn't explain what's going on, and leads one to > believe that you need to be careful _not_ to take a safepoint check with > the Watcher thread. I don't read it that way but would it be better if it said "do not _need to_ honor" instead? David ----- > I'll stop reading comments again. > > Thanks for the explanation though, the latter part I knew about. > > Coleen > >> >>> 65 // The WatcherThread is not a JavaThread so we do not honor >>> the >>> 66 // safepoint protocol for the PeriodicTask_lock. >>> 67 MutexLockerEx ml(PeriodicTask_lock, >>> Mutex::_no_safepoint_check_flag); >>> >>> >>> Because WatcherThread::stop() does safepoint check. It's unclear >>> whether enroll and disenroll can be called by the WatcherThread also. >>> If so, should they have no_safepoint_check. >> >> You can only use MutexLockerEx with _no_safepoint_check_flag if you >> never want to check for safepoints. If the only caller is a >> non-JavaThread then that is trivially true. If the caller can be a >> JavaThread then safepoint checking can only be elided under very >> specific circumstances (ie leaf methods with other constraints). If >> the lock is to be acquired by JavaThreads, as is the case with >> enrol/disenrol then we should check for safepoints (as the conditions >> for eliding safepoint checks for JavaThreads are not met by those >> methods). >> >>> The whole safepoint checking inconsistency still makes me nervous, but >>> the comment seems misleading. >> >> Hope it is clearer now. >> >> David >> >>> >>> I honestly don't know enough about the rest to review it. >>> >>> thanks, >>> Coleen >>> >>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>> This should be the last webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>> >>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >>>> to hear from you in this hopefully final round... >>>> >>>> Dan >>>> >>>> >>>> >>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Here is an updated webrev after addressing David H's comments: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>> >>>>> Also, here is the bug's URL: >>>>> >>>>> JDK-8072439 fix for 8047720 may need more work >>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>> >>>>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>>>> system for a ride during its beta period so I won't be doing direct >>>>> Aurora Adhoc jobs... >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> My fix for the following bug: >>>>>> >>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>> >>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>> >>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>> >>>>>> This code review is for a general cleanup pass on PeriodicTask_lock >>>>>> and some of the surrounding code. This is a targeted review in that >>>>>> I would like to hear from three groups of people: >>>>>> >>>>>> 1) The author and reviewers for: >>>>>> >>>>>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>>>>> execution interval >>>>>> >>>>>> Rickard, David H, and Markus G. >>>>>> >>>>>> 2) The reviewers for: >>>>>> >>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>> >>>>>> Markus G and Coleen >>>>>> >>>>>> 3) Alex and Carsten >>>>>> >>>>>> >>>>>> Here's the webrev URL: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>> >>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>> the original deadlock that was being fixed. Similar testing >>>>>> will be done with this fix. >>>>>> >>>>>> Dan >>>>> >>>>> >>>>> >>>> >>> > From markus.gronlund at oracle.com Fri Feb 27 10:25:16 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 27 Feb 2015 02:25:16 -0800 (PST) Subject: RFR (S) : 8073607 : add trace events for inlining In-Reply-To: <54ECE8E0.2080201@oracle.com> References: <54ECE8E0.2080201@oracle.com> Message-ID: <5e8ddad6-e877-481f-946f-0d5a7691c0be@default> Hi Igor, In trace.xml: 404 405 406 407 You don't need to write an individual UTF8 string for every class, method and desc as we have "intrinsics" for taking care of this for you. This also means you wouldn't need to create a separate struct, as you can just define the necessary fields as type METHOD in the CompilerInlining event: 411 412 413 414 415 416 417 // I also removed these attributes " is_requestable="false" is_constant="false" - they are defaults. I changed to "is_instant=true" since it looks like the event does not span over a duration in bytecodeInfo.cpp. At the event site, you will now need to pass the Hotspot Method* as the values (unsure how you pull that out of a ci* artifact, but you have the Metadata* for the Method there somewhere): result.set_caller(Method* caller_method); result.set_callee(Method* callee_method); Thanks Markus -----Original Message----- From: Igor Ignatyev Sent: den 24 februari 2015 22:11 To: hotspot-compiler-dev at openjdk.java.net compiler; serviceability-dev at openjdk.java.net Subject: RFR (S) : 8073607 : add trace events for inlining Hi guys, could you please review the patch which adds trace events for inlining for c1/c2 compiler? An added event provides information about caller, callee, bci, inline status and message. webrev : http://cr.openjdk.java.net/~iignatyev/8073607/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8073607 -- Igor From igor.ignatyev at oracle.com Fri Feb 27 10:30:22 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 27 Feb 2015 13:30:22 +0300 Subject: RFR (S) : 8073607 : add trace events for inlining In-Reply-To: <5e8ddad6-e877-481f-946f-0d5a7691c0be@default> References: <54ECE8E0.2080201@oracle.com> <5e8ddad6-e877-481f-946f-0d5a7691c0be@default> Message-ID: <54F0473E.8020806@oracle.com> Hi Markus, thank you for your review. we can't use Method instead of ciMethod since there are some cases then we have ciMethod but can't get Method from it, e.g. unresolved class. I think it makes sense to implement "intrinsics" for ciMethod/ciClass, can you advise me how to do that? Thanks, Igor On 02/27/2015 01:25 PM, Markus Gronlund wrote: > Hi Igor, > > In trace.xml: > > > 404 > 405 > 406 > 407 > > You don't need to write an individual UTF8 string for every class, method and desc as we have "intrinsics" for taking care of this for you. > > This also means you wouldn't need to create a separate struct, as you can just define the necessary fields as type METHOD in the CompilerInlining event: > > 410 has_thread="true" is_instant="true"> > 411 > 412 > 413 > 414 > 415 > 416 > 417 > > > // I also removed these attributes " is_requestable="false" is_constant="false" - they are defaults. I changed to "is_instant=true" since it looks like the event does not span over a duration in bytecodeInfo.cpp. > > At the event site, you will now need to pass the Hotspot Method* as the values (unsure how you pull that out of a ci* artifact, but you have the Metadata* for the Method there somewhere): > > result.set_caller(Method* caller_method); > result.set_callee(Method* callee_method); > > Thanks > Markus > > -----Original Message----- > From: Igor Ignatyev > Sent: den 24 februari 2015 22:11 > To: hotspot-compiler-dev at openjdk.java.net compiler; serviceability-dev at openjdk.java.net > Subject: RFR (S) : 8073607 : add trace events for inlining > > Hi guys, > > could you please review the patch which adds trace events for inlining for c1/c2 compiler? > > An added event provides information about caller, callee, bci, inline status and message. > > webrev : http://cr.openjdk.java.net/~iignatyev/8073607/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8073607 > -- > Igor > From markus.gronlund at oracle.com Fri Feb 27 10:37:06 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 27 Feb 2015 02:37:06 -0800 (PST) Subject: RFR (S) : 8073607 : add trace events for inlining In-Reply-To: <54F0473E.8020806@oracle.com> References: <54ECE8E0.2080201@oracle.com> <5e8ddad6-e877-481f-946f-0d5a7691c0be@default> <54F0473E.8020806@oracle.com> Message-ID: <55ed84d1-65b2-4c71-a453-b57a28cebe53@default> Are you saying that ciMethod does not always have a Method* to be referenced? In that case, my suggested approach will be problematic. Adding intrinsics are not trivial - we could probably take this outside this thread. If you cannot use Method*, then your struct approach is understandable. /Markus -----Original Message----- From: Igor Ignatyev Sent: den 27 februari 2015 11:30 To: Markus Gronlund Cc: hotspot-compiler-dev at openjdk.java.net compiler; serviceability-dev at openjdk.java.net Subject: Re: RFR (S) : 8073607 : add trace events for inlining Hi Markus, thank you for your review. we can't use Method instead of ciMethod since there are some cases then we have ciMethod but can't get Method from it, e.g. unresolved class. I think it makes sense to implement "intrinsics" for ciMethod/ciClass, can you advise me how to do that? Thanks, Igor On 02/27/2015 01:25 PM, Markus Gronlund wrote: > Hi Igor, > > In trace.xml: > > > 404 > 405 > 406 > 407 > > You don't need to write an individual UTF8 string for every class, method and desc as we have "intrinsics" for taking care of this for you. > > This also means you wouldn't need to create a separate struct, as you can just define the necessary fields as type METHOD in the CompilerInlining event: > > 410 has_thread="true" is_instant="true"> > 411 > 412 > 413 > 414 > 415 > 416 > 417 > > > // I also removed these attributes " is_requestable="false" is_constant="false" - they are defaults. I changed to "is_instant=true" since it looks like the event does not span over a duration in bytecodeInfo.cpp. > > At the event site, you will now need to pass the Hotspot Method* as the values (unsure how you pull that out of a ci* artifact, but you have the Metadata* for the Method there somewhere): > > result.set_caller(Method* caller_method); > result.set_callee(Method* callee_method); > > Thanks > Markus > > -----Original Message----- > From: Igor Ignatyev > Sent: den 24 februari 2015 22:11 > To: hotspot-compiler-dev at openjdk.java.net compiler; > serviceability-dev at openjdk.java.net > Subject: RFR (S) : 8073607 : add trace events for inlining > > Hi guys, > > could you please review the patch which adds trace events for inlining for c1/c2 compiler? > > An added event provides information about caller, callee, bci, inline status and message. > > webrev : http://cr.openjdk.java.net/~iignatyev/8073607/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8073607 > -- > Igor > From igor.ignatyev at oracle.com Fri Feb 27 10:47:57 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 27 Feb 2015 13:47:57 +0300 Subject: RFR (S) : 8073607 : add trace events for inlining In-Reply-To: <55ed84d1-65b2-4c71-a453-b57a28cebe53@default> References: <54ECE8E0.2080201@oracle.com> <5e8ddad6-e877-481f-946f-0d5a7691c0be@default> <54F0473E.8020806@oracle.com> <55ed84d1-65b2-4c71-a453-b57a28cebe53@default> Message-ID: <54F04B5D.1080200@oracle.com> On 02/27/2015 01:37 PM, Markus Gronlund wrote: > Are you saying that ciMethod does not always have a Method* to be referenced? right. e.g. one of ciMethod ctor[1] set _method_data (used as Method* in get_method[2]) to null. [1] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/6357f6686ca2/src/share/vm/ci/ciMethod.cpp#l172 [2] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/6357f6686ca2/src/share/vm/ci/ciMethod.hpp#l98 > > In that case, my suggested approach will be problematic. Adding intrinsics are not trivial - we could probably take this outside this thread. > > If you cannot use Method*, then your struct approach is understandable. > > /Markus > > -----Original Message----- > From: Igor Ignatyev > Sent: den 27 februari 2015 11:30 > To: Markus Gronlund > Cc: hotspot-compiler-dev at openjdk.java.net compiler; serviceability-dev at openjdk.java.net > Subject: Re: RFR (S) : 8073607 : add trace events for inlining > > Hi Markus, > > thank you for your review. > we can't use Method instead of ciMethod since there are some cases then we have ciMethod but can't get Method from it, e.g. unresolved class. I think it makes sense to implement "intrinsics" for ciMethod/ciClass, can you advise me how to do that? > > Thanks, > Igor > > On 02/27/2015 01:25 PM, Markus Gronlund wrote: >> Hi Igor, >> >> In trace.xml: >> >> >> 404 >> 405 >> 406 >> 407 >> >> You don't need to write an individual UTF8 string for every class, method and desc as we have "intrinsics" for taking care of this for you. >> >> This also means you wouldn't need to create a separate struct, as you can just define the necessary fields as type METHOD in the CompilerInlining event: >> >> > 410 has_thread="true" is_instant="true"> >> 411 >> 412 >> 413 >> 414 >> 415 >> 416 >> 417 >> >> >> // I also removed these attributes " is_requestable="false" is_constant="false" - they are defaults. I changed to "is_instant=true" since it looks like the event does not span over a duration in bytecodeInfo.cpp. >> >> At the event site, you will now need to pass the Hotspot Method* as the values (unsure how you pull that out of a ci* artifact, but you have the Metadata* for the Method there somewhere): >> >> result.set_caller(Method* caller_method); >> result.set_callee(Method* callee_method); >> >> Thanks >> Markus >> >> -----Original Message----- >> From: Igor Ignatyev >> Sent: den 24 februari 2015 22:11 >> To: hotspot-compiler-dev at openjdk.java.net compiler; >> serviceability-dev at openjdk.java.net >> Subject: RFR (S) : 8073607 : add trace events for inlining >> >> Hi guys, >> >> could you please review the patch which adds trace events for inlining for c1/c2 compiler? >> >> An added event provides information about caller, callee, bci, inline status and message. >> >> webrev : http://cr.openjdk.java.net/~iignatyev/8073607/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8073607 >> -- >> Igor >> From daniel.daugherty at oracle.com Fri Feb 27 15:22:07 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 27 Feb 2015 08:22:07 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EEC6C5.7060903@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EEC6C5.7060903@oracle.com> Message-ID: <54F08B9F.80801@oracle.com> On 2/26/15 12:09 AM, David Holmes wrote: > On 26/02/2015 3:00 AM, Daniel D. Daugherty wrote: >> This should be the last webrev: >> >> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ > > Nothing further from me - looks good. Thanks! Dan > > Thanks, > David > >> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >> to hear from you in this hopefully final round... >> >> Dan >> >> >> >> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Here is an updated webrev after addressing David H's comments: >>> >>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>> >>> Also, here is the bug's URL: >>> >>> JDK-8072439 fix for 8047720 may need more work >>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>> >>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>> system for a ride during its beta period so I won't be doing direct >>> Aurora Adhoc jobs... >>> >>> Dan >>> >>> >>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> My fix for the following bug: >>>> >>>> JDK-8047720 Xprof hangs on Solaris >>>> >>>> that was pushed to JDK9 last June needs to be cleaned up. >>>> >>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>> Varming (varming at gmail.com) for reporting the mess that I made >>>> in WatcherThread::stop() and for suggesting fixes. >>>> >>>> This code review is for a general cleanup pass on PeriodicTask_lock >>>> and some of the surrounding code. This is a targeted review in that >>>> I would like to hear from three groups of people: >>>> >>>> 1) The author and reviewers for: >>>> >>>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>>> execution interval >>>> >>>> Rickard, David H, and Markus G. >>>> >>>> 2) The reviewers for: >>>> >>>> JDK-8047720 Xprof hangs on Solaris >>>> >>>> Markus G and Coleen >>>> >>>> 3) Alex and Carsten >>>> >>>> >>>> Here's the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>> >>>> I've attached the original RFR for JDK-8047720 that explains >>>> the original deadlock that was being fixed. Similar testing >>>> will be done with this fix. >>>> >>>> Dan >>> >>> >>> >> From daniel.daugherty at oracle.com Fri Feb 27 15:46:37 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 27 Feb 2015 08:46:37 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54EEC7B3.3070400@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> Message-ID: <54F0915D.3050700@oracle.com> Coleen, Thanks for the review. Replies embedded below. David, Thanks for jumping in while I was out of the office yesterday. On 2/26/15 12:13 AM, David Holmes wrote: > On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >> >> On 2/25/15, 10:59 PM, David Holmes wrote: >>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>> >>>> Hi, I think you have better reviewer for this now but I did have a >>>> couple of questions. >>>> >>>> in >>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>> >>>> >>>> >>>> This comment is really confusing because I think you do in fact honor >>>> the safepoint protocol sometimes for the WatcherThread, true? >>> >>> Depends what you mean by "honor the safepoint protocol". The >>> WatcherThread will sometimes acquire locks that potentially check the >>> safepoint state, but as it is not a JavaThread such paths are never >>> actually taken. Hence we can call the code that will never consider >>> taking them if the only caller of that code (as in this case) is a >>> non-JavaThread. >> >> So you could theoretically have the watcher thread use the regular >> MutexLocker, which checks for safepoints, and somewhere behind the >> scenes, the safepoint check is elided. > > Yes, internally there is one path for JavaThreads and a different path > for non-JavaThreads. JavaThreads perform thread-state transitions > which form part of the safepoint protocol. So it looks like "honor the safepoint protocol" is bad choice of words. More below. Earlier in this thread, Marcus talked about switching from MutexLockerEx -> MutexLocker and the problem that he ran into with the wait() function. He's planning to explore this idea further using a different bug ID in order to clean up this wart. > >> So the comment really doesn't explain what's going on, and leads one to >> believe that you need to be careful _not_ to take a safepoint check with >> the Watcher thread. > > I don't read it that way but would it be better if it said "do not > _need to_ honor" instead? Perhaps "does not participate in the safepoint protocol" is better and more clear? > > David > ----- > >> I'll stop reading comments again. Please don't. I'm trying to make the comments more clear in an area that is a bit messy. If the comments don't make sense to you, then I need to fix that. >> >> Thanks for the explanation though, the latter part I knew about. >> >> Coleen >> >>> >>>> 65 // The WatcherThread is not a JavaThread so we do not honor >>>> the >>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>> Mutex::_no_safepoint_check_flag); >>>> >>>> >>>> Because WatcherThread::stop() does safepoint check. WatcherThread::stop() does a safepoint check because it is called by a JavaThread instead of the WatcherThread. I added a new comment that was supposed to make this clear. Is the comment in thread.cpp not clear? >>>> It's unclear >>>> whether enroll and disenroll can be called by the WatcherThread also. >>>> If so, should they have no_safepoint_check. That's true. It is not clear that the WatcherThread does not call enroll() or disenroll() and I didn't add an assert for this one. As David pointed out earlier in this review thread, the API for the PeriodicTask class needs to be cleaned up a bit. I concur, but we agreed that should be done via another bug ID that is focused on just API cleanup. >>> >>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>> never want to check for safepoints. If the only caller is a >>> non-JavaThread then that is trivially true. If the caller can be a >>> JavaThread then safepoint checking can only be elided under very >>> specific circumstances (ie leaf methods with other constraints). If >>> the lock is to be acquired by JavaThreads, as is the case with >>> enrol/disenrol then we should check for safepoints (as the conditions >>> for eliding safepoint checks for JavaThreads are not met by those >>> methods). >>> >>>> The whole safepoint checking inconsistency still makes me nervous, but >>>> the comment seems misleading. >>> >>> Hope it is clearer now. >>> >>> David >>> >>>> >>>> I honestly don't know enough about the rest to review it. Thanks for taking a look at it anyway. Dan >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>> This should be the last webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>> >>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >>>>> to hear from you in this hopefully final round... >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Here is an updated webrev after addressing David H's comments: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>> >>>>>> Also, here is the bug's URL: >>>>>> >>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>> >>>>>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>>>>> system for a ride during its beta period so I won't be doing direct >>>>>> Aurora Adhoc jobs... >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> My fix for the following bug: >>>>>>> >>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>> >>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>> >>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>> >>>>>>> This code review is for a general cleanup pass on PeriodicTask_lock >>>>>>> and some of the surrounding code. This is a targeted review in that >>>>>>> I would like to hear from three groups of people: >>>>>>> >>>>>>> 1) The author and reviewers for: >>>>>>> >>>>>>> JDK-7127792 Add the ability to change an existing PeriodicTask's >>>>>>> execution interval >>>>>>> >>>>>>> Rickard, David H, and Markus G. >>>>>>> >>>>>>> 2) The reviewers for: >>>>>>> >>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>> >>>>>>> Markus G and Coleen >>>>>>> >>>>>>> 3) Alex and Carsten >>>>>>> >>>>>>> >>>>>>> Here's the webrev URL: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>> >>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>> will be done with this fix. >>>>>>> >>>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>> >>>> >> From coleen.phillimore at oracle.com Fri Feb 27 20:36:55 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Feb 2015 15:36:55 -0500 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F0915D.3050700@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> Message-ID: <54F0D567.8000307@oracle.com> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: > Coleen, > > Thanks for the review. Replies embedded below. > > David, > > Thanks for jumping in while I was out of the office yesterday. > > > On 2/26/15 12:13 AM, David Holmes wrote: >> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>> >>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi, I think you have better reviewer for this now but I did have a >>>>> couple of questions. >>>>> >>>>> in >>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>> >>>>> >>>>> >>>>> This comment is really confusing because I think you do in fact honor >>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>> >>>> Depends what you mean by "honor the safepoint protocol". The >>>> WatcherThread will sometimes acquire locks that potentially check the >>>> safepoint state, but as it is not a JavaThread such paths are never >>>> actually taken. Hence we can call the code that will never consider >>>> taking them if the only caller of that code (as in this case) is a >>>> non-JavaThread. >>> >>> So you could theoretically have the watcher thread use the regular >>> MutexLocker, which checks for safepoints, and somewhere behind the >>> scenes, the safepoint check is elided. >> >> Yes, internally there is one path for JavaThreads and a different >> path for non-JavaThreads. JavaThreads perform thread-state >> transitions which form part of the safepoint protocol. > > So it looks like "honor the safepoint protocol" is bad choice of > words. More below. > > Earlier in this thread, Marcus talked about switching from > MutexLockerEx -> MutexLocker and the problem that he ran into > with the wait() function. He's planning to explore this idea > further using a different bug ID in order to clean up this > wart. > > + // The WatcherThread is not a JavaThread so we do not honor the + // safepoint protocol for the PeriodicTask_lock. MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); Your explanation makes sense. To be honest, I'm not sure how to reword it so it makes more sense, other than to add that the safepoint check isn't made anyway for !JavaThreads. Coleen >> >>> So the comment really doesn't explain what's going on, and leads one to >>> believe that you need to be careful _not_ to take a safepoint check >>> with >>> the Watcher thread. >> >> I don't read it that way but would it be better if it said "do not >> _need to_ honor" instead? > > Perhaps "does not participate in the safepoint protocol" is > better and more clear? > > >> >> David >> ----- >> >>> I'll stop reading comments again. > > Please don't. I'm trying to make the comments more clear in an > area that is a bit messy. If the comments don't make sense to > you, then I need to fix that. > > >>> >>> Thanks for the explanation though, the latter part I knew about. >>> >>> Coleen >>> >>>> >>>>> 65 // The WatcherThread is not a JavaThread so we do not honor >>>>> the >>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>> Mutex::_no_safepoint_check_flag); >>>>> >>>>> >>>>> Because WatcherThread::stop() does safepoint check. > > WatcherThread::stop() does a safepoint check because it is > called by a JavaThread instead of the WatcherThread. I added > a new comment that was supposed to make this clear. Is the > comment in thread.cpp not clear? > > >>>>> It's unclear >>>>> whether enroll and disenroll can be called by the WatcherThread also. >>>>> If so, should they have no_safepoint_check. > > That's true. It is not clear that the WatcherThread does not call > enroll() or disenroll() and I didn't add an assert for this one. > As David pointed out earlier in this review thread, the API for > the PeriodicTask class needs to be cleaned up a bit. I concur, > but we agreed that should be done via another bug ID that is > focused on just API cleanup. > > >>>> >>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>> never want to check for safepoints. If the only caller is a >>>> non-JavaThread then that is trivially true. If the caller can be a >>>> JavaThread then safepoint checking can only be elided under very >>>> specific circumstances (ie leaf methods with other constraints). If >>>> the lock is to be acquired by JavaThreads, as is the case with >>>> enrol/disenrol then we should check for safepoints (as the conditions >>>> for eliding safepoint checks for JavaThreads are not met by those >>>> methods). >>>> >>>>> The whole safepoint checking inconsistency still makes me nervous, >>>>> but >>>>> the comment seems misleading. >>>> >>>> Hope it is clearer now. >>>> >>>> David >>>> >>>>> >>>>> I honestly don't know enough about the rest to review it. > > Thanks for taking a look at it anyway. > > Dan > > >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>> This should be the last webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>> >>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >>>>>> to hear from you in this hopefully final round... >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>> >>>>>>> Also, here is the bug's URL: >>>>>>> >>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>> >>>>>>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>>>>>> system for a ride during its beta period so I won't be doing direct >>>>>>> Aurora Adhoc jobs... >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> My fix for the following bug: >>>>>>>> >>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>> >>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>> >>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>> >>>>>>>> This code review is for a general cleanup pass on >>>>>>>> PeriodicTask_lock >>>>>>>> and some of the surrounding code. This is a targeted review in >>>>>>>> that >>>>>>>> I would like to hear from three groups of people: >>>>>>>> >>>>>>>> 1) The author and reviewers for: >>>>>>>> >>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>> PeriodicTask's >>>>>>>> execution interval >>>>>>>> >>>>>>>> Rickard, David H, and Markus G. >>>>>>>> >>>>>>>> 2) The reviewers for: >>>>>>>> >>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>> >>>>>>>> Markus G and Coleen >>>>>>>> >>>>>>>> 3) Alex and Carsten >>>>>>>> >>>>>>>> >>>>>>>> Here's the webrev URL: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>> >>>>>>>> >>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>> will be done with this fix. >>>>>>>> >>>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Feb 27 21:54:25 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 27 Feb 2015 14:54:25 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F0D567.8000307@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> Message-ID: <54F0E791.8020409@oracle.com> Coleen and David, My final attempt to get more acceptable wording for this comment: Here's the current wording: + // The WatcherThread is not a JavaThread so we do not honor the + // safepoint protocol for the PeriodicTask_lock. MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); How about: + // The WatcherThread does not participate in the safepoint protocol + // for the PeriodicTask_lock because it is not a JavaThread. MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); This change would be made in task.cpp: PeriodicTask::real_time_tick() and thread.cpp: WatcherThread::sleep(). Is this acceptable? Dan On 2/27/15 1:36 PM, Coleen Phillimore wrote: > > On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >> Coleen, >> >> Thanks for the review. Replies embedded below. >> >> David, >> >> Thanks for jumping in while I was out of the office yesterday. >> >> >> On 2/26/15 12:13 AM, David Holmes wrote: >>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>> >>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>> couple of questions. >>>>>> >>>>>> in >>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>> >>>>>> >>>>>> >>>>>> This comment is really confusing because I think you do in fact >>>>>> honor >>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>> >>>>> Depends what you mean by "honor the safepoint protocol". The >>>>> WatcherThread will sometimes acquire locks that potentially check the >>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>> actually taken. Hence we can call the code that will never consider >>>>> taking them if the only caller of that code (as in this case) is a >>>>> non-JavaThread. >>>> >>>> So you could theoretically have the watcher thread use the regular >>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>> scenes, the safepoint check is elided. >>> >>> Yes, internally there is one path for JavaThreads and a different >>> path for non-JavaThreads. JavaThreads perform thread-state >>> transitions which form part of the safepoint protocol. >> >> So it looks like "honor the safepoint protocol" is bad choice of >> words. More below. >> >> Earlier in this thread, Marcus talked about switching from >> MutexLockerEx -> MutexLocker and the problem that he ran into >> with the wait() function. He's planning to explore this idea >> further using a different bug ID in order to clean up this >> wart. >> >> > > + // The WatcherThread is not a JavaThread so we do not honor the > + // safepoint protocol for the PeriodicTask_lock. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > Your explanation makes sense. To be honest, I'm not sure how to > reword it so it makes more sense, other than to add that the safepoint > check isn't made anyway for !JavaThreads. > > Coleen >>> >>>> So the comment really doesn't explain what's going on, and leads >>>> one to >>>> believe that you need to be careful _not_ to take a safepoint check >>>> with >>>> the Watcher thread. >>> >>> I don't read it that way but would it be better if it said "do not >>> _need to_ honor" instead? >> >> Perhaps "does not participate in the safepoint protocol" is >> better and more clear? >> >> >>> >>> David >>> ----- >>> >>>> I'll stop reading comments again. >> >> Please don't. I'm trying to make the comments more clear in an >> area that is a bit messy. If the comments don't make sense to >> you, then I need to fix that. >> >> >>>> >>>> Thanks for the explanation though, the latter part I knew about. >>>> >>>> Coleen >>>> >>>>> >>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>> honor >>>>>> the >>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>> Mutex::_no_safepoint_check_flag); >>>>>> >>>>>> >>>>>> Because WatcherThread::stop() does safepoint check. >> >> WatcherThread::stop() does a safepoint check because it is >> called by a JavaThread instead of the WatcherThread. I added >> a new comment that was supposed to make this clear. Is the >> comment in thread.cpp not clear? >> >> >>>>>> It's unclear >>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>> also. >>>>>> If so, should they have no_safepoint_check. >> >> That's true. It is not clear that the WatcherThread does not call >> enroll() or disenroll() and I didn't add an assert for this one. >> As David pointed out earlier in this review thread, the API for >> the PeriodicTask class needs to be cleaned up a bit. I concur, >> but we agreed that should be done via another bug ID that is >> focused on just API cleanup. >> >> >>>>> >>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>> never want to check for safepoints. If the only caller is a >>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>> JavaThread then safepoint checking can only be elided under very >>>>> specific circumstances (ie leaf methods with other constraints). If >>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>> enrol/disenrol then we should check for safepoints (as the conditions >>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>> methods). >>>>> >>>>>> The whole safepoint checking inconsistency still makes me >>>>>> nervous, but >>>>>> the comment seems misleading. >>>>> >>>>> Hope it is clearer now. >>>>> >>>>> David >>>>> >>>>>> >>>>>> I honestly don't know enough about the rest to review it. >> >> Thanks for taking a look at it anyway. >> >> Dan >> >> >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>> This should be the last webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>> >>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >>>>>>> to hear from you in this hopefully final round... >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>> >>>>>>>> >>>>>>>> Also, here is the bug's URL: >>>>>>>> >>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>> >>>>>>>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>> direct >>>>>>>> Aurora Adhoc jobs... >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> My fix for the following bug: >>>>>>>>> >>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>> >>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>> >>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>> >>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>> PeriodicTask_lock >>>>>>>>> and some of the surrounding code. This is a targeted review in >>>>>>>>> that >>>>>>>>> I would like to hear from three groups of people: >>>>>>>>> >>>>>>>>> 1) The author and reviewers for: >>>>>>>>> >>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>> PeriodicTask's >>>>>>>>> execution interval >>>>>>>>> >>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>> >>>>>>>>> 2) The reviewers for: >>>>>>>>> >>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>> >>>>>>>>> Markus G and Coleen >>>>>>>>> >>>>>>>>> 3) Alex and Carsten >>>>>>>>> >>>>>>>>> >>>>>>>>> Here's the webrev URL: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>> will be done with this fix. >>>>>>>>> >>>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: