From yekaterina.kantserova at oracle.com Mon Jun 2 09:35:51 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 02 Jun 2014 11:35:51 +0200 Subject: RFR(S): 8043915: Tests get ClassNotFoundException: com.oracle.java.testlibrary.StreamPumper In-Reply-To: References: <5385CF6B.3090404@oracle.com> Message-ID: <538C4577.2010205@oracle.com> Peter, thanks for your review! See my comments inlined. On 05/30/2014 02:08 PM, Peter Allwin wrote: > Hi Katja, > > Is it necessary to @build classes used in @run statements? I see you added it to some but GetObjectSizeOverflow.java is missing ClassFileInstaller. No it is not. Here is an explanation from Jon: "The class specified in an "@run main" directive is subject to an implicit "@build" meaning that it will be compiled if needed." But it does no harm and my intention was to change as little as possible. New webrev can be found here: http://cr.openjdk.java.net/~ykantser/8043915/webrev.01/ Thanks, Katja > > > Other than that it looks good! > > Thanks, > /peter > > > On 28 May 2014, at 13:58, Yekaterina Kantserova wrote: > >> Hi, >> >> Could I please have a review of this fix. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8043915/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8043915 >> >> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when for example running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >> >> Verified locally. >> >> Thanks, >> Katja From mattias.tobiasson at oracle.com Mon Jun 2 12:11:16 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Mon, 2 Jun 2014 05:11:16 -0700 (PDT) Subject: RFR: 8036006 [TESTBUG] sun/tools/native2ascii/NativeErrors.java: Process exit code was 0, but error was expected Message-ID: <72fa23ae-9f9f-451a-a76c-e1a66789afa5@default> Hi, Could someone please review this test fix? The test tries to write to a read-only file and expects an error. The test will fail if it is run as root, because root is allowed to write to read-only files. The fix is to check if the file is really read-only with function java.io.File.canWrite(). If we are root then canWrite() will return true and the read-only part of the test is skipped. webrev: http://cr.openjdk.java.net/~ykantser/8036006/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8036006 Mattias From staffan.larsen at oracle.com Mon Jun 2 12:14:28 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 2 Jun 2014 14:14:28 +0200 Subject: RFR: 8036006 [TESTBUG] sun/tools/native2ascii/NativeErrors.java: Process exit code was 0, but error was expected In-Reply-To: <72fa23ae-9f9f-451a-a76c-e1a66789afa5@default> References: <72fa23ae-9f9f-451a-a76c-e1a66789afa5@default> Message-ID: Looks good! Thanks, /Staffan On 2 jun 2014, at 14:11, Mattias Tobiasson wrote: > Hi, > Could someone please review this test fix? > > The test tries to write to a read-only file and expects an error. > The test will fail if it is run as root, because root is allowed to write to read-only files. > > The fix is to check if the file is really read-only with function java.io.File.canWrite(). > If we are root then canWrite() will return true and the read-only part of the test is skipped. > > webrev: http://cr.openjdk.java.net/~ykantser/8036006/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8036006 > > Mattias > From peter.allwin at oracle.com Mon Jun 2 13:15:57 2014 From: peter.allwin at oracle.com (Peter Allwin) Date: Mon, 2 Jun 2014 15:15:57 +0200 Subject: RFR(S): 8043915: Tests get ClassNotFoundException: com.oracle.java.testlibrary.StreamPumper In-Reply-To: <538C4577.2010205@oracle.com> References: <5385CF6B.3090404@oracle.com> <538C4577.2010205@oracle.com> Message-ID: <8F42F6E7-3DE6-4738-A049-0547940AC1D4@oracle.com> On 02 Jun 2014, at 11:35, Yekaterina Kantserova wrote: > Peter, thanks for your review! See my comments inlined. > > On 05/30/2014 02:08 PM, Peter Allwin wrote: >> Hi Katja, >> >> Is it necessary to @build classes used in @run statements? I see you added it to some but GetObjectSizeOverflow.java is missing ClassFileInstaller. > > No it is not. Here is an explanation from Jon: > "The class specified in an "@run main" directive is subject to an implicit "@build" meaning that it will be compiled if needed." > But it does no harm and my intention was to change as little as possible. > Ah, thanks for the clarification! > New webrev can be found here: http://cr.openjdk.java.net/~ykantser/8043915/webrev.01/ > Looks good to me! /peter > Thanks, > Katja > >> >> >> Other than that it looks good! >> >> Thanks, >> /peter >> >> >> On 28 May 2014, at 13:58, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8043915/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8043915 >>> >>> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when for example running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >>> >>> Verified locally. >>> >>> Thanks, >>> Katja > From markus.gronlund at oracle.com Mon Jun 2 14:41:43 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Mon, 2 Jun 2014 07:41:43 -0700 (PDT) Subject: RFR(XXS): 8044531: Event based tracing locks to rank as leafs where possible Message-ID: Greetings, ? Kindly asking for review for the following small change: ? Webrev: http://cr.openjdk.java.net/~mgronlun/8044531/webrev01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8044531 ? Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Mon Jun 2 14:48:08 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 02 Jun 2014 08:48:08 -0600 Subject: RFR(XXS): 8044531: Event based tracing locks to rank as leafs where possible In-Reply-To: References: Message-ID: <538C8EA8.4000809@oracle.com> On 6/2/14 8:41 AM, Markus Gr?nlund wrote: > > Greetings, > > Kindly asking for review for the following small change: > > Webrev: http://cr.openjdk.java.net/~mgronlun/8044531/webrev01/ > > src/share/vm/runtime/mutexLocker.cpp line 285 def(JfrStream_lock , Mutex, nonleaf+1, true); Now that the other locks in the logical group that were nonleaf are now leaf, I think you can make this one 'nonleaf' without the '+1'. Thumbs up. Dan > Bug: https://bugs.openjdk.java.net/browse/JDK-8044531 > > Thanks > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Mon Jun 2 14:49:51 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Mon, 2 Jun 2014 07:49:51 -0700 (PDT) Subject: RFR(XXS): 8044531: Event based tracing locks to rank as leafs where possible In-Reply-To: <538C8EA8.4000809@oracle.com> References: <538C8EA8.4000809@oracle.com> Message-ID: Thanks Dan! ? I will remove the +1 ? Cheers Markus ? ? From: Daniel D. Daugherty Sent: den 2 juni 2014 16:48 To: Markus Gr?nlund Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev Subject: Re: RFR(XXS): 8044531: Event based tracing locks to rank as leafs where possible ? On 6/2/14 8:41 AM, Markus Gr?nlund wrote: Greetings, ? Kindly asking for review for the following small change: ? Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8044531/webrev01/"http://cr.openjdk.java.net/~mgronlun/8044531/webrev01/ ? src/share/vm/runtime/mutexLocker.cpp ??? line 285?? def(JfrStream_lock?????????????? , Mutex,?? nonleaf+1,?? true); ??????? Now that the other locks in the logical group that were ??????? nonleaf are now leaf, I think you can make this one 'nonleaf' ? ? ? ? without the '+1'. Thumbs up. ? Dan ? Bug: https://bugs.openjdk.java.net/browse/JDK-8044531 ? Thanks Markus ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.auno at oracle.com Mon Jun 2 15:29:18 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Mon, 02 Jun 2014 17:29:18 +0200 Subject: RFR(XXS): 8044540: serviceability/sa/jmap-hashcode/Test8028623.java should be quarantined Message-ID: <538C984E.3040605@oracle.com> Hi, Could I please have a review of this very small fix. webrev: http://cr.openjdk.java.net/~miauno/8044540/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8044540 Verified locally. Thanks, Mikael From mikael.auno at oracle.com Mon Jun 2 16:14:54 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Mon, 02 Jun 2014 18:14:54 +0200 Subject: RFR(XS): 8044495: Remove test demo/jvmti/mtrace/TraceJFrame.java Message-ID: <538CA2FE.40906@oracle.com> Hi, Could I please have a review of this small fix, removing the test TraceJFrame.java. webrev: http://cr.openjdk.java.net/~miauno/8044495/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8044495 This test was created a long, long time ago as it reportedly had been very slow to "step into the first JFrame" in the early stages of JDK 1.5. Thus, it times how long it takes to create that first JFrame while tracing, and then seemingly ignores the result and returns PASS. During its life time, however, we've had lots and lots of failures in this test due to non-existent or misconfigured X11 displays. As such, we believe we're better off without it. Thanks, Mikael From staffan.larsen at oracle.com Mon Jun 2 17:27:48 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 2 Jun 2014 19:27:48 +0200 Subject: RFR(XS): 8044495: Remove test demo/jvmti/mtrace/TraceJFrame.java In-Reply-To: <538CA2FE.40906@oracle.com> References: <538CA2FE.40906@oracle.com> Message-ID: <90C2E583-806C-4374-A103-26157C5132ED@oracle.com> Looks good! Thanks for cleaning this up. /Staffan On 2 jun 2014, at 18:14, Mikael Auno wrote: > Hi, > > Could I please have a review of this small fix, removing the test > TraceJFrame.java. > > webrev: http://cr.openjdk.java.net/~miauno/8044495/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8044495 > > This test was created a long, long time ago as it reportedly had been > very slow to "step into the first JFrame" in the early stages of JDK > 1.5. Thus, it times how long it takes to create that first JFrame while > tracing, and then seemingly ignores the result and returns PASS. During > its life time, however, we've had lots and lots of failures in this test > due to non-existent or misconfigured X11 displays. As such, we believe > we're better off without it. > > Thanks, > Mikael From staffan.larsen at oracle.com Mon Jun 2 17:28:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 2 Jun 2014 19:28:31 +0200 Subject: RFR(XXS): 8044540: serviceability/sa/jmap-hashcode/Test8028623.java should be quarantined In-Reply-To: <538C984E.3040605@oracle.com> References: <538C984E.3040605@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 2 jun 2014, at 17:29, Mikael Auno wrote: > Hi, > > Could I please have a review of this very small fix. > > webrev: http://cr.openjdk.java.net/~miauno/8044540/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8044540 > > Verified locally. > > Thanks, > Mikael From serguei.spitsyn at oracle.com Mon Jun 2 21:48:12 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 02 Jun 2014 14:48:12 -0700 Subject: RFR(XS): 8044495: Remove test demo/jvmti/mtrace/TraceJFrame.java In-Reply-To: <538CA2FE.40906@oracle.com> References: <538CA2FE.40906@oracle.com> Message-ID: <538CF11C.3080309@oracle.com> Mikael, It looks good. Thank you for doing this! Thanks, Serguei On 6/2/14 9:14 AM, Mikael Auno wrote: > Hi, > > Could I please have a review of this small fix, removing the test > TraceJFrame.java. > > webrev: http://cr.openjdk.java.net/~miauno/8044495/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8044495 > > This test was created a long, long time ago as it reportedly had been > very slow to "step into the first JFrame" in the early stages of JDK > 1.5. Thus, it times how long it takes to create that first JFrame while > tracing, and then seemingly ignores the result and returns PASS. During > its life time, however, we've had lots and lots of failures in this test > due to non-existent or misconfigured X11 displays. As such, we believe > we're better off without it. > > Thanks, > Mikael From david.holmes at oracle.com Tue Jun 3 02:21:37 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Jun 2014 12:21:37 +1000 Subject: RFR: 8036006 [TESTBUG] sun/tools/native2ascii/NativeErrors.java: Process exit code was 0, but error was expected In-Reply-To: References: <72fa23ae-9f9f-451a-a76c-e1a66789afa5@default> Message-ID: <538D3131.5050807@oracle.com> +1 David On 2/06/2014 10:14 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 2 jun 2014, at 14:11, Mattias Tobiasson wrote: > >> Hi, >> Could someone please review this test fix? >> >> The test tries to write to a read-only file and expects an error. >> The test will fail if it is run as root, because root is allowed to write to read-only files. >> >> The fix is to check if the file is really read-only with function java.io.File.canWrite(). >> If we are root then canWrite() will return true and the read-only part of the test is skipped. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8036006/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8036006 >> >> Mattias >> > From david.holmes at oracle.com Tue Jun 3 02:46:14 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Jun 2014 12:46:14 +1000 Subject: RFR(XXS): 8044531: Event based tracing locks to rank as leafs where possible In-Reply-To: References: Message-ID: <538D36F6.8090903@oracle.com> Change looks fine but the proof of the ranking is in the testing. ;-) David On 3/06/2014 12:41 AM, Markus Gr?nlund wrote: > Greetings, > > Kindly asking for review for the following small change: > > Webrev: http://cr.openjdk.java.net/~mgronlun/8044531/webrev01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044531 > > Thanks > > Markus > From mikael.auno at oracle.com Tue Jun 3 13:43:52 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Tue, 03 Jun 2014 15:43:52 +0200 Subject: RFR(XS): 8044495: Remove test demo/jvmti/mtrace/TraceJFrame.java In-Reply-To: <538CF11C.3080309@oracle.com> References: <538CA2FE.40906@oracle.com> <538CF11C.3080309@oracle.com> Message-ID: <538DD118.7070708@oracle.com> Thanks for the reviews. Staffan, could you help me push this? The exported changeset is attached. Thanks, Mikael On 2014-06-02 23:48, serguei.spitsyn at oracle.com wrote: > Mikael, > > It looks good. > Thank you for doing this! > > Thanks, > Serguei > > On 6/2/14 9:14 AM, Mikael Auno wrote: >> Hi, >> >> Could I please have a review of this small fix, removing the test >> TraceJFrame.java. >> >> webrev: http://cr.openjdk.java.net/~miauno/8044495/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8044495 >> >> This test was created a long, long time ago as it reportedly had been >> very slow to "step into the first JFrame" in the early stages of JDK >> 1.5. Thus, it times how long it takes to create that first JFrame while >> tracing, and then seemingly ignores the result and returns PASS. During >> its life time, however, we've had lots and lots of failures in this test >> due to non-existent or misconfigured X11 displays. As such, we believe >> we're better off without it. >> >> Thanks, >> Mikael > -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8044495.patch Type: text/x-patch Size: 4942 bytes Desc: not available URL: From mikael.auno at oracle.com Tue Jun 3 13:47:45 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Tue, 03 Jun 2014 15:47:45 +0200 Subject: RFR(XXS): 8044540: serviceability/sa/jmap-hashcode/Test8028623.java should be quarantined In-Reply-To: References: <538C984E.3040605@oracle.com> Message-ID: <538DD201.4060901@oracle.com> Thanks for the review. Could you also help me push this to hs-rt? The exported changeset is attached. Mikael On 2014-06-02 19:28, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 2 jun 2014, at 17:29, Mikael Auno wrote: > >> Hi, >> >> Could I please have a review of this very small fix. >> >> webrev: http://cr.openjdk.java.net/~miauno/8044540/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8044540 >> >> Verified locally. >> >> Thanks, >> Mikael > -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8044540.patch Type: text/x-patch Size: 769 bytes Desc: not available URL: From aleksej.efimov at oracle.com Tue Jun 3 13:49:12 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 03 Jun 2014 17:49:12 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> Message-ID: <538DD258.8020002@oracle.com> Staffan, David, Returning back to our WaitForMultipleObjects()/WAIT_ABANDONED discussions: Thank you for your comments and remarks. I can't disagree with motivation that it's better to have a fatal error during the incorrect mutex handling then data corruption (the consequence of the previous fix). In case of such error it'll be much more easier to debug/catch it (but as Staffan said - we have tried to check all call paths and don't think that we'll encounter such behavior). I have modified the discussed code according to your suggestions: http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.01/ To abort the process the 'exitTransportWithError' function was utilized. Also I have tried to check that behavior isn't changed by running "svc" regression tests set. There was no related test failures observed. Best Regards, Aleksej On 05/15/2014 01:11 PM, Staffan Larsen wrote: > On 15 maj 2014, at 03:48, David Holmes wrote: > >> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >>> David, Vitaly, >>> >>> I totally agree with Vitaly's explanation (Vitaly - thank you for that) >>> and code in shmemBase.c (the usage of enterMutex() function for >>> sending/receiving bytes through shared memory connection) illustrates on >>> how the connection shutdown event is used as a "cancellation token". >> Thanks for clarifying that. >> >> So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. >> >> The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. >> >> Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: >> >> 204 /* If the mutex is abandoned we want to return an error >> 205 * and also release the mutex so that we don't cause >> 206 * other threads to be blocked. If a mutex was abandoned >> 207 * we are in scary state. Data may be corrupted or inconsistent >> 208 * but it is still better to let other threads run (and possibly >> 209 * crash) than having them blocked (on the premise that a crash >> 210 * is always easier to debug than a hang). >> >> Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. >> >> But I'll let the serviceability folk chime in here. > I was involved in fixing this and writing the comment, so obviously I thought it a good solution :-) > > I do agree that it would probably be a good idea to consider this a fatal error and abort. At that point in the code we don?t have any really nice ways of doing that, though. We could just print an error and call abort(). What we are doing now is returning an error from sysIPMutexEnter() and delegating the error handling to the caller. We have tried to check all call paths to verify that they do ?the right thing? in the face of an error. It is obviously hard to verify, but it looks like they all terminate the connection with some kind of error message. > > /Staffan > > >> Thanks, >> David >> >> >>> Thank you, >>> -Aleksej >>> >>> >>> On 05/14/2014 01:05 PM, David Holmes wrote: >>>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>>> In windows, you acquire a mutex by waiting on it using one of the wait >>>>> functions, one of them employed in the code in question. If >>>>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>>>> current thread has ownership now. >>>> Yes I understand the basic mechanics :) >>>> >>>>> It's also common to use multi wait functions where the event is a >>>>> "cancelation token", e.g. manual reset event; this allows someone to >>>>> cancel waiting on mutex acquisition and return from the wait function. >>>>> Presumably that's the case here, but I'll let Aleksej confirm; just >>>>> wanted to throw this out there in the meantime :). >>>> Ah I see - yes cancellable lock acquisition would make sense. >>>> >>>> Thanks, >>>> David >>>> >>>>> Sent from my phone >>>>> >>>>> On May 13, 2014 6:46 PM, "David Holmes" >>>> > wrote: >>>>> >>>>> Hi Aleksej, >>>>> >>>>> Thanks for the doc references regarding abandonment. >>>>> >>>>> Let me rephrase my question. What is this logic trying to achieve by >>>>> waiting on both a mutex and an event? Do we already own the mutex >>>>> when this function is called? >>>>> >>>>> David >>>>> >>>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>>> >>>>> David, >>>>> >>>>> The Windows has a different terminology for mutex objects (much >>>>> differs >>>>> from the POSIX one). This one link gave me some understanding of >>>>> it [1]. >>>>> >>>>> Here is the MSDN [1] description of what "abandoned mutex" is: >>>>> " If a thread terminates without releasing its ownership of a >>>>> mutex >>>>> object, the mutex object is considered to be abandoned. A >>>>> waiting thread >>>>> can acquire ownership of an abandoned mutex object, but the wait >>>>> function will return*WAIT_ABANDONED*to indicate that the mutex >>>>> object is >>>>> abandoned. An abandoned mutex object indicates that an error has >>>>> occurred and that any shared resource being protected by the >>>>> mutex >>>>> object is in an undefined state. If the thread proceeds as >>>>> though the >>>>> mutex object had not been abandoned, it is no longer considered >>>>> abandoned after the thread releases its ownership. This restores >>>>> normal >>>>> behavior if a handle to the mutex object is subsequently >>>>> specified in a >>>>> wait function." >>>>> >>>>> >>>>> What does it mean to wait on mutex and ownership of the mutex >>>>> object: >>>>> "Any thread with a handle to a mutex object can use one of >>>>> thewait >>>>> functions >>>>> >>>> >to >>>>> request ownership of the mutex object. If the mutex object is >>>>> owned by >>>>> another thread, the wait function blocks the requesting thread >>>>> until the >>>>> owning thread releases the mutex object using the*ReleaseMutex* >>>>> >>>> >__function." >>>>> >>>>> How we can release mutex and wait on already owned mutex: >>>>> " After a thread obtains ownership of a mutex, it can specify >>>>> the same >>>>> mutex in repeated calls to the wait-functions >>>>> >>>> >__without >>>>> blocking its execution. This prevents a thread from deadlocking >>>>> itself >>>>> while waiting for a mutex that it already owns. To release its >>>>> ownership >>>>> under such circumstances, the thread must call*ReleaseMutex* >>>>> >>>> >__once >>>>> for each time that the mutex satisfied the conditions of a wait >>>>> function." >>>>> >>>>> [1] >>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>>> >>>>> >>>>> -Aleksej >>>>> >>>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>>> >>>>> I don't understand this one at all. What is an "abandoned >>>>> mutex"? For >>>>> that matter why does the code wait on a mutex and an event? >>>>> Do we >>>>> already own the mutex? If so what does it mean to wait on >>>>> it? If not >>>>> then how can we release it? >>>>> >>>>> ??? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>>> >>>>> >>>>> This is debugger's shared memory transport so cc'ing >>>>> serviceability-dev >>>>> as that is there this code is maintained. >>>>> >>>>> Is there a test case or any outline of the conditions >>>>> that cause this? I >>>>> think that would be useful to understand the issue >>>>> further. >>>>> >>>>> -Alan >>>>> >>>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>>> >>>>> Hi, >>>>> >>>>> Can I have a review for 8032901 bug [1] fix [2]. >>>>> There is a possible >>>>> case when 'WaitForMultipleObjects' function can >>>>> return the >>>>> WAIT_ABANDONED_0 [3] error value. >>>>> In such case it's better to release the mutex and >>>>> return error value. >>>>> This will prevent other threads to be blocked on >>>>> abandoned mutex. >>>>> >>>>> Thank you, >>>>> Aleksej >>>>> >>>>> [1] >>>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>>> >>>>> [2] >>>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>>> >>>>> [3] >>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>>> >>>>> >>>>> >>>>> >>>>> From staffan.larsen at oracle.com Wed Jun 4 07:23:22 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Jun 2014 09:23:22 +0200 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <538DD258.8020002@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> <538DD258.8020002@oracle.com> Message-ID: <57D067E1-75F6-4416-9443-32CFE1656734@oracle.com> Looks ok to me. /Staffan On 3 jun 2014, at 15:49, Aleksej Efimov wrote: > Staffan, David, > > Returning back to our WaitForMultipleObjects()/WAIT_ABANDONED discussions: > Thank you for your comments and remarks. I can't disagree with motivation that it's better to have a fatal error during the incorrect mutex handling then data corruption (the consequence of the previous fix). In case of such error it'll be much more easier to debug/catch it (but as Staffan said - we have tried to check all call paths and don't think that we'll encounter such behavior). > I have modified the discussed code according to your suggestions: http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.01/ > To abort the process the 'exitTransportWithError' function was utilized. > Also I have tried to check that behavior isn't changed by running "svc" regression tests set. There was no related test failures observed. > > Best Regards, > Aleksej > > On 05/15/2014 01:11 PM, Staffan Larsen wrote: >> On 15 maj 2014, at 03:48, David Holmes wrote: >> >>> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >>>> David, Vitaly, >>>> >>>> I totally agree with Vitaly's explanation (Vitaly - thank you for that) >>>> and code in shmemBase.c (the usage of enterMutex() function for >>>> sending/receiving bytes through shared memory connection) illustrates on >>>> how the connection shutdown event is used as a "cancellation token". >>> Thanks for clarifying that. >>> >>> So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. >>> >>> The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. >>> >>> Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: >>> >>> 204 /* If the mutex is abandoned we want to return an error >>> 205 * and also release the mutex so that we don't cause >>> 206 * other threads to be blocked. If a mutex was abandoned >>> 207 * we are in scary state. Data may be corrupted or inconsistent >>> 208 * but it is still better to let other threads run (and possibly >>> 209 * crash) than having them blocked (on the premise that a crash >>> 210 * is always easier to debug than a hang). >>> >>> Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. >>> >>> But I'll let the serviceability folk chime in here. >> I was involved in fixing this and writing the comment, so obviously I thought it a good solution :-) >> >> I do agree that it would probably be a good idea to consider this a fatal error and abort. At that point in the code we don?t have any really nice ways of doing that, though. We could just print an error and call abort(). What we are doing now is returning an error from sysIPMutexEnter() and delegating the error handling to the caller. We have tried to check all call paths to verify that they do ?the right thing? in the face of an error. It is obviously hard to verify, but it looks like they all terminate the connection with some kind of error message. >> >> /Staffan >> >> >>> Thanks, >>> David >>> >>> >>>> Thank you, >>>> -Aleksej >>>> >>>> >>>> On 05/14/2014 01:05 PM, David Holmes wrote: >>>>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>>>> In windows, you acquire a mutex by waiting on it using one of the wait >>>>>> functions, one of them employed in the code in question. If >>>>>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>>>>> current thread has ownership now. >>>>> Yes I understand the basic mechanics :) >>>>> >>>>>> It's also common to use multi wait functions where the event is a >>>>>> "cancelation token", e.g. manual reset event; this allows someone to >>>>>> cancel waiting on mutex acquisition and return from the wait function. >>>>>> Presumably that's the case here, but I'll let Aleksej confirm; just >>>>>> wanted to throw this out there in the meantime :). >>>>> Ah I see - yes cancellable lock acquisition would make sense. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On May 13, 2014 6:46 PM, "David Holmes" >>>>> > wrote: >>>>>> >>>>>> Hi Aleksej, >>>>>> >>>>>> Thanks for the doc references regarding abandonment. >>>>>> >>>>>> Let me rephrase my question. What is this logic trying to achieve by >>>>>> waiting on both a mutex and an event? Do we already own the mutex >>>>>> when this function is called? >>>>>> >>>>>> David >>>>>> >>>>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>>>> >>>>>> David, >>>>>> >>>>>> The Windows has a different terminology for mutex objects (much >>>>>> differs >>>>>> from the POSIX one). This one link gave me some understanding of >>>>>> it [1]. >>>>>> >>>>>> Here is the MSDN [1] description of what "abandoned mutex" is: >>>>>> " If a thread terminates without releasing its ownership of a >>>>>> mutex >>>>>> object, the mutex object is considered to be abandoned. A >>>>>> waiting thread >>>>>> can acquire ownership of an abandoned mutex object, but the wait >>>>>> function will return*WAIT_ABANDONED*to indicate that the mutex >>>>>> object is >>>>>> abandoned. An abandoned mutex object indicates that an error has >>>>>> occurred and that any shared resource being protected by the >>>>>> mutex >>>>>> object is in an undefined state. If the thread proceeds as >>>>>> though the >>>>>> mutex object had not been abandoned, it is no longer considered >>>>>> abandoned after the thread releases its ownership. This restores >>>>>> normal >>>>>> behavior if a handle to the mutex object is subsequently >>>>>> specified in a >>>>>> wait function." >>>>>> >>>>>> >>>>>> What does it mean to wait on mutex and ownership of the mutex >>>>>> object: >>>>>> "Any thread with a handle to a mutex object can use one of >>>>>> thewait >>>>>> functions >>>>>> >>>>> >to >>>>>> request ownership of the mutex object. If the mutex object is >>>>>> owned by >>>>>> another thread, the wait function blocks the requesting thread >>>>>> until the >>>>>> owning thread releases the mutex object using the*ReleaseMutex* >>>>>> >>>>> >__function." >>>>>> >>>>>> How we can release mutex and wait on already owned mutex: >>>>>> " After a thread obtains ownership of a mutex, it can specify >>>>>> the same >>>>>> mutex in repeated calls to the wait-functions >>>>>> >>>>> >__without >>>>>> blocking its execution. This prevents a thread from deadlocking >>>>>> itself >>>>>> while waiting for a mutex that it already owns. To release its >>>>>> ownership >>>>>> under such circumstances, the thread must call*ReleaseMutex* >>>>>> >>>>> >__once >>>>>> for each time that the mutex satisfied the conditions of a wait >>>>>> function." >>>>>> >>>>>> [1] >>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>>>> >>>>>> >>>>>> -Aleksej >>>>>> >>>>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>>>> >>>>>> I don't understand this one at all. What is an "abandoned >>>>>> mutex"? For >>>>>> that matter why does the code wait on a mutex and an event? >>>>>> Do we >>>>>> already own the mutex? If so what does it mean to wait on >>>>>> it? If not >>>>>> then how can we release it? >>>>>> >>>>>> ??? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>>>> >>>>>> >>>>>> This is debugger's shared memory transport so cc'ing >>>>>> serviceability-dev >>>>>> as that is there this code is maintained. >>>>>> >>>>>> Is there a test case or any outline of the conditions >>>>>> that cause this? I >>>>>> think that would be useful to understand the issue >>>>>> further. >>>>>> >>>>>> -Alan >>>>>> >>>>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Can I have a review for 8032901 bug [1] fix [2]. >>>>>> There is a possible >>>>>> case when 'WaitForMultipleObjects' function can >>>>>> return the >>>>>> WAIT_ABANDONED_0 [3] error value. >>>>>> In such case it's better to release the mutex and >>>>>> return error value. >>>>>> This will prevent other threads to be blocked on >>>>>> abandoned mutex. >>>>>> >>>>>> Thank you, >>>>>> Aleksej >>>>>> >>>>>> [1] >>>>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>>>> >>>>>> [2] >>>>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>>>> >>>>>> [3] >>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > From david.holmes at oracle.com Wed Jun 4 09:46:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Jun 2014 19:46:53 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <57D067E1-75F6-4416-9443-32CFE1656734@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> <538DD258.8020002@oracle.com> <57D067E1-75F6-4416-9443-32CFE1656734@oracle.com> Message-ID: <538EEB0D.1070704@oracle.com> Me too. Thanks, David On 4/06/2014 5:23 PM, Staffan Larsen wrote: > Looks ok to me. > > /Staffan > > On 3 jun 2014, at 15:49, Aleksej Efimov wrote: > >> Staffan, David, >> >> Returning back to our WaitForMultipleObjects()/WAIT_ABANDONED discussions: >> Thank you for your comments and remarks. I can't disagree with motivation that it's better to have a fatal error during the incorrect mutex handling then data corruption (the consequence of the previous fix). In case of such error it'll be much more easier to debug/catch it (but as Staffan said - we have tried to check all call paths and don't think that we'll encounter such behavior). >> I have modified the discussed code according to your suggestions: http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.01/ >> To abort the process the 'exitTransportWithError' function was utilized. >> Also I have tried to check that behavior isn't changed by running "svc" regression tests set. There was no related test failures observed. >> >> Best Regards, >> Aleksej >> >> On 05/15/2014 01:11 PM, Staffan Larsen wrote: >>> On 15 maj 2014, at 03:48, David Holmes wrote: >>> >>>> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >>>>> David, Vitaly, >>>>> >>>>> I totally agree with Vitaly's explanation (Vitaly - thank you for that) >>>>> and code in shmemBase.c (the usage of enterMutex() function for >>>>> sending/receiving bytes through shared memory connection) illustrates on >>>>> how the connection shutdown event is used as a "cancellation token". >>>> Thanks for clarifying that. >>>> >>>> So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. >>>> >>>> The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. >>>> >>>> Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: >>>> >>>> 204 /* If the mutex is abandoned we want to return an error >>>> 205 * and also release the mutex so that we don't cause >>>> 206 * other threads to be blocked. If a mutex was abandoned >>>> 207 * we are in scary state. Data may be corrupted or inconsistent >>>> 208 * but it is still better to let other threads run (and possibly >>>> 209 * crash) than having them blocked (on the premise that a crash >>>> 210 * is always easier to debug than a hang). >>>> >>>> Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. >>>> >>>> But I'll let the serviceability folk chime in here. >>> I was involved in fixing this and writing the comment, so obviously I thought it a good solution :-) >>> >>> I do agree that it would probably be a good idea to consider this a fatal error and abort. At that point in the code we don?t have any really nice ways of doing that, though. We could just print an error and call abort(). What we are doing now is returning an error from sysIPMutexEnter() and delegating the error handling to the caller. We have tried to check all call paths to verify that they do ?the right thing? in the face of an error. It is obviously hard to verify, but it looks like they all terminate the connection with some kind of error message. >>> >>> /Staffan >>> >>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Thank you, >>>>> -Aleksej >>>>> >>>>> >>>>> On 05/14/2014 01:05 PM, David Holmes wrote: >>>>>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>>>>> In windows, you acquire a mutex by waiting on it using one of the wait >>>>>>> functions, one of them employed in the code in question. If >>>>>>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>>>>>> current thread has ownership now. >>>>>> Yes I understand the basic mechanics :) >>>>>> >>>>>>> It's also common to use multi wait functions where the event is a >>>>>>> "cancelation token", e.g. manual reset event; this allows someone to >>>>>>> cancel waiting on mutex acquisition and return from the wait function. >>>>>>> Presumably that's the case here, but I'll let Aleksej confirm; just >>>>>>> wanted to throw this out there in the meantime :). >>>>>> Ah I see - yes cancellable lock acquisition would make sense. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Sent from my phone >>>>>>> >>>>>>> On May 13, 2014 6:46 PM, "David Holmes" >>>>>> > wrote: >>>>>>> >>>>>>> Hi Aleksej, >>>>>>> >>>>>>> Thanks for the doc references regarding abandonment. >>>>>>> >>>>>>> Let me rephrase my question. What is this logic trying to achieve by >>>>>>> waiting on both a mutex and an event? Do we already own the mutex >>>>>>> when this function is called? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> The Windows has a different terminology for mutex objects (much >>>>>>> differs >>>>>>> from the POSIX one). This one link gave me some understanding of >>>>>>> it [1]. >>>>>>> >>>>>>> Here is the MSDN [1] description of what "abandoned mutex" is: >>>>>>> " If a thread terminates without releasing its ownership of a >>>>>>> mutex >>>>>>> object, the mutex object is considered to be abandoned. A >>>>>>> waiting thread >>>>>>> can acquire ownership of an abandoned mutex object, but the wait >>>>>>> function will return*WAIT_ABANDONED*to indicate that the mutex >>>>>>> object is >>>>>>> abandoned. An abandoned mutex object indicates that an error has >>>>>>> occurred and that any shared resource being protected by the >>>>>>> mutex >>>>>>> object is in an undefined state. If the thread proceeds as >>>>>>> though the >>>>>>> mutex object had not been abandoned, it is no longer considered >>>>>>> abandoned after the thread releases its ownership. This restores >>>>>>> normal >>>>>>> behavior if a handle to the mutex object is subsequently >>>>>>> specified in a >>>>>>> wait function." >>>>>>> >>>>>>> >>>>>>> What does it mean to wait on mutex and ownership of the mutex >>>>>>> object: >>>>>>> "Any thread with a handle to a mutex object can use one of >>>>>>> thewait >>>>>>> functions >>>>>>> >>>>>> >to >>>>>>> request ownership of the mutex object. If the mutex object is >>>>>>> owned by >>>>>>> another thread, the wait function blocks the requesting thread >>>>>>> until the >>>>>>> owning thread releases the mutex object using the*ReleaseMutex* >>>>>>> >>>>>> >__function." >>>>>>> >>>>>>> How we can release mutex and wait on already owned mutex: >>>>>>> " After a thread obtains ownership of a mutex, it can specify >>>>>>> the same >>>>>>> mutex in repeated calls to the wait-functions >>>>>>> >>>>>> >__without >>>>>>> blocking its execution. This prevents a thread from deadlocking >>>>>>> itself >>>>>>> while waiting for a mutex that it already owns. To release its >>>>>>> ownership >>>>>>> under such circumstances, the thread must call*ReleaseMutex* >>>>>>> >>>>>> >__once >>>>>>> for each time that the mutex satisfied the conditions of a wait >>>>>>> function." >>>>>>> >>>>>>> [1] >>>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>>>>> >>>>>>> >>>>>>> -Aleksej >>>>>>> >>>>>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>>>>> >>>>>>> I don't understand this one at all. What is an "abandoned >>>>>>> mutex"? For >>>>>>> that matter why does the code wait on a mutex and an event? >>>>>>> Do we >>>>>>> already own the mutex? If so what does it mean to wait on >>>>>>> it? If not >>>>>>> then how can we release it? >>>>>>> >>>>>>> ??? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>>>>> >>>>>>> >>>>>>> This is debugger's shared memory transport so cc'ing >>>>>>> serviceability-dev >>>>>>> as that is there this code is maintained. >>>>>>> >>>>>>> Is there a test case or any outline of the conditions >>>>>>> that cause this? I >>>>>>> think that would be useful to understand the issue >>>>>>> further. >>>>>>> >>>>>>> -Alan >>>>>>> >>>>>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Can I have a review for 8032901 bug [1] fix [2]. >>>>>>> There is a possible >>>>>>> case when 'WaitForMultipleObjects' function can >>>>>>> return the >>>>>>> WAIT_ABANDONED_0 [3] error value. >>>>>>> In such case it's better to release the mutex and >>>>>>> return error value. >>>>>>> This will prevent other threads to be blocked on >>>>>>> abandoned mutex. >>>>>>> >>>>>>> Thank you, >>>>>>> Aleksej >>>>>>> >>>>>>> [1] >>>>>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>>>>> >>>>>>> [2] >>>>>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>>>>> >>>>>>> [3] >>>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> > From aleksej.efimov at oracle.com Wed Jun 4 11:43:05 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 04 Jun 2014 15:43:05 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <538EEB0D.1070704@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> <538DD258.8020002@oracle.com> <57D067E1-75F6-4416-9443-32CFE1656734@oracle.com> <538EEB0D.1070704@oracle.com> Message-ID: <538F0649.5000706@oracle.com> Thank you David. Thank you Staffan. On 06/04/2014 01:46 PM, David Holmes wrote: > Me too. > > Thanks, > David > > On 4/06/2014 5:23 PM, Staffan Larsen wrote: >> Looks ok to me. >> >> /Staffan >> >> On 3 jun 2014, at 15:49, Aleksej Efimov >> wrote: >> >>> Staffan, David, >>> >>> Returning back to our WaitForMultipleObjects()/WAIT_ABANDONED >>> discussions: >>> Thank you for your comments and remarks. I can't disagree with >>> motivation that it's better to have a fatal error during the >>> incorrect mutex handling then data corruption (the consequence of >>> the previous fix). In case of such error it'll be much more easier >>> to debug/catch it (but as Staffan said - we have tried to check all >>> call paths and don't think that we'll encounter such behavior). >>> I have modified the discussed code according to your suggestions: >>> http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.01/ >>> To abort the process the 'exitTransportWithError' function was >>> utilized. >>> Also I have tried to check that behavior isn't changed by running >>> "svc" regression tests set. There was no related test failures >>> observed. >>> >>> Best Regards, >>> Aleksej >>> >>> On 05/15/2014 01:11 PM, Staffan Larsen wrote: >>>> On 15 maj 2014, at 03:48, David Holmes >>>> wrote: >>>> >>>>> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >>>>>> David, Vitaly, >>>>>> >>>>>> I totally agree with Vitaly's explanation (Vitaly - thank you for >>>>>> that) >>>>>> and code in shmemBase.c (the usage of enterMutex() function for >>>>>> sending/receiving bytes through shared memory connection) >>>>>> illustrates on >>>>>> how the connection shutdown event is used as a "cancellation token". >>>>> Thanks for clarifying that. >>>>> >>>>> So if we were to encounter an abandoned mutex the code would >>>>> presently have acquired the mutex but return an error, thus >>>>> preventing a subsequent release, and preventing other threads from >>>>> acquiring (but allowing current thread to recurisevely acquire. So >>>>> this could both hang and cause data corruption. >>>>> >>>>> The new code will still return an error but release the mutex. So >>>>> no more hangs (other than by conditions caused by data corruption) >>>>> but more opportunity for data corruption. >>>>> >>>>> Obviously it depends on exactly what happens in the critical >>>>> sections guarded by this mutex, but in general I don't agree with >>>>> this rationale for making the change: >>>>> >>>>> 204 /* If the mutex is abandoned we want to return an error >>>>> 205 * and also release the mutex so that we don't cause >>>>> 206 * other threads to be blocked. If a mutex was abandoned >>>>> 207 * we are in scary state. Data may be corrupted or >>>>> inconsistent >>>>> 208 * but it is still better to let other threads run (and >>>>> possibly >>>>> 209 * crash) than having them blocked (on the premise that a >>>>> crash >>>>> 210 * is always easier to debug than a hang). >>>>> >>>>> Considering something has to have gone drastically wrong for the >>>>> mutex to become abandoned, I'm more inclined to consider this a >>>>> fatal error and abort. >>>>> >>>>> But I'll let the serviceability folk chime in here. >>>> I was involved in fixing this and writing the comment, so obviously >>>> I thought it a good solution :-) >>>> >>>> I do agree that it would probably be a good idea to consider this a >>>> fatal error and abort. At that point in the code we don?t have any >>>> really nice ways of doing that, though. We could just print an >>>> error and call abort(). What we are doing now is returning an error >>>> from sysIPMutexEnter() and delegating the error handling to the >>>> caller. We have tried to check all call paths to verify that they >>>> do ?the right thing? in the face of an error. It is obviously hard >>>> to verify, but it looks like they all terminate the connection with >>>> some kind of error message. >>>> >>>> /Staffan >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Thank you, >>>>>> -Aleksej >>>>>> >>>>>> >>>>>> On 05/14/2014 01:05 PM, David Holmes wrote: >>>>>>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>>>>>> In windows, you acquire a mutex by waiting on it using one of >>>>>>>> the wait >>>>>>>> functions, one of them employed in the code in question. If >>>>>>>> WaitForMultipleObjects succeeds and returns the index of the >>>>>>>> mutex, >>>>>>>> current thread has ownership now. >>>>>>> Yes I understand the basic mechanics :) >>>>>>> >>>>>>>> It's also common to use multi wait functions where the event is a >>>>>>>> "cancelation token", e.g. manual reset event; this allows >>>>>>>> someone to >>>>>>>> cancel waiting on mutex acquisition and return from the wait >>>>>>>> function. >>>>>>>> Presumably that's the case here, but I'll let Aleksej confirm; >>>>>>>> just >>>>>>>> wanted to throw this out there in the meantime :). >>>>>>> Ah I see - yes cancellable lock acquisition would make sense. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Sent from my phone >>>>>>>> >>>>>>>> On May 13, 2014 6:46 PM, "David Holmes" >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Aleksej, >>>>>>>> >>>>>>>> Thanks for the doc references regarding abandonment. >>>>>>>> >>>>>>>> Let me rephrase my question. What is this logic trying to >>>>>>>> achieve by >>>>>>>> waiting on both a mutex and an event? Do we already own the >>>>>>>> mutex >>>>>>>> when this function is called? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> The Windows has a different terminology for mutex >>>>>>>> objects (much >>>>>>>> differs >>>>>>>> from the POSIX one). This one link gave me some >>>>>>>> understanding of >>>>>>>> it [1]. >>>>>>>> >>>>>>>> Here is the MSDN [1] description of what "abandoned >>>>>>>> mutex" is: >>>>>>>> " If a thread terminates without releasing its >>>>>>>> ownership of a >>>>>>>> mutex >>>>>>>> object, the mutex object is considered to be abandoned. A >>>>>>>> waiting thread >>>>>>>> can acquire ownership of an abandoned mutex object, but >>>>>>>> the wait >>>>>>>> function will return*WAIT_ABANDONED*to indicate that >>>>>>>> the mutex >>>>>>>> object is >>>>>>>> abandoned. An abandoned mutex object indicates that an >>>>>>>> error has >>>>>>>> occurred and that any shared resource being protected >>>>>>>> by the >>>>>>>> mutex >>>>>>>> object is in an undefined state. If the thread proceeds as >>>>>>>> though the >>>>>>>> mutex object had not been abandoned, it is no longer >>>>>>>> considered >>>>>>>> abandoned after the thread releases its ownership. This >>>>>>>> restores >>>>>>>> normal >>>>>>>> behavior if a handle to the mutex object is subsequently >>>>>>>> specified in a >>>>>>>> wait function." >>>>>>>> >>>>>>>> >>>>>>>> What does it mean to wait on mutex and ownership of the >>>>>>>> mutex >>>>>>>> object: >>>>>>>> "Any thread with a handle to a mutex object can use one of >>>>>>>> thewait >>>>>>>> functions >>>>>>>> >>>>>>> >>>>>>>> >to >>>>>>>> >>>>>>>> request ownership of the mutex object. If the mutex >>>>>>>> object is >>>>>>>> owned by >>>>>>>> another thread, the wait function blocks the requesting >>>>>>>> thread >>>>>>>> until the >>>>>>>> owning thread releases the mutex object using >>>>>>>> the*ReleaseMutex* >>>>>>>> >>>>>>> >>>>>>>> >__function." >>>>>>>> >>>>>>>> >>>>>>>> How we can release mutex and wait on already owned mutex: >>>>>>>> " After a thread obtains ownership of a mutex, it can >>>>>>>> specify >>>>>>>> the same >>>>>>>> mutex in repeated calls to the wait-functions >>>>>>>> >>>>>>> >>>>>>>> >__without >>>>>>>> >>>>>>>> blocking its execution. This prevents a thread from >>>>>>>> deadlocking >>>>>>>> itself >>>>>>>> while waiting for a mutex that it already owns. To >>>>>>>> release its >>>>>>>> ownership >>>>>>>> under such circumstances, the thread must >>>>>>>> call*ReleaseMutex* >>>>>>>> >>>>>>> >>>>>>>> >__once >>>>>>>> >>>>>>>> for each time that the mutex satisfied the conditions >>>>>>>> of a wait >>>>>>>> function." >>>>>>>> >>>>>>>> [1] >>>>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -Aleksej >>>>>>>> >>>>>>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>>>>>> >>>>>>>> I don't understand this one at all. What is an >>>>>>>> "abandoned >>>>>>>> mutex"? For >>>>>>>> that matter why does the code wait on a mutex and >>>>>>>> an event? >>>>>>>> Do we >>>>>>>> already own the mutex? If so what does it mean to >>>>>>>> wait on >>>>>>>> it? If not >>>>>>>> then how can we release it? >>>>>>>> >>>>>>>> ??? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>>>>>> >>>>>>>> >>>>>>>> This is debugger's shared memory transport so >>>>>>>> cc'ing >>>>>>>> serviceability-dev >>>>>>>> as that is there this code is maintained. >>>>>>>> >>>>>>>> Is there a test case or any outline of the >>>>>>>> conditions >>>>>>>> that cause this? I >>>>>>>> think that would be useful to understand the issue >>>>>>>> further. >>>>>>>> >>>>>>>> -Alan >>>>>>>> >>>>>>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Can I have a review for 8032901 bug [1] fix >>>>>>>> [2]. >>>>>>>> There is a possible >>>>>>>> case when 'WaitForMultipleObjects' function >>>>>>>> can >>>>>>>> return the >>>>>>>> WAIT_ABANDONED_0 [3] error value. >>>>>>>> In such case it's better to release the >>>>>>>> mutex and >>>>>>>> return error value. >>>>>>>> This will prevent other threads to be >>>>>>>> blocked on >>>>>>>> abandoned mutex. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Aleksej >>>>>>>> >>>>>>>> [1] >>>>>>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>>>>>> >>>>>>>> [2] >>>>>>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>>>>>> >>>>>>>> [3] >>>>>>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>> >> From mattias.tobiasson at oracle.com Wed Jun 4 11:55:10 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Wed, 4 Jun 2014 04:55:10 -0700 (PDT) Subject: RFR: 8036006 [TESTBUG] sun/tools/native2ascii/NativeErrors.java: Process exit code was 0, but error was expected Message-ID: <3bf849cf-336d-4e9b-994b-e0075b4699be@default> Hi Staffan, Could you please submit this patch. I have set sla and dholmes as reviewers. The patch is attached. Mattias ----- Original Message ----- From: david.holmes at oracle.com To: staffan.larsen at oracle.com, mattias.tobiasson at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Tuesday, June 3, 2014 4:21:40 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR: 8036006 [TESTBUG] sun/tools/native2ascii/NativeErrors.java: Process exit code was 0, but error was expected +1 David On 2/06/2014 10:14 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 2 jun 2014, at 14:11, Mattias Tobiasson wrote: > >> Hi, >> Could someone please review this test fix? >> >> The test tries to write to a read-only file and expects an error. >> The test will fail if it is run as root, because root is allowed to write to read-only files. >> >> The fix is to check if the file is really read-only with function java.io.File.canWrite(). >> If we are root then canWrite() will return true and the read-only part of the test is skipped. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8036006/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8036006 >> >> Mattias >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8036006.diff Type: text/x-patch Size: 1252 bytes Desc: not available URL: From dmitry.samersoff at oracle.com Thu Jun 5 07:08:05 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 05 Jun 2014 11:08:05 +0400 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <537B5D0B.9000207@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> Message-ID: <53901755.7050404@oracle.com> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ On 2014-05-20 17:47, Dmitry Samersoff wrote: > On 2014-04-07 16:56, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review the patch >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >> >> it's based on the patch contributed by Carlos Santos (see CR) and all >> credentials belong to him. >> >> -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 radhakrishnan.mohan at gmail.com Fri Jun 6 11:26:33 2014 From: radhakrishnan.mohan at gmail.com (Mohan Radhakrishnan) Date: Fri, 6 Jun 2014 16:56:33 +0530 Subject: API usage Message-ID: Hi, Is there a users' list ? Are there recommendations for API users anywhere in the form of articles or source code ? There was a introductory article in the Java magazine and one can look the VisualVM code. What else will help me ? Thanks, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Jun 6 11:54:11 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Jun 2014 21:54:11 +1000 Subject: API usage In-Reply-To: References: Message-ID: <5391ABE3.30805@oracle.com> Hi Mohan, On 6/06/2014 9:26 PM, Mohan Radhakrishnan wrote: > Hi, > Is there a users' list ? Are there recommendations for API users > anywhere in the form of articles or source code ? There was a > introductory article in the Java magazine and one can look the VisualVM > code. What else will help me ? Don't know exactly what you are referring to but OpenJDK lists are about developers not users (hence the -dev). For user discussion seek out a Forum. David Holmes > > Thanks, > Mohan From kevin.walls at oracle.com Fri Jun 6 21:42:36 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 06 Jun 2014 22:42:36 +0100 Subject: RFR(XXS): 8044540: serviceability/sa/jmap-hashcode/Test8028623.java should be quarantined In-Reply-To: References: <538C984E.3040605@oracle.com> Message-ID: <539235CC.1010805@oracle.com> Hi - I think this is too late, but just a note that I'd started a review request on a version of that test which would fail gracefully (pass) if it wasn't able to use jmap to attach. But I left that change (bug 8039995, on this alias) pending, waiting to find out if it was irrelevant - i.e. whether we're just making a mistake in the way we do these tests - shouldn't we be running SA tests in an environment where SA features are able to work: either running as root as required on some systems, or at least with the kernel.yama.ptrace_scope = 0 on some Linux systems. Just wanted to make sure these threads are joined up... Thanks Kevin On 02/06/14 18:28, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 2 jun 2014, at 17:29, Mikael Auno wrote: > >> Hi, >> >> Could I please have a review of this very small fix. >> >> webrev: http://cr.openjdk.java.net/~miauno/8044540/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8044540 >> >> Verified locally. >> >> Thanks, >> Mikael From poonam.bajaj at oracle.com Sat Jun 7 09:18:29 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Sat, 07 Jun 2014 14:48:29 +0530 Subject: RFR JDK-8046282: SA update Message-ID: <5392D8E5.6000105@oracle.com> Hi, Please review these changes for the bug 8046282 for JDK 9. These changes add some definitions on the SA side and the supporting code on the hotspot side. Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 Thanks, Poonam From sean.coffey at oracle.com Sat Jun 7 10:35:12 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Sat, 07 Jun 2014 11:35:12 +0100 Subject: RFR: 8046269: Build broken : THIS_FILE : undeclared identifier Message-ID: <5392EAE0.2080105@oracle.com> jdk7u-dev has windows build issues since JDK-8032901 fix was pushed. bug report : https://bugs.openjdk.java.net/browse/JDK-8046269 Fix is simple and involves defining THIS_FILE if not defined. Not an issue for JDK 8u since that logic is already there. > diff --git a/src/windows/transport/shmem/shmem_md.c > b/src/windows/transport/shmem/shmem_md.c > --- a/src/windows/transport/shmem/shmem_md.c > +++ b/src/windows/transport/shmem/shmem_md.c > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2003, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -30,6 +30,11 @@ > #include "sysShmem.h" > #include "shmemBase.h" /* for exitTransportWithError */ > > +/* Use THIS_FILE when it is available. */ > +#ifndef THIS_FILE > + #define THIS_FILE __FILE__ > +#endif > + > /* > * These functions are not completely universal. For now, they are used > * exclusively for Jbug's shared memory transport mechanism. They have regards, Sean. From sundararajan.athijegannathan at oracle.com Mon Jun 9 05:08:41 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 09 Jun 2014 10:38:41 +0530 Subject: RFR JDK-8046282: SA update In-Reply-To: <5392D8E5.6000105@oracle.com> References: <5392D8E5.6000105@oracle.com> Message-ID: <53954159.1070009@oracle.com> The pattern of enum within a class and toString helper to return string description of it -- is used for many cases. Why not use enums with String accepting constructor and toString (or new method called "toDescription()) override? You could have add "Unknown" in these enums to map to an option that is available in VM -- but not in SA. Since it is a debugger it is expected to work with incomplete info.. so whereever you map a VM data structure element to java enum, you can map unknown enum constants to "Unknown" on Java side. Of course, if there is a sentinel element defined in VM side, you could use that itself - no need for "Unknown" in such cases. It'd nice to simplify that class-within-enum pattern... -Sundar On Saturday 07 June 2014 02:48 PM, Poonam Bajaj wrote: > Hi, > > Please review these changes for the bug 8046282 for JDK 9. These > changes add some definitions on the SA side and the supporting code on > the hotspot side. > > Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 > > Thanks, > Poonam > From markus.gronlund at oracle.com Mon Jun 9 08:10:28 2014 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Mon, 9 Jun 2014 01:10:28 -0700 (PDT) Subject: RFR JDK-8046282: SA update In-Reply-To: <5392D8E5.6000105@oracle.com> References: <5392D8E5.6000105@oracle.com> Message-ID: <175cefdf-8009-4ffd-bd8b-9f4369873b91@default> Hi Poonam, I think this looks good (not a Reviewer). Thanks for giving SA some much needed attention. /Markus -----Original Message----- From: Poonam Bajaj Sent: den 7 juni 2014 11:18 To: serviceability-dev Subject: RFR JDK-8046282: SA update Hi, Please review these changes for the bug 8046282 for JDK 9. These changes add some definitions on the SA side and the supporting code on the hotspot side. Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 Thanks, Poonam From poonam.bajaj at oracle.com Mon Jun 9 09:10:50 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Mon, 09 Jun 2014 14:40:50 +0530 Subject: RFR JDK-8046282: SA update In-Reply-To: <53954159.1070009@oracle.com> References: <5392D8E5.6000105@oracle.com> <53954159.1070009@oracle.com> Message-ID: <53957A1A.7090207@oracle.com> Hi Sundar, Yes, it is possible to do that. e.g. G1YCType can be defined like this. public enum G1YCType { Normal ("Normal"), InitialMark ("Initial Mark"), DuringMark ("During Mark"), Mixed ("Mixed"), G1YCTypeEndSentinel ("Unknown") private final String value; G1YCType(String val) { this.value = val; } public String value() { return value; } } But, my purpose of having a class and an enum being used in that class was to have the similar kind of code structure on the SA side as is present on the hotspot side. e.g the above is defined as the following on the hotspot side: 030 enum G1YCType { 031 Normal, 032 InitialMark, 033 DuringMark, 034 Mixed, 035 G1YCTypeEndSentinel 036 }; 037 038 class G1YCTypeHelper { 039 public: 040 static const char* to_string(G1YCType type) { 041 switch(type) { 042 case Normal: return "Normal"; 043 case InitialMark: return "Initial Mark"; 044 case DuringMark: return "During Mark"; 045 case Mixed: return "Mixed"; 046 default: ShouldNotReachHere(); return NULL; 047 } 048 } 049 }; And I have tried to replicate the same on the SA side so that one can easily understand and map the definitions on both the sides. 27 public class G1YCTypeHelper { 28 29 public enum G1YCType { 30 Normal, 31 InitialMark, 32 DuringMark, 33 Mixed, 34 G1YCTypeEndSentinel 35 } 36 37 public static String toString(G1YCType type) { 38 switch (type) { 39 case Normal: 40 return "Normal"; 41 case InitialMark: 42 return "Initial Mark"; 43 case DuringMark: 44 return "During Mark"; 45 case Mixed: 46 return "Mixed"; 47 default: 48 return null; 49 } 50 } 51 } Please let me know if this is still a concern for you. Thanks, Poonam On 6/9/2014 10:38 AM, A. Sundararajan wrote: > The pattern of enum within a class and toString helper to return > string description of it -- is used for many cases. > > Why not use enums with String accepting constructor and toString (or > new method called "toDescription()) override? You could have add > "Unknown" in these enums to map to an option that is available in VM > -- but not in SA. > > Since it is a debugger it is expected to work with incomplete info.. > so whereever you map a VM data structure element to java enum, you can > map unknown enum constants to "Unknown" on Java side. Of course, if > there is a sentinel element defined in VM side, you could use that > itself - no need for "Unknown" in such cases. > > It'd nice to simplify that class-within-enum pattern... > > -Sundar > > On Saturday 07 June 2014 02:48 PM, Poonam Bajaj wrote: >> Hi, >> >> Please review these changes for the bug 8046282 for JDK 9. These >> changes add some definitions on the SA side and the supporting code >> on the hotspot side. >> >> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 >> >> Thanks, >> Poonam >> > From sundararajan.athijegannathan at oracle.com Mon Jun 9 09:26:57 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 09 Jun 2014 14:56:57 +0530 Subject: RFR JDK-8046282: SA update In-Reply-To: <53957A1A.7090207@oracle.com> References: <5392D8E5.6000105@oracle.com> <53954159.1070009@oracle.com> <53957A1A.7090207@oracle.com> Message-ID: <53957DE1.8060006@oracle.com> Since SA is java code, we could have it cleaner.. my 2 cents, -Sundar On Monday 09 June 2014 02:40 PM, Poonam Bajaj wrote: > Hi Sundar, > > Yes, it is possible to do that. e.g. G1YCType can be defined like this. > > public enum G1YCType { > Normal ("Normal"), > InitialMark ("Initial Mark"), > DuringMark ("During Mark"), > Mixed ("Mixed"), > G1YCTypeEndSentinel ("Unknown") > > private final String value; > > G1YCType(String val) { > this.value = val; > } > public String value() { > return value; > } > } > > But, my purpose of having a class and an enum being used in that class > was to have the similar kind of code structure on the SA side as is > present on the hotspot side. e.g the above is defined as the following > on the hotspot side: > > 030 enum G1YCType { > 031 Normal, > 032 InitialMark, > 033 DuringMark, > 034 Mixed, > 035 G1YCTypeEndSentinel > 036 }; > 037 > 038 class G1YCTypeHelper { > 039 public: > 040 static const char* to_string(G1YCType type) { > 041 switch(type) { > 042 case Normal: return "Normal"; > 043 case InitialMark: return "Initial Mark"; > 044 case DuringMark: return "During Mark"; > 045 case Mixed: return "Mixed"; > 046 default: ShouldNotReachHere(); return NULL; > 047 } > 048 } > 049 }; > > And I have tried to replicate the same on the SA side so that one can > easily understand and map the definitions on both the sides. > > 27 public class G1YCTypeHelper { > 28 > 29 public enum G1YCType { > 30 Normal, > 31 InitialMark, > 32 DuringMark, > 33 Mixed, > 34 G1YCTypeEndSentinel > 35 } > 36 > 37 public static String toString(G1YCType type) { > 38 switch (type) { > 39 case Normal: > 40 return "Normal"; > 41 case InitialMark: > 42 return "Initial Mark"; > 43 case DuringMark: > 44 return "During Mark"; > 45 case Mixed: > 46 return "Mixed"; > 47 default: > 48 return null; > 49 } > 50 } > 51 } > > > Please let me know if this is still a concern for you. > > Thanks, > Poonam > > On 6/9/2014 10:38 AM, A. Sundararajan wrote: >> The pattern of enum within a class and toString helper to return >> string description of it -- is used for many cases. >> >> Why not use enums with String accepting constructor and toString (or >> new method called "toDescription()) override? You could have add >> "Unknown" in these enums to map to an option that is available in VM >> -- but not in SA. >> >> Since it is a debugger it is expected to work with incomplete info.. >> so whereever you map a VM data structure element to java enum, you >> can map unknown enum constants to "Unknown" on Java side. Of course, >> if there is a sentinel element defined in VM side, you could use that >> itself - no need for "Unknown" in such cases. >> >> It'd nice to simplify that class-within-enum pattern... >> >> -Sundar >> >> On Saturday 07 June 2014 02:48 PM, Poonam Bajaj wrote: >>> Hi, >>> >>> Please review these changes for the bug 8046282 for JDK 9. These >>> changes add some definitions on the SA side and the supporting code >>> on the hotspot side. >>> >>> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 >>> >>> Thanks, >>> Poonam >>> >> From poonam.bajaj at oracle.com Mon Jun 9 09:27:49 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Mon, 09 Jun 2014 14:57:49 +0530 Subject: RFR JDK-8046282: SA update In-Reply-To: <175cefdf-8009-4ffd-bd8b-9f4369873b91@default> References: <5392D8E5.6000105@oracle.com> <175cefdf-8009-4ffd-bd8b-9f4369873b91@default> Message-ID: <53957E15.6050600@oracle.com> Thanks Markus! regards, Poonam On 6/9/2014 1:40 PM, Markus Gr?nlund wrote: > Hi Poonam, > > I think this looks good (not a Reviewer). > > Thanks for giving SA some much needed attention. > > /Markus > > > -----Original Message----- > From: Poonam Bajaj > Sent: den 7 juni 2014 11:18 > To: serviceability-dev > Subject: RFR JDK-8046282: SA update > > Hi, > > Please review these changes for the bug 8046282 for JDK 9. These changes add some definitions on the SA side and the supporting code on the hotspot side. > > Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 > > Thanks, > Poonam > From staffan.larsen at oracle.com Mon Jun 9 09:48:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 Jun 2014 11:48:33 +0200 Subject: RFR: 8046269: Build broken : THIS_FILE : undeclared identifier In-Reply-To: <5392EAE0.2080105@oracle.com> References: <5392EAE0.2080105@oracle.com> Message-ID: <4B267C0E-D231-4356-972E-159409027E04@oracle.com> Looks good! Thanks, /Staffan On 7 jun 2014, at 12:35, Se?n Coffey wrote: > jdk7u-dev has windows build issues since JDK-8032901 fix was pushed. > bug report : https://bugs.openjdk.java.net/browse/JDK-8046269 > > Fix is simple and involves defining THIS_FILE if not defined. Not an issue for JDK 8u since that logic is already there. > >> diff --git a/src/windows/transport/shmem/shmem_md.c b/src/windows/transport/shmem/shmem_md.c >> --- a/src/windows/transport/shmem/shmem_md.c >> +++ b/src/windows/transport/shmem/shmem_md.c >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2003, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -30,6 +30,11 @@ >> #include "sysShmem.h" >> #include "shmemBase.h" /* for exitTransportWithError */ >> >> +/* Use THIS_FILE when it is available. */ >> +#ifndef THIS_FILE >> + #define THIS_FILE __FILE__ >> +#endif >> + >> /* >> * These functions are not completely universal. For now, they are used >> * exclusively for Jbug's shared memory transport mechanism. They have > > regards, > Sean. > From alex.schenkman at oracle.com Mon Jun 9 15:27:58 2014 From: alex.schenkman at oracle.com (Alex Schenkman) Date: Mon, 09 Jun 2014 17:27:58 +0200 Subject: RFR(XS): 8046348, 8046351, 8046352, 8046355: Adding tests to ProblemList.txt Message-ID: <5395D27E.10306@oracle.com> Please review these four additions to ProblemList.txt https://bugs.openjdk.java.net/browse/JDK-8046348 http://cr.openjdk.java.net/~miauno/8046348/ https://bugs.openjdk.java.net/browse/JDK-8046351 http://cr.openjdk.java.net/~miauno/8046351/ https://bugs.openjdk.java.net/browse/JDK-8046352 http://cr.openjdk.java.net/~miauno/8046352/ https://bugs.openjdk.java.net/browse/JDK-8046355 http://cr.openjdk.java.net/~miauno/8046355/ Thanks in advance! -- Alex Schenkman Java VM SQE Stockholm -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Jun 9 17:12:47 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 Jun 2014 19:12:47 +0200 Subject: RFR(XS): 8046348, 8046351, 8046352, 8046355: Adding tests to ProblemList.txt In-Reply-To: <5395D27E.10306@oracle.com> References: <5395D27E.10306@oracle.com> Message-ID: <63E5A63A-991F-4000-AC4D-AE0D3687347E@oracle.com> Looks good. In the future I would prefer one changeset with all the changes since that would be easier to review. /Staffan On 9 jun 2014, at 17:27, Alex Schenkman wrote: > Please review these four additions to ProblemList.txt > > https://bugs.openjdk.java.net/browse/JDK-8046348 > http://cr.openjdk.java.net/~miauno/8046348/ > > https://bugs.openjdk.java.net/browse/JDK-8046351 > http://cr.openjdk.java.net/~miauno/8046351/ > > https://bugs.openjdk.java.net/browse/JDK-8046352 > http://cr.openjdk.java.net/~miauno/8046352/ > > https://bugs.openjdk.java.net/browse/JDK-8046355 > http://cr.openjdk.java.net/~miauno/8046355/ > > > Thanks in advance! > > -- > Alex Schenkman > Java VM SQE Stockholm -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Jun 9 19:03:34 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 Jun 2014 21:03:34 +0200 Subject: RFR: 8044135 Add API to start JMX agent from attach framework Message-ID: This is the first part in a two-part series of removing the management-agent.jar and replacing its functionality with APIs in the attach framework. In this change I have added the new APIs, a later change will remove management-api.jar. management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. management-agent.jar will be problematic when we move to a modular JDK in JDK 9 and should be replaced by a "real" API. So this change adds two methods to VirtualMachine in the attach framework for starting either a local or a remote management agent. webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8044135 Thanks, /Staffan From Alan.Bateman at oracle.com Mon Jun 9 19:54:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 09 Jun 2014 20:54:03 +0100 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: References: Message-ID: <539610DB.9050602@oracle.com> On 09/06/2014 20:03, Staffan Larsen wrote: > This is the first part in a two-part series of removing the management-agent.jar and replacing its functionality with APIs in the attach framework. In this change I have added the new APIs, a later change will remove management-api.jar. > > management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. > > management-agent.jar will be problematic when we move to a modular JDK in JDK 9 and should be replaced by a "real" API. So this change adds two methods to VirtualMachine in the attach framework for starting either a local or a remote management agent. > > webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8044135 > This looks reasonable to me. I assume that the removal of management-agent.jar will come in another change and that tests such as LocalManagementTest will be updated then. On this webrev then there are few unnecessary imports in HotSpotVirtualMachine - I only noticed these as it initially looked like this was introducing a dependency on JMX. IllegalArgumentException isn't a checked exception so there isn't a need for verifyKeyName to declare it. Missing space in "if(" at line 174. An alternative name for verifyKeyName is checkedKeyName - might be more natural when used with filter. -Alan. From brent.christian at oracle.com Mon Jun 9 22:23:30 2014 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 09 Jun 2014 15:23:30 -0700 Subject: RFR (8u40) 8044473 : Allow for extended set of platform MXBeans Message-ID: <539633E2.1050505@oracle.com> Please review my change for: 8044473 - Allow for extended set of platform MXBeans which adds an internal ExtendedPlatformComponent mechanism. There are no new public APIs or MXBeans. JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8044473 Webrev: http://cr.openjdk.java.net/~bchristi/8044473/webrev.00/ Thanks, -Brent From david.holmes at oracle.com Tue Jun 10 06:30:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Jun 2014 16:30:29 +1000 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: References: Message-ID: <5396A605.7050608@oracle.com> Hi Staffan, A few general comments: VirtualMachine.java: - Can/should these references be links to external docs? _See the online documentation for "Monitoring and Management Using JMX Technology" for further details._ startManagementAgent(Properties agentProperties) should specify what happens when agentProperties is null: NPE, IAE, no-op ? (Current implementation throws NPE) --- LocalVirtualMachine.java needs copyright year update. --- SimpleProvider.java (also needs copyright update) Do the empty methods not generate a javac warning regarding it not being possible to throw IOException? You can drop the throws IOException as it is okay to throw fewer exceptions than the super method you are overriding. --- Cheers, David On 10/06/2014 5:03 AM, Staffan Larsen wrote: > This is the first part in a two-part series of removing the management-agent.jar and replacing its functionality with APIs in the attach framework. In this change I have added the new APIs, a later change will remove management-api.jar. > > management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. > > management-agent.jar will be problematic when we move to a modular JDK in JDK 9 and should be replaced by a "real" API. So this change adds two methods to VirtualMachine in the attach framework for starting either a local or a remote management agent. > > webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8044135 > > Thanks, > /Staffan > From staffan.larsen at oracle.com Tue Jun 10 07:06:10 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Jun 2014 09:06:10 +0200 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: <539610DB.9050602@oracle.com> References: <539610DB.9050602@oracle.com> Message-ID: <98AA20E7-8FFC-441D-A15A-1CF26EB5C5FB@oracle.com> On 9 jun 2014, at 21:54, Alan Bateman wrote: > On 09/06/2014 20:03, Staffan Larsen wrote: >> This is the first part in a two-part series of removing the management-agent.jar and replacing its functionality with APIs in the attach framework. In this change I have added the new APIs, a later change will remove management-api.jar. >> >> management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. >> management-agent.jar will be problematic when we move to a modular JDK in JDK 9 and should be replaced by a "real" API. So this change adds two methods to VirtualMachine in the attach framework for starting either a local or a remote management agent. >> >> webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8044135 >> > This looks reasonable to me. I assume that the removal of management-agent.jar will come in another change and that tests such as LocalManagementTest will be updated then. That was my plan, but now I think it would be better to update the tests in this change to validate that the new API works as expected by the tests. > On this webrev then there are few unnecessary imports in HotSpotVirtualMachine - I only noticed these as it initially looked like this was introducing a dependency on JMX. Fixed. > IllegalArgumentException isn't a checked exception so there isn't a need for verifyKeyName to declare it. Missing space in "if(" at line 174. An alternative name for verifyKeyName is checkedKeyName - might be more natural when used with filter. Fixed. Thanks, /Staffan > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Jun 10 07:09:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Jun 2014 09:09:32 +0200 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: <5396A605.7050608@oracle.com> References: <5396A605.7050608@oracle.com> Message-ID: On 10 jun 2014, at 08:30, David Holmes wrote: > Hi Staffan, > > A few general comments: > > VirtualMachine.java: > > - Can/should these references be links to external docs? > > _See the online documentation for "Monitoring and Management Using JMX Technology" for further details._ Good suggestion. I have tried adding links in a similar way to the JVMTI links in the same file. > > startManagementAgent(Properties agentProperties) should specify what happens when agentProperties is null: NPE, IAE, no-op ? (Current implementation throws NPE) I changed the spec and implementation to throw IAE. > > --- > > LocalVirtualMachine.java needs copyright year update. Fixed. > > --- > > SimpleProvider.java (also needs copyright update) > > Do the empty methods not generate a javac warning regarding it not being possible to throw IOException? You can drop the throws IOException as it is okay to throw fewer exceptions than the super method you are overriding. Fixed. An updated webrev is here: http://cr.openjdk.java.net/~sla/8044135/webrev.01/ This version also has updates to test files that used management-agent.jar: test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java test/sun/management/jmxremote/bootstrap/LocalManagementTest.java test/sun/management/jmxremote/bootstrap/TestManager.java test/sun/management/jmxremote/startstop/JMXStartStopTest.java I also too the liberty of fixing some warnings in those files. Thanks, /Staffan > > --- > > Cheers, > David > > > On 10/06/2014 5:03 AM, Staffan Larsen wrote: >> This is the first part in a two-part series of removing the management-agent.jar and replacing its functionality with APIs in the attach framework. In this change I have added the new APIs, a later change will remove management-api.jar. >> >> management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. >> >> management-agent.jar will be problematic when we move to a modular JDK in JDK 9 and should be replaced by a "real" API. So this change adds two methods to VirtualMachine in the attach framework for starting either a local or a remote management agent. >> >> webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8044135 >> >> Thanks, >> /Staffan >> From david.holmes at oracle.com Tue Jun 10 07:21:14 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Jun 2014 17:21:14 +1000 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: References: <5396A605.7050608@oracle.com> Message-ID: <5396B1EA.2010101@oracle.com> On 10/06/2014 5:09 PM, Staffan Larsen wrote: > On 10 jun 2014, at 08:30, David Holmes wrote: >> >> A few general comments: >> >> VirtualMachine.java: >> >> - Can/should these references be links to external docs? >> >> _See the online documentation for "Monitoring and Management Using JMX Technology" for further details._ > > Good suggestion. I have tried adding links in a similar way to the JVMTI links in the same file. I know there is some kind of doc-root anchor you can use instead of: href="../../../../../../../../technotes :) >> >> startManagementAgent(Properties agentProperties) should specify what happens when agentProperties is null: NPE, IAE, no-op ? (Current implementation throws NPE) > > I changed the spec and implementation to throw IAE. Ok. I would have gone for NPE but I don't know what the conventions are in this part of the API space. :) >> >> --- >> >> LocalVirtualMachine.java needs copyright year update. > > Fixed. > >> >> --- >> >> SimpleProvider.java (also needs copyright update) >> >> Do the empty methods not generate a javac warning regarding it not being possible to throw IOException? You can drop the throws IOException as it is okay to throw fewer exceptions than the super method you are overriding. > > Fixed. > > An updated webrev is here: http://cr.openjdk.java.net/~sla/8044135/webrev.01/ > > This version also has updates to test files that used management-agent.jar: > test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java > test/sun/management/jmxremote/bootstrap/LocalManagementTest.java > test/sun/management/jmxremote/bootstrap/TestManager.java > test/sun/management/jmxremote/startstop/JMXStartStopTest.java > > I also too the liberty of fixing some warnings in those files. Can't really comment on the test updates as I'm not familiar with their operation. Cheers, David > Thanks, > /Staffan > > >> >> --- >> >> Cheers, >> David >> >> >> On 10/06/2014 5:03 AM, Staffan Larsen wrote: >>> This is the first part in a two-part series of removing the management-agent.jar and replacing its functionality with APIs in the attach framework. In this change I have added the new APIs, a later change will remove management-api.jar. >>> >>> management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. >>> >>> management-agent.jar will be problematic when we move to a modular JDK in JDK 9 and should be replaced by a "real" API. So this change adds two methods to VirtualMachine in the attach framework for starting either a local or a remote management agent. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8044135 >>> >>> Thanks, >>> /Staffan >>> > From Alan.Bateman at oracle.com Tue Jun 10 07:40:36 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Jun 2014 08:40:36 +0100 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: References: <5396A605.7050608@oracle.com> Message-ID: <5396B674.1060907@oracle.com> On 10/06/2014 08:09, Staffan Larsen wrote: > : > > > An updated webrev is here: http://cr.openjdk.java.net/~sla/8044135/webrev.01/ To David's point about IAE vs. NPE then this API throws NPE when passed a null so it would be good to keep that consistent. I don't think I've come across @SuppressedWarnings("unused") before - if these methods are never called in the tests then can't they be removed? -Alan. From staffan.larsen at oracle.com Tue Jun 10 07:46:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Jun 2014 09:46:32 +0200 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: <5396B674.1060907@oracle.com> References: <5396A605.7050608@oracle.com> <5396B674.1060907@oracle.com> Message-ID: On 10 jun 2014, at 09:40, Alan Bateman wrote: > On 10/06/2014 08:09, Staffan Larsen wrote: >> : >> >> >> An updated webrev is here: http://cr.openjdk.java.net/~sla/8044135/webrev.01/ > To David's point about IAE vs. NPE then this API throws NPE when passed a null so it would be good to keep that consistent. Changed: http://cr.openjdk.java.net/~sla/8044135/webrev.02/ > I don't think I've come across @SuppressedWarnings("unused") before - if these methods are never called in the tests then can't they be removed? They are used, but only via reflection from the main() method. Eclipse, at least, can?t see that so flags them as ?unused? - minor annoyance. Thank, /Staffan From staffan.larsen at oracle.com Tue Jun 10 07:58:23 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Jun 2014 09:58:23 +0200 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure Message-ID: This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ bug: https://bugs.openjdk.java.net/browse/JDK-6622468 The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. I have run this through JPRT with no failures. Thanks, /Staffan [0] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html From serguei.spitsyn at oracle.com Tue Jun 10 09:44:34 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 10 Jun 2014 02:44:34 -0700 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: References: Message-ID: <5396D382.9050804@oracle.com> Staffan, It looks good, just one comment. test/com/sun/jdi/VMConnection.java 61 String vmOpts = System.getProperty("test.vm.opts"); 62 if (vmOpts != null) { 63 retVal += System.getProperty("test.vm.opts"); I wonder why not this: 63 retVal += vmOpts; Thanks, Serguei On 6/10/14 12:58 AM, Staffan Larsen wrote: > This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. > > For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. > > In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. > > webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-6622468 > > The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. > > I have run this through JPRT with no failures. > > Thanks, > /Staffan > > > [0] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Jun 10 11:59:21 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Jun 2014 13:59:21 +0200 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: <5396D382.9050804@oracle.com> References: <5396D382.9050804@oracle.com> Message-ID: <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> On 10 jun 2014, at 11:44, serguei.spitsyn at oracle.com wrote: > Staffan, > > It looks good, just one comment. > > test/com/sun/jdi/VMConnection.java > 61 String vmOpts = System.getProperty("test.vm.opts"); > 62 if (vmOpts != null) { > 63 retVal += System.getProperty("test.vm.opts"); > I wonder why not this: > 63 retVal += vmOpts; Uh. Yeah, I wonder that, too. Fixed. :-) Thanks, /Staffan > > Thanks, > Serguei > > > On 6/10/14 12:58 AM, Staffan Larsen wrote: >> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >> >> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >> >> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >> >> webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-6622468 >> >> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >> >> I have run this through JPRT with no failures. >> >> Thanks, >> /Staffan >> >> >> [0] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Jun 10 12:07:54 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 10 Jun 2014 14:07:54 +0200 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: References: Message-ID: <5396F51A.9020000@oracle.com> Hi Staffan, In: http://cr.openjdk.java.net/~sla/8044135/webrev.00/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java.frames.html line 190, I wonder whether some escape mechanism should be put in place for entry.getValue(). Do you have the guarantee that entry.getValue() will never contain a white space? Best regards, -- daniel On 6/9/14 9:03 PM, Staffan Larsen wrote: > This is the first part in a two-part series of removing the management-agent.jar and replacing its functionality with APIs in the attach framework. In this change I have added the new APIs, a later change will remove management-api.jar. > > management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. > > management-agent.jar will be problematic when we move to a modular JDK in JDK 9 and should be replaced by a "real" API. So this change adds two methods to VirtualMachine in the attach framework for starting either a local or a remote management agent. > > webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8044135 > > Thanks, > /Staffan > From staffan.larsen at oracle.com Tue Jun 10 13:19:49 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Jun 2014 15:19:49 +0200 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: <5396F51A.9020000@oracle.com> References: <5396F51A.9020000@oracle.com> Message-ID: <341B174D-B0BC-44A5-B158-DCC2A7D0AAD9@oracle.com> On 10 jun 2014, at 14:07, Daniel Fuchs wrote: > Hi Staffan, > > In: > http://cr.openjdk.java.net/~sla/8044135/webrev.00/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java.frames.html > > line 190, I wonder whether some escape mechanism should > be put in place for entry.getValue(). > > Do you have the guarantee that entry.getValue() will never contain > a white space? Good point. I?ve added some code to put the values in quotes if there are spaces in the values. (I know I could add the quotes always, but it felt more correct to only do it when needed). I also updated the StartManagementAgent test to verify that this works. webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.03/ Thanks, /Staffan > > Best regards, > > -- daniel > > On 6/9/14 9:03 PM, Staffan Larsen wrote: >> This is the first part in a two-part series of removing the management-agent.jar and replacing its functionality with APIs in the attach framework. In this change I have added the new APIs, a later change will remove management-api.jar. >> >> management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. >> >> management-agent.jar will be problematic when we move to a modular JDK in JDK 9 and should be replaced by a "real" API. So this change adds two methods to VirtualMachine in the attach framework for starting either a local or a remote management agent. >> >> webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8044135 >> >> Thanks, >> /Staffan >> > From Alan.Bateman at oracle.com Wed Jun 11 06:58:29 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Jun 2014 07:58:29 +0100 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: References: <5396A605.7050608@oracle.com> <5396B674.1060907@oracle.com> Message-ID: <5397FE15.4080409@oracle.com> On 10/06/2014 08:46, Staffan Larsen wrote: > > Changed: http://cr.openjdk.java.net/~sla/8044135/webrev.02/ > > I took another pass over this (webrev.03, latest I think). Now that the NPE issue is resolved then I think it means that VirtualMachine#startManagementAgent needs to @throws IllegalArgumentException in its javadoc to make it clear that this is throw when non-String or other validation fails. It probably doesn't have to specify that the properties have to start with com.sun.management as that might change over time. It otherwise looks okay to me, I guess I would leave out the Eclipse specific @SuppressWarnings("unused") as we don't usually use this in the JDK code base for non-javac warnings. -Alan From staffan.larsen at oracle.com Wed Jun 11 08:00:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Jun 2014 10:00:09 +0200 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> Message-ID: I realized that the code in VMConnection does not take into account the test.java.opts property as it should. updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ (only VMConnection changed) Thanks, /Staffan On 10 jun 2014, at 13:59, Staffan Larsen wrote: > > On 10 jun 2014, at 11:44, serguei.spitsyn at oracle.com wrote: > >> Staffan, >> >> It looks good, just one comment. >> >> test/com/sun/jdi/VMConnection.java >> 61 String vmOpts = System.getProperty("test.vm.opts"); >> 62 if (vmOpts != null) { >> 63 retVal += System.getProperty("test.vm.opts"); >> I wonder why not this: >> 63 retVal += vmOpts; > Uh. Yeah, I wonder that, too. Fixed. :-) > > Thanks, > /Staffan > > > >> >> Thanks, >> Serguei >> >> >> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>> >>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>> >>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>> >>> webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-6622468 >>> >>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>> >>> I have run this through JPRT with no failures. >>> >>> Thanks, >>> /Staffan >>> >>> >>> [0] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 11 08:07:41 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 11 Jun 2014 01:07:41 -0700 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> Message-ID: <53980E4D.9050209@oracle.com> On 6/11/14 1:00 AM, Staffan Larsen wrote: > I realized that the code in VMConnection does not take into account > the test.java.opts property as it should. > > updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ > (only > VMConnection changed) Nice catch! It looks good. Thanks, Serguei > > Thanks, > /Staffan > > On 10 jun 2014, at 13:59, Staffan Larsen > wrote: > >> >> On 10 jun 2014, at 11:44,serguei.spitsyn at oracle.com >> wrote: >> >>> Staffan, >>> >>> It looks good, just one comment. >>> >>> test/com/sun/jdi/VMConnection.java >>> 61 String vmOpts = System.getProperty("test.vm.opts"); >>> 62 if (vmOpts != null) { >>> 63 retVal += System.getProperty("test.vm.opts"); >>> I wonder why not this: >>> 63 retVal += vmOpts; >> Uh. Yeah, I wonder that, too. Fixed. :-) >> >> Thanks, >> /Staffan >> >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>>> >>>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>>> >>>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>>> >>>> webrev:http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>>> bug:https://bugs.openjdk.java.net/browse/JDK-6622468 >>>> >>>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>>> >>>> I have run this through JPRT with no failures. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> [0]http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Jun 11 08:08:48 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Jun 2014 10:08:48 +0200 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: <5397FE15.4080409@oracle.com> References: <5396A605.7050608@oracle.com> <5396B674.1060907@oracle.com> <5397FE15.4080409@oracle.com> Message-ID: <2820B1F0-5315-482F-9454-C86D9F2DA374@oracle.com> On 11 jun 2014, at 08:58, Alan Bateman wrote: > On 10/06/2014 08:46, Staffan Larsen wrote: >> >> Changed: http://cr.openjdk.java.net/~sla/8044135/webrev.02/ >> >> > I took another pass over this (webrev.03, latest I think). > > Now that the NPE issue is resolved then I think it means that VirtualMachine#startManagementAgent needs to @throws IllegalArgumentException in its javadoc to make it clear that this is throw when non-String or other validation fails. It probably doesn't have to specify that the properties have to start with com.sun.management as that might change over time. I added: + * @throws IllegalArgumentException + * If keys or values in agentProperties are invalid. + * > It otherwise looks okay to me, I guess I would leave out the Eclipse specific @SuppressWarnings("unused") as we don't usually use this in the JDK code base for non-javac warnings. I would prefer to leave them in as they do no harm for non-Eclipse users and are only present in the tests. updated webrev: http://cr.openjdk.java.net/~sla/8044135/webrev.04/ Thanks, /Staffan From staffan.larsen at oracle.com Wed Jun 11 08:09:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Jun 2014 10:09:09 +0200 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: <53980E4D.9050209@oracle.com> References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> <53980E4D.9050209@oracle.com> Message-ID: <21704F94-3326-4F41-8219-98664798EB8B@oracle.com> Thanks Serguei! On 11 jun 2014, at 10:07, serguei.spitsyn at oracle.com wrote: > On 6/11/14 1:00 AM, Staffan Larsen wrote: >> I realized that the code in VMConnection does not take into account the test.java.opts property as it should. >> >> updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ (only VMConnection changed) > > Nice catch! > It looks good. > > Thanks, > Serguei > >> >> Thanks, >> /Staffan >> >> On 10 jun 2014, at 13:59, Staffan Larsen wrote: >> >>> >>> On 10 jun 2014, at 11:44, serguei.spitsyn at oracle.com wrote: >>> >>>> Staffan, >>>> >>>> It looks good, just one comment. >>>> >>>> test/com/sun/jdi/VMConnection.java >>>> 61 String vmOpts = System.getProperty("test.vm.opts"); >>>> 62 if (vmOpts != null) { >>>> 63 retVal += System.getProperty("test.vm.opts"); >>>> I wonder why not this: >>>> 63 retVal += vmOpts; >>> Uh. Yeah, I wonder that, too. Fixed. :-) >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>>>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>>>> >>>>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>>>> >>>>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6622468 >>>>> >>>>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>>>> >>>>> I have run this through JPRT with no failures. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> [0] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Jun 11 10:18:22 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 Jun 2014 12:18:22 +0200 Subject: RFR (8u40) 8044473 : Allow for extended set of platform MXBeans In-Reply-To: <539633E2.1050505@oracle.com> References: <539633E2.1050505@oracle.com> Message-ID: <53982CEE.5020407@oracle.com> Hi Brent, Looks reasonable to me. ExtendedPlatformComponent doesn't support registering several instances of MXBean with the same interface but that looks like a reasonable limitation. best regards, -- daniel On 6/10/14 12:23 AM, Brent Christian wrote: > Please review my change for: > > 8044473 - Allow for extended set of platform MXBeans > > which adds an internal ExtendedPlatformComponent mechanism. > > There are no new public APIs or MXBeans. > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8044473 > > Webrev: > http://cr.openjdk.java.net/~bchristi/8044473/webrev.00/ > > Thanks, > -Brent > From Alan.Bateman at oracle.com Wed Jun 11 12:57:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Jun 2014 13:57:14 +0100 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: <2820B1F0-5315-482F-9454-C86D9F2DA374@oracle.com> References: <5396A605.7050608@oracle.com> <5396B674.1060907@oracle.com> <5397FE15.4080409@oracle.com> <2820B1F0-5315-482F-9454-C86D9F2DA374@oracle.com> Message-ID: <5398522A.5040700@oracle.com> On 11/06/2014 09:08, Staffan Larsen wrote: > > I added: > > + * @throws IllegalArgumentException > + * If keys or values in agentProperties are invalid. > + * That is probably okay for now, thanks. > : > > I would prefer to leave them in as they do no harm for non-Eclipse users and are only present in the tests. > I don't use Eclipse but I will guess that it shouldn't complain if these methods are package-private (just an approach that would avoid suppressing non-javac warnings). -Alan From staffan.larsen at oracle.com Wed Jun 11 13:39:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Jun 2014 15:39:31 +0200 Subject: RFR: 8044135 Add API to start JMX agent from attach framework In-Reply-To: <5398522A.5040700@oracle.com> References: <5396A605.7050608@oracle.com> <5396B674.1060907@oracle.com> <5397FE15.4080409@oracle.com> <2820B1F0-5315-482F-9454-C86D9F2DA374@oracle.com> <5398522A.5040700@oracle.com> Message-ID: <80E70CB4-2E81-475A-B346-837E62FFD198@oracle.com> On 11 jun 2014, at 14:57, Alan Bateman wrote: > On 11/06/2014 09:08, Staffan Larsen wrote: >> >> I added: >> >> + * @throws IllegalArgumentException >> + * If keys or values in agentProperties are invalid. >> + * > That is probably okay for now, thanks. > > >> : >> >> I would prefer to leave them in as they do no harm for non-Eclipse users and are only present in the tests. >> > I don't use Eclipse but I will guess that it shouldn't complain if these methods are package-private (just an approach that would avoid suppressing non-javac warnings). Yes, that works. I will push with that change. Thanks, /Staffan > > -Alan From erik.gahlin at oracle.com Wed Jun 11 22:37:10 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 12 Jun 2014 00:37:10 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind Message-ID: <5398DA16.7090200@oracle.com> Hi, Could I have a review of a test that has been failing intermittently. The test now uses files for synchronization instead of waiting for a process that sleeps. Webrev: http://cr.openjdk.java.net/~egahlin/8028474/ Bug: https://bugs.openjdk.java.net/browse/JDK-8028474 Description: The test starts ten Java processes, each with a unique id. Each process creates a file named after the id and then it waits for the test to remove the file, at which the Java process exits. The processes are monitored by the test to make sure notifications are sent when processes are started/terminated. To avoid Java processes being left behind, in case of an unexpected failure, shutdown hooks are registered that remove files when the test exits. If files are not removed, i.e. due to a JVM crash, the Java processes will exit themselves after 1000 s. Thanks Erik From shanliang.jiang at oracle.com Thu Jun 12 06:21:41 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 12 Jun 2014 08:21:41 +0200 Subject: Codereview request: JDK-8044865 Fix raw and unchecked lint warnings in management-related code Message-ID: <539946F5.6030801@oracle.com> Hi, Please review the following fix: webrev: http://cr.openjdk.java.net/~sjiang/JDK-8044865/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8044865 Thanks, Shanliang From staffan.larsen at oracle.com Thu Jun 12 06:29:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Jun 2014 08:29:05 +0200 Subject: Codereview request: JDK-8044865 Fix raw and unchecked lint warnings in management-related code In-Reply-To: <539946F5.6030801@oracle.com> References: <539946F5.6030801@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 12 jun 2014, at 08:21, shanliang wrote: > Hi, > > Please review the following fix: > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8044865/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8044865 > > Thanks, > Shanliang From daniel.fuchs at oracle.com Thu Jun 12 06:36:00 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Jun 2014 08:36:00 +0200 Subject: Codereview request: JDK-8044865 Fix raw and unchecked lint warnings in management-related code In-Reply-To: <539946F5.6030801@oracle.com> References: <539946F5.6030801@oracle.com> Message-ID: <53994A50.1040702@oracle.com> looks good Shanliang! -- daniel On 6/12/14 8:21 AM, shanliang wrote: > Hi, > > Please review the following fix: > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8044865/00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8044865 > > Thanks, > Shanliang From erik.gahlin at oracle.com Thu Jun 12 07:31:49 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 12 Jun 2014 09:31:49 +0200 Subject: Codereview request: JDK-8044865 Fix raw and unchecked lint warnings in management-related code In-Reply-To: <539946F5.6030801@oracle.com> References: <539946F5.6030801@oracle.com> Message-ID: <53995765.7060907@oracle.com> Looks good Erik shanliang skrev 12/06/14 08:21: > Hi, > > Please review the following fix: > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8044865/00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8044865 > > Thanks, > Shanliang From erik.gahlin at oracle.com Thu Jun 12 07:36:38 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 12 Jun 2014 09:36:38 +0200 Subject: jmx-dev Codereview request: JDK-8044865 Fix raw and unchecked lint warnings in management-related code In-Reply-To: <539946F5.6030801@oracle.com> References: <539946F5.6030801@oracle.com> Message-ID: <53995886.5090104@oracle.com> Looks good Erik shanliang skrev 12/06/14 08:21: > Hi, > > Please review the following fix: > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8044865/00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8044865 > > Thanks, > Shanliang From poonam.bajaj at oracle.com Thu Jun 12 07:55:46 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 12 Jun 2014 13:25:46 +0530 Subject: RFR JDK-8046282: SA update In-Reply-To: <53957DE1.8060006@oracle.com> References: <5392D8E5.6000105@oracle.com> <53954159.1070009@oracle.com> <53957A1A.7090207@oracle.com> <53957DE1.8060006@oracle.com> Message-ID: <53995D02.6060406@oracle.com> Hi Sundar, Is it okay with you if I keep the enum and class definitions as they are now? And can I add you as the reviewer for these changes? Thanks, Poonam On 6/9/2014 2:56 PM, A. Sundararajan wrote: > Since SA is java code, we could have it cleaner.. > > my 2 cents, > -Sundar > > On Monday 09 June 2014 02:40 PM, Poonam Bajaj wrote: >> Hi Sundar, >> >> Yes, it is possible to do that. e.g. G1YCType can be defined like this. >> >> public enum G1YCType { >> Normal ("Normal"), >> InitialMark ("Initial Mark"), >> DuringMark ("During Mark"), >> Mixed ("Mixed"), >> G1YCTypeEndSentinel ("Unknown") >> >> private final String value; >> >> G1YCType(String val) { >> this.value = val; >> } >> public String value() { >> return value; >> } >> } >> >> But, my purpose of having a class and an enum being used in that >> class was to have the similar kind of code structure on the SA side >> as is present on the hotspot side. e.g the above is defined as the >> following on the hotspot side: >> >> 030 enum G1YCType { >> 031 Normal, >> 032 InitialMark, >> 033 DuringMark, >> 034 Mixed, >> 035 G1YCTypeEndSentinel >> 036 }; >> 037 >> 038 class G1YCTypeHelper { >> 039 public: >> 040 static const char* to_string(G1YCType type) { >> 041 switch(type) { >> 042 case Normal: return "Normal"; >> 043 case InitialMark: return "Initial Mark"; >> 044 case DuringMark: return "During Mark"; >> 045 case Mixed: return "Mixed"; >> 046 default: ShouldNotReachHere(); return NULL; >> 047 } >> 048 } >> 049 }; >> >> And I have tried to replicate the same on the SA side so that one can >> easily understand and map the definitions on both the sides. >> >> 27 public class G1YCTypeHelper { >> 28 >> 29 public enum G1YCType { >> 30 Normal, >> 31 InitialMark, >> 32 DuringMark, >> 33 Mixed, >> 34 G1YCTypeEndSentinel >> 35 } >> 36 >> 37 public static String toString(G1YCType type) { >> 38 switch (type) { >> 39 case Normal: >> 40 return "Normal"; >> 41 case InitialMark: >> 42 return "Initial Mark"; >> 43 case DuringMark: >> 44 return "During Mark"; >> 45 case Mixed: >> 46 return "Mixed"; >> 47 default: >> 48 return null; >> 49 } >> 50 } >> 51 } >> >> >> Please let me know if this is still a concern for you. >> >> Thanks, >> Poonam >> >> On 6/9/2014 10:38 AM, A. Sundararajan wrote: >>> The pattern of enum within a class and toString helper to return >>> string description of it -- is used for many cases. >>> >>> Why not use enums with String accepting constructor and toString (or >>> new method called "toDescription()) override? You could have add >>> "Unknown" in these enums to map to an option that is available in VM >>> -- but not in SA. >>> >>> Since it is a debugger it is expected to work with incomplete info.. >>> so whereever you map a VM data structure element to java enum, you >>> can map unknown enum constants to "Unknown" on Java side. Of >>> course, if there is a sentinel element defined in VM side, you could >>> use that itself - no need for "Unknown" in such cases. >>> >>> It'd nice to simplify that class-within-enum pattern... >>> >>> -Sundar >>> >>> On Saturday 07 June 2014 02:48 PM, Poonam Bajaj wrote: >>>> Hi, >>>> >>>> Please review these changes for the bug 8046282 for JDK 9. These >>>> changes add some definitions on the SA side and the supporting code >>>> on the hotspot side. >>>> >>>> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 >>>> >>>> Thanks, >>>> Poonam >>>> >>> > From alex.schenkman at oracle.com Thu Jun 12 09:37:07 2014 From: alex.schenkman at oracle.com (Alex Schenkman) Date: Thu, 12 Jun 2014 11:37:07 +0200 Subject: RFR(XS): 8046348, 8046351, 8046352, 8046355: Adding tests to ProblemList.txt In-Reply-To: <63E5A63A-991F-4000-AC4D-AE0D3687347E@oracle.com> References: <5395D27E.10306@oracle.com> <63E5A63A-991F-4000-AC4D-AE0D3687347E@oracle.com> Message-ID: <539974C3.4010601@oracle.com> Thanks for the review, Staffan. Could you please help me commit this? The changesets are attached. On 2014-06-09 19:12, Staffan Larsen wrote: > Looks good. In the future I would prefer one changeset with all the > changes since that would be easier to review. > > /Staffan > > > On 9 jun 2014, at 17:27, Alex Schenkman > wrote: > >> Please review these four additions to ProblemList.txt >> >> https://bugs.openjdk.java.net/browse/JDK-8046348 >> http://cr.openjdk.java.net/~miauno/8046348/ >> >> https://bugs.openjdk.java.net/browse/JDK-8046351 >> http://cr.openjdk.java.net/~miauno/8046351/ >> >> https://bugs.openjdk.java.net/browse/JDK-8046352 >> http://cr.openjdk.java.net/~miauno/8046352/ >> >> https://bugs.openjdk.java.net/browse/JDK-8046355 >> http://cr.openjdk.java.net/~miauno/8046355/ >> >> >> Thanks in advance! >> >> -- >> Alex Schenkman >> Java VM SQE Stockholm > -- Alex Schenkman Java VM SQE Stockholm -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8046355.patch Type: text/x-patch Size: 4948 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8046352.patch Type: text/x-patch Size: 4281 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8046351.patch Type: text/x-patch Size: 3625 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8046348.patch Type: text/x-patch Size: 2842 bytes Desc: not available URL: From serguei.spitsyn at oracle.com Thu Jun 12 09:50:38 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Jun 2014 02:50:38 -0700 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <53901755.7050404@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> Message-ID: <539977EE.70106@oracle.com> Hi Dmitry, There is no description of the fix. Could you, please, provide one? What did you basically wanted to achieve? Also, how did the fix been tested? It seems, a unit test would be nice to have. Thanks, Serguei On 6/5/14 12:08 AM, Dmitry Samersoff wrote: > http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ > > On 2014-05-20 17:47, Dmitry Samersoff wrote: >> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review the patch >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>> >>> it's based on the patch contributed by Carlos Santos (see CR) and all >>> credentials belong to him. >>> >>> -Dmitry >>> >> > From dmitry.samersoff at oracle.com Thu Jun 12 10:10:01 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 Jun 2014 14:10:01 +0400 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <539977EE.70106@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> <539977EE.70106@oracle.com> Message-ID: <53997C79.1000500@oracle.com> Serguei, *The problem:* If someone run prelink utility while Java program is running DSO's mappings in it's /proc//maps become messy. After prelink it contains entry like /lib64/libc-2.15.so (deleted) /lib64/libpthread-2.15.so.#prelink#.EECVts instead of normal /lib64/libc-2.15.so Here is the letter from Carlos, describing the problem in details: https://bugs.openjdk.java.net/browse/JDK-8038392 *The fix:* The fix allows SA to handle situation above. Also I fix longstanding issue - maps file parser in SA doesn't skip [stack*, [heap] etc entry and attempts to open it as a DSO *Testing:* I tested it manually with a different of prelink options (no prelink, prelink all, prelink some libraries only) -Dmitry On 2014-06-12 13:50, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > There is no description of the fix. > Could you, please, provide one? > What did you basically wanted to achieve? > Also, how did the fix been tested? > It seems, a unit test would be nice to have. > > Thanks, > Serguei > > On 6/5/14 12:08 AM, Dmitry Samersoff wrote: >> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >> >> On 2014-05-20 17:47, Dmitry Samersoff wrote: >>> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>>> Hi Everybody, >>>> >>>> Please review the patch >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>> >>>> it's based on the patch contributed by Carlos Santos (see CR) and all >>>> credentials belong to him. >>>> >>>> -Dmitry >>>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Thu Jun 12 10:49:50 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 Jun 2014 03:49:50 -0700 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <53997C79.1000500@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> <539977EE.70106@oracle.com> <53997C79.1000500@oracle.com> Message-ID: <539985CE.1000408@oracle.com> Dmitry, Thank you for the details! I have a couple of comments so far. + if (word[5][0] == '[') { + // not a shared library entry. ignore. + if (strncmp(word[5],"[stack",6) == 0) { + continue; + } + if (strncmp(word[5],"[heap]",6) == 0) { + continue; + } + + // SA don't handle VDSO + if (strncmp(word[5],"[vdso]",6) == 0) { + continue; + } + if (strncmp(word[5],"[vsyscall]",6) == 0) { + continue; + } + } I'd suggest to simplify the fragment above to something like thus: + // SA does not handle the lines with patterns: + // "[stack]", "[heap]", "[vdso]","[vsyscall]", etc. + if (word[5][0] == '[') { + continue;// not a shared library entry, ignore + } This fragment does not look correct: + if (nwords > 6) { + // prelink altered mapfile when the program is running. + // Entries like one below have to be skipped + // /lib64/libc-2.15.so (deleted) + // SO name in entries like one below have to be stripped. + // /lib64/libpthread-2.15.so.#prelink#.EECVts + char *s = strstr(word[5],".#prelink#"); + if (s == NULL) { + // No prelink keyword. skip deleted library + print_debug("skip shared object %s deleted by prelink\n", word[5]); + continue; + } + + // Fall through + print_debug("rectifing shared object name %s changed by prelink\n", word[5]); + *s = 0; + } The line with the pattern "(deleted)" has 7 words, but the line like: /lib64/libpthread-2.15.so.#prelink#.EECVts has only 6 words, and so, your code will not process it properly. I'd expect something like this: + if (nwords > 6) { + // prelink altered mapfile when the program is running. + // Entries like one below have to be skipped: + // /lib64/libc-2.15.so (deleted) + print_debug("skip shared object %s deleted by prelink\n", word[5]); + continue; + } else { + char *s = strstr(word[5],".#prelink#"); + if (s != NULL) { + // There is the prelink keyword + print_debug("rectifying shared object name %s changed by prelink\n", word[5]); + *s = 0; + } + } Is it hard to add a unit test for this issue? Thanks, Serguei On 6/12/14 3:10 AM, Dmitry Samersoff wrote: > Serguei, > > *The problem:* > > If someone run prelink utility while Java program is running DSO's > mappings in it's /proc//maps become messy. > > After prelink it contains entry like > > /lib64/libc-2.15.so (deleted) > /lib64/libpthread-2.15.so.#prelink#.EECVts > > instead of normal > > /lib64/libc-2.15.so > > Here is the letter from Carlos, describing the problem in details: > https://bugs.openjdk.java.net/browse/JDK-8038392 > > *The fix:* > > The fix allows SA to handle situation above. > > Also I fix longstanding issue - maps file parser in SA doesn't skip > [stack*, [heap] etc entry and attempts to open it as a DSO > > *Testing:* > > I tested it manually with a different of prelink options (no prelink, > prelink all, prelink some libraries only) > > -Dmitry > > > On 2014-06-12 13:50, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> There is no description of the fix. >> Could you, please, provide one? >> What did you basically wanted to achieve? >> Also, how did the fix been tested? >> It seems, a unit test would be nice to have. >> >> Thanks, >> Serguei >> >> On 6/5/14 12:08 AM, Dmitry Samersoff wrote: >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>> >>> On 2014-05-20 17:47, Dmitry Samersoff wrote: >>>> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>>>> Hi Everybody, >>>>> >>>>> Please review the patch >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>> >>>>> it's based on the patch contributed by Carlos Santos (see CR) and all >>>>> credentials belong to him. >>>>> >>>>> -Dmitry >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Thu Jun 12 11:23:05 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 Jun 2014 15:23:05 +0400 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <539985CE.1000408@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> <539977EE.70106@oracle.com> <53997C79.1000500@oracle.com> <539985CE.1000408@oracle.com> Message-ID: <53998D99.2060505@oracle.com> Serguei, Thank you for the review, please see below. On 2014-06-12 14:49, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thank you for the details! > > I have a couple of comments so far. > > + if (word[5][0] == '[') { > + // not a shared library entry. ignore. > + if (strncmp(word[5],"[stack",6) == 0) { > + continue; > + } > + if (strncmp(word[5],"[heap]",6) == 0) { > + continue; > + } > + > + // SA don't handle VDSO > + if (strncmp(word[5],"[vdso]",6) == 0) { > + continue; > + } > + if (strncmp(word[5],"[vsyscall]",6) == 0) { > + continue; > + } > + } > > I'd suggest to simplify the fragment above to something like thus: > > + // SA does not handle the lines with patterns: > + // "[stack]", "[heap]", "[vdso]", "[vsyscall]", etc. > + if (word[5][0] == '[') { > + continue; // not a shared library entry, ignore > + } I'll change it. > > This fragment does not look correct: > > + if (nwords > 6) { > + // prelink altered mapfile when the program is running. > + // Entries like one below have to be skipped > + // /lib64/libc-2.15.so (deleted) > + // SO name in entries like one below have to be stripped. > + // /lib64/libpthread-2.15.so.#prelink#.EECVts > + char *s = strstr(word[5],".#prelink#"); > + if (s == NULL) { > + // No prelink keyword. skip deleted library > + print_debug("skip shared object %s deleted by prelink\n", word[5]); > + continue; > + } > + > + // Fall through > + print_debug("rectifing shared object name %s changed by prelink\n", word[5]); > + *s = 0; > + } We always have word "(deleted)" at the end (see fragment of map below). But if the word "(deleted)" relates to original DSO we should skip the entry but if it relates to tmp file created by prelink we should accept this mapping - it's a new place for original library. Actually map entry looks like: 7f490b190000-7f490b1a8000 r-xp 00000000 08:01 350 /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) 7f490b1a8000-7f490b3a7000 ---p 00018000 08:01 350 /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) 7f490b3a7000-7f490b3a8000 r--p 00017000 08:01 350 /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) 7f490b3a8000-7f490b3a9000 rw-p 00018000 08:01 350 /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) 7f490b3a9000-7f490b3ad000 rw-p 00000000 00:00 0 7f490b3ad000-7f490b3cf000 r-xp 00000000 08:01 48013 /lib64/ld-2.15.so (deleted) > The line with the pattern "(deleted)" has 7 words, but the line like: > /lib64/libpthread-2.15.so.#prelink#.EECVts > > has only 6 words, and so, your code will not process it properly. > > I'd expect something like this: > > + if (nwords > 6) { > + // prelink altered mapfile when the program is running. > + // Entries like one below have to be skipped: > + // /lib64/libc-2.15.so (deleted) > + print_debug("skip shared object %s deleted by prelink\n", word[5]); > + continue; > + } else { > + char *s = strstr(word[5],".#prelink#"); > + if (s != NULL) { > + // There is the prelink keyword > + print_debug("rectifying shared object name %s changed by prelink\n", word[5]); > + *s = 0; > + } > + } > > > Is it hard to add a unit test for this issue? It's not possible to test prelink during nightly as it affects entire OS (actually it's a bad idea to run prelink while java program is running). -Dmitry > > Thanks, > Serguei > > On 6/12/14 3:10 AM, Dmitry Samersoff wrote: >> Serguei, >> >> *The problem:* >> >> If someone run prelink utility while Java program is running DSO's >> mappings in it's /proc//maps become messy. >> >> After prelink it contains entry like >> >> /lib64/libc-2.15.so (deleted) >> /lib64/libpthread-2.15.so.#prelink#.EECVts >> >> instead of normal >> >> /lib64/libc-2.15.so >> >> Here is the letter from Carlos, describing the problem in details: >> https://bugs.openjdk.java.net/browse/JDK-8038392 >> >> *The fix:* >> >> The fix allows SA to handle situation above. >> >> Also I fix longstanding issue - maps file parser in SA doesn't skip >> [stack*, [heap] etc entry and attempts to open it as a DSO >> >> *Testing:* >> >> I tested it manually with a different of prelink options (no prelink, >> prelink all, prelink some libraries only) >> >> -Dmitry >> >> >> On 2014-06-12 13:50, serguei.spitsyn at oracle.com wrote: >>> Hi Dmitry, >>> >>> There is no description of the fix. >>> Could you, please, provide one? >>> What did you basically wanted to achieve? >>> Also, how did the fix been tested? >>> It seems, a unit test would be nice to have. >>> >>> Thanks, >>> Serguei >>> >>> On 6/5/14 12:08 AM, Dmitry Samersoff wrote: >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>> >>>> On 2014-05-20 17:47, Dmitry Samersoff wrote: >>>>> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>>>>> Hi Everybody, >>>>>> >>>>>> Please review the patch >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>> >>>>>> it's based on the patch contributed by Carlos Santos (see CR) and all >>>>>> credentials belong to him. >>>>>> >>>>>> -Dmitry >>>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Jun 13 08:14:05 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Jun 2014 01:14:05 -0700 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <53998D99.2060505@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> <539977EE.70106@oracle.com> <53997C79.1000500@oracle.com> <539985CE.1000408@oracle.com> <53998D99.2060505@oracle.com> Message-ID: <539AB2CD.2040809@oracle.com> Dmitry, Thank you for the explanations! The fix looks good pending the simplification below. I'm Ok with your testing approach. Thanks, Serguei On 6/12/14 4:23 AM, Dmitry Samersoff wrote: > Serguei, > > Thank you for the review, please see below. > > On 2014-06-12 14:49, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> Thank you for the details! >> >> I have a couple of comments so far. >> >> + if (word[5][0] == '[') { >> + // not a shared library entry. ignore. >> + if (strncmp(word[5],"[stack",6) == 0) { >> + continue; >> + } >> + if (strncmp(word[5],"[heap]",6) == 0) { >> + continue; >> + } >> + >> + // SA don't handle VDSO >> + if (strncmp(word[5],"[vdso]",6) == 0) { >> + continue; >> + } >> + if (strncmp(word[5],"[vsyscall]",6) == 0) { >> + continue; >> + } >> + } >> >> I'd suggest to simplify the fragment above to something like thus: >> >> + // SA does not handle the lines with patterns: >> + // "[stack]", "[heap]", "[vdso]", "[vsyscall]", etc. >> + if (word[5][0] == '[') { >> + continue; // not a shared library entry, ignore >> + } > I'll change it. > >> This fragment does not look correct: >> >> + if (nwords > 6) { >> + // prelink altered mapfile when the program is running. >> + // Entries like one below have to be skipped >> + // /lib64/libc-2.15.so (deleted) >> + // SO name in entries like one below have to be stripped. >> + // /lib64/libpthread-2.15.so.#prelink#.EECVts >> + char *s = strstr(word[5],".#prelink#"); >> + if (s == NULL) { >> + // No prelink keyword. skip deleted library >> + print_debug("skip shared object %s deleted by prelink\n", word[5]); >> + continue; >> + } >> + >> + // Fall through >> + print_debug("rectifing shared object name %s changed by prelink\n", word[5]); >> + *s = 0; >> + } > > We always have word "(deleted)" at the end (see fragment of map below). > > But if the word "(deleted)" relates to original DSO we should skip the > entry but if it relates to tmp file created by prelink we should accept > this mapping - it's a new place for original library. > > > Actually map entry looks like: > > 7f490b190000-7f490b1a8000 r-xp 00000000 08:01 350 > /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) > > 7f490b1a8000-7f490b3a7000 ---p 00018000 08:01 350 > /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) > > 7f490b3a7000-7f490b3a8000 r--p 00017000 08:01 350 > /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) > > 7f490b3a8000-7f490b3a9000 rw-p 00018000 08:01 > 350 /lib64/libpthread-2.15.so.#prelink#.EECVts > (deleted) > > 7f490b3a9000-7f490b3ad000 rw-p 00000000 00:00 0 > 7f490b3ad000-7f490b3cf000 r-xp 00000000 08:01 > > 48013 /lib64/ld-2.15.so (deleted) > > >> The line with the pattern "(deleted)" has 7 words, but the line like: >> /lib64/libpthread-2.15.so.#prelink#.EECVts >> >> has only 6 words, and so, your code will not process it properly. >> >> I'd expect something like this: >> >> + if (nwords > 6) { >> + // prelink altered mapfile when the program is running. >> + // Entries like one below have to be skipped: >> + // /lib64/libc-2.15.so (deleted) >> + print_debug("skip shared object %s deleted by prelink\n", word[5]); >> + continue; >> + } else { >> + char *s = strstr(word[5],".#prelink#"); >> + if (s != NULL) { >> + // There is the prelink keyword >> + print_debug("rectifying shared object name %s changed by prelink\n", word[5]); >> + *s = 0; >> + } >> + } >> >> >> Is it hard to add a unit test for this issue? > It's not possible to test prelink during nightly as it affects entire OS > (actually it's a bad idea to run prelink while java program is running). > > > -Dmitry > > > >> Thanks, >> Serguei >> >> On 6/12/14 3:10 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> *The problem:* >>> >>> If someone run prelink utility while Java program is running DSO's >>> mappings in it's /proc//maps become messy. >>> >>> After prelink it contains entry like >>> >>> /lib64/libc-2.15.so (deleted) >>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>> >>> instead of normal >>> >>> /lib64/libc-2.15.so >>> >>> Here is the letter from Carlos, describing the problem in details: >>> https://bugs.openjdk.java.net/browse/JDK-8038392 >>> >>> *The fix:* >>> >>> The fix allows SA to handle situation above. >>> >>> Also I fix longstanding issue - maps file parser in SA doesn't skip >>> [stack*, [heap] etc entry and attempts to open it as a DSO >>> >>> *Testing:* >>> >>> I tested it manually with a different of prelink options (no prelink, >>> prelink all, prelink some libraries only) >>> >>> -Dmitry >>> >>> >>> On 2014-06-12 13:50, serguei.spitsyn at oracle.com wrote: >>>> Hi Dmitry, >>>> >>>> There is no description of the fix. >>>> Could you, please, provide one? >>>> What did you basically wanted to achieve? >>>> Also, how did the fix been tested? >>>> It seems, a unit test would be nice to have. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 6/5/14 12:08 AM, Dmitry Samersoff wrote: >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>> >>>>> On 2014-05-20 17:47, Dmitry Samersoff wrote: >>>>>> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>>>>>> Hi Everybody, >>>>>>> >>>>>>> Please review the patch >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>>> >>>>>>> it's based on the patch contributed by Carlos Santos (see CR) and all >>>>>>> credentials belong to him. >>>>>>> >>>>>>> -Dmitry >>>>>>> > From dmitry.samersoff at oracle.com Fri Jun 13 10:47:45 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 13 Jun 2014 14:47:45 +0400 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <539AB2CD.2040809@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> <539977EE.70106@oracle.com> <53997C79.1000500@oracle.com> <539985CE.1000408@oracle.com> <53998D99.2060505@oracle.com> <539AB2CD.2040809@oracle.com> Message-ID: <539AD6D1.20609@oracle.com> Serguei, Thank you for the review. Updated webrev is here: http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.03/ -Dmitry On 2014-06-13 12:14, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thank you for the explanations! > The fix looks good pending the simplification below. > I'm Ok with your testing approach. > > Thanks, > Serguei > > On 6/12/14 4:23 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Thank you for the review, please see below. >> >> On 2014-06-12 14:49, serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> Thank you for the details! >>> >>> I have a couple of comments so far. >>> >>> + if (word[5][0] == '[') { >>> + // not a shared library entry. ignore. >>> + if (strncmp(word[5],"[stack",6) == 0) { >>> + continue; >>> + } >>> + if (strncmp(word[5],"[heap]",6) == 0) { >>> + continue; >>> + } >>> + >>> + // SA don't handle VDSO >>> + if (strncmp(word[5],"[vdso]",6) == 0) { >>> + continue; >>> + } >>> + if (strncmp(word[5],"[vsyscall]",6) == 0) { >>> + continue; >>> + } >>> + } >>> >>> I'd suggest to simplify the fragment above to something like thus: >>> >>> + // SA does not handle the lines with patterns: >>> + // "[stack]", "[heap]", "[vdso]", "[vsyscall]", etc. >>> + if (word[5][0] == '[') { >>> + continue; // not a shared library entry, ignore >>> + } >> I'll change it. >> >>> This fragment does not look correct: >>> >>> + if (nwords > 6) { >>> + // prelink altered mapfile when the program is running. >>> + // Entries like one below have to be skipped >>> + // /lib64/libc-2.15.so (deleted) >>> + // SO name in entries like one below have to be stripped. >>> + // /lib64/libpthread-2.15.so.#prelink#.EECVts >>> + char *s = strstr(word[5],".#prelink#"); >>> + if (s == NULL) { >>> + // No prelink keyword. skip deleted library >>> + print_debug("skip shared object %s deleted by prelink\n", >>> word[5]); >>> + continue; >>> + } >>> + >>> + // Fall through >>> + print_debug("rectifing shared object name %s changed by >>> prelink\n", word[5]); >>> + *s = 0; >>> + } >> >> We always have word "(deleted)" at the end (see fragment of map >> below). >> >> But if the word "(deleted)" relates to original DSO we should skip the >> entry but if it relates to tmp file created by prelink we should accept >> this mapping - it's a new place for original library. >> >> >> Actually map entry looks like: >> >> 7f490b190000-7f490b1a8000 r-xp 00000000 08:01 350 >> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >> >> 7f490b1a8000-7f490b3a7000 ---p 00018000 08:01 350 >> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >> >> 7f490b3a7000-7f490b3a8000 r--p 00017000 08:01 350 >> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >> >> 7f490b3a8000-7f490b3a9000 rw-p 00018000 08:01 >> 350 /lib64/libpthread-2.15.so.#prelink#.EECVts >> (deleted) >> >> 7f490b3a9000-7f490b3ad000 rw-p 00000000 00:00 0 >> 7f490b3ad000-7f490b3cf000 r-xp 00000000 08:01 >> >> 48013 /lib64/ld-2.15.so (deleted) >> >> >>> The line with the pattern "(deleted)" has 7 words, but the line like: >>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>> >>> has only 6 words, and so, your code will not process it properly. >>> >>> I'd expect something like this: >>> >>> + if (nwords > 6) { >>> + // prelink altered mapfile when the program is running. >>> + // Entries like one below have to be skipped: >>> + // /lib64/libc-2.15.so (deleted) >>> + print_debug("skip shared object %s deleted by prelink\n", >>> word[5]); >>> + continue; >>> + } else { >>> + char *s = strstr(word[5],".#prelink#"); >>> + if (s != NULL) { >>> + // There is the prelink keyword >>> + print_debug("rectifying shared object name %s changed by >>> prelink\n", word[5]); >>> + *s = 0; >>> + } >>> + } >>> >>> >>> Is it hard to add a unit test for this issue? >> It's not possible to test prelink during nightly as it affects entire OS >> (actually it's a bad idea to run prelink while java program is running). >> >> >> -Dmitry >> >> >> >>> Thanks, >>> Serguei >>> >>> On 6/12/14 3:10 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> *The problem:* >>>> >>>> If someone run prelink utility while Java program is running DSO's >>>> mappings in it's /proc//maps become messy. >>>> >>>> After prelink it contains entry like >>>> >>>> /lib64/libc-2.15.so (deleted) >>>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>>> >>>> instead of normal >>>> >>>> /lib64/libc-2.15.so >>>> >>>> Here is the letter from Carlos, describing the problem in details: >>>> https://bugs.openjdk.java.net/browse/JDK-8038392 >>>> >>>> *The fix:* >>>> >>>> The fix allows SA to handle situation above. >>>> >>>> Also I fix longstanding issue - maps file parser in SA doesn't skip >>>> [stack*, [heap] etc entry and attempts to open it as a DSO >>>> >>>> *Testing:* >>>> >>>> I tested it manually with a different of prelink options (no prelink, >>>> prelink all, prelink some libraries only) >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-06-12 13:50, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dmitry, >>>>> >>>>> There is no description of the fix. >>>>> Could you, please, provide one? >>>>> What did you basically wanted to achieve? >>>>> Also, how did the fix been tested? >>>>> It seems, a unit test would be nice to have. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 6/5/14 12:08 AM, Dmitry Samersoff wrote: >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>> >>>>>> On 2014-05-20 17:47, Dmitry Samersoff wrote: >>>>>>> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>>>>>>> Hi Everybody, >>>>>>>> >>>>>>>> Please review the patch >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>>>> >>>>>>>> it's based on the patch contributed by Carlos Santos (see CR) >>>>>>>> and all >>>>>>>> credentials belong to him. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Jun 13 10:53:16 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Jun 2014 03:53:16 -0700 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <539AD6D1.20609@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> <539977EE.70106@oracle.com> <53997C79.1000500@oracle.com> <539985CE.1000408@oracle.com> <53998D99.2060505@oracle.com> <539AB2CD.2040809@oracle.com> <539AD6D1.20609@oracle.com> Message-ID: <539AD81C.3030105@oracle.com> On 6/13/14 3:47 AM, Dmitry Samersoff wrote: > Serguei, > > Thank you for the review. > > Updated webrev is here: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.03/ Good as expected. Thanks, Serguei > > -Dmitry > > On 2014-06-13 12:14, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> Thank you for the explanations! >> The fix looks good pending the simplification below. >> I'm Ok with your testing approach. >> >> Thanks, >> Serguei >> >> On 6/12/14 4:23 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Thank you for the review, please see below. >>> >>> On 2014-06-12 14:49, serguei.spitsyn at oracle.com wrote: >>>> Dmitry, >>>> >>>> Thank you for the details! >>>> >>>> I have a couple of comments so far. >>>> >>>> + if (word[5][0] == '[') { >>>> + // not a shared library entry. ignore. >>>> + if (strncmp(word[5],"[stack",6) == 0) { >>>> + continue; >>>> + } >>>> + if (strncmp(word[5],"[heap]",6) == 0) { >>>> + continue; >>>> + } >>>> + >>>> + // SA don't handle VDSO >>>> + if (strncmp(word[5],"[vdso]",6) == 0) { >>>> + continue; >>>> + } >>>> + if (strncmp(word[5],"[vsyscall]",6) == 0) { >>>> + continue; >>>> + } >>>> + } >>>> >>>> I'd suggest to simplify the fragment above to something like thus: >>>> >>>> + // SA does not handle the lines with patterns: >>>> + // "[stack]", "[heap]", "[vdso]", "[vsyscall]", etc. >>>> + if (word[5][0] == '[') { >>>> + continue; // not a shared library entry, ignore >>>> + } >>> I'll change it. >>> >>>> This fragment does not look correct: >>>> >>>> + if (nwords > 6) { >>>> + // prelink altered mapfile when the program is running. >>>> + // Entries like one below have to be skipped >>>> + // /lib64/libc-2.15.so (deleted) >>>> + // SO name in entries like one below have to be stripped. >>>> + // /lib64/libpthread-2.15.so.#prelink#.EECVts >>>> + char *s = strstr(word[5],".#prelink#"); >>>> + if (s == NULL) { >>>> + // No prelink keyword. skip deleted library >>>> + print_debug("skip shared object %s deleted by prelink\n", >>>> word[5]); >>>> + continue; >>>> + } >>>> + >>>> + // Fall through >>>> + print_debug("rectifing shared object name %s changed by >>>> prelink\n", word[5]); >>>> + *s = 0; >>>> + } >>> We always have word "(deleted)" at the end (see fragment of map >>> below). >>> >>> But if the word "(deleted)" relates to original DSO we should skip the >>> entry but if it relates to tmp file created by prelink we should accept >>> this mapping - it's a new place for original library. >>> >>> >>> Actually map entry looks like: >>> >>> 7f490b190000-7f490b1a8000 r-xp 00000000 08:01 350 >>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>> >>> 7f490b1a8000-7f490b3a7000 ---p 00018000 08:01 350 >>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>> >>> 7f490b3a7000-7f490b3a8000 r--p 00017000 08:01 350 >>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>> >>> 7f490b3a8000-7f490b3a9000 rw-p 00018000 08:01 >>> 350 /lib64/libpthread-2.15.so.#prelink#.EECVts >>> (deleted) >>> >>> 7f490b3a9000-7f490b3ad000 rw-p 00000000 00:00 0 >>> 7f490b3ad000-7f490b3cf000 r-xp 00000000 08:01 >>> >>> 48013 /lib64/ld-2.15.so (deleted) >>> >>> >>>> The line with the pattern "(deleted)" has 7 words, but the line like: >>>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>>> >>>> has only 6 words, and so, your code will not process it properly. >>>> >>>> I'd expect something like this: >>>> >>>> + if (nwords > 6) { >>>> + // prelink altered mapfile when the program is running. >>>> + // Entries like one below have to be skipped: >>>> + // /lib64/libc-2.15.so (deleted) >>>> + print_debug("skip shared object %s deleted by prelink\n", >>>> word[5]); >>>> + continue; >>>> + } else { >>>> + char *s = strstr(word[5],".#prelink#"); >>>> + if (s != NULL) { >>>> + // There is the prelink keyword >>>> + print_debug("rectifying shared object name %s changed by >>>> prelink\n", word[5]); >>>> + *s = 0; >>>> + } >>>> + } >>>> >>>> >>>> Is it hard to add a unit test for this issue? >>> It's not possible to test prelink during nightly as it affects entire OS >>> (actually it's a bad idea to run prelink while java program is running). >>> >>> >>> -Dmitry >>> >>> >>> >>>> Thanks, >>>> Serguei >>>> >>>> On 6/12/14 3:10 AM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> *The problem:* >>>>> >>>>> If someone run prelink utility while Java program is running DSO's >>>>> mappings in it's /proc//maps become messy. >>>>> >>>>> After prelink it contains entry like >>>>> >>>>> /lib64/libc-2.15.so (deleted) >>>>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>>>> >>>>> instead of normal >>>>> >>>>> /lib64/libc-2.15.so >>>>> >>>>> Here is the letter from Carlos, describing the problem in details: >>>>> https://bugs.openjdk.java.net/browse/JDK-8038392 >>>>> >>>>> *The fix:* >>>>> >>>>> The fix allows SA to handle situation above. >>>>> >>>>> Also I fix longstanding issue - maps file parser in SA doesn't skip >>>>> [stack*, [heap] etc entry and attempts to open it as a DSO >>>>> >>>>> *Testing:* >>>>> >>>>> I tested it manually with a different of prelink options (no prelink, >>>>> prelink all, prelink some libraries only) >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-06-12 13:50, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> There is no description of the fix. >>>>>> Could you, please, provide one? >>>>>> What did you basically wanted to achieve? >>>>>> Also, how did the fix been tested? >>>>>> It seems, a unit test would be nice to have. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 6/5/14 12:08 AM, Dmitry Samersoff wrote: >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>>> >>>>>>> On 2014-05-20 17:47, Dmitry Samersoff wrote: >>>>>>>> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>>>>>>>> Hi Everybody, >>>>>>>>> >>>>>>>>> Please review the patch >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>>>>> >>>>>>>>> it's based on the patch contributed by Carlos Santos (see CR) >>>>>>>>> and all >>>>>>>>> credentials belong to him. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> > From staffan.larsen at oracle.com Fri Jun 13 10:58:15 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Jun 2014 12:58:15 +0200 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <539AD6D1.20609@oracle.com> References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> <539977EE.70106@oracle.com> <53997C79.1000500@oracle.com> <539985CE.1000408@oracle.com> <53998D99.2060505@oracle.com> <539AB2CD.2040809@oracle.com> <539AD6D1.20609@oracle.com> Message-ID: Looks good! One small nit: rectifing -> rectifying Thanks, /Staffan On 13 jun 2014, at 12:47, Dmitry Samersoff wrote: > Serguei, > > Thank you for the review. > > Updated webrev is here: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.03/ > > -Dmitry > > On 2014-06-13 12:14, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> Thank you for the explanations! >> The fix looks good pending the simplification below. >> I'm Ok with your testing approach. >> >> Thanks, >> Serguei >> >> On 6/12/14 4:23 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Thank you for the review, please see below. >>> >>> On 2014-06-12 14:49, serguei.spitsyn at oracle.com wrote: >>>> Dmitry, >>>> >>>> Thank you for the details! >>>> >>>> I have a couple of comments so far. >>>> >>>> + if (word[5][0] == '[') { >>>> + // not a shared library entry. ignore. >>>> + if (strncmp(word[5],"[stack",6) == 0) { >>>> + continue; >>>> + } >>>> + if (strncmp(word[5],"[heap]",6) == 0) { >>>> + continue; >>>> + } >>>> + >>>> + // SA don't handle VDSO >>>> + if (strncmp(word[5],"[vdso]",6) == 0) { >>>> + continue; >>>> + } >>>> + if (strncmp(word[5],"[vsyscall]",6) == 0) { >>>> + continue; >>>> + } >>>> + } >>>> >>>> I'd suggest to simplify the fragment above to something like thus: >>>> >>>> + // SA does not handle the lines with patterns: >>>> + // "[stack]", "[heap]", "[vdso]", "[vsyscall]", etc. >>>> + if (word[5][0] == '[') { >>>> + continue; // not a shared library entry, ignore >>>> + } >>> I'll change it. >>> >>>> This fragment does not look correct: >>>> >>>> + if (nwords > 6) { >>>> + // prelink altered mapfile when the program is running. >>>> + // Entries like one below have to be skipped >>>> + // /lib64/libc-2.15.so (deleted) >>>> + // SO name in entries like one below have to be stripped. >>>> + // /lib64/libpthread-2.15.so.#prelink#.EECVts >>>> + char *s = strstr(word[5],".#prelink#"); >>>> + if (s == NULL) { >>>> + // No prelink keyword. skip deleted library >>>> + print_debug("skip shared object %s deleted by prelink\n", >>>> word[5]); >>>> + continue; >>>> + } >>>> + >>>> + // Fall through >>>> + print_debug("rectifing shared object name %s changed by >>>> prelink\n", word[5]); >>>> + *s = 0; >>>> + } >>> >>> We always have word "(deleted)" at the end (see fragment of map >>> below). >>> >>> But if the word "(deleted)" relates to original DSO we should skip the >>> entry but if it relates to tmp file created by prelink we should accept >>> this mapping - it's a new place for original library. >>> >>> >>> Actually map entry looks like: >>> >>> 7f490b190000-7f490b1a8000 r-xp 00000000 08:01 350 >>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>> >>> 7f490b1a8000-7f490b3a7000 ---p 00018000 08:01 350 >>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>> >>> 7f490b3a7000-7f490b3a8000 r--p 00017000 08:01 350 >>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>> >>> 7f490b3a8000-7f490b3a9000 rw-p 00018000 08:01 >>> 350 /lib64/libpthread-2.15.so.#prelink#.EECVts >>> (deleted) >>> >>> 7f490b3a9000-7f490b3ad000 rw-p 00000000 00:00 0 >>> 7f490b3ad000-7f490b3cf000 r-xp 00000000 08:01 >>> >>> 48013 /lib64/ld-2.15.so (deleted) >>> >>> >>>> The line with the pattern "(deleted)" has 7 words, but the line like: >>>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>>> >>>> has only 6 words, and so, your code will not process it properly. >>>> >>>> I'd expect something like this: >>>> >>>> + if (nwords > 6) { >>>> + // prelink altered mapfile when the program is running. >>>> + // Entries like one below have to be skipped: >>>> + // /lib64/libc-2.15.so (deleted) >>>> + print_debug("skip shared object %s deleted by prelink\n", >>>> word[5]); >>>> + continue; >>>> + } else { >>>> + char *s = strstr(word[5],".#prelink#"); >>>> + if (s != NULL) { >>>> + // There is the prelink keyword >>>> + print_debug("rectifying shared object name %s changed by >>>> prelink\n", word[5]); >>>> + *s = 0; >>>> + } >>>> + } >>>> >>>> >>>> Is it hard to add a unit test for this issue? >>> It's not possible to test prelink during nightly as it affects entire OS >>> (actually it's a bad idea to run prelink while java program is running). >>> >>> >>> -Dmitry >>> >>> >>> >>>> Thanks, >>>> Serguei >>>> >>>> On 6/12/14 3:10 AM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> *The problem:* >>>>> >>>>> If someone run prelink utility while Java program is running DSO's >>>>> mappings in it's /proc//maps become messy. >>>>> >>>>> After prelink it contains entry like >>>>> >>>>> /lib64/libc-2.15.so (deleted) >>>>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>>>> >>>>> instead of normal >>>>> >>>>> /lib64/libc-2.15.so >>>>> >>>>> Here is the letter from Carlos, describing the problem in details: >>>>> https://bugs.openjdk.java.net/browse/JDK-8038392 >>>>> >>>>> *The fix:* >>>>> >>>>> The fix allows SA to handle situation above. >>>>> >>>>> Also I fix longstanding issue - maps file parser in SA doesn't skip >>>>> [stack*, [heap] etc entry and attempts to open it as a DSO >>>>> >>>>> *Testing:* >>>>> >>>>> I tested it manually with a different of prelink options (no prelink, >>>>> prelink all, prelink some libraries only) >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-06-12 13:50, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> There is no description of the fix. >>>>>> Could you, please, provide one? >>>>>> What did you basically wanted to achieve? >>>>>> Also, how did the fix been tested? >>>>>> It seems, a unit test would be nice to have. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 6/5/14 12:08 AM, Dmitry Samersoff wrote: >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>>> >>>>>>> On 2014-05-20 17:47, Dmitry Samersoff wrote: >>>>>>>> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>>>>>>>> Hi Everybody, >>>>>>>>> >>>>>>>>> Please review the patch >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>>>>> >>>>>>>>> it's based on the patch contributed by Carlos Santos (see CR) >>>>>>>>> and all >>>>>>>>> credentials belong to him. >>>>>>>>> >>>>>>>>> -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 yekaterina.kantserova at oracle.com Fri Jun 13 10:59:58 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 13 Jun 2014 12:59:58 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <5398DA16.7090200@oracle.com> References: <5398DA16.7090200@oracle.com> Message-ID: <539AD9AE.2050309@oracle.com> Erik, is there some reason why we need to keep MonitorVmStartTerminate.sh? I've moved the JTreg header to MonitorVmStartTerminate.java /* * @test * @bug 4990825 * @summary attach to external but local JVM processes * @library /lib/testlibrary * @build jdk.testlibrary.* * @run main MonitorVmStartTerminate */ and the test works just fine. The JTreg run contains all pathes and system properties MonitorVmStartTerminate.sh tries to construct: ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate See the log attached. Note *@build jdk.testlibrary.** instead of *@build jdk.testlibrary.ProcessTools* to make sure all testlibrary classes are compiled to the right place when running tests concurrently. Thanks, Katja (Not a Reviewer) On 06/12/2014 12:37 AM, Erik Gahlin wrote: > Hi, > > Could I have a review of a test that has been failing > intermittently. The test now uses files for synchronization > instead of waiting for a process that sleeps. > > Webrev: > http://cr.openjdk.java.net/~egahlin/8028474/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8028474 > > Description: > > The test starts ten Java processes, each with a unique id. > > Each process creates a file named after the id and then it waits for > the test to remove the file, at which the Java process exits. > > The processes are monitored by the test to make sure notifications > are sent when processes are started/terminated. > > To avoid Java processes being left behind, in case of an unexpected > failure, shutdown hooks are registered that remove files when the test > exits. If files are not removed, i.e. due to a JVM crash, > the Java processes will exit themselves after 1000 s. > > Thanks > Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- #Test Results (version 2) #Fri Jun 13 12:32:26 CEST 2014 #checksum:17dc52f725b2e9b #-----testdescription----- $file=/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java $root=/localhome/ykantser/jdk9/dev/jdk/test keywords=bug4990825 library=/lib/testlibrary run=USER_SPECIFIED build jdk.testlibrary.*\nUSER_SPECIFIED main MonitorVmStartTerminate\n source=MonitorVmStartTerminate.java title=attach to external but local JVM processes #-----environment----- #-----testresult----- description=file\:/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java elapsed=3131 0\:00\:03.131 end=Fri Jun 13 12\:32\:26 CEST 2014 environment=regtest execStatus=Passed. Execution successful hostname=ykantser02 javatestOS=Linux 3.5.0-39-generic (amd64) javatestVersion=4.4 jtregVersion=jtreg 4.1 fcs b09 script=com.sun.javatest.regtest.RegressionScript sections=script_messages build compile build compile main start=Fri Jun 13 12\:32\:23 CEST 2014 test=sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java user.name=ykantser work=/tmp/jtreg/jtreg-workdir/sun/jvmstat/monitor/MonitoredVm #section:script_messages ----------messages:(5/286)---------- JDK under test: (/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image) java version "1.9.0-internal" Java(TM) SE Runtime Environment (build 1.9.0-internal-ykantser_2014_05_02_14_36-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) #section:build ----------messages:(3/123)---------- command: build jdk.testlibrary.* reason: User specified action: run build jdk.testlibrary.* elapsed time (seconds): 1.051 result: Passed. Build successful #section:compile ----------messages:(3/1586)---------- command: compile -XDignore.symbol.file=true /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/FileUtils.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/IOUtils.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/JDKToolFinder.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/Asserts.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/ProcessThread.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/InputArguments.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/XRun.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/Sleeper.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/StreamPumper.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/JcmdBase.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/OutputBuffer.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/JDKToolLauncher.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/Utils.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/TestThread.java reason: .class file out of date or does not exist elapsed time (seconds): 1.047 ----------rerun:(18/3169)*---------- DISPLAY=:0 \\ GNOME_DESKTOP_SESSION_ID=this-is-deprecated \\ HOME=/home/ykantser \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ /localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/javac \\ -J-Dtest.vm.opts= \\ -J-Dtest.jdk=/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image \\ -J-Dtest.timeout.factor=1.0 \\ -J-Dtest.src.path=/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm:/localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary \\ -J-Dtest.compiler.opts= \\ -J-Dcompile.jdk=/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image \\ -J-Dtest.classes=/tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm \\ -J-Dtest.class.path=/tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm:/tmp/jtreg/jtreg-workdir/classes/lib/testlibrary \\ -J-Dtest.java.opts= \\ -J-Dtest.src=/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm \\ -J-Dtest.tool.vm.opts= \\ -d /tmp/jtreg/jtreg-workdir/classes/lib/testlibrary -classpath /localhome/ykantser/openjdk/jtreg/jtreg_4.1-20140318/lib/javatest.jar:/localhome/ykantser/openjdk/jtreg/jtreg_4.1-20140318/lib/jtreg.jar:/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm:/tmp/jtreg/jtreg-workdir/classes/lib/testlibrary:/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/lib/tools.jar -sourcepath /localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm:/localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary -XDignore.symbol.file=true /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/FileUtils.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/IOUtils.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/JDKToolFinder.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/Asserts.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/ProcessThread.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/InputArguments.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/XRun.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/Sleeper.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/StreamPumper.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/JcmdBase.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/OutputBuffer.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/JDKToolLauncher.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/Utils.java /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/TestThread.java ----------System.out:(0/0)---------- ----------System.err:(2/182)---------- Note: /localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary/jdk/testlibrary/StreamPumper.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. result: Passed. Compilation successful #section:build ----------messages:(3/108)---------- command: build MonitorVmStartTerminate reason: Named class compiled on demand elapsed time (seconds): 0.654 result: Passed. Build successful #section:compile ----------messages:(3/223)---------- command: compile -XDignore.symbol.file=true /localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java reason: .class file out of date or does not exist elapsed time (seconds): 0.632 ----------rerun:(18/1822)*---------- DISPLAY=:0 \\ GNOME_DESKTOP_SESSION_ID=this-is-deprecated \\ HOME=/home/ykantser \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ /localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/javac \\ -J-Dtest.vm.opts= \\ -J-Dtest.jdk=/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image \\ -J-Dtest.timeout.factor=1.0 \\ -J-Dtest.src.path=/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm:/localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary \\ -J-Dtest.compiler.opts= \\ -J-Dcompile.jdk=/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image \\ -J-Dtest.classes=/tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm \\ -J-Dtest.class.path=/tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm:/tmp/jtreg/jtreg-workdir/classes/lib/testlibrary \\ -J-Dtest.java.opts= \\ -J-Dtest.src=/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm \\ -J-Dtest.tool.vm.opts= \\ -d /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm -classpath /localhome/ykantser/openjdk/jtreg/jtreg_4.1-20140318/lib/javatest.jar:/localhome/ykantser/openjdk/jtreg/jtreg_4.1-20140318/lib/jtreg.jar:/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm:/tmp/jtreg/jtreg-workdir/classes/lib/testlibrary:/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/lib/tools.jar -sourcepath /localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm:/localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary -XDignore.symbol.file=true /localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java ----------System.out:(0/0)---------- ----------System.err:(0/0)---------- result: Passed. Compilation successful #section:main ----------messages:(3/133)---------- command: main MonitorVmStartTerminate reason: User specified action: run main MonitorVmStartTerminate elapsed time (seconds): 1.364 ----------System.out:(53/4547)---------- started=0, terminated=0 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_0 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_1 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_2 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_3 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_4 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_5 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_6 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_7 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_8 Starting 1d7b0d07-d2df-4a71-9600-555d2608c496_9 Waiting for all processes to get started notification Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_2 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_1 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_0 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_8 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_4 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_7 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_3 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_6 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_9 ] Command line: [/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm MonitorVmStartTerminate$JavaProcess 1d7b0d07-d2df-4a71-9600-555d2608c496_5 ] started=0, terminated=0 started=10, terminated=0 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_0 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_1 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_2 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_3 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_4 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_5 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_6 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_7 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_8 Terminating 1d7b0d07-d2df-4a71-9600-555d2608c496_9 Waiting for all processes to get terminated notification Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_2 stder: started=0, terminated=1 Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_1 stder: Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_5 stder: started=0, terminated=3 Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_6 stder: started=0, terminated=4 Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_4 stder: started=0, terminated=5 Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_7 stder: started=0, terminated=6 Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_3 stder: Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_9 stder: started=0, terminated=8 Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_8 stder: started=0, terminated=9 Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_0 stder: started=0, terminated=10 ----------System.err:(11/1305)---------- Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_2 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_2 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_1 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_1 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_5 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_5 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_6 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_6 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_4 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_4 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_7 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_7 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_3 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_3 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_9 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_9 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_8 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_8 to be removed, 0 s Java Process 1d7b0d07-d2df-4a71-9600-555d2608c496_0 stdout:Waiting for 1d7b0d07-d2df-4a71-9600-555d2608c496_0 to be removed, 0 s STATUS:Passed. ----------rerun:(19/1666)*---------- DISPLAY=:0 \\ GNOME_DESKTOP_SESSION_ID=this-is-deprecated \\ HOME=/home/ykantser \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ CLASSPATH=/localhome/ykantser/openjdk/jtreg/jtreg_4.1-20140318/lib/javatest.jar:/localhome/ykantser/openjdk/jtreg/jtreg_4.1-20140318/lib/jtreg.jar:/tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm:/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm:/tmp/jtreg/jtreg-workdir/classes/lib/testlibrary:/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/lib/tools.jar \\ /localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java \\ -Dtest.vm.opts= \\ -Dtest.jdk=/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image \\ -Dtest.timeout.factor=1.0 \\ -Dtest.src.path=/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm:/localhome/ykantser/jdk9/dev/jdk/test/lib/testlibrary \\ -Dtest.compiler.opts= \\ -Dcompile.jdk=/localhome/ykantser/jdk9/dev/build/linux-x86_64-normal-server-release/images/j2sdk-image \\ -Dtest.classes=/tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm \\ -Dtest.class.path=/tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm:/tmp/jtreg/jtreg-workdir/classes/lib/testlibrary \\ -Dtest.java.opts= \\ -Dtest.src=/localhome/ykantser/jdk9/dev/jdk/test/sun/jvmstat/monitor/MonitoredVm \\ -Dtest.tool.vm.opts= \\ com.sun.javatest.regtest.MainWrapper /tmp/jtreg/jtreg-workdir/classes/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.jta result: Passed. Execution successful test result: Passed. Execution successful From staffan.larsen at oracle.com Fri Jun 13 11:03:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Jun 2014 13:03:50 +0200 Subject: RFR: 8046778 Better error messages when starting JMX agent via attach or jcmd Message-ID: <07BCF5C0-59D1-4903-8535-B80F99F54A88@oracle.com> When starting the JMX agent via jcmd, the error messages you get are very cryptic: $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start 9979: java.lang.RuntimeException: Invalid option specified $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start config.file=apa 10024: java.lang.RuntimeException: Config file not found $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start jmxremote.port=5000 9979: sun.management.AgentConfigurationError This is just because errors are note propagated correctly to the jcmd. With some small changes the above can look like this: $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start 89673: java.lang.RuntimeException: Invalid com.sun.management.jmxremote.port number: No port specified $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start config.file=apa 89673: java.lang.RuntimeException: Config file not found: apa $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start jmxremote.port=5000 89673: java.lang.RuntimeException: Password file not found: /Users/staffan/mercurial/jdk9-hs-rt/build/macosx-x86_64-normal-server-release/jdk/lib/management/jmxremote.password webrev: http://cr.openjdk.java.net/~sla/8046778/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8046778 Thanks, /Staffan From dmitry.samersoff at oracle.com Fri Jun 13 11:12:30 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 13 Jun 2014 15:12:30 +0400 Subject: NEED REVIEWER RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: References: <5342A069.3000205@oracle.com> <537B5D0B.9000207@oracle.com> <53901755.7050404@oracle.com> <539977EE.70106@oracle.com> <53997C79.1000500@oracle.com> <539985CE.1000408@oracle.com> <53998D99.2060505@oracle.com> <539AB2CD.2040809@oracle.com> <539AD6D1.20609@oracle.com> Message-ID: <539ADC9E.1090902@oracle.com> Thanks! On 2014-06-13 14:58, Staffan Larsen wrote: > Looks good! > > One small nit: rectifing -> rectifying > > Thanks, > /Staffan > > On 13 jun 2014, at 12:47, Dmitry Samersoff wrote: > >> Serguei, >> >> Thank you for the review. >> >> Updated webrev is here: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.03/ >> >> -Dmitry >> >> On 2014-06-13 12:14, serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> Thank you for the explanations! >>> The fix looks good pending the simplification below. >>> I'm Ok with your testing approach. >>> >>> Thanks, >>> Serguei >>> >>> On 6/12/14 4:23 AM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> Thank you for the review, please see below. >>>> >>>> On 2014-06-12 14:49, serguei.spitsyn at oracle.com wrote: >>>>> Dmitry, >>>>> >>>>> Thank you for the details! >>>>> >>>>> I have a couple of comments so far. >>>>> >>>>> + if (word[5][0] == '[') { >>>>> + // not a shared library entry. ignore. >>>>> + if (strncmp(word[5],"[stack",6) == 0) { >>>>> + continue; >>>>> + } >>>>> + if (strncmp(word[5],"[heap]",6) == 0) { >>>>> + continue; >>>>> + } >>>>> + >>>>> + // SA don't handle VDSO >>>>> + if (strncmp(word[5],"[vdso]",6) == 0) { >>>>> + continue; >>>>> + } >>>>> + if (strncmp(word[5],"[vsyscall]",6) == 0) { >>>>> + continue; >>>>> + } >>>>> + } >>>>> >>>>> I'd suggest to simplify the fragment above to something like thus: >>>>> >>>>> + // SA does not handle the lines with patterns: >>>>> + // "[stack]", "[heap]", "[vdso]", "[vsyscall]", etc. >>>>> + if (word[5][0] == '[') { >>>>> + continue; // not a shared library entry, ignore >>>>> + } >>>> I'll change it. >>>> >>>>> This fragment does not look correct: >>>>> >>>>> + if (nwords > 6) { >>>>> + // prelink altered mapfile when the program is running. >>>>> + // Entries like one below have to be skipped >>>>> + // /lib64/libc-2.15.so (deleted) >>>>> + // SO name in entries like one below have to be stripped. >>>>> + // /lib64/libpthread-2.15.so.#prelink#.EECVts >>>>> + char *s = strstr(word[5],".#prelink#"); >>>>> + if (s == NULL) { >>>>> + // No prelink keyword. skip deleted library >>>>> + print_debug("skip shared object %s deleted by prelink\n", >>>>> word[5]); >>>>> + continue; >>>>> + } >>>>> + >>>>> + // Fall through >>>>> + print_debug("rectifing shared object name %s changed by >>>>> prelink\n", word[5]); >>>>> + *s = 0; >>>>> + } >>>> >>>> We always have word "(deleted)" at the end (see fragment of map >>>> below). >>>> >>>> But if the word "(deleted)" relates to original DSO we should skip the >>>> entry but if it relates to tmp file created by prelink we should accept >>>> this mapping - it's a new place for original library. >>>> >>>> >>>> Actually map entry looks like: >>>> >>>> 7f490b190000-7f490b1a8000 r-xp 00000000 08:01 350 >>>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>>> >>>> 7f490b1a8000-7f490b3a7000 ---p 00018000 08:01 350 >>>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>>> >>>> 7f490b3a7000-7f490b3a8000 r--p 00017000 08:01 350 >>>> /lib64/libpthread-2.15.so.#prelink#.EECVts (deleted) >>>> >>>> 7f490b3a8000-7f490b3a9000 rw-p 00018000 08:01 >>>> 350 /lib64/libpthread-2.15.so.#prelink#.EECVts >>>> (deleted) >>>> >>>> 7f490b3a9000-7f490b3ad000 rw-p 00000000 00:00 0 >>>> 7f490b3ad000-7f490b3cf000 r-xp 00000000 08:01 >>>> >>>> 48013 /lib64/ld-2.15.so (deleted) >>>> >>>> >>>>> The line with the pattern "(deleted)" has 7 words, but the line like: >>>>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>>>> >>>>> has only 6 words, and so, your code will not process it properly. >>>>> >>>>> I'd expect something like this: >>>>> >>>>> + if (nwords > 6) { >>>>> + // prelink altered mapfile when the program is running. >>>>> + // Entries like one below have to be skipped: >>>>> + // /lib64/libc-2.15.so (deleted) >>>>> + print_debug("skip shared object %s deleted by prelink\n", >>>>> word[5]); >>>>> + continue; >>>>> + } else { >>>>> + char *s = strstr(word[5],".#prelink#"); >>>>> + if (s != NULL) { >>>>> + // There is the prelink keyword >>>>> + print_debug("rectifying shared object name %s changed by >>>>> prelink\n", word[5]); >>>>> + *s = 0; >>>>> + } >>>>> + } >>>>> >>>>> >>>>> Is it hard to add a unit test for this issue? >>>> It's not possible to test prelink during nightly as it affects entire OS >>>> (actually it's a bad idea to run prelink while java program is running). >>>> >>>> >>>> -Dmitry >>>> >>>> >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 6/12/14 3:10 AM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> *The problem:* >>>>>> >>>>>> If someone run prelink utility while Java program is running DSO's >>>>>> mappings in it's /proc//maps become messy. >>>>>> >>>>>> After prelink it contains entry like >>>>>> >>>>>> /lib64/libc-2.15.so (deleted) >>>>>> /lib64/libpthread-2.15.so.#prelink#.EECVts >>>>>> >>>>>> instead of normal >>>>>> >>>>>> /lib64/libc-2.15.so >>>>>> >>>>>> Here is the letter from Carlos, describing the problem in details: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8038392 >>>>>> >>>>>> *The fix:* >>>>>> >>>>>> The fix allows SA to handle situation above. >>>>>> >>>>>> Also I fix longstanding issue - maps file parser in SA doesn't skip >>>>>> [stack*, [heap] etc entry and attempts to open it as a DSO >>>>>> >>>>>> *Testing:* >>>>>> >>>>>> I tested it manually with a different of prelink options (no prelink, >>>>>> prelink all, prelink some libraries only) >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-06-12 13:50, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> There is no description of the fix. >>>>>>> Could you, please, provide one? >>>>>>> What did you basically wanted to achieve? >>>>>>> Also, how did the fix been tested? >>>>>>> It seems, a unit test would be nice to have. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 6/5/14 12:08 AM, Dmitry Samersoff wrote: >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>>>> >>>>>>>> On 2014-05-20 17:47, Dmitry Samersoff wrote: >>>>>>>>> On 2014-04-07 16:56, Dmitry Samersoff wrote: >>>>>>>>>> Hi Everybody, >>>>>>>>>> >>>>>>>>>> Please review the patch >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>>>>>>> >>>>>>>>>> it's based on the patch contributed by Carlos Santos (see CR) >>>>>>>>>> and all >>>>>>>>>> credentials belong to him. >>>>>>>>>> >>>>>>>>>> -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 yekaterina.kantserova at oracle.com Fri Jun 13 11:25:36 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 13 Jun 2014 13:25:36 +0200 Subject: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call. Message-ID: <539ADFB0.7070906@oracle.com> Hi, Could I please have a review of this fix. webrev: http://cr.openjdk.java.net/~ykantser/6545295 bug: https://bugs.openjdk.java.net/browse/JDK-6545295 The test has been re-written using the testlibrary's functionality. It's verified internally on all basic platforms. Thanks, Katja From staffan.larsen at oracle.com Fri Jun 13 11:44:49 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Jun 2014 13:44:49 +0200 Subject: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call. In-Reply-To: <539ADFB0.7070906@oracle.com> References: <539ADFB0.7070906@oracle.com> Message-ID: <61562968-A1B4-4075-828A-8B957BBFB78B@oracle.com> Katja, Great to see this simplification! A couple of comments: - I don?t think you need to launch jhat with -XX:+UsePerfData - no one is attaching or reading data from the process. - The static processBuilder field seems to be mis-used. Why not use different ProcessBuilder objects for the HelloWorld and jhat? - For dumpFile.deleteOnExit() to be useful you should add it as early as possible (line 48 perhaps?). If it is the last line in the test you can just as well do dumpFile.delete(). /S On 13 jun 2014, at 13:25, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/6545295 > bug: https://bugs.openjdk.java.net/browse/JDK-6545295 > > The test has been re-written using the testlibrary's functionality. It's verified internally on all basic platforms. > > Thanks, > Katja From staffan.larsen at oracle.com Fri Jun 13 12:09:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Jun 2014 14:09:32 +0200 Subject: RFR: 8043939 Remove management-agent.jar Message-ID: <26463974-40D4-489C-B679-5DEBA605EFE6@oracle.com> management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. JDK-8044135 added an API in the attach framework to start the JMX agent, and it is now time to remove management-agent.jar. webrev: http://cr.openjdk.java.net/~sla/8043939/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8043939 Thanks, /Staffan From yekaterina.kantserova at oracle.com Fri Jun 13 12:15:02 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 13 Jun 2014 14:15:02 +0200 Subject: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call. In-Reply-To: <61562968-A1B4-4075-828A-8B957BBFB78B@oracle.com> References: <539ADFB0.7070906@oracle.com> <61562968-A1B4-4075-828A-8B957BBFB78B@oracle.com> Message-ID: <539AEB46.6000304@oracle.com> Staffan, thanks for your review! The new webrev can be found here: http://cr.openjdk.java.net/~ykantser/6545295/webrev.01/ // Katja On 06/13/2014 01:44 PM, Staffan Larsen wrote: > Katja, > > Great to see this simplification! A couple of comments: > > - I don?t think you need to launch jhat with -XX:+UsePerfData - no one is attaching or reading data from the process. > > - The static processBuilder field seems to be mis-used. Why not use different ProcessBuilder objects for the HelloWorld and jhat? > > - For dumpFile.deleteOnExit() to be useful you should add it as early as possible (line 48 perhaps?). If it is the last line in the test you can just as well do dumpFile.delete(). Of cause it should be dumpFile.delete()! - dumpFile.deleteOnExit() has crept in by mistake. > > /S > > > On 13 jun 2014, at 13:25, Yekaterina Kantserova wrote: > >> Hi, >> >> Could I please have a review of this fix. >> >> webrev: http://cr.openjdk.java.net/~ykantser/6545295 >> bug: https://bugs.openjdk.java.net/browse/JDK-6545295 >> >> The test has been re-written using the testlibrary's functionality. It's verified internally on all basic platforms. >> >> Thanks, >> Katja From Alan.Bateman at oracle.com Fri Jun 13 12:18:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Jun 2014 13:18:38 +0100 Subject: RFR: 8043939 Remove management-agent.jar In-Reply-To: <26463974-40D4-489C-B679-5DEBA605EFE6@oracle.com> References: <26463974-40D4-489C-B679-5DEBA605EFE6@oracle.com> Message-ID: <539AEC1E.5060605@oracle.com> On 13/06/2014 13:09, Staffan Larsen wrote: > management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. > > JDK-8044135 added an API in the attach framework to start the JMX agent, and it is now time to remove management-agent.jar. > > webrev: http://cr.openjdk.java.net/~sla/8043939/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8043939 > This looks good to me, I assume the previous change to add the methods to the attach API took care of the tests that use management-agent.jar (no more to update, right?) -Alan From staffan.larsen at oracle.com Fri Jun 13 12:22:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Jun 2014 14:22:14 +0200 Subject: RFR: 8043939 Remove management-agent.jar In-Reply-To: <539AEC1E.5060605@oracle.com> References: <26463974-40D4-489C-B679-5DEBA605EFE6@oracle.com> <539AEC1E.5060605@oracle.com> Message-ID: On 13 jun 2014, at 14:18, Alan Bateman wrote: > On 13/06/2014 13:09, Staffan Larsen wrote: >> management-agent.jar is the java agent that is used with the attach API to start the JMX agent in a target VM. It's the approach used in JDK 6 to start JMX in a running VM and predates the "jcmd ManagementAgent.start" command added in 7uX. >> >> JDK-8044135 added an API in the attach framework to start the JMX agent, and it is now time to remove management-agent.jar. >> >> webrev: http://cr.openjdk.java.net/~sla/8043939/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8043939 >> > This looks good to me, I assume the previous change to add the methods to the attach API took care of the tests that use management-agent.jar (no more to update, right?) Right. I grepped for ?management-agent? in all the tests, sources and makefiles and could find no references. Thanks, /Staffan From staffan.larsen at oracle.com Fri Jun 13 12:23:15 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Jun 2014 14:23:15 +0200 Subject: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call. In-Reply-To: <539AEB46.6000304@oracle.com> References: <539ADFB0.7070906@oracle.com> <61562968-A1B4-4075-828A-8B957BBFB78B@oracle.com> <539AEB46.6000304@oracle.com> Message-ID: <63AA910B-7ABF-4527-9130-72207A70ED3F@oracle.com> Looks good! Thanks, /Staffan On 13 jun 2014, at 14:15, Yekaterina Kantserova wrote: > Staffan, thanks for your review! > > The new webrev can be found here: http://cr.openjdk.java.net/~ykantser/6545295/webrev.01/ > > // Katja > > On 06/13/2014 01:44 PM, Staffan Larsen wrote: >> Katja, >> >> Great to see this simplification! A couple of comments: >> >> - I don?t think you need to launch jhat with -XX:+UsePerfData - no one is attaching or reading data from the process. >> >> - The static processBuilder field seems to be mis-used. Why not use different ProcessBuilder objects for the HelloWorld and jhat? >> >> - For dumpFile.deleteOnExit() to be useful you should add it as early as possible (line 48 perhaps?). If it is the last line in the test you can just as well do dumpFile.delete(). > > Of cause it should be dumpFile.delete()! - dumpFile.deleteOnExit() has crept in by mistake. > >> >> /S >> >> >> On 13 jun 2014, at 13:25, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/6545295 >>> bug: https://bugs.openjdk.java.net/browse/JDK-6545295 >>> >>> The test has been re-written using the testlibrary's functionality. It's verified internally on all basic platforms. >>> >>> Thanks, >>> Katja -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Mon Jun 16 07:59:15 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 16 Jun 2014 09:59:15 +0200 Subject: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call. In-Reply-To: <63AA910B-7ABF-4527-9130-72207A70ED3F@oracle.com> References: <539ADFB0.7070906@oracle.com> <61562968-A1B4-4075-828A-8B957BBFB78B@oracle.com> <539AEB46.6000304@oracle.com> <63AA910B-7ABF-4527-9130-72207A70ED3F@oracle.com> Message-ID: <539EA3D3.6080904@oracle.com> Hi, could I get one more review please? Thanks, Katja On 06/13/2014 02:23 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 13 jun 2014, at 14:15, Yekaterina Kantserova > > wrote: > >> Staffan, thanks for your review! >> >> The new webrev can be found >> here:http://cr.openjdk.java.net/~ykantser/6545295/webrev.01/ >> >> >> // Katja >> >> On 06/13/2014 01:44 PM, Staffan Larsen wrote: >>> Katja, >>> >>> Great to see this simplification! A couple of comments: >>> >>> - I don?t think you need to launch jhat with -XX:+UsePerfData - no >>> one is attaching or reading data from the process. >>> >>> - The static processBuilder field seems to be mis-used. Why not use >>> different ProcessBuilder objects for the HelloWorld and jhat? >>> >>> - For dumpFile.deleteOnExit() to be useful you should add it as >>> early as possible (line 48 perhaps?). If it is the last line in the >>> test you can just as well do dumpFile.delete(). >> >> Of cause it should be dumpFile.delete()! - dumpFile.deleteOnExit() >> has crept in by mistake. >> >>> >>> /S >>> >>> >>> On 13 jun 2014, at 13:25, Yekaterina Kantserova >>> >> > wrote: >>> >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> webrev: http://cr.openjdk.java.net/~ykantser/6545295 >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-6545295 >>>> >>>> The test has been re-written using the testlibrary's functionality. >>>> It's verified internally on all basic platforms. >>>> >>>> Thanks, >>>> Katja > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Jun 16 08:45:24 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jun 2014 10:45:24 +0200 Subject: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call. In-Reply-To: <539EA3D3.6080904@oracle.com> References: <539ADFB0.7070906@oracle.com> <61562968-A1B4-4075-828A-8B957BBFB78B@oracle.com> <539AEB46.6000304@oracle.com> <63AA910B-7ABF-4527-9130-72207A70ED3F@oracle.com> <539EA3D3.6080904@oracle.com> Message-ID: Katja, The policy for reviews in the jdk repo is different from the hotspot repo. For the jdk it is ok with a single review. /Staffan On 16 jun 2014, at 09:59, Yekaterina Kantserova wrote: > Hi, > > could I get one more review please? > > Thanks, > Katja > > > On 06/13/2014 02:23 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >> On 13 jun 2014, at 14:15, Yekaterina Kantserova wrote: >> >>> Staffan, thanks for your review! >>> >>> The new webrev can be found here: http://cr.openjdk.java.net/~ykantser/6545295/webrev.01/ >>> >>> // Katja >>> >>> On 06/13/2014 01:44 PM, Staffan Larsen wrote: >>>> Katja, >>>> >>>> Great to see this simplification! A couple of comments: >>>> >>>> - I don?t think you need to launch jhat with -XX:+UsePerfData - no one is attaching or reading data from the process. >>>> >>>> - The static processBuilder field seems to be mis-used. Why not use different ProcessBuilder objects for the HelloWorld and jhat? >>>> >>>> - For dumpFile.deleteOnExit() to be useful you should add it as early as possible (line 48 perhaps?). If it is the last line in the test you can just as well do dumpFile.delete(). >>> >>> Of cause it should be dumpFile.delete()! - dumpFile.deleteOnExit() has crept in by mistake. >>> >>>> >>>> /S >>>> >>>> >>>> On 13 jun 2014, at 13:25, Yekaterina Kantserova wrote: >>>> >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ykantser/6545295 >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6545295 >>>>> >>>>> The test has been re-written using the testlibrary's functionality. It's verified internally on all basic platforms. >>>>> >>>>> Thanks, >>>>> Katja >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Mon Jun 16 09:05:45 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 16 Jun 2014 11:05:45 +0200 Subject: RFR(S): 6545295: TEST BUG: The test HatHeapDump1Test uses wrong path in exec call. In-Reply-To: References: <539ADFB0.7070906@oracle.com> <61562968-A1B4-4075-828A-8B957BBFB78B@oracle.com> <539AEB46.6000304@oracle.com> <63AA910B-7ABF-4527-9130-72207A70ED3F@oracle.com> <539EA3D3.6080904@oracle.com> Message-ID: <539EB369.3020009@oracle.com> Oh, great! Could you please be my sponsor? The patch is attached to this mail. // Katja On 06/16/2014 10:45 AM, Staffan Larsen wrote: > Katja, > > The policy for reviews in the jdk repo is different from the hotspot > repo. For the jdk it is ok with a single review. > > /Staffan > > > On 16 jun 2014, at 09:59, Yekaterina Kantserova > > wrote: > >> Hi, >> >> could I get one more review please? >> >> Thanks, >> Katja >> >> >> On 06/13/2014 02:23 PM, Staffan Larsen wrote: >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>> On 13 jun 2014, at 14:15, Yekaterina Kantserova >>> >> > wrote: >>> >>>> Staffan, thanks for your review! >>>> >>>> The new webrev can be found >>>> here:http://cr.openjdk.java.net/~ykantser/6545295/webrev.01/ >>>> >>>> >>>> // Katja >>>> >>>> On 06/13/2014 01:44 PM, Staffan Larsen wrote: >>>>> Katja, >>>>> >>>>> Great to see this simplification! A couple of comments: >>>>> >>>>> - I don?t think you need to launch jhat with -XX:+UsePerfData - no >>>>> one is attaching or reading data from the process. >>>>> >>>>> - The static processBuilder field seems to be mis-used. Why not >>>>> use different ProcessBuilder objects for the HelloWorld and jhat? >>>>> >>>>> - For dumpFile.deleteOnExit() to be useful you should add it as >>>>> early as possible (line 48 perhaps?). If it is the last line in >>>>> the test you can just as well do dumpFile.delete(). >>>> >>>> Of cause it should be dumpFile.delete()! - dumpFile.deleteOnExit() >>>> has crept in by mistake. >>>> >>>>> >>>>> /S >>>>> >>>>> >>>>> On 13 jun 2014, at 13:25, Yekaterina Kantserova >>>>> >>>> > wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Could I please have a review of this fix. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ykantser/6545295 >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6545295 >>>>>> >>>>>> The test has been re-written using the testlibrary's >>>>>> functionality. It's verified internally on all basic platforms. >>>>>> >>>>>> Thanks, >>>>>> Katja >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6545295.1.patch.zip Type: application/zip Size: 3871 bytes Desc: not available URL: From poonam.bajaj at oracle.com Mon Jun 16 09:15:30 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Mon, 16 Jun 2014 14:45:30 +0530 Subject: RFR JDK-8046282: SA update In-Reply-To: <53995D02.6060406@oracle.com> References: <5392D8E5.6000105@oracle.com> <53954159.1070009@oracle.com> <53957A1A.7090207@oracle.com> <53957DE1.8060006@oracle.com> <53995D02.6060406@oracle.com> Message-ID: <539EB5B2.3020603@oracle.com> Hi Sundar, I have updated the enum classes. The updated webrev is available here: http://cr.openjdk.java.net/~poonam/8046282/webrev.01/ Please review the changes and let me know your feedback. Thanks, Poonam On 6/12/2014 1:25 PM, Poonam Bajaj wrote: > Hi Sundar, > > Is it okay with you if I keep the enum and class definitions as they > are now? And can I add you as the reviewer for these changes? > > Thanks, > Poonam > > On 6/9/2014 2:56 PM, A. Sundararajan wrote: >> Since SA is java code, we could have it cleaner.. >> >> my 2 cents, >> -Sundar >> >> On Monday 09 June 2014 02:40 PM, Poonam Bajaj wrote: >>> Hi Sundar, >>> >>> Yes, it is possible to do that. e.g. G1YCType can be defined like >>> this. >>> >>> public enum G1YCType { >>> Normal ("Normal"), >>> InitialMark ("Initial Mark"), >>> DuringMark ("During Mark"), >>> Mixed ("Mixed"), >>> G1YCTypeEndSentinel ("Unknown") >>> >>> private final String value; >>> >>> G1YCType(String val) { >>> this.value = val; >>> } >>> public String value() { >>> return value; >>> } >>> } >>> >>> But, my purpose of having a class and an enum being used in that >>> class was to have the similar kind of code structure on the SA side >>> as is present on the hotspot side. e.g the above is defined as the >>> following on the hotspot side: >>> >>> 030 enum G1YCType { >>> 031 Normal, >>> 032 InitialMark, >>> 033 DuringMark, >>> 034 Mixed, >>> 035 G1YCTypeEndSentinel >>> 036 }; >>> 037 >>> 038 class G1YCTypeHelper { >>> 039 public: >>> 040 static const char* to_string(G1YCType type) { >>> 041 switch(type) { >>> 042 case Normal: return "Normal"; >>> 043 case InitialMark: return "Initial Mark"; >>> 044 case DuringMark: return "During Mark"; >>> 045 case Mixed: return "Mixed"; >>> 046 default: ShouldNotReachHere(); return NULL; >>> 047 } >>> 048 } >>> 049 }; >>> >>> And I have tried to replicate the same on the SA side so that one >>> can easily understand and map the definitions on both the sides. >>> >>> 27 public class G1YCTypeHelper { >>> 28 >>> 29 public enum G1YCType { >>> 30 Normal, >>> 31 InitialMark, >>> 32 DuringMark, >>> 33 Mixed, >>> 34 G1YCTypeEndSentinel >>> 35 } >>> 36 >>> 37 public static String toString(G1YCType type) { >>> 38 switch (type) { >>> 39 case Normal: >>> 40 return "Normal"; >>> 41 case InitialMark: >>> 42 return "Initial Mark"; >>> 43 case DuringMark: >>> 44 return "During Mark"; >>> 45 case Mixed: >>> 46 return "Mixed"; >>> 47 default: >>> 48 return null; >>> 49 } >>> 50 } >>> 51 } >>> >>> >>> Please let me know if this is still a concern for you. >>> >>> Thanks, >>> Poonam >>> >>> On 6/9/2014 10:38 AM, A. Sundararajan wrote: >>>> The pattern of enum within a class and toString helper to return >>>> string description of it -- is used for many cases. >>>> >>>> Why not use enums with String accepting constructor and toString >>>> (or new method called "toDescription()) override? You could have >>>> add "Unknown" in these enums to map to an option that is available >>>> in VM -- but not in SA. >>>> >>>> Since it is a debugger it is expected to work with incomplete >>>> info.. so whereever you map a VM data structure element to java >>>> enum, you can map unknown enum constants to "Unknown" on Java >>>> side. Of course, if there is a sentinel element defined in VM >>>> side, you could use that itself - no need for "Unknown" in such cases. >>>> >>>> It'd nice to simplify that class-within-enum pattern... >>>> >>>> -Sundar >>>> >>>> On Saturday 07 June 2014 02:48 PM, Poonam Bajaj wrote: >>>>> Hi, >>>>> >>>>> Please review these changes for the bug 8046282 for JDK 9. These >>>>> changes add some definitions on the SA side and the supporting >>>>> code on the hotspot side. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 >>>>> >>>>> Thanks, >>>>> Poonam >>>>> >>>> >> From sundararajan.athijegannathan at oracle.com Mon Jun 16 10:24:04 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 16 Jun 2014 15:54:04 +0530 Subject: RFR JDK-8046282: SA update In-Reply-To: <539EB5B2.3020603@oracle.com> References: <5392D8E5.6000105@oracle.com> <53954159.1070009@oracle.com> <53957A1A.7090207@oracle.com> <53957DE1.8060006@oracle.com> <53995D02.6060406@oracle.com> <539EB5B2.3020603@oracle.com> Message-ID: <539EC5C4.8050607@oracle.com> Hi Poonam, Looks good to me. -Sundar On Monday 16 June 2014 02:45 PM, Poonam Bajaj wrote: > Hi Sundar, > > I have updated the enum classes. The updated webrev is available here: > http://cr.openjdk.java.net/~poonam/8046282/webrev.01/ > > Please review the changes and let me know your feedback. > > Thanks, > Poonam > > > On 6/12/2014 1:25 PM, Poonam Bajaj wrote: >> Hi Sundar, >> >> Is it okay with you if I keep the enum and class definitions as they >> are now? And can I add you as the reviewer for these changes? >> >> Thanks, >> Poonam >> >> On 6/9/2014 2:56 PM, A. Sundararajan wrote: >>> Since SA is java code, we could have it cleaner.. >>> >>> my 2 cents, >>> -Sundar >>> >>> On Monday 09 June 2014 02:40 PM, Poonam Bajaj wrote: >>>> Hi Sundar, >>>> >>>> Yes, it is possible to do that. e.g. G1YCType can be defined like >>>> this. >>>> >>>> public enum G1YCType { >>>> Normal ("Normal"), >>>> InitialMark ("Initial Mark"), >>>> DuringMark ("During Mark"), >>>> Mixed ("Mixed"), >>>> G1YCTypeEndSentinel ("Unknown") >>>> >>>> private final String value; >>>> >>>> G1YCType(String val) { >>>> this.value = val; >>>> } >>>> public String value() { >>>> return value; >>>> } >>>> } >>>> >>>> But, my purpose of having a class and an enum being used in that >>>> class was to have the similar kind of code structure on the SA side >>>> as is present on the hotspot side. e.g the above is defined as the >>>> following on the hotspot side: >>>> >>>> 030 enum G1YCType { >>>> 031 Normal, >>>> 032 InitialMark, >>>> 033 DuringMark, >>>> 034 Mixed, >>>> 035 G1YCTypeEndSentinel >>>> 036 }; >>>> 037 >>>> 038 class G1YCTypeHelper { >>>> 039 public: >>>> 040 static const char* to_string(G1YCType type) { >>>> 041 switch(type) { >>>> 042 case Normal: return "Normal"; >>>> 043 case InitialMark: return "Initial Mark"; >>>> 044 case DuringMark: return "During Mark"; >>>> 045 case Mixed: return "Mixed"; >>>> 046 default: ShouldNotReachHere(); return NULL; >>>> 047 } >>>> 048 } >>>> 049 }; >>>> >>>> And I have tried to replicate the same on the SA side so that one >>>> can easily understand and map the definitions on both the sides. >>>> >>>> 27 public class G1YCTypeHelper { >>>> 28 >>>> 29 public enum G1YCType { >>>> 30 Normal, >>>> 31 InitialMark, >>>> 32 DuringMark, >>>> 33 Mixed, >>>> 34 G1YCTypeEndSentinel >>>> 35 } >>>> 36 >>>> 37 public static String toString(G1YCType type) { >>>> 38 switch (type) { >>>> 39 case Normal: >>>> 40 return "Normal"; >>>> 41 case InitialMark: >>>> 42 return "Initial Mark"; >>>> 43 case DuringMark: >>>> 44 return "During Mark"; >>>> 45 case Mixed: >>>> 46 return "Mixed"; >>>> 47 default: >>>> 48 return null; >>>> 49 } >>>> 50 } >>>> 51 } >>>> >>>> >>>> Please let me know if this is still a concern for you. >>>> >>>> Thanks, >>>> Poonam >>>> >>>> On 6/9/2014 10:38 AM, A. Sundararajan wrote: >>>>> The pattern of enum within a class and toString helper to return >>>>> string description of it -- is used for many cases. >>>>> >>>>> Why not use enums with String accepting constructor and toString >>>>> (or new method called "toDescription()) override? You could have >>>>> add "Unknown" in these enums to map to an option that is available >>>>> in VM -- but not in SA. >>>>> >>>>> Since it is a debugger it is expected to work with incomplete >>>>> info.. so whereever you map a VM data structure element to java >>>>> enum, you can map unknown enum constants to "Unknown" on Java >>>>> side. Of course, if there is a sentinel element defined in VM >>>>> side, you could use that itself - no need for "Unknown" in such >>>>> cases. >>>>> >>>>> It'd nice to simplify that class-within-enum pattern... >>>>> >>>>> -Sundar >>>>> >>>>> On Saturday 07 June 2014 02:48 PM, Poonam Bajaj wrote: >>>>>> Hi, >>>>>> >>>>>> Please review these changes for the bug 8046282 for JDK 9. These >>>>>> changes add some definitions on the SA side and the supporting >>>>>> code on the hotspot side. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 >>>>>> >>>>>> Thanks, >>>>>> Poonam >>>>>> >>>>> >>> From poonam.bajaj at oracle.com Mon Jun 16 10:24:09 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Mon, 16 Jun 2014 15:54:09 +0530 Subject: RFR JDK-8046282: SA update In-Reply-To: <539EC5C4.8050607@oracle.com> References: <5392D8E5.6000105@oracle.com> <53954159.1070009@oracle.com> <53957A1A.7090207@oracle.com> <53957DE1.8060006@oracle.com> <53995D02.6060406@oracle.com> <539EB5B2.3020603@oracle.com> <539EC5C4.8050607@oracle.com> Message-ID: <539EC5C9.2020301@oracle.com> Thanks for the review, Sundar. regards, Poonam On 6/16/2014 3:54 PM, A. Sundararajan wrote: > Hi Poonam, > > Looks good to me. > > -Sundar > > On Monday 16 June 2014 02:45 PM, Poonam Bajaj wrote: >> Hi Sundar, >> >> I have updated the enum classes. The updated webrev is available here: >> http://cr.openjdk.java.net/~poonam/8046282/webrev.01/ >> >> Please review the changes and let me know your feedback. >> >> Thanks, >> Poonam >> >> >> On 6/12/2014 1:25 PM, Poonam Bajaj wrote: >>> Hi Sundar, >>> >>> Is it okay with you if I keep the enum and class definitions as they >>> are now? And can I add you as the reviewer for these changes? >>> >>> Thanks, >>> Poonam >>> >>> On 6/9/2014 2:56 PM, A. Sundararajan wrote: >>>> Since SA is java code, we could have it cleaner.. >>>> >>>> my 2 cents, >>>> -Sundar >>>> >>>> On Monday 09 June 2014 02:40 PM, Poonam Bajaj wrote: >>>>> Hi Sundar, >>>>> >>>>> Yes, it is possible to do that. e.g. G1YCType can be defined like >>>>> this. >>>>> >>>>> public enum G1YCType { >>>>> Normal ("Normal"), >>>>> InitialMark ("Initial Mark"), >>>>> DuringMark ("During Mark"), >>>>> Mixed ("Mixed"), >>>>> G1YCTypeEndSentinel ("Unknown") >>>>> >>>>> private final String value; >>>>> >>>>> G1YCType(String val) { >>>>> this.value = val; >>>>> } >>>>> public String value() { >>>>> return value; >>>>> } >>>>> } >>>>> >>>>> But, my purpose of having a class and an enum being used in that >>>>> class was to have the similar kind of code structure on the SA >>>>> side as is present on the hotspot side. e.g the above is defined >>>>> as the following on the hotspot side: >>>>> >>>>> 030 enum G1YCType { >>>>> 031 Normal, >>>>> 032 InitialMark, >>>>> 033 DuringMark, >>>>> 034 Mixed, >>>>> 035 G1YCTypeEndSentinel >>>>> 036 }; >>>>> 037 >>>>> 038 class G1YCTypeHelper { >>>>> 039 public: >>>>> 040 static const char* to_string(G1YCType type) { >>>>> 041 switch(type) { >>>>> 042 case Normal: return "Normal"; >>>>> 043 case InitialMark: return "Initial Mark"; >>>>> 044 case DuringMark: return "During Mark"; >>>>> 045 case Mixed: return "Mixed"; >>>>> 046 default: ShouldNotReachHere(); return NULL; >>>>> 047 } >>>>> 048 } >>>>> 049 }; >>>>> >>>>> And I have tried to replicate the same on the SA side so that one >>>>> can easily understand and map the definitions on both the sides. >>>>> >>>>> 27 public class G1YCTypeHelper { >>>>> 28 >>>>> 29 public enum G1YCType { >>>>> 30 Normal, >>>>> 31 InitialMark, >>>>> 32 DuringMark, >>>>> 33 Mixed, >>>>> 34 G1YCTypeEndSentinel >>>>> 35 } >>>>> 36 >>>>> 37 public static String toString(G1YCType type) { >>>>> 38 switch (type) { >>>>> 39 case Normal: >>>>> 40 return "Normal"; >>>>> 41 case InitialMark: >>>>> 42 return "Initial Mark"; >>>>> 43 case DuringMark: >>>>> 44 return "During Mark"; >>>>> 45 case Mixed: >>>>> 46 return "Mixed"; >>>>> 47 default: >>>>> 48 return null; >>>>> 49 } >>>>> 50 } >>>>> 51 } >>>>> >>>>> >>>>> Please let me know if this is still a concern for you. >>>>> >>>>> Thanks, >>>>> Poonam >>>>> >>>>> On 6/9/2014 10:38 AM, A. Sundararajan wrote: >>>>>> The pattern of enum within a class and toString helper to return >>>>>> string description of it -- is used for many cases. >>>>>> >>>>>> Why not use enums with String accepting constructor and toString >>>>>> (or new method called "toDescription()) override? You could have >>>>>> add "Unknown" in these enums to map to an option that is >>>>>> available in VM -- but not in SA. >>>>>> >>>>>> Since it is a debugger it is expected to work with incomplete >>>>>> info.. so whereever you map a VM data structure element to java >>>>>> enum, you can map unknown enum constants to "Unknown" on Java >>>>>> side. Of course, if there is a sentinel element defined in VM >>>>>> side, you could use that itself - no need for "Unknown" in such >>>>>> cases. >>>>>> >>>>>> It'd nice to simplify that class-within-enum pattern... >>>>>> >>>>>> -Sundar >>>>>> >>>>>> On Saturday 07 June 2014 02:48 PM, Poonam Bajaj wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review these changes for the bug 8046282 for JDK 9. These >>>>>>> changes add some definitions on the SA side and the supporting >>>>>>> code on the hotspot side. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046282 >>>>>>> >>>>>>> Thanks, >>>>>>> Poonam >>>>>>> >>>>>> >>>> > From erik.gahlin at oracle.com Mon Jun 16 10:32:04 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 16 Jun 2014 12:32:04 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <539AD9AE.2050309@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> Message-ID: <539EC7A4.10006@oracle.com> Yekaterina Kantserova skrev 13/06/14 12:59: > Erik, > > is there some reason why we need to keep MonitorVmStartTerminate.sh? > I've moved the JTreg header to MonitorVmStartTerminate.java Hi Katja, That's how I did the test initially, and it works locally, but I could never get it to work in JPRT without the shell script. I believe the tools.jar is not on the class path. Erik > > /* > * @test > * @bug 4990825 > * @summary attach to external but local JVM processes > * @library /lib/testlibrary > * @build jdk.testlibrary.* > * @run main MonitorVmStartTerminate > */ > > and the test works just fine. > > The JTreg run contains all pathes and system properties > MonitorVmStartTerminate.sh tries to construct: > ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} > -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate > > See the log attached. > > Note *@build jdk.testlibrary.** instead of *@build > jdk.testlibrary.ProcessTools* to make sure all testlibrary classes are > compiled > to the right place when running tests concurrently. > > Thanks, > Katja (Not a Reviewer) > > > > On 06/12/2014 12:37 AM, Erik Gahlin wrote: >> Hi, >> >> Could I have a review of a test that has been failing >> intermittently. The test now uses files for synchronization >> instead of waiting for a process that sleeps. >> >> Webrev: >> http://cr.openjdk.java.net/~egahlin/8028474/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8028474 >> >> Description: >> >> The test starts ten Java processes, each with a unique id. >> >> Each process creates a file named after the id and then it waits for >> the test to remove the file, at which the Java process exits. >> >> The processes are monitored by the test to make sure notifications >> are sent when processes are started/terminated. >> >> To avoid Java processes being left behind, in case of an unexpected >> failure, shutdown hooks are registered that remove files when the test >> exits. If files are not removed, i.e. due to a JVM crash, >> the Java processes will exit themselves after 1000 s. >> >> Thanks >> Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Mon Jun 16 10:47:46 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 16 Jun 2014 12:47:46 +0200 Subject: Fwd: system profilers and incomplete stacks References: Message-ID: Forwarding to serviceability alias where this question belongs I think. Begin forwarded message: > From: Brendan Gregg > Subject: system profilers and incomplete stacks > Date: June 12, 2014 at 7:15:54 PM GMT+2 > To: hotspot-compiler-dev at openjdk.java.net > > G'Day, > > Is there a way to run hotspot so that a system profiler (eg, DTrace, or Linux perf_events) can measure complete stacks? I often get incomplete, partial stacks, with one or a few frames only. I'm not worried about symbols right now, what I'd like is to walk stacks all the way down to thread start. > > I've been browsing the hotspot code, but haven't found out how yet. I suspect it's related to Java optimized frames, and has ditched the frame pointer. I was looking for an equivalent -fno-omit-frame-pointer option. > > Here's an example: > > # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, 8000)] = count(); }' > [...] > org/mozilla/javascript/ > ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* > 0x884acce8200002da > 1 > > sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* > 0xffffffff20007f4b > 1 > > org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* > 0xa20000041 > 1 > [...] > > I see similar incomplete stacks with Linux perf_events. Oracle JDKs from 6 to 8, and OpenJDK. > > thanks, > > Brendan > -- > http://www.brendangregg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Jun 16 11:04:58 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jun 2014 13:04:58 +0200 Subject: system profilers and incomplete stacks In-Reply-To: References: Message-ID: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> I think this is the bug you are looking at: https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to someone else to confirm. /Staffan On 16 jun 2014, at 12:47, Roland Westrelin wrote: > Forwarding to serviceability alias where this question belongs I think. > > Begin forwarded message: > >> From: Brendan Gregg >> Subject: system profilers and incomplete stacks >> Date: June 12, 2014 at 7:15:54 PM GMT+2 >> To: hotspot-compiler-dev at openjdk.java.net >> >> G'Day, >> >> Is there a way to run hotspot so that a system profiler (eg, DTrace, or Linux perf_events) can measure complete stacks? I often get incomplete, partial stacks, with one or a few frames only. I'm not worried about symbols right now, what I'd like is to walk stacks all the way down to thread start. >> >> I've been browsing the hotspot code, but haven't found out how yet. I suspect it's related to Java optimized frames, and has ditched the frame pointer. I was looking for an equivalent -fno-omit-frame-pointer option. >> >> Here's an example: >> >> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, 8000)] = count(); }' >> [...] >> org/mozilla/javascript/ >> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >> 0x884acce8200002da >> 1 >> >> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >> 0xffffffff20007f4b >> 1 >> >> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >> 0xa20000041 >> 1 >> [...] >> >> I see similar incomplete stacks with Linux perf_events. Oracle JDKs from 6 to 8, and OpenJDK. >> >> thanks, >> >> Brendan >> -- >> http://www.brendangregg.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Jun 16 11:49:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jun 2014 13:49:53 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <539EC7A4.10006@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> Message-ID: <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> On 16 jun 2014, at 12:32, Erik Gahlin wrote: > Yekaterina Kantserova skrev 13/06/14 12:59: >> Erik, >> >> is there some reason why we need to keep MonitorVmStartTerminate.sh? I've moved the JTreg header to MonitorVmStartTerminate.java > Hi Katja, > > That's how I did the test initially, and it works locally, but I could never get it to work in JPRT without the shell script. I believe the tools.jar is not on the class path. That is weird. I see other tests that depend in tools.jar and they work fine. /Staffan > > Erik >> >> /* >> * @test >> * @bug 4990825 >> * @summary attach to external but local JVM processes >> * @library /lib/testlibrary >> * @build jdk.testlibrary.* >> * @run main MonitorVmStartTerminate >> */ >> >> and the test works just fine. >> >> The JTreg run contains all pathes and system properties MonitorVmStartTerminate.sh tries to construct: >> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >> >> See the log attached. >> >> Note @build jdk.testlibrary.* instead of @build jdk.testlibrary.ProcessTools to make sure all testlibrary classes are compiled >> to the right place when running tests concurrently. >> >> Thanks, >> Katja (Not a Reviewer) >> >> >> >> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>> Hi, >>> >>> Could I have a review of a test that has been failing >>> intermittently. The test now uses files for synchronization >>> instead of waiting for a process that sleeps. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~egahlin/8028474/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>> >>> Description: >>> >>> The test starts ten Java processes, each with a unique id. >>> >>> Each process creates a file named after the id and then it waits for >>> the test to remove the file, at which the Java process exits. >>> >>> The processes are monitored by the test to make sure notifications >>> are sent when processes are started/terminated. >>> >>> To avoid Java processes being left behind, in case of an unexpected >>> failure, shutdown hooks are registered that remove files when the test >>> exits. If files are not removed, i.e. due to a JVM crash, >>> the Java processes will exit themselves after 1000 s. >>> >>> Thanks >>> Erik >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Jun 16 11:59:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jun 2014 13:59:42 +0200 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> Message-ID: I would appreciate a Review of this change. Thanks, /Staffan On 11 jun 2014, at 10:00, Staffan Larsen wrote: > I realized that the code in VMConnection does not take into account the test.java.opts property as it should. > > updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ (only VMConnection changed) > > Thanks, > /Staffan > > On 10 jun 2014, at 13:59, Staffan Larsen wrote: > >> >> On 10 jun 2014, at 11:44, serguei.spitsyn at oracle.com wrote: >> >>> Staffan, >>> >>> It looks good, just one comment. >>> >>> test/com/sun/jdi/VMConnection.java >>> 61 String vmOpts = System.getProperty("test.vm.opts"); >>> 62 if (vmOpts != null) { >>> 63 retVal += System.getProperty("test.vm.opts"); >>> I wonder why not this: >>> 63 retVal += vmOpts; >> Uh. Yeah, I wonder that, too. Fixed. :-) >> >> Thanks, >> /Staffan >> >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>>> >>>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>>> >>>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-6622468 >>>> >>>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>>> >>>> I have run this through JPRT with no failures. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> [0] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jun 16 12:22:59 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Jun 2014 22:22:59 +1000 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> Message-ID: <539EE1A3.70607@oracle.com> Looks okay to me. Thanks, David On 16/06/2014 9:59 PM, Staffan Larsen wrote: > I would appreciate a Review of this change. > > Thanks, > /Staffan > > On 11 jun 2014, at 10:00, Staffan Larsen > wrote: > >> I realized that the code in VMConnection does not take into account >> the test.java.opts property as it should. >> >> updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ >> (only VMConnection changed) >> >> Thanks, >> /Staffan >> >> On 10 jun 2014, at 13:59, Staffan Larsen > > wrote: >> >>> >>> On 10 jun 2014, at 11:44,serguei.spitsyn at oracle.com >>> wrote: >>> >>>> Staffan, >>>> >>>> It looks good, just one comment. >>>> >>>> test/com/sun/jdi/VMConnection.java >>>> 61 String vmOpts = System.getProperty("test.vm.opts"); >>>> 62 if (vmOpts != null) { >>>> 63 retVal += System.getProperty("test.vm.opts"); >>>> I wonder why not this: >>>> 63 retVal += vmOpts; >>> Uh. Yeah, I wonder that, too. Fixed. :-) >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>>>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>>>> >>>>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>>>> >>>>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>>>> >>>>> webrev:http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>>>> bug:https://bugs.openjdk.java.net/browse/JDK-6622468 >>>>> >>>>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>>>> >>>>> I have run this through JPRT with no failures. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> [0]http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html >> > From dmitry.samersoff at oracle.com Mon Jun 16 12:24:07 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 16 Jun 2014 16:24:07 +0400 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <539EC7A4.10006@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> Message-ID: <539EE1E7.20409@oracle.com> Erik, It should work see e.g. hotspot/test/runtime/RedefineFinalizer you might need to add -Xbootclasspath/a:tools.jar to @run and -XDignore.symbol.file to @compile -Dmitry On 2014-06-16 14:32, Erik Gahlin wrote: > Yekaterina Kantserova skrev 13/06/14 12:59: >> Erik, >> >> is there some reason why we need to keep MonitorVmStartTerminate.sh? >> I've moved the JTreg header to MonitorVmStartTerminate.java > Hi Katja, > > That's how I did the test initially, and it works locally, but I could > never get it to work in JPRT without the shell script. I believe the > tools.jar is not on the class path. > > Erik >> >> /* >> * @test >> * @bug 4990825 >> * @summary attach to external but local JVM processes >> * @library /lib/testlibrary >> * @build jdk.testlibrary.* >> * @run main MonitorVmStartTerminate >> */ >> >> and the test works just fine. >> >> The JTreg run contains all pathes and system properties >> MonitorVmStartTerminate.sh tries to construct: >> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} >> -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >> >> See the log attached. >> >> Note *@build jdk.testlibrary.** instead of *@build >> jdk.testlibrary.ProcessTools* to make sure all testlibrary classes are >> compiled >> to the right place when running tests concurrently. >> >> Thanks, >> Katja (Not a Reviewer) >> >> >> >> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>> Hi, >>> >>> Could I have a review of a test that has been failing >>> intermittently. The test now uses files for synchronization >>> instead of waiting for a process that sleeps. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~egahlin/8028474/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>> >>> Description: >>> >>> The test starts ten Java processes, each with a unique id. >>> >>> Each process creates a file named after the id and then it waits for >>> the test to remove the file, at which the Java process exits. >>> >>> The processes are monitored by the test to make sure notifications >>> are sent when processes are started/terminated. >>> >>> To avoid Java processes being left behind, in case of an unexpected >>> failure, shutdown hooks are registered that remove files when the test >>> exits. If files are not removed, i.e. due to a JVM crash, >>> the Java processes will exit themselves after 1000 s. >>> >>> Thanks >>> Erik >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Jun 16 12:39:03 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 16 Jun 2014 16:39:03 +0400 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <539EC7A4.10006@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> Message-ID: <539EE567.6010604@oracle.com> Erik, It's better to check lock-file age rather than maintain in-process timeout variable, it guards the test from the situation when lock file was not removed from the previous run for some reason. see jdk/test/sun/management/jdp/JdpDoSomething.java -Dmitry On 2014-06-16 14:32, Erik Gahlin wrote: > Yekaterina Kantserova skrev 13/06/14 12:59: >> Erik, >> >> is there some reason why we need to keep MonitorVmStartTerminate.sh? >> I've moved the JTreg header to MonitorVmStartTerminate.java > Hi Katja, > > That's how I did the test initially, and it works locally, but I could > never get it to work in JPRT without the shell script. I believe the > tools.jar is not on the class path. > > Erik >> >> /* >> * @test >> * @bug 4990825 >> * @summary attach to external but local JVM processes >> * @library /lib/testlibrary >> * @build jdk.testlibrary.* >> * @run main MonitorVmStartTerminate >> */ >> >> and the test works just fine. >> >> The JTreg run contains all pathes and system properties >> MonitorVmStartTerminate.sh tries to construct: >> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} >> -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >> >> See the log attached. >> >> Note *@build jdk.testlibrary.** instead of *@build >> jdk.testlibrary.ProcessTools* to make sure all testlibrary classes are >> compiled >> to the right place when running tests concurrently. >> >> Thanks, >> Katja (Not a Reviewer) >> >> >> >> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>> Hi, >>> >>> Could I have a review of a test that has been failing >>> intermittently. The test now uses files for synchronization >>> instead of waiting for a process that sleeps. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~egahlin/8028474/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>> >>> Description: >>> >>> The test starts ten Java processes, each with a unique id. >>> >>> Each process creates a file named after the id and then it waits for >>> the test to remove the file, at which the Java process exits. >>> >>> The processes are monitored by the test to make sure notifications >>> are sent when processes are started/terminated. >>> >>> To avoid Java processes being left behind, in case of an unexpected >>> failure, shutdown hooks are registered that remove files when the test >>> exits. If files are not removed, i.e. due to a JVM crash, >>> the Java processes will exit themselves after 1000 s. >>> >>> Thanks >>> Erik >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Mon Jun 16 12:48:52 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jun 2014 14:48:52 +0200 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: <539EE1A3.70607@oracle.com> References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> <539EE1A3.70607@oracle.com> Message-ID: Thanks David! On 16 jun 2014, at 14:22, David Holmes wrote: > Looks okay to me. > > Thanks, > David > > On 16/06/2014 9:59 PM, Staffan Larsen wrote: >> I would appreciate a Review of this change. >> >> Thanks, >> /Staffan >> >> On 11 jun 2014, at 10:00, Staffan Larsen > > wrote: >> >>> I realized that the code in VMConnection does not take into account >>> the test.java.opts property as it should. >>> >>> updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ >>> (only VMConnection changed) >>> >>> Thanks, >>> /Staffan >>> >>> On 10 jun 2014, at 13:59, Staffan Larsen >> > wrote: >>> >>>> >>>> On 10 jun 2014, at 11:44,serguei.spitsyn at oracle.com >>>> wrote: >>>> >>>>> Staffan, >>>>> >>>>> It looks good, just one comment. >>>>> >>>>> test/com/sun/jdi/VMConnection.java >>>>> 61 String vmOpts = System.getProperty("test.vm.opts"); >>>>> 62 if (vmOpts != null) { >>>>> 63 retVal += System.getProperty("test.vm.opts"); >>>>> I wonder why not this: >>>>> 63 retVal += vmOpts; >>>> Uh. Yeah, I wonder that, too. Fixed. :-) >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>>>>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>>>>> >>>>>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>>>>> >>>>>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>>>>> >>>>>> webrev:http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-6622468 >>>>>> >>>>>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>>>>> >>>>>> I have run this through JPRT with no failures. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> >>>>>> [0]http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html >>> >> From daniel.daugherty at oracle.com Mon Jun 16 15:01:15 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 16 Jun 2014 09:01:15 -0600 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> Message-ID: <539F06BB.9050302@oracle.com> > updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ test/com/sun/jdi/VMConnection.java line 62: System.out.println("vmOpts: "+vmOpts); line 67: System.out.println("javaOpts: "+javaOpts); line 68: if (javaOpts != null) { Indent off by one in patch view; looks like there are tabs. test/com/sun/jdi/connect/spi/DebugUsingCustomConnector.java line 62: List launchers = vmm.launchingConnectors(); Indent off by one in patch view; looks like there is a tab. test/com/sun/jdi/sde/MangleStepTest.java old line 85: waitForInput(); Why was this line deleted? No comments on the other files. Dan On 6/16/14 5:59 AM, Staffan Larsen wrote: > I would appreciate a Review of this change. > > Thanks, > /Staffan > > On 11 jun 2014, at 10:00, Staffan Larsen > wrote: > >> I realized that the code in VMConnection does not take into account >> the test.java.opts property as it should. >> >> updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ >> (only >> VMConnection changed) >> >> Thanks, >> /Staffan >> >> On 10 jun 2014, at 13:59, Staffan Larsen > > wrote: >> >>> >>> On 10 jun 2014, at 11:44,serguei.spitsyn at oracle.com >>> wrote: >>> >>>> Staffan, >>>> >>>> It looks good, just one comment. >>>> >>>> test/com/sun/jdi/VMConnection.java >>>> 61 String vmOpts = System.getProperty("test.vm.opts"); >>>> 62 if (vmOpts != null) { >>>> 63 retVal += System.getProperty("test.vm.opts"); >>>> I wonder why not this: >>>> 63 retVal += vmOpts; >>> Uh. Yeah, I wonder that, too. Fixed. :-) >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>>>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>>>> >>>>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>>>> >>>>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>>>> >>>>> webrev:http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>>>> bug:https://bugs.openjdk.java.net/browse/JDK-6622468 >>>>> >>>>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>>>> >>>>> I have run this through JPRT with no failures. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> [0]http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Jun 16 17:39:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 16 Jun 2014 19:39:31 +0200 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: <539F06BB.9050302@oracle.com> References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> <539F06BB.9050302@oracle.com> Message-ID: <6DDA690E-2070-4325-B7A2-CAF24C181718@oracle.com> On 16 jun 2014, at 17:01, Daniel D. Daugherty wrote: > > updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ > > test/com/sun/jdi/VMConnection.java > line 62: System.out.println("vmOpts: "+vmOpts); > line 67: System.out.println("javaOpts: "+javaOpts); > line 68: if (javaOpts != null) { > Indent off by one in patch view; looks like there are tabs. > > test/com/sun/jdi/connect/spi/DebugUsingCustomConnector.java > line 62: List launchers = vmm.launchingConnectors(); > Indent off by one in patch view; looks like there is a tab. Yes, I noticed the tab problem too. Fixed. > test/com/sun/jdi/sde/MangleStepTest.java > old line 85: waitForInput(); > Why was this line deleted? The waitForInput() method waits for input on stdin. There is no process that provides that input so it?s not necessary. The reason it works before my change is that System.in.read() returns -1 (end of input) when run in ?othervm? mode. With the ?driver? change I wanted the tests to be able to run in ?agentvm? mode and there System.in.read() blocks. I haven?t delved into the details of why, but since there is no reason to wait for input here I simply removed the line. I should have mentioned this in the review request. Thanks, /Staffan > > No comments on the other files. > > Dan > > > On 6/16/14 5:59 AM, Staffan Larsen wrote: >> I would appreciate a Review of this change. >> >> Thanks, >> /Staffan >> >> On 11 jun 2014, at 10:00, Staffan Larsen wrote: >> >>> I realized that the code in VMConnection does not take into account the test.java.opts property as it should. >>> >>> updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ (only VMConnection changed) >>> >>> Thanks, >>> /Staffan >>> >>> On 10 jun 2014, at 13:59, Staffan Larsen wrote: >>> >>>> >>>> On 10 jun 2014, at 11:44, serguei.spitsyn at oracle.com wrote: >>>> >>>>> Staffan, >>>>> >>>>> It looks good, just one comment. >>>>> >>>>> test/com/sun/jdi/VMConnection.java >>>>> 61 String vmOpts = System.getProperty("test.vm.opts"); >>>>> 62 if (vmOpts != null) { >>>>> 63 retVal += System.getProperty("test.vm.opts"); >>>>> I wonder why not this: >>>>> 63 retVal += vmOpts; >>>> Uh. Yeah, I wonder that, too. Fixed. :-) >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>>>>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>>>>> >>>>>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>>>>> >>>>>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6622468 >>>>>> >>>>>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>>>>> >>>>>> I have run this through JPRT with no failures. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> >>>>>> [0] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Mon Jun 16 17:42:51 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 16 Jun 2014 11:42:51 -0600 Subject: RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure In-Reply-To: <6DDA690E-2070-4325-B7A2-CAF24C181718@oracle.com> References: <5396D382.9050804@oracle.com> <9AB37EA7-7005-4389-83A5-5DF5F1636D3A@oracle.com> <539F06BB.9050302@oracle.com> <6DDA690E-2070-4325-B7A2-CAF24C181718@oracle.com> Message-ID: <539F2C9B.6000705@oracle.com> Thanks for closing the loop on my late review. Thumbs up! Dan On 6/16/14 11:39 AM, Staffan Larsen wrote: > > On 16 jun 2014, at 17:01, Daniel D. Daugherty > > wrote: > >> > updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ >> >> test/com/sun/jdi/VMConnection.java >> line 62: System.out.println("vmOpts: "+vmOpts); >> line 67: System.out.println("javaOpts: "+javaOpts); >> line 68: if (javaOpts != null) { >> Indent off by one in patch view; looks like there are tabs. >> >> test/com/sun/jdi/connect/spi/DebugUsingCustomConnector.java >> line 62: List launchers = vmm.launchingConnectors(); >> Indent off by one in patch view; looks like there is a tab. > > Yes, I noticed the tab problem too. Fixed. > >> test/com/sun/jdi/sde/MangleStepTest.java >> old line 85: waitForInput(); >> Why was this line deleted? > > The waitForInput() method waits for input on stdin. There is no > process that provides that input so it?s not necessary. The reason it > works before my change is that System.in.read() returns -1 (end of > input) when run in ?othervm? mode. With the ?driver? change I wanted > the tests to be able to run in ?agentvm? mode and there > System.in.read() blocks. I haven?t delved into the details of why, but > since there is no reason to wait for input here I simply removed the > line. I should have mentioned this in the review request. > > Thanks, > /Staffan > > >> >> No comments on the other files. >> >> Dan >> >> >> On 6/16/14 5:59 AM, Staffan Larsen wrote: >>> I would appreciate a Review of this change. >>> >>> Thanks, >>> /Staffan >>> >>> On 11 jun 2014, at 10:00, Staffan Larsen >> > wrote: >>> >>>> I realized that the code in VMConnection does not take into account >>>> the test.java.opts property as it should. >>>> >>>> updated webrev: >>>> http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/ >>>> (only >>>> VMConnection changed) >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 10 jun 2014, at 13:59, Staffan Larsen >>> > wrote: >>>> >>>>> >>>>> On 10 jun 2014, at 11:44,serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> It looks good, just one comment. >>>>>> >>>>>> test/com/sun/jdi/VMConnection.java >>>>>> 61 String vmOpts = System.getProperty("test.vm.opts"); >>>>>> 62 if (vmOpts != null) { >>>>>> 63 retVal += System.getProperty("test.vm.opts"); >>>>>> I wonder why not this: >>>>>> 63 retVal += vmOpts; >>>>> Uh. Yeah, I wonder that, too. Fixed. :-) >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 6/10/14 12:58 AM, Staffan Larsen wrote: >>>>>>> This is a new take on this old bug. Since my previous attempt [0], jtreg has been update with a ?driver? feature and this is exactly what these tests need. Specifying ?@run driver? (instead of ?@run main?) will launch the test with no vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be available in the System property test.vm.opts and the test code can use those arguments when launching other processes. >>>>>>> >>>>>>> For the JDI tests this is a very good match. The tests run two processes: one debugger and one debuggee. It is really the debuggee that is being tested, the the debugger is just driving the testing. So it is the debuggee that should be invoked with the specified -vmoptions. >>>>>>> >>>>>>> In this change I?ve changed all debuggers to be launched with ?@run driver? and all debuggees to be launched using the test.vm.opts options. This will remove the need to the esoteric @debuggeeVMOptions file that was previously used to pass arguments to the debuggee. >>>>>>> >>>>>>> webrev:http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/ >>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-6622468 >>>>>>> >>>>>>> The webrev is very boring to read, probably best to read the diff file directly. test/com/sun/jdi/VMConnection.java has the only substantial change. >>>>>>> >>>>>>> I have run this through JPRT with no failures. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> [0]http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brendan.d.gregg at gmail.com Tue Jun 17 00:14:33 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Mon, 16 Jun 2014 17:14:33 -0700 Subject: system profilers and incomplete stacks In-Reply-To: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> Message-ID: Thanks but no, I'm aware of that bug and workarounds (I'm using the LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which isn't mentioned in the bug comments, but probably should be). That bug is about missing symbols, but the stacks shown in that bug still go all the way to thread_start. My stacks often don't. For simple programs, the stacks are complete. But something complex (eg, vert.x with event loops), and the stacks are often incomplete, one frame only. Very much like what I see with -fomit-frame-pointer, although this is hotspot, not gcc. Such incomplete stacks are seen using either DTrace or perf_events. It was suggested to me to email the hotspot developers, because this may well be a hotspot optimization they are familiar with. It may also be something really obvious, like that the JVM breaks native stacks due to optimized frames / green threads / etc, and there is absolutely no way around it (no way to disable it). If that's true, it may also mean that the DTrace jstack() action has always had this issue. I'm still reading the source... Brendan On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen wrote: > I think this is the bug you are looking at: > https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to > someone else to confirm. > > /Staffan > > > On 16 jun 2014, at 12:47, Roland Westrelin > wrote: > > Forwarding to serviceability alias where this question belongs I think. > > Begin forwarded message: > > *From: *Brendan Gregg > *Subject: **system profilers and incomplete stacks* > *Date: *June 12, 2014 at 7:15:54 PM GMT+2 > *To: *hotspot-compiler-dev at openjdk.java.net > > G'Day, > > Is there a way to run hotspot so that a system profiler (eg, DTrace, or > Linux perf_events) can measure complete stacks? I often get incomplete, > partial stacks, with one or a few frames only. I'm not worried about > symbols right now, what I'd like is to walk stacks all the way down to > thread start. > > I've been browsing the hotspot code, but haven't found out how yet. I > suspect it's related to Java optimized frames, and has ditched the frame > pointer. I was looking for an equivalent -fno-omit-frame-pointer option. > > Here's an example: > > # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, 8000)] = > count(); }' > [...] > org/mozilla/javascript/ > > ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* > 0x884acce8200002da > 1 > > sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* > 0xffffffff20007f4b > 1 > > > org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* > 0xa20000041 > 1 > [...] > > I see similar incomplete stacks with Linux perf_events. Oracle JDKs from 6 > to 8, and OpenJDK. > > thanks, > > Brendan > -- > http://www.brendangregg.com > > > > -- http://www.brendangregg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 17 05:45:50 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 16 Jun 2014 22:45:50 -0700 Subject: system profilers and incomplete stacks In-Reply-To: References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> Message-ID: <539FD60E.10203@oracle.com> Hi Brendan, We are aware of these issues and work with the Solaris team to fix them in JDK 9. One is the frame pointer is used by the server compiler as a general purpose register on intel. Another is about the virtual (or inlined) frames. There are a couple of related bugs: https://bugs.openjdk.java.net/browse/JDK-6617153 https://bugs.openjdk.java.net/browse/JDK-6276264 There can be more issues filed on this. Please, note, that the jstack action is not implemented on Linux yet. Thanks, Serguei On 6/16/14 5:14 PM, Brendan Gregg wrote: > Thanks but no, I'm aware of that bug and workarounds (I'm using the > LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, > which isn't mentioned in the bug comments, but probably should be). > That bug is about missing symbols, but the stacks shown in that bug > still go all the way to thread_start. My stacks often don't. > > For simple programs, the stacks are complete. But something complex > (eg, vert.x with event loops), and the stacks are often incomplete, > one frame only. Very much like what I see with -fomit-frame-pointer, > although this is hotspot, not gcc. Such incomplete stacks are seen > using either DTrace or perf_events. > > It was suggested to me to email the hotspot developers, because this > may well be a hotspot optimization they are familiar with. It may also > be something really obvious, like that the JVM breaks native stacks > due to optimized frames / green threads / etc, and there is absolutely > no way around it (no way to disable it). If that's true, it may also > mean that the DTrace jstack() action has always had this issue. I'm > still reading the source... > > Brendan > > > > On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen > > wrote: > > I think this is the bug you are looking at: > https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer > to someone else to confirm. > > /Staffan > > > On 16 jun 2014, at 12:47, Roland Westrelin > > > wrote: > >> Forwarding to serviceability alias where this question belongs I >> think. >> >> Begin forwarded message: >> >>> *From: *Brendan Gregg >> > >>> *Subject: **system profilers and incomplete stacks* >>> *Date: *June 12, 2014 at 7:15:54 PM GMT+2 >>> *To: *hotspot-compiler-dev at openjdk.java.net >>> >>> >>> G'Day, >>> >>> Is there a way to run hotspot so that a system profiler (eg, >>> DTrace, or Linux perf_events) can measure complete stacks? I >>> often get incomplete, partial stacks, with one or a few frames >>> only. I'm not worried about symbols right now, what I'd like is >>> to walk stacks all the way down to thread start. >>> >>> I've been browsing the hotspot code, but haven't found out how >>> yet. I suspect it's related to Java optimized frames, and has >>> ditched the frame pointer. I was looking for an equivalent >>> -fno-omit-frame-pointer option. >>> >>> Here's an example: >>> >>> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, >>> 8000)] = count(); }' >>> [...] >>> org/mozilla/javascript/ >>> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >>> 0x884acce8200002da >>> 1 >>> >>> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >>> 0xffffffff20007f4b >>> 1 >>> >>> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >>> 0xa20000041 >>> 1 >>> [...] >>> >>> I see similar incomplete stacks with Linux perf_events. Oracle >>> JDKs from 6 to 8, and OpenJDK. >>> >>> thanks, >>> >>> Brendan >>> -- >>> http://www.brendangregg.com >> > > > > > -- > http://www.brendangregg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Jun 17 05:48:24 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Jun 2014 15:48:24 +1000 Subject: system profilers and incomplete stacks In-Reply-To: References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> Message-ID: <539FD6A8.4080109@oracle.com> Hi Brendan, I'm not quite seeing the complete context here so a few queries: 1. Which platform are you running Dtrace on? (hotspot has to provide helper d-scripts to allow Dtrace to walk Java stacks) 2. What are perf-events? How do they try to walk stacks? 3. Does "jstack -m" show full stacks for the apps where you see problem? Thanks, David On 17/06/2014 10:14 AM, Brendan Gregg wrote: > Thanks but no, I'm aware of that bug and workarounds (I'm using the > LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which > isn't mentioned in the bug comments, but probably should be). That bug > is about missing symbols, but the stacks shown in that bug still go all > the way to thread_start. My stacks often don't. > > For simple programs, the stacks are complete. But something complex (eg, > vert.x with event loops), and the stacks are often incomplete, one frame > only. Very much like what I see with -fomit-frame-pointer, although this > is hotspot, not gcc. Such incomplete stacks are seen using either DTrace > or perf_events. > > It was suggested to me to email the hotspot developers, because this may > well be a hotspot optimization they are familiar with. It may also be > something really obvious, like that the JVM breaks native stacks due to > optimized frames / green threads / etc, and there is absolutely no way > around it (no way to disable it). If that's true, it may also mean that > the DTrace jstack() action has always had this issue. I'm still reading > the source... > > Brendan > > > > On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen > > wrote: > > I think this is the bug you are looking at: > https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to > someone else to confirm. > > /Staffan > > > On 16 jun 2014, at 12:47, Roland Westrelin > > > wrote: > >> Forwarding to serviceability alias where this question belongs I >> think. >> >> Begin forwarded message: >> >>> *From: *Brendan Gregg >> > >>> *Subject: **system profilers and incomplete stacks* >>> *Date: *June 12, 2014 at 7:15:54 PM GMT+2 >>> *To: *hotspot-compiler-dev at openjdk.java.net >>> >>> >>> G'Day, >>> >>> Is there a way to run hotspot so that a system profiler (eg, >>> DTrace, or Linux perf_events) can measure complete stacks? I >>> often get incomplete, partial stacks, with one or a few frames >>> only. I'm not worried about symbols right now, what I'd like is >>> to walk stacks all the way down to thread start. >>> >>> I've been browsing the hotspot code, but haven't found out how >>> yet. I suspect it's related to Java optimized frames, and has >>> ditched the frame pointer. I was looking for an equivalent >>> -fno-omit-frame-pointer option. >>> >>> Here's an example: >>> >>> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, >>> 8000)] = count(); }' >>> [...] >>> org/mozilla/javascript/ >>> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >>> 0x884acce8200002da >>> 1 >>> >>> >>> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >>> 0xffffffff20007f4b >>> 1 >>> >>> >>> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >>> 0xa20000041 >>> 1 >>> [...] >>> >>> I see similar incomplete stacks with Linux perf_events. Oracle >>> JDKs from 6 to 8, and OpenJDK. >>> >>> thanks, >>> >>> Brendan >>> -- >>> http://www.brendangregg.com >> > > > > > -- > http://www.brendangregg.com From brendan.d.gregg at gmail.com Tue Jun 17 06:52:19 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Mon, 16 Jun 2014 23:52:19 -0700 Subject: system profilers and incomplete stacks In-Reply-To: <539FD60E.10203@oracle.com> References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> <539FD60E.10203@oracle.com> Message-ID: G'Day Serguei, On Mon, Jun 16, 2014 at 10:45 PM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Brendan, > > We are aware of these issues and work with the Solaris team to fix them in > JDK 9. > One is the frame pointer is used by the server compiler as a general > purpose register on intel. > Another is about the virtual (or inlined) frames. > > There are a couple of related bugs: > https://bugs.openjdk.java.net/browse/JDK-6617153 > https://bugs.openjdk.java.net/browse/JDK-6276264 > > There can be more issues filed on this. > Ah, thanks, it's JDK-6276264. As Tom Rodriguez said at the time (2005): "The server VM uses the frame pointer as an allocatable register and there's no way to turn that off." I was really hoping there was a way to turn that off, like -fno-omit-frame-pointer. This also means DTrace jstack() has never worked fully. For the applications I tried it on, 50% of stacks were incomplete. Perhaps it wasn't that bad in 2005. I've been getting more mileage today from Java profilers. Please, note, that the jstack action is not implemented on Linux yet. > Linux doesn't have DTrace jstack(), no, but its perf_events does has support for loading an auxiliary file of symbols, which can created via a Java agent for that purpose (eg, https://github.com/jrudolph/perf-map-agent). But that hasn't been working fully for the same reason - incomplete stacks. Brendan > Thanks, > Serguei > > > > On 6/16/14 5:14 PM, Brendan Gregg wrote: > > Thanks but no, I'm aware of that bug and workarounds (I'm using the > LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which > isn't mentioned in the bug comments, but probably should be). That bug is > about missing symbols, but the stacks shown in that bug still go all the > way to thread_start. My stacks often don't. > > For simple programs, the stacks are complete. But something complex (eg, > vert.x with event loops), and the stacks are often incomplete, one frame > only. Very much like what I see with -fomit-frame-pointer, although this is > hotspot, not gcc. Such incomplete stacks are seen using either DTrace or > perf_events. > > It was suggested to me to email the hotspot developers, because this may > well be a hotspot optimization they are familiar with. It may also be > something really obvious, like that the JVM breaks native stacks due to > optimized frames / green threads / etc, and there is absolutely no way > around it (no way to disable it). If that's true, it may also mean that the > DTrace jstack() action has always had this issue. I'm still reading the > source... > > Brendan > > > > On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen > wrote: > >> I think this is the bug you are looking at: >> https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to >> someone else to confirm. >> >> /Staffan >> >> >> On 16 jun 2014, at 12:47, Roland Westrelin >> wrote: >> >> Forwarding to serviceability alias where this question belongs I think. >> >> Begin forwarded message: >> >> *From: *Brendan Gregg >> *Subject: **system profilers and incomplete stacks* >> *Date: *June 12, 2014 at 7:15:54 PM GMT+2 >> *To: *hotspot-compiler-dev at openjdk.java.net >> >> G'Day, >> >> Is there a way to run hotspot so that a system profiler (eg, DTrace, or >> Linux perf_events) can measure complete stacks? I often get incomplete, >> partial stacks, with one or a few frames only. I'm not worried about >> symbols right now, what I'd like is to walk stacks all the way down to >> thread start. >> >> I've been browsing the hotspot code, but haven't found out how yet. I >> suspect it's related to Java optimized frames, and has ditched the frame >> pointer. I was looking for an equivalent -fno-omit-frame-pointer option. >> >> Here's an example: >> >> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, 8000)] = >> count(); }' >> [...] >> org/mozilla/javascript/ >> >> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >> 0x884acce8200002da >> 1 >> >> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >> 0xffffffff20007f4b >> 1 >> >> >> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >> 0xa20000041 >> 1 >> [...] >> >> I see similar incomplete stacks with Linux perf_events. Oracle JDKs >> from 6 to 8, and OpenJDK. >> >> thanks, >> >> Brendan >> -- >> http://www.brendangregg.com >> >> >> >> > > > -- > http://www.brendangregg.com > > > -- http://www.brendangregg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brendan.d.gregg at gmail.com Tue Jun 17 07:06:45 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Tue, 17 Jun 2014 00:06:45 -0700 Subject: system profilers and incomplete stacks In-Reply-To: <539FD6A8.4080109@oracle.com> References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> <539FD6A8.4080109@oracle.com> Message-ID: G'Day David, Looks like it's JDK-6276264; I'll answer these questions anyone in case anyone was interested... On Mon, Jun 16, 2014 at 10:48 PM, David Holmes wrote: > Hi Brendan, > > I'm not quite seeing the complete context here so a few queries: > > 1. Which platform are you running Dtrace on? (hotspot has to provide > helper d-scripts to allow Dtrace to walk Java stacks) > OmniOS. I'd also tried Oracle Linux, but it doesn't look like they have done jstack() yet. > 2. What are perf-events? How do they try to walk stacks? > The Linux perf command, which is sometimes known as perf_events. Like DTrace, it's hard to summarize as it does many things, including static and dynamic probe instrumentation, sampling, and profiling of CPU performance counters. It's probably the most important of all the Linux tools in this area because it is in the mainline kernel. It has a couple of stack walking modes: frame pointers, and libdw DWARF unwind. More modes could be added. > > 3. Does "jstack -m" show full stacks for the apps where you see problem? > I'll have to compare it more closely, but on first look it appears to match the broken stacks. Eg: [...] ----------------- t at 21 ----------------- 0x00007ffffee69f3a ioctl + 0xa 0x00007fffe7cbc8b2 0x00007fffe7dea54c ----------------- t at 23 ----------------- 0x00007ffffee6a96a __writev + 0xa 0x00007ffff86e8abe Java_sun_nio_ch_FileDispatcherImpl_writev0 + 0x2e 0x00007fffe7ca258b 0x00007fffe7d5c500 * sun.nio.ch.SocketDispatcher.writev(java.io.FileDescriptor, long, int) bci:4 line:51 (Compiled frame) * sun.nio.ch.IOUtil.write(java.io.FileDescriptor, java.nio.ByteBuffer[], int, int, sun.nio.ch.NativeDispatcher) bci:277 line:148 (Compiled frame) ----------------- t at 24 ----------------- 0x00007ffffee6a96a __writev + 0xa 0x00007ffff86e8abe Java_sun_nio_ch_FileDispatcherImpl_writev0 + 0x2e 0x00007fffe7ca258b 0x00007fffe7d5c500 * sun.nio.ch.SocketDispatcher.writev(java.io.FileDescriptor, long, int) bci:4 line:51 (Compiled frame) * sun.nio.ch.IOUtil.write(java.io.FileDescriptor, java.nio.ByteBuffer[], int, int, sun.nio.ch.NativeDispatcher) bci:277 line:148 (Compiled frame) ----------------- t at 25 ----------------- [...] Thanks, Brendan > Thanks, > David > > > On 17/06/2014 10:14 AM, Brendan Gregg wrote: > >> Thanks but no, I'm aware of that bug and workarounds (I'm using the >> LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which >> isn't mentioned in the bug comments, but probably should be). That bug >> is about missing symbols, but the stacks shown in that bug still go all >> the way to thread_start. My stacks often don't. >> >> For simple programs, the stacks are complete. But something complex (eg, >> vert.x with event loops), and the stacks are often incomplete, one frame >> only. Very much like what I see with -fomit-frame-pointer, although this >> is hotspot, not gcc. Such incomplete stacks are seen using either DTrace >> or perf_events. >> >> It was suggested to me to email the hotspot developers, because this may >> well be a hotspot optimization they are familiar with. It may also be >> something really obvious, like that the JVM breaks native stacks due to >> optimized frames / green threads / etc, and there is absolutely no way >> around it (no way to disable it). If that's true, it may also mean that >> the DTrace jstack() action has always had this issue. I'm still reading >> the source... >> >> Brendan >> >> >> >> On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen >> > wrote: >> >> I think this is the bug you are looking at: >> https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to >> someone else to confirm. >> >> /Staffan >> >> >> On 16 jun 2014, at 12:47, Roland Westrelin >> > >> wrote: >> >> Forwarding to serviceability alias where this question belongs I >>> think. >>> >>> Begin forwarded message: >>> >>> *From: *Brendan Gregg >>> > >>>> *Subject: **system profilers and incomplete stacks* >>>> *Date: *June 12, 2014 at 7:15:54 PM GMT+2 >>>> *To: *hotspot-compiler-dev at openjdk.java.net >>>> >>>> >>>> >>>> G'Day, >>>> >>>> Is there a way to run hotspot so that a system profiler (eg, >>>> DTrace, or Linux perf_events) can measure complete stacks? I >>>> often get incomplete, partial stacks, with one or a few frames >>>> only. I'm not worried about symbols right now, what I'd like is >>>> to walk stacks all the way down to thread start. >>>> >>>> I've been browsing the hotspot code, but haven't found out how >>>> yet. I suspect it's related to Java optimized frames, and has >>>> ditched the frame pointer. I was looking for an equivalent >>>> -fno-omit-frame-pointer option. >>>> >>>> Here's an example: >>>> >>>> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, >>>> 8000)] = count(); }' >>>> [...] >>>> org/mozilla/javascript/ >>>> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/ >>>> mozilla/javascript/ScriptableObject$Slot;* >>>> 0x884acce8200002da >>>> 1 >>>> >>>> >>>> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >>>> 0xffffffff20007f4b >>>> 1 >>>> >>>> >>>> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/ >>>> Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/ >>>> Context;Lorg/mozilla/javascript/Scriptable;)Lorg/ >>>> mozilla/javascript/Scriptable;* >>>> 0xa20000041 >>>> 1 >>>> [...] >>>> >>>> I see similar incomplete stacks with Linux perf_events. Oracle >>>> JDKs from 6 to 8, and OpenJDK. >>>> >>>> thanks, >>>> >>>> Brendan >>>> -- >>>> http://www.brendangregg.com >>>> >>> >>> >> >> >> >> -- >> http://www.brendangregg.com >> > -- http://www.brendangregg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 17 07:11:18 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 17 Jun 2014 00:11:18 -0700 Subject: system profilers and incomplete stacks In-Reply-To: References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> <539FD60E.10203@oracle.com> Message-ID: <539FEA16.2050607@oracle.com> Brendan, Thank you for the details, especially, about the perf_events! I was not aware about the issue on Linux. I agree, the Solaris jstack issue was not that bad back in 2005. It needs to be fixed cooperatively with the OS. We have an idea how to fix it, this work is at the prototyping stage now. Thanks, Serguei On 6/16/14 11:52 PM, Brendan Gregg wrote: > G'Day Serguei, > > On Mon, Jun 16, 2014 at 10:45 PM, serguei.spitsyn at oracle.com > > wrote: > > Hi Brendan, > > We are aware of these issues and work with the Solaris team to fix > them in JDK 9. > One is the frame pointer is used by the server compiler as a > general purpose register on intel. > Another is about the virtual (or inlined) frames. > > There are a couple of related bugs: > https://bugs.openjdk.java.net/browse/JDK-6617153 > https://bugs.openjdk.java.net/browse/JDK-6276264 > > There can be more issues filed on this. > > > Ah, thanks, it's JDK-6276264. > > As Tom Rodriguez said at the time (2005): "The server VM uses the > frame pointer as an allocatable register and there's no way to turn > that off." I was really hoping there was a way to turn that off, like > -fno-omit-frame-pointer. > > This also means DTrace jstack() has never worked fully. For the > applications I tried it on, 50% of stacks were incomplete. Perhaps it > wasn't that bad in 2005. I've been getting more mileage today from > Java profilers. > > Please, note, that the jstack action is not implemented on Linux yet. > > > Linux doesn't have DTrace jstack(), no, but its perf_events does has > support for loading an auxiliary file of symbols, which can created > via a Java agent for that purpose (eg, > https://github.com/jrudolph/perf-map-agent). But that hasn't been > working fully for the same reason - incomplete stacks. > > Brendan > > > Thanks, > Serguei > > > > On 6/16/14 5:14 PM, Brendan Gregg wrote: >> Thanks but no, I'm aware of that bug and workarounds (I'm using >> the LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so >> workaround, which isn't mentioned in the bug comments, but >> probably should be). That bug is about missing symbols, but the >> stacks shown in that bug still go all the way to thread_start. My >> stacks often don't. >> >> For simple programs, the stacks are complete. But something >> complex (eg, vert.x with event loops), and the stacks are often >> incomplete, one frame only. Very much like what I see with >> -fomit-frame-pointer, although this is hotspot, not gcc. Such >> incomplete stacks are seen using either DTrace or perf_events. >> >> It was suggested to me to email the hotspot developers, because >> this may well be a hotspot optimization they are familiar with. >> It may also be something really obvious, like that the JVM breaks >> native stacks due to optimized frames / green threads / etc, and >> there is absolutely no way around it (no way to disable it). If >> that's true, it may also mean that the DTrace jstack() action has >> always had this issue. I'm still reading the source... >> >> Brendan >> >> >> >> On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen >> > wrote: >> >> I think this is the bug you are looking at: >> https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll >> defer to someone else to confirm. >> >> /Staffan >> >> >> On 16 jun 2014, at 12:47, Roland Westrelin >> > > wrote: >> >>> Forwarding to serviceability alias where this question >>> belongs I think. >>> >>> Begin forwarded message: >>> >>>> *From: *Brendan Gregg >>> > >>>> *Subject: **system profilers and incomplete stacks* >>>> *Date: *June 12, 2014 at 7:15:54 PM GMT+2 >>>> *To: *hotspot-compiler-dev at openjdk.java.net >>>> >>>> >>>> G'Day, >>>> >>>> Is there a way to run hotspot so that a system profiler >>>> (eg, DTrace, or Linux perf_events) can measure complete >>>> stacks? I often get incomplete, partial stacks, with one or >>>> a few frames only. I'm not worried about symbols right now, >>>> what I'd like is to walk stacks all the way down to thread >>>> start. >>>> >>>> I've been browsing the hotspot code, but haven't found out >>>> how yet. I suspect it's related to Java optimized frames, >>>> and has ditched the frame pointer. I was looking for an >>>> equivalent -fno-omit-frame-pointer option. >>>> >>>> Here's an example: >>>> >>>> # dtrace -n 'profile-99 /execname == "java"/ { >>>> @[jstack(100, 8000)] = count(); }' >>>> [...] >>>> org/mozilla/javascript/ >>>> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >>>> 0x884acce8200002da >>>> 1 >>>> >>>> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >>>> 0xffffffff20007f4b >>>> 1 >>>> >>>> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >>>> 0xa20000041 >>>> 1 >>>> [...] >>>> >>>> I see similar incomplete stacks with Linux perf_events. >>>> Oracle JDKs from 6 to 8, and OpenJDK. >>>> >>>> thanks, >>>> >>>> Brendan >>>> -- >>>> http://www.brendangregg.com >>> >> >> >> >> >> -- >> http://www.brendangregg.com > > > > > -- > http://www.brendangregg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Jun 17 08:24:12 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Jun 2014 10:24:12 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows Message-ID: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> This is yet another fallout of the bug in the ps command in cygwin that causes it to sometimes miss process in the list. In this case I cannot use jps to list the processes since one of the test cases launches jdwp with suspend=y which suspends the VM before it is visible to jps. Instead I retry the ps command 10 times hoping that it works eventually. webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/test/com/sun/jdi/ProcessAttachTest.sh.sdiff.html bug: https://bugs.openjdk.java.net/browse/JDK-8046883 Thanks, /Staffan From Alan.Bateman at oracle.com Tue Jun 17 09:45:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Jun 2014 10:45:55 +0100 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> Message-ID: <53A00E53.5040106@oracle.com> On 17/06/2014 09:24, Staffan Larsen wrote: > This is yet another fallout of the bug in the ps command in cygwin that causes it to sometimes miss process in the list. > > In this case I cannot use jps to list the processes since one of the test cases launches jdwp with suspend=y which suspends the VM before it is visible to jps. Instead I retry the ps command 10 times hoping that it works eventually. > > webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/test/com/sun/jdi/ProcessAttachTest.sh.sdiff.html > bug: https://bugs.openjdk.java.net/browse/JDK-8046883 > I don't understand the bug in cygwin but I just wonder if it's a timing issue. If it is then maybe it would be better to sleep 2 at line 79 into the loop as a sleep 1? -Alan. From dmitry.samersoff at oracle.com Tue Jun 17 09:56:51 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 17 Jun 2014 13:56:51 +0400 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> Message-ID: <53A010E3.4010409@oracle.com> Staffan, As we need windows pid it might be better to try native windows commands instead of cygwin ps: tasklist wmic process get Processid,Executablepath -Dmitry On 2014-06-17 12:24, Staffan Larsen wrote: > This is yet another fallout of the bug in the ps command in cygwin that causes it to sometimes miss process in the list. > > In this case I cannot use jps to list the processes since one of the test cases launches jdwp with suspend=y which suspends the VM before it is visible to jps. Instead I retry the ps command 10 times hoping that it works eventually. > > webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/test/com/sun/jdi/ProcessAttachTest.sh.sdiff.html > bug: https://bugs.openjdk.java.net/browse/JDK-8046883 > > Thanks, > /Staffan > -- 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 Jun 17 12:35:18 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Jun 2014 14:35:18 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <53A00E53.5040106@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> Message-ID: <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> On 17 jun 2014, at 11:45, Alan Bateman wrote: > On 17/06/2014 09:24, Staffan Larsen wrote: >> This is yet another fallout of the bug in the ps command in cygwin that causes it to sometimes miss process in the list. >> >> In this case I cannot use jps to list the processes since one of the test cases launches jdwp with suspend=y which suspends the VM before it is visible to jps. Instead I retry the ps command 10 times hoping that it works eventually. >> >> webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/test/com/sun/jdi/ProcessAttachTest.sh.sdiff.html >> bug: https://bugs.openjdk.java.net/browse/JDK-8046883 >> > I don't understand the bug in cygwin but I just wonder if it's a timing issue. If it is then maybe it would be better to sleep 2 at line 79 into the loop as a sleep 1? It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. /Staffan > > -Alan. From staffan.larsen at oracle.com Tue Jun 17 12:38:20 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Jun 2014 14:38:20 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <53A010E3.4010409@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A010E3.4010409@oracle.com> Message-ID: <27509A92-D694-4FD1-A282-0235CEEF7D7D@oracle.com> On 17 jun 2014, at 11:56, Dmitry Samersoff wrote: > Staffan, > > As we need windows pid it might be better to try native windows commands > instead of cygwin ps: > > tasklist I tried this, but since it does not list the command line it?s not possible to identify the process I am looking for. > wmic process get Processid,Executablepath I didn?t know about wmic. It seems usable for this. Something like: pid=`wmic process get ProcessId,CommandLine /TRANSLATE:NoComma /FORMAT:csv | grep "cookie=$$" | cut -d "," -f 3` seems to work. On the other hand, if the real problem is that the actual process has not yet been launched (even if bash returns with a cygwin process id) it won?t help whatever command I run - there is no process to list. /Staffan > > -Dmitry > > > On 2014-06-17 12:24, Staffan Larsen wrote: >> This is yet another fallout of the bug in the ps command in cygwin that causes it to sometimes miss process in the list. >> >> In this case I cannot use jps to list the processes since one of the test cases launches jdwp with suspend=y which suspends the VM before it is visible to jps. Instead I retry the ps command 10 times hoping that it works eventually. >> >> webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/test/com/sun/jdi/ProcessAttachTest.sh.sdiff.html >> bug: https://bugs.openjdk.java.net/browse/JDK-8046883 >> >> Thanks, >> /Staffan >> > > > -- > 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 Alan.Bateman at oracle.com Tue Jun 17 13:03:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Jun 2014 14:03:39 +0100 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> Message-ID: <53A03CAB.6050206@oracle.com> On 17/06/2014 13:35, Staffan Larsen wrote: > : > > It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. > > Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. > > Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. -Alan From staffan.larsen at oracle.com Tue Jun 17 13:12:58 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Jun 2014 15:12:58 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <53A03CAB.6050206@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> <53A03CAB.6050206@oracle.com> Message-ID: On 17 jun 2014, at 15:03, Alan Bateman wrote: > On 17/06/2014 13:35, Staffan Larsen wrote: >> : >> >> It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. >> >> Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. >> >> > Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. Ah, I see. I misunderstood your comment. I started looking at rewriting the test in pure Java instead of the shell script. With the new Process.getPid() this looks like the best approach. I?ll come back with a new review request soon. /Staffan From dmitry.samersoff at oracle.com Tue Jun 17 14:11:22 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 17 Jun 2014 18:11:22 +0400 Subject: RFR(S): JDK-8044762 com/sun/jdi/OptionTest.java test time out Message-ID: <53A04C8A.4030403@oracle.com> Please, Review a small fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8044762/webrev.01/ under some circumstances debugInit_exit is called before gdata is initialized. -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 daniel.daugherty at oracle.com Tue Jun 17 14:35:44 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 17 Jun 2014 08:35:44 -0600 Subject: RFR(S): JDK-8044762 com/sun/jdi/OptionTest.java test time out In-Reply-To: <53A04C8A.4030403@oracle.com> References: <53A04C8A.4030403@oracle.com> Message-ID: <53A05240.3070207@oracle.com> On 6/17/14 8:11 AM, Dmitry Samersoff wrote: > Please, > > Review a small fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8044762/webrev.01/ src/share/back/debugInit.c line 1290: LOG_MISC(("Dumping core as requiested by command line")); Typo: 'requiested' -> 'requested' Thumbs up. Dan > > under some circumstances debugInit_exit is called before gdata is > initialized. > > -Dmitry > From dmitry.samersoff at oracle.com Tue Jun 17 16:55:56 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 17 Jun 2014 20:55:56 +0400 Subject: RFR(S): JDK-8044762 com/sun/jdi/OptionTest.java test time out In-Reply-To: <53A05240.3070207@oracle.com> References: <53A04C8A.4030403@oracle.com> <53A05240.3070207@oracle.com> Message-ID: <53A0731C.8000607@oracle.com> Dan, Thank you. Typeo fixed (in-place). -Dmitry On 2014-06-17 18:35, Daniel D. Daugherty wrote: > On 6/17/14 8:11 AM, Dmitry Samersoff wrote: >> Please, >> >> Review a small fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8044762/webrev.01/ > > src/share/back/debugInit.c > line 1290: LOG_MISC(("Dumping core as requiested by command line")); > Typo: 'requiested' -> 'requested' > > Thumbs up. > > Dan > > >> >> under some circumstances debugInit_exit is called before gdata is >> initialized. >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Tue Jun 17 17:46:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Jun 2014 19:46:05 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> <53A03CAB.6050206@oracle.com> Message-ID: <09D86058-1054-42C2-9689-7E6D4726A789@oracle.com> Here is a rewrite of the test in Java instead of a shell script. Should be easier to maintain. webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ Thanks, /Staffan On 17 jun 2014, at 15:12, Staffan Larsen wrote: > > On 17 jun 2014, at 15:03, Alan Bateman wrote: > >> On 17/06/2014 13:35, Staffan Larsen wrote: >>> : >>> >>> It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. >>> >>> Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. >>> >>> >> Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. > > Ah, I see. I misunderstood your comment. > > I started looking at rewriting the test in pure Java instead of the shell script. With the new Process.getPid() this looks like the best approach. I?ll come back with a new review request soon. > > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Jun 17 17:47:15 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Jun 2014 19:47:15 +0200 Subject: RFR(S): JDK-8044762 com/sun/jdi/OptionTest.java test time out In-Reply-To: <53A0731C.8000607@oracle.com> References: <53A04C8A.4030403@oracle.com> <53A05240.3070207@oracle.com> <53A0731C.8000607@oracle.com> Message-ID: <7009EFA3-C277-4222-8F1C-469867EC017A@oracle.com> Looks good! Thanks, /Staffan On 17 jun 2014, at 18:55, Dmitry Samersoff wrote: > Dan, > > Thank you. > > Typeo fixed (in-place). > > -Dmitry > > On 2014-06-17 18:35, Daniel D. Daugherty wrote: >> On 6/17/14 8:11 AM, Dmitry Samersoff wrote: >>> Please, >>> >>> Review a small fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8044762/webrev.01/ >> >> src/share/back/debugInit.c >> line 1290: LOG_MISC(("Dumping core as requiested by command line")); >> Typo: 'requiested' -> 'requested' >> >> Thumbs up. >> >> Dan >> >> >>> >>> under some circumstances debugInit_exit is called before gdata is >>> initialized. >>> >>> -Dmitry >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Tue Jun 17 18:30:38 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Jun 2014 20:30:38 +0200 Subject: RFR: 8044772 TempDirTest.java still times out with -Xcomp Message-ID: This test launches four other VMs, thus taking a very long time to run with -Xcomp. The real change here is to increase the timeout of the test, but I have also added some logging so that it is possible to see for how far along the test has come if it times out. bug: https://bugs.openjdk.java.net/browse/JDK-8044772 webrev: http://cr.openjdk.java.net/~sla/8044772/webrev.00/ Thanks, /Staffan From staffan.larsen at oracle.com Tue Jun 17 18:40:06 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Jun 2014 20:40:06 +0200 Subject: RFR: 8046778 Better error messages when starting JMX agent via attach or jcmd In-Reply-To: <07BCF5C0-59D1-4903-8535-B80F99F54A88@oracle.com> References: <07BCF5C0-59D1-4903-8535-B80F99F54A88@oracle.com> Message-ID: <7D2A29E4-7487-4F91-BABF-628579D4307D@oracle.com> This change is still looking for a reviewer. Thanks, /Staffan On 13 jun 2014, at 13:03, Staffan Larsen wrote: > > When starting the JMX agent via jcmd, the error messages you get are very cryptic: > > $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start > 9979: > java.lang.RuntimeException: Invalid option specified > > $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start config.file=apa > 10024: > java.lang.RuntimeException: Config file not found > > $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start jmxremote.port=5000 > 9979: > sun.management.AgentConfigurationError > > > This is just because errors are note propagated correctly to the jcmd. With some small changes the above can look like this: > > $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start > 89673: > java.lang.RuntimeException: Invalid com.sun.management.jmxremote.port number: No port specified > > $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start config.file=apa > 89673: > java.lang.RuntimeException: Config file not found: apa > > $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start jmxremote.port=5000 > 89673: > java.lang.RuntimeException: Password file not found: /Users/staffan/mercurial/jdk9-hs-rt/build/macosx-x86_64-normal-server-release/jdk/lib/management/jmxremote.password > > webrev: http://cr.openjdk.java.net/~sla/8046778/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8046778 > > Thanks, > /Staffan > From erik.gahlin at oracle.com Tue Jun 17 21:13:53 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 17 Jun 2014 23:13:53 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> Message-ID: <53A0AF91.9060204@oracle.com> Yes, very weird Could have been that I needed the tools.jar in the child processes, or it could have been something else. If I remember correctly, I got a CNF that I didn't get with the shell script, but it was few months back. Anyway, I retried with JPRT and now it works without the shell script. http://cr.openjdk.java.net/~egahlin/8028474_2/ Erik Staffan Larsen skrev 2014-06-16 13:49: > > On 16 jun 2014, at 12:32, Erik Gahlin > wrote: > >> Yekaterina Kantserova skrev 13/06/14 12:59: >>> Erik, >>> >>> is there some reason why we need to keep MonitorVmStartTerminate.sh? >>> I've moved the JTreg header to MonitorVmStartTerminate.java >> Hi Katja, >> >> That's how I did the test initially, and it works locally, but I >> could never get it to work in JPRT without the shell script. I >> believe the tools.jar is not on the class path. > > That is weird. I see other tests that depend in tools.jar and they > work fine. > > /Staffan > > >> >> Erik >>> >>> /* >>> * @test >>> * @bug 4990825 >>> * @summary attach to external but local JVM processes >>> * @library /lib/testlibrary >>> * @build jdk.testlibrary.* >>> * @run main MonitorVmStartTerminate >>> */ >>> >>> and the test works just fine. >>> >>> The JTreg run contains all pathes and system properties >>> MonitorVmStartTerminate.sh tries to construct: >>> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} >>> -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >>> >>> See the log attached. >>> >>> Note *@build jdk.testlibrary.** instead of *@build >>> jdk.testlibrary.ProcessTools* to make sure all testlibrary classes >>> are compiled >>> to the right place when running tests concurrently. >>> >>> Thanks, >>> Katja (Not a Reviewer) >>> >>> >>> >>> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>>> Hi, >>>> >>>> Could I have a review of a test that has been failing >>>> intermittently. The test now uses files for synchronization >>>> instead of waiting for a process that sleeps. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~egahlin/8028474/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>>> >>>> Description: >>>> >>>> The test starts ten Java processes, each with a unique id. >>>> >>>> Each process creates a file named after the id and then it waits for >>>> the test to remove the file, at which the Java process exits. >>>> >>>> The processes are monitored by the test to make sure notifications >>>> are sent when processes are started/terminated. >>>> >>>> To avoid Java processes being left behind, in case of an unexpected >>>> failure, shutdown hooks are registered that remove files when the >>>> test >>>> exits. If files are not removed, i.e. due to a JVM crash, >>>> the Java processes will exit themselves after 1000 s. >>>> >>>> Thanks >>>> Erik >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Tue Jun 17 21:20:50 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 17 Jun 2014 23:20:50 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <539EE567.6010604@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <539EE567.6010604@oracle.com> Message-ID: <53A0B132.6050705@oracle.com> Hi Dmitry, I'm not worried about files being left behind from a previous run , they all have unique names. Erik Dmitry Samersoff skrev 2014-06-16 14:39: > Erik, > > It's better to check lock-file age rather than maintain in-process > timeout variable, it guards the test from the situation when lock file > was not removed from the previous run for some reason. > > see jdk/test/sun/management/jdp/JdpDoSomething.java > > -Dmitry > > On 2014-06-16 14:32, Erik Gahlin wrote: >> Yekaterina Kantserova skrev 13/06/14 12:59: >>> Erik, >>> >>> is there some reason why we need to keep MonitorVmStartTerminate.sh? >>> I've moved the JTreg header to MonitorVmStartTerminate.java >> Hi Katja, >> >> That's how I did the test initially, and it works locally, but I could >> never get it to work in JPRT without the shell script. I believe the >> tools.jar is not on the class path. >> >> Erik >>> /* >>> * @test >>> * @bug 4990825 >>> * @summary attach to external but local JVM processes >>> * @library /lib/testlibrary >>> * @build jdk.testlibrary.* >>> * @run main MonitorVmStartTerminate >>> */ >>> >>> and the test works just fine. >>> >>> The JTreg run contains all pathes and system properties >>> MonitorVmStartTerminate.sh tries to construct: >>> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} >>> -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >>> >>> See the log attached. >>> >>> Note *@build jdk.testlibrary.** instead of *@build >>> jdk.testlibrary.ProcessTools* to make sure all testlibrary classes are >>> compiled >>> to the right place when running tests concurrently. >>> >>> Thanks, >>> Katja (Not a Reviewer) >>> >>> >>> >>> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>>> Hi, >>>> >>>> Could I have a review of a test that has been failing >>>> intermittently. The test now uses files for synchronization >>>> instead of waiting for a process that sleeps. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~egahlin/8028474/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>>> >>>> Description: >>>> >>>> The test starts ten Java processes, each with a unique id. >>>> >>>> Each process creates a file named after the id and then it waits for >>>> the test to remove the file, at which the Java process exits. >>>> >>>> The processes are monitored by the test to make sure notifications >>>> are sent when processes are started/terminated. >>>> >>>> To avoid Java processes being left behind, in case of an unexpected >>>> failure, shutdown hooks are registered that remove files when the test >>>> exits. If files are not removed, i.e. due to a JVM crash, >>>> the Java processes will exit themselves after 1000 s. >>>> >>>> Thanks >>>> Erik > From david.holmes at oracle.com Wed Jun 18 02:05:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jun 2014 12:05:06 +1000 Subject: RFR: 8044772 TempDirTest.java still times out with -Xcomp In-Reply-To: References: Message-ID: <53A0F3D2.1030605@oracle.com> Hi Staffan On 18/06/2014 4:30 AM, Staffan Larsen wrote: > This test launches four other VMs, thus taking a very long time to run with -Xcomp. The real change here is to increase the timeout of the test, but I have also added some logging so that it is possible to see for how far along the test has come if it times out. > > bug: https://bugs.openjdk.java.net/browse/JDK-8044772 > webrev: http://cr.openjdk.java.net/~sla/8044772/webrev.00/ I would have expected you to print out the elapsed time after running the tests rather than before. The initial printout would typically be zero. But no big deal. David > Thanks, > /Staffan > From david.holmes at oracle.com Wed Jun 18 02:11:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jun 2014 12:11:23 +1000 Subject: RFR: 8046778 Better error messages when starting JMX agent via attach or jcmd In-Reply-To: <7D2A29E4-7487-4F91-BABF-628579D4307D@oracle.com> References: <07BCF5C0-59D1-4903-8535-B80F99F54A88@oracle.com> <7D2A29E4-7487-4F91-BABF-628579D4307D@oracle.com> Message-ID: <53A0F54B.3050909@oracle.com> On 18/06/2014 4:40 AM, Staffan Larsen wrote: > This change is still looking for a reviewer. Looks okay. Though in general the error handling in that code still seems somewhat lacking - there are places where exception chaining should be being used. David > Thanks, > /Staffan > > On 13 jun 2014, at 13:03, Staffan Larsen wrote: > >> >> When starting the JMX agent via jcmd, the error messages you get are very cryptic: >> >> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start >> 9979: >> java.lang.RuntimeException: Invalid option specified >> >> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start config.file=apa >> 10024: >> java.lang.RuntimeException: Config file not found >> >> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start jmxremote.port=5000 >> 9979: >> sun.management.AgentConfigurationError >> >> >> This is just because errors are note propagated correctly to the jcmd. With some small changes the above can look like this: >> >> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start >> 89673: >> java.lang.RuntimeException: Invalid com.sun.management.jmxremote.port number: No port specified >> >> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start config.file=apa >> 89673: >> java.lang.RuntimeException: Config file not found: apa >> >> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start jmxremote.port=5000 >> 89673: >> java.lang.RuntimeException: Password file not found: /Users/staffan/mercurial/jdk9-hs-rt/build/macosx-x86_64-normal-server-release/jdk/lib/management/jmxremote.password >> >> webrev: http://cr.openjdk.java.net/~sla/8046778/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8046778 >> >> Thanks, >> /Staffan >> > From staffan.larsen at oracle.com Wed Jun 18 06:59:52 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 18 Jun 2014 08:59:52 +0200 Subject: RFR: 8044772 TempDirTest.java still times out with -Xcomp In-Reply-To: <53A0F3D2.1030605@oracle.com> References: <53A0F3D2.1030605@oracle.com> Message-ID: On 18 jun 2014, at 04:05, David Holmes wrote: > Hi Staffan > > On 18/06/2014 4:30 AM, Staffan Larsen wrote: >> This test launches four other VMs, thus taking a very long time to run with -Xcomp. The real change here is to increase the timeout of the test, but I have also added some logging so that it is possible to see for how far along the test has come if it times out. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8044772 >> webrev: http://cr.openjdk.java.net/~sla/8044772/webrev.00/ > > I would have expected you to print out the elapsed time after running the tests rather than before. The initial printout would typically be zero. But no big deal. The test runs four times with different permutations. It often times out during one of the last permutations. I wanted to see how long time it took to get there. Maybe I should add timing both before and after the test, though. /S > > David > > > >> Thanks, >> /Staffan >> From staffan.larsen at oracle.com Wed Jun 18 07:00:23 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 18 Jun 2014 09:00:23 +0200 Subject: RFR: 8046778 Better error messages when starting JMX agent via attach or jcmd In-Reply-To: <53A0F54B.3050909@oracle.com> References: <07BCF5C0-59D1-4903-8535-B80F99F54A88@oracle.com> <7D2A29E4-7487-4F91-BABF-628579D4307D@oracle.com> <53A0F54B.3050909@oracle.com> Message-ID: <453C2A1C-370E-4683-B18B-F61B02491358@oracle.com> On 18 jun 2014, at 04:11, David Holmes wrote: > On 18/06/2014 4:40 AM, Staffan Larsen wrote: >> This change is still looking for a reviewer. > > Looks okay. Though in general the error handling in that code still seems somewhat lacking - there are places where exception chaining should be being used. Thanks. Agree that it isn?t perfect. /Staffan > > David > >> Thanks, >> /Staffan >> >> On 13 jun 2014, at 13:03, Staffan Larsen wrote: >> >>> >>> When starting the JMX agent via jcmd, the error messages you get are very cryptic: >>> >>> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start >>> 9979: >>> java.lang.RuntimeException: Invalid option specified >>> >>> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start config.file=apa >>> 10024: >>> java.lang.RuntimeException: Config file not found >>> >>> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start jmxremote.port=5000 >>> 9979: >>> sun.management.AgentConfigurationError >>> >>> >>> This is just because errors are note propagated correctly to the jcmd. With some small changes the above can look like this: >>> >>> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start >>> 89673: >>> java.lang.RuntimeException: Invalid com.sun.management.jmxremote.port number: No port specified >>> >>> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start config.file=apa >>> 89673: >>> java.lang.RuntimeException: Config file not found: apa >>> >>> $ build/macosx-x86_64-normal-server-release/jdk/bin/jcmd Sleeper ManagementAgent.start jmxremote.port=5000 >>> 89673: >>> java.lang.RuntimeException: Password file not found: /Users/staffan/mercurial/jdk9-hs-rt/build/macosx-x86_64-normal-server-release/jdk/lib/management/jmxremote.password >>> >>> webrev: http://cr.openjdk.java.net/~sla/8046778/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8046778 >>> >>> Thanks, >>> /Staffan >>> >> From staffan.larsen at oracle.com Wed Jun 18 07:26:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 18 Jun 2014 09:26:53 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53A0AF91.9060204@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> Message-ID: <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> Erik, How about using Process.destroyForcibly() as a means to terminate the process instead of using files for signaling? /Staffan On 17 jun 2014, at 23:13, Erik Gahlin wrote: > Yes, very weird > > Could have been that I needed the tools.jar in the child processes, or it could have been something else. If I remember correctly, I got a CNF that I didn't get with the shell script, but it was few months back. > > Anyway, I retried with JPRT and now it works without the shell script. > > http://cr.openjdk.java.net/~egahlin/8028474_2/ > > Erik > > Staffan Larsen skrev 2014-06-16 13:49: >> >> On 16 jun 2014, at 12:32, Erik Gahlin wrote: >> >>> Yekaterina Kantserova skrev 13/06/14 12:59: >>>> Erik, >>>> >>>> is there some reason why we need to keep MonitorVmStartTerminate.sh? I've moved the JTreg header to MonitorVmStartTerminate.java >>> Hi Katja, >>> >>> That's how I did the test initially, and it works locally, but I could never get it to work in JPRT without the shell script. I believe the tools.jar is not on the class path. >> >> That is weird. I see other tests that depend in tools.jar and they work fine. >> >> /Staffan >> >> >>> >>> Erik >>>> >>>> /* >>>> * @test >>>> * @bug 4990825 >>>> * @summary attach to external but local JVM processes >>>> * @library /lib/testlibrary >>>> * @build jdk.testlibrary.* >>>> * @run main MonitorVmStartTerminate >>>> */ >>>> >>>> and the test works just fine. >>>> >>>> The JTreg run contains all pathes and system properties MonitorVmStartTerminate.sh tries to construct: >>>> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >>>> >>>> See the log attached. >>>> >>>> Note @build jdk.testlibrary.* instead of @build jdk.testlibrary.ProcessTools to make sure all testlibrary classes are compiled >>>> to the right place when running tests concurrently. >>>> >>>> Thanks, >>>> Katja (Not a Reviewer) >>>> >>>> >>>> >>>> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>>>> Hi, >>>>> >>>>> Could I have a review of a test that has been failing >>>>> intermittently. The test now uses files for synchronization >>>>> instead of waiting for a process that sleeps. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~egahlin/8028474/ >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>>>> >>>>> Description: >>>>> >>>>> The test starts ten Java processes, each with a unique id. >>>>> >>>>> Each process creates a file named after the id and then it waits for >>>>> the test to remove the file, at which the Java process exits. >>>>> >>>>> The processes are monitored by the test to make sure notifications >>>>> are sent when processes are started/terminated. >>>>> >>>>> To avoid Java processes being left behind, in case of an unexpected >>>>> failure, shutdown hooks are registered that remove files when the test >>>>> exits. If files are not removed, i.e. due to a JVM crash, >>>>> the Java processes will exit themselves after 1000 s. >>>>> >>>>> Thanks >>>>> Erik >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Wed Jun 18 07:37:29 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 18 Jun 2014 09:37:29 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> Message-ID: <53A141B9.5000403@oracle.com> Didn't know about destroyForcibly(). I could try that. Erik Staffan Larsen skrev 18/06/14 09:26: > Erik, > > How about using Process.destroyForcibly() as a means to terminate the > process instead of using files for signaling? > > /Staffan > > On 17 jun 2014, at 23:13, Erik Gahlin > wrote: > >> Yes, very weird >> >> Could have been that I needed the tools.jar in the child processes, >> or it could have been something else. If I remember correctly, I got >> a CNF that I didn't get with the shell script, but it was few months >> back. >> >> Anyway, I retried with JPRT and now it works without the shell script. >> >> http://cr.openjdk.java.net/~egahlin/8028474_2/ >> >> Erik >> >> Staffan Larsen skrev 2014-06-16 13:49: >>> >>> On 16 jun 2014, at 12:32, Erik Gahlin >> > wrote: >>> >>>> Yekaterina Kantserova skrev 13/06/14 12:59: >>>>> Erik, >>>>> >>>>> is there some reason why we need to keep >>>>> MonitorVmStartTerminate.sh? I've moved the JTreg header to >>>>> MonitorVmStartTerminate.java >>>> Hi Katja, >>>> >>>> That's how I did the test initially, and it works locally, but I >>>> could never get it to work in JPRT without the shell script. I >>>> believe the tools.jar is not on the class path. >>> >>> That is weird. I see other tests that depend in tools.jar and they >>> work fine. >>> >>> /Staffan >>> >>> >>>> >>>> Erik >>>>> >>>>> /* >>>>> * @test >>>>> * @bug 4990825 >>>>> * @summary attach to external but local JVM processes >>>>> * @library /lib/testlibrary >>>>> * @build jdk.testlibrary.* >>>>> * @run main MonitorVmStartTerminate >>>>> */ >>>>> >>>>> and the test works just fine. >>>>> >>>>> The JTreg run contains all pathes and system properties >>>>> MonitorVmStartTerminate.sh tries to construct: >>>>> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} >>>>> -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >>>>> >>>>> See the log attached. >>>>> >>>>> Note *@build jdk.testlibrary.** instead of *@build >>>>> jdk.testlibrary.ProcessTools* to make sure all testlibrary classes >>>>> are compiled >>>>> to the right place when running tests concurrently. >>>>> >>>>> Thanks, >>>>> Katja (Not a Reviewer) >>>>> >>>>> >>>>> >>>>> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>>>>> Hi, >>>>>> >>>>>> Could I have a review of a test that has been failing >>>>>> intermittently. The test now uses files for synchronization >>>>>> instead of waiting for a process that sleeps. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~egahlin/8028474/ >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>>>>> >>>>>> Description: >>>>>> >>>>>> The test starts ten Java processes, each with a unique id. >>>>>> >>>>>> Each process creates a file named after the id and then it waits >>>>>> for >>>>>> the test to remove the file, at which the Java process exits. >>>>>> >>>>>> The processes are monitored by the test to make sure notifications >>>>>> are sent when processes are started/terminated. >>>>>> >>>>>> To avoid Java processes being left behind, in case of an unexpected >>>>>> failure, shutdown hooks are registered that remove files when >>>>>> the test >>>>>> exits. If files are not removed, i.e. due to a JVM crash, >>>>>> the Java processes will exit themselves after 1000 s. >>>>>> >>>>>> Thanks >>>>>> Erik >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.allwin at oracle.com Wed Jun 18 11:59:34 2014 From: peter.allwin at oracle.com (Peter Allwin) Date: Wed, 18 Jun 2014 13:59:34 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <09D86058-1054-42C2-9689-7E6D4726A789@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> <53A03CAB.6050206@oracle.com> <09D86058-1054-42C2-9689-7E6D4726A789@oracle.com> Message-ID: <09FCC0B8-CC24-488B-99C7-66D3D17267AE@oracle.com> This looks a lot better! (Since we?re using fancy new features we could use streams to find the connector instance) AttachingConnector ac = Bootstrap.virtualMachineManager().attachingConnectors() .stream() .filter(c -> c.name().equals("com.sun.jdi.ProcessAttach")) .findFirst() .orElseThrow(() -> new RuntimeException("Unable to locate ProcessAttachingConnector")); Thanks! /peter On 17 Jun 2014, at 19:46, Staffan Larsen wrote: > Here is a rewrite of the test in Java instead of a shell script. Should be easier to maintain. > > webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ > > Thanks, > /Staffan > > On 17 jun 2014, at 15:12, Staffan Larsen wrote: > >> >> On 17 jun 2014, at 15:03, Alan Bateman wrote: >> >>> On 17/06/2014 13:35, Staffan Larsen wrote: >>>> : >>>> >>>> It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. >>>> >>>> Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. >>>> >>>> >>> Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. >> >> Ah, I see. I misunderstood your comment. >> >> I started looking at rewriting the test in pure Java instead of the shell script. With the new Process.getPid() this looks like the best approach. I?ll come back with a new review request soon. >> >> /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Jun 19 09:06:08 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 19 Jun 2014 11:06:08 +0200 Subject: RFR: Backout fix for 8032901: WaitForMultipleObjects() return value not handled appropriately Message-ID: <0D039703-4052-4AB1-92DE-BA78E71A7C52@oracle.com> This fix was intended to catch a supposedly rare error return value from WaitForMultipleObjects in the shared memory transport for JDI. Unfortunately the error is not so rare (which should have been discovered during testing of the fix) and the fix has caused all the JDI tests on windows to become unstable. While we investigate if the fix can be applied together with changes in the code (so that the error does not happen), I would like to backout the fix. The backout will also have to be applied to 8u20 and 7u80 since the fix was backported there without sufficient baking in 9. webrev: http://cr.openjdk.java.net/~sla/8046024/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8046024 Thanks, /Staffan From Alan.Bateman at oracle.com Thu Jun 19 09:11:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Jun 2014 10:11:08 +0100 Subject: RFR: Backout fix for 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <0D039703-4052-4AB1-92DE-BA78E71A7C52@oracle.com> References: <0D039703-4052-4AB1-92DE-BA78E71A7C52@oracle.com> Message-ID: <53A2A92C.4000900@oracle.com> On 19/06/2014 10:06, Staffan Larsen wrote: > This fix was intended to catch a supposedly rare error return value from WaitForMultipleObjects in the shared memory transport for JDI. Unfortunately the error is not so rare (which should have been discovered during testing of the fix) and the fix has caused all the JDI tests on windows to become unstable. > > While we investigate if the fix can be applied together with changes in the code (so that the error does not happen), I would like to backout the fix. > > The backout will also have to be applied to 8u20 and 7u80 since the fix was backported there without sufficient baking in 9. > > webrev: http://cr.openjdk.java.net/~sla/8046024/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8046024 > Backing it out for now make sense to me, the change looks good. -Alan. From staffan.larsen at oracle.com Thu Jun 19 10:55:35 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 19 Jun 2014 12:55:35 +0200 Subject: RFR: Backout fix for 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <53A2A92C.4000900@oracle.com> References: <0D039703-4052-4AB1-92DE-BA78E71A7C52@oracle.com> <53A2A92C.4000900@oracle.com> Message-ID: <2C54F116-9EA3-430A-9E55-F9E108658B87@oracle.com> On 19 jun 2014, at 11:11, Alan Bateman wrote: > On 19/06/2014 10:06, Staffan Larsen wrote: >> This fix was intended to catch a supposedly rare error return value from WaitForMultipleObjects in the shared memory transport for JDI. Unfortunately the error is not so rare (which should have been discovered during testing of the fix) and the fix has caused all the JDI tests on windows to become unstable. >> >> While we investigate if the fix can be applied together with changes in the code (so that the error does not happen), I would like to backout the fix. >> >> The backout will also have to be applied to 8u20 and 7u80 since the fix was backported there without sufficient baking in 9. >> >> webrev: http://cr.openjdk.java.net/~sla/8046024/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8046024 >> > Backing it out for now make sense to me, the change looks good. Thanks Alan. I have filed a follow-up bug: https://bugs.openjdk.java.net/browse/JDK-8047334 /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Jun 20 13:19:07 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 20 Jun 2014 07:19:07 -0600 Subject: Can't build jdk9-dev due to conflicting includes In-Reply-To: <53A4220A.4010609@gmail.com> References: <53A4220A.4010609@gmail.com> Message-ID: <53A434CB.6020804@oracle.com> Adding the Serviceability group since SA belongs to them... I believe that this issue is solved by this changeset: Changeset: 64e35dfa4ff5 Author: jwilhelm Date: 2014-06-13 17:07 -0400 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/64e35dfa4ff5 8046408: Build failure from multiple ptrace.h Summary: prefer over Reviewed-by: sla, mikael Contributed-by: kim.barrett at oracle.com That changeset was pushed to JDK9-hs yesterday which means it should be in JDK9-dev next week (presuming all goes well with the weekend PIT of today's snapshot). Dan On 6/20/14 5:59 AM, Peter Levart wrote: > Hi, > > I get the following compile error when building on Fedora 20, 64 Bit: > > Compiling > /home/peter/work/hg/jdk9-dev/hotspot/src/share/vm/utilities/workgroup.cpp > Compiling > /home/peter/work/hg/jdk9-dev/hotspot/src/share/vm/utilities/xmlstream.cpp > Compiling > /home/peter/work/hg/jdk9-dev/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp > Making signal interposition lib... > Making SA debugger back-end... > In file included from > /home/peter/work/hg/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0, > from > /home/peter/work/hg/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30, > from > /home/peter/work/hg/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33: > /usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct > ptrace_peeksiginfo_args' > struct ptrace_peeksiginfo_args { > ^ > In file included from > /home/peter/work/hg/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0: > /usr/include/sys/ptrace.h:191:8: note: originally defined here > struct ptrace_peeksiginfo_args > ^ > gmake[6]: *** [libsaproc.so] Error 1 > gmake[6]: *** Waiting for unfinished jobs.... > gmake[5]: *** [the_vm] Error 2 > gmake[4]: *** [product] Error 2 > gmake[3]: *** [generic_build2] Error 2 > gmake[2]: *** [product] Error 2 > gmake[1]: *** > [/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make: *** [hotspot-only] Error 2 > > > ...it seems there are 2 definitions of "struct > ptrace_peeksiginfo_args" in 2 different system include files: > > /usr/include/linux/ptrace.h > /usr/include/sys/ptrace.h > > ...they are included by the following two hostpot files in > jdk9-dev/hotspot/agent/src/os/linux: > > libproc.h:#include > ps_proc.c:#include > > > Which one is the right one? > > Regards, Peter > From peter.levart at gmail.com Fri Jun 20 13:20:37 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 20 Jun 2014 15:20:37 +0200 Subject: Can't build jdk9-dev due to conflicting includes In-Reply-To: <53A434CB.6020804@oracle.com> References: <53A4220A.4010609@gmail.com> <53A434CB.6020804@oracle.com> Message-ID: <53A43525.5090403@gmail.com> On 06/20/2014 03:19 PM, Daniel D. Daugherty wrote: > Adding the Serviceability group since SA belongs to them... > > I believe that this issue is solved by this changeset: > > Changeset: 64e35dfa4ff5 > Author: jwilhelm > Date: 2014-06-13 17:07 -0400 > URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/64e35dfa4ff5 > > 8046408: Build failure from multiple ptrace.h > Summary: prefer over > Reviewed-by: sla, mikael > Contributed-by: kim.barrett at oracle.com > > > That changeset was pushed to JDK9-hs yesterday which means it > should be in JDK9-dev next week (presuming all goes well with > the weekend PIT of today's snapshot). Thanks, Dan. I can live with a local change until then. Regards, Peter > > Dan > > > On 6/20/14 5:59 AM, Peter Levart wrote: >> Hi, >> >> I get the following compile error when building on Fedora 20, 64 Bit: >> >> Compiling >> /home/peter/work/hg/jdk9-dev/hotspot/src/share/vm/utilities/workgroup.cpp >> Compiling >> /home/peter/work/hg/jdk9-dev/hotspot/src/share/vm/utilities/xmlstream.cpp >> Compiling >> /home/peter/work/hg/jdk9-dev/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp >> Making signal interposition lib... >> Making SA debugger back-end... >> In file included from >> /home/peter/work/hg/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0, >> from >> /home/peter/work/hg/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30, >> from >> /home/peter/work/hg/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33: >> /usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct >> ptrace_peeksiginfo_args' >> struct ptrace_peeksiginfo_args { >> ^ >> In file included from >> /home/peter/work/hg/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0: >> /usr/include/sys/ptrace.h:191:8: note: originally defined here >> struct ptrace_peeksiginfo_args >> ^ >> gmake[6]: *** [libsaproc.so] Error 1 >> gmake[6]: *** Waiting for unfinished jobs.... >> gmake[5]: *** [the_vm] Error 2 >> gmake[4]: *** [product] Error 2 >> gmake[3]: *** [generic_build2] Error 2 >> gmake[2]: *** [product] Error 2 >> gmake[1]: *** >> [/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >> Error 2 >> make: *** [hotspot-only] Error 2 >> >> >> ...it seems there are 2 definitions of "struct >> ptrace_peeksiginfo_args" in 2 different system include files: >> >> /usr/include/linux/ptrace.h >> /usr/include/sys/ptrace.h >> >> ...they are included by the following two hostpot files in >> jdk9-dev/hotspot/agent/src/os/linux: >> >> libproc.h:#include >> ps_proc.c:#include >> >> >> Which one is the right one? >> >> Regards, Peter >> > From staffan.larsen at oracle.com Mon Jun 23 08:33:56 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Jun 2014 10:33:56 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <09FCC0B8-CC24-488B-99C7-66D3D17267AE@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> <53A03CAB.6050206@oracle.com> <09D86058-1054-42C2-9689-7E6D4726A789@oracle.com> <09FCC0B8-CC24-488B-99C7-66D3D17267AE@oracle.com> Message-ID: Fancy! new review: http://cr.openjdk.java.net/~sla/8046883/webrev.01/ /Staffan On 18 jun 2014, at 13:59, Peter Allwin wrote: > This looks a lot better! > > (Since we?re using fancy new features we could use streams to find the connector instance) > > AttachingConnector ac = Bootstrap.virtualMachineManager().attachingConnectors() > .stream() > .filter(c -> c.name().equals("com.sun.jdi.ProcessAttach")) > .findFirst() > .orElseThrow(() -> new RuntimeException("Unable to locate ProcessAttachingConnector")); > > Thanks! > /peter > > On 17 Jun 2014, at 19:46, Staffan Larsen wrote: > >> Here is a rewrite of the test in Java instead of a shell script. Should be easier to maintain. >> >> webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ >> >> Thanks, >> /Staffan >> >> On 17 jun 2014, at 15:12, Staffan Larsen wrote: >> >>> >>> On 17 jun 2014, at 15:03, Alan Bateman wrote: >>> >>>> On 17/06/2014 13:35, Staffan Larsen wrote: >>>>> : >>>>> >>>>> It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. >>>>> >>>>> Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. >>>>> >>>>> >>>> Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. >>> >>> Ah, I see. I misunderstood your comment. >>> >>> I started looking at rewriting the test in pure Java instead of the shell script. With the new Process.getPid() this looks like the best approach. I?ll come back with a new review request soon. >>> >>> /Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Jun 23 08:40:30 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Jun 2014 10:40:30 +0200 Subject: RFR: 8044772 TempDirTest.java still times out with -Xcomp In-Reply-To: References: <53A0F3D2.1030605@oracle.com> Message-ID: Added printouts both before and after the test run: http://cr.openjdk.java.net/~sla/8044772/webrev.01/ Thanks, /Staffan On 18 jun 2014, at 08:59, Staffan Larsen wrote: > > On 18 jun 2014, at 04:05, David Holmes wrote: > >> Hi Staffan >> >> On 18/06/2014 4:30 AM, Staffan Larsen wrote: >>> This test launches four other VMs, thus taking a very long time to run with -Xcomp. The real change here is to increase the timeout of the test, but I have also added some logging so that it is possible to see for how far along the test has come if it times out. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8044772 >>> webrev: http://cr.openjdk.java.net/~sla/8044772/webrev.00/ >> >> I would have expected you to print out the elapsed time after running the tests rather than before. The initial printout would typically be zero. But no big deal. > > The test runs four times with different permutations. It often times out during one of the last permutations. I wanted to see how long time it took to get there. Maybe I should add timing both before and after the test, though. > > /S > >> >> David >> >> >> >>> Thanks, >>> /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jun 23 11:27:27 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Jun 2014 21:27:27 +1000 Subject: RFR: 8044772 TempDirTest.java still times out with -Xcomp In-Reply-To: References: <53A0F3D2.1030605@oracle.com> Message-ID: <53A80F1F.6030900@oracle.com> Looks fine. Thanks, David On 23/06/2014 6:40 PM, Staffan Larsen wrote: > Added printouts both before and after the test run: > http://cr.openjdk.java.net/~sla/8044772/webrev.01/ > > Thanks, > /Staffan > > On 18 jun 2014, at 08:59, Staffan Larsen > wrote: > >> >> On 18 jun 2014, at 04:05, David Holmes > > wrote: >> >>> Hi Staffan >>> >>> On 18/06/2014 4:30 AM, Staffan Larsen wrote: >>>> This test launches four other VMs, thus taking a very long time to >>>> run with -Xcomp. The real change here is to increase the timeout of >>>> the test, but I have also added some logging so that it is possible >>>> to see for how far along the test has come if it times out. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044772 >>>> webrev: http://cr.openjdk.java.net/~sla/8044772/webrev.00/ >>> >>> I would have expected you to print out the elapsed time after running >>> the tests rather than before. The initial printout would typically be >>> zero. But no big deal. >> >> The test runs four times with different permutations. It often times >> out during one of the last permutations. I wanted to see how long time >> it took to get there. Maybe I should add timing both before and after >> the test, though. >> >> /S >> >>> >>> David >>> >>> >>> >>>> Thanks, >>>> /Staffan > From markus.gronlund at oracle.com Mon Jun 23 15:02:40 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Mon, 23 Jun 2014 08:02:40 -0700 (PDT) Subject: RFR(S): 8047812: Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops Message-ID: <635a016d-fe91-4cc7-ac08-ce038536356c@default> Greetings, ? Kindly asking for reviews for the following change: ? Bug: https://bugs.openjdk.java.net/browse/JDK-8047812 Webrev: http://cr.openjdk.java.net/~mgronlun/8047812/webrev01 ? Description: The "8038212: Method::is_valid_method() check has performance regression ??impact for stackwalking" - changeset introduced a change in how the ClassLoaderDataGraph::_unloading list of ClassLoaderData's is purged. This change to the purging of the CLD's work the same as before for most GC's, but when using CMS GC, SystemDictionary::do_unloading() is called twice with no explicit purge call in between. On the second call (post-sweep), we can now get stale class loader oops delivered as part of the Klass closure callbacks from the _unloading list. Again, this is because there is no explicit purge call in between these two entries to SystemDictionary::do_unloading() - and being CMS and concurrent, it is very hard to accommodate a timely and proper purge call here. The first do_unloading call comes after CMS concurrent marking, and the second comes from a Full GC triggered while sweeping the CMS heap. This fix ensures the unloading purge mechanism to work correctly also for the CMS collector, in that only CLDs with non-reclaimed class loader oops will deliver klasses from the _unloading list. In addition, this will ensure a single "logical" pass is achieved when iterating the unloading list in-between purges (avoiding the processing of the same data twice). This fix is precipitated by nightly testing failures with CMS after the introduction of 8038212: Method::is_valid_method() check has performance regression ??impact for stackwalking" - for example "nsk/sysdict/vm/stress/jck12a//sysdictj12a008" which is crashing because of following up stale klass loader oop's from the ClassLoaderDataGraph::_unloading list. ? Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 24 00:20:23 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 23 Jun 2014 17:20:23 -0700 Subject: RFR(S): 8047812: Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops In-Reply-To: <635a016d-fe91-4cc7-ac08-ce038536356c@default> References: <635a016d-fe91-4cc7-ac08-ce038536356c@default> Message-ID: <53A8C447.8070103@oracle.com> Markus, It looks correct in general and the comments are good. However, it makes it a little bit more complex. I'd suggest to rename the "_saved_unloading" to something more meaningful. What about "_iterated_unloading", "_processed_unloading" or "_posted_unloading" ? No pressure, just some thinking. :) Thanks, Serguei On 6/23/14 8:02 AM, Markus Gr?nlund wrote: > Greetings, > > > > Kindly asking for reviews for the following change: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8047812 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8047812/webrev01 > > > > Description: > > The "8038212: Method::is_valid_method() check has performance regression > impact for stackwalking" - changeset introduced a change in how the ClassLoaderDataGraph::_unloading list of ClassLoaderData's is purged. > > This change to the purging of the CLD's work the same as before for most GC's, but when using CMS GC, SystemDictionary::do_unloading() is called twice with no explicit purge call in between. On the second call (post-sweep), we can now get stale class loader oops delivered as part of the Klass closure callbacks from the _unloading list. Again, this is because there is no explicit purge call in between these two entries to SystemDictionary::do_unloading() - and being CMS and concurrent, it is very hard to accommodate a timely and proper purge call here. > > The first do_unloading call comes after CMS concurrent marking, and the second comes from a Full GC triggered while sweeping the CMS heap. > > This fix ensures the unloading purge mechanism to work correctly also for the CMS collector, in that only CLDs with non-reclaimed class loader oops will deliver klasses from the _unloading list. In addition, this will ensure a single "logical" pass is achieved when iterating the unloading list in-between purges (avoiding the processing of the same data twice). > > This fix is precipitated by nightly testing failures with CMS after the introduction of 8038212: Method::is_valid_method() check has performance regression > impact for stackwalking" - for example "nsk/sysdict/vm/stress/jck12a//sysdictj12a008" which is crashing because of following up stale klass loader oop's from the ClassLoaderDataGraph::_unloading list. > > > > Thanks > > Markus From markus.gronlund at oracle.com Tue Jun 24 07:49:20 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Tue, 24 Jun 2014 00:49:20 -0700 (PDT) Subject: RFR(S): 8047812: Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops In-Reply-To: <53A8C447.8070103@oracle.com> References: <635a016d-fe91-4cc7-ac08-ce038536356c@default> <53A8C447.8070103@oracle.com> Message-ID: Hi Serguei, Thanks for taking a look and coming up with some suggestions on renaming the field. In regards to naming, I have followed the existing pattern for CMS support (see "_saved_head" field). As always on naming, I think it depends on which perspective you take: if you take the view of an outside consumer of the iterator function, then maybe "_processed_unloading" might be a useful name for the file (but this only as "processed" in regards to "delivered via callbacks" sense of the term). But, if we take the GC centric view (which this does since it add specialization for CMS GC), then the list is "saved" for by each GC thread enter until the point of purging. We have still not really reached the point where the rationale for this list (_unloading) in used - and that is during "purge" where all the CLDs reachable via the _unloading list are deallocated. So the other candidate I would consider would be something like "_previous_unloading", but this is close enough to "_saved_unloading". For these reasons I would suggest going with "_saved_unloading". Thanks for the suggestions though. /Markus -----Original Message----- From: Serguei Spitsyn Sent: den 24 juni 2014 02:20 To: Markus Gr?nlund; hotspot-runtime-dev; serviceability-dev Subject: Re: RFR(S): 8047812: Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops Markus, It looks correct in general and the comments are good. However, it makes it a little bit more complex. I'd suggest to rename the "_saved_unloading" to something more meaningful. What about "_iterated_unloading", "_processed_unloading" or "_posted_unloading" ? No pressure, just some thinking. :) Thanks, Serguei On 6/23/14 8:02 AM, Markus Gr?nlund wrote: > Greetings, > > > > Kindly asking for reviews for the following change: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8047812 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8047812/webrev01 > > > > Description: > > The "8038212: Method::is_valid_method() check has performance regression > impact for stackwalking" - changeset introduced a change in how the ClassLoaderDataGraph::_unloading list of ClassLoaderData's is purged. > > This change to the purging of the CLD's work the same as before for most GC's, but when using CMS GC, SystemDictionary::do_unloading() is called twice with no explicit purge call in between. On the second call (post-sweep), we can now get stale class loader oops delivered as part of the Klass closure callbacks from the _unloading list. Again, this is because there is no explicit purge call in between these two entries to SystemDictionary::do_unloading() - and being CMS and concurrent, it is very hard to accommodate a timely and proper purge call here. > > The first do_unloading call comes after CMS concurrent marking, and the second comes from a Full GC triggered while sweeping the CMS heap. > > This fix ensures the unloading purge mechanism to work correctly also for the CMS collector, in that only CLDs with non-reclaimed class loader oops will deliver klasses from the _unloading list. In addition, this will ensure a single "logical" pass is achieved when iterating the unloading list in-between purges (avoiding the processing of the same data twice). > > This fix is precipitated by nightly testing failures with CMS after the introduction of 8038212: Method::is_valid_method() check has performance regression > impact for stackwalking" - for example "nsk/sysdict/vm/stress/jck12a//sysdictj12a008" which is crashing because of following up stale klass loader oop's from the ClassLoaderDataGraph::_unloading list. > > > > Thanks > > Markus From serguei.spitsyn at oracle.com Tue Jun 24 07:58:37 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 Jun 2014 00:58:37 -0700 Subject: RFR(S): 8047812: Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops In-Reply-To: References: <635a016d-fe91-4cc7-ac08-ce038536356c@default> <53A8C447.8070103@oracle.com> Message-ID: <53A92FAD.4030602@oracle.com> Hi Markus, I'm Ok with the "_saved_unloading" if you prefer it. Thanks! Serguei On 6/24/14 12:49 AM, Markus Gr?nlund wrote: > Hi Serguei, > > Thanks for taking a look and coming up with some suggestions on renaming the field. > > In regards to naming, I have followed the existing pattern for CMS support (see "_saved_head" field). > > As always on naming, I think it depends on which perspective you take: if you take the view of an outside consumer of the iterator function, then maybe "_processed_unloading" might be a useful name for the file (but this only as "processed" in regards to "delivered via callbacks" sense of the term). > > But, if we take the GC centric view (which this does since it add specialization for CMS GC), then the list is "saved" for by each GC thread enter until the point of purging. We have still not really reached the point where the rationale for this list (_unloading) in used - and that is during "purge" where all the CLDs reachable via the _unloading list are deallocated. > > So the other candidate I would consider would be something like "_previous_unloading", but this is close enough to "_saved_unloading". > > For these reasons I would suggest going with "_saved_unloading". > > Thanks for the suggestions though. > > /Markus > > > -----Original Message----- > From: Serguei Spitsyn > Sent: den 24 juni 2014 02:20 > To: Markus Gr?nlund; hotspot-runtime-dev; serviceability-dev > Subject: Re: RFR(S): 8047812: Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops > > Markus, > > It looks correct in general and the comments are good. > > However, it makes it a little bit more complex. > I'd suggest to rename the "_saved_unloading" to something more meaningful. > What about "_iterated_unloading", "_processed_unloading" or "_posted_unloading" ? > No pressure, just some thinking. :) > > Thanks, > Serguei > > On 6/23/14 8:02 AM, Markus Gr?nlund wrote: >> Greetings, >> >> >> >> Kindly asking for reviews for the following change: >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8047812 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8047812/webrev01 >> >> >> >> Description: >> >> The "8038212: Method::is_valid_method() check has performance regression >> impact for stackwalking" - changeset introduced a change in how the ClassLoaderDataGraph::_unloading list of ClassLoaderData's is purged. >> >> This change to the purging of the CLD's work the same as before for most GC's, but when using CMS GC, SystemDictionary::do_unloading() is called twice with no explicit purge call in between. On the second call (post-sweep), we can now get stale class loader oops delivered as part of the Klass closure callbacks from the _unloading list. Again, this is because there is no explicit purge call in between these two entries to SystemDictionary::do_unloading() - and being CMS and concurrent, it is very hard to accommodate a timely and proper purge call here. >> >> The first do_unloading call comes after CMS concurrent marking, and the second comes from a Full GC triggered while sweeping the CMS heap. >> >> This fix ensures the unloading purge mechanism to work correctly also for the CMS collector, in that only CLDs with non-reclaimed class loader oops will deliver klasses from the _unloading list. In addition, this will ensure a single "logical" pass is achieved when iterating the unloading list in-between purges (avoiding the processing of the same data twice). >> >> This fix is precipitated by nightly testing failures with CMS after the introduction of 8038212: Method::is_valid_method() check has performance regression >> impact for stackwalking" - for example "nsk/sysdict/vm/stress/jck12a//sysdictj12a008" which is crashing because of following up stale klass loader oop's from the ClassLoaderDataGraph::_unloading list. >> >> >> >> Thanks >> >> Markus From shanliang.jiang at oracle.com Tue Jun 24 08:30:29 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 24 Jun 2014 10:30:29 +0200 Subject: RFR 8038321: RMIConnector_NPETest.java can't start rmid if running on fastdebug or Solaris-sparc Message-ID: <53A93725.7010102@oracle.com> Hi, The test is to test a NPE during creating a JMX RMI server, but it got timeout when starting a RMID, the fix is to remove this timeout, it is not easy to have a reasonable timeout working for different testing machines, and the test is not implemented to test sun.rmi.server.Activation. bug: https://bugs.openjdk.java.net/browse/JDK-8038321 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038321/00/ Thanks, Shanliang From staffan.larsen at oracle.com Tue Jun 24 08:38:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 24 Jun 2014 10:38:07 +0200 Subject: RFR 8038321: RMIConnector_NPETest.java can't start rmid if running on fastdebug or Solaris-sparc In-Reply-To: <53A93725.7010102@oracle.com> References: <53A93725.7010102@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 24 jun 2014, at 10:30, shanliang wrote: > Hi, > > The test is to test a NPE during creating a JMX RMI server, but it got timeout when starting a RMID, the fix is to remove this timeout, it is not easy to have a reasonable timeout working for different testing machines, and the test is not implemented to test sun.rmi.server.Activation. > > bug: https://bugs.openjdk.java.net/browse/JDK-8038321 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038321/00/ > > Thanks, > Shanliang From jaroslav.bachorik at oracle.com Tue Jun 24 08:44:04 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 24 Jun 2014 10:44:04 +0200 Subject: RFR 8038321: RMIConnector_NPETest.java can't start rmid if running on fastdebug or Solaris-sparc In-Reply-To: <53A93725.7010102@oracle.com> References: <53A93725.7010102@oracle.com> Message-ID: <53A93A54.7070208@oracle.com> Looks fine! -JB- On 06/24/2014 10:30 AM, shanliang wrote: > Hi, > > The test is to test a NPE during creating a JMX RMI server, but it got > timeout when starting a RMID, the fix is to remove this timeout, it is > not easy to have a reasonable timeout working for different testing > machines, and the test is not implemented to test > sun.rmi.server.Activation. > > bug: https://bugs.openjdk.java.net/browse/JDK-8038321 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038321/00/ > > > Thanks, > Shanliang From staffan.larsen at oracle.com Tue Jun 24 11:12:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 24 Jun 2014 13:12:01 +0200 Subject: RFR: JDK-8047973 Quarantine compiler/ciReplay/* Message-ID: These tests keep being unstable in nightly testing (see JDK-8032226) so will have to be quarantined. Thanks, /Staffan diff --git a/test/compiler/ciReplay/TestSA.sh b/test/compiler/ciReplay/TestSA.sh --- a/test/compiler/ciReplay/TestSA.sh +++ b/test/compiler/ciReplay/TestSA.sh @@ -26,6 +26,7 @@ ## ## @test ## @bug 8011675 +## @ignore ## @summary testing of ciReplay with using generated by SA replay.txt ## @author igor.ignatyev at oracle.com ## @run shell TestSA.sh diff --git a/test/compiler/ciReplay/TestVM.sh b/test/compiler/ciReplay/TestVM.sh --- a/test/compiler/ciReplay/TestVM.sh +++ b/test/compiler/ciReplay/TestVM.sh @@ -26,6 +26,7 @@ ## ## @test ## @bug 8011675 +## @ignore ## @summary testing of ciReplay with using generated by VM replay.txt ## @author igor.ignatyev at oracle.com ## @run shell TestVM.sh diff --git a/test/compiler/ciReplay/TestVM_no_comp_level.sh b/test/compiler/ciReplay/TestVM_no_comp_level.sh --- a/test/compiler/ciReplay/TestVM_no_comp_level.sh +++ b/test/compiler/ciReplay/TestVM_no_comp_level.sh @@ -26,6 +26,7 @@ ## ## @test ## @bug 8011675 +## @ignore ## @summary testing of ciReplay with using generated by VM replay.txt w/o comp_level ## @author igor.ignatyev at oracle.com ## @run shell TestVM_no_comp_level.sh From erik.gahlin at oracle.com Tue Jun 24 12:19:15 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 24 Jun 2014 14:19:15 +0200 Subject: RFR(S): 8046783: Add hidden field to methods for event based tracing Message-ID: <53A96CC3.7070604@oracle.com> Hi, Could I have a review of a small metadata fix for event based tracing. A hidden field is added to the method metadata so it's possible to filter uninteresting methods by a tracing backend, i.e. methods annotated with j.l.i.Lambdaform$Hidden that show up in stack traces when using Nashorn. Webrev: http://cr.openjdk.java.net/~egahlin/8046783_1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8046783 Thanks Erik From erik.gahlin at oracle.com Tue Jun 24 12:22:59 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 24 Jun 2014 14:22:59 +0200 Subject: RFR 8038321: RMIConnector_NPETest.java can't start rmid if running on fastdebug or Solaris-sparc In-Reply-To: <53A93725.7010102@oracle.com> References: <53A93725.7010102@oracle.com> Message-ID: <53A96DA3.6000309@oracle.com> Looks good! Erik shanliang skrev 2014-06-24 10:30: > Hi, > > The test is to test a NPE during creating a JMX RMI server, but it got > timeout when starting a RMID, the fix is to remove this timeout, it is > not easy to have a reasonable timeout working for different testing > machines, and the test is not implemented to test > sun.rmi.server.Activation. > > bug: https://bugs.openjdk.java.net/browse/JDK-8038321 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038321/00/ > > > Thanks, > Shanliang From staffan.larsen at oracle.com Tue Jun 24 12:23:04 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 24 Jun 2014 14:23:04 +0200 Subject: RFR(S): 8046783: Add hidden field to methods for event based tracing In-Reply-To: <53A96CC3.7070604@oracle.com> References: <53A96CC3.7070604@oracle.com> Message-ID: <335B6F6B-3E6A-4604-B569-1CD0DDC2AC77@oracle.com> Looks good! Thanks, /Staffan On 24 jun 2014, at 14:19, Erik Gahlin wrote: > Hi, > > Could I have a review of a small metadata fix for event based tracing. > > A hidden field is added to the method metadata so it's possible to filter uninteresting methods by a tracing backend, i.e. methods annotated with j.l.i.Lambdaform$Hidden that show up in stack traces when using Nashorn. > > Webrev: > http://cr.openjdk.java.net/~egahlin/8046783_1/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8046783 > > Thanks > Erik > From markus.gronlund at oracle.com Tue Jun 24 13:40:29 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Tue, 24 Jun 2014 06:40:29 -0700 (PDT) Subject: RFR(S): 8046783: Add hidden field to methods for event based tracing In-Reply-To: <53A96CC3.7070604@oracle.com> References: <53A96CC3.7070604@oracle.com> Message-ID: <2fc2d422-2066-41b0-9d97-8176bee1a692@default> Looks good. /Markus -----Original Message----- From: Erik Gahlin Sent: den 24 juni 2014 14:19 To: Serviceability Dev Subject: RFR(S): 8046783: Add hidden field to methods for event based tracing Hi, Could I have a review of a small metadata fix for event based tracing. A hidden field is added to the method metadata so it's possible to filter uninteresting methods by a tracing backend, i.e. methods annotated with j.l.i.Lambdaform$Hidden that show up in stack traces when using Nashorn. Webrev: http://cr.openjdk.java.net/~egahlin/8046783_1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8046783 Thanks Erik From igor.ignatyev at oracle.com Tue Jun 24 12:45:42 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 24 Jun 2014 16:45:42 +0400 Subject: RFR: JDK-8047973 Quarantine compiler/ciReplay/* In-Reply-To: References: Message-ID: <53A972F6.2070006@oracle.com> Staffan, 1. '@ignore' should be followed by CR numbers 2. I doubt that TestVM* failures are related to JDK-8032226. these tests don't use SA agent, they rather fail due to JDK-8031978 Igor On 06/24/2014 03:12 PM, Staffan Larsen wrote: > These tests keep being unstable in nightly testing (see JDK-8032226) so will have to be quarantined. > > Thanks, > /Staffan > > > > diff --git a/test/compiler/ciReplay/TestSA.sh b/test/compiler/ciReplay/TestSA.sh > --- a/test/compiler/ciReplay/TestSA.sh > +++ b/test/compiler/ciReplay/TestSA.sh > @@ -26,6 +26,7 @@ > ## > ## @test > ## @bug 8011675 > +## @ignore > ## @summary testing of ciReplay with using generated by SA replay.txt > ## @author igor.ignatyev at oracle.com > ## @run shell TestSA.sh > diff --git a/test/compiler/ciReplay/TestVM.sh b/test/compiler/ciReplay/TestVM.sh > --- a/test/compiler/ciReplay/TestVM.sh > +++ b/test/compiler/ciReplay/TestVM.sh > @@ -26,6 +26,7 @@ > ## > ## @test > ## @bug 8011675 > +## @ignore > ## @summary testing of ciReplay with using generated by VM replay.txt > ## @author igor.ignatyev at oracle.com > ## @run shell TestVM.sh > diff --git a/test/compiler/ciReplay/TestVM_no_comp_level.sh b/test/compiler/ciReplay/TestVM_no_comp_level.sh > --- a/test/compiler/ciReplay/TestVM_no_comp_level.sh > +++ b/test/compiler/ciReplay/TestVM_no_comp_level.sh > @@ -26,6 +26,7 @@ > ## > ## @test > ## @bug 8011675 > +## @ignore > ## @summary testing of ciReplay with using generated by VM replay.txt w/o comp_level > ## @author igor.ignatyev at oracle.com > ## @run shell TestVM_no_comp_level.sh > From staffan.larsen at oracle.com Wed Jun 25 06:53:04 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 25 Jun 2014 08:53:04 +0200 Subject: RFR: JDK-8047973 Quarantine compiler/ciReplay/* In-Reply-To: <53A972F6.2070006@oracle.com> References: <53A972F6.2070006@oracle.com> Message-ID: <0C947CA1-88DE-4EA9-9BF2-BB9F72F388A3@oracle.com> On 24 jun 2014, at 14:45, Igor Ignatyev wrote: > Staffan, > > 1. '@ignore' should be followed by CR numbers Good catch - I have fixed that below. > 2. I doubt that TestVM* failures are related to JDK-8032226. these tests don't use SA agent, they rather fail due to JDK-8031978 You are right. There seems to be some confusion in the RULEs for these two CRs so they match incorrectly. I have added 8031978 or 8032226 as appropriate to the @ignores. /Staffan diff --git a/test/compiler/ciReplay/TestSA.sh b/test/compiler/ciReplay/TestSA.sh --- a/test/compiler/ciReplay/TestSA.sh +++ b/test/compiler/ciReplay/TestSA.sh @@ -26,6 +26,7 @@ ## ## @test ## @bug 8011675 +## @ignore 8032226, 8031978 ## @summary testing of ciReplay with using generated by SA replay.txt ## @author igor.ignatyev at oracle.com ## @run shell TestSA.sh diff --git a/test/compiler/ciReplay/TestVM.sh b/test/compiler/ciReplay/TestVM.sh --- a/test/compiler/ciReplay/TestVM.sh +++ b/test/compiler/ciReplay/TestVM.sh @@ -26,6 +26,7 @@ ## ## @test ## @bug 8011675 +## @ignore 8031978 ## @summary testing of ciReplay with using generated by VM replay.txt ## @author igor.ignatyev at oracle.com ## @run shell TestVM.sh diff --git a/test/compiler/ciReplay/TestVM_no_comp_level.sh b/test/compiler/ciReplay/TestVM_no_comp_level.sh --- a/test/compiler/ciReplay/TestVM_no_comp_level.sh +++ b/test/compiler/ciReplay/TestVM_no_comp_level.sh @@ -26,6 +26,7 @@ ## ## @test ## @bug 8011675 +## @ignore 8031978 ## @summary testing of ciReplay with using generated by VM replay.txt w/o comp_level ## @author igor.ignatyev at oracle.com ## @run shell TestVM_no_comp_level.sh > > Igor > > On 06/24/2014 03:12 PM, Staffan Larsen wrote: >> These tests keep being unstable in nightly testing (see JDK-8032226) so will have to be quarantined. >> >> Thanks, >> /Staffan >> >> >> >> diff --git a/test/compiler/ciReplay/TestSA.sh b/test/compiler/ciReplay/TestSA.sh >> --- a/test/compiler/ciReplay/TestSA.sh >> +++ b/test/compiler/ciReplay/TestSA.sh >> @@ -26,6 +26,7 @@ >> ## >> ## @test >> ## @bug 8011675 >> +## @ignore >> ## @summary testing of ciReplay with using generated by SA replay.txt >> ## @author igor.ignatyev at oracle.com >> ## @run shell TestSA.sh >> diff --git a/test/compiler/ciReplay/TestVM.sh b/test/compiler/ciReplay/TestVM.sh >> --- a/test/compiler/ciReplay/TestVM.sh >> +++ b/test/compiler/ciReplay/TestVM.sh >> @@ -26,6 +26,7 @@ >> ## >> ## @test >> ## @bug 8011675 >> +## @ignore >> ## @summary testing of ciReplay with using generated by VM replay.txt >> ## @author igor.ignatyev at oracle.com >> ## @run shell TestVM.sh >> diff --git a/test/compiler/ciReplay/TestVM_no_comp_level.sh b/test/compiler/ciReplay/TestVM_no_comp_level.sh >> --- a/test/compiler/ciReplay/TestVM_no_comp_level.sh >> +++ b/test/compiler/ciReplay/TestVM_no_comp_level.sh >> @@ -26,6 +26,7 @@ >> ## >> ## @test >> ## @bug 8011675 >> +## @ignore >> ## @summary testing of ciReplay with using generated by VM replay.txt w/o comp_level >> ## @author igor.ignatyev at oracle.com >> ## @run shell TestVM_no_comp_level.sh >> From markus.gronlund at oracle.com Wed Jun 25 11:58:17 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 25 Jun 2014 04:58:17 -0700 (PDT) Subject: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" Message-ID: <882452e7-0b02-414a-8a04-125737cb2faf@default> Greetings, ? Kindly looking for reviews for the following change: ? Bug: http://bugs.openjdk.java.net/browse/JDK-8039905 Webrev: http://cr.openjdk.java.net/~mgronlun/8039905/webrev01/ ? Description: ? JVMTI inspection code for following references makes use of a VM_HeapWalkOperation in order to follow-up root sets. ? In bug: ? https://bugs.openjdk.java.net/browse/JDK-8038624 - "interpretedVFrame::expressions() must respect InterpreterOopMap for liveness", it was found that the interpretedVFrame code had a discrepancy between basing length information from both asking the interpreter frame (which saw live expression slots for calls instructions) as well as the oop map (which did not).? ? The liveness decisions for a particular BCI should be based on what the oopmap gives, and that was done as of that bug (8038624). ? In that process, I added an assert in an attempt to validate certain assumptions, and this assert has triggered during nightly testing in some cases. ? I have therefore inspected the GC code which follow-up roots from an interpreted frame (please see frame::oops_interpreted_do() and InterpreterFrameClosure::do_offset() (in frame.cpp) for reference), and reworked ?InterpretedVFrame so that inspections for the locals and expression slots are done in the same way as the GC code (especially in regards to taking decisions on the InterpreterOopMap). ? I needed to use InterpreterOopMap from a const context, and this is why I have "constified" this class where needed, as well as making "number_of_entries()" a const public accessor (to easily reach oop_mask length info). ? Testing completed: ? nsk/jdi* tests (especially the problematic ones reported for 8039905) compiler/6507107/HeapWalkingTest ? Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 25 13:57:34 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 25 Jun 2014 06:57:34 -0700 Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check Message-ID: <53AAD54E.8090804@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8013942 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.1 Summary: This is a Nightly Stabilization issue. The problem is that the JVMTI GetLocalObject() function is hitting the assert as the type of the local at current bci is not T_OBJECT as expected. It is because this local is alive only in a narrow scope of one condition in the method but current bci is out of this csope. A fragment from the target method: static Class canonicalize(Class t, int how) { Class ct; <== The local if (t == Object.class) { // no change, ever } else if (!t.isPrimitive()) { switch (how) { case UNWRAP: ct = Wrapper.asPrimitiveType(t); <== Initialized here if (ct != t) return ct; break; case RAW_RETURN: case ERASE: return Object.class; } } else if (t == void.class) { <== The GetLocalObject() is called with bci in this block // no change, usually switch (how) { case RAW_RETURN: return int.class; case WRAP: return Void.class; } } else { . . . The local 'ct' is only alive in the block of condition "if (!t.isPrimitive())". However, it is dead local in the next block. The fix suggested in the webrev above is to use the oop_mask for the method's current bci. It tells when the local is dead in the scope of this bci. Return the JVMTI_ERROR_INVALID_SLOT error in such a case. The fix also includes the tweeks which are necessary to enable the InterpreterOopMap.is_dead() function in the product mode as it was originally defined only under "#ifdef ENABLE_ZAP_DEAD_LOCALS". This makes the code in the oopMapCache.?pp a little bit more simple. Testing: Running the failing tests: vm.mlvm.indy.func.jvmti In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and amd64 Thanks, Serguei From erik.gahlin at oracle.com Wed Jun 25 22:56:54 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 26 Jun 2014 00:56:54 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53A141B9.5000403@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> Message-ID: <53AB53B6.4020604@oracle.com> It didn't work. There's no termination notification, if I use Process#destroyForcibly(). I believe the hsperfdata file is left behind so it will not be able to detect that the process has died. Here is an updated version that renames some variable/methods. http://cr.openjdk.java.net/~egahlin/8028474_3/ Thanks Erik Erik Gahlin skrev 2014-06-18 09:37: > Didn't know about destroyForcibly(). I could try that. > > Erik > > Staffan Larsen skrev 18/06/14 09:26: >> Erik, >> >> How about using Process.destroyForcibly() as a means to terminate the >> process instead of using files for signaling? >> >> /Staffan >> >> On 17 jun 2014, at 23:13, Erik Gahlin > > wrote: >> >>> Yes, very weird >>> >>> Could have been that I needed the tools.jar in the child processes, >>> or it could have been something else. If I remember correctly, I got >>> a CNF that I didn't get with the shell script, but it was few months >>> back. >>> >>> Anyway, I retried with JPRT and now it works without the shell script. >>> >>> http://cr.openjdk.java.net/~egahlin/8028474_2/ >>> >>> Erik >>> >>> Staffan Larsen skrev 2014-06-16 13:49: >>>> >>>> On 16 jun 2014, at 12:32, Erik Gahlin >>> > wrote: >>>> >>>>> Yekaterina Kantserova skrev 13/06/14 12:59: >>>>>> Erik, >>>>>> >>>>>> is there some reason why we need to keep >>>>>> MonitorVmStartTerminate.sh? I've moved the JTreg header to >>>>>> MonitorVmStartTerminate.java >>>>> Hi Katja, >>>>> >>>>> That's how I did the test initially, and it works locally, but I >>>>> could never get it to work in JPRT without the shell script. I >>>>> believe the tools.jar is not on the class path. >>>> >>>> That is weird. I see other tests that depend in tools.jar and they >>>> work fine. >>>> >>>> /Staffan >>>> >>>> >>>>> >>>>> Erik >>>>>> >>>>>> /* >>>>>> * @test >>>>>> * @bug 4990825 >>>>>> * @summary attach to external but local JVM processes >>>>>> * @library /lib/testlibrary >>>>>> * @build jdk.testlibrary.* >>>>>> * @run main MonitorVmStartTerminate >>>>>> */ >>>>>> >>>>>> and the test works just fine. >>>>>> >>>>>> The JTreg run contains all pathes and system properties >>>>>> MonitorVmStartTerminate.sh tries to construct: >>>>>> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} >>>>>> -Dtest.classes=${TESTCLASSES} -classpath ${CP} >>>>>> MonitorVmStartTerminate >>>>>> >>>>>> See the log attached. >>>>>> >>>>>> Note *@build jdk.testlibrary.** instead of *@build >>>>>> jdk.testlibrary.ProcessTools* to make sure all testlibrary >>>>>> classes are compiled >>>>>> to the right place when running tests concurrently. >>>>>> >>>>>> Thanks, >>>>>> Katja (Not a Reviewer) >>>>>> >>>>>> >>>>>> >>>>>> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I have a review of a test that has been failing >>>>>>> intermittently. The test now uses files for synchronization >>>>>>> instead of waiting for a process that sleeps. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~egahlin/8028474/ >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>>>>>> >>>>>>> Description: >>>>>>> >>>>>>> The test starts ten Java processes, each with a unique id. >>>>>>> >>>>>>> Each process creates a file named after the id and then it >>>>>>> waits for >>>>>>> the test to remove the file, at which the Java process exits. >>>>>>> >>>>>>> The processes are monitored by the test to make sure notifications >>>>>>> are sent when processes are started/terminated. >>>>>>> >>>>>>> To avoid Java processes being left behind, in case of an >>>>>>> unexpected >>>>>>> failure, shutdown hooks are registered that remove files when >>>>>>> the test >>>>>>> exits. If files are not removed, i.e. due to a JVM crash, >>>>>>> the Java processes will exit themselves after 1000 s. >>>>>>> >>>>>>> Thanks >>>>>>> Erik >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Thu Jun 26 00:12:33 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 26 Jun 2014 02:12:33 +0200 Subject: RFR(S): 8047368: Remove oracle.jrockit.jfr from open package.access list Message-ID: <53AB6571.9@oracle.com> Hi, Could I have a review of a small fix that removes references to jfr from the package.access list. Bug: https://bugs.openjdk.java.net/browse/JDK-8047368 Webrev: http://cr.openjdk.java.net/~egahlin/8047368/ Thanks Erik From staffan.larsen at oracle.com Thu Jun 26 08:57:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 26 Jun 2014 10:57:50 +0200 Subject: RFR(S): 8047368: Remove oracle.jrockit.jfr from open package.access list In-Reply-To: <53AB6571.9@oracle.com> References: <53AB6571.9@oracle.com> Message-ID: <3533C9BC-A2DE-4227-94DD-DE70D41550FB@oracle.com> Looks good! Thanks, /Staffan On 26 jun 2014, at 02:12, Erik Gahlin wrote: > Hi, > > Could I have a review of a small fix that removes references to jfr from the package.access list. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8047368 > > Webrev: > http://cr.openjdk.java.net/~egahlin/8047368/ > > Thanks > Erik From staffan.larsen at oracle.com Thu Jun 26 11:22:13 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 26 Jun 2014 13:22:13 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53AB53B6.4020604@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> Message-ID: <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> Indentation around JavaProcess.getId() is weird. JavaProcess.getPid/setPid/pid do not appear to be used. JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis()) before the loop and for each iteration to determine if the timeout has expired (instead of "time+=100?)? nit: missing empty line before line 139, method releaseStarted(). /Staffan On 26 jun 2014, at 00:56, Erik Gahlin wrote: > It didn't work. > > There's no termination notification, if I use Process#destroyForcibly(). I believe the hsperfdata file is left behind so it will not be able to detect that the process has died. > > Here is an updated version that renames some variable/methods. > > http://cr.openjdk.java.net/~egahlin/8028474_3/ > > Thanks > Erik > > Erik Gahlin skrev 2014-06-18 09:37: >> Didn't know about destroyForcibly(). I could try that. >> >> Erik >> >> Staffan Larsen skrev 18/06/14 09:26: >>> Erik, >>> >>> How about using Process.destroyForcibly() as a means to terminate the process instead of using files for signaling? >>> >>> /Staffan >>> >>> On 17 jun 2014, at 23:13, Erik Gahlin wrote: >>> >>>> Yes, very weird >>>> >>>> Could have been that I needed the tools.jar in the child processes, or it could have been something else. If I remember correctly, I got a CNF that I didn't get with the shell script, but it was few months back. >>>> >>>> Anyway, I retried with JPRT and now it works without the shell script. >>>> >>>> http://cr.openjdk.java.net/~egahlin/8028474_2/ >>>> >>>> Erik >>>> >>>> Staffan Larsen skrev 2014-06-16 13:49: >>>>> >>>>> On 16 jun 2014, at 12:32, Erik Gahlin wrote: >>>>> >>>>>> Yekaterina Kantserova skrev 13/06/14 12:59: >>>>>>> Erik, >>>>>>> >>>>>>> is there some reason why we need to keep MonitorVmStartTerminate.sh? I've moved the JTreg header to MonitorVmStartTerminate.java >>>>>> Hi Katja, >>>>>> >>>>>> That's how I did the test initially, and it works locally, but I could never get it to work in JPRT without the shell script. I believe the tools.jar is not on the class path. >>>>> >>>>> That is weird. I see other tests that depend in tools.jar and they work fine. >>>>> >>>>> /Staffan >>>>> >>>>> >>>>>> >>>>>> Erik >>>>>>> >>>>>>> /* >>>>>>> * @test >>>>>>> * @bug 4990825 >>>>>>> * @summary attach to external but local JVM processes >>>>>>> * @library /lib/testlibrary >>>>>>> * @build jdk.testlibrary.* >>>>>>> * @run main MonitorVmStartTerminate >>>>>>> */ >>>>>>> >>>>>>> and the test works just fine. >>>>>>> >>>>>>> The JTreg run contains all pathes and system properties MonitorVmStartTerminate.sh tries to construct: >>>>>>> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >>>>>>> >>>>>>> See the log attached. >>>>>>> >>>>>>> Note @build jdk.testlibrary.* instead of @build jdk.testlibrary.ProcessTools to make sure all testlibrary classes are compiled >>>>>>> to the right place when running tests concurrently. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja (Not a Reviewer) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Could I have a review of a test that has been failing >>>>>>>> intermittently. The test now uses files for synchronization >>>>>>>> instead of waiting for a process that sleeps. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~egahlin/8028474/ >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>>>>>>> >>>>>>>> Description: >>>>>>>> >>>>>>>> The test starts ten Java processes, each with a unique id. >>>>>>>> >>>>>>>> Each process creates a file named after the id and then it waits for >>>>>>>> the test to remove the file, at which the Java process exits. >>>>>>>> >>>>>>>> The processes are monitored by the test to make sure notifications >>>>>>>> are sent when processes are started/terminated. >>>>>>>> >>>>>>>> To avoid Java processes being left behind, in case of an unexpected >>>>>>>> failure, shutdown hooks are registered that remove files when the test >>>>>>>> exits. If files are not removed, i.e. due to a JVM crash, >>>>>>>> the Java processes will exit themselves after 1000 s. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Erik >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanliang.jiang at oracle.com Thu Jun 26 13:15:47 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 26 Jun 2014 15:15:47 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently Message-ID: <53AC1D03.9080200@oracle.com> Hi, Today ProcessTools.executeProcess has the code: new OutputAnalyzer(pb.start()); and OutputAnalyzer constructor calls immediately: exitValue = process.exitValue(); the test got exception because the process did not end. So a direct solution for the test is not to call: ProcessTools.executeTestJvm(args); but: ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); Process process = pb.start(); process.waitFor(); OutputAnalyzer output = new OutputAnalyzer(process); here we do waiting: process.waitFor(); before constructing an OutputAnalyzer. ProcessTools is a tool class we may have same issue for other tests using this class. So we may need to improve the test library. bug: https://bugs.openjdk.java.net/browse/JDK-8031554 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ Thanks, Shanliang From jaroslav.bachorik at oracle.com Thu Jun 26 13:33:31 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 26 Jun 2014 15:33:31 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <53AC1D03.9080200@oracle.com> References: <53AC1D03.9080200@oracle.com> Message-ID: <53AC212B.1040101@oracle.com> Hi Shanliang, On 06/26/2014 03:15 PM, shanliang wrote: > Hi, > > Today ProcessTools.executeProcess has the code: > new OutputAnalyzer(pb.start()); > > and OutputAnalyzer constructor calls immediately: > exitValue = process.exitValue(); > > the test got exception because the process did not end. Are you sure about this? The OutputAnalyzer constructor, before calling process.exitValue(), calls ProcessTools.getOutput(process) which actually does process.waitFor() A probable explanation would be that process.waitFor() gets interrupted without the target process actually ending. Either the result of ProcessTools.getOutput() should be checked for null to detect this situation or ProcessTools.getOutput() should throw a more aggressive exception when waitFor() gets interrupted. -JB- > > So a direct solution for the test is not to call: > ProcessTools.executeTestJvm(args); > > but: > ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); > Process process = pb.start(); > process.waitFor(); > OutputAnalyzer output = new OutputAnalyzer(process); > > here we do waiting: > process.waitFor(); > before constructing an OutputAnalyzer. > > ProcessTools is a tool class we may have same issue for other tests > using this class. So we may need to improve the test library. > > bug: https://bugs.openjdk.java.net/browse/JDK-8031554 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ > > > Thanks, > Shanliang > From shanliang.jiang at oracle.com Thu Jun 26 15:24:53 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 26 Jun 2014 17:24:53 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <53AC212B.1040101@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> Message-ID: <53AC3B45.8010009@oracle.com> Jaroslav Bachorik wrote: > Hi Shanliang, > > On 06/26/2014 03:15 PM, shanliang wrote: >> Hi, >> >> Today ProcessTools.executeProcess has the code: >> new OutputAnalyzer(pb.start()); >> >> and OutputAnalyzer constructor calls immediately: >> exitValue = process.exitValue(); >> >> the test got exception because the process did not end. > > Are you sure about this? > > The OutputAnalyzer constructor, before calling process.exitValue(), > calls ProcessTools.getOutput(process) which actually does > process.waitFor() Good catch! > > A probable explanation would be that process.waitFor() gets > interrupted without the target process actually ending. > > Either the result of ProcessTools.getOutput() should be checked for > null to detect this situation or ProcessTools.getOutput() should throw > a more aggressive exception when waitFor() gets interrupted. It was possible beacause of an InterruptedException, but maybe a Process issue too. process.waitFor() was called by the test main thread, I am wondering who wanted to interrupt this thread? Not know why ProcessTools.getOutput() catches InterruptedException and then returns null, are there some other tests dependent to this behavior? otherwise better to not catch InterruptedException. I think to keep this modification, it will allow us to get more information if the bug is reproduced, if getting an InterruptedException then we need to do more investigation for why, if no exception then we may rise a question to process.waitFor(). Shanliang > > -JB- > >> >> So a direct solution for the test is not to call: >> ProcessTools.executeTestJvm(args); >> >> but: >> ProcessBuilder pb = >> ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); >> Process process = pb.start(); >> process.waitFor(); >> OutputAnalyzer output = new OutputAnalyzer(process); >> >> here we do waiting: >> process.waitFor(); >> before constructing an OutputAnalyzer. >> >> ProcessTools is a tool class we may have same issue for other tests >> using this class. So we may need to improve the test library. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8031554 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ >> >> >> Thanks, >> Shanliang >> > From vladimir.x.ivanov at oracle.com Thu Jun 26 22:02:05 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 27 Jun 2014 02:02:05 +0400 Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check In-Reply-To: <53AAD54E.8090804@oracle.com> References: <53AAD54E.8090804@oracle.com> Message-ID: <53AC985D.6080806@oracle.com> Looks good. Best regards, Vladimir Ivanov On 6/25/14 5:57 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8013942 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.1 > > > > Summary: > > This is a Nightly Stabilization issue. > > The problem is that the JVMTI GetLocalObject() function is hitting > the assert > as the type of the local at current bci is not T_OBJECT as expected. > It is because this local is alive only in a narrow scope of one > condition in the method but current bci is out of this csope. > > A fragment from the target method: > > static Class canonicalize(Class t, int how) { > Class ct; <== The local > if (t == Object.class) { > // no change, ever > } else if (!t.isPrimitive()) { > switch (how) { > case UNWRAP: > ct = Wrapper.asPrimitiveType(t); <== Initialized here > if (ct != t) return ct; > break; > case RAW_RETURN: > case ERASE: > return Object.class; > } > } else if (t == void.class) { <== The > GetLocalObject() is called with bci in this block > // no change, usually > switch (how) { > case RAW_RETURN: > return int.class; > case WRAP: > return Void.class; > } > } else { > . . . > > The local 'ct' is only alive in the block of condition "if > (!t.isPrimitive())". > However, it is dead local in the next block. > > The fix suggested in the webrev above is to use the oop_mask for the > method's current bci. > It tells when the local is dead in the scope of this bci. > Return the JVMTI_ERROR_INVALID_SLOT error in such a case. > > The fix also includes the tweeks which are necessary to enable the > InterpreterOopMap.is_dead() > function in the product mode as it was originally defined only under > "#ifdef ENABLE_ZAP_DEAD_LOCALS". > This makes the code in the oopMapCache.?pp a little bit more simple. > > > Testing: > Running the failing tests: vm.mlvm.indy.func.jvmti > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and amd64 > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Thu Jun 26 22:15:28 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 26 Jun 2014 15:15:28 -0700 Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check In-Reply-To: <53AC985D.6080806@oracle.com> References: <53AAD54E.8090804@oracle.com> <53AC985D.6080806@oracle.com> Message-ID: <53AC9B80.9030805@oracle.com> Thanks, Vladimir! Serguei On 6/26/14 3:02 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 6/25/14 5:57 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8013942 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.1 >> >> >> >> >> Summary: >> >> This is a Nightly Stabilization issue. >> >> The problem is that the JVMTI GetLocalObject() function is hitting >> the assert >> as the type of the local at current bci is not T_OBJECT as expected. >> It is because this local is alive only in a narrow scope of one >> condition in the method but current bci is out of this csope. >> >> A fragment from the target method: >> >> static Class canonicalize(Class t, int how) { >> Class ct; <== The local >> if (t == Object.class) { >> // no change, ever >> } else if (!t.isPrimitive()) { >> switch (how) { >> case UNWRAP: >> ct = Wrapper.asPrimitiveType(t); <== Initialized >> here >> if (ct != t) return ct; >> break; >> case RAW_RETURN: >> case ERASE: >> return Object.class; >> } >> } else if (t == void.class) { <== The >> GetLocalObject() is called with bci in this block >> // no change, usually >> switch (how) { >> case RAW_RETURN: >> return int.class; >> case WRAP: >> return Void.class; >> } >> } else { >> . . . >> >> The local 'ct' is only alive in the block of condition "if >> (!t.isPrimitive())". >> However, it is dead local in the next block. >> >> The fix suggested in the webrev above is to use the oop_mask for the >> method's current bci. >> It tells when the local is dead in the scope of this bci. >> Return the JVMTI_ERROR_INVALID_SLOT error in such a case. >> >> The fix also includes the tweeks which are necessary to enable the >> InterpreterOopMap.is_dead() >> function in the product mode as it was originally defined only under >> "#ifdef ENABLE_ZAP_DEAD_LOCALS". >> This makes the code in the oopMapCache.?pp a little bit more simple. >> >> >> Testing: >> Running the failing tests: vm.mlvm.indy.func.jvmti >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and >> amd64 >> >> >> Thanks, >> Serguei >> From markus.gronlund at oracle.com Fri Jun 27 08:12:23 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 27 Jun 2014 01:12:23 -0700 (PDT) Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check In-Reply-To: <53AC9B80.9030805@oracle.com> References: <53AAD54E.8090804@oracle.com> <53AC985D.6080806@oracle.com> <53AC9B80.9030805@oracle.com> Message-ID: Hi Serguei, I am not convinced this is the right way to do this - by removing the #ifdef ENABLE_ZAP_DEAD_LOCALS" (which is an COMPILER2 specific #define under an ASSERT), we have now unconditionally increased the bitsize for every oopmap entry to two (compared to one previously) - the inlined oop_map bits_size cache is predefined to hold two words. This means the oopmap bitmap cache is effectively halved unconditionally. /Markus -----Original Message----- From: Serguei Spitsyn Sent: den 27 juni 2014 00:15 To: Vladimir Ivanov; hotspot-dev at openjdk.java.net Developers; serviceability-dev at openjdk.java.net Subject: Re: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check Thanks, Vladimir! Serguei On 6/26/14 3:02 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 6/25/14 5:57 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8013942 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVM >> TI-lobj.1 >> >> >> >> >> Summary: >> >> This is a Nightly Stabilization issue. >> >> The problem is that the JVMTI GetLocalObject() function is hitting >> the assert >> as the type of the local at current bci is not T_OBJECT as expected. >> It is because this local is alive only in a narrow scope of one >> condition in the method but current bci is out of this csope. >> >> A fragment from the target method: >> >> static Class canonicalize(Class t, int how) { >> Class ct; <== The local >> if (t == Object.class) { >> // no change, ever >> } else if (!t.isPrimitive()) { >> switch (how) { >> case UNWRAP: >> ct = Wrapper.asPrimitiveType(t); <== Initialized >> here >> if (ct != t) return ct; >> break; >> case RAW_RETURN: >> case ERASE: >> return Object.class; >> } >> } else if (t == void.class) { <== The >> GetLocalObject() is called with bci in this block >> // no change, usually >> switch (how) { >> case RAW_RETURN: >> return int.class; >> case WRAP: >> return Void.class; >> } >> } else { >> . . . >> >> The local 'ct' is only alive in the block of condition "if >> (!t.isPrimitive())". >> However, it is dead local in the next block. >> >> The fix suggested in the webrev above is to use the oop_mask for >> the method's current bci. >> It tells when the local is dead in the scope of this bci. >> Return the JVMTI_ERROR_INVALID_SLOT error in such a case. >> >> The fix also includes the tweeks which are necessary to enable the >> InterpreterOopMap.is_dead() >> function in the product mode as it was originally defined only >> under "#ifdef ENABLE_ZAP_DEAD_LOCALS". >> This makes the code in the oopMapCache.?pp a little bit more simple. >> >> >> Testing: >> Running the failing tests: vm.mlvm.indy.func.jvmti >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and >> amd64 >> >> >> Thanks, >> Serguei >> From serguei.spitsyn at oracle.com Fri Jun 27 08:34:23 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 27 Jun 2014 01:34:23 -0700 Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check In-Reply-To: References: <53AAD54E.8090804@oracle.com> <53AC985D.6080806@oracle.com> <53AC9B80.9030805@oracle.com> Message-ID: <53AD2C8F.9090702@oracle.com> Hi Markus, I raised a good point, thanks! What do you think about increasing the predefined size (N from 2 to 4)? 64 class InterpreterOopMap: ResourceObj { 65 friend class OopMapCache; 66 67 public: 68 enum { 69 N = 2, // the number of words reserved 70 // for inlined mask storage 71 small_mask_limit = N * BitsPerWord, // the maximum number of bits 72 // available for small masks, 73 // small_mask_limit can be set to 0 74 // for testing bit_mask allocation Thanks, Serguei On 6/27/14 1:12 AM, Markus Gr?nlund wrote: > Hi Serguei, > > > I am not convinced this is the right way to do this - by removing the #ifdef ENABLE_ZAP_DEAD_LOCALS" (which is an COMPILER2 specific #define under an ASSERT), we have now unconditionally increased the bitsize for every oopmap entry to two (compared to one previously) - the inlined oop_map bits_size cache is predefined to hold two words. > > This means the oopmap bitmap cache is effectively halved unconditionally. > > /Markus > > > -----Original Message----- > From: Serguei Spitsyn > Sent: den 27 juni 2014 00:15 > To: Vladimir Ivanov; hotspot-dev at openjdk.java.net Developers; serviceability-dev at openjdk.java.net > Subject: Re: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check > > Thanks, Vladimir! > Serguei > > On 6/26/14 3:02 PM, Vladimir Ivanov wrote: >> Looks good. >> >> Best regards, >> Vladimir Ivanov >> >> On 6/25/14 5:57 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8013942 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVM >>> TI-lobj.1 >>> >>> >>> >>> >>> Summary: >>> >>> This is a Nightly Stabilization issue. >>> >>> The problem is that the JVMTI GetLocalObject() function is hitting >>> the assert >>> as the type of the local at current bci is not T_OBJECT as expected. >>> It is because this local is alive only in a narrow scope of one >>> condition in the method but current bci is out of this csope. >>> >>> A fragment from the target method: >>> >>> static Class canonicalize(Class t, int how) { >>> Class ct; <== The local >>> if (t == Object.class) { >>> // no change, ever >>> } else if (!t.isPrimitive()) { >>> switch (how) { >>> case UNWRAP: >>> ct = Wrapper.asPrimitiveType(t); <== Initialized >>> here >>> if (ct != t) return ct; >>> break; >>> case RAW_RETURN: >>> case ERASE: >>> return Object.class; >>> } >>> } else if (t == void.class) { <== The >>> GetLocalObject() is called with bci in this block >>> // no change, usually >>> switch (how) { >>> case RAW_RETURN: >>> return int.class; >>> case WRAP: >>> return Void.class; >>> } >>> } else { >>> . . . >>> >>> The local 'ct' is only alive in the block of condition "if >>> (!t.isPrimitive())". >>> However, it is dead local in the next block. >>> >>> The fix suggested in the webrev above is to use the oop_mask for >>> the method's current bci. >>> It tells when the local is dead in the scope of this bci. >>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case. >>> >>> The fix also includes the tweeks which are necessary to enable the >>> InterpreterOopMap.is_dead() >>> function in the product mode as it was originally defined only >>> under "#ifdef ENABLE_ZAP_DEAD_LOCALS". >>> This makes the code in the oopMapCache.?pp a little bit more simple. >>> >>> >>> Testing: >>> Running the failing tests: vm.mlvm.indy.func.jvmti >>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and >>> amd64 >>> >>> >>> Thanks, >>> Serguei >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Jun 27 08:48:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 27 Jun 2014 10:48:43 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <53AC3B45.8010009@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> <53AC3B45.8010009@oracle.com> Message-ID: <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> It does look suspicious to catch and ignore the InterruptedException, especially since the OutputAnalyzer constructor will fail in this case. Christian is the original author of these classes: do you know if there is a good rationale for doing this? Or should we propagate the InterruptedException? Thanks, /Staffan On 26 jun 2014, at 17:24, shanliang wrote: > Jaroslav Bachorik wrote: >> Hi Shanliang, >> >> On 06/26/2014 03:15 PM, shanliang wrote: >>> Hi, >>> >>> Today ProcessTools.executeProcess has the code: >>> new OutputAnalyzer(pb.start()); >>> >>> and OutputAnalyzer constructor calls immediately: >>> exitValue = process.exitValue(); >>> >>> the test got exception because the process did not end. >> >> Are you sure about this? >> >> The OutputAnalyzer constructor, before calling process.exitValue(), calls ProcessTools.getOutput(process) which actually does process.waitFor() > Good catch! >> >> A probable explanation would be that process.waitFor() gets interrupted without the target process actually ending. >> >> Either the result of ProcessTools.getOutput() should be checked for null to detect this situation or ProcessTools.getOutput() should throw a more aggressive exception when waitFor() gets interrupted. > It was possible beacause of an InterruptedException, but maybe a Process issue too. > > process.waitFor() was called by the test main thread, I am wondering who wanted to interrupt this thread? > > Not know why ProcessTools.getOutput() catches InterruptedException and then returns null, are there some other tests dependent to this behavior? otherwise better to not catch InterruptedException. > > I think to keep this modification, it will allow us to get more information if the bug is reproduced, if getting an InterruptedException then we need to do more investigation for why, if no exception then we may rise a question to process.waitFor(). > > Shanliang >> >> -JB- >> >>> >>> So a direct solution for the test is not to call: >>> ProcessTools.executeTestJvm(args); >>> >>> but: >>> ProcessBuilder pb = >>> ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); >>> Process process = pb.start(); >>> process.waitFor(); >>> OutputAnalyzer output = new OutputAnalyzer(process); >>> >>> here we do waiting: >>> process.waitFor(); >>> before constructing an OutputAnalyzer. >>> >>> ProcessTools is a tool class we may have same issue for other tests >>> using this class. So we may need to improve the test library. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8031554 >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ >>> >>> >>> Thanks, >>> Shanliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jun 27 08:53:34 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 27 Jun 2014 01:53:34 -0700 Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check In-Reply-To: <53AD2C8F.9090702@oracle.com> References: <53AAD54E.8090804@oracle.com> <53AC985D.6080806@oracle.com> <53AC9B80.9030805@oracle.com> <53AD2C8F.9090702@oracle.com> Message-ID: <53AD310E.1010200@oracle.com> On 6/27/14 1:34 AM, serguei.spitsyn at oracle.com wrote: > Hi Markus, > > I raised a good point, thanks! Sorry, I wanted to say: "You raised a good point!" :) > What do you think about increasing the predefined size (N from 2 to 4)? > > 64 class InterpreterOopMap: ResourceObj { > 65 friend class OopMapCache; > 66 > 67 public: > 68 enum { > 69 N = 2, // the number of words reserved > 70 // for inlined mask storage > 71 small_mask_limit = N * BitsPerWord, // the maximum number of bits > 72 // available for small masks, > 73 // small_mask_limit can be set to 0 > 74 // for testing bit_mask allocation > > > Thanks, > Serguei > > On 6/27/14 1:12 AM, Markus Gr?nlund wrote: >> Hi Serguei, >> >> >> I am not convinced this is the right way to do this - by removing the #ifdef ENABLE_ZAP_DEAD_LOCALS" (which is an COMPILER2 specific #define under an ASSERT), we have now unconditionally increased the bitsize for every oopmap entry to two (compared to one previously) - the inlined oop_map bits_size cache is predefined to hold two words. >> >> This means the oopmap bitmap cache is effectively halved unconditionally. >> >> /Markus >> >> >> -----Original Message----- >> From: Serguei Spitsyn >> Sent: den 27 juni 2014 00:15 >> To: Vladimir Ivanov;hotspot-dev at openjdk.java.net Developers;serviceability-dev at openjdk.java.net >> Subject: Re: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check >> >> Thanks, Vladimir! >> Serguei >> >> On 6/26/14 3:02 PM, Vladimir Ivanov wrote: >>> Looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 6/25/14 5:57 PM,serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8013942 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVM >>>> TI-lobj.1 >>>> >>>> >>>> >>>> >>>> Summary: >>>> >>>> This is a Nightly Stabilization issue. >>>> >>>> The problem is that the JVMTI GetLocalObject() function is hitting >>>> the assert >>>> as the type of the local at current bci is not T_OBJECT as expected. >>>> It is because this local is alive only in a narrow scope of one >>>> condition in the method but current bci is out of this csope. >>>> >>>> A fragment from the target method: >>>> >>>> static Class canonicalize(Class t, int how) { >>>> Class ct; <== The local >>>> if (t == Object.class) { >>>> // no change, ever >>>> } else if (!t.isPrimitive()) { >>>> switch (how) { >>>> case UNWRAP: >>>> ct = Wrapper.asPrimitiveType(t); <== Initialized >>>> here >>>> if (ct != t) return ct; >>>> break; >>>> case RAW_RETURN: >>>> case ERASE: >>>> return Object.class; >>>> } >>>> } else if (t == void.class) { <== The >>>> GetLocalObject() is called with bci in this block >>>> // no change, usually >>>> switch (how) { >>>> case RAW_RETURN: >>>> return int.class; >>>> case WRAP: >>>> return Void.class; >>>> } >>>> } else { >>>> . . . >>>> >>>> The local 'ct' is only alive in the block of condition "if >>>> (!t.isPrimitive())". >>>> However, it is dead local in the next block. >>>> >>>> The fix suggested in the webrev above is to use the oop_mask for >>>> the method's current bci. >>>> It tells when the local is dead in the scope of this bci. >>>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case. >>>> >>>> The fix also includes the tweeks which are necessary to enable the >>>> InterpreterOopMap.is_dead() >>>> function in the product mode as it was originally defined only >>>> under "#ifdef ENABLE_ZAP_DEAD_LOCALS". >>>> This makes the code in the oopMapCache.?pp a little bit more simple. >>>> >>>> >>>> Testing: >>>> Running the failing tests: vm.mlvm.indy.func.jvmti >>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and >>>> amd64 >>>> >>>> >>>> Thanks, >>>> Serguei >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.tornqvist at oracle.com Fri Jun 27 13:50:50 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 27 Jun 2014 09:50:50 -0400 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> <53AC3B45.8010009@oracle.com> <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> Message-ID: <0d1001cf920e$cff48620$6fdd9260$@oracle.com> I can't remember if there was a reason for doing it like this, but it seems reasonable to not catch the InterruptedException in getOutput(). Thanks, Christian From: Staffan Larsen [mailto:staffan.larsen at oracle.com] Sent: Friday, June 27, 2014 4:49 AM To: shanliang Cc: Jaroslav Bachorik; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; Christian Tornqvist Subject: Re: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently It does look suspicious to catch and ignore the InterruptedException, especially since the OutputAnalyzer constructor will fail in this case. Christian is the original author of these classes: do you know if there is a good rationale for doing this? Or should we propagate the InterruptedException? Thanks, /Staffan On 26 jun 2014, at 17:24, shanliang > wrote: Jaroslav Bachorik wrote: Hi Shanliang, On 06/26/2014 03:15 PM, shanliang wrote: Hi, Today ProcessTools.executeProcess has the code: new OutputAnalyzer(pb.start()); and OutputAnalyzer constructor calls immediately: exitValue = process.exitValue(); the test got exception because the process did not end. Are you sure about this? The OutputAnalyzer constructor, before calling process.exitValue(), calls ProcessTools.getOutput(process) which actually does process.waitFor() Good catch! A probable explanation would be that process.waitFor() gets interrupted without the target process actually ending. Either the result of ProcessTools.getOutput() should be checked for null to detect this situation or ProcessTools.getOutput() should throw a more aggressive exception when waitFor() gets interrupted. It was possible beacause of an InterruptedException, but maybe a Process issue too. process.waitFor() was called by the test main thread, I am wondering who wanted to interrupt this thread? Not know why ProcessTools.getOutput() catches InterruptedException and then returns null, are there some other tests dependent to this behavior? otherwise better to not catch InterruptedException. I think to keep this modification, it will allow us to get more information if the bug is reproduced, if getting an InterruptedException then we need to do more investigation for why, if no exception then we may rise a question to process.waitFor(). Shanliang -JB- So a direct solution for the test is not to call: ProcessTools.executeTestJvm(args); but: ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); Process process = pb.start(); process.waitFor(); OutputAnalyzer output = new OutputAnalyzer(process); here we do waiting: process.waitFor(); before constructing an OutputAnalyzer. ProcessTools is a tool class we may have same issue for other tests using this class. So we may need to improve the test library. bug: https://bugs.openjdk.java.net/browse/JDK-8031554 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ Thanks, Shanliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Jun 27 16:18:17 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 27 Jun 2014 10:18:17 -0600 Subject: RFR (XS) fix for a safepoint deadlock (8047720) Message-ID: <53AD9949.9030601@oracle.com> Greetings, I have a fix ready for the following bug: 8047720 Xprof hangs on Solaris https://bugs.openjdk.java.net/browse/JDK-8047720 Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ This deadlock occurred between the following threads: Main thread - Trying to stop the WatcherThread as part of shutting down the VM; this thread is blocked on the PeriodicTask_lock which keeps it from reaching a safepoint. WatcherThread - Requested a VM_ForceSafepoint to complete a JavaThread::java_suspend() call as part of a FlatProfiler record_thread_ticks() call; this thread owns the PeriodicTask_lock since it is processing a periodic task. VMThread - Trying to start a safepoint; this thread is blocked waiting for the Main thread to reach a safepoint. The PeriodicTask_lock is one of the VM internal locks and is typically managed using Mutex::_no_safepoint_check_flag to avoid deadlocks. Yes, the irony is dripping on the floor... :-) The interesting part of this deadlock is that I think that it is possible for other periodic tasks to hit it. Anything that causes the WatcherThread to start a safepoint while processing a periodic task should be susceptible to this race. Think about the -XX:+DeoptimizeALot option and how it causes VM_Deopt requests on thread state transitions... Interesting... Testing: - I found a way to add delays to the right spots in the VM to make the deadlock reproduce in just about every run of the test associated with the bug. The new os::naked_short_sleep() function is your friend. Thanks to Fred for adding that! See the bug report for the debugging diffs. - 72 hours of running the test in the bug report with delays enabled for product, fastdebug and jvmg bits in parallel on my Solaris X86 server. - JPRT test run - Aurora Adhoc results are in process; we're having issues with both a broken testbase build and infra problems with results not being uploaded. From markus.gronlund at oracle.com Fri Jun 27 17:46:03 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 27 Jun 2014 10:46:03 -0700 (PDT) Subject: RFR (XS) fix for a safepoint deadlock (8047720) In-Reply-To: <53AD9949.9030601@oracle.com> References: <53AD9949.9030601@oracle.com> Message-ID: <9d8d88b0-df16-4137-a658-4ac8d2e461f2@default> Hi Dan, This looks good, thanks for chasing this down! Cheers Markus -----Original Message----- From: Daniel D. Daugherty Sent: den 27 juni 2014 18:18 To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: RFR (XS) fix for a safepoint deadlock (8047720) Greetings, I have a fix ready for the following bug: 8047720 Xprof hangs on Solaris https://bugs.openjdk.java.net/browse/JDK-8047720 Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ This deadlock occurred between the following threads: Main thread - Trying to stop the WatcherThread as part of shutting down the VM; this thread is blocked on the PeriodicTask_lock which keeps it from reaching a safepoint. WatcherThread - Requested a VM_ForceSafepoint to complete a JavaThread::java_suspend() call as part of a FlatProfiler record_thread_ticks() call; this thread owns the PeriodicTask_lock since it is processing a periodic task. VMThread - Trying to start a safepoint; this thread is blocked waiting for the Main thread to reach a safepoint. The PeriodicTask_lock is one of the VM internal locks and is typically managed using Mutex::_no_safepoint_check_flag to avoid deadlocks. Yes, the irony is dripping on the floor... :-) The interesting part of this deadlock is that I think that it is possible for other periodic tasks to hit it. Anything that causes the WatcherThread to start a safepoint while processing a periodic task should be susceptible to this race. Think about the -XX:+DeoptimizeALot option and how it causes VM_Deopt requests on thread state transitions... Interesting... Testing: - I found a way to add delays to the right spots in the VM to make the deadlock reproduce in just about every run of the test associated with the bug. The new os::naked_short_sleep() function is your friend. Thanks to Fred for adding that! See the bug report for the debugging diffs. - 72 hours of running the test in the bug report with delays enabled for product, fastdebug and jvmg bits in parallel on my Solaris X86 server. - JPRT test run - Aurora Adhoc results are in process; we're having issues with both a broken testbase build and infra problems with results not being uploaded. From daniel.daugherty at oracle.com Fri Jun 27 17:46:00 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 27 Jun 2014 11:46:00 -0600 Subject: RFR (XS) fix for a safepoint deadlock (8047720) In-Reply-To: <9d8d88b0-df16-4137-a658-4ac8d2e461f2@default> References: <53AD9949.9030601@oracle.com> <9d8d88b0-df16-4137-a658-4ac8d2e461f2@default> Message-ID: <53ADADD8.1060506@oracle.com> Markus, Thanks for the fast review! Dan On 6/27/14 11:46 AM, Markus Gr?nlund wrote: > Hi Dan, > > This looks good, thanks for chasing this down! > > Cheers > Markus > > > > -----Original Message----- > From: Daniel D. Daugherty > Sent: den 27 juni 2014 18:18 > To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Subject: RFR (XS) fix for a safepoint deadlock (8047720) > > Greetings, > > I have a fix ready for the following bug: > > 8047720 Xprof hangs on Solaris > https://bugs.openjdk.java.net/browse/JDK-8047720 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ > > This deadlock occurred between the following threads: > > Main thread - Trying to stop the WatcherThread as part of > shutting down the VM; this thread is blocked > on the PeriodicTask_lock which keeps it from > reaching a safepoint. > WatcherThread - Requested a VM_ForceSafepoint to complete > a JavaThread::java_suspend() call as part > of a FlatProfiler record_thread_ticks() > call; this thread owns the PeriodicTask_lock > since it is processing a periodic task. > VMThread - Trying to start a safepoint; this thread is > blocked waiting for the Main thread to reach > a safepoint. > > The PeriodicTask_lock is one of the VM internal locks and is typically managed using Mutex::_no_safepoint_check_flag to avoid deadlocks. Yes, the irony is dripping on the floor... :-) > > The interesting part of this deadlock is that I think that it is possible for other periodic tasks to hit it. Anything that causes the WatcherThread to start a safepoint while processing a periodic task should be susceptible to this race. Think about the -XX:+DeoptimizeALot option and how it causes VM_Deopt requests on thread state transitions... Interesting... > > Testing: > - I found a way to add delays to the right spots in the > VM to make the deadlock reproduce in just about every > run of the test associated with the bug. The new > os::naked_short_sleep() function is your friend. Thanks > to Fred for adding that! See the bug report for the > debugging diffs. > - 72 hours of running the test in the bug report with > delays enabled for product, fastdebug and jvmg bits > in parallel on my Solaris X86 server. > - JPRT test run > - Aurora Adhoc results are in process; we're having issues > with both a broken testbase build and infra problems > with results not being uploaded. > From daniel.daugherty at oracle.com Fri Jun 27 20:27:26 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 27 Jun 2014 14:27:26 -0600 Subject: RFR (XS) fix for a safepoint deadlock (8047720) In-Reply-To: <53ADD1E3.7070109@oracle.com> References: <53AD9949.9030601@oracle.com> <53ADD1E3.7070109@oracle.com> Message-ID: <53ADD3AE.8080006@oracle.com> Thanks for the review! Dan On 6/27/14 2:19 PM, Coleen Phillimore wrote: > > This looks good. Good to track down this deadlock! > Coleen > > On 6/27/14, 12:18 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix ready for the following bug: >> >> 8047720 Xprof hangs on Solaris >> https://bugs.openjdk.java.net/browse/JDK-8047720 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ >> >> This deadlock occurred between the following threads: >> >> Main thread - Trying to stop the WatcherThread as part of >> shutting down the VM; this thread is blocked >> on the PeriodicTask_lock which keeps it from >> reaching a safepoint. >> WatcherThread - Requested a VM_ForceSafepoint to complete >> a JavaThread::java_suspend() call as part >> of a FlatProfiler record_thread_ticks() >> call; this thread owns the PeriodicTask_lock >> since it is processing a periodic task. >> VMThread - Trying to start a safepoint; this thread is >> blocked waiting for the Main thread to reach >> a safepoint. >> >> The PeriodicTask_lock is one of the VM internal locks and is >> typically managed using Mutex::_no_safepoint_check_flag to >> avoid deadlocks. Yes, the irony is dripping on the floor... :-) >> >> The interesting part of this deadlock is that I think that it >> is possible for other periodic tasks to hit it. Anything that >> causes the WatcherThread to start a safepoint while processing >> a periodic task should be susceptible to this race. Think about >> the -XX:+DeoptimizeALot option and how it causes VM_Deopt >> requests on thread state transitions... Interesting... >> >> Testing: >> - I found a way to add delays to the right spots in the >> VM to make the deadlock reproduce in just about every >> run of the test associated with the bug. The new >> os::naked_short_sleep() function is your friend. Thanks >> to Fred for adding that! See the bug report for the >> debugging diffs. >> - 72 hours of running the test in the bug report with >> delays enabled for product, fastdebug and jvmg bits >> in parallel on my Solaris X86 server. >> - JPRT test run >> - Aurora Adhoc results are in process; we're having issues >> with both a broken testbase build and infra problems >> with results not being uploaded. >> > From david.holmes at oracle.com Mon Jun 30 05:33:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Jun 2014 15:33:29 +1000 Subject: RFR (XS) fix for a safepoint deadlock (8047720) In-Reply-To: <53AD9949.9030601@oracle.com> References: <53AD9949.9030601@oracle.com> Message-ID: <53B0F6A9.1060109@oracle.com> Hi Dan, I see this has already gone in but I think it is worth looking closer at this. On 28/06/2014 2:18 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a fix ready for the following bug: > > 8047720 Xprof hangs on Solaris > https://bugs.openjdk.java.net/browse/JDK-8047720 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ > > This deadlock occurred between the following threads: > > Main thread - Trying to stop the WatcherThread as part of > shutting down the VM; this thread is blocked > on the PeriodicTask_lock which keeps it from > reaching a safepoint. > WatcherThread - Requested a VM_ForceSafepoint to complete > a JavaThread::java_suspend() call as part > of a FlatProfiler record_thread_ticks() > call; this thread owns the PeriodicTask_lock > since it is processing a periodic task. > VMThread - Trying to start a safepoint; this thread is > blocked waiting for the Main thread to reach > a safepoint. > > The PeriodicTask_lock is one of the VM internal locks and is > typically managed using Mutex::_no_safepoint_check_flag to > avoid deadlocks. Yes, the irony is dripping on the floor... :-) What was overlooked here is that the holder of a lock that is acquired without safepoint checks, must never block at a safepoint whilst holding that lock. In this case the blocking is indirect, caused by the synchronous nature of the VM_Operation, rather than a direct result of "blocking for the safepoint" (which the WatcherThread does not participate in). I wonder if the WatcherThread should really be using the async variant of VM_ForceSafepoint here? > The interesting part of this deadlock is that I think that it > is possible for other periodic tasks to hit it. Anything that > causes the WatcherThread to start a safepoint while processing > a periodic task should be susceptible to this race. Think about > the -XX:+DeoptimizeALot option and how it causes VM_Deopt > requests on thread state transitions... Interesting... I don't think so. You need three threads involved to get the deadlock. In the current case the main thread's locking of the PeriodicTask_lock without a safepoint check is what causes the problem - that violates the rules surrounding use of "no safepoint checks". The other methods that a JavaThread might call that acquire the PeriodicTask_lock do perform the safepoint checks, so they wouldn't deadlock. Hence it seems to me that only WatcherThread::stop can lead to this problem. And as WatcherThread::stop is only called from before_exit, and that can only be called once, it seems to me that we could/should actually acquire the lock with a safepoint check. Cheers, David > > Testing: > - I found a way to add delays to the right spots in the > VM to make the deadlock reproduce in just about every > run of the test associated with the bug. The new > os::naked_short_sleep() function is your friend. Thanks > to Fred for adding that! See the bug report for the > debugging diffs. > - 72 hours of running the test in the bug report with > delays enabled for product, fastdebug and jvmg bits > in parallel on my Solaris X86 server. > - JPRT test run > - Aurora Adhoc results are in process; we're having issues > with both a broken testbase build and infra problems > with results not being uploaded. > From david.holmes at oracle.com Mon Jun 30 05:54:00 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Jun 2014 15:54:00 +1000 Subject: RFR (XS) fix for a safepoint deadlock (8047720) In-Reply-To: <53B0F6A9.1060109@oracle.com> References: <53AD9949.9030601@oracle.com> <53B0F6A9.1060109@oracle.com> Message-ID: <53B0FB78.6060506@oracle.com> Correction ... On 30/06/2014 3:33 PM, David Holmes wrote: > Hi Dan, > > I see this has already gone in but I think it is worth looking closer at > this. > > On 28/06/2014 2:18 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix ready for the following bug: >> >> 8047720 Xprof hangs on Solaris >> https://bugs.openjdk.java.net/browse/JDK-8047720 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ >> >> This deadlock occurred between the following threads: >> >> Main thread - Trying to stop the WatcherThread as part of >> shutting down the VM; this thread is blocked >> on the PeriodicTask_lock which keeps it from >> reaching a safepoint. >> WatcherThread - Requested a VM_ForceSafepoint to complete >> a JavaThread::java_suspend() call as part >> of a FlatProfiler record_thread_ticks() >> call; this thread owns the PeriodicTask_lock >> since it is processing a periodic task. >> VMThread - Trying to start a safepoint; this thread is >> blocked waiting for the Main thread to reach >> a safepoint. >> >> The PeriodicTask_lock is one of the VM internal locks and is >> typically managed using Mutex::_no_safepoint_check_flag to >> avoid deadlocks. Yes, the irony is dripping on the floor... :-) > > What was overlooked here is that the holder of a lock that is acquired > without safepoint checks, must never block at a safepoint whilst holding > that lock. In this case the blocking is indirect, caused by the > synchronous nature of the VM_Operation, rather than a direct result of > "blocking for the safepoint" (which the WatcherThread does not > participate in). I wonder if the WatcherThread should really be using > the async variant of VM_ForceSafepoint here? > >> The interesting part of this deadlock is that I think that it >> is possible for other periodic tasks to hit it. Anything that >> causes the WatcherThread to start a safepoint while processing >> a periodic task should be susceptible to this race. Think about >> the -XX:+DeoptimizeALot option and how it causes VM_Deopt >> requests on thread state transitions... Interesting... > > I don't think so. You need three threads involved to get the deadlock. But that isn't the point. As you state this deadlock, at VM shutdown, could impact any synchronous safepoint operations executed by the WatcherThread. That aside ... > In the current case the main thread's locking of the PeriodicTask_lock > without a safepoint check is what causes the problem - that violates the > rules surrounding use of "no safepoint checks". The other methods that a > JavaThread might call that acquire the PeriodicTask_lock do perform the > safepoint checks, so they wouldn't deadlock. Hence it seems to me that > only WatcherThread::stop can lead to this problem. And as > WatcherThread::stop is only called from before_exit, and that can only > be called once, it seems to me that we could/should actually acquire the > lock with a safepoint check. David ----- > Cheers, > David > >> >> Testing: >> - I found a way to add delays to the right spots in the >> VM to make the deadlock reproduce in just about every >> run of the test associated with the bug. The new >> os::naked_short_sleep() function is your friend. Thanks >> to Fred for adding that! See the bug report for the >> debugging diffs. >> - 72 hours of running the test in the bug report with >> delays enabled for product, fastdebug and jvmg bits >> in parallel on my Solaris X86 server. >> - JPRT test run >> - Aurora Adhoc results are in process; we're having issues >> with both a broken testbase build and infra problems >> with results not being uploaded. >> From staffan.larsen at oracle.com Mon Jun 30 07:42:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 30 Jun 2014 09:42:02 +0200 Subject: RFR: JDK-8047973 Quarantine compiler/ciReplay/* In-Reply-To: <0C947CA1-88DE-4EA9-9BF2-BB9F72F388A3@oracle.com> References: <53A972F6.2070006@oracle.com> <0C947CA1-88DE-4EA9-9BF2-BB9F72F388A3@oracle.com> Message-ID: <44632BBF-EC47-4FBD-A347-DCE9BB43DF48@oracle.com> Can I have a Review of this change? Thanks, /Staffan On 25 jun 2014, at 08:53, Staffan Larsen wrote: > > On 24 jun 2014, at 14:45, Igor Ignatyev wrote: > >> Staffan, >> >> 1. '@ignore' should be followed by CR numbers > > Good catch - I have fixed that below. > >> 2. I doubt that TestVM* failures are related to JDK-8032226. these tests don't use SA agent, they rather fail due to JDK-8031978 > > You are right. There seems to be some confusion in the RULEs for these two CRs so they match incorrectly. I have added 8031978 or 8032226 as appropriate to the @ignores. > > /Staffan > > > diff --git a/test/compiler/ciReplay/TestSA.sh b/test/compiler/ciReplay/TestSA.sh > --- a/test/compiler/ciReplay/TestSA.sh > +++ b/test/compiler/ciReplay/TestSA.sh > @@ -26,6 +26,7 @@ > ## > ## @test > ## @bug 8011675 > +## @ignore 8032226, 8031978 > ## @summary testing of ciReplay with using generated by SA replay.txt > ## @author igor.ignatyev at oracle.com > ## @run shell TestSA.sh > diff --git a/test/compiler/ciReplay/TestVM.sh b/test/compiler/ciReplay/TestVM.sh > --- a/test/compiler/ciReplay/TestVM.sh > +++ b/test/compiler/ciReplay/TestVM.sh > @@ -26,6 +26,7 @@ > ## > ## @test > ## @bug 8011675 > +## @ignore 8031978 > ## @summary testing of ciReplay with using generated by VM replay.txt > ## @author igor.ignatyev at oracle.com > ## @run shell TestVM.sh > diff --git a/test/compiler/ciReplay/TestVM_no_comp_level.sh b/test/compiler/ciReplay/TestVM_no_comp_level.sh > --- a/test/compiler/ciReplay/TestVM_no_comp_level.sh > +++ b/test/compiler/ciReplay/TestVM_no_comp_level.sh > @@ -26,6 +26,7 @@ > ## > ## @test > ## @bug 8011675 > +## @ignore 8031978 > ## @summary testing of ciReplay with using generated by VM replay.txt w/o comp_level > ## @author igor.ignatyev at oracle.com > ## @run shell TestVM_no_comp_level.sh > >> >> Igor >> >> On 06/24/2014 03:12 PM, Staffan Larsen wrote: >>> These tests keep being unstable in nightly testing (see JDK-8032226) so will have to be quarantined. >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> diff --git a/test/compiler/ciReplay/TestSA.sh b/test/compiler/ciReplay/TestSA.sh >>> --- a/test/compiler/ciReplay/TestSA.sh >>> +++ b/test/compiler/ciReplay/TestSA.sh >>> @@ -26,6 +26,7 @@ >>> ## >>> ## @test >>> ## @bug 8011675 >>> +## @ignore >>> ## @summary testing of ciReplay with using generated by SA replay.txt >>> ## @author igor.ignatyev at oracle.com >>> ## @run shell TestSA.sh >>> diff --git a/test/compiler/ciReplay/TestVM.sh b/test/compiler/ciReplay/TestVM.sh >>> --- a/test/compiler/ciReplay/TestVM.sh >>> +++ b/test/compiler/ciReplay/TestVM.sh >>> @@ -26,6 +26,7 @@ >>> ## >>> ## @test >>> ## @bug 8011675 >>> +## @ignore >>> ## @summary testing of ciReplay with using generated by VM replay.txt >>> ## @author igor.ignatyev at oracle.com >>> ## @run shell TestVM.sh >>> diff --git a/test/compiler/ciReplay/TestVM_no_comp_level.sh b/test/compiler/ciReplay/TestVM_no_comp_level.sh >>> --- a/test/compiler/ciReplay/TestVM_no_comp_level.sh >>> +++ b/test/compiler/ciReplay/TestVM_no_comp_level.sh >>> @@ -26,6 +26,7 @@ >>> ## >>> ## @test >>> ## @bug 8011675 >>> +## @ignore >>> ## @summary testing of ciReplay with using generated by VM replay.txt w/o comp_level >>> ## @author igor.ignatyev at oracle.com >>> ## @run shell TestVM_no_comp_level.sh >>> > From vladimir.x.ivanov at oracle.com Mon Jun 30 07:49:52 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 30 Jun 2014 11:49:52 +0400 Subject: RFR: JDK-8047973 Quarantine compiler/ciReplay/* In-Reply-To: <44632BBF-EC47-4FBD-A347-DCE9BB43DF48@oracle.com> References: <53A972F6.2070006@oracle.com> <0C947CA1-88DE-4EA9-9BF2-BB9F72F388A3@oracle.com> <44632BBF-EC47-4FBD-A347-DCE9BB43DF48@oracle.com> Message-ID: <53B116A0.4030301@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 6/30/14 11:42 AM, Staffan Larsen wrote: > Can I have a Review of this change? > > Thanks, > /Staffan > > > On 25 jun 2014, at 08:53, Staffan Larsen wrote: > >> >> On 24 jun 2014, at 14:45, Igor Ignatyev wrote: >> >>> Staffan, >>> >>> 1. '@ignore' should be followed by CR numbers >> >> Good catch - I have fixed that below. >> >>> 2. I doubt that TestVM* failures are related to JDK-8032226. these tests don't use SA agent, they rather fail due to JDK-8031978 >> >> You are right. There seems to be some confusion in the RULEs for these two CRs so they match incorrectly. I have added 8031978 or 8032226 as appropriate to the @ignores. >> >> /Staffan >> >> >> diff --git a/test/compiler/ciReplay/TestSA.sh b/test/compiler/ciReplay/TestSA.sh >> --- a/test/compiler/ciReplay/TestSA.sh >> +++ b/test/compiler/ciReplay/TestSA.sh >> @@ -26,6 +26,7 @@ >> ## >> ## @test >> ## @bug 8011675 >> +## @ignore 8032226, 8031978 >> ## @summary testing of ciReplay with using generated by SA replay.txt >> ## @author igor.ignatyev at oracle.com >> ## @run shell TestSA.sh >> diff --git a/test/compiler/ciReplay/TestVM.sh b/test/compiler/ciReplay/TestVM.sh >> --- a/test/compiler/ciReplay/TestVM.sh >> +++ b/test/compiler/ciReplay/TestVM.sh >> @@ -26,6 +26,7 @@ >> ## >> ## @test >> ## @bug 8011675 >> +## @ignore 8031978 >> ## @summary testing of ciReplay with using generated by VM replay.txt >> ## @author igor.ignatyev at oracle.com >> ## @run shell TestVM.sh >> diff --git a/test/compiler/ciReplay/TestVM_no_comp_level.sh b/test/compiler/ciReplay/TestVM_no_comp_level.sh >> --- a/test/compiler/ciReplay/TestVM_no_comp_level.sh >> +++ b/test/compiler/ciReplay/TestVM_no_comp_level.sh >> @@ -26,6 +26,7 @@ >> ## >> ## @test >> ## @bug 8011675 >> +## @ignore 8031978 >> ## @summary testing of ciReplay with using generated by VM replay.txt w/o comp_level >> ## @author igor.ignatyev at oracle.com >> ## @run shell TestVM_no_comp_level.sh >> >>> >>> Igor >>> >>> On 06/24/2014 03:12 PM, Staffan Larsen wrote: >>>> These tests keep being unstable in nightly testing (see JDK-8032226) so will have to be quarantined. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> >>>> diff --git a/test/compiler/ciReplay/TestSA.sh b/test/compiler/ciReplay/TestSA.sh >>>> --- a/test/compiler/ciReplay/TestSA.sh >>>> +++ b/test/compiler/ciReplay/TestSA.sh >>>> @@ -26,6 +26,7 @@ >>>> ## >>>> ## @test >>>> ## @bug 8011675 >>>> +## @ignore >>>> ## @summary testing of ciReplay with using generated by SA replay.txt >>>> ## @author igor.ignatyev at oracle.com >>>> ## @run shell TestSA.sh >>>> diff --git a/test/compiler/ciReplay/TestVM.sh b/test/compiler/ciReplay/TestVM.sh >>>> --- a/test/compiler/ciReplay/TestVM.sh >>>> +++ b/test/compiler/ciReplay/TestVM.sh >>>> @@ -26,6 +26,7 @@ >>>> ## >>>> ## @test >>>> ## @bug 8011675 >>>> +## @ignore >>>> ## @summary testing of ciReplay with using generated by VM replay.txt >>>> ## @author igor.ignatyev at oracle.com >>>> ## @run shell TestVM.sh >>>> diff --git a/test/compiler/ciReplay/TestVM_no_comp_level.sh b/test/compiler/ciReplay/TestVM_no_comp_level.sh >>>> --- a/test/compiler/ciReplay/TestVM_no_comp_level.sh >>>> +++ b/test/compiler/ciReplay/TestVM_no_comp_level.sh >>>> @@ -26,6 +26,7 @@ >>>> ## >>>> ## @test >>>> ## @bug 8011675 >>>> +## @ignore >>>> ## @summary testing of ciReplay with using generated by VM replay.txt w/o comp_level >>>> ## @author igor.ignatyev at oracle.com >>>> ## @run shell TestVM_no_comp_level.sh >>>> >> > From staffan.larsen at oracle.com Mon Jun 30 11:22:12 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 30 Jun 2014 13:22:12 +0200 Subject: RFR: JDK-8048710 Use ServiceLoader for the jvmstat protocols Message-ID: All, The jvmstat implementation has three different protocols (file, local and rmi). These protocol implementations are currently loaded with Class.forName() using a specific scheme to create the class name. A more standard approach is to use ServiceLoader for this instead. This also makes it easier to break out different implementation classes for different packagings. webrev: http://cr.openjdk.java.net/~sla/8048710/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8048710 Thanks, /Staffan From Alan.Bateman at oracle.com Mon Jun 30 13:25:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Jun 2014 14:25:53 +0100 Subject: RFR: JDK-8048710 Use ServiceLoader for the jvmstat protocols In-Reply-To: References: Message-ID: <53B16561.4020506@oracle.com> On 30/06/2014 12:22, Staffan Larsen wrote: > All, > > The jvmstat implementation has three different protocols (file, local and rmi). These protocol implementations are currently loaded with Class.forName() using a specific scheme to create the class name. A more standard approach is to use ServiceLoader for this instead. This also makes it easier to break out different implementation classes for different packagings. > > webrev: http://cr.openjdk.java.net/~sla/8048710/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8048710 > This looks good to me. One comment on monitoredHostServiceLoader is that it specifies the class loader as null and so will search the system class loader. I think this is okay as it provides a bit of flexibility to deploy other protocols on the class path if needed. One other comment is that using ServiceLoader with a security manager often requires additional permissions to be granted because it involve scanning the class path. I don't know if we have any tests that use jvmstat with a security manager, just something to mention in case it comes up. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Mon Jun 30 16:43:19 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 30 Jun 2014 18:43:19 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() Message-ID: <53B193A7.2020109@oracle.com> Please, review the following test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 Intricate log parsing in order to get an application PID is replaced with the new Process.getPid() API call. While doing this cleanup it also become obvious that it was unnecessary to start a socket server for each launched test application just in order to shut it down when the same functionality can be achieved through the usage of stdin/stdout provided by the Process instance. Thanks, -JB- From daniel.daugherty at oracle.com Mon Jun 30 17:08:56 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 30 Jun 2014 11:08:56 -0600 Subject: RFR (XS) fix for a safepoint deadlock (8047720) In-Reply-To: <53B0FB78.6060506@oracle.com> References: <53AD9949.9030601@oracle.com> <53B0F6A9.1060109@oracle.com> <53B0FB78.6060506@oracle.com> Message-ID: <53B199A8.7040003@oracle.com> David, Thanks for the review. Obviously I can't list you as a reviewer since I already pushed the changeset... On 6/29/14 11:54 PM, David Holmes wrote: > Correction ... > > On 30/06/2014 3:33 PM, David Holmes wrote: >> Hi Dan, >> >> I see this has already gone in but I think it is worth looking closer at >> this. >> >> On 28/06/2014 2:18 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a fix ready for the following bug: >>> >>> 8047720 Xprof hangs on Solaris >>> https://bugs.openjdk.java.net/browse/JDK-8047720 >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ >>> >>> This deadlock occurred between the following threads: >>> >>> Main thread - Trying to stop the WatcherThread as part of >>> shutting down the VM; this thread is blocked >>> on the PeriodicTask_lock which keeps it from >>> reaching a safepoint. >>> WatcherThread - Requested a VM_ForceSafepoint to complete >>> a JavaThread::java_suspend() call as part >>> of a FlatProfiler record_thread_ticks() >>> call; this thread owns the PeriodicTask_lock >>> since it is processing a periodic task. >>> VMThread - Trying to start a safepoint; this thread is >>> blocked waiting for the Main thread to reach >>> a safepoint. >>> >>> The PeriodicTask_lock is one of the VM internal locks and is >>> typically managed using Mutex::_no_safepoint_check_flag to >>> avoid deadlocks. Yes, the irony is dripping on the floor... :-) >> >> What was overlooked here is that the holder of a lock that is acquired >> without safepoint checks, must never block at a safepoint whilst holding >> that lock. I'm not sure about the above rule when you're talking about internal VM threads that are really JavaThreads. JavaThreads can run into all kinds of our special logic when doing thread state transitions and the like. JavaThreads can also post JVM/TI events which can lead to blocking at safepoints or blocking on JVM/TI raw monitors in event handlers, etc... >> In this case the blocking is indirect, caused by the >> synchronous nature of the VM_Operation, rather than a direct result of >> "blocking for the safepoint" (which the WatcherThread does not >> participate in). Right. The WatcherThread intentionally does not participate in safepoints when using the PeriodicTask_lock. To me, that means that other threads using that lock should not participate in the safepoint protocol. I believe we're trying to be consistent about how we use locks with respect to honoring the safepoint protocol or not. Markus G has a bug fix in process where he's trying to add sanity checks that detect inconsistent use of locks. In this particular case, I believe that the Main thread's use of the PeriodicTask_lock with the safepoint protocol enabled would be seen as inconsistent. However, I may not have all the details for what Markus is doing. >> I wonder if the WatcherThread should really be using >> the async variant of VM_ForceSafepoint here? The WatcherThread is trying to do a JavaThread::java_suspend() call. JavaThread::java_suspend() cannot return to the caller until it is sure that the target thread will not execute any more bytecodes. Switching to an async VM_ForceSafepoint would break that invariant and cause subtle deadlocks because a target JavaThread could acquire a Java monitor when the suspend requesting thread thinks it is suspended. Been down that road before and it is not pretty. >> >>> The interesting part of this deadlock is that I think that it >>> is possible for other periodic tasks to hit it. Anything that >>> causes the WatcherThread to start a safepoint while processing >>> a periodic task should be susceptible to this race. Think about >>> the -XX:+DeoptimizeALot option and how it causes VM_Deopt >>> requests on thread state transitions... Interesting... >> >> I don't think so. You need three threads involved to get the deadlock. > > But that isn't the point. As you state this deadlock, at VM shutdown, > could impact any synchronous safepoint operations executed by the > WatcherThread. Right. The problem is that the WatcherThread holds the PeriodicTask_lock across the potential for VM operations so we have to be very, very careful with non-WatcherThread uses of that lock to avoid deadlocks. > > That aside ... > >> In the current case the main thread's locking of the PeriodicTask_lock >> without a safepoint check is what causes the problem - that violates the >> rules surrounding use of "no safepoint checks". The other methods that a >> JavaThread might call that acquire the PeriodicTask_lock do perform the >> safepoint checks, so they wouldn't deadlock. Hence it seems to me that >> only WatcherThread::stop can lead to this problem. And as >> WatcherThread::stop is only called from before_exit, and that can only >> be called once, it seems to me that we could/should actually acquire the >> lock with a safepoint check. Agreed that only the WatcherThread::stop() call can lead to this deadlock because it is that call that catches the PeriodicTask_lock being held across a VM operation. That's the heart of this deadlock and we're only differing on how to solve that deadlock. The primary purpose of WatcherThread::stop() is setting the _should_terminate flag so that the WatcherThread knows that it should stop dispatching periodic tasks. _should_terminate is already volatile and the existing code does an OrderAccess::fence() just to be sure the update is seen. The secondary purpose of WatcherThread::stop() is waking up the WatcherThread so that it stops in a more timely fashion. The WatcherThread waits for a fixed amount of time so it will eventually wake up and see the new _should_terminate value. If caller of WatcherThread::stop() cannot get the PeriodicTask_lock, then that means the WatcherThread is active so WatcherThread::stop() only has to set the flag. It is possible for the WatcherThread::stop() call to race with the WatcherThread dropping the PeriodicTask_lock and waiting. In that case, the WatcherThread waits for a fixed amount of time so it will eventually wake up and see the new _should_terminate value. I intentionally don't want WatcherThread::stop() to honor the safepoint protocol when accessing the PeriodicTask_lock so that we remain consistent with our use of that lock. See my comments above about Markus' work in this area. WatcherThread::stop() will honor the safepoint protocol a couple of lines down from my changes: 1380 // it is ok to take late safepoints here, if needed 1381 MutexLocker mu(Terminator_lock); The subsequent wait() loop also honors the safepoint protocol. Dan > > David > ----- > >> Cheers, >> David >> >>> >>> Testing: >>> - I found a way to add delays to the right spots in the >>> VM to make the deadlock reproduce in just about every >>> run of the test associated with the bug. The new >>> os::naked_short_sleep() function is your friend. Thanks >>> to Fred for adding that! See the bug report for the >>> debugging diffs. >>> - 72 hours of running the test in the bug report with >>> delays enabled for product, fastdebug and jvmg bits >>> in parallel on my Solaris X86 server. >>> - JPRT test run >>> - Aurora Adhoc results are in process; we're having issues >>> with both a broken testbase build and infra problems >>> with results not being uploaded. >>> From serguei.spitsyn at oracle.com Mon Jun 30 21:09:13 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 30 Jun 2014 14:09:13 -0700 Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check In-Reply-To: <53AD310E.1010200@oracle.com> References: <53AAD54E.8090804@oracle.com> <53AC985D.6080806@oracle.com> <53AC9B80.9030805@oracle.com> <53AD2C8F.9090702@oracle.com> <53AD310E.1010200@oracle.com> Message-ID: <53B1D1F9.5050404@oracle.com> Coleen, Vladimir and Markus, Markus raised a good point on the predefined number of words reserved for inlined mask storage. I'm suggesting the following update: diff -r 6b78c6948ec8 src/share/vm/interpreter/oopMapCache.hpp --- a/src/share/vm/interpreter/oopMapCache.hpp Wed Jun 25 22:12:25 2014 +0000 +++ b/src/share/vm/interpreter/oopMapCache.hpp Mon Jun 30 14:02:17 2014 -0700 @@ -66,19 +66,15 @@ class InterpreterOopMap: ResourceObj { public: enum { - N = 2, // the number of words reserved + N = 4, // the number of words reserved // for inlined mask storage small_mask_limit = N * BitsPerWord, // the maximum number of bits // available for small masks, // small_mask_limit can be set to 0 // for testing bit_mask allocation The updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.2 Please, let me know if this update looks Ok. Thanks, Serguei On 6/27/14 1:53 AM, serguei.spitsyn at oracle.com wrote: > On 6/27/14 1:34 AM, serguei.spitsyn at oracle.com wrote: >> Hi Markus, >> >> I raised a good point, thanks! > > Sorry, I wanted to say: "You raised a good point!" :) >> What do you think about increasing the predefined size (N from 2 to 4)? >> >> 64 class InterpreterOopMap: ResourceObj { >> 65 friend class OopMapCache; >> 66 >> 67 public: >> 68 enum { >> 69 N = 2, // the number of words reserved >> 70 // for inlined mask storage >> 71 small_mask_limit = N * BitsPerWord, // the maximum number of bits >> 72 // available for small masks, >> 73 // small_mask_limit can be set to 0 >> 74 // for testing bit_mask allocation >> >> >> Thanks, >> Serguei >> >> On 6/27/14 1:12 AM, Markus Gr?nlund wrote: >>> Hi Serguei, >>> >>> >>> I am not convinced this is the right way to do this - by removing the #ifdef ENABLE_ZAP_DEAD_LOCALS" (which is an COMPILER2 specific #define under an ASSERT), we have now unconditionally increased the bitsize for every oopmap entry to two (compared to one previously) - the inlined oop_map bits_size cache is predefined to hold two words. >>> >>> This means the oopmap bitmap cache is effectively halved unconditionally. >>> >>> /Markus >>> >>> >>> -----Original Message----- >>> From: Serguei Spitsyn >>> Sent: den 27 juni 2014 00:15 >>> To: Vladimir Ivanov;hotspot-dev at openjdk.java.net Developers;serviceability-dev at openjdk.java.net >>> Subject: Re: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check >>> >>> Thanks, Vladimir! >>> Serguei >>> >>> On 6/26/14 3:02 PM, Vladimir Ivanov wrote: >>>> Looks good. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 6/25/14 5:57 PM,serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8013942 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVM >>>>> TI-lobj.1 >>>>> >>>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This is a Nightly Stabilization issue. >>>>> >>>>> The problem is that the JVMTI GetLocalObject() function is hitting >>>>> the assert >>>>> as the type of the local at current bci is not T_OBJECT as expected. >>>>> It is because this local is alive only in a narrow scope of one >>>>> condition in the method but current bci is out of this csope. >>>>> >>>>> A fragment from the target method: >>>>> >>>>> static Class canonicalize(Class t, int how) { >>>>> Class ct; <== The local >>>>> if (t == Object.class) { >>>>> // no change, ever >>>>> } else if (!t.isPrimitive()) { >>>>> switch (how) { >>>>> case UNWRAP: >>>>> ct = Wrapper.asPrimitiveType(t); <== Initialized >>>>> here >>>>> if (ct != t) return ct; >>>>> break; >>>>> case RAW_RETURN: >>>>> case ERASE: >>>>> return Object.class; >>>>> } >>>>> } else if (t == void.class) { <== The >>>>> GetLocalObject() is called with bci in this block >>>>> // no change, usually >>>>> switch (how) { >>>>> case RAW_RETURN: >>>>> return int.class; >>>>> case WRAP: >>>>> return Void.class; >>>>> } >>>>> } else { >>>>> . . . >>>>> >>>>> The local 'ct' is only alive in the block of condition "if >>>>> (!t.isPrimitive())". >>>>> However, it is dead local in the next block. >>>>> >>>>> The fix suggested in the webrev above is to use the oop_mask for >>>>> the method's current bci. >>>>> It tells when the local is dead in the scope of this bci. >>>>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case. >>>>> >>>>> The fix also includes the tweeks which are necessary to enable the >>>>> InterpreterOopMap.is_dead() >>>>> function in the product mode as it was originally defined only >>>>> under "#ifdef ENABLE_ZAP_DEAD_LOCALS". >>>>> This makes the code in the oopMapCache.?pp a little bit more simple. >>>>> >>>>> >>>>> Testing: >>>>> Running the failing tests: vm.mlvm.indy.func.jvmti >>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and >>>>> amd64 >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: