From jaroslav.bachorik at oracle.com Mon Dec 1 09:16:29 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 01 Dec 2014 10:16:29 +0100 Subject: RFR 8064441: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <5476E1D6.8010601@oracle.com> References: <5475CE4D.5010705@oracle.com> <547673CD.2070205@oracle.com> <5476E1D6.8010601@oracle.com> Message-ID: <547C31ED.40607@oracle.com> On 11/27/2014 09:33 AM, Jaroslav Bachorik wrote: > On 11/27/2014 01:43 AM, David Holmes wrote: >> On 26/11/2014 10:57 PM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8064441 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8064441/webrev.00 >>> >>> The test fails because of System.out.println() may induce unexpected >>> locking. The solution is to use an already existing LockFreeLogManager >>> library class to collect the logs in the lock-free manner and print the >>> logs only after all the test code has been run. >> >> I seem to remember spending a lot of time on this test in the past, >> where the phaser usage was intended to ensure that we could not be seen >> to be blocking on the internal locks associated with the println. Where >> has this gone wrong? > > The remaining problem is the usage of System.out.print[ln]() inside the > test threads. System.out.print[ln]() might involve blocking the calling > thread and eg. create false positives when the test is waiting for a > thread to enter the blocked state. > >> >> What are the semantics of the lockfreelogger? When will we see its >> output? > > It is using thread local lists of the logging records. Each logging > record has an id which is unique and monotonous over all the threads -> > an AtomicInteger instance is used to achieve this. > > You can retrieve the log output (ordered by the log record id) by > calling LockFreeLogManager.toString(). > > Review for the LockFreeLogManager is available here > [http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015848.html] David, are you ok with this change then? Thanks, -JB- > > > -JB- > >> >> Thanks, >> David >> >>> Thanks, >>> >>> -JB- > From shanliang.jiang at oracle.com Mon Dec 1 13:50:16 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 01 Dec 2014 14:50:16 +0100 Subject: Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs Message-ID: <547C7218.2040001@oracle.com> Hi, please review this test bug fix: webrev: http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8065764 The test tested the mode "difference", according to the Javadoc: If the counter difference mode is used, the value of the derived gauge is calculated as the difference between the observed counter values for two successive observations. The test set the first value and then waited 2 times of granularityperiod at line 171, hoped that the monitor would get the first observation during this waiting time, but the test could fail because granularityperiod * 2 was not enough and the test did the second set before the monitor did the first observation. It is easy to make the test timeout by commenting out the line 171. The proposed solution is to get informed when the monitor did observation on calling: StdObservedObject.getNbObjects(); Thanks, Shanliang From daniel.fuchs at oracle.com Mon Dec 1 14:29:38 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 01 Dec 2014 15:29:38 +0100 Subject: Codereview: JDK-8065764 javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547C7218.2040001@oracle.com> References: <547C7218.2040001@oracle.com> Message-ID: <547C7B52.3060501@oracle.com> 55 // derived gange 56 private volatile int derivedGange = 1; Typo in both lines: gange -> gauge - data = new Integer(values[i]); - echo(">>> Set data = " + data.intValue()); It is strange that you no longer have to set the value to a different value. I don't understand how the test can succeed: first gauge: data.intValue() - 0 = data.intValue() = 0 second gauge (and so on): data.intValue() - data.intValue() = 0 how can that ever exceed the threshold of 2? I must have missed something. best regards -- daniel On 01/12/14 14:50, shanliang wrote: > Hi, > please review this test bug fix: > > webrev: > http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-8065764 > > The test tested the mode "difference", according to the Javadoc: > If the counter difference mode is used, the value of the derived > gauge is calculated as the difference between the observed counter > values for two successive observations. > > The test set the first value and then waited 2 times of > granularityperiod at line 171, hoped that the monitor would get the > first observation during this waiting time, but the test could fail > because granularityperiod * 2 was not enough and the test did the second > set before the monitor did the first observation. > > It is easy to make the test timeout by commenting out the line 171. > > The proposed solution is to get informed when the monitor did > observation on calling: > StdObservedObject.getNbObjects(); > > Thanks, > Shanliang > > From chris.plummer at oracle.com Tue Dec 2 02:39:22 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 01 Dec 2014 18:39:22 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <546CBCAB.7040101@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> Message-ID: <547D265A.20005@oracle.com> Sorry about the long delay in getting back to this. I ran into two separate JPRT issues that were preventing me from testing these changes, plus I was on vacation last week. Here's an updated webrev. I'm not sure where we left things, so I'll just say what's changed since the original version: 1. Rewrote the test to be in Java instead of a shell script. 2. Moved the test from hotspot/test/runtime/memory to jdk/test/tools/launcher 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to override the default 32k minimum value. https://bugs.openjdk.java.net/browse/JDK-6762191 http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ thanks, Chris On 11/19/14 7:52 AM, Chris Plummer wrote: > On 11/19/14 2:12 AM, David Holmes wrote: >> On 19/11/2014 6:49 PM, Chris Plummer wrote: >>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k >>> references, and also moved the test from hotspot/test/runtime to >>> jdk/test/tools/launcher as David requested. That required some >>> adjustments to the test script, since test_env.sh does not exist in >>> jdk/test, so I had to pull in the bits I needed into the script. >> >> Is there a reason this needs a shell script instead of using the >> testlibrary tools to launch the VM and check the output? > Not that I'm aware of. I guess I just really didn't look at what it > would take to make it all in java. I'll have a look at java examples > and convert it. > > Chris >> >> Sorry that should have been mentioned much earlier. >> >> David >> >> >>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ >>> >>> I still need to rerun through JPRT. I'll do so once there are no more >>> suggested changes. >>> >>> thanks, >>> >>> Chris >>> >>> On 11/18/14 2:08 PM, Chris Plummer wrote: >>>> Adding core-libs-dev at openjdk.java.net, since one of the changes is in >>>> java.c. >>>> >>>> Chris >>>> >>>> On 11/12/14 6:43 PM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> Sorry for the delay. >>>>> >>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>>>>> Hi, >>>>>> >>>>>> I'm still looking for reviewers. >>>>> >>>>> As the change is to the launcher it needs to be reviewed by the >>>>> launcher owner - which I think is serviceability (though also cc'd >>>>> Kumar :) ). >>>>> >>>>> Launcher change, and your rationale, seems okay to me. I'd probably >>>>> put the test in to jdk/test/tools/launcher/ though. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>>>>> This is an initial review for 6762191. I'm guessing there will be >>>>>>> recommendations to fix in a different way, but thought this >>>>>>> would be a >>>>>>> good time to start the discussion. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>>>>> >>>>>>> The bug is that if the -Xss size is set to something very small >>>>>>> (like >>>>>>> 16k), on linux there will be a crash due to overwriting the end >>>>>>> of the >>>>>>> stack. This happens before hotspot can compute its stack needs and >>>>>>> verify that the stack is big enough. >>>>>>> >>>>>>> It didn't seem viable to move the hotspot stack size check >>>>>>> earlier. It >>>>>>> depends on too much other work done before that point, and the >>>>>>> changes >>>>>>> would have been disruptive. The stack size check is currently >>>>>>> done in >>>>>>> os::init_2(). >>>>>>> >>>>>>> What is needed is a check before the thread is created. That way we >>>>>>> can create a thread with a big enough stack to handle all needs >>>>>>> up to >>>>>>> the point of the check in os::init_2(). This initial check does not >>>>>>> need to be the final check. It just needs to confirm that we have >>>>>>> enough stack to get us to the check in os::init_2(). >>>>>>> >>>>>>> I decided to check in java.c if the -Xss size is too small, and >>>>>>> set it >>>>>>> to a larger size if it is. I hard coded this size to 32k (I'll >>>>>>> explain >>>>>>> why 32k later). I suspect this is the part that will result in some >>>>>>> debate. If you have better suggestions let me know. If it does stay >>>>>>> here, then probably the 32k needs to be a #define, and maybe >>>>>>> even an >>>>>>> OS porting interface, but I'm not sure where to put it. >>>>>>> >>>>>>> The reason I chose 32k is because this is big enough for all >>>>>>> platforms >>>>>>> to get to the stack size check in os::init_2(). It is also smaller >>>>>>> than the actual minimum stack size allowed on any platform. 32-bit >>>>>>> windows has the smallest requirement at 64k. I add some printfs to >>>>>>> print the minimum stack requirement, and then ran a simple JTReg >>>>>>> test >>>>>>> with every JPRT supported platform to get the results. >>>>>>> >>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>>>>> -Xss32k, and -XXss, where is the size from the >>>>>>> error message produced by the JVM, such as in the following: >>>>>>> >>>>>>> $ java -Xss32k -version >>>>>>> The stack size specified is too small, Specify at least 100k >>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>> >>>>>>> I ran this test through JPRT on all platforms, and they all pass. >>>>>>> >>>>>>> One thing to point out is that Windows behaves a bit different than >>>>>>> the other platforms. It always rounds the stack size up to a >>>>>>> multiple >>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so >>>>>>> there >>>>>>> is no error produced in this case. However, on 32-bit Windows >>>>>>> with C2, >>>>>>> 68k is the minimum, so an error is produced since the stack will >>>>>>> only >>>>>>> be 64k. There is no bug here. It's just a bit confusing. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>> >>>> >>> > From staffan.larsen at oracle.com Tue Dec 2 07:29:06 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 2 Dec 2014 08:29:06 +0100 Subject: JEP: Allow debug tools to detect mismatch btwn sourcecode and bytecode In-Reply-To: <547A4C81.4000506@oracle.com> References: <547A4C81.4000506@oracle.com> Message-ID: Hi Bruno, This is an interesting proposal and I guess it would avoid a lot of unnecessary confusion for developers. As I understand it, the exact algorithm used to compute the fingerprint would need to be known to debuggers, or at least an implementation of it would need to be provided by the JDK. The proposed solution would require an addition to the class file format to store the fingerprint. Most likely in the form of a new ?attribute?. It would be interesting to hear opinions from debugger developers (netbeans, eclipse, intellij?) on this proposal. Thanks, /Staffan > On 29 nov 2014, at 23:45, Bruno Borges wrote: > > Hi all, > > Based on a common incident that happens not rarely among developers, and as recently felt by Martijn Dashort [1], it seems to be a good idea to: "Enable debugger to detect when there is a mismatch between source code and class being debugged" (thanks to Stuart Marks for the excellent problem statement [2]). > > [1] https://twitter.com/dashorst/status/538329707549560832 > [2] https://twitter.com/stuartmarks/status/538722163700674561 > > So I came up with the following JEP draft, and I'd like to have your input in this matter as well any comments, suggestions, etc. > > --- JEP DRAFT BEGIN --- > > Summary > ------- > Enable debugger to detect when there is a mismatch between source code and class being debugged > > Goals > ----- > * Detect mismatch between the source code and the class bytecode being debugged > * Allow for IDEs to identify through Debugger API such mismatch, enabling development of extensions > > Motivation > ---------- > To increase development productivity by avoiding developers on wasting time debugging the wrong source code > > Description > ----------- > Developers often find themselves debugging a Java application attached to their IDE, where the source code used to compile the bytecode being debugged is similar, but not the same. This leads to time wasted in understanding why some things behave differently, and sometimes developers blame the JVM, or the application server, or something in the runtime environment. > > By providing a fingerprint to the source code used to compile a bytecode, when javac is configured to do so (example: -g:sourcefingerprint), and injecting that fingerprint into the bytecode, the Debugger API can then expose such information to IDEs and Debugger agents. The jdb command and the Java Debug Interface API may need to be extended to add such information. > > Testing > ------- > A test use case to validate this JEP is in the form of: > - compile a Java class > - modify the source code > - run the bytecode initially compiled > - debug the application > - identify the mismatch that source code has been modified > > Debug with jdb. > > Risks and Assumptions > --------------------- > There is a risk of the source code match the bytecode, but not inherited classes, which means not only the class being debugged but its structure and inherited graph must also match. > > The fingerprint must consider multiple data from the source code in order to be stringent: > - sourcecode checksum > - Java class structure > - inheritance graph > > It may be required to considered other form of data to build the fingerprint. > > Dependences > ----------- > Beyond the jdb tool and the Java Debug Interface, there are no other identified dependencies. > > --- JEP DRAFT END --- > > -- Bruno Borges // +5511995649058 LAD Principal Product Manager Exalogic | Cloud | CAF | Java From david.holmes at oracle.com Tue Dec 2 09:37:00 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Dec 2014 19:37:00 +1000 Subject: RFR 8064441: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <547C31ED.40607@oracle.com> References: <5475CE4D.5010705@oracle.com> <547673CD.2070205@oracle.com> <5476E1D6.8010601@oracle.com> <547C31ED.40607@oracle.com> Message-ID: <547D883C.8060400@oracle.com> On 1/12/2014 7:16 PM, Jaroslav Bachorik wrote: > On 11/27/2014 09:33 AM, Jaroslav Bachorik wrote: >> On 11/27/2014 01:43 AM, David Holmes wrote: >>> On 26/11/2014 10:57 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8064441 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8064441/webrev.00 >>>> >>>> The test fails because of System.out.println() may induce unexpected >>>> locking. The solution is to use an already existing LockFreeLogManager >>>> library class to collect the logs in the lock-free manner and print the >>>> logs only after all the test code has been run. >>> >>> I seem to remember spending a lot of time on this test in the past, >>> where the phaser usage was intended to ensure that we could not be seen >>> to be blocking on the internal locks associated with the println. Where >>> has this gone wrong? >> >> The remaining problem is the usage of System.out.print[ln]() inside the >> test threads. System.out.print[ln]() might involve blocking the calling >> thread and eg. create false positives when the test is waiting for a >> thread to enter the blocked state. >> >>> >>> What are the semantics of the lockfreelogger? When will we see its >>> output? >> >> It is using thread local lists of the logging records. Each logging >> record has an id which is unique and monotonous over all the threads -> >> an AtomicInteger instance is used to achieve this. >> >> You can retrieve the log output (ordered by the log record id) by >> calling LockFreeLogManager.toString(). >> >> Review for the LockFreeLogManager is available here >> [http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015848.html] >> > > David, are you ok with this change then? I guess so. Still not sure why we see the println problem though - but don't have time to delve into it. Thanks, David > Thanks, > > -JB- > >> >> >> -JB- >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> >>>> -JB- >> > From bruno.borges at oracle.com Tue Dec 2 11:02:47 2014 From: bruno.borges at oracle.com (Bruno Borges) Date: Tue, 02 Dec 2014 09:02:47 -0200 Subject: JEP: Allow debug tools to detect mismatch btwn sourcecode and bytecode In-Reply-To: References: <547A4C81.4000506@oracle.com> Message-ID: <547D9C57.5090302@oracle.com> Hi Staffan, thanks for your feedback. The fingerprint algorithm may be either: - added to javac as an argument, in order to calculate during compilation and inject that to the classfile format "new attribute" - a new tool provided by JDK, say "javafp" that would be allowed for standalone calls - both solutions above, where javac delegates to "javafp" the calculation during compilation, which allows IDEs to reuse this tool during debugging The Debugger API exposes the fingerprint so Debugging agents become aware of what sourcecode was used to compile. Now there's one thing I am still not sure if it holds true, or it's something will never happen, or not lead to any errors, by tricking developers. The sourcecode of the class being debugged may have not changed, but instead, its super class or default methods of implemented interfaces, which could lead to different behavior. This anomaly would require the fingerprint to not be a simple checksum on top of the source code but on the full inheritance graph and any implemented interface, or subinterface that has default methods. # interfaces interface C -> fp based on C's sourcecode subinterface D with default method -> fp based on D's sourcecode subinterface E -> fp based on D's sourcecode and E's sourcecode (considers D's because of default methods) # classes class A -> fp based java.lang.Object's computed class fp (taken from JDK) and A's sourcecode class B extends A -> fp based on A's fp and B's source code class C extends B implements D -> fp based on B's fp, D's fp, and C's source code class F extends C implements E -> fp based on C's fp, E's fp, and F's source code The cases above exposes the possibilities, in my view, of anomalies during debugging that could lead developers to believe they are debugging the right source code. Often, developers skip calls to super methods (or default methods in interfaces, now in Java SE 8). With a fingerprint based not only on source code but also on inheritance graph containing actual code (I see no point in doing fp for plain interfaces), this anomaly could be avoided easily. I confess I am still not sure if fingerprints based on inheritance graph is really necessary. That's something I'd like to discuss here. *# When sourcecode of inheritance graph is not available* How would fingerprint be calculated in case there is no classfile fingerprint attribute available on inheritance graph (say, when extending a legacy library compiled on previous versions, or deliberately chosen by the developer to not calculate and inject fingerprint during compilation (if this is an option). If we see that fingerprint based on inheritance graph is required, then what would happen if there is no fingerprint on super classes, or interface with default method, or interface inherited from one with default methods? In summary, questions are: (1) must source code fingerprint consider inheritance graph? (2) if -1- is 'yes', how to behave and proceed when dealing with bytecode without the fingerprint attribute, or if fingerprint is optional during compilation? On 02/12/2014 05:29, Staffan Larsen wrote: > Hi Bruno, > > This is an interesting proposal and I guess it would avoid a lot of unnecessary confusion for developers. > > As I understand it, the exact algorithm used to compute the fingerprint would need to be known to debuggers, or at least an implementation of it would need to be provided by the JDK. > > The proposed solution would require an addition to the class file format to store the fingerprint. Most likely in the form of a new ?attribute?. > > It would be interesting to hear opinions from debugger developers (netbeans, eclipse, intellij?) on this proposal. > > Thanks, > /Staffan > > >> On 29 nov 2014, at 23:45, Bruno Borges wrote: >> >> Hi all, >> >> Based on a common incident that happens not rarely among developers, and as recently felt by Martijn Dashort [1], it seems to be a good idea to: "Enable debugger to detect when there is a mismatch between source code and class being debugged" (thanks to Stuart Marks for the excellent problem statement [2]). >> >> [1] https://twitter.com/dashorst/status/538329707549560832 >> [2] https://twitter.com/stuartmarks/status/538722163700674561 >> >> So I came up with the following JEP draft, and I'd like to have your input in this matter as well any comments, suggestions, etc. >> >> --- JEP DRAFT BEGIN --- >> >> Summary >> ------- >> Enable debugger to detect when there is a mismatch between source code and class being debugged >> >> Goals >> ----- >> * Detect mismatch between the source code and the class bytecode being debugged >> * Allow for IDEs to identify through Debugger API such mismatch, enabling development of extensions >> >> Motivation >> ---------- >> To increase development productivity by avoiding developers on wasting time debugging the wrong source code >> >> Description >> ----------- >> Developers often find themselves debugging a Java application attached to their IDE, where the source code used to compile the bytecode being debugged is similar, but not the same. This leads to time wasted in understanding why some things behave differently, and sometimes developers blame the JVM, or the application server, or something in the runtime environment. >> >> By providing a fingerprint to the source code used to compile a bytecode, when javac is configured to do so (example: -g:sourcefingerprint), and injecting that fingerprint into the bytecode, the Debugger API can then expose such information to IDEs and Debugger agents. The jdb command and the Java Debug Interface API may need to be extended to add such information. >> >> Testing >> ------- >> A test use case to validate this JEP is in the form of: >> - compile a Java class >> - modify the source code >> - run the bytecode initially compiled >> - debug the application >> - identify the mismatch that source code has been modified >> >> Debug with jdb. >> >> Risks and Assumptions >> --------------------- >> There is a risk of the source code match the bytecode, but not inherited classes, which means not only the class being debugged but its structure and inherited graph must also match. >> >> The fingerprint must consider multiple data from the source code in order to be stringent: >> - sourcecode checksum >> - Java class structure >> - inheritance graph >> >> It may be required to considered other form of data to build the fingerprint. >> >> Dependences >> ----------- >> Beyond the jdb tool and the Java Debug Interface, there are no other identified dependencies. >> >> --- JEP DRAFT END --- >> >> -- Bruno Borges // +5511995649058 LAD Principal Product Manager Exalogic | Cloud | CAF | Java -- Bruno Borges // +5511995649058 LAD Principal Product Manager Exalogic | Cloud | CAF | Java -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Dec 2 11:36:32 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 02 Dec 2014 14:36:32 +0300 Subject: RFR(M) JDK-8042397: tmtools/jmap/heap_config/jmap_heap_config_OldSize fails Message-ID: <547DA440.8050704@oracle.com> Hi Everybody, Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8042397/webrev.08/ The test is ported from VM testbase to JTREG, added separate class intended to provide standard framework for launching slave application. Part of this fix will be moved to testlibrary after it bakes for some time as a part of the single test. JMapHeapConfigTest.java - JMap test LingeredApp.java - framework it self. LingeredAppTest.java - simple unit test for the framework -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Tue Dec 2 15:51:09 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 02 Dec 2014 16:51:09 +0100 Subject: RFR 8064441: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <547D883C.8060400@oracle.com> References: <5475CE4D.5010705@oracle.com> <547673CD.2070205@oracle.com> <5476E1D6.8010601@oracle.com> <547C31ED.40607@oracle.com> <547D883C.8060400@oracle.com> Message-ID: <547DDFED.107@oracle.com> On 12/02/2014 10:37 AM, David Holmes wrote: > On 1/12/2014 7:16 PM, Jaroslav Bachorik wrote: >> On 11/27/2014 09:33 AM, Jaroslav Bachorik wrote: >>> On 11/27/2014 01:43 AM, David Holmes wrote: >>>> On 26/11/2014 10:57 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8064441 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8064441/webrev.00 >>>>> >>>>> The test fails because of System.out.println() may induce unexpected >>>>> locking. The solution is to use an already existing LockFreeLogManager >>>>> library class to collect the logs in the lock-free manner and print >>>>> the >>>>> logs only after all the test code has been run. >>>> >>>> I seem to remember spending a lot of time on this test in the past, >>>> where the phaser usage was intended to ensure that we could not be seen >>>> to be blocking on the internal locks associated with the println. Where >>>> has this gone wrong? >>> >>> The remaining problem is the usage of System.out.print[ln]() inside the >>> test threads. System.out.print[ln]() might involve blocking the calling >>> thread and eg. create false positives when the test is waiting for a >>> thread to enter the blocked state. >>> >>>> >>>> What are the semantics of the lockfreelogger? When will we see its >>>> output? >>> >>> It is using thread local lists of the logging records. Each logging >>> record has an id which is unique and monotonous over all the threads -> >>> an AtomicInteger instance is used to achieve this. >>> >>> You can retrieve the log output (ordered by the log record id) by >>> calling LockFreeLogManager.toString(). >>> >>> Review for the LockFreeLogManager is available here >>> [http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015848.html] >>> >>> >> >> David, are you ok with this change then? > > I guess so. Still not sure why we see the println problem though - but > don't have time to delve into it. Thanks! PrintStream and Writer are full of synchronized blocks. When on use them in multithreaded environment an occasional blocking might occur. For example, in Locks.java, 'LockAThread' and 'LockBThread' threads run concurrently, both of them outputting some log info via System.out. So it may happen that when asserting the 'LockAThread' thread state in 'checkBlockedObject' the thread is in blocked state thanks to blocking on the output stream internals rather than on the test monitor. I hope this clarifies the problem a bit. -JB- > > Thanks, > David > >> Thanks, >> >> -JB- >> >>> >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> >> From staffan.friberg at oracle.com Tue Dec 2 18:33:01 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 10:33:01 -0800 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <546CC3FE.7070105@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <5416D64C.9020207@oracle.com> <545B4986.1050700@oracle.com> <545B5520.7010407@oracle.com> <545B70D2.9080008@oracle.com> <545B6F58.2000907@oracle.com> <546CC3FE.7070105@oracle.com> Message-ID: <547E05DD.2090607@oracle.com> Hi, After some further discussion we the GC team we have decided to split up this patch further to make it easier to push. Since this patch covers all GCs and multiple changes are on their way in creating conflicts in the different GCs it is hard to push this in a single commit. So to make sure this moves forward and reduce contention we decided to split it up in 4 pieces. 1. Event Implementation 2. Support for PS and ParOld 3. Support for CMS 4. Support for G1 I have created sub-tasks for each of these in the JDK-8055845. I'm working on the first step and will send out a separate review for that later today and the others will follow later. Cheers, Staffan On 11/19/2014 08:23 AM, Staffan Friberg wrote: > Hi, > > Erik and Tomas asked me to separate the G1 changes which was pushed > separately in JDK-8064473. > Erik also had some further comments offline that I have taken care of. > > Here is the new webrev, cr.openjdk.java.net/~sfriberg/8055845/webrev.06 > > Thanks, > Staffan > > > On 11/06/2014 01:53 PM, Bengt Rutisson wrote: >> >> >> On 2014-11-06 14:00, Staffan Friberg wrote: >>> Good catch, fixed. >>> >>> // Too large; allocate the object individually. >>> obj = sp->par_allocate(word_sz); >>> if (obj != NULL) { >>> gc_tracer()->report_promotion_outside_plab_event(old, word_sz, age, >>> false); >>> } >>> >>> Please let me know if anyone wants a full new webrev with this. >> >> >> Looks good. Reviewed. >> >> Bengt >> >>> >>> Thanks, >>> Staffan >>> >>> >>> On 11/06/2014 12:01 PM, Bengt Rutisson wrote: >>>> >>>> Hi Staffan, >>>> >>>> On 2014-11-06 11:12, Staffan Friberg wrote: >>>>> Hi, >>>>> >>>>> After further off list discussion it was decided to keep the >>>>> gc_tracer in par_promote as is. >>>>> >>>>> I have uploaded a new webrev, >>>>> http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05 >>>>> >>>>> The main change here is a rewrite of the G1 code which is cleaner >>>>> and also reuses the read age. By sending the markOop down through >>>>> the call we can now trust the read age and do not need to reread >>>>> it when incrementing which improves the YC performance slightly as >>>>> it avoids the rather complex bit extraction. >>>> >>>> >>>> Looks good to me. One detail in parNewGeneration.cpp: >>>> >>>> 274 } else { >>>> 275 // Too large; allocate the object individually. >>>> 276 gc_tracer()->report_promotion_outside_plab_event(old, word_sz, >>>> age, false); >>>> 277 obj = sp->par_allocate(word_sz); >>>> 278 } >>>> >>>> Seems like par_allocate() return NULL. Maybe we should check that >>>> before reporting the event. Similarly to what you do in the other >>>> GCs, for example G1: >>>> >>>> g1Allocator.cpp >>>> >>>> 141 obj = _g1h->par_allocate_during_gc(purpose, word_sz, context); >>>> 142 if (obj != NULL >>>> 143 && >>>> _g1h->_gc_tracer_stw->should_report_promotion_outside_plab_event()) { >>>> 144 bool tenured = >>>> _g1h->heap_region_containing_raw(obj)->is_old(); >>>> 145 _g1h->_gc_tracer_stw->report_promotion_outside_plab_event(old, >>>> word_sz, >>>> 146 age, tenured); >>>> 147 } >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> Staffan >>>>> >>>>> On 09/15/2014 02:06 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> psPromotionManager.inline.hpp >>>>>> >>>>>> I think the PSPromotionManager::copy_to_survivor_space() might >>>>>> send multiple events. If the allocation to the young gen fails we >>>>>> will fall through to do an old gen allocation. But we send the >>>>>> events before we realize that the allocation has failed, i.e. >>>>>> new_obj is NULL. >>>>>> >>>>>> I talked to Erik a bit about how to handle the gc_tracer in >>>>>> par_promote. He'll get back to you with some thoughts on that. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>> On 2014-09-06 00:20, Staffan Friberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have uploaded a new webrev here, >>>>>>> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >>>>>>> >>>>>>> It contains several changes >>>>>>> >>>>>>> - Split event into two events (PromoteObjectInNewPLAB, >>>>>>> PromoteObjectOutsidePLAB) >>>>>>> - Moved events to "vm/gc/detailed/PromoteObject..." >>>>>>> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >>>>>>> - Not sure if the way I do it with passing the >>>>>>> ParNewTracer is the best solution, please let me know if you >>>>>>> have an idea how to improve it >>>>>>> - Simplified the G1 code to avoid sending age and having a >>>>>>> single call site >>>>>>> - Fixed so that the generated event has size information in >>>>>>> bytes rather than words >>>>>>> >>>>>>> Thanks for offline comments and suggestions from Dmitry and Thomas. >>>>>>> >>>>>>> Cheers, >>>>>>> Staffan >>>>>>> >>>>>>> On 08/29/2014 03:32 PM, Staffan Friberg wrote: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>> On 08/28/2014 11:34 PM, Erik Helin wrote: >>>>>>>>> (it seems like we lost hotspot-gc-dev at openjdk.java.net >>>>>>>>> somewhere in this thread, I'm adding it back) >>>>>>>>> >>>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>>> Hi Erik, >>>>>>>>>> >>>>>>>>>> Thanks for the comments. >>>>>>>>>>> - Aren't the events for promotion to the tenured generation >>>>>>>>>>> (SerialOld) >>>>>>>>>>> and the CMS generation missing? >>>>>>>>>> The reason for leaving out these two, Serial completely and CMS >>>>>>>>>> promotion, was due to that neither as far as I understand >>>>>>>>>> make use of >>>>>>>>>> PLABs. >>>>>>>>> >>>>>>>>> I might be wrong here, but looking at the function >>>>>>>>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it >>>>>>>>> looks to me like SerialOld is using PLABs when ParNew is >>>>>>>>> promoting objects from young to old. >>>>>>>>> >>>>>>>>> As for CMS, looking at >>>>>>>>> ConcurrentMarkSweepGeneration::par_promote (in >>>>>>>>> concurrentMarkSweepGeneration.cpp) it seems like each >>>>>>>>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace >>>>>>>>> Local Allocation Buffer) that is a thread-local allocation >>>>>>>>> buffer. See compactibleFreeListSpace.{hpp,cpp} for more details. >>>>>>>>> >>>>>>>>> Given this, I think we should add events for Serial and CMS as >>>>>>>>> well. >>>>>>>>> >>>>>>>> >>>>>>>> Ok I see what you mean with CMS, basically the equivalent to >>>>>>>> getting a PLAB would be when we refill the CFLS_LAB in the >>>>>>>> alloc function. It still does the allocation to a small memory >>>>>>>> (~ size of object) area from the freelist, but at least we did >>>>>>>> extra work to refill the local CFLS_LAB. Need to do some >>>>>>>> analysis to see how often we refill so the overhead doesn't get >>>>>>>> too high. >>>>>>>> The only issue I run into is how I can in a nice way get access >>>>>>>> to the ParNewTracer from ParNewGeneration to call the report >>>>>>>> function. Let's sync up next week and see how it can be solved. >>>>>>>> >>>>>>>> The tenured GC requires something similar to be supported, >>>>>>>> however since ParNewGC is deprecated for usage without CMS in >>>>>>>> JDK 8 we might want to skip that combination. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>>>> - Would it make sense to differentiate, either by separate >>>>>>>>>>> events or by >>>>>>>>>>> a field in a event, between promotions to to-space and to >>>>>>>>>>> the old >>>>>>>>>>> generation? >>>>>>>>>>> - The are two events for TLAB allocations, >>>>>>>>>>> java/object_alloc_in_new_TLAB and >>>>>>>>>>> java/object_alloc_outside_TLAB. >>>>>>>>>>> What do you think about using two events for PLAB >>>>>>>>>>> allocations as well: >>>>>>>>>>> - java/object_alloc_in_new_PLAB >>>>>>>>>>> - java/object_alloc_outside_PLAB >>>>>>>>>> I think this is a matter of taste and probably how similar we >>>>>>>>>> want the >>>>>>>>>> event to be to the existing allocation event. I personally >>>>>>>>>> prefer a >>>>>>>>>> single event but if the GC team and serviceability team feel >>>>>>>>>> it would be >>>>>>>>>> better to have two I can certainly rewrite. The reason for me >>>>>>>>>> preferring >>>>>>>>>> a single event is just ease of analysis, you can easily >>>>>>>>>> filter a list of >>>>>>>>>> events on a field, it is harder to merge two different events >>>>>>>>>> with >>>>>>>>>> different fields and work with them in an straight forward >>>>>>>>>> fashion. >>>>>>>>>> >>>>>>>>>> Any general preference for having a single or multiple events? >>>>>>>>> >>>>>>>>> I would prefer to have two events in this case and try to >>>>>>>>> follow the existing allocation events as much as possible >>>>>>>>> (both in naming and in style). Keeping the tenured field (I >>>>>>>>> missed it the first time I read the patch) is good. >>>>>>>>> >>>>>>>> Yes, tenured would be independent of having two events, only >>>>>>>> PLAB size and directAllocation would be affected when having >>>>>>>> two event types. >>>>>>>> >>>>>>>> *Erik Gahlin*, any preference from your end? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>>>> - In PSPromotionManager, instead of utilizing the C++ >>>>>>>>>>> friendship with >>>>>>>>>>> PSScavenge, should we add a getter function for the >>>>>>>>>>> gc_tracer? >>>>>>>>>> Created a getter function. >>>>>>>>> >>>>>>>>> Thanks! If you make report_promotion_sample const, then the >>>>>>>>> getter can return a const ParallelScavengeTracer*, right? >>>>>>>>> >>>>>>>> Done >>>>>>>> >>>>>>>> //Staffan >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.friberg at oracle.com Tue Dec 2 18:50:29 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 10:50:29 -0800 Subject: RFR: JDK-8066441 - Add PLAB trace event Message-ID: <547E09F5.9050408@oracle.com> Hi, As noted in the original thread [1] about this event we split up the commit in 4 different steps. This is the first step that only adds the event and methods to send them, but the usage will be added separately for the 3 GCs using PLABs. Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 Thanks, Staffan [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html From dmitry.samersoff at oracle.com Tue Dec 2 19:14:58 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 02 Dec 2014 22:14:58 +0300 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending Message-ID: <547E0FB2.3060402@oracle.com> Please review the small fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ Added more missed exception checks to sadis.c -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yekaterina.kantserova at oracle.com Tue Dec 2 19:22:46 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 2 Dec 2014 11:22:46 -0800 (PST) Subject: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent Message-ID: Hi, Could I please have a review of this small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8044591 webrev: http://cr.openjdk.java.net/~ykantser/8044591/webrev.00/ Thanks, Katja From staffan.larsen at oracle.com Tue Dec 2 19:51:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 2 Dec 2014 20:51:53 +0100 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <547E0FB2.3060402@oracle.com> References: <547E0FB2.3060402@oracle.com> Message-ID: <5ABF6FE5-C91B-4C06-9D2E-539BE18AA594@oracle.com> These two lines are wrong. The "!= NULL? should not be there: 241 if (!(*env)->ExceptionOccurred(env) != NULL) { 255 if (!(*env)->ExceptionOccurred(env) != NULL) { Otherwise looks good. /Staffan > On 2 dec 2014, at 20:14, Dmitry Samersoff wrote: > > Please review the small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ > > Added more missed exception checks to sadis.c > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Tue Dec 2 19:54:49 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 2 Dec 2014 20:54:49 +0100 Subject: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent In-Reply-To: References: Message-ID: <59E4D3A8-4E2E-40E8-8A15-533CD4E90FFF@oracle.com> Looks good, but the test also needs to be removed from ProblemList.txt. /Staffan > On 2 dec 2014, at 20:22, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8044591 > webrev: http://cr.openjdk.java.net/~ykantser/8044591/webrev.00/ > > Thanks, > Katja From yekaterina.kantserova at oracle.com Tue Dec 2 20:12:34 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 2 Dec 2014 12:12:34 -0800 (PST) Subject: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent Message-ID: <34ded636-8f32-4c4b-bf5f-ae5a236624c6@default> Right! Thank you for the catch! // Katja ----- Original Message ----- From: staffan.larsen at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Tuesday, December 2, 2014 8:54:53 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent Looks good, but the test also needs to be removed from ProblemList.txt. /Staffan > On 2 dec 2014, at 20:22, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8044591 > webrev: http://cr.openjdk.java.net/~ykantser/8044591/webrev.00/ > > Thanks, > Katja From dmitry.samersoff at oracle.com Tue Dec 2 21:47:59 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 03 Dec 2014 00:47:59 +0300 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <5ABF6FE5-C91B-4C06-9D2E-539BE18AA594@oracle.com> References: <547E0FB2.3060402@oracle.com> <5ABF6FE5-C91B-4C06-9D2E-539BE18AA594@oracle.com> Message-ID: <547E338F.3070205@oracle.com> Staffan, Thanks! Will fix it. -Dmitry On 2014-12-02 22:51, Staffan Larsen wrote: > These two lines are wrong. The "!= NULL? should not be there: > > 241 if (!(*env)->ExceptionOccurred(env) != NULL) { > 255 if (!(*env)->ExceptionOccurred(env) != NULL) { > > Otherwise looks good. > > /Staffan > >> On 2 dec 2014, at 20:14, Dmitry Samersoff wrote: >> >> Please review the small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >> >> Added more missed exception checks to sadis.c >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Tue Dec 2 22:24:13 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 02 Dec 2014 14:24:13 -0800 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <547E0FB2.3060402@oracle.com> References: <547E0FB2.3060402@oracle.com> Message-ID: <547E3C0D.5040307@oracle.com> Dmitry, It is good in general modulo Staffan's comments. There are some inconsistencies: - the ExceptionOccurred(env) is compared to != NULL (which make the logic more complex) in some places and no such comparison (implicit comparison instead) in others - two different forms of check/action are used: - (*env)->ExceptionOccurred(env) and - !(*env)->ExceptionOccurred(env) I'd suggest to do it the same way and always return the "default" value if an exception occurred. It will make the logic more flat and clear. Otherwise, we have to think what exact value is returned in exception occurred cases like at lines 241, 255. The comment // OOM is used inconsistently too. Thanks, Serguei On 12/2/14 11:14 AM, Dmitry Samersoff wrote: > Please review the small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ > > Added more missed exception checks to sadis.c > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Dec 3 07:48:17 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 02 Dec 2014 23:48:17 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <547D265A.20005@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> Message-ID: <547EC041.4000103@oracle.com> The fix still looks good to me. Thanks, Serguei On 12/1/14 6:39 PM, Chris Plummer wrote: > Sorry about the long delay in getting back to this. I ran into two > separate JPRT issues that were preventing me from testing these > changes, plus I was on vacation last week. Here's an updated webrev. > I'm not sure where we left things, so I'll just say what's changed > since the original version: > > 1. Rewrote the test to be in Java instead of a shell script. > 2. Moved the test from hotspot/test/runtime/memory to > jdk/test/tools/launcher > 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to override > the default 32k minimum value. > > https://bugs.openjdk.java.net/browse/JDK-6762191 > http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ > > thanks, > > Chris > > On 11/19/14 7:52 AM, Chris Plummer wrote: >> On 11/19/14 2:12 AM, David Holmes wrote: >>> On 19/11/2014 6:49 PM, Chris Plummer wrote: >>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k >>>> references, and also moved the test from hotspot/test/runtime to >>>> jdk/test/tools/launcher as David requested. That required some >>>> adjustments to the test script, since test_env.sh does not exist in >>>> jdk/test, so I had to pull in the bits I needed into the script. >>> >>> Is there a reason this needs a shell script instead of using the >>> testlibrary tools to launch the VM and check the output? >> Not that I'm aware of. I guess I just really didn't look at what it >> would take to make it all in java. I'll have a look at java examples >> and convert it. >> >> Chris >>> >>> Sorry that should have been mentioned much earlier. >>> >>> David >>> >>> >>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ >>>> >>>> I still need to rerun through JPRT. I'll do so once there are no more >>>> suggested changes. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 11/18/14 2:08 PM, Chris Plummer wrote: >>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes is in >>>>> java.c. >>>>> >>>>> Chris >>>>> >>>>> On 11/12/14 6:43 PM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> Sorry for the delay. >>>>>> >>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm still looking for reviewers. >>>>>> >>>>>> As the change is to the launcher it needs to be reviewed by the >>>>>> launcher owner - which I think is serviceability (though also cc'd >>>>>> Kumar :) ). >>>>>> >>>>>> Launcher change, and your rationale, seems okay to me. I'd probably >>>>>> put the test in to jdk/test/tools/launcher/ though. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>>>>>> This is an initial review for 6762191. I'm guessing there will be >>>>>>>> recommendations to fix in a different way, but thought this >>>>>>>> would be a >>>>>>>> good time to start the discussion. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>>>>>> >>>>>>>> The bug is that if the -Xss size is set to something very small >>>>>>>> (like >>>>>>>> 16k), on linux there will be a crash due to overwriting the end >>>>>>>> of the >>>>>>>> stack. This happens before hotspot can compute its stack needs and >>>>>>>> verify that the stack is big enough. >>>>>>>> >>>>>>>> It didn't seem viable to move the hotspot stack size check >>>>>>>> earlier. It >>>>>>>> depends on too much other work done before that point, and the >>>>>>>> changes >>>>>>>> would have been disruptive. The stack size check is currently >>>>>>>> done in >>>>>>>> os::init_2(). >>>>>>>> >>>>>>>> What is needed is a check before the thread is created. That >>>>>>>> way we >>>>>>>> can create a thread with a big enough stack to handle all needs >>>>>>>> up to >>>>>>>> the point of the check in os::init_2(). This initial check does >>>>>>>> not >>>>>>>> need to be the final check. It just needs to confirm that we have >>>>>>>> enough stack to get us to the check in os::init_2(). >>>>>>>> >>>>>>>> I decided to check in java.c if the -Xss size is too small, and >>>>>>>> set it >>>>>>>> to a larger size if it is. I hard coded this size to 32k (I'll >>>>>>>> explain >>>>>>>> why 32k later). I suspect this is the part that will result in >>>>>>>> some >>>>>>>> debate. If you have better suggestions let me know. If it does >>>>>>>> stay >>>>>>>> here, then probably the 32k needs to be a #define, and maybe >>>>>>>> even an >>>>>>>> OS porting interface, but I'm not sure where to put it. >>>>>>>> >>>>>>>> The reason I chose 32k is because this is big enough for all >>>>>>>> platforms >>>>>>>> to get to the stack size check in os::init_2(). It is also smaller >>>>>>>> than the actual minimum stack size allowed on any platform. 32-bit >>>>>>>> windows has the smallest requirement at 64k. I add some printfs to >>>>>>>> print the minimum stack requirement, and then ran a simple >>>>>>>> JTReg test >>>>>>>> with every JPRT supported platform to get the results. >>>>>>>> >>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>>>>>> -Xss32k, and -XXss, where is the size from the >>>>>>>> error message produced by the JVM, such as in the following: >>>>>>>> >>>>>>>> $ java -Xss32k -version >>>>>>>> The stack size specified is too small, Specify at least 100k >>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>> >>>>>>>> I ran this test through JPRT on all platforms, and they all pass. >>>>>>>> >>>>>>>> One thing to point out is that Windows behaves a bit different >>>>>>>> than >>>>>>>> the other platforms. It always rounds the stack size up to a >>>>>>>> multiple >>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so >>>>>>>> there >>>>>>>> is no error produced in this case. However, on 32-bit Windows >>>>>>>> with C2, >>>>>>>> 68k is the minimum, so an error is produced since the stack >>>>>>>> will only >>>>>>>> be 64k. There is no bug here. It's just a bit confusing. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>> >>>>> >>>> >> > From erik.helin at oracle.com Wed Dec 3 09:19:30 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 3 Dec 2014 10:19:30 +0100 Subject: RFR: JDK-8066441 - Add PLAB trace event In-Reply-To: <547E09F5.9050408@oracle.com> References: <547E09F5.9050408@oracle.com> Message-ID: <20141203091929.GD5786@ehelin.jrpg.bea.com> On 2014-12-02, Staffan Friberg wrote: > Hi, > > As noted in the original thread [1] about this event we split up the commit > in 4 different steps. This is the first step that only adds the event and > methods to send them, but the usage will be added separately for the 3 GCs > using PLABs. > > Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 > Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 Looks good, Reviewed. Thanks, Erik > Thanks, > Staffan > > [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html > From thomas.schatzl at oracle.com Wed Dec 3 09:21:52 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Dec 2014 10:21:52 +0100 Subject: RFR: JDK-8066441 - Add PLAB trace event In-Reply-To: <547E09F5.9050408@oracle.com> References: <547E09F5.9050408@oracle.com> Message-ID: <1417598512.3312.6.camel@oracle.com> On Tue, 2014-12-02 at 10:50 -0800, Staffan Friberg wrote: > Hi, > > As noted in the original thread [1] about this event we split up the > commit in 4 different steps. This is the first step that only adds the > event and methods to send them, but the usage will be added separately > for the 3 GCs using PLABs. > > Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 > Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 > > Thanks, > Staffan > > [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html > Looks good. Thanks. Thomas From yekaterina.kantserova at oracle.com Wed Dec 3 10:01:14 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 03 Dec 2014 11:01:14 +0100 Subject: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <34ded636-8f32-4c4b-bf5f-ae5a236624c6@default> References: <34ded636-8f32-4c4b-bf5f-ae5a236624c6@default> Message-ID: <547EDF6A.80607@oracle.com> The new webrev can be found here: http://cr.openjdk.java.net/~ykantser/8044591/webrev.02/ // Katja On 12/02/2014 09:12 PM, Yekaterina Kantserova wrote: > Right! Thank you for the catch! > > // Katja > > ----- Original Message ----- > From: staffan.larsen at oracle.com > To: yekaterina.kantserova at oracle.com > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, December 2, 2014 8:54:53 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent > > Looks good, but the test also needs to be removed from ProblemList.txt. > > /Staffan > >> On 2 dec 2014, at 20:22, Yekaterina Kantserova wrote: >> >> Hi, >> >> Could I please have a review of this small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8044591 >> webrev: http://cr.openjdk.java.net/~ykantser/8044591/webrev.00/ >> >> Thanks, >> Katja From frederic.parain at oracle.com Wed Dec 3 10:04:38 2014 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 03 Dec 2014 11:04:38 +0100 Subject: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent In-Reply-To: References: Message-ID: <547EE036.5070108@oracle.com> Looks good to me, Thank you for fixing it. Fred On 12/02/2014 08:22 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8044591 > webrev: http://cr.openjdk.java.net/~ykantser/8044591/webrev.00/ > > Thanks, > Katja > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From staffan.larsen at oracle.com Wed Dec 3 10:09:20 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 3 Dec 2014 11:09:20 +0100 Subject: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <547EDF6A.80607@oracle.com> References: <34ded636-8f32-4c4b-bf5f-ae5a236624c6@default> <547EDF6A.80607@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 3 dec 2014, at 11:01, Yekaterina Kantserova wrote: > > The new webrev can be found here: http://cr.openjdk.java.net/~ykantser/8044591/webrev.02/ > > // Katja > > > On 12/02/2014 09:12 PM, Yekaterina Kantserova wrote: >> Right! Thank you for the catch! >> >> // Katja >> >> ----- Original Message ----- >> From: staffan.larsen at oracle.com >> To: yekaterina.kantserova at oracle.com >> Cc: serviceability-dev at openjdk.java.net >> Sent: Tuesday, December 2, 2014 8:54:53 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent >> >> Looks good, but the test also needs to be removed from ProblemList.txt. >> >> /Staffan >> >>> On 2 dec 2014, at 20:22, Yekaterina Kantserova wrote: >>> >>> Hi, >>> >>> Could I please have a review of this small fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8044591 >>> webrev: http://cr.openjdk.java.net/~ykantser/8044591/webrev.00/ >>> >>> Thanks, >>> Katja > From erik.gahlin at oracle.com Wed Dec 3 10:13:51 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 03 Dec 2014 11:13:51 +0100 Subject: RFR: JDK-8066441 - Add PLAB trace event In-Reply-To: <547E09F5.9050408@oracle.com> References: <547E09F5.9050408@oracle.com> Message-ID: <547EE25F.6080003@oracle.com> Looks good! Staffan Friberg skrev 02/12/14 19:50: > Hi, > > As noted in the original thread [1] about this event we split up the > commit in 4 different steps. This is the first step that only adds the > event and methods to send them, but the usage will be added separately > for the 3 GCs using PLABs. > > Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 > Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 > > Thanks, > Staffan > > [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html > > From yekaterina.kantserova at oracle.com Wed Dec 3 10:47:35 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 03 Dec 2014 11:47:35 +0100 Subject: RFR(XS): 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <547EE036.5070108@oracle.com> References: <547EE036.5070108@oracle.com> Message-ID: <547EEA47.8070707@oracle.com> Staffan, Fredric, thanks for your reviews! // Katja On 12/03/2014 11:04 AM, Frederic Parain wrote: > Looks good to me, > > Thank you for fixing it. > > Fred > > On 12/02/2014 08:22 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8044591 >> webrev: http://cr.openjdk.java.net/~ykantser/8044591/webrev.00/ >> >> Thanks, >> Katja >> > From dmitry.samersoff at oracle.com Wed Dec 3 11:39:23 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 03 Dec 2014 14:39:23 +0300 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. In-Reply-To: <5475DB63.2000805@oracle.com> References: <5370E26B.3030509@oracle.com> <537B3921.2090402@oracle.com> <352D5134-6A27-4257-AC6A-9EF041288830@oracle.com> <5380E426.5080904@oracle.com> <546E3510.3010606@oracle.com> <5475DB63.2000805@oracle.com> Message-ID: <547EF66B.5060204@oracle.com> Kevin, Looks good for me! -Dmitry On 2014-11-26 16:53, KEVIN WALLS wrote: > > ...and an update to the webrev in the same place that also checks the > SELinux deny_ptrace flag, another reason you can get a permission denied > error and fail the test. > > http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ > > Thanks > Kevin > > > On 20/11/2014 18:38, KEVIN WALLS wrote: >> Hi, >> >> I'm resurrecting this thread to revisit this testcase, the one that >> fails if not in an environment where an SA attach is permitted (which >> is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac >> systems as a non-root user). >> >> There are times when we want to check if an SA attach is likely to >> work, so in the following webrev I've put that in the testlibrary. >> >> In doing this I now realise that heap dumping with jmap/sa is broken, >> as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416 >> >> I won't remove the @ignore in this change, but it would make sense to >> me to do the fix below, including backporting to places where jmap -F >> still works. >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8039995 >> >> Thanks >> Kevin >> >> >> >> >> On 24/05/2014 19:25, Kevin Walls wrote: >>> >>> Thanks Peter, and thanks Dmitry - >>> >>> So another thread on this has started about why such a test runs in >>> an environment that can't expected to attach to its own processes >>> anyway: seems that some test systems permit that, and some run as a >>> user that can't necessarily expect to have that ability. >>> >>> (Dmitry I'm not sure about exiting with that error value? If that's >>> something people are meant to know about I have missed it. But the >>> test would fail if jmap didn't create the heap dump file, i.e. if it >>> fails but doesn't exit with the right code.) >>> >>> For the moment I'll wait on that other information for whether this >>> needs to be fixed in the test... >>> >>> Thanks! >>> Kevin >>> >>> >>> >>> >>> On 23/05/14 12:00, Peter Allwin wrote: >>>> Looks good to me! >>>> >>>> >>>> Thanks for looking at this Kevin, >>>> /peter >>>> >>>> On 20 May 2014, at 13:14, Kevin Walls wrote: >>>> >>>>> Hi - any comments? 8-) >>>>> >>>>> On 12/05/14 16:02, Kevin Walls wrote >>>>>> Hi, >>>>>> >>>>>> I'd like to get a review of this test change. It assumed that >>>>>> jmap would have permission to run on a process that the test >>>>>> itself created, but this is not necessarily the case. >>>>>> >>>>>> Here I'm considering it OK to skip (pass) the test where jmap >>>>>> fails to attach. The test itself was not platform-specific and as >>>>>> long as we have other platforms where jmap step will work, we are >>>>>> testing for this problem. >>>>>> >>>>>> bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ >>>>>> >>>>>> Thanks >>>>>> Kevin >>> >> > -- 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 peter.allwin at oracle.com Wed Dec 3 12:04:36 2014 From: peter.allwin at oracle.com (Peter Allwin) Date: Wed, 3 Dec 2014 13:04:36 +0100 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. In-Reply-To: <5475DB63.2000805@oracle.com> References: <5370E26B.3030509@oracle.com> <537B3921.2090402@oracle.com> <352D5134-6A27-4257-AC6A-9EF041288830@oracle.com> <5380E426.5080904@oracle.com> <546E3510.3010606@oracle.com> <5475DB63.2000805@oracle.com> Message-ID: <90672964-8DD8-4CBD-9432-2D3D9D9843BC@oracle.com> Looks good to me! Thanks, /peter > On 26 Nov 2014, at 14:53, KEVIN WALLS wrote: > > > ...and an update to the webrev in the same place that also checks the SELinux deny_ptrace flag, another reason you can get a permission denied error and fail the test. > > http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ > > Thanks > Kevin > > > On 20/11/2014 18:38, KEVIN WALLS wrote: >> Hi, >> >> I'm resurrecting this thread to revisit this testcase, the one that fails if not in an environment where an SA attach is permitted (which is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac systems as a non-root user). >> >> There are times when we want to check if an SA attach is likely to work, so in the following webrev I've put that in the testlibrary. >> >> In doing this I now realise that heap dumping with jmap/sa is broken, as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416 >> >> I won't remove the @ignore in this change, but it would make sense to me to do the fix below, including backporting to places where jmap -F still works. >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8039995 >> >> Thanks >> Kevin >> >> >> >> >> On 24/05/2014 19:25, Kevin Walls wrote: >>> >>> Thanks Peter, and thanks Dmitry - >>> >>> So another thread on this has started about why such a test runs in an environment that can't expected to attach to its own processes anyway: seems that some test systems permit that, and some run as a user that can't necessarily expect to have that ability. >>> >>> (Dmitry I'm not sure about exiting with that error value? If that's something people are meant to know about I have missed it. But the test would fail if jmap didn't create the heap dump file, i.e. if it fails but doesn't exit with the right code.) >>> >>> For the moment I'll wait on that other information for whether this needs to be fixed in the test... >>> >>> Thanks! >>> Kevin >>> >>> >>> >>> >>> On 23/05/14 12:00, Peter Allwin wrote: >>>> Looks good to me! >>>> >>>> >>>> Thanks for looking at this Kevin, >>>> /peter >>>> >>>> On 20 May 2014, at 13:14, Kevin Walls wrote: >>>> >>>>> Hi - any comments? 8-) >>>>> >>>>> On 12/05/14 16:02, Kevin Walls wrote >>>>>> Hi, >>>>>> >>>>>> I'd like to get a review of this test change. It assumed that jmap would have permission to run on a process that the test itself created, but this is not necessarily the case. >>>>>> >>>>>> Here I'm considering it OK to skip (pass) the test where jmap fails to attach. The test itself was not platform-specific and as long as we have other platforms where jmap step will work, we are testing for this problem. >>>>>> >>>>>> bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ >>>>>> >>>>>> Thanks >>>>>> Kevin >>> >> > From kevin.walls at oracle.com Wed Dec 3 12:05:30 2014 From: kevin.walls at oracle.com (KEVIN WALLS) Date: Wed, 03 Dec 2014 12:05:30 +0000 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. In-Reply-To: <547EF66B.5060204@oracle.com> References: <5370E26B.3030509@oracle.com> <537B3921.2090402@oracle.com> <352D5134-6A27-4257-AC6A-9EF041288830@oracle.com> <5380E426.5080904@oracle.com> <546E3510.3010606@oracle.com> <5475DB63.2000805@oracle.com> <547EF66B.5060204@oracle.com> Message-ID: <547EFC8A.7090609@oracle.com> Thanks Dmitry and Peter! On 03/12/2014 11:39, Dmitry Samersoff wrote: > Kevin, > > Looks good for me! > > -Dmitry > > On 2014-11-26 16:53, KEVIN WALLS wrote: >> ...and an update to the webrev in the same place that also checks the >> SELinux deny_ptrace flag, another reason you can get a permission denied >> error and fail the test. >> >> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >> >> Thanks >> Kevin >> >> >> On 20/11/2014 18:38, KEVIN WALLS wrote: >>> Hi, >>> >>> I'm resurrecting this thread to revisit this testcase, the one that >>> fails if not in an environment where an SA attach is permitted (which >>> is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac >>> systems as a non-root user). >>> >>> There are times when we want to check if an SA attach is likely to >>> work, so in the following webrev I've put that in the testlibrary. >>> >>> In doing this I now realise that heap dumping with jmap/sa is broken, >>> as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416 >>> >>> I won't remove the @ignore in this change, but it would make sense to >>> me to do the fix below, including backporting to places where jmap -F >>> still works. >>> >>> webrev >>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >>> >>> bug >>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>> >>> Thanks >>> Kevin >>> >>> >>> >>> >>> On 24/05/2014 19:25, Kevin Walls wrote: >>>> Thanks Peter, and thanks Dmitry - >>>> >>>> So another thread on this has started about why such a test runs in >>>> an environment that can't expected to attach to its own processes >>>> anyway: seems that some test systems permit that, and some run as a >>>> user that can't necessarily expect to have that ability. >>>> >>>> (Dmitry I'm not sure about exiting with that error value? If that's >>>> something people are meant to know about I have missed it. But the >>>> test would fail if jmap didn't create the heap dump file, i.e. if it >>>> fails but doesn't exit with the right code.) >>>> >>>> For the moment I'll wait on that other information for whether this >>>> needs to be fixed in the test... >>>> >>>> Thanks! >>>> Kevin >>>> >>>> >>>> >>>> >>>> On 23/05/14 12:00, Peter Allwin wrote: >>>>> Looks good to me! >>>>> >>>>> >>>>> Thanks for looking at this Kevin, >>>>> /peter >>>>> >>>>> On 20 May 2014, at 13:14, Kevin Walls wrote: >>>>> >>>>>> Hi - any comments? 8-) >>>>>> >>>>>> On 12/05/14 16:02, Kevin Walls wrote >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to get a review of this test change. It assumed that >>>>>>> jmap would have permission to run on a process that the test >>>>>>> itself created, but this is not necessarily the case. >>>>>>> >>>>>>> Here I'm considering it OK to skip (pass) the test where jmap >>>>>>> fails to attach. The test itself was not platform-specific and as >>>>>>> long as we have other platforms where jmap step will work, we are >>>>>>> testing for this problem. >>>>>>> >>>>>>> bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ >>>>>>> >>>>>>> Thanks >>>>>>> Kevin > From dmitry.samersoff at oracle.com Wed Dec 3 12:06:49 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 03 Dec 2014 15:06:49 +0300 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <547E3C0D.5040307@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> Message-ID: <547EFCD9.5020301@oracle.com> Serguei, Updated webrev http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ -Dmitry On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: > Dmitry, > > It is good in general modulo Staffan's comments. > > There are some inconsistencies: > - the ExceptionOccurred(env) is compared to != NULL (which make the > logic more complex) > in some places and no such comparison (implicit comparison instead) > in others > - two different forms of check/action are used: > - (*env)->ExceptionOccurred(env) and > - !(*env)->ExceptionOccurred(env) > > I'd suggest to do it the same way and always return the "default" value > if an exception occurred. > It will make the logic more flat and clear. > Otherwise, we have to think what exact value is returned in exception > occurred cases like at lines 241, 255. > > The comment // OOM is used inconsistently too. > > > Thanks, > Serguei > > > On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >> Please review the small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >> >> Added more missed exception checks to sadis.c >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Wed Dec 3 12:53:11 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 3 Dec 2014 13:53:11 +0100 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. In-Reply-To: <5475DB63.2000805@oracle.com> References: <5370E26B.3030509@oracle.com> <537B3921.2090402@oracle.com> <352D5134-6A27-4257-AC6A-9EF041288830@oracle.com> <5380E426.5080904@oracle.com> <546E3510.3010606@oracle.com> <5475DB63.2000805@oracle.com> Message-ID: 178 public static boolean canPtraceAttachOSX() throws Exception { 179 return userName.equals("root"); 180 } Ptrace isn?t the API that is doing the most vigorous access checks on OS X. Instead the system call task_for_pid() is what causes most of the access denied problems. So perhaps just skipping the ?Ptrace? part of the method name above is good. Then, on OS X again, the root user will indeed av access to other processes, but it?s not the only way. A regular user can also get access if a couple of prerequisites are met: 1) The attaching program is compiled with SecTaskAccess=allowed in Info.plist. We do this for jstack, jinfo and jmap. 2) The attaching program is signed. 3) The user has given permission for taking control of another process via a dialog box that OS X displays. (I think these are all?) Regarding signing above: Oracle signs binaries that we ship with an official certificate, but development binaries are also signed if a certificate called openjdk_codesign is found on the machine where the product is built. Usually one creates a self-signed such certificate if one wants to test the attaching functionality. All this to say that if we only check for root, then it will not be possible to run the tests as a regular user even if you have done 1-3 above. That would be a shame, but perhaps cannot be avoided given the complexity involved. /Staffan > On 26 nov 2014, at 14:53, KEVIN WALLS wrote: > > > ...and an update to the webrev in the same place that also checks the SELinux deny_ptrace flag, another reason you can get a permission denied error and fail the test. > > http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ > > Thanks > Kevin > > > On 20/11/2014 18:38, KEVIN WALLS wrote: >> Hi, >> >> I'm resurrecting this thread to revisit this testcase, the one that fails if not in an environment where an SA attach is permitted (which is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac systems as a non-root user). >> >> There are times when we want to check if an SA attach is likely to work, so in the following webrev I've put that in the testlibrary. >> >> In doing this I now realise that heap dumping with jmap/sa is broken, as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416 >> >> I won't remove the @ignore in this change, but it would make sense to me to do the fix below, including backporting to places where jmap -F still works. >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8039995 >> >> Thanks >> Kevin >> >> >> >> >> On 24/05/2014 19:25, Kevin Walls wrote: >>> >>> Thanks Peter, and thanks Dmitry - >>> >>> So another thread on this has started about why such a test runs in an environment that can't expected to attach to its own processes anyway: seems that some test systems permit that, and some run as a user that can't necessarily expect to have that ability. >>> >>> (Dmitry I'm not sure about exiting with that error value? If that's something people are meant to know about I have missed it. But the test would fail if jmap didn't create the heap dump file, i.e. if it fails but doesn't exit with the right code.) >>> >>> For the moment I'll wait on that other information for whether this needs to be fixed in the test... >>> >>> Thanks! >>> Kevin >>> >>> >>> >>> >>> On 23/05/14 12:00, Peter Allwin wrote: >>>> Looks good to me! >>>> >>>> >>>> Thanks for looking at this Kevin, >>>> /peter >>>> >>>> On 20 May 2014, at 13:14, Kevin Walls wrote: >>>> >>>>> Hi - any comments? 8-) >>>>> >>>>> On 12/05/14 16:02, Kevin Walls wrote >>>>>> Hi, >>>>>> >>>>>> I'd like to get a review of this test change. It assumed that jmap would have permission to run on a process that the test itself created, but this is not necessarily the case. >>>>>> >>>>>> Here I'm considering it OK to skip (pass) the test where jmap fails to attach. The test itself was not platform-specific and as long as we have other platforms where jmap step will work, we are testing for this problem. >>>>>> >>>>>> bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ >>>>>> >>>>>> Thanks >>>>>> Kevin >>> >> > From Alan.Bateman at oracle.com Wed Dec 3 12:56:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Dec 2014 12:56:41 +0000 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <547D265A.20005@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> Message-ID: <547F0889.5050204@oracle.com> On 02/12/2014 02:39, Chris Plummer wrote: > Sorry about the long delay in getting back to this. I ran into two > separate JPRT issues that were preventing me from testing these > changes, plus I was on vacation last week. Here's an updated webrev. > I'm not sure where we left things, so I'll just say what's changed > since the original version: > > 1. Rewrote the test to be in Java instead of a shell script. > 2. Moved the test from hotspot/test/runtime/memory to > jdk/test/tools/launcher > 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to override > the default 32k minimum value. > > https://bugs.openjdk.java.net/browse/JDK-6762191 > http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ This looks to me. A minor comment for java.c is that this code uses 4-space indent (different to hotspot). The test looks okay too, you might just checking the copyright date as I assume was not written in 2010. Also I think the import of java.io.File may be left behind from the previous round. -Alan From staffan.larsen at oracle.com Wed Dec 3 13:01:48 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 3 Dec 2014 14:01:48 +0100 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <547EFCD9.5020301@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> Message-ID: <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> Changes look good. What testing have you done? /Staffan > On 3 dec 2014, at 13:06, Dmitry Samersoff wrote: > > Serguei, > > Updated webrev > > http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ > > -Dmitry > > On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> It is good in general modulo Staffan's comments. >> >> There are some inconsistencies: >> - the ExceptionOccurred(env) is compared to != NULL (which make the >> logic more complex) >> in some places and no such comparison (implicit comparison instead) >> in others >> - two different forms of check/action are used: >> - (*env)->ExceptionOccurred(env) and >> - !(*env)->ExceptionOccurred(env) >> >> I'd suggest to do it the same way and always return the "default" value >> if an exception occurred. >> It will make the logic more flat and clear. >> Otherwise, we have to think what exact value is returned in exception >> occurred cases like at lines 241, 255. >> >> The comment // OOM is used inconsistently too. >> >> >> Thanks, >> Serguei >> >> >> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>> Please review the small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>> >>> Added more missed exception checks to sadis.c >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From chris.hegarty at oracle.com Wed Dec 3 14:40:43 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 03 Dec 2014 14:40:43 +0000 Subject: RFR [9]: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java fails to compile Message-ID: <547F20EB.3000103@oracle.com> The changes in 8035000 [1] changed some common rmi testlibrary classes, RMID.java for one, and this test no longer compiles. The test should call RMID destroy() instead of shutdown(..). ../chhegar/s/jdk/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java:64: error: method shutdown in class RMID cannot be applied to given types; rmid.shutdown(rmidPort); ^ required: no arguments found: int reason: actual and formal argument lists differ in length 1 error diff --git a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java --- a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java +++ b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java @@ -61,7 +61,7 @@ // ignore } } - rmid.shutdown(rmidPort); + rmid.destroy(); } -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8035000 From Alan.Bateman at oracle.com Wed Dec 3 14:41:57 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 03 Dec 2014 14:41:57 +0000 Subject: RFR [9]: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java fails to compile In-Reply-To: <547F20EB.3000103@oracle.com> References: <547F20EB.3000103@oracle.com> Message-ID: <547F2135.3000708@oracle.com> On 03/12/2014 14:40, Chris Hegarty wrote: > : > > diff --git > a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java > b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java > > --- > a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java > +++ > b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java > @@ -61,7 +61,7 @@ > // ignore > } > } > - rmid.shutdown(rmidPort); > + rmid.destroy(); > } I'm sure Stuart does a good "D'oh". The change looks okay to me. -Alan. From dmitry.samersoff at oracle.com Wed Dec 3 15:15:26 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 03 Dec 2014 18:15:26 +0300 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> Message-ID: <547F290E.6030009@oracle.com> Staffan, Only manual smoke check: opened core jstack -v dis couple of addresses -Dmitry On 2014-12-03 16:01, Staffan Larsen wrote: > Changes look good. What testing have you done? > > /Staffan > >> On 3 dec 2014, at 13:06, Dmitry Samersoff wrote: >> >> Serguei, >> >> Updated webrev >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ >> >> -Dmitry >> >> On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> It is good in general modulo Staffan's comments. >>> >>> There are some inconsistencies: >>> - the ExceptionOccurred(env) is compared to != NULL (which make the >>> logic more complex) >>> in some places and no such comparison (implicit comparison instead) >>> in others >>> - two different forms of check/action are used: >>> - (*env)->ExceptionOccurred(env) and >>> - !(*env)->ExceptionOccurred(env) >>> >>> I'd suggest to do it the same way and always return the "default" value >>> if an exception occurred. >>> It will make the logic more flat and clear. >>> Otherwise, we have to think what exact value is returned in exception >>> occurred cases like at lines 241, 255. >>> >>> The comment // OOM is used inconsistently too. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>>> Please review the small fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>>> >>>> Added more missed exception checks to sadis.c >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Wed Dec 3 15:23:08 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 3 Dec 2014 16:23:08 +0100 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <547F290E.6030009@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> <547F290E.6030009@oracle.com> Message-ID: <8034E927-F91B-4BB2-A480-0A399526ED7A@oracle.com> Ok. > On 3 dec 2014, at 16:15, Dmitry Samersoff wrote: > > Staffan, > > Only manual smoke check: > > opened core > > jstack -v > dis couple of addresses > > -Dmitry > > On 2014-12-03 16:01, Staffan Larsen wrote: >> Changes look good. What testing have you done? >> >> /Staffan >> >>> On 3 dec 2014, at 13:06, Dmitry Samersoff wrote: >>> >>> Serguei, >>> >>> Updated webrev >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ >>> >>> -Dmitry >>> >>> On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >>>> Dmitry, >>>> >>>> It is good in general modulo Staffan's comments. >>>> >>>> There are some inconsistencies: >>>> - the ExceptionOccurred(env) is compared to != NULL (which make the >>>> logic more complex) >>>> in some places and no such comparison (implicit comparison instead) >>>> in others >>>> - two different forms of check/action are used: >>>> - (*env)->ExceptionOccurred(env) and >>>> - !(*env)->ExceptionOccurred(env) >>>> >>>> I'd suggest to do it the same way and always return the "default" value >>>> if an exception occurred. >>>> It will make the logic more flat and clear. >>>> Otherwise, we have to think what exact value is returned in exception >>>> occurred cases like at lines 241, 255. >>>> >>>> The comment // OOM is used inconsistently too. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>>>> Please review the small fix. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>>>> >>>>> Added more missed exception checks to sadis.c >>>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From kevin.walls at oracle.com Wed Dec 3 16:17:57 2014 From: kevin.walls at oracle.com (KEVIN WALLS) Date: Wed, 03 Dec 2014 16:17:57 +0000 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. In-Reply-To: References: <5370E26B.3030509@oracle.com> <537B3921.2090402@oracle.com> <352D5134-6A27-4257-AC6A-9EF041288830@oracle.com> <5380E426.5080904@oracle.com> <546E3510.3010606@oracle.com> <5475DB63.2000805@oracle.com> Message-ID: <547F37B5.5010801@oracle.com> Thanks Staffan - Yes, I've updated it to be simply canAttachOSX(). Seems likely we should go ahead with that and possibly revisit the OSX conditions, good to have the method there so we can make it more complete and complex later when/if required. Right now, I think this is suitable for our automated tests, it could be that we are stopping people (you? 8-) ) running this automated test as a non-root user, such tests will not execute, but shouldn't fail... Thanks Kevin On 03/12/2014 12:53, Staffan Larsen wrote: > 178 public static boolean canPtraceAttachOSX() throws Exception { > 179 return userName.equals("root"); > 180 } > > Ptrace isn?t the API that is doing the most vigorous access checks on OS X. Instead the system call task_for_pid() is what causes most of the access denied problems. So perhaps just skipping the ?Ptrace? part of the method name above is good. > > Then, on OS X again, the root user will indeed av access to other processes, but it?s not the only way. A regular user can also get access if a couple of prerequisites are met: > 1) The attaching program is compiled with SecTaskAccess=allowed in Info.plist. We do this for jstack, jinfo and jmap. > 2) The attaching program is signed. > 3) The user has given permission for taking control of another process via a dialog box that OS X displays. > (I think these are all?) > > Regarding signing above: Oracle signs binaries that we ship with an official certificate, but development binaries are also signed if a certificate called openjdk_codesign is found on the machine where the product is built. Usually one creates a self-signed such certificate if one wants to test the attaching functionality. > > All this to say that if we only check for root, then it will not be possible to run the tests as a regular user even if you have done 1-3 above. That would be a shame, but perhaps cannot be avoided given the complexity involved. > > /Staffan > > >> On 26 nov 2014, at 14:53, KEVIN WALLS wrote: >> >> >> ...and an update to the webrev in the same place that also checks the SELinux deny_ptrace flag, another reason you can get a permission denied error and fail the test. >> >> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >> >> Thanks >> Kevin >> >> >> On 20/11/2014 18:38, KEVIN WALLS wrote: >>> Hi, >>> >>> I'm resurrecting this thread to revisit this testcase, the one that fails if not in an environment where an SA attach is permitted (which is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac systems as a non-root user). >>> >>> There are times when we want to check if an SA attach is likely to work, so in the following webrev I've put that in the testlibrary. >>> >>> In doing this I now realise that heap dumping with jmap/sa is broken, as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416 >>> >>> I won't remove the @ignore in this change, but it would make sense to me to do the fix below, including backporting to places where jmap -F still works. >>> >>> webrev >>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >>> >>> bug >>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>> >>> Thanks >>> Kevin >>> >>> >>> >>> >>> On 24/05/2014 19:25, Kevin Walls wrote: >>>> Thanks Peter, and thanks Dmitry - >>>> >>>> So another thread on this has started about why such a test runs in an environment that can't expected to attach to its own processes anyway: seems that some test systems permit that, and some run as a user that can't necessarily expect to have that ability. >>>> >>>> (Dmitry I'm not sure about exiting with that error value? If that's something people are meant to know about I have missed it. But the test would fail if jmap didn't create the heap dump file, i.e. if it fails but doesn't exit with the right code.) >>>> >>>> For the moment I'll wait on that other information for whether this needs to be fixed in the test... >>>> >>>> Thanks! >>>> Kevin >>>> >>>> >>>> >>>> >>>> On 23/05/14 12:00, Peter Allwin wrote: >>>>> Looks good to me! >>>>> >>>>> >>>>> Thanks for looking at this Kevin, >>>>> /peter >>>>> >>>>> On 20 May 2014, at 13:14, Kevin Walls wrote: >>>>> >>>>>> Hi - any comments? 8-) >>>>>> >>>>>> On 12/05/14 16:02, Kevin Walls wrote >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to get a review of this test change. It assumed that jmap would have permission to run on a process that the test itself created, but this is not necessarily the case. >>>>>>> >>>>>>> Here I'm considering it OK to skip (pass) the test where jmap fails to attach. The test itself was not platform-specific and as long as we have other platforms where jmap step will work, we are testing for this problem. >>>>>>> >>>>>>> bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ >>>>>>> >>>>>>> Thanks >>>>>>> Kevin From staffan.friberg at oracle.com Wed Dec 3 17:19:44 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Wed, 03 Dec 2014 09:19:44 -0800 Subject: RFR: JDK-8066441 - Add PLAB trace event In-Reply-To: <1417598512.3312.6.camel@oracle.com> References: <547E09F5.9050408@oracle.com> <1417598512.3312.6.camel@oracle.com> Message-ID: <547F4630.7080506@oracle.com> Thanks for all the reviews. Marcus Larsson has kindly agreed to sponsor the patch. Cheers, Staffan On 12/03/2014 01:21 AM, Thomas Schatzl wrote: > On Tue, 2014-12-02 at 10:50 -0800, Staffan Friberg wrote: >> Hi, >> >> As noted in the original thread [1] about this event we split up the >> commit in 4 different steps. This is the first step that only adds the >> event and methods to send them, but the usage will be added separately >> for the 3 GCs using PLABs. >> >> Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 >> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 >> >> Thanks, >> Staffan >> >> [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html >> > Looks good. Thanks. > > Thomas > > From stuart.marks at oracle.com Wed Dec 3 17:24:39 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 03 Dec 2014 09:24:39 -0800 Subject: RFR [9]: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java fails to compile In-Reply-To: <547F2135.3000708@oracle.com> References: <547F20EB.3000103@oracle.com> <547F2135.3000708@oracle.com> Message-ID: <547F4757.1070402@oracle.com> On 12/3/14 6:41 AM, Alan Bateman wrote: > On 03/12/2014 14:40, Chris Hegarty wrote: >> diff --git >> a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java >> b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java >> --- a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java >> +++ b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java >> @@ -61,7 +61,7 @@ >> // ignore >> } >> } >> - rmid.shutdown(rmidPort); >> + rmid.destroy(); >> } > I'm sure Stuart does a good "D'oh". > > The change looks okay to me. D'oh is right! Sorry about this. I didn't know that there were other dependencies on the RMI test library. Sigh... I guess I should have looked harder. Thanks for cleaning this up. s'marks From maynardj at us.ibm.com Wed Dec 3 18:20:14 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Wed, 03 Dec 2014 12:20:14 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E4DE6.30305@us.ibm.com> Message-ID: <547F545E.7090500@us.ibm.com> On 12/03/2014 02:24 AM, Volker Simonis wrote: > Hi Maynard, > > if you don't mind please post the next mail to the mailing list > thread. I think these problems and discussions may be helpfull for > others as well (e.g. people doing another port). > > On Wed, Dec 3, 2014 at 12:40 AM, Maynard Johnson wrote: >> On 12/01/2014 05:16 PM, Maynard Johnson wrote: >>> On 11/25/2014 12:40 PM, Volker Simonis wrote: >>>> Hi Maynard, >>>> >>>> so here finally comes my version of your change. I've tested 'jstack' >>>> with no, '-F' and '-m' flags on PIDs and core files on BigEndian >>>> Linux/PPC64 and it seems to work quite stable now. I've also done some >>>> basic tests with 'jmap' with no, '-histo' and '-F' flags and 'jinfo'. >>> Hi, Volker, >>> Thank you very much for your help with the patch I posted. >>> I tried out your new patch and my results aren't quite as expected. I wonder >>> if I need to update my source tree as it's a few weeks old by now. Anyway, >>> running 'jstack `which java` core', I usually get something like the following >>> for the thread that's running the actual java app code: >>> >>> --------------------------------- >>> Thread 22585: (state = IN_JAVA, current Java SP = null >>> ) >>> - test.main(java.lang.String[]) @bci=100, line=54, pc=0x00003fff8800953c, Method*=0x00003fff7dc00998 (Interpreted frame) >>> --------------------------------- >>> >>> As you can see, there's no compiled frame output where I expect I should see something. >>> I get this pretty consistently on both BE and LE. I also see the same thing running 'jstack -F ' >>> on BE. But unfortunately, neither 'jstack -F ' nor 'jmap ' are working at all on LE right now; >>> instead, I get the following error (which I'm investigating): >>> >>> Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process >> Hi Volker, >> I discovered that the hotspot debugger's call to ptrace was failing with errno of EPERM. This doesn't make sense >> to me since I'm running both the java app session and the 'jstack -F' session under my normal user account. > > If you're running on Debian/Ubuntu it is probably this issue: > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection > > which can be solved by doing: > > echo 0 > /proc/sys/kernel/yama/ptrace_scope Yes, that was the issue. Thanks for the tip! > > or set ptrace_scope to 0 in /etc/sysctl.d/10-ptrace.conf > > >> But when I ran the 'jstack -F' under root, it worked -- sort of. I get the following stack: >> >> Thread 44376: (state = IN_JAVA) >> - java.lang.String.getChars(int, int, char[], int) @bci=1, line=805 (Compiled frame; information may be imprecise) >> - test.main(java.lang.String[]) @bci=100, line=54 (Interpreted frame) >> >> Line #54 is a call to test.run_test, so I expected to see that in the stack (I was running the test java app with >> "-XX:-Inline"). >> > > I don't think we will ever manage to get this 100% correct. The > problem is that Java stacks are only guaranteed to be walkable at > safepoints. That's what happens when we use plain jstack. 'jstack -F' > or jstak on a core file may catch the threads in a state where sp/pc > are in an inconsistent state. I don't think there's much we can do > about it. I think the corresponding output on Linux/x86 isn't perfect > either. Yes, indeed. I looked more closely at my x86 stack output, and I see what you mean. -Maynard > >> I'll see if I can make more progress tomorrow. >> >> -Maynard >>> >> [snip] >> > From maynardj at us.ibm.com Wed Dec 3 18:33:38 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Wed, 03 Dec 2014 12:33:38 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> Message-ID: <547F5782.1060800@us.ibm.com> On 12/03/2014 02:40 AM, Volker Simonis wrote: > On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson wrote: >> On 12/02/2014 11:45 AM, Volker Simonis wrote: >>> Hi Maynard, >>> >>> did you intentionally answered only to me or can we take the discussion back to the mailing list? >> >> Yes, it was intentional. I figured that if we did indeed have some functional problems to fix, >> we may want to discuss off-list until we agree we're ready for full patch review. I apologize if >> that's not following normal process. Let me know how and when you'd like me to bring this discussion >> back to the list. Hi, Volker, You've answered all of my concerns -- thanks for your patience. Can you please let me know the process for getting the web review moving? >> >>> Please find further comments inline: >>> >>> On Tue, Dec 2, 2014 at 12:16 AM, Maynard Johnson > wrote: >>>> On 11/25/2014 12:40 PM, Volker Simonis wrote: >>>>> Hi Maynard, >>>>> >>>>> so here finally comes my version of your change. I've tested 'jstack' >>>>> with no, '-F' and '-m' flags on PIDs and core files on BigEndian >>>>> Linux/PPC64 and it seems to work quite stable now. I've also done some >>>>> basic tests with 'jmap' with no, '-histo' and '-F' flags and 'jinfo'. >>>> Hi, Volker, >>>> Thank you very much for your help with the patch I posted. >>>> I tried out your new patch and my results aren't quite as expected. I wonder >>>> if I need to update my source tree as it's a few weeks old by now. Anyway, >>>> running 'jstack `which java` core', I usually get something like the following >>>> for the thread that's running the actual java app code: >>> >>> I've cloned today a fresh copy of jdk9-dev, applied the patch and build the images. Everything worked as expected. Could you please also try with a fresh version of jdk9-dev. >> >> OK, I did the same today. >> >>> >>>> >>>> --------------------------------- >>>> Thread 22585: (state = IN_JAVA, current Java SP = null >>>> ) >>>> - test.main(java.lang.String[]) @bci=100, line=54, pc=0x00003fff8800953c, Method*=0x00003fff7dc00998 (Interpreted frame) >>>> --------------------------------- >>>> >>>> As you can see, there's no compiled frame output where I expect I should see something. >>>> I get this pretty consistently on both BE and LE. I also see the same thing running 'jstack -F ' >>>> on BE. >>> >>> That's not unusual. The problem with your example is that it above test.main all the other methods are compiled AND inlined. That means that there's just one physical frame above test.main. If the stack tracing routine can't make sense of the first frame, in not only skips that frame, but also all the virtual java frames which are contained inside this physical frame. You can try to run your example with "-XX:-Inline" to avoid inlining and see deeper stack traces. >> >> Thanks for the tip. Using "-XX:-Inline" does show more stack. Sometimes the stack looks like following: >> >> --------------------------------- >> Thread 18959: (state = IN_JAVA) >> - test.get_my_chars(int, int, char[], java.lang.String, int) @bci=34, line=14 (Compiled frame; information may be imprecise) >> - test.run_test() @bci=63, line=31 (Compiled frame) >> - test.main(java.lang.String[]) @bci=100, line=54 (Interpreted frame) >> --------------------------------- >> >> But usually the stack just has "main" and "run_test", always with the same line numbers, whether or not get_my_chars is included in the stack. But as I mentioned in my earlier note, line #31 in run_test is the first line of a for-loop, not the (expected) call to get_my_chars. >> > > Again, PC to line/BCImapping is only precise at safepoints. There's no > chance to get this 100% right. But that's the same on all > architectures. If you run with -XX:+PrintInlining you will what has > been inlined which may help to interprete the missing parts in a stack > trace which was not taken at a safepoint. > >> In the approximate 10 times that I re-ran my test with the "-XX:-Inline" (sometimes killing it with SIGSEGV to get a core file; sometimes using 'jstack -F'), I twice got an NPE: >> >> java.lang.NullPointerException >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:88) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >> . . . >> >> Line 88 in StackTrace.java is >> >> tty.print(" - " + method.externalNameAndSignature() + >> " @bci=" + vf.getBCI()); >> >> I'll work on debugging this. >> > > Yes, that should be fixed. Maybe we need some more checks if 'method' > and 'vf' are valid. In fact, I'm consistently seeing the same NPE on x86 when I run the java app with "-XX:-Inline" and then do 'jstack -F '. Do you know if there's a bug report open already for this? The jdk9 source on my x86 system was a couple months (or so) old, so I wanted to see if this still fails with current upstream code. I refreshed my source tree (via get_source.sh) and tried to rebuild it, but I got a compile failure. I imagine someone else is already working on that. -Maynard > [snip] From volker.simonis at gmail.com Wed Dec 3 18:43:45 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 3 Dec 2014 19:43:45 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F5782.1060800@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> <547F5782.1060800@us.ibm.com> Message-ID: On Wed, Dec 3, 2014 at 7:33 PM, Maynard Johnson wrote: > On 12/03/2014 02:40 AM, Volker Simonis wrote: >> On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson wrote: >>> On 12/02/2014 11:45 AM, Volker Simonis wrote: >>>> Hi Maynard, >>>> >>>> did you intentionally answered only to me or can we take the discussion back to the mailing list? >>> >>> Yes, it was intentional. I figured that if we did indeed have some functional problems to fix, >>> we may want to discuss off-list until we agree we're ready for full patch review. I apologize if >>> that's not following normal process. Let me know how and when you'd like me to bring this discussion >>> back to the list. > Hi, Volker, > You've answered all of my concerns -- thanks for your patience. Can you please let me know the > process for getting the web review moving? > >>> >>>> Please find further comments inline: >>>> >>>> On Tue, Dec 2, 2014 at 12:16 AM, Maynard Johnson > wrote: >>>>> On 11/25/2014 12:40 PM, Volker Simonis wrote: >>>>>> Hi Maynard, >>>>>> >>>>>> so here finally comes my version of your change. I've tested 'jstack' >>>>>> with no, '-F' and '-m' flags on PIDs and core files on BigEndian >>>>>> Linux/PPC64 and it seems to work quite stable now. I've also done some >>>>>> basic tests with 'jmap' with no, '-histo' and '-F' flags and 'jinfo'. >>>>> Hi, Volker, >>>>> Thank you very much for your help with the patch I posted. >>>>> I tried out your new patch and my results aren't quite as expected. I wonder >>>>> if I need to update my source tree as it's a few weeks old by now. Anyway, >>>>> running 'jstack `which java` core', I usually get something like the following >>>>> for the thread that's running the actual java app code: >>>> >>>> I've cloned today a fresh copy of jdk9-dev, applied the patch and build the images. Everything worked as expected. Could you please also try with a fresh version of jdk9-dev. >>> >>> OK, I did the same today. >>> >>>> >>>>> >>>>> --------------------------------- >>>>> Thread 22585: (state = IN_JAVA, current Java SP = null >>>>> ) >>>>> - test.main(java.lang.String[]) @bci=100, line=54, pc=0x00003fff8800953c, Method*=0x00003fff7dc00998 (Interpreted frame) >>>>> --------------------------------- >>>>> >>>>> As you can see, there's no compiled frame output where I expect I should see something. >>>>> I get this pretty consistently on both BE and LE. I also see the same thing running 'jstack -F ' >>>>> on BE. >>>> >>>> That's not unusual. The problem with your example is that it above test.main all the other methods are compiled AND inlined. That means that there's just one physical frame above test.main. If the stack tracing routine can't make sense of the first frame, in not only skips that frame, but also all the virtual java frames which are contained inside this physical frame. You can try to run your example with "-XX:-Inline" to avoid inlining and see deeper stack traces. >>> >>> Thanks for the tip. Using "-XX:-Inline" does show more stack. Sometimes the stack looks like following: >>> >>> --------------------------------- >>> Thread 18959: (state = IN_JAVA) >>> - test.get_my_chars(int, int, char[], java.lang.String, int) @bci=34, line=14 (Compiled frame; information may be imprecise) >>> - test.run_test() @bci=63, line=31 (Compiled frame) >>> - test.main(java.lang.String[]) @bci=100, line=54 (Interpreted frame) >>> --------------------------------- >>> >>> But usually the stack just has "main" and "run_test", always with the same line numbers, whether or not get_my_chars is included in the stack. But as I mentioned in my earlier note, line #31 in run_test is the first line of a for-loop, not the (expected) call to get_my_chars. >>> >> >> Again, PC to line/BCImapping is only precise at safepoints. There's no >> chance to get this 100% right. But that's the same on all >> architectures. If you run with -XX:+PrintInlining you will what has >> been inlined which may help to interprete the missing parts in a stack >> trace which was not taken at a safepoint. >> >>> In the approximate 10 times that I re-ran my test with the "-XX:-Inline" (sometimes killing it with SIGSEGV to get a core file; sometimes using 'jstack -F'), I twice got an NPE: >>> >>> java.lang.NullPointerException >>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:88) >>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >>> . . . >>> >>> Line 88 in StackTrace.java is >>> >>> tty.print(" - " + method.externalNameAndSignature() + >>> " @bci=" + vf.getBCI()); >>> >>> I'll work on debugging this. >>> >> >> Yes, that should be fixed. Maybe we need some more checks if 'method' >> and 'vf' are valid. > In fact, I'm consistently seeing the same NPE on x86 when I run the java app with "-XX:-Inline" > and then do 'jstack -F '. Do you know if there's a bug report open already for this? > The jdk9 source on my x86 system was a couple months (or so) old, so I wanted to see if > this still fails with current upstream code. I refreshed my source tree (via get_source.sh) > and tried to rebuild it, but I got a compile failure. I imagine someone else is already Just as a short note (I'll answer all the other questions tomorrow). You should call 'bash common/bin/hgforest.sh pull -u' in the top level repositoy for updating the whole forest. "get_source.sh" will just fetch a new clone and copy it over the old version. This may be the source of your your build problem because it may leave old files in your workspace. > working on that. > > -Maynard >> > [snip] > From aph at redhat.com Wed Dec 3 18:50:48 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Dec 2014 18:50:48 +0000 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F545E.7090500@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E4DE6.30305@us.ibm.com> <547F545E.7090500@us.ibm.com> Message-ID: <547F5B88.10703@redhat.com> On 12/03/2014 06:20 PM, Maynard Johnson wrote: >> If you're running on Debian/Ubuntu it is probably this issue: >> > >> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection >> > >> > which can be solved by doing: >> > >> > echo 0 > /proc/sys/kernel/yama/ptrace_scope > Yes, that was the issue. Thanks for the tip! Good Lord, is that the default on Ubuntu? Argh. :-( Andrew. From maynardj at us.ibm.com Wed Dec 3 18:55:03 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Wed, 03 Dec 2014 12:55:03 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F5782.1060800@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> <547F5782.1060800@us.ibm.com> Message-ID: <547F5C87.7080803@us.ibm.com> On 12/03/2014 12:33 PM, Maynard Johnson wrote: > On 12/03/2014 02:40 AM, Volker Simonis wrote: >> On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson wrote: >>> In the approximate 10 times that I re-ran my test with the "-XX:-Inline" (sometimes killing it with SIGSEGV to get a core file; sometimes using 'jstack -F'), I twice got an NPE: [snip] >>> >>> java.lang.NullPointerException >>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:88) >>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >>> . . . >>> >>> Line 88 in StackTrace.java is >>> >>> tty.print(" - " + method.externalNameAndSignature() + >>> " @bci=" + vf.getBCI()); >>> >>> I'll work on debugging this. >>> >> >> Yes, that should be fixed. Maybe we need some more checks if 'method' >> and 'vf' are valid. > In fact, I'm consistently seeing the same NPE on x86 when I run the java app with "-XX:-Inline" > and then do 'jstack -F '. Do you know if there's a bug report open already for this? > The jdk9 source on my x86 system was a couple months (or so) old, so I wanted to see if > this still fails with current upstream code. I refreshed my source tree (via get_source.sh) > and tried to rebuild it, but I got a compile failure. I imagine someone else is already > working on that. Never mind . . . The compile failure was due to a conflict between a local change I made in one of the files and a change from upstream. I fixed it and the current upstream source builds fine on x86 now. However, the above-mentioned NPE still occurs most of the time. -Maynard > > -Maynard >> > [snip] > From kumar.x.srinivasan at oracle.com Wed Dec 3 18:58:24 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 03 Dec 2014 10:58:24 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <547D265A.20005@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> Message-ID: <547F5D50.30309@oracle.com> Hi Chris, Approved with some minor nits, typos which needs correction. yes java.c follows the JDK indenting as Alan pointed out. TooSmallStackSize.java Copyright should be 2014, 1. 37 * stack size for the platform (as provided by the JVM error message when a very 38 * small is used), and then verify that the JVM can be launched with that stack s/small is/small stack is/ 2. 54 * Returns the minimum stack size this platform will allowed based on the s/allowed/allow/ 3. 58 * The TestResult argument must containthe result of having already run s/containthe/contain the/ 4. 92 if (verbose) System.out.println("*** Testing " + stackSize); I know this is allowed in the HotSpot world but in JDK land we always use with a LF + Indent, also in other places. 5. 85 * Returns the mimumum allowed stack size gleaned from the error message, s/mimumum/minimum Finally I am concerned with the integration, since it spans both HotSpot and JDK, and it appears the test will fail if the HotSpot changes are not integrated first, or has it already ? Thanks Kumar On 12/1/2014 6:39 PM, Chris Plummer wrote: > Sorry about the long delay in getting back to this. I ran into two > separate JPRT issues that were preventing me from testing these > changes, plus I was on vacation last week. Here's an updated webrev. > I'm not sure where we left things, so I'll just say what's changed > since the original version: > > 1. Rewrote the test to be in Java instead of a shell script. > 2. Moved the test from hotspot/test/runtime/memory to > jdk/test/tools/launcher > 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to override > the default 32k minimum value. > > https://bugs.openjdk.java.net/browse/JDK-6762191 > http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ > > thanks, > > Chris > > On 11/19/14 7:52 AM, Chris Plummer wrote: >> On 11/19/14 2:12 AM, David Holmes wrote: >>> On 19/11/2014 6:49 PM, Chris Plummer wrote: >>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k >>>> references, and also moved the test from hotspot/test/runtime to >>>> jdk/test/tools/launcher as David requested. That required some >>>> adjustments to the test script, since test_env.sh does not exist in >>>> jdk/test, so I had to pull in the bits I needed into the script. >>> >>> Is there a reason this needs a shell script instead of using the >>> testlibrary tools to launch the VM and check the output? >> Not that I'm aware of. I guess I just really didn't look at what it >> would take to make it all in java. I'll have a look at java examples >> and convert it. >> >> Chris >>> >>> Sorry that should have been mentioned much earlier. >>> >>> David >>> >>> >>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ >>>> >>>> I still need to rerun through JPRT. I'll do so once there are no more >>>> suggested changes. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 11/18/14 2:08 PM, Chris Plummer wrote: >>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes is in >>>>> java.c. >>>>> >>>>> Chris >>>>> >>>>> On 11/12/14 6:43 PM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> Sorry for the delay. >>>>>> >>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm still looking for reviewers. >>>>>> >>>>>> As the change is to the launcher it needs to be reviewed by the >>>>>> launcher owner - which I think is serviceability (though also cc'd >>>>>> Kumar :) ). >>>>>> >>>>>> Launcher change, and your rationale, seems okay to me. I'd probably >>>>>> put the test in to jdk/test/tools/launcher/ though. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>>>>>> This is an initial review for 6762191. I'm guessing there will be >>>>>>>> recommendations to fix in a different way, but thought this >>>>>>>> would be a >>>>>>>> good time to start the discussion. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>>>>>> >>>>>>>> The bug is that if the -Xss size is set to something very small >>>>>>>> (like >>>>>>>> 16k), on linux there will be a crash due to overwriting the end >>>>>>>> of the >>>>>>>> stack. This happens before hotspot can compute its stack needs and >>>>>>>> verify that the stack is big enough. >>>>>>>> >>>>>>>> It didn't seem viable to move the hotspot stack size check >>>>>>>> earlier. It >>>>>>>> depends on too much other work done before that point, and the >>>>>>>> changes >>>>>>>> would have been disruptive. The stack size check is currently >>>>>>>> done in >>>>>>>> os::init_2(). >>>>>>>> >>>>>>>> What is needed is a check before the thread is created. That >>>>>>>> way we >>>>>>>> can create a thread with a big enough stack to handle all needs >>>>>>>> up to >>>>>>>> the point of the check in os::init_2(). This initial check does >>>>>>>> not >>>>>>>> need to be the final check. It just needs to confirm that we have >>>>>>>> enough stack to get us to the check in os::init_2(). >>>>>>>> >>>>>>>> I decided to check in java.c if the -Xss size is too small, and >>>>>>>> set it >>>>>>>> to a larger size if it is. I hard coded this size to 32k (I'll >>>>>>>> explain >>>>>>>> why 32k later). I suspect this is the part that will result in >>>>>>>> some >>>>>>>> debate. If you have better suggestions let me know. If it does >>>>>>>> stay >>>>>>>> here, then probably the 32k needs to be a #define, and maybe >>>>>>>> even an >>>>>>>> OS porting interface, but I'm not sure where to put it. >>>>>>>> >>>>>>>> The reason I chose 32k is because this is big enough for all >>>>>>>> platforms >>>>>>>> to get to the stack size check in os::init_2(). It is also smaller >>>>>>>> than the actual minimum stack size allowed on any platform. 32-bit >>>>>>>> windows has the smallest requirement at 64k. I add some printfs to >>>>>>>> print the minimum stack requirement, and then ran a simple >>>>>>>> JTReg test >>>>>>>> with every JPRT supported platform to get the results. >>>>>>>> >>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>>>>>> -Xss32k, and -XXss, where is the size from the >>>>>>>> error message produced by the JVM, such as in the following: >>>>>>>> >>>>>>>> $ java -Xss32k -version >>>>>>>> The stack size specified is too small, Specify at least 100k >>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>> >>>>>>>> I ran this test through JPRT on all platforms, and they all pass. >>>>>>>> >>>>>>>> One thing to point out is that Windows behaves a bit different >>>>>>>> than >>>>>>>> the other platforms. It always rounds the stack size up to a >>>>>>>> multiple >>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so >>>>>>>> there >>>>>>>> is no error produced in this case. However, on 32-bit Windows >>>>>>>> with C2, >>>>>>>> 68k is the minimum, so an error is produced since the stack >>>>>>>> will only >>>>>>>> be 64k. There is no bug here. It's just a bit confusing. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>> >>>>> >>>> >> > From chris.plummer at oracle.com Wed Dec 3 19:26:41 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 03 Dec 2014 11:26:41 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <547F5D50.30309@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> <547F5D50.30309@oracle.com> Message-ID: <547F63F1.5050202@oracle.com> Hi Kumar, On 12/3/14 10:58 AM, Kumar Srinivasan wrote: > Hi Chris, > > Approved with some minor nits, typos which needs correction. > > yes java.c follows the JDK indenting as Alan pointed out. > > TooSmallStackSize.java > > Copyright should be 2014, Copy/paste error from example test I was referred to. I will fix, and also remove the import if not needed. > > 1. > > 37 * stack size for the platform (as provided by the JVM error > message when a very > 38 * small is used), and then verify that the JVM can be launched > with that stack > > s/small is/small stack is/ ok > > 2. > > 54 * Returns the minimum stack size this platform will allowed > based on the > > s/allowed/allow/ ok > > 3. > > 58 * The TestResult argument must containthe result of having > already run > s/containthe/contain the/ ok > > 4. > 92 if (verbose) System.out.println("*** Testing " + stackSize); > > I know this is allowed in the HotSpot world but in JDK land we always > use with a LF + Indent, also in other places. Are curly braces needed then? I know some coding conventions require them. > > 5. > 85 * Returns the mimumum allowed stack size gleaned from the > error message, > s/mimumum/minimum ok. > > > Finally I am concerned with the integration, since it spans both > HotSpot and JDK, and it appears the test will fail if the HotSpot > changes are not integrated first, or has it already ? There are no hotspot changes. java.c is where the fix is. thanks, Chris > > Thanks > Kumar > > > > > > > > On 12/1/2014 6:39 PM, Chris Plummer wrote: >> Sorry about the long delay in getting back to this. I ran into two >> separate JPRT issues that were preventing me from testing these >> changes, plus I was on vacation last week. Here's an updated webrev. >> I'm not sure where we left things, so I'll just say what's changed >> since the original version: >> >> 1. Rewrote the test to be in Java instead of a shell script. >> 2. Moved the test from hotspot/test/runtime/memory to >> jdk/test/tools/launcher >> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to >> override the default 32k minimum value. >> >> https://bugs.openjdk.java.net/browse/JDK-6762191 >> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ >> >> thanks, >> >> Chris >> >> On 11/19/14 7:52 AM, Chris Plummer wrote: >>> On 11/19/14 2:12 AM, David Holmes wrote: >>>> On 19/11/2014 6:49 PM, Chris Plummer wrote: >>>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k >>>>> references, and also moved the test from hotspot/test/runtime to >>>>> jdk/test/tools/launcher as David requested. That required some >>>>> adjustments to the test script, since test_env.sh does not exist in >>>>> jdk/test, so I had to pull in the bits I needed into the script. >>>> >>>> Is there a reason this needs a shell script instead of using the >>>> testlibrary tools to launch the VM and check the output? >>> Not that I'm aware of. I guess I just really didn't look at what it >>> would take to make it all in java. I'll have a look at java examples >>> and convert it. >>> >>> Chris >>>> >>>> Sorry that should have been mentioned much earlier. >>>> >>>> David >>>> >>>> >>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ >>>>> >>>>> I still need to rerun through JPRT. I'll do so once there are no more >>>>> suggested changes. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 11/18/14 2:08 PM, Chris Plummer wrote: >>>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes >>>>>> is in >>>>>> java.c. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 11/12/14 6:43 PM, David Holmes wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> Sorry for the delay. >>>>>>> >>>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm still looking for reviewers. >>>>>>> >>>>>>> As the change is to the launcher it needs to be reviewed by the >>>>>>> launcher owner - which I think is serviceability (though also cc'd >>>>>>> Kumar :) ). >>>>>>> >>>>>>> Launcher change, and your rationale, seems okay to me. I'd probably >>>>>>> put the test in to jdk/test/tools/launcher/ though. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>>>>>>> This is an initial review for 6762191. I'm guessing there will be >>>>>>>>> recommendations to fix in a different way, but thought this >>>>>>>>> would be a >>>>>>>>> good time to start the discussion. >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>>>>>>> >>>>>>>>> The bug is that if the -Xss size is set to something very >>>>>>>>> small (like >>>>>>>>> 16k), on linux there will be a crash due to overwriting the >>>>>>>>> end of the >>>>>>>>> stack. This happens before hotspot can compute its stack needs >>>>>>>>> and >>>>>>>>> verify that the stack is big enough. >>>>>>>>> >>>>>>>>> It didn't seem viable to move the hotspot stack size check >>>>>>>>> earlier. It >>>>>>>>> depends on too much other work done before that point, and the >>>>>>>>> changes >>>>>>>>> would have been disruptive. The stack size check is currently >>>>>>>>> done in >>>>>>>>> os::init_2(). >>>>>>>>> >>>>>>>>> What is needed is a check before the thread is created. That >>>>>>>>> way we >>>>>>>>> can create a thread with a big enough stack to handle all >>>>>>>>> needs up to >>>>>>>>> the point of the check in os::init_2(). This initial check >>>>>>>>> does not >>>>>>>>> need to be the final check. It just needs to confirm that we have >>>>>>>>> enough stack to get us to the check in os::init_2(). >>>>>>>>> >>>>>>>>> I decided to check in java.c if the -Xss size is too small, >>>>>>>>> and set it >>>>>>>>> to a larger size if it is. I hard coded this size to 32k (I'll >>>>>>>>> explain >>>>>>>>> why 32k later). I suspect this is the part that will result in >>>>>>>>> some >>>>>>>>> debate. If you have better suggestions let me know. If it does >>>>>>>>> stay >>>>>>>>> here, then probably the 32k needs to be a #define, and maybe >>>>>>>>> even an >>>>>>>>> OS porting interface, but I'm not sure where to put it. >>>>>>>>> >>>>>>>>> The reason I chose 32k is because this is big enough for all >>>>>>>>> platforms >>>>>>>>> to get to the stack size check in os::init_2(). It is also >>>>>>>>> smaller >>>>>>>>> than the actual minimum stack size allowed on any platform. >>>>>>>>> 32-bit >>>>>>>>> windows has the smallest requirement at 64k. I add some >>>>>>>>> printfs to >>>>>>>>> print the minimum stack requirement, and then ran a simple >>>>>>>>> JTReg test >>>>>>>>> with every JPRT supported platform to get the results. >>>>>>>>> >>>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>>>>>>> -Xss32k, and -XXss, where is the size from the >>>>>>>>> error message produced by the JVM, such as in the following: >>>>>>>>> >>>>>>>>> $ java -Xss32k -version >>>>>>>>> The stack size specified is too small, Specify at least 100k >>>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>>> >>>>>>>>> I ran this test through JPRT on all platforms, and they all pass. >>>>>>>>> >>>>>>>>> One thing to point out is that Windows behaves a bit different >>>>>>>>> than >>>>>>>>> the other platforms. It always rounds the stack size up to a >>>>>>>>> multiple >>>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, >>>>>>>>> so there >>>>>>>>> is no error produced in this case. However, on 32-bit Windows >>>>>>>>> with C2, >>>>>>>>> 68k is the minimum, so an error is produced since the stack >>>>>>>>> will only >>>>>>>>> be 64k. There is no bug here. It's just a bit confusing. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>> >>>>>> >>>>> >>> >> > From staffan.larsen at oracle.com Wed Dec 3 19:50:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 3 Dec 2014 20:50:02 +0100 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. In-Reply-To: <547F37B5.5010801@oracle.com> References: <5370E26B.3030509@oracle.com> <537B3921.2090402@oracle.com> <352D5134-6A27-4257-AC6A-9EF041288830@oracle.com> <5380E426.5080904@oracle.com> <546E3510.3010606@oracle.com> <5475DB63.2000805@oracle.com> <547F37B5.5010801@oracle.com> Message-ID: I agree. Go ahead with this and hopefully we can revisit it later. Thanks, /Staffan > On 3 dec 2014, at 17:17, KEVIN WALLS wrote: > > Thanks Staffan - > > Yes, I've updated it to be simply canAttachOSX(). Seems likely we should go ahead with that and possibly revisit the OSX conditions, good to have the method there so we can make it more complete and complex later when/if required. Right now, I think this is suitable for our automated tests, it could be that we are stopping people (you? 8-) ) running this automated test as a non-root user, such tests will not execute, but shouldn't fail... > > Thanks > Kevin > > > On 03/12/2014 12:53, Staffan Larsen wrote: >> 178 public static boolean canPtraceAttachOSX() throws Exception { >> 179 return userName.equals("root"); >> 180 } >> >> Ptrace isn?t the API that is doing the most vigorous access checks on OS X. Instead the system call task_for_pid() is what causes most of the access denied problems. So perhaps just skipping the ?Ptrace? part of the method name above is good. >> >> Then, on OS X again, the root user will indeed av access to other processes, but it?s not the only way. A regular user can also get access if a couple of prerequisites are met: >> 1) The attaching program is compiled with SecTaskAccess=allowed in Info.plist. We do this for jstack, jinfo and jmap. >> 2) The attaching program is signed. >> 3) The user has given permission for taking control of another process via a dialog box that OS X displays. >> (I think these are all?) >> >> Regarding signing above: Oracle signs binaries that we ship with an official certificate, but development binaries are also signed if a certificate called openjdk_codesign is found on the machine where the product is built. Usually one creates a self-signed such certificate if one wants to test the attaching functionality. >> >> All this to say that if we only check for root, then it will not be possible to run the tests as a regular user even if you have done 1-3 above. That would be a shame, but perhaps cannot be avoided given the complexity involved. >> >> /Staffan >> >> >>> On 26 nov 2014, at 14:53, KEVIN WALLS wrote: >>> >>> >>> ...and an update to the webrev in the same place that also checks the SELinux deny_ptrace flag, another reason you can get a permission denied error and fail the test. >>> >>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >>> >>> Thanks >>> Kevin >>> >>> >>> On 20/11/2014 18:38, KEVIN WALLS wrote: >>>> Hi, >>>> >>>> I'm resurrecting this thread to revisit this testcase, the one that fails if not in an environment where an SA attach is permitted (which is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac systems as a non-root user). >>>> >>>> There are times when we want to check if an SA attach is likely to work, so in the following webrev I've put that in the testlibrary. >>>> >>>> In doing this I now realise that heap dumping with jmap/sa is broken, as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416 >>>> >>>> I won't remove the @ignore in this change, but it would make sense to me to do the fix below, including backporting to places where jmap -F still works. >>>> >>>> webrev >>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >>>> >>>> bug >>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>> >>>> Thanks >>>> Kevin >>>> >>>> >>>> >>>> >>>> On 24/05/2014 19:25, Kevin Walls wrote: >>>>> Thanks Peter, and thanks Dmitry - >>>>> >>>>> So another thread on this has started about why such a test runs in an environment that can't expected to attach to its own processes anyway: seems that some test systems permit that, and some run as a user that can't necessarily expect to have that ability. >>>>> >>>>> (Dmitry I'm not sure about exiting with that error value? If that's something people are meant to know about I have missed it. But the test would fail if jmap didn't create the heap dump file, i.e. if it fails but doesn't exit with the right code.) >>>>> >>>>> For the moment I'll wait on that other information for whether this needs to be fixed in the test... >>>>> >>>>> Thanks! >>>>> Kevin >>>>> >>>>> >>>>> >>>>> >>>>> On 23/05/14 12:00, Peter Allwin wrote: >>>>>> Looks good to me! >>>>>> >>>>>> >>>>>> Thanks for looking at this Kevin, >>>>>> /peter >>>>>> >>>>>> On 20 May 2014, at 13:14, Kevin Walls wrote: >>>>>> >>>>>>> Hi - any comments? 8-) >>>>>>> >>>>>>> On 12/05/14 16:02, Kevin Walls wrote >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'd like to get a review of this test change. It assumed that jmap would have permission to run on a process that the test itself created, but this is not necessarily the case. >>>>>>>> >>>>>>>> Here I'm considering it OK to skip (pass) the test where jmap fails to attach. The test itself was not platform-specific and as long as we have other platforms where jmap step will work, we are testing for this problem. >>>>>>>> >>>>>>>> bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Kevin > From serguei.spitsyn at oracle.com Wed Dec 3 20:01:58 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 03 Dec 2014 12:01:58 -0800 Subject: RFR(S), SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <547EFCD9.5020301@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> Message-ID: <547F6C36.8000003@oracle.com> Dmitry, Looks good. Thanks, Serguei On 12/3/14 4:06 AM, Dmitry Samersoff wrote: > Serguei, > > Updated webrev > > http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ > > -Dmitry > > On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> It is good in general modulo Staffan's comments. >> >> There are some inconsistencies: >> - the ExceptionOccurred(env) is compared to != NULL (which make the >> logic more complex) >> in some places and no such comparison (implicit comparison instead) >> in others >> - two different forms of check/action are used: >> - (*env)->ExceptionOccurred(env) and >> - !(*env)->ExceptionOccurred(env) >> >> I'd suggest to do it the same way and always return the "default" value >> if an exception occurred. >> It will make the logic more flat and clear. >> Otherwise, we have to think what exact value is returned in exception >> occurred cases like at lines 241, 255. >> >> The comment // OOM is used inconsistently too. >> >> >> Thanks, >> Serguei >> >> >> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>> Please review the small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>> >>> Added more missed exception checks to sadis.c >>> > From kevin.walls at oracle.com Wed Dec 3 21:06:56 2014 From: kevin.walls at oracle.com (KEVIN WALLS) Date: Wed, 03 Dec 2014 21:06:56 +0000 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. In-Reply-To: References: <5370E26B.3030509@oracle.com> <537B3921.2090402@oracle.com> <352D5134-6A27-4257-AC6A-9EF041288830@oracle.com> <5380E426.5080904@oracle.com> <546E3510.3010606@oracle.com> <5475DB63.2000805@oracle.com> <547F37B5.5010801@oracle.com> Message-ID: <547F7B70.4030403@oracle.com> Thanks! On 03/12/2014 19:50, Staffan Larsen wrote: > I agree. Go ahead with this and hopefully we can revisit it later. > > Thanks, > /Staffan > >> On 3 dec 2014, at 17:17, KEVIN WALLS wrote: >> >> Thanks Staffan - >> >> Yes, I've updated it to be simply canAttachOSX(). Seems likely we should go ahead with that and possibly revisit the OSX conditions, good to have the method there so we can make it more complete and complex later when/if required. Right now, I think this is suitable for our automated tests, it could be that we are stopping people (you? 8-) ) running this automated test as a non-root user, such tests will not execute, but shouldn't fail... >> >> Thanks >> Kevin >> >> >> On 03/12/2014 12:53, Staffan Larsen wrote: >>> 178 public static boolean canPtraceAttachOSX() throws Exception { >>> 179 return userName.equals("root"); >>> 180 } >>> >>> Ptrace isn?t the API that is doing the most vigorous access checks on OS X. Instead the system call task_for_pid() is what causes most of the access denied problems. So perhaps just skipping the ?Ptrace? part of the method name above is good. >>> >>> Then, on OS X again, the root user will indeed av access to other processes, but it?s not the only way. A regular user can also get access if a couple of prerequisites are met: >>> 1) The attaching program is compiled with SecTaskAccess=allowed in Info.plist. We do this for jstack, jinfo and jmap. >>> 2) The attaching program is signed. >>> 3) The user has given permission for taking control of another process via a dialog box that OS X displays. >>> (I think these are all?) >>> >>> Regarding signing above: Oracle signs binaries that we ship with an official certificate, but development binaries are also signed if a certificate called openjdk_codesign is found on the machine where the product is built. Usually one creates a self-signed such certificate if one wants to test the attaching functionality. >>> >>> All this to say that if we only check for root, then it will not be possible to run the tests as a regular user even if you have done 1-3 above. That would be a shame, but perhaps cannot be avoided given the complexity involved. >>> >>> /Staffan >>> >>> >>>> On 26 nov 2014, at 14:53, KEVIN WALLS wrote: >>>> >>>> >>>> ...and an update to the webrev in the same place that also checks the SELinux deny_ptrace flag, another reason you can get a permission denied error and fail the test. >>>> >>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >>>> >>>> Thanks >>>> Kevin >>>> >>>> >>>> On 20/11/2014 18:38, KEVIN WALLS wrote: >>>>> Hi, >>>>> >>>>> I'm resurrecting this thread to revisit this testcase, the one that fails if not in an environment where an SA attach is permitted (which is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac systems as a non-root user). >>>>> >>>>> There are times when we want to check if an SA attach is likely to work, so in the following webrev I've put that in the testlibrary. >>>>> >>>>> In doing this I now realise that heap dumping with jmap/sa is broken, as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416 >>>>> >>>>> I won't remove the @ignore in this change, but it would make sense to me to do the fix below, including backporting to places where jmap -F still works. >>>>> >>>>> webrev >>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ >>>>> >>>>> bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>>> >>>>> Thanks >>>>> Kevin >>>>> >>>>> >>>>> >>>>> >>>>> On 24/05/2014 19:25, Kevin Walls wrote: >>>>>> Thanks Peter, and thanks Dmitry - >>>>>> >>>>>> So another thread on this has started about why such a test runs in an environment that can't expected to attach to its own processes anyway: seems that some test systems permit that, and some run as a user that can't necessarily expect to have that ability. >>>>>> >>>>>> (Dmitry I'm not sure about exiting with that error value? If that's something people are meant to know about I have missed it. But the test would fail if jmap didn't create the heap dump file, i.e. if it fails but doesn't exit with the right code.) >>>>>> >>>>>> For the moment I'll wait on that other information for whether this needs to be fixed in the test... >>>>>> >>>>>> Thanks! >>>>>> Kevin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 23/05/14 12:00, Peter Allwin wrote: >>>>>>> Looks good to me! >>>>>>> >>>>>>> >>>>>>> Thanks for looking at this Kevin, >>>>>>> /peter >>>>>>> >>>>>>> On 20 May 2014, at 13:14, Kevin Walls wrote: >>>>>>> >>>>>>>> Hi - any comments? 8-) >>>>>>>> >>>>>>>> On 12/05/14 16:02, Kevin Walls wrote >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'd like to get a review of this test change. It assumed that jmap would have permission to run on a process that the test itself created, but this is not necessarily the case. >>>>>>>>> >>>>>>>>> Here I'm considering it OK to skip (pass) the test where jmap fails to attach. The test itself was not platform-specific and as long as we have other platforms where jmap step will work, we are testing for this problem. >>>>>>>>> >>>>>>>>> bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Kevin From kevin.walls at oracle.com Wed Dec 3 22:06:02 2014 From: kevin.walls at oracle.com (KEVIN WALLS) Date: Wed, 03 Dec 2014 22:06:02 +0000 Subject: RFR(XS): 8061785: [TEST_BUG] serviceability/sa/jmap-hashcode/Test8028623.java has utf8 character corrupted by earlier merge Message-ID: <547F894A.4090901@oracle.com> Hi, This is a review request for a changing a couple of characters in a test. It's the same test I just changed with another review, I kept it separate so as to complicate the review already in progress (it had gone on long enough..). The test contains an embedded utf8 character, to test a jmap/SA heap dumping fix. The test is not broken here in 9/hs-rt, but in another clone I saw this character get corrupted by a merge: it was rewritten as literal ?? question marks. It wasn't clear if it was an hg issue (I couldn't reproduce that) or perhaps more likely the editor used to do a merge. To avoid the same thing happening again we can change the utf8 char to \uXXXX format. The change below I tested to check the test still correctly fails on a non-fixed JVM, and passes on a fixed one bug: https://bugs.openjdk.java.net/browse/JDK-8061785 change: $ hg diff test/serviceability/sa/jmap-hashcode/Test8028623.java diff --git a/test/serviceability/sa/jmap-hashcode/Test8028623.java b/test/serviceability/sa/jmap-hashcode/Test8028623.java --- a/test/serviceability/sa/jmap-hashcode/Test8028623.java +++ b/test/serviceability/sa/jmap-hashcode/Test8028623.java @@ -41,12 +41,12 @@ public class Test8028623 { - public static int ? = 1; + public static int \u00CB = 1; public static String dumpFile = "heap.out"; public static void main (String[] args) { - System.out.println(?); + System.out.println(\u00CB); try { if (!Platform.shouldSAAttach()) { ---------------------------------------------------------------------------------------------- Thanks Kevin From kumar.x.srinivasan at oracle.com Wed Dec 3 22:13:03 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 03 Dec 2014 14:13:03 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <547F63F1.5050202@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> <547F5D50.30309@oracle.com> <547F63F1.5050202@oracle.com> Message-ID: <547F8AEF.3000002@oracle.com> On 12/3/2014 11:26 AM, Chris Plummer wrote: > Hi Kumar, > > On 12/3/14 10:58 AM, Kumar Srinivasan wrote: >> Hi Chris, >> >> Approved with some minor nits, typos which needs correction. >> >> yes java.c follows the JDK indenting as Alan pointed out. >> >> TooSmallStackSize.java >> >> Copyright should be 2014, > Copy/paste error from example test I was referred to. I will fix, and > also remove the import if not needed. >> >> 1. >> >> 37 * stack size for the platform (as provided by the JVM error >> message when a very >> 38 * small is used), and then verify that the JVM can be launched >> with that stack >> >> s/small is/small stack is/ > ok >> >> 2. >> >> 54 * Returns the minimum stack size this platform will allowed >> based on the >> >> s/allowed/allow/ > ok >> >> 3. >> >> 58 * The TestResult argument must containthe result of having >> already run >> s/containthe/contain the/ > ok >> >> 4. >> 92 if (verbose) System.out.println("*** Testing " + stackSize); >> >> I know this is allowed in the HotSpot world but in JDK land we always >> use with a LF + Indent, also in other places. > Are curly braces needed then? I know some coding conventions require > them. No not necessary for one liners. >> >> 5. >> 85 * Returns the mimumum allowed stack size gleaned from the >> error message, >> s/mimumum/minimum > ok. >> >> >> Finally I am concerned with the integration, since it spans both >> HotSpot and JDK, and it appears the test will fail if the HotSpot >> changes are not integrated first, or has it already ? > There are no hotspot changes. java.c is where the fix is. Great!. Thanks Kumar > > thanks, > > Chris >> >> Thanks >> Kumar >> >> >> >> >> >> >> >> On 12/1/2014 6:39 PM, Chris Plummer wrote: >>> Sorry about the long delay in getting back to this. I ran into two >>> separate JPRT issues that were preventing me from testing these >>> changes, plus I was on vacation last week. Here's an updated webrev. >>> I'm not sure where we left things, so I'll just say what's changed >>> since the original version: >>> >>> 1. Rewrote the test to be in Java instead of a shell script. >>> 2. Moved the test from hotspot/test/runtime/memory to >>> jdk/test/tools/launcher >>> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to >>> override the default 32k minimum value. >>> >>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ >>> >>> thanks, >>> >>> Chris >>> >>> On 11/19/14 7:52 AM, Chris Plummer wrote: >>>> On 11/19/14 2:12 AM, David Holmes wrote: >>>>> On 19/11/2014 6:49 PM, Chris Plummer wrote: >>>>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k >>>>>> references, and also moved the test from hotspot/test/runtime to >>>>>> jdk/test/tools/launcher as David requested. That required some >>>>>> adjustments to the test script, since test_env.sh does not exist in >>>>>> jdk/test, so I had to pull in the bits I needed into the script. >>>>> >>>>> Is there a reason this needs a shell script instead of using the >>>>> testlibrary tools to launch the VM and check the output? >>>> Not that I'm aware of. I guess I just really didn't look at what it >>>> would take to make it all in java. I'll have a look at java >>>> examples and convert it. >>>> >>>> Chris >>>>> >>>>> Sorry that should have been mentioned much earlier. >>>>> >>>>> David >>>>> >>>>> >>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ >>>>>> >>>>>> I still need to rerun through JPRT. I'll do so once there are no >>>>>> more >>>>>> suggested changes. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 11/18/14 2:08 PM, Chris Plummer wrote: >>>>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes >>>>>>> is in >>>>>>> java.c. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 11/12/14 6:43 PM, David Holmes wrote: >>>>>>>> Hi Chris, >>>>>>>> >>>>>>>> Sorry for the delay. >>>>>>>> >>>>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm still looking for reviewers. >>>>>>>> >>>>>>>> As the change is to the launcher it needs to be reviewed by the >>>>>>>> launcher owner - which I think is serviceability (though also cc'd >>>>>>>> Kumar :) ). >>>>>>>> >>>>>>>> Launcher change, and your rationale, seems okay to me. I'd >>>>>>>> probably >>>>>>>> put the test in to jdk/test/tools/launcher/ though. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>>>>>>>> This is an initial review for 6762191. I'm guessing there >>>>>>>>>> will be >>>>>>>>>> recommendations to fix in a different way, but thought this >>>>>>>>>> would be a >>>>>>>>>> good time to start the discussion. >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>>>>>>>> >>>>>>>>>> The bug is that if the -Xss size is set to something very >>>>>>>>>> small (like >>>>>>>>>> 16k), on linux there will be a crash due to overwriting the >>>>>>>>>> end of the >>>>>>>>>> stack. This happens before hotspot can compute its stack >>>>>>>>>> needs and >>>>>>>>>> verify that the stack is big enough. >>>>>>>>>> >>>>>>>>>> It didn't seem viable to move the hotspot stack size check >>>>>>>>>> earlier. It >>>>>>>>>> depends on too much other work done before that point, and >>>>>>>>>> the changes >>>>>>>>>> would have been disruptive. The stack size check is currently >>>>>>>>>> done in >>>>>>>>>> os::init_2(). >>>>>>>>>> >>>>>>>>>> What is needed is a check before the thread is created. That >>>>>>>>>> way we >>>>>>>>>> can create a thread with a big enough stack to handle all >>>>>>>>>> needs up to >>>>>>>>>> the point of the check in os::init_2(). This initial check >>>>>>>>>> does not >>>>>>>>>> need to be the final check. It just needs to confirm that we >>>>>>>>>> have >>>>>>>>>> enough stack to get us to the check in os::init_2(). >>>>>>>>>> >>>>>>>>>> I decided to check in java.c if the -Xss size is too small, >>>>>>>>>> and set it >>>>>>>>>> to a larger size if it is. I hard coded this size to 32k >>>>>>>>>> (I'll explain >>>>>>>>>> why 32k later). I suspect this is the part that will result >>>>>>>>>> in some >>>>>>>>>> debate. If you have better suggestions let me know. If it >>>>>>>>>> does stay >>>>>>>>>> here, then probably the 32k needs to be a #define, and maybe >>>>>>>>>> even an >>>>>>>>>> OS porting interface, but I'm not sure where to put it. >>>>>>>>>> >>>>>>>>>> The reason I chose 32k is because this is big enough for all >>>>>>>>>> platforms >>>>>>>>>> to get to the stack size check in os::init_2(). It is also >>>>>>>>>> smaller >>>>>>>>>> than the actual minimum stack size allowed on any platform. >>>>>>>>>> 32-bit >>>>>>>>>> windows has the smallest requirement at 64k. I add some >>>>>>>>>> printfs to >>>>>>>>>> print the minimum stack requirement, and then ran a simple >>>>>>>>>> JTReg test >>>>>>>>>> with every JPRT supported platform to get the results. >>>>>>>>>> >>>>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>>>>>>>> -Xss32k, and -XXss, where is the size from >>>>>>>>>> the >>>>>>>>>> error message produced by the JVM, such as in the following: >>>>>>>>>> >>>>>>>>>> $ java -Xss32k -version >>>>>>>>>> The stack size specified is too small, Specify at least 100k >>>>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>>>> >>>>>>>>>> I ran this test through JPRT on all platforms, and they all >>>>>>>>>> pass. >>>>>>>>>> >>>>>>>>>> One thing to point out is that Windows behaves a bit >>>>>>>>>> different than >>>>>>>>>> the other platforms. It always rounds the stack size up to a >>>>>>>>>> multiple >>>>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, >>>>>>>>>> so there >>>>>>>>>> is no error produced in this case. However, on 32-bit Windows >>>>>>>>>> with C2, >>>>>>>>>> 68k is the minimum, so an error is produced since the stack >>>>>>>>>> will only >>>>>>>>>> be 64k. There is no bug here. It's just a bit confusing. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From chris.plummer at oracle.com Thu Dec 4 08:12:58 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 04 Dec 2014 00:12:58 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <547F0889.5050204@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> <547F0889.5050204@oracle.com> Message-ID: <5480178A.9090709@oracle.com> On 12/3/14 4:56 AM, Alan Bateman wrote: > On 02/12/2014 02:39, Chris Plummer wrote: >> Sorry about the long delay in getting back to this. I ran into two >> separate JPRT issues that were preventing me from testing these >> changes, plus I was on vacation last week. Here's an updated webrev. >> I'm not sure where we left things, so I'll just say what's changed >> since the original version: >> >> 1. Rewrote the test to be in Java instead of a shell script. >> 2. Moved the test from hotspot/test/runtime/memory to >> jdk/test/tools/launcher >> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to >> override the default 32k minimum value. >> >> https://bugs.openjdk.java.net/browse/JDK-6762191 >> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ > This looks to me. A minor comment for java.c is that this code uses > 4-space indent (different to hotspot). > > The test looks okay too, you might just checking the copyright date as > I assume was not written in 2010. Also I think the import of > java.io.File may be left behind from the previous round. > > -Alan Hi Alan, While removing the java.io.File import, I also questioned why I had java.io.IOException being imported. There were a couple of methods that declared it thrown, and the main method therefore had to catch it, but it turns out this was just copy/paste from the Settings.java test I used as a template, and is not actually needed. I removed the import, throws, and try/catch of IOException. All the other issues mentioned by others have also been addressed. A new webrev can be found at: http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/ thanks, Chris From volker.simonis at gmail.com Thu Dec 4 08:16:52 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Dec 2014 09:16:52 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F5B88.10703@redhat.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E4DE6.30305@us.ibm.com> <547F545E.7090500@us.ibm.com> <547F5B88.10703@redhat.com> Message-ID: On Wed, Dec 3, 2014 at 7:50 PM, Andrew Haley wrote: > On 12/03/2014 06:20 PM, Maynard Johnson wrote: >>> If you're running on Debian/Ubuntu it is probably this issue: >>> > >>> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection >>> > >>> > which can be solved by doing: >>> > >>> > echo 0 > /proc/sys/kernel/yama/ptrace_scope >> Yes, that was the issue. Thanks for the tip! > > Good Lord, is that the default on Ubuntu? Argh. :-( > Yes, all for the sake of security! Probably we won't be able to invoke gcc without any extra efforts in the near future and finally the shell will be banned :) > Andrew. > > From volker.simonis at gmail.com Thu Dec 4 08:20:28 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Dec 2014 09:20:28 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F5C87.7080803@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> <547F5782.1060800@us.ibm.com> <547F5C87.7080803@us.ibm.com> Message-ID: On Wed, Dec 3, 2014 at 7:55 PM, Maynard Johnson wrote: > On 12/03/2014 12:33 PM, Maynard Johnson wrote: >> On 12/03/2014 02:40 AM, Volker Simonis wrote: >>> On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson wrote: >>>> In the approximate 10 times that I re-ran my test with the "-XX:-Inline" (sometimes killing it with SIGSEGV to get a core file; sometimes using 'jstack -F'), I twice got an NPE: > [snip] >>>> >>>> java.lang.NullPointerException >>>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:88) >>>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >>>> . . . >>>> >>>> Line 88 in StackTrace.java is >>>> >>>> tty.print(" - " + method.externalNameAndSignature() + >>>> " @bci=" + vf.getBCI()); >>>> >>>> I'll work on debugging this. >>>> >>> >>> Yes, that should be fixed. Maybe we need some more checks if 'method' >>> and 'vf' are valid. >> In fact, I'm consistently seeing the same NPE on x86 when I run the java app with "-XX:-Inline" >> and then do 'jstack -F '. Do you know if there's a bug report open already for this? >> The jdk9 source on my x86 system was a couple months (or so) old, so I wanted to see if >> this still fails with current upstream code. I refreshed my source tree (via get_source.sh) >> and tried to rebuild it, but I got a compile failure. I imagine someone else is already >> working on that. > Never mind . . . The compile failure was due to a conflict between a local change I made in > one of the files and a change from upstream. I fixed it and the current upstream source builds > fine on x86 now. However, the above-mentioned NPE still occurs most of the time. > That's bad, but that seems to be another issue which should be fixed separately. If you have no more changes/addons compared to my last webrev I can offer to submit a new request for review on behalf of you so we finally get this in. We will need on more review from the serviceability team and a sponsor who will push the change for us. Regards, Volker > -Maynard >> >> -Maynard >>> >> [snip] >> > From jaroslav.bachorik at oracle.com Thu Dec 4 09:42:00 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 04 Dec 2014 10:42:00 +0100 Subject: RFR 8034263: Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails intermittently Message-ID: <54802C68.6010908@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8034263 Webrev: http://cr.openjdk.java.net/~jbachorik/8034263/webrev.00 The test fails intermittently only for CMS collector - "One thing about CMS is that it does concurrent work. So just a theory would be that a concurrent cycle is started and sometime finishes (which might trigger a notification) and sometimes does not finish before the test has completed. " (from discussion with Bengt Rutisson) The 'fix' is to relax the condition for when CMS is used and check that at least the expected number of notifications was triggered. Thanks, -JB- From staffan.larsen at oracle.com Thu Dec 4 11:52:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 4 Dec 2014 12:52:05 +0100 Subject: RFR(XS): 8061785: [TEST_BUG] serviceability/sa/jmap-hashcode/Test8028623.java has utf8 character corrupted by earlier merge In-Reply-To: <547F894A.4090901@oracle.com> References: <547F894A.4090901@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 3 dec 2014, at 23:06, KEVIN WALLS wrote: > > Hi, > > This is a review request for a changing a couple of characters in a test. It's the same test I just changed with another review, I kept it separate so as to complicate the review already in progress (it had gone on long enough..). > > > The test contains an embedded utf8 character, to test a jmap/SA heap dumping fix. The test is not broken here in 9/hs-rt, but in another clone I saw this character get corrupted by a merge: it was rewritten as literal ?? question marks. It wasn't clear if it was an hg issue (I couldn't reproduce that) or perhaps more likely the editor used to do a merge. > > To avoid the same thing happening again we can change the utf8 char to \uXXXX format. > > The change below I tested to check the test still correctly fails on a non-fixed JVM, and passes on a fixed one > > bug: > https://bugs.openjdk.java.net/browse/JDK-8061785 > > change: > $ hg diff test/serviceability/sa/jmap-hashcode/Test8028623.java > diff --git a/test/serviceability/sa/jmap-hashcode/Test8028623.java b/test/serviceability/sa/jmap-hashcode/Test8028623.java > --- a/test/serviceability/sa/jmap-hashcode/Test8028623.java > +++ b/test/serviceability/sa/jmap-hashcode/Test8028623.java > @@ -41,12 +41,12 @@ > > public class Test8028623 { > > - public static int ? = 1; > + public static int \u00CB = 1; > public static String dumpFile = "heap.out"; > > public static void main (String[] args) { > > - System.out.println(?); > + System.out.println(\u00CB); > > try { > if (!Platform.shouldSAAttach()) { > > ---------------------------------------------------------------------------------------------- > Thanks > Kevin > From dmitry.samersoff at oracle.com Thu Dec 4 13:05:49 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 04 Dec 2014 16:05:49 +0300 Subject: RFR(XS): 8061785: [TEST_BUG] serviceability/sa/jmap-hashcode/Test8028623.java has utf8 character corrupted by earlier merge In-Reply-To: <547F894A.4090901@oracle.com> References: <547F894A.4090901@oracle.com> Message-ID: <54805C2D.6080402@oracle.com> Looks good for me. -Dmitry On 2014-12-04 01:06, KEVIN WALLS wrote: > Hi, > > This is a review request for a changing a couple of characters in a > test. It's the same test I just changed with another review, I kept it > separate so as to complicate the review already in progress (it had gone > on long enough..). > > > The test contains an embedded utf8 character, to test a jmap/SA heap > dumping fix. The test is not broken here in 9/hs-rt, but in another > clone I saw this character get corrupted by a merge: it was rewritten as > literal ?? question marks. It wasn't clear if it was an hg issue (I > couldn't reproduce that) or perhaps more likely the editor used to do a > merge. > > To avoid the same thing happening again we can change the utf8 char to > \uXXXX format. > > The change below I tested to check the test still correctly fails on a > non-fixed JVM, and passes on a fixed one > > bug: > https://bugs.openjdk.java.net/browse/JDK-8061785 > > change: > $ hg diff test/serviceability/sa/jmap-hashcode/Test8028623.java > diff --git a/test/serviceability/sa/jmap-hashcode/Test8028623.java > b/test/serviceability/sa/jmap-hashcode/Test8028623.java > --- a/test/serviceability/sa/jmap-hashcode/Test8028623.java > +++ b/test/serviceability/sa/jmap-hashcode/Test8028623.java > @@ -41,12 +41,12 @@ > > public class Test8028623 { > > - public static int ? = 1; > + public static int \u00CB = 1; > public static String dumpFile = "heap.out"; > > public static void main (String[] args) { > > - System.out.println(?); > + System.out.println(\u00CB); > > try { > if (!Platform.shouldSAAttach()) { > > ---------------------------------------------------------------------------------------------- > > Thanks > Kevin > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From kevin.walls at oracle.com Thu Dec 4 13:11:15 2014 From: kevin.walls at oracle.com (KEVIN WALLS) Date: Thu, 04 Dec 2014 13:11:15 +0000 Subject: RFR(XS): 8061785: [TEST_BUG] serviceability/sa/jmap-hashcode/Test8028623.java has utf8 character corrupted by earlier merge In-Reply-To: <54805C2D.6080402@oracle.com> References: <547F894A.4090901@oracle.com> <54805C2D.6080402@oracle.com> Message-ID: <54805D73.2060304@oracle.com> Thanks both of you! From maynardj at us.ibm.com Thu Dec 4 14:27:32 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Thu, 04 Dec 2014 08:27:32 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> <547F5782.1060800@us.ibm.com> <547F5C87.7080803@us.ibm.com> Message-ID: <54806F54.6050307@us.ibm.com> On 12/04/2014 02:20 AM, Volker Simonis wrote: > On Wed, Dec 3, 2014 at 7:55 PM, Maynard Johnson wrote: >> On 12/03/2014 12:33 PM, Maynard Johnson wrote: >>> On 12/03/2014 02:40 AM, Volker Simonis wrote: >>>> On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson wrote: >>>>> In the approximate 10 times that I re-ran my test with the "-XX:-Inline" (sometimes killing it with SIGSEGV to get a core file; sometimes using 'jstack -F'), I twice got an NPE: >> [snip] >>>>> >>>>> java.lang.NullPointerException >>>>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:88) >>>>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >>>>> . . . >>>>> >>>>> Line 88 in StackTrace.java is >>>>> >>>>> tty.print(" - " + method.externalNameAndSignature() + >>>>> " @bci=" + vf.getBCI()); >>>>> >>>>> I'll work on debugging this. >>>>> >>>> >>>> Yes, that should be fixed. Maybe we need some more checks if 'method' >>>> and 'vf' are valid. >>> In fact, I'm consistently seeing the same NPE on x86 when I run the java app with "-XX:-Inline" >>> and then do 'jstack -F '. Do you know if there's a bug report open already for this? >>> The jdk9 source on my x86 system was a couple months (or so) old, so I wanted to see if >>> this still fails with current upstream code. I refreshed my source tree (via get_source.sh) >>> and tried to rebuild it, but I got a compile failure. I imagine someone else is already >>> working on that. >> Never mind . . . The compile failure was due to a conflict between a local change I made in >> one of the files and a change from upstream. I fixed it and the current upstream source builds >> fine on x86 now. However, the above-mentioned NPE still occurs most of the time. >> > > That's bad, but that seems to be another issue which should be fixed separately. > > If you have no more changes/addons compared to my last webrev I can > offer to submit a new request for review on behalf of you so we > finally get this in. Yes, please -- and thanks again for all your help. -Maynard > We will need on more review from the > serviceability team and a sponsor who will push the change for us. > > Regards, > Volker > >> -Maynard >>> >>> -Maynard >>>> >>> [snip] >>> >> > From Alan.Bateman at oracle.com Thu Dec 4 17:30:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 17:30:48 +0000 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <5480178A.9090709@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> <547F0889.5050204@oracle.com> <5480178A.9090709@oracle.com> Message-ID: <54809A48.5090201@oracle.com> On 04/12/2014 08:12, Chris Plummer wrote: > Hi Alan, > > While removing the java.io.File import, I also questioned why I had > java.io.IOException being imported. There were a couple of methods > that declared it thrown, and the main method therefore had to catch > it, but it turns out this was just copy/paste from the Settings.java > test I used as a template, and is not actually needed. I removed the > import, throws, and try/catch of IOException. > > All the other issues mentioned by others have also been addressed. A > new webrev can be found at: > > http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/ This looks good to me. -Alan. From volker.simonis at gmail.com Thu Dec 4 17:50:46 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Dec 2014 18:50:46 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 Message-ID: Hi, I'd like to submit this webrev which adds support for the SA agent on Linux/PPC64 on behalf of Maynard Johnson who is the main author of the change: http://cr.openjdk.java.net/~simonis/webrevs/8049716 https://bugs.openjdk.java.net/browse/JDK-8049716 I have already reviewed and tested the change and from my side everything looks fine. The change touches quite some shared code but all of these changes are trivial and straight-forward (i.e. they just add Linux/PPC64 support with the help of '#ifdef's in C or yet another 'elseif' clause in Java). We need a second reviewer and a sponsor who can push this to the hotspot repository once the review is completed. Thank you and best regards, Volker From chris.plummer at oracle.com Thu Dec 4 20:11:57 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 04 Dec 2014 12:11:57 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <54809A48.5090201@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> <547F0889.5050204@oracle.com> <5480178A.9090709@oracle.com> <54809A48.5090201@oracle.com> Message-ID: <5480C00D.1050003@oracle.com> On 12/4/14 9:30 AM, Alan Bateman wrote: > On 04/12/2014 08:12, Chris Plummer wrote: >> Hi Alan, >> >> While removing the java.io.File import, I also questioned why I had >> java.io.IOException being imported. There were a couple of methods >> that declared it thrown, and the main method therefore had to catch >> it, but it turns out this was just copy/paste from the Settings.java >> test I used as a template, and is not actually needed. I removed the >> import, throws, and try/catch of IOException. >> >> All the other issues mentioned by others have also been addressed. A >> new webrev can be found at: >> >> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/ > This looks good to me. > > -Alan. Thanks everyone for the reviews! Chris From asmundak at google.com Thu Dec 4 19:15:25 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 4 Dec 2014 11:15:25 -0800 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: Message-ID: The changes for agent/src/os/linux/symtab.c b/agent/src/os/linux/symtab.c in http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break Linux/PPC64 little-endian: it uses ABIv2, which dropped function descriptors. So the preprocessor brackets in it should read #if defined(ppc64) && !defined(ABI_ELFv2) instead of just #if defined(ppc64) Sorry for the late notice. Sasha On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: > Hi, > > I'd like to submit this webrev which adds support for the SA agent on > Linux/PPC64 on behalf of Maynard Johnson who is the main author of the > change: > > http://cr.openjdk.java.net/~simonis/webrevs/8049716 > https://bugs.openjdk.java.net/browse/JDK-8049716 > > I have already reviewed and tested the change and from my side > everything looks fine. > > The change touches quite some shared code but all of these changes are > trivial and straight-forward (i.e. they just add Linux/PPC64 support > with the help of '#ifdef's in C or yet another 'elseif' clause in > Java). > > We need a second reviewer and a sponsor who can push this to the > hotspot repository once the review is completed. > > Thank you and best regards, > Volker From brendan.d.gregg at gmail.com Thu Dec 4 22:55:37 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Thu, 4 Dec 2014 14:55:37 -0800 Subject: A hotspot patch for stack profiling (frame pointer) Message-ID: G'Day, I've hacked hotspot to return the frame pointer, in part to see what this involves, and also to have a working prototype for analysis. Along with an agent to resolve symbols, this has allowed full stack profiling using Linux perf_events. The following flame graphs show the resulting profiles. A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg Same thing, but this time disabling inlining, to show more frames: http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg As expected, performance is worse without inlining. You can compare the flame graphs side by side to see why. Less time spent doing work / I/O! https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff is my patch, and currently only works for x86-64. It removes RBP from the register pools, and inserts "mov(rbp, rsp)" into two function prologues. It is also unsupported: use at your own risk. I'm not a veteran hotspot engineer, so chances I messed something up are high. I'd love to be able to enable frame pointers in Oracle JDK, eg, with an -XX:+NoOmitFramePointer option. It could be put under -XX:+UnlockDiagnosticVMOptions or XX:+UnlockExperimentalVMOptions. So long as we had some way to turn it on. If someone wants to include (improve, rewrite) my patch, please do. I don't have much perf data yet, but on the vert.x microbenchmark it looked like returning the frame pointer cost 2.6% performance. I hope that's somewhat worst-case for production workloads. (I was also able to recover the 2.6% by fine tuning other options, so were this a production change, I'd be hoping not to regress performance at all.) We've discussed this before ( http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/thread.html#15939). The Solaris-assisted approach that Serguei Spitsyn described (JDK-6617153) should work very well. The JVM can run as-is, full stacks can be generated on-demand, and symbols should always be correct. The frame pointer approach costs a little performance, and only shows partial stacks after inlining (unless you disable inlining, but that can cost >40% performance). There is the other issue Volker Simonis mentioned as well, where some stacks may not be profiled correctly. And, if you are unlucky, symbols can move during the profile, so any static perf-map-agent map will translate some incorrectly (I've considered developing a way to detect this, and highlight such frames as dubious.) At Netflix we are mostly Java on Linux. Switching to Oracle Solaris for this feature is going to be a tough sell, especially when the value of full stack profiling isn't widely understood. I personally think it might be a bit easier if a -XX:+NoOmitFramePointer option existed, so Linux users can try the feature, then consider the better Solaris version after gaining solid experience on why it is so important. We recently blogged about the value of stack profiling and flame graphs, http://techblog.netflix.com/2014/11/nodejs-in-flames.html, although this was for Node.js, which already has frame pointer support. If anyone wants to try generating these mixed mode CPU flame graphs themselves (in a test environment!), the first step is to compile OpenJDK 8 b132 with the previous patch, and get that running. Also install the packages for the "perf" command. The remaining steps would be something like: # git clone --depth=1 https://github.com/brendangregg/FlameGraph # git clone --depth=1 https://github.com/jrudolph/perf-map-agent # cd perf-map-agent # export JAVA_HOME=/... # cmake . # make # perf record -F 99 -p `pgrep -n java` -g -- sleep 30 # java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar net.virtualvoid.perf.AttachOnce `pgrep -n java` # perf script > ../FlameGraph/out.stacks # cd ../FlameGraph # ./stackcollapse-perf.pl < out.stacks | ./flamegraph.pl --color=java > out.svg Finally, if you are new to CPU flame graphs, see http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html . Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: From maynardj at us.ibm.com Thu Dec 4 23:43:38 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Thu, 04 Dec 2014 17:43:38 -0600 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: Message-ID: <5480F1AA.4010900@us.ibm.com> On 12/04/2014 01:15 PM, Alexander Smundak wrote: > The changes for agent/src/os/linux/symtab.c > b/agent/src/os/linux/symtab.c in > http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break > Linux/PPC64 little-endian: > it uses ABIv2, which dropped function descriptors. So the preprocessor > brackets in it should > read > #if defined(ppc64) && !defined(ABI_ELFv2) > instead of just > #if defined(ppc64) Hi, Alexander, I think this is actually fine everywhere except one place. The 'opd' variable will be set to something other than NULL at line 379 only if running on ppc64 BE. So in the rest of that function, opd is checked for non-null before using it. The only place where I think there may be a problem is at line 455: -------------------------- #if defined(ppc64) // On Linux/PPC64 the debuginfo files contain an empty file descriptor // section (i.e. '.opd' section) which makes the resolution of symbols // with the above algorithm impossible (we would need the have both, the // .opd section from the library and the symbol table from the debuginfo // file which doesn't match with the current workflow.) if (false) { #else // Look for a separate debuginfo file. if (try_debuginfo) { #endif -------------------------- Here I think we should do as you suggest: #if defined(ppc64) && !defined(ABI_ELFv2) -Maynard > > Sorry for the late notice. > Sasha > > On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >> Hi, >> >> I'd like to submit this webrev which adds support for the SA agent on >> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >> change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >> https://bugs.openjdk.java.net/browse/JDK-8049716 >> >> I have already reviewed and tested the change and from my side >> everything looks fine. >> >> The change touches quite some shared code but all of these changes are >> trivial and straight-forward (i.e. they just add Linux/PPC64 support >> with the help of '#ifdef's in C or yet another 'elseif' clause in >> Java). >> >> We need a second reviewer and a sponsor who can push this to the >> hotspot repository once the review is completed. >> >> Thank you and best regards, >> Volker > From david.holmes at oracle.com Thu Dec 4 23:46:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 09:46:42 +1000 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <5480178A.9090709@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> <547F0889.5050204@oracle.com> <5480178A.9090709@oracle.com> Message-ID: <5480F262.9010407@oracle.com> Looks good to me too Chris - sorry for the delay getting back to you. But at least Kumar spotted all the typos :) David On 4/12/2014 6:12 PM, Chris Plummer wrote: > On 12/3/14 4:56 AM, Alan Bateman wrote: >> On 02/12/2014 02:39, Chris Plummer wrote: >>> Sorry about the long delay in getting back to this. I ran into two >>> separate JPRT issues that were preventing me from testing these >>> changes, plus I was on vacation last week. Here's an updated webrev. >>> I'm not sure where we left things, so I'll just say what's changed >>> since the original version: >>> >>> 1. Rewrote the test to be in Java instead of a shell script. >>> 2. Moved the test from hotspot/test/runtime/memory to >>> jdk/test/tools/launcher >>> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to >>> override the default 32k minimum value. >>> >>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ >> This looks to me. A minor comment for java.c is that this code uses >> 4-space indent (different to hotspot). >> >> The test looks okay too, you might just checking the copyright date as >> I assume was not written in 2010. Also I think the import of >> java.io.File may be left behind from the previous round. >> >> -Alan > Hi Alan, > > While removing the java.io.File import, I also questioned why I had > java.io.IOException being imported. There were a couple of methods that > declared it thrown, and the main method therefore had to catch it, but > it turns out this was just copy/paste from the Settings.java test I used > as a template, and is not actually needed. I removed the import, throws, > and try/catch of IOException. > > All the other issues mentioned by others have also been addressed. A new > webrev can be found at: > > http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/ > > thanks, > > Chris From serguei.spitsyn at oracle.com Fri Dec 5 00:38:35 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 04 Dec 2014 16:38:35 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <5480F262.9010407@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> <546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com> <547F0889.5050204@oracle.com> <5480178A.9090709@oracle.com> <5480F262.9010407@oracle.com> Message-ID: <5480FE8B.5010301@oracle.com> It still looks good to me too. :) Thanks, Serguei On 12/4/14 3:46 PM, David Holmes wrote: > Looks good to me too Chris - sorry for the delay getting back to you. > But at least Kumar spotted all the typos :) > > David > > On 4/12/2014 6:12 PM, Chris Plummer wrote: >> On 12/3/14 4:56 AM, Alan Bateman wrote: >>> On 02/12/2014 02:39, Chris Plummer wrote: >>>> Sorry about the long delay in getting back to this. I ran into two >>>> separate JPRT issues that were preventing me from testing these >>>> changes, plus I was on vacation last week. Here's an updated webrev. >>>> I'm not sure where we left things, so I'll just say what's changed >>>> since the original version: >>>> >>>> 1. Rewrote the test to be in Java instead of a shell script. >>>> 2. Moved the test from hotspot/test/runtime/memory to >>>> jdk/test/tools/launcher >>>> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to >>>> override the default 32k minimum value. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ >>> This looks to me. A minor comment for java.c is that this code uses >>> 4-space indent (different to hotspot). >>> >>> The test looks okay too, you might just checking the copyright date as >>> I assume was not written in 2010. Also I think the import of >>> java.io.File may be left behind from the previous round. >>> >>> -Alan >> Hi Alan, >> >> While removing the java.io.File import, I also questioned why I had >> java.io.IOException being imported. There were a couple of methods that >> declared it thrown, and the main method therefore had to catch it, but >> it turns out this was just copy/paste from the Settings.java test I used >> as a template, and is not actually needed. I removed the import, throws, >> and try/catch of IOException. >> >> All the other issues mentioned by others have also been addressed. A new >> webrev can be found at: >> >> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/ >> >> thanks, >> >> Chris From david.holmes at oracle.com Fri Dec 5 01:19:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 11:19:23 +1000 Subject: RFR 8064441: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <547DDFED.107@oracle.com> References: <5475CE4D.5010705@oracle.com> <547673CD.2070205@oracle.com> <5476E1D6.8010601@oracle.com> <547C31ED.40607@oracle.com> <547D883C.8060400@oracle.com> <547DDFED.107@oracle.com> Message-ID: <5481081B.6080403@oracle.com> On 3/12/2014 1:51 AM, Jaroslav Bachorik wrote: > On 12/02/2014 10:37 AM, David Holmes wrote: >> On 1/12/2014 7:16 PM, Jaroslav Bachorik wrote: >>> On 11/27/2014 09:33 AM, Jaroslav Bachorik wrote: >>>> On 11/27/2014 01:43 AM, David Holmes wrote: >>>>> On 26/11/2014 10:57 PM, Jaroslav Bachorik wrote: >>>>>> Please, review the following test change >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8064441 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8064441/webrev.00 >>>>>> >>>>>> The test fails because of System.out.println() may induce unexpected >>>>>> locking. The solution is to use an already existing >>>>>> LockFreeLogManager >>>>>> library class to collect the logs in the lock-free manner and print >>>>>> the >>>>>> logs only after all the test code has been run. >>>>> >>>>> I seem to remember spending a lot of time on this test in the past, >>>>> where the phaser usage was intended to ensure that we could not be >>>>> seen >>>>> to be blocking on the internal locks associated with the println. >>>>> Where >>>>> has this gone wrong? >>>> >>>> The remaining problem is the usage of System.out.print[ln]() inside the >>>> test threads. System.out.print[ln]() might involve blocking the calling >>>> thread and eg. create false positives when the test is waiting for a >>>> thread to enter the blocked state. >>>> >>>>> >>>>> What are the semantics of the lockfreelogger? When will we see its >>>>> output? >>>> >>>> It is using thread local lists of the logging records. Each logging >>>> record has an id which is unique and monotonous over all the threads -> >>>> an AtomicInteger instance is used to achieve this. >>>> >>>> You can retrieve the log output (ordered by the log record id) by >>>> calling LockFreeLogManager.toString(). >>>> >>>> Review for the LockFreeLogManager is available here >>>> [http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015848.html] >>>> >>>> >>>> >>> >>> David, are you ok with this change then? >> >> I guess so. Still not sure why we see the println problem though - but >> don't have time to delve into it. > > Thanks! > > PrintStream and Writer are full of synchronized blocks. When on use them > in multithreaded environment an occasional blocking might occur. > > For example, in Locks.java, 'LockAThread' and 'LockBThread' threads run > concurrently, both of them outputting some log info via System.out. So > it may happen that when asserting the 'LockAThread' thread state in > 'checkBlockedObject' the thread is in blocked state thanks to blocking > on the output stream internals rather than on the test monitor. Yes but that is what the Phaser is supposed to prevent - the logging occurs prior to the phaser actions. David > I hope this clarifies the problem a bit. > > -JB- > >> >> Thanks, >> David >> >>> Thanks, >>> >>> -JB- >>> >>>> >>>> >>>> -JB- >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>> >>> > From asmundak at google.com Fri Dec 5 01:50:08 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 4 Dec 2014 17:50:08 -0800 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <5480F1AA.4010900@us.ibm.com> References: <5480F1AA.4010900@us.ibm.com> Message-ID: You are correct, but there no need to have this code for LE at all. BTW, a bit on nitpicking in the same file: + String endian = System.getProperty("sun.cpu.endian"); + if (endian.equals("big")) + return true; + else + return false; can be rewirtten as return "big".equals(System.getProperty("sun.cpu.endian")); On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: > On 12/04/2014 01:15 PM, Alexander Smundak wrote: >> The changes for agent/src/os/linux/symtab.c >> b/agent/src/os/linux/symtab.c in >> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >> Linux/PPC64 little-endian: >> it uses ABIv2, which dropped function descriptors. So the preprocessor >> brackets in it should >> read >> #if defined(ppc64) && !defined(ABI_ELFv2) >> instead of just >> #if defined(ppc64) > Hi, Alexander, > I think this is actually fine everywhere except one place. The 'opd' variable will be > set to something other than NULL at line 379 only if running on ppc64 BE. So in > the rest of that function, opd is checked for non-null before using it. The only > place where I think there may be a problem is at line 455: > > -------------------------- > #if defined(ppc64) > // On Linux/PPC64 the debuginfo files contain an empty file descriptor > // section (i.e. '.opd' section) which makes the resolution of symbols > // with the above algorithm impossible (we would need the have both, the > // .opd section from the library and the symbol table from the debuginfo > // file which doesn't match with the current workflow.) > if (false) { > #else > // Look for a separate debuginfo file. > if (try_debuginfo) { > #endif > -------------------------- > > Here I think we should do as you suggest: > #if defined(ppc64) && !defined(ABI_ELFv2) > > -Maynard >> >> Sorry for the late notice. >> Sasha >> >> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>> Hi, >>> >>> I'd like to submit this webrev which adds support for the SA agent on >>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>> change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>> >>> I have already reviewed and tested the change and from my side >>> everything looks fine. >>> >>> The change touches quite some shared code but all of these changes are >>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>> Java). >>> >>> We need a second reviewer and a sponsor who can push this to the >>> hotspot repository once the review is completed. >>> >>> Thank you and best regards, >>> Volker >> > From jaroslav.bachorik at oracle.com Fri Dec 5 12:04:04 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 05 Dec 2014 13:04:04 +0100 Subject: RFR 8064441: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <5481081B.6080403@oracle.com> References: <5475CE4D.5010705@oracle.com> <547673CD.2070205@oracle.com> <5476E1D6.8010601@oracle.com> <547C31ED.40607@oracle.com> <547D883C.8060400@oracle.com> <547DDFED.107@oracle.com> <5481081B.6080403@oracle.com> Message-ID: <54819F34.3080104@oracle.com> On 12/05/2014 02:19 AM, David Holmes wrote: > On 3/12/2014 1:51 AM, Jaroslav Bachorik wrote: >> On 12/02/2014 10:37 AM, David Holmes wrote: >>> On 1/12/2014 7:16 PM, Jaroslav Bachorik wrote: >>>> On 11/27/2014 09:33 AM, Jaroslav Bachorik wrote: >>>>> On 11/27/2014 01:43 AM, David Holmes wrote: >>>>>> On 26/11/2014 10:57 PM, Jaroslav Bachorik wrote: >>>>>>> Please, review the following test change >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8064441 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8064441/webrev.00 >>>>>>> >>>>>>> The test fails because of System.out.println() may induce unexpected >>>>>>> locking. The solution is to use an already existing >>>>>>> LockFreeLogManager >>>>>>> library class to collect the logs in the lock-free manner and print >>>>>>> the >>>>>>> logs only after all the test code has been run. >>>>>> >>>>>> I seem to remember spending a lot of time on this test in the past, >>>>>> where the phaser usage was intended to ensure that we could not be >>>>>> seen >>>>>> to be blocking on the internal locks associated with the println. >>>>>> Where >>>>>> has this gone wrong? >>>>> >>>>> The remaining problem is the usage of System.out.print[ln]() inside >>>>> the >>>>> test threads. System.out.print[ln]() might involve blocking the >>>>> calling >>>>> thread and eg. create false positives when the test is waiting for a >>>>> thread to enter the blocked state. >>>>> >>>>>> >>>>>> What are the semantics of the lockfreelogger? When will we see its >>>>>> output? >>>>> >>>>> It is using thread local lists of the logging records. Each logging >>>>> record has an id which is unique and monotonous over all the >>>>> threads -> >>>>> an AtomicInteger instance is used to achieve this. >>>>> >>>>> You can retrieve the log output (ordered by the log record id) by >>>>> calling LockFreeLogManager.toString(). >>>>> >>>>> Review for the LockFreeLogManager is available here >>>>> [http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015848.html] >>>>> >>>>> >>>>> >>>>> >>>> >>>> David, are you ok with this change then? >>> >>> I guess so. Still not sure why we see the println problem though - but >>> don't have time to delve into it. >> >> Thanks! >> >> PrintStream and Writer are full of synchronized blocks. When on use them >> in multithreaded environment an occasional blocking might occur. >> >> For example, in Locks.java, 'LockAThread' and 'LockBThread' threads run >> concurrently, both of them outputting some log info via System.out. So >> it may happen that when asserting the 'LockAThread' thread state in >> 'checkBlockedObject' the thread is in blocked state thanks to blocking >> on the output stream internals rather than on the test monitor. > > Yes but that is what the Phaser is supposed to prevent - the logging > occurs prior to the phaser actions. I would be lying if I told I knew exactly where the contention was happening. But when I removed the logging completely I wasn't able to reproduce the failure in 500 subsequent runs (usually it took up to 100 runs to encounter the failure) and from that and the fact that there is no other place the contention could take place, short of the Phaser itself, I deduced that the logging was the culprit. With the new collecting ("lock-free") logger the test also runs without the failure in 500 runs so I suppose it was the logging. -JB- > > David > >> I hope this clarifies the problem a bit. >> >> -JB- >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> >>>> -JB- >>>> >>>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>> >>>> >> From maynardj at us.ibm.com Fri Dec 5 14:10:58 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Fri, 05 Dec 2014 08:10:58 -0600 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> Message-ID: <5481BCF2.9050501@us.ibm.com> On 12/04/2014 07:50 PM, Alexander Smundak wrote: > You are correct, but there no need to have this code for LE at all. Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file along with the "#if defined(ppc64)". > > BTW, a bit on nitpicking in the same file: > + String endian = System.getProperty("sun.cpu.endian"); > + if (endian.equals("big")) > + return true; > + else > + return false; > can be rewirtten as > return "big".equals(System.getProperty("sun.cpu.endian")); Right. A silly piece of coding there. :-/ -Maynard > > > On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>> The changes for agent/src/os/linux/symtab.c >>> b/agent/src/os/linux/symtab.c in >>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>> Linux/PPC64 little-endian: >>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>> brackets in it should >>> read >>> #if defined(ppc64) && !defined(ABI_ELFv2) >>> instead of just >>> #if defined(ppc64) >> Hi, Alexander, >> I think this is actually fine everywhere except one place. The 'opd' variable will be >> set to something other than NULL at line 379 only if running on ppc64 BE. So in >> the rest of that function, opd is checked for non-null before using it. The only >> place where I think there may be a problem is at line 455: >> >> -------------------------- >> #if defined(ppc64) >> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >> // section (i.e. '.opd' section) which makes the resolution of symbols >> // with the above algorithm impossible (we would need the have both, the >> // .opd section from the library and the symbol table from the debuginfo >> // file which doesn't match with the current workflow.) >> if (false) { >> #else >> // Look for a separate debuginfo file. >> if (try_debuginfo) { >> #endif >> -------------------------- >> >> Here I think we should do as you suggest: >> #if defined(ppc64) && !defined(ABI_ELFv2) >> >> -Maynard >>> >>> Sorry for the late notice. >>> Sasha >>> >>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>> Hi, >>>> >>>> I'd like to submit this webrev which adds support for the SA agent on >>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>> change: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>> >>>> I have already reviewed and tested the change and from my side >>>> everything looks fine. >>>> >>>> The change touches quite some shared code but all of these changes are >>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>> Java). >>>> >>>> We need a second reviewer and a sponsor who can push this to the >>>> hotspot repository once the review is completed. >>>> >>>> Thank you and best regards, >>>> Volker >>> >> > From volker.simonis at gmail.com Fri Dec 5 15:01:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 16:01:33 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <5481BCF2.9050501@us.ibm.com> References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: Hi Sasha, thanks for looking at this change. I'll incorporate your suggestions into the final version. I'm just waiting for one more review before preparing a new webrev. Regards, Volker On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: > On 12/04/2014 07:50 PM, Alexander Smundak wrote: >> You are correct, but there no need to have this code for LE at all. > Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file > along with the "#if defined(ppc64)". >> >> BTW, a bit on nitpicking in the same file: >> + String endian = System.getProperty("sun.cpu.endian"); >> + if (endian.equals("big")) >> + return true; >> + else >> + return false; >> can be rewirtten as >> return "big".equals(System.getProperty("sun.cpu.endian")); > Right. A silly piece of coding there. :-/ > > -Maynard >> >> >> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>> The changes for agent/src/os/linux/symtab.c >>>> b/agent/src/os/linux/symtab.c in >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>> Linux/PPC64 little-endian: >>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>> brackets in it should >>>> read >>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>> instead of just >>>> #if defined(ppc64) >>> Hi, Alexander, >>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>> the rest of that function, opd is checked for non-null before using it. The only >>> place where I think there may be a problem is at line 455: >>> >>> -------------------------- >>> #if defined(ppc64) >>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>> // section (i.e. '.opd' section) which makes the resolution of symbols >>> // with the above algorithm impossible (we would need the have both, the >>> // .opd section from the library and the symbol table from the debuginfo >>> // file which doesn't match with the current workflow.) >>> if (false) { >>> #else >>> // Look for a separate debuginfo file. >>> if (try_debuginfo) { >>> #endif >>> -------------------------- >>> >>> Here I think we should do as you suggest: >>> #if defined(ppc64) && !defined(ABI_ELFv2) >>> >>> -Maynard >>>> >>>> Sorry for the late notice. >>>> Sasha >>>> >>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>> Hi, >>>>> >>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>> change: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>> >>>>> I have already reviewed and tested the change and from my side >>>>> everything looks fine. >>>>> >>>>> The change touches quite some shared code but all of these changes are >>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>> Java). >>>>> >>>>> We need a second reviewer and a sponsor who can push this to the >>>>> hotspot repository once the review is completed. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>> >>> >> > From volker.simonis at gmail.com Fri Dec 5 19:22:22 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 20:22:22 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: Hi Brendan, I'm still not understanding who is taking the actual stack traces (let alone the symbols) in your examples. Is this done by 'perf' itself based only on the frame pointer? As I wrote before, this is pretty hard to get right for a JVM, but there are good approximations. Have you looked at the 'jstack' tool which is part of the JDK? If you run it on a Java process, it will give you exact stack traces with full inlining information. However this only works at safepoints so it is probably not suitable for profiling with performance counters. But you can also use 'jstack -F -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most of the time even with inlined Java frames. This is probably the best you can get when interrupting a running JVM at an arbitrary point in time. As you mentioned in one of your blogs, the VM can be in the C-Library or even in the kernel at that time which don't preserve the frame pointer either. So it will be already hard to even walk up to the first Java frame. But nevertheless, if the output of 'jstack -F -m' is "good enough" for your purpose, you can implement something similar in 'perf' or a helper library of 'perf' and be happy (I don't actually know how perf takes stack traces but I suppose there may some kind of callback mechanism for walking unknown frames). This is actually not so hard. I've recently implemented a "print_native_stack()" function within hotspot itself (you can call it for example from gdb during debugging - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). Maye you could call this functions directly from 'perf' if perf attaches with ptrace to the process (I assume it does or how else could it walk the stack)? These were just some random thoughts with the hope that they may be helpful. Regards, Volker PS: by the way - the flame graphs look really impressive and it would be really nice to have something like this for Java. On Thu, Dec 4, 2014 at 11:55 PM, Brendan Gregg wrote: > G'Day, > > I've hacked hotspot to return the frame pointer, in part to see what this > involves, and also to have a working prototype for analysis. Along with an > agent to resolve symbols, this has allowed full stack profiling using Linux > perf_events. The following flame graphs show the resulting profiles. > > A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg > > Same thing, but this time disabling inlining, to show more frames: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg > > As expected, performance is worse without inlining. You can compare the > flame graphs side by side to see why. Less time spent doing work / I/O! > > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > is my patch, and currently only works for x86-64. It removes RBP from the > register pools, and inserts "mov(rbp, rsp)" into two function prologues. It > is also unsupported: use at your own risk. I'm not a veteran hotspot > engineer, so chances I messed something up are high. > > I'd love to be able to enable frame pointers in Oracle JDK, eg, with an > -XX:+NoOmitFramePointer option. It could be put under > -XX:+UnlockDiagnosticVMOptions or XX:+UnlockExperimentalVMOptions. So long > as we had some way to turn it on. If someone wants to include (improve, > rewrite) my patch, please do. > > I don't have much perf data yet, but on the vert.x microbenchmark it looked > like returning the frame pointer cost 2.6% performance. I hope that's > somewhat worst-case for production workloads. (I was also able to recover > the 2.6% by fine tuning other options, so were this a production change, I'd > be hoping not to regress performance at all.) > > We've discussed this before > (http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/thread.html#15939). > The Solaris-assisted approach that Serguei Spitsyn described (JDK-6617153) > should work very well. The JVM can run as-is, full stacks can be generated > on-demand, and symbols should always be correct. > > The frame pointer approach costs a little performance, and only shows > partial stacks after inlining (unless you disable inlining, but that can > cost >40% performance). There is the other issue Volker Simonis mentioned as > well, where some stacks may not be profiled correctly. And, if you are > unlucky, symbols can move during the profile, so any static perf-map-agent > map will translate some incorrectly (I've considered developing a way to > detect this, and highlight such frames as dubious.) > > At Netflix we are mostly Java on Linux. Switching to Oracle Solaris for this > feature is going to be a tough sell, especially when the value of full stack > profiling isn't widely understood. I personally think it might be a bit > easier if a -XX:+NoOmitFramePointer option existed, so Linux users can try > the feature, then consider the better Solaris version after gaining solid > experience on why it is so important. > > We recently blogged about the value of stack profiling and flame graphs, > http://techblog.netflix.com/2014/11/nodejs-in-flames.html, although this was > for Node.js, which already has frame pointer support. > > If anyone wants to try generating these mixed mode CPU flame graphs > themselves (in a test environment!), the first step is to compile OpenJDK 8 > b132 with the previous patch, and get that running. Also install the > packages for the "perf" command. The remaining steps would be something > like: > > # git clone --depth=1 https://github.com/brendangregg/FlameGraph > # git clone --depth=1 https://github.com/jrudolph/perf-map-agent > # cd perf-map-agent > # export JAVA_HOME=/... > # cmake . > # make > # perf record -F 99 -p `pgrep -n java` -g -- sleep 30 > # java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar > net.virtualvoid.perf.AttachOnce `pgrep -n java` > # perf script > ../FlameGraph/out.stacks > # cd ../FlameGraph > # ./stackcollapse-perf.pl < out.stacks | ./flamegraph.pl --color=java > > out.svg > > Finally, if you are new to CPU flame graphs, see > http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html . > > Brendan From staffan.larsen at oracle.com Fri Dec 5 19:34:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 5 Dec 2014 20:34:43 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: Just to note that the implementation of ?jstack -F? is not at all suitable for profiling since has a very high overhead (it attaches a debugger to the process). /Staffan > On 5 dec 2014, at 20:22, Volker Simonis wrote: > > Hi Brendan, > > I'm still not understanding who is taking the actual stack traces (let > alone the symbols) in your examples. Is this done by 'perf' itself > based only on the frame pointer? > > As I wrote before, this is pretty hard to get right for a JVM, but > there are good approximations. Have you looked at the 'jstack' tool > which is part of the JDK? If you run it on a Java process, it will > give you exact stack traces with full inlining information. However > this only works at safepoints so it is probably not suitable for > profiling with performance counters. But you can also use 'jstack -F > -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most > of the time even with inlined Java frames. This is probably the best > you can get when interrupting a running JVM at an arbitrary point in > time. As you mentioned in one of your blogs, the VM can be in the > C-Library or even in the kernel at that time which don't preserve the > frame pointer either. So it will be already hard to even walk up to > the first Java frame. > > But nevertheless, if the output of 'jstack -F -m' is "good enough" for > your purpose, you can implement something similar in 'perf' or a > helper library of 'perf' and be happy (I don't actually know how perf > takes stack traces but I suppose there may some kind of callback > mechanism for walking unknown frames). This is actually not so hard. > I've recently implemented a "print_native_stack()" function within > hotspot itself (you can call it for example from gdb during debugging > - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). > Maye you could call this functions directly from 'perf' if perf > attaches with ptrace to the process (I assume it does or how else > could it walk the stack)? > > These were just some random thoughts with the hope that they may be helpful. > > Regards, > Volker > > PS: by the way - the flame graphs look really impressive and it would > be really nice to have something like this for Java. > > > On Thu, Dec 4, 2014 at 11:55 PM, Brendan Gregg > wrote: >> G'Day, >> >> I've hacked hotspot to return the frame pointer, in part to see what this >> involves, and also to have a working prototype for analysis. Along with an >> agent to resolve symbols, this has allowed full stack profiling using Linux >> perf_events. The following flame graphs show the resulting profiles. >> >> A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> Same thing, but this time disabling inlining, to show more frames: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg >> >> As expected, performance is worse without inlining. You can compare the >> flame graphs side by side to see why. Less time spent doing work / I/O! >> >> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >> is my patch, and currently only works for x86-64. It removes RBP from the >> register pools, and inserts "mov(rbp, rsp)" into two function prologues. It >> is also unsupported: use at your own risk. I'm not a veteran hotspot >> engineer, so chances I messed something up are high. >> >> I'd love to be able to enable frame pointers in Oracle JDK, eg, with an >> -XX:+NoOmitFramePointer option. It could be put under >> -XX:+UnlockDiagnosticVMOptions or XX:+UnlockExperimentalVMOptions. So long >> as we had some way to turn it on. If someone wants to include (improve, >> rewrite) my patch, please do. >> >> I don't have much perf data yet, but on the vert.x microbenchmark it looked >> like returning the frame pointer cost 2.6% performance. I hope that's >> somewhat worst-case for production workloads. (I was also able to recover >> the 2.6% by fine tuning other options, so were this a production change, I'd >> be hoping not to regress performance at all.) >> >> We've discussed this before >> (http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/thread.html#15939). >> The Solaris-assisted approach that Serguei Spitsyn described (JDK-6617153) >> should work very well. The JVM can run as-is, full stacks can be generated >> on-demand, and symbols should always be correct. >> >> The frame pointer approach costs a little performance, and only shows >> partial stacks after inlining (unless you disable inlining, but that can >> cost >40% performance). There is the other issue Volker Simonis mentioned as >> well, where some stacks may not be profiled correctly. And, if you are >> unlucky, symbols can move during the profile, so any static perf-map-agent >> map will translate some incorrectly (I've considered developing a way to >> detect this, and highlight such frames as dubious.) >> >> At Netflix we are mostly Java on Linux. Switching to Oracle Solaris for this >> feature is going to be a tough sell, especially when the value of full stack >> profiling isn't widely understood. I personally think it might be a bit >> easier if a -XX:+NoOmitFramePointer option existed, so Linux users can try >> the feature, then consider the better Solaris version after gaining solid >> experience on why it is so important. >> >> We recently blogged about the value of stack profiling and flame graphs, >> http://techblog.netflix.com/2014/11/nodejs-in-flames.html, although this was >> for Node.js, which already has frame pointer support. >> >> If anyone wants to try generating these mixed mode CPU flame graphs >> themselves (in a test environment!), the first step is to compile OpenJDK 8 >> b132 with the previous patch, and get that running. Also install the >> packages for the "perf" command. The remaining steps would be something >> like: >> >> # git clone --depth=1 https://github.com/brendangregg/FlameGraph >> # git clone --depth=1 https://github.com/jrudolph/perf-map-agent >> # cd perf-map-agent >> # export JAVA_HOME=/... >> # cmake . >> # make >> # perf record -F 99 -p `pgrep -n java` -g -- sleep 30 >> # java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar >> net.virtualvoid.perf.AttachOnce `pgrep -n java` >> # perf script > ../FlameGraph/out.stacks >> # cd ../FlameGraph >> # ./stackcollapse-perf.pl < out.stacks | ./flamegraph.pl --color=java > >> out.svg >> >> Finally, if you are new to CPU flame graphs, see >> http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html . >> >> Brendan From brendan.d.gregg at gmail.com Fri Dec 5 19:57:09 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Fri, 5 Dec 2014 11:57:09 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg wrote: > G'Day, > > I've hacked hotspot to return the frame pointer, in part to see what this > involves, and also to have a working prototype for analysis. Along with an > agent to resolve symbols, this has allowed full stack profiling using Linux > perf_events. The following flame graphs show the resulting profiles. > > A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg > > Same thing, but this time disabling inlining, to show more frames: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg > > As expected, performance is worse without inlining. You can compare the > flame graphs side by side to see why. Less time spent doing work / I/O! > > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > is my patch, > [...] > In case there's problems with the patch URL, the patch is: --- openjdk8clean/hotspot/src/cpu/x86/vm/x86_64.ad 2014-03-04 02:52:11.000000000 +0000 +++ openjdk8/hotspot/src/cpu/x86/vm/x86_64.ad 2014-11-08 01:10:49.686044933 +0000 @@ -166,10 +166,9 @@ // 3) reg_class stack_slots( /* one chunk of stack-based "registers" */ ) // -// Class for all pointer registers (including RSP) +// Class for all pointer registers (including RSP, excluding RBP) reg_class any_reg(RAX, RAX_H, RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -184,10 +183,9 @@ R14, R14_H, R15, R15_H); -// Class for all pointer registers except RSP +// Class for all pointer registers except RSP and RBP reg_class ptr_reg(RAX, RAX_H, RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -199,9 +197,8 @@ R13, R13_H, R14, R14_H); -// Class for all pointer registers except RAX and RSP +// Class for all pointer registers except RAX, RSP and RBP reg_class ptr_no_rax_reg(RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -226,9 +223,8 @@ R13, R13_H, R14, R14_H); -// Class for all pointer registers except RAX, RBX and RSP +// Class for all pointer registers except RAX, RBX, RSP and RBP reg_class ptr_no_rax_rbx_reg(RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -260,10 +256,9 @@ // Singleton class for TLS pointer reg_class ptr_r15_reg(R15, R15_H); -// Class for all long registers (except RSP) +// Class for all long registers (except RSP and RBP) reg_class long_reg(RAX, RAX_H, RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -275,9 +270,8 @@ R13, R13_H, R14, R14_H); -// Class for all long registers except RAX, RDX (and RSP) -reg_class long_no_rax_rdx_reg(RBP, RBP_H, - RDI, RDI_H, +// Class for all long registers except RAX, RDX (and RSP, RBP) +reg_class long_no_rax_rdx_reg(RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, RBX, RBX_H, @@ -288,9 +282,8 @@ R13, R13_H, R14, R14_H); -// Class for all long registers except RCX (and RSP) -reg_class long_no_rcx_reg(RBP, RBP_H, - RDI, RDI_H, +// Class for all long registers except RCX (and RSP, RBP) +reg_class long_no_rcx_reg(RDI, RDI_H, RSI, RSI_H, RAX, RAX_H, RDX, RDX_H, @@ -302,9 +295,8 @@ R13, R13_H, R14, R14_H); -// Class for all long registers except RAX (and RSP) -reg_class long_no_rax_reg(RBP, RBP_H, - RDX, RDX_H, +// Class for all long registers except RAX (and RSP, RBP) +reg_class long_no_rax_reg(RDX, RDX_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -325,10 +317,9 @@ // Singleton class for RDX long register reg_class long_rdx_reg(RDX, RDX_H); -// Class for all int registers (except RSP) +// Class for all int registers (except RSP and RBP) reg_class int_reg(RAX, RDX, - RBP, RDI, RSI, RCX, @@ -340,10 +331,9 @@ R13, R14); -// Class for all int registers except RCX (and RSP) +// Class for all int registers except RCX (and RSP, RBP) reg_class int_no_rcx_reg(RAX, RDX, - RBP, RDI, RSI, RBX, @@ -355,8 +345,7 @@ R14); // Class for all int registers except RAX, RDX (and RSP) -reg_class int_no_rax_rdx_reg(RBP, - RDI, +reg_class int_no_rax_rdx_reg(RDI, RSI, RCX, RBX, @@ -718,6 +707,7 @@ st->print("# stack bang"); st->print("\n\t"); st->print("pushq rbp\t# Save rbp"); + // BDG consider: st->print("movq rbp, rsp\t# "); if (framesize) { st->print("\n\t"); st->print("subq rsp, #%d\t# Create frame",framesize); --- openjdk8clean/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-03-04 02:52:11.000000000 +0000 +++ openjdk8/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-11-07 23:57:11.589593723 +0000 @@ -5236,6 +5236,7 @@ // We always push rbp, so that on return to interpreter rbp, will be // restored correctly and we can correct the stack. push(rbp); + mov(rbp, rsp); // Remove word for ebp framesize -= wordSize; --- openjdk8clean/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp 2014-03-04 02:52:10.000000000 +0000 +++ openjdk8/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp 2014-11-07 23:57:21.933257882 +0000 @@ -358,6 +358,7 @@ generate_stack_overflow_check(frame_size_in_bytes); push(rbp); + mov(rbp, rsp); #ifdef TIERED // c2 leaves fpu stack dirty. Clean it on entry if (UseSSE < 2 ) { Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Dec 5 22:50:52 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 23:50:52 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: Yes, that's clear. I didn't wanted to propose using "jstack -F" directly. I just wanted to say that it's possible for an external tool to get a "reasonable good" stack trace out of a JVM process at any time and "jstack -F" can be taken as a boilerplate of how to do that. That said, I still don't know how perf creates stack traces. Does it attach to the process with ptrace or how else does it inspect the stacks after a performance counter event? On Fri, Dec 5, 2014 at 8:34 PM, Staffan Larsen wrote: > Just to note that the implementation of ?jstack -F? is not at all suitable for profiling since has a very high overhead (it attaches a debugger to the process). > > /Staffan > >> On 5 dec 2014, at 20:22, Volker Simonis wrote: >> >> Hi Brendan, >> >> I'm still not understanding who is taking the actual stack traces (let >> alone the symbols) in your examples. Is this done by 'perf' itself >> based only on the frame pointer? >> >> As I wrote before, this is pretty hard to get right for a JVM, but >> there are good approximations. Have you looked at the 'jstack' tool >> which is part of the JDK? If you run it on a Java process, it will >> give you exact stack traces with full inlining information. However >> this only works at safepoints so it is probably not suitable for >> profiling with performance counters. But you can also use 'jstack -F >> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >> of the time even with inlined Java frames. This is probably the best >> you can get when interrupting a running JVM at an arbitrary point in >> time. As you mentioned in one of your blogs, the VM can be in the >> C-Library or even in the kernel at that time which don't preserve the >> frame pointer either. So it will be already hard to even walk up to >> the first Java frame. >> >> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >> your purpose, you can implement something similar in 'perf' or a >> helper library of 'perf' and be happy (I don't actually know how perf >> takes stack traces but I suppose there may some kind of callback >> mechanism for walking unknown frames). This is actually not so hard. >> I've recently implemented a "print_native_stack()" function within >> hotspot itself (you can call it for example from gdb during debugging >> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >> Maye you could call this functions directly from 'perf' if perf >> attaches with ptrace to the process (I assume it does or how else >> could it walk the stack)? >> >> These were just some random thoughts with the hope that they may be helpful. >> >> Regards, >> Volker >> >> PS: by the way - the flame graphs look really impressive and it would >> be really nice to have something like this for Java. >> >> >> On Thu, Dec 4, 2014 at 11:55 PM, Brendan Gregg >> wrote: >>> G'Day, >>> >>> I've hacked hotspot to return the frame pointer, in part to see what this >>> involves, and also to have a working prototype for analysis. Along with an >>> agent to resolve symbols, this has allowed full stack profiling using Linux >>> perf_events. The following flame graphs show the resulting profiles. >>> >>> A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): >>> >>> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >>> >>> Same thing, but this time disabling inlining, to show more frames: >>> >>> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg >>> >>> As expected, performance is worse without inlining. You can compare the >>> flame graphs side by side to see why. Less time spent doing work / I/O! >>> >>> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >>> is my patch, and currently only works for x86-64. It removes RBP from the >>> register pools, and inserts "mov(rbp, rsp)" into two function prologues. It >>> is also unsupported: use at your own risk. I'm not a veteran hotspot >>> engineer, so chances I messed something up are high. >>> >>> I'd love to be able to enable frame pointers in Oracle JDK, eg, with an >>> -XX:+NoOmitFramePointer option. It could be put under >>> -XX:+UnlockDiagnosticVMOptions or XX:+UnlockExperimentalVMOptions. So long >>> as we had some way to turn it on. If someone wants to include (improve, >>> rewrite) my patch, please do. >>> >>> I don't have much perf data yet, but on the vert.x microbenchmark it looked >>> like returning the frame pointer cost 2.6% performance. I hope that's >>> somewhat worst-case for production workloads. (I was also able to recover >>> the 2.6% by fine tuning other options, so were this a production change, I'd >>> be hoping not to regress performance at all.) >>> >>> We've discussed this before >>> (http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/thread.html#15939). >>> The Solaris-assisted approach that Serguei Spitsyn described (JDK-6617153) >>> should work very well. The JVM can run as-is, full stacks can be generated >>> on-demand, and symbols should always be correct. >>> >>> The frame pointer approach costs a little performance, and only shows >>> partial stacks after inlining (unless you disable inlining, but that can >>> cost >40% performance). There is the other issue Volker Simonis mentioned as >>> well, where some stacks may not be profiled correctly. And, if you are >>> unlucky, symbols can move during the profile, so any static perf-map-agent >>> map will translate some incorrectly (I've considered developing a way to >>> detect this, and highlight such frames as dubious.) >>> >>> At Netflix we are mostly Java on Linux. Switching to Oracle Solaris for this >>> feature is going to be a tough sell, especially when the value of full stack >>> profiling isn't widely understood. I personally think it might be a bit >>> easier if a -XX:+NoOmitFramePointer option existed, so Linux users can try >>> the feature, then consider the better Solaris version after gaining solid >>> experience on why it is so important. >>> >>> We recently blogged about the value of stack profiling and flame graphs, >>> http://techblog.netflix.com/2014/11/nodejs-in-flames.html, although this was >>> for Node.js, which already has frame pointer support. >>> >>> If anyone wants to try generating these mixed mode CPU flame graphs >>> themselves (in a test environment!), the first step is to compile OpenJDK 8 >>> b132 with the previous patch, and get that running. Also install the >>> packages for the "perf" command. The remaining steps would be something >>> like: >>> >>> # git clone --depth=1 https://github.com/brendangregg/FlameGraph >>> # git clone --depth=1 https://github.com/jrudolph/perf-map-agent >>> # cd perf-map-agent >>> # export JAVA_HOME=/... >>> # cmake . >>> # make >>> # perf record -F 99 -p `pgrep -n java` -g -- sleep 30 >>> # java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar >>> net.virtualvoid.perf.AttachOnce `pgrep -n java` >>> # perf script > ../FlameGraph/out.stacks >>> # cd ../FlameGraph >>> # ./stackcollapse-perf.pl < out.stacks | ./flamegraph.pl --color=java > >>> out.svg >>> >>> Finally, if you are new to CPU flame graphs, see >>> http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html . >>> >>> Brendan > From brendan.d.gregg at gmail.com Fri Dec 5 23:09:46 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Fri, 5 Dec 2014 15:09:46 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: G'Day Volker, On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis wrote: > Hi Brendan, > > I'm still not understanding who is taking the actual stack traces (let > alone the symbols) in your examples. Is this done by 'perf' itself > based only on the frame pointer? perf is walking the frame pointers. A JVMTI agent, perf-map-agent, is providing a map file for symbol translation under /tmp/perf-PID.map. Linux perf already hunts for such a file when doing symbol translation. > > As I wrote before, this is pretty hard to get right for a JVM, but > there are good approximations. Have you looked at the 'jstack' tool > which is part of the JDK? If you run it on a Java process, it will > give you exact stack traces with full inlining information. However > this only works at safepoints so it is probably not suitable for > profiling with performance counters. Right, jstack works, and I get full correct stacks. I do really want to take stacks at any moment: not just CPU samples, but when tracing kernel TCP events, or PMC cache miss profiling, etc. perf can already do many advanced tracing and profiling activities. I just needed the Java stacks for context. > But you can also use 'jstack -F > -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most > of the time even with inlined Java frames. This is probably the best > you can get when interrupting a running JVM at an arbitrary point in > time. As you mentioned in one of your blogs, the VM can be in the > C-Library or even in the kernel at that time which don't preserve the > frame pointer either. So it will be already hard to even walk up to > the first Java frame. Well, the JVMs I'm looking at are already built with -fno-omit-frame-pointer (which is good). I edited hotspot to preserve it as well. Here's before I changed hotspot: http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg Yes, most stacks are clearly broken. After changing hotspot: http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg It's looking pretty good. If you look carefully on the far left and right, there are 0.8% stacks in read() and write() directly from java, which may well be broken (unless a java thread is calling these directly; there could also be some gcc inlining going on). Even if they are broken, I can see 98% of my profile. Plus, I'd be interested to know what exactly is reusing the frame pointer, so we could fix that too. The Java stacks themselves are also about a third as deep as they should be, due to inlining. > > But nevertheless, if the output of 'jstack -F -m' is "good enough" for > your purpose, you can implement something similar in 'perf' or a > helper library of 'perf' and be happy (I don't actually know how perf > takes stack traces but I suppose there may some kind of callback > mechanism for walking unknown frames). This is actually not so hard. > I've recently implemented a "print_native_stack()" function within > hotspot itself (you can call it for example from gdb during debugging > - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). > Maye you could call this functions directly from 'perf' if perf > attaches with ptrace to the process (I assume it does or how else > could it walk the stack)? An OS-cooperative stack walker would be great, and I think the hotspot team is already doing this for Oracle Solaris. Thanks for the code too, this is pretty interesting. jstack -F -m eats 0.5s of CPU for me, so it would need work to make this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary kernel functions or tracepoints and get Java context from them, too. Eg, TCP functions, memory allocation, disk I/O, etc. > > These were just some random thoughts with the hope that they may be helpful. Yes, thanks! Brendan From dmitry.samersoff at oracle.com Sun Dec 7 14:17:41 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 07 Dec 2014 17:17:41 +0300 Subject: RFR(S) 8028773: SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> Message-ID: <54846185.3050508@oracle.com> Please, review a modified fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.03/ Windows compiler doesn't allow declaration in the middle of the function for c code. Also I put my few cents to reduce build noise and add a pragma that disable windows compiler warnings that have no value in this context. -Dmitry On 2014-12-03 16:01, Staffan Larsen wrote: > Changes look good. What testing have you done? > > /Staffan > >> On 3 dec 2014, at 13:06, Dmitry Samersoff wrote: >> >> Serguei, >> >> Updated webrev >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ >> >> -Dmitry >> >> On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> It is good in general modulo Staffan's comments. >>> >>> There are some inconsistencies: >>> - the ExceptionOccurred(env) is compared to != NULL (which make the >>> logic more complex) >>> in some places and no such comparison (implicit comparison instead) >>> in others >>> - two different forms of check/action are used: >>> - (*env)->ExceptionOccurred(env) and >>> - !(*env)->ExceptionOccurred(env) >>> >>> I'd suggest to do it the same way and always return the "default" value >>> if an exception occurred. >>> It will make the logic more flat and clear. >>> Otherwise, we have to think what exact value is returned in exception >>> occurred cases like at lines 241, 255. >>> >>> The comment // OOM is used inconsistently too. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>>> Please review the small fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>>> >>>> Added more missed exception checks to sadis.c >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- 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 joe.darcy at oracle.com Mon Dec 8 06:57:00 2014 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 07 Dec 2014 22:57:00 -0800 Subject: JDK 9 RFR of JDK-8066636: Suppress deprecation warnings in the jdk.jvmstat and jdk.jdi modules Message-ID: <54854BBC.3080908@oracle.com> Hello, Please review the small patch below to fix JDK-8066636: Suppress deprecation warnings in the jdk.jvmstat and jdk.jdi modules Thanks, -Joe diff -r 913808eaf19a src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java --- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java Mon Nov 10 08:43:27 2014 -0800 +++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java Sun Dec 07 22:52:50 2014 -0800 @@ -59,6 +59,7 @@ StackFrame get() throws IncompatibleThreadStateException; } + @SuppressWarnings("deprecation") public static Value evaluate(String expr, VirtualMachine vm, GetFrame frameGetter) throws ParseException, InvocationException, diff -r 913808eaf19a src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java --- a/src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java Mon Nov 10 08:43:27 2014 -0800 +++ b/src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java Sun Dec 07 22:52:50 2014 -0800 @@ -158,6 +158,7 @@ * the sun.jvmstat.perfdata.aliasmap file indicates some other * file as the source. */ + @SuppressWarnings("deprecation") private void buildAliasMap() { assert Thread.holdsLock(this); diff -r 913808eaf19a src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java --- a/src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java Mon Nov 10 08:43:27 2014 -0800 +++ b/src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java Sun Dec 07 22:52:50 2014 -0800 @@ -76,6 +76,7 @@ } } + @SuppressWarnings("deprecation") // Use of RMISecurityManager public static void main(String[] args) { String rminame = null; int argc = 0; From joe.darcy at oracle.com Mon Dec 8 07:04:38 2014 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 07 Dec 2014 23:04:38 -0800 Subject: JDK 9 RFR of JDK-8066634: Suppress deprecation warnings in java.management module Message-ID: <54854D86.5040501@oracle.com> Hello, Please review the patch below which addresses JDK-8066634: Suppress deprecation warnings in java.management module Thanks, -Joe diff -r 913808eaf19a src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java --- a/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java Mon Nov 10 08:43:27 2014 -0800 +++ b/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java Sun Dec 07 23:02:51 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 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 @@ -1707,16 +1707,19 @@ throw new UnsupportedOperationException("Not supported yet."); } + @SuppressWarnings("deprecation") public ObjectInputStream deserialize(ObjectName name, byte[] data) throws InstanceNotFoundException, OperationsException { throw new UnsupportedOperationException("Not supported yet."); } + @SuppressWarnings("deprecation") public ObjectInputStream deserialize(String className, byte[] data) throws OperationsException, ReflectionException { throw new UnsupportedOperationException("Not supported yet."); } + @SuppressWarnings("deprecation") public ObjectInputStream deserialize(String className, ObjectName loaderName, byte[] data) throws InstanceNotFoundException, OperationsException, ReflectionException { From staffan.larsen at oracle.com Mon Dec 8 07:23:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 8 Dec 2014 08:23:43 +0100 Subject: JDK 9 RFR of JDK-8066636: Suppress deprecation warnings in the jdk.jvmstat and jdk.jdi modules In-Reply-To: <54854BBC.3080908@oracle.com> References: <54854BBC.3080908@oracle.com> Message-ID: <5C92B60E-863B-4B4C-9873-E13DC028BE16@oracle.com> Looks good! Thanks, /Staffan > On 8 dec 2014, at 07:57, joe darcy wrote: > > Hello, > > Please review the small patch below to fix > > JDK-8066636: Suppress deprecation warnings in the jdk.jvmstat and jdk.jdi modules > > Thanks, > > -Joe > > diff -r 913808eaf19a src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java > --- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java Mon Nov 10 08:43:27 2014 -0800 > +++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java Sun Dec 07 22:52:50 2014 -0800 > @@ -59,6 +59,7 @@ > StackFrame get() throws IncompatibleThreadStateException; > } > > + @SuppressWarnings("deprecation") > public static Value evaluate(String expr, VirtualMachine vm, > GetFrame frameGetter) throws ParseException, > InvocationException, > diff -r 913808eaf19a src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java > --- a/src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java Mon Nov 10 08:43:27 2014 -0800 > +++ b/src/jdk.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java Sun Dec 07 22:52:50 2014 -0800 > @@ -158,6 +158,7 @@ > * the sun.jvmstat.perfdata.aliasmap file indicates some other > * file as the source. > */ > + @SuppressWarnings("deprecation") > private void buildAliasMap() { > assert Thread.holdsLock(this); > > diff -r 913808eaf19a src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java > --- a/src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java Mon Nov 10 08:43:27 2014 -0800 > +++ b/src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java Sun Dec 07 22:52:50 2014 -0800 > @@ -76,6 +76,7 @@ > } > } > > + @SuppressWarnings("deprecation") // Use of RMISecurityManager > public static void main(String[] args) { > String rminame = null; > int argc = 0; > From staffan.larsen at oracle.com Mon Dec 8 07:24:10 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 8 Dec 2014 08:24:10 +0100 Subject: JDK 9 RFR of JDK-8066634: Suppress deprecation warnings in java.management module In-Reply-To: <54854D86.5040501@oracle.com> References: <54854D86.5040501@oracle.com> Message-ID: <176D2575-3654-45A3-8C22-81A81AE5464C@oracle.com> Looks good! Thanks, /Staffan > On 8 dec 2014, at 08:04, joe darcy wrote: > > Hello, > > Please review the patch below which addresses > > JDK-8066634: Suppress deprecation warnings in java.management module > > Thanks, > > -Joe > > diff -r 913808eaf19a src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > --- a/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java Mon Nov 10 08:43:27 2014 -0800 > +++ b/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java Sun Dec 07 23:02:51 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 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 > @@ -1707,16 +1707,19 @@ > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(ObjectName name, byte[] data) throws InstanceNotFoundException, > OperationsException { > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(String className, byte[] data) throws OperationsException, > ReflectionException { > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(String className, ObjectName loaderName, > byte[] data) throws InstanceNotFoundException, OperationsException, > ReflectionException { > From Alan.Bateman at oracle.com Mon Dec 8 08:36:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Dec 2014 08:36:52 +0000 Subject: JDK 9 RFR of JDK-8066634: Suppress deprecation warnings in java.management module In-Reply-To: <54854D86.5040501@oracle.com> References: <54854D86.5040501@oracle.com> Message-ID: <54856324.8030504@oracle.com> I assume you meant to cc jmx-dev for this one. In any case it looks okay to me. -Alan On 08/12/2014 07:04, joe darcy wrote: > Hello, > > Please review the patch below which addresses > > JDK-8066634: Suppress deprecation warnings in java.management module > > Thanks, > > -Joe > > diff -r 913808eaf19a > src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > --- > a/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > Mon Nov 10 08:43:27 2014 -0800 > +++ > b/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > Sun Dec 07 23:02:51 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 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 > @@ -1707,16 +1707,19 @@ > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(ObjectName name, byte[] > data) throws InstanceNotFoundException, > OperationsException { > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(String className, byte[] > data) throws OperationsException, > ReflectionException { > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(String className, ObjectName > loaderName, > byte[] data) throws InstanceNotFoundException, > OperationsException, > ReflectionException { > From daniel.fuchs at oracle.com Mon Dec 8 09:26:07 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 08 Dec 2014 10:26:07 +0100 Subject: JDK 9 RFR of JDK-8066634: Suppress deprecation warnings in java.management module In-Reply-To: <54854D86.5040501@oracle.com> References: <54854D86.5040501@oracle.com> Message-ID: <54856EAF.50604@oracle.com> Hi Joe, Looks good! best regards, -- daniel On 12/8/14 8:04 AM, joe darcy wrote: > Hello, > > Please review the patch below which addresses > > JDK-8066634: Suppress deprecation warnings in java.management module > > Thanks, > > -Joe > > diff -r 913808eaf19a > src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > --- > a/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > Mon Nov 10 08:43:27 2014 -0800 > +++ > b/src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java > Sun Dec 07 23:02:51 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 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 > @@ -1707,16 +1707,19 @@ > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(ObjectName name, byte[] > data) throws InstanceNotFoundException, > OperationsException { > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(String className, byte[] > data) throws OperationsException, > ReflectionException { > throw new UnsupportedOperationException("Not supported yet."); > } > > + @SuppressWarnings("deprecation") > public ObjectInputStream deserialize(String className, ObjectName > loaderName, > byte[] data) throws InstanceNotFoundException, > OperationsException, > ReflectionException { > From serguei.spitsyn at oracle.com Mon Dec 8 11:02:47 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 08 Dec 2014 03:02:47 -0800 Subject: RFR(S) 8028773: SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <54846185.3050508@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> <54846185.3050508@oracle.com> Message-ID: <54858557.8030907@oracle.com> Looks good. Some minor comments. Better to reformat with one variable at a line: 113 const char *error_message = NULL, *jrepath = NULL, *libname = NULL; 283 jbyte *start, *end; Uninitialized locals: 115 #ifdef _WINDOWS 116 HINSTANCE hsdis_handle; 117 #else 118 void* hsdis_handle; 119 #endif ... 201 jlong result; ... 282 jboolean isCopy; 283 jbyte *start, *end; 284 jclass disclass; 285 const char *options; Unaligned parameters: 209 result = (*env)->CallLongMethod(env, denv->dis, denv->handle_event, denv->visitor, 210 event_string, (jlong) (uintptr_t)arg); Thanks, Serguei On 12/7/14 6:17 AM, Dmitry Samersoff wrote: > Please, review a modified fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.03/ > > Windows compiler doesn't allow declaration in the middle of the function > for c code. > > Also I put my few cents to reduce build noise and add a pragma that > disable windows compiler warnings that have no value in this context. > > -Dmitry > > > On 2014-12-03 16:01, Staffan Larsen wrote: >> Changes look good. What testing have you done? >> >> /Staffan >> >>> On 3 dec 2014, at 13:06, Dmitry Samersoff wrote: >>> >>> Serguei, >>> >>> Updated webrev >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ >>> >>> -Dmitry >>> >>> On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >>>> Dmitry, >>>> >>>> It is good in general modulo Staffan's comments. >>>> >>>> There are some inconsistencies: >>>> - the ExceptionOccurred(env) is compared to != NULL (which make the >>>> logic more complex) >>>> in some places and no such comparison (implicit comparison instead) >>>> in others >>>> - two different forms of check/action are used: >>>> - (*env)->ExceptionOccurred(env) and >>>> - !(*env)->ExceptionOccurred(env) >>>> >>>> I'd suggest to do it the same way and always return the "default" value >>>> if an exception occurred. >>>> It will make the logic more flat and clear. >>>> Otherwise, we have to think what exact value is returned in exception >>>> occurred cases like at lines 241, 255. >>>> >>>> The comment // OOM is used inconsistently too. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>>>> Please review the small fix. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>>>> >>>>> Added more missed exception checks to sadis.c >>>>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maynardj at us.ibm.com Mon Dec 8 15:05:54 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 08 Dec 2014 09:05:54 -0600 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: <5485BE52.9000500@us.ibm.com> On 12/05/2014 05:09 PM, Brendan Gregg wrote: > G'Day Volker, > > On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis > wrote: >> Hi Brendan, >> >> I'm still not understanding who is taking the actual stack traces (let >> alone the symbols) in your examples. Is this done by 'perf' itself >> based only on the frame pointer? > > perf is walking the frame pointers. Volker, to be specific, the perf profiling tool has a user space part and a kernel space part. The collection of stack traces is done by the kernel. When a user-specified event (or series of events) occur, the process being profiled is interrupted and the sampled information (which can optionally include a full stack trace) is made available to the user space perf tool to be saved to a file for future post-profiling processing. During the profiling phase, the perf tool collects information about the profiled process's memory mappings, which allows for this address-to-symbol. resolution, It's in the post-profiling phase where the sampled instruction, along with its associated stack trace, are resolved to the appropriate symbol (i.e., function/method) in a specific binary file (e.g., library, exectuable). And if the VM creates a /tmp/perf-.map file to save information about JITed methods, the perf's post-profiling tool will find it and use it to correlate sampled addresses it collected from the VM's executable anonymous memory mappings to the method names. -Maynard > > A JVMTI agent, perf-map-agent, is providing a map file for symbol > translation under /tmp/perf-PID.map. Linux perf already hunts for such > a file when doing symbol translation. > >> >> As I wrote before, this is pretty hard to get right for a JVM, but >> there are good approximations. Have you looked at the 'jstack' tool >> which is part of the JDK? If you run it on a Java process, it will >> give you exact stack traces with full inlining information. However >> this only works at safepoints so it is probably not suitable for >> profiling with performance counters. > > Right, jstack works, and I get full correct stacks. I do really want > to take stacks at any moment: not just CPU samples, but when tracing > kernel TCP events, or PMC cache miss profiling, etc. perf can already > do many advanced tracing and profiling activities. I just needed the > Java stacks for context. > >> But you can also use 'jstack -F >> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >> of the time even with inlined Java frames. This is probably the best >> you can get when interrupting a running JVM at an arbitrary point in >> time. As you mentioned in one of your blogs, the VM can be in the >> C-Library or even in the kernel at that time which don't preserve the >> frame pointer either. So it will be already hard to even walk up to >> the first Java frame. > > Well, the JVMs I'm looking at are already built with > -fno-omit-frame-pointer (which is good). I edited hotspot to preserve > it as well. > > Here's before I changed hotspot: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg > > Yes, most stacks are clearly broken. > > After changing hotspot: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg > > It's looking pretty good. If you look carefully on the far left and > right, there are 0.8% stacks in read() and write() directly from java, > which may well be broken (unless a java thread is calling these > directly; there could also be some gcc inlining going on). Even if > they are broken, I can see 98% of my profile. Plus, I'd be interested > to know what exactly is reusing the frame pointer, so we could fix > that too. > > The Java stacks themselves are also about a third as deep as they > should be, due to inlining. > >> >> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >> your purpose, you can implement something similar in 'perf' or a >> helper library of 'perf' and be happy (I don't actually know how perf >> takes stack traces but I suppose there may some kind of callback >> mechanism for walking unknown frames). This is actually not so hard. >> I've recently implemented a "print_native_stack()" function within >> hotspot itself (you can call it for example from gdb during debugging >> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >> Maye you could call this functions directly from 'perf' if perf >> attaches with ptrace to the process (I assume it does or how else >> could it walk the stack)? > > An OS-cooperative stack walker would be great, and I think the hotspot > team is already doing this for Oracle Solaris. Thanks for the code > too, this is pretty interesting. > > jstack -F -m eats 0.5s of CPU for me, so it would need work to make > this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary > kernel functions or tracepoints and get Java context from them, too. > Eg, TCP functions, memory allocation, disk I/O, etc. > >> >> These were just some random thoughts with the hope that they may be helpful. > > Yes, thanks! > > Brendan > From volker.simonis at gmail.com Mon Dec 8 16:58:10 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Dec 2014 17:58:10 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5485BE52.9000500@us.ibm.com> References: <5485BE52.9000500@us.ibm.com> Message-ID: On Mon, Dec 8, 2014 at 4:05 PM, Maynard Johnson wrote: > On 12/05/2014 05:09 PM, Brendan Gregg wrote: >> G'Day Volker, >> >> On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis >> wrote: >>> Hi Brendan, >>> >>> I'm still not understanding who is taking the actual stack traces (let >>> alone the symbols) in your examples. Is this done by 'perf' itself >>> based only on the frame pointer? >> >> perf is walking the frame pointers. > Volker, to be specific, the perf profiling tool has a user space part and a > kernel space part. The collection of stack traces is done by the kernel. Hi Maynard, thanks for the explanation. So how does the kernel kernel collects stack traces - simply by looking at the frame pointers? Is there any way of extension mechanism to support the kernel with this task (i.e. a callback mechanism where the kernel provides a pc/sp/p touple and gets back the previous frame or a kind of plugin/module which will be called for the stack trace generation). I suppose such extensibility will be hard to achieve because it would have to be executed in the kernel context but I just wanted to ask. Regards, Volker > When a user-specified event (or series of events) occur, the process > being profiled is interrupted and the sampled information (which can > optionally include a full stack trace) is made available to the user space > perf tool to be saved to a file for future post-profiling processing. > > During the profiling phase, the perf tool collects information about the > profiled process's memory mappings, which allows for this address-to-symbol. > resolution, It's in the post-profiling phase where the sampled instruction, > along with its associated stack trace, are resolved to the appropriate symbol > (i.e., function/method) in a specific binary file (e.g., library, exectuable). > > And if the VM creates a /tmp/perf-.map file to save information about > JITed methods, the perf's post-profiling tool will find it and use it to > correlate sampled addresses it collected from the VM's executable anonymous > memory mappings to the method names. > > -Maynard >> >> A JVMTI agent, perf-map-agent, is providing a map file for symbol >> translation under /tmp/perf-PID.map. Linux perf already hunts for such >> a file when doing symbol translation. >> >>> >>> As I wrote before, this is pretty hard to get right for a JVM, but >>> there are good approximations. Have you looked at the 'jstack' tool >>> which is part of the JDK? If you run it on a Java process, it will >>> give you exact stack traces with full inlining information. However >>> this only works at safepoints so it is probably not suitable for >>> profiling with performance counters. >> >> Right, jstack works, and I get full correct stacks. I do really want >> to take stacks at any moment: not just CPU samples, but when tracing >> kernel TCP events, or PMC cache miss profiling, etc. perf can already >> do many advanced tracing and profiling activities. I just needed the >> Java stacks for context. >> >>> But you can also use 'jstack -F >>> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >>> of the time even with inlined Java frames. This is probably the best >>> you can get when interrupting a running JVM at an arbitrary point in >>> time. As you mentioned in one of your blogs, the VM can be in the >>> C-Library or even in the kernel at that time which don't preserve the >>> frame pointer either. So it will be already hard to even walk up to >>> the first Java frame. >> >> Well, the JVMs I'm looking at are already built with >> -fno-omit-frame-pointer (which is good). I edited hotspot to preserve >> it as well. >> >> Here's before I changed hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg >> >> Yes, most stacks are clearly broken. >> >> After changing hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> It's looking pretty good. If you look carefully on the far left and >> right, there are 0.8% stacks in read() and write() directly from java, >> which may well be broken (unless a java thread is calling these >> directly; there could also be some gcc inlining going on). Even if >> they are broken, I can see 98% of my profile. Plus, I'd be interested >> to know what exactly is reusing the frame pointer, so we could fix >> that too. >> >> The Java stacks themselves are also about a third as deep as they >> should be, due to inlining. >> >>> >>> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >>> your purpose, you can implement something similar in 'perf' or a >>> helper library of 'perf' and be happy (I don't actually know how perf >>> takes stack traces but I suppose there may some kind of callback >>> mechanism for walking unknown frames). This is actually not so hard. >>> I've recently implemented a "print_native_stack()" function within >>> hotspot itself (you can call it for example from gdb during debugging >>> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >>> Maye you could call this functions directly from 'perf' if perf >>> attaches with ptrace to the process (I assume it does or how else >>> could it walk the stack)? >> >> An OS-cooperative stack walker would be great, and I think the hotspot >> team is already doing this for Oracle Solaris. Thanks for the code >> too, this is pretty interesting. >> >> jstack -F -m eats 0.5s of CPU for me, so it would need work to make >> this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary >> kernel functions or tracepoints and get Java context from them, too. >> Eg, TCP functions, memory allocation, disk I/O, etc. >> >>> >>> These were just some random thoughts with the hope that they may be helpful. >> >> Yes, thanks! >> >> Brendan >> > From mikael.gerdin at oracle.com Mon Dec 8 17:15:35 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Dec 2014 18:15:35 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5485BE52.9000500@us.ibm.com> References: <5485BE52.9000500@us.ibm.com> Message-ID: <5485DCB7.4010901@oracle.com> Maynard, On 2014-12-08 16:05, Maynard Johnson wrote: > On 12/05/2014 05:09 PM, Brendan Gregg wrote: >> G'Day Volker, >> >> On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis >> wrote: >>> Hi Brendan, >>> >>> I'm still not understanding who is taking the actual stack traces (let >>> alone the symbols) in your examples. Is this done by 'perf' itself >>> based only on the frame pointer? >> >> perf is walking the frame pointers. > Volker, to be specific, the perf profiling tool has a user space part and a > kernel space part. The collection of stack traces is done by the kernel. > When a user-specified event (or series of events) occur, the process > being profiled is interrupted and the sampled information (which can > optionally include a full stack trace) is made available to the user space > perf tool to be saved to a file for future post-profiling processing. > > During the profiling phase, the perf tool collects information about the > profiled process's memory mappings, which allows for this address-to-symbol. > resolution, It's in the post-profiling phase where the sampled instruction, > along with its associated stack trace, are resolved to the appropriate symbol > (i.e., function/method) in a specific binary file (e.g., library, exectuable). > > And if the VM creates a /tmp/perf-.map file to save information about > JITed methods, the perf's post-profiling tool will find it and use it to > correlate sampled addresses it collected from the VM's executable anonymous > memory mappings to the method names. I seem to recall reading about perf having support for DWARF debug info. If the VM (or a JVM/TI agent) could create DWARF debug symbols, could that be used to convey information about inlined functions and stack unwinding without frame pointers? I realize that emitting DWARF debug symbols for generated code is not a trivial undertaking but since perf is running sampling in the kernel and we can't disable inlining that seems to be one of the few ways we can get complete stack traces. There would be several other advantages to having DWARF symbols for generated code, GDB can use them when debugging the JVM for example. An alternate approach could be to extend the information in perf-.map to have more detailed PC ranges with information about which functions are inlined. A lot of that information is available in the VM but not necessarily exposed via the tool APIs /Mikael > > -Maynard >> >> A JVMTI agent, perf-map-agent, is providing a map file for symbol >> translation under /tmp/perf-PID.map. Linux perf already hunts for such >> a file when doing symbol translation. >> >>> >>> As I wrote before, this is pretty hard to get right for a JVM, but >>> there are good approximations. Have you looked at the 'jstack' tool >>> which is part of the JDK? If you run it on a Java process, it will >>> give you exact stack traces with full inlining information. However >>> this only works at safepoints so it is probably not suitable for >>> profiling with performance counters. >> >> Right, jstack works, and I get full correct stacks. I do really want >> to take stacks at any moment: not just CPU samples, but when tracing >> kernel TCP events, or PMC cache miss profiling, etc. perf can already >> do many advanced tracing and profiling activities. I just needed the >> Java stacks for context. >> >>> But you can also use 'jstack -F >>> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >>> of the time even with inlined Java frames. This is probably the best >>> you can get when interrupting a running JVM at an arbitrary point in >>> time. As you mentioned in one of your blogs, the VM can be in the >>> C-Library or even in the kernel at that time which don't preserve the >>> frame pointer either. So it will be already hard to even walk up to >>> the first Java frame. >> >> Well, the JVMs I'm looking at are already built with >> -fno-omit-frame-pointer (which is good). I edited hotspot to preserve >> it as well. >> >> Here's before I changed hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg >> >> Yes, most stacks are clearly broken. >> >> After changing hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> It's looking pretty good. If you look carefully on the far left and >> right, there are 0.8% stacks in read() and write() directly from java, >> which may well be broken (unless a java thread is calling these >> directly; there could also be some gcc inlining going on). Even if >> they are broken, I can see 98% of my profile. Plus, I'd be interested >> to know what exactly is reusing the frame pointer, so we could fix >> that too. >> >> The Java stacks themselves are also about a third as deep as they >> should be, due to inlining. >> >>> >>> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >>> your purpose, you can implement something similar in 'perf' or a >>> helper library of 'perf' and be happy (I don't actually know how perf >>> takes stack traces but I suppose there may some kind of callback >>> mechanism for walking unknown frames). This is actually not so hard. >>> I've recently implemented a "print_native_stack()" function within >>> hotspot itself (you can call it for example from gdb during debugging >>> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >>> Maye you could call this functions directly from 'perf' if perf >>> attaches with ptrace to the process (I assume it does or how else >>> could it walk the stack)? >> >> An OS-cooperative stack walker would be great, and I think the hotspot >> team is already doing this for Oracle Solaris. Thanks for the code >> too, this is pretty interesting. >> >> jstack -F -m eats 0.5s of CPU for me, so it would need work to make >> this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary >> kernel functions or tracepoints and get Java context from them, too. >> Eg, TCP functions, memory allocation, disk I/O, etc. >> >>> >>> These were just some random thoughts with the hope that they may be helpful. >> >> Yes, thanks! >> >> Brendan >> > From jaroslav.bachorik at oracle.com Mon Dec 8 18:09:58 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 08 Dec 2014 19:09:58 +0100 Subject: RFR 8059949: com/sun/tools/attach/StartManagementAgent.java interrupted! (timed out?) Message-ID: <5485E976.5000304@oracle.com> Please, review this small test adjustment Issue : https://bugs.openjdk.java.net/browse/JDK-8059949 Webrev: http://cr.openjdk.java.net/~jbachorik/8059949/webrev.01 The test is failing very intermittently when run on fastdebug builds. In the diagnostic output there is no indication of any unexpected errors - the test just times out while trying to start the local JMX agent. This change is an attempt to give the test more time to finish by increasing the timeout. Thanks, -JB- From staffan.larsen at oracle.com Mon Dec 8 19:17:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 8 Dec 2014 20:17:42 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5485BE52.9000500@us.ibm.com> References: <5485BE52.9000500@us.ibm.com> Message-ID: <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> > On 8 dec 2014, at 16:05, Maynard Johnson wrote: > > On 12/05/2014 05:09 PM, Brendan Gregg wrote: >> G'Day Volker, >> >> On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis >> wrote: >>> Hi Brendan, >>> >>> I'm still not understanding who is taking the actual stack traces (let >>> alone the symbols) in your examples. Is this done by 'perf' itself >>> based only on the frame pointer? >> >> perf is walking the frame pointers. > Volker, to be specific, the perf profiling tool has a user space part and a > kernel space part. The collection of stack traces is done by the kernel. > When a user-specified event (or series of events) occur, the process > being profiled is interrupted and the sampled information (which can > optionally include a full stack trace) is made available to the user space > perf tool to be saved to a file for future post-profiling processing. > > During the profiling phase, the perf tool collects information about the > profiled process's memory mappings, which allows for this address-to-symbol. > resolution, It's in the post-profiling phase where the sampled instruction, > along with its associated stack trace, are resolved to the appropriate symbol > (i.e., function/method) in a specific binary file (e.g., library, exectuable). > > And if the VM creates a /tmp/perf-.map file to save information about > JITed methods, the perf's post-profiling tool will find it and use it to > correlate sampled addresses it collected from the VM's executable anonymous > memory mappings to the method names. Is there a way in this .map file to express that different JITed methods are located at the same address at different times? This typically happens a lot when classes and their JITed methods are being unloaded from the VM. That space will be reused by a different method. I?m guessing this would confuse perf. /Staffan > > -Maynard >> >> A JVMTI agent, perf-map-agent, is providing a map file for symbol >> translation under /tmp/perf-PID.map. Linux perf already hunts for such >> a file when doing symbol translation. >> >>> >>> As I wrote before, this is pretty hard to get right for a JVM, but >>> there are good approximations. Have you looked at the 'jstack' tool >>> which is part of the JDK? If you run it on a Java process, it will >>> give you exact stack traces with full inlining information. However >>> this only works at safepoints so it is probably not suitable for >>> profiling with performance counters. >> >> Right, jstack works, and I get full correct stacks. I do really want >> to take stacks at any moment: not just CPU samples, but when tracing >> kernel TCP events, or PMC cache miss profiling, etc. perf can already >> do many advanced tracing and profiling activities. I just needed the >> Java stacks for context. >> >>> But you can also use 'jstack -F >>> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >>> of the time even with inlined Java frames. This is probably the best >>> you can get when interrupting a running JVM at an arbitrary point in >>> time. As you mentioned in one of your blogs, the VM can be in the >>> C-Library or even in the kernel at that time which don't preserve the >>> frame pointer either. So it will be already hard to even walk up to >>> the first Java frame. >> >> Well, the JVMs I'm looking at are already built with >> -fno-omit-frame-pointer (which is good). I edited hotspot to preserve >> it as well. >> >> Here's before I changed hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg >> >> Yes, most stacks are clearly broken. >> >> After changing hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> It's looking pretty good. If you look carefully on the far left and >> right, there are 0.8% stacks in read() and write() directly from java, >> which may well be broken (unless a java thread is calling these >> directly; there could also be some gcc inlining going on). Even if >> they are broken, I can see 98% of my profile. Plus, I'd be interested >> to know what exactly is reusing the frame pointer, so we could fix >> that too. >> >> The Java stacks themselves are also about a third as deep as they >> should be, due to inlining. >> >>> >>> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >>> your purpose, you can implement something similar in 'perf' or a >>> helper library of 'perf' and be happy (I don't actually know how perf >>> takes stack traces but I suppose there may some kind of callback >>> mechanism for walking unknown frames). This is actually not so hard. >>> I've recently implemented a "print_native_stack()" function within >>> hotspot itself (you can call it for example from gdb during debugging >>> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >>> Maye you could call this functions directly from 'perf' if perf >>> attaches with ptrace to the process (I assume it does or how else >>> could it walk the stack)? >> >> An OS-cooperative stack walker would be great, and I think the hotspot >> team is already doing this for Oracle Solaris. Thanks for the code >> too, this is pretty interesting. >> >> jstack -F -m eats 0.5s of CPU for me, so it would need work to make >> this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary >> kernel functions or tracepoints and get Java context from them, too. >> Eg, TCP functions, memory allocation, disk I/O, etc. >> >>> >>> These were just some random thoughts with the hope that they may be helpful. >> >> Yes, thanks! >> >> Brendan >> > From staffan.larsen at oracle.com Mon Dec 8 19:18:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 8 Dec 2014 20:18:09 +0100 Subject: RFR 8059949: com/sun/tools/attach/StartManagementAgent.java interrupted! (timed out?) In-Reply-To: <5485E976.5000304@oracle.com> References: <5485E976.5000304@oracle.com> Message-ID: <7E5FA9FA-6EB3-463F-BFD6-2906E56F9E15@oracle.com> Looks good! Thanks, /Staffan > On 8 dec 2014, at 19:09, Jaroslav Bachorik wrote: > > Please, review this small test adjustment > > Issue : https://bugs.openjdk.java.net/browse/JDK-8059949 > Webrev: http://cr.openjdk.java.net/~jbachorik/8059949/webrev.01 > > The test is failing very intermittently when run on fastdebug builds. In the diagnostic output there is no indication of any unexpected errors - the test just times out while trying to start the local JMX agent. This change is an attempt to give the test more time to finish by increasing the timeout. > > Thanks, > > -JB- From brendan.d.gregg at gmail.com Mon Dec 8 20:31:47 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Mon, 8 Dec 2014 12:31:47 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> References: <5485BE52.9000500@us.ibm.com> <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> Message-ID: G'Day Staffan, On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen wrote: > >> On 8 dec 2014, at 16:05, Maynard Johnson wrote: >> [...] >> >> And if the VM creates a /tmp/perf-.map file to save information about >> JITed methods, the perf's post-profiling tool will find it and use it to >> correlate sampled addresses it collected from the VM's executable anonymous >> memory mappings to the method names. > > Is there a way in this .map file to express that different JITed methods are located at the same address at different times? This typically happens a lot when classes and their JITed methods are being unloaded from the VM. That space will be reused by a different method. I?m guessing this would confuse perf. In the .map file, no, at least not currently. However, consider the following perf sampled stack trace (this is from my patched OpenJDK 8, with frame pointers): # perf record -F 99 -a -g -- sleep 10 # perf script [...] java 10532 [008] 3444046.716431: cpu-clock: 7fe919301c30 (/tmp/perf-10490.map) 7fe91934d50c (/tmp/perf-10490.map) 7fe9193a43d0 (/tmp/perf-10490.map) 7fe9194ffcf0 (/tmp/perf-10490.map) 7fe9195026d0 (/tmp/perf-10490.map) 7fe9194ffc4c (/tmp/perf-10490.map) 7fe91b6c440c (/tmp/perf-10490.map) 7fe91afa9c00 (/tmp/perf-10490.map) 7fe91ab739f4 (/tmp/perf-10490.map) 7fe91df23630 (/tmp/perf-10490.map) 7fe91ab739f4 (/tmp/perf-10490.map) 7fe91acc7ea8 (/tmp/perf-10490.map) 7fe91c4fa014 (/tmp/perf-10490.map) 7fe9190072e0 (/tmp/perf-10490.map) 7fe9190072e0 (/tmp/perf-10490.map) 7fe919007325 (/tmp/perf-10490.map) 7fe9190004e7 (/tmp/perf-10490.map) 7fe92f70670e JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/am 7fe92f707a3f JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-r 7fe92f707edf JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/l 7fe92f741668 thread_entry(JavaThread*, Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) 7fe92fa555c8 JavaThread::thread_main_inner() (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) 7fe92fa5581c JavaThread::run() (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) 7fe92f916ba2 java_start(Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) 7fe92ff95e9a start_thread (/lib/x86_64-linux-gnu/libpthread-2.15.so) perf script emits every sampled stack trace, which I normally do for flame graph generation. If I had Johannes's perf-map-agent loaded, then those hex addresses become Java method symbols. Note the timestamp on the cpu-clock line. So... It should be easy to change perf-map-agent to write a timestamped map file, to a different location (so perf doesn't find it). Use the same timestamp type as perf. Then, a little Perl wrapper can take "perf script" output and translate the addresses based on the timestamped map file. (perf itself can be enhanced to do this, although the time frame for a perf change propagating to Linux users may be years, so the Perl wrapper could be used in the meantime.) I haven't needed to do this yet. map file churn in production has been small (depends on workload). The real pain for us is switching apps from Oracle JDK to my patched OpenJDK, so we get the frame pointer. Brendan From jaroslav.bachorik at oracle.com Mon Dec 8 20:35:01 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 08 Dec 2014 21:35:01 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 Message-ID: <54860B75.5070008@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 The test fails very intermittently when RMI registry is trying to bind to a port previously used in the test (via ServerSocket). This seems to be caused by the sockets created via `new ServerSocket(0)` and being in reusable mode. The fix attempts to prevent this by explicitly forbidding the reusable mode. Thanks, -JB- From brendan.d.gregg at gmail.com Mon Dec 8 22:19:58 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Mon, 8 Dec 2014 14:19:58 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5485DCB7.4010901@oracle.com> References: <5485BE52.9000500@us.ibm.com> <5485DCB7.4010901@oracle.com> Message-ID: G'Day Mikael, On Mon, Dec 8, 2014 at 9:15 AM, Mikael Gerdin wrote: > Maynard, > > > On 2014-12-08 16:05, Maynard Johnson wrote: >> [...] >> >> And if the VM creates a /tmp/perf-.map file to save information about >> JITed methods, the perf's post-profiling tool will find it and use it to >> correlate sampled addresses it collected from the VM's executable >> anonymous >> memory mappings to the method names. > > > I seem to recall reading about perf having support for DWARF debug info. > > If the VM (or a JVM/TI agent) could create DWARF debug symbols, could that > be used to convey information about inlined functions and stack unwinding > without frame pointers? > I realize that emitting DWARF debug symbols for generated code is not a > trivial undertaking but since perf is running sampling in the kernel and we > can't disable inlining that seems to be one of the few ways we can get > complete stack traces. It's a good idea, but I'm not sure the DWARF unwind approach is suitable for dynamic JIT. I'm usually sampling at 99 Hertz. With inlined symbols, just the perf.map file can become 10s of Mbytes, and I assume the DWARF info would be similar. So the file would need to be in a consistent state so that perf can begin reading it anytime, and do stack walking based on what it reads, while at the same time symbols may be compiled anytime and the map file would need to change. With the frame pointer approach, perf always knows how to walk the stack, at any time. If symbols move during the profile, it breaks translation but not walking. And there's different ways to deal with the translation issue (collect before and after maps and note differences, or do timestamped maps). I assume the reliable option is having kernel support for Java unwinding (like the Solaris approach mentioned previously). Frame pointer support can be an option for situations when the kernel support isn't available, while noting its caveats. > > There would be several other advantages to having DWARF symbols for > generated code, GDB can use them when debugging the JVM for example. > > An alternate approach could be to extend the information in perf-.map > to have more detailed PC ranges with information about which functions are > inlined. A lot of that information is available in the VM but not > necessarily exposed via the tool APIs Johannes has done some of this with the perf-map-agent "unfold" option (https://github.com/jrudolph/perf-map-agent), which includes inlined information. I've tried adding an extra filter step to resuscitate frames that were inlined, which sort-of worked (needs more work). However, having inlined stacks hasn't been that much of a problem. I've shown my flame graphs to developers, noting that inlined frames can't be seen, and so far they can still follow what's going on (the use case here is performance profiling, to figure out where the bulk of CPU time is spent). jstack(1) output can be used for clues, to see how the inlined code maps to the full stacks. And, there's JVM tunables that can be used to reduce inlining. Brendan From stuart.marks at oracle.com Tue Dec 9 00:39:03 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 08 Dec 2014 16:39:03 -0800 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54860B75.5070008@oracle.com> References: <54860B75.5070008@oracle.com> Message-ID: <548644A7.9040103@oracle.com> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 > Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 > > The test fails very intermittently when RMI registry is trying to bind to a port > previously used in the test (via ServerSocket). > > This seems to be caused by the sockets created via `new ServerSocket(0)` and > being in reusable mode. The fix attempts to prevent this by explicitly > forbidding the reusable mode. Hi Jaroslav, I happened to see this fly by, and there are (I think) some similar issues going on in the RMI tests. But first I'll note that I don't think setReuseAddress() will have the effect that you want. Typically it's set to true before binding a socket, so that a subsequent bind operation will succeed even if the address/port is already in use. ServerSockets created with new ServerSocket(0) are already bound, and I'm not sure what calling setReuseAddress(false) will do on such sockets. The spec says behavior is undefined, but my bet is that it does nothing. I guess it doesn't hurt to try this out to see if it makes a difference, but I don't have much confidence it will help. The potential similarity to the RMI tests is exemplified by JDK-8049202 (sorry, this bug report isn't open) but briefly this tests the RMI registry as follows: 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default RMI registry port] in order to ensure that 1099 isn't in use by something else already; 2. If this succeeds, it immediately closes the ServerSocket. 3. Then it creates a new RMI registry on port 1099. In principle, this should succeed, yet it fails around 10% of the time on some systems. The error is "port already in use". My best theory is that even though the socket has just been closed by a user program, the kernel has to run the socket through some of the socket states such as FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually closed and is available for reuse. If a program -- even the same one -- attempts to open a socket on the same port before the socket has reached its final state, it will get an "already in use error". If this is true I don't believe that setting SO_REUSEADDR will work if the socket is in one of these final states. (I remember reading this somewhere but I'm not sure where at the moment. I can try to dig it up if there is interest.) I admit this is just a theory and I'm open to alternatives, and I'm also open to hearing about ways to deal with this problem. Could something similar be going on with this JMX test? s'marks From aph at redhat.com Tue Dec 9 09:39:53 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 09 Dec 2014 09:39:53 +0000 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5485BE52.9000500@us.ibm.com> <5485DCB7.4010901@oracle.com> Message-ID: <5486C369.1050807@redhat.com> On 08/12/14 22:19, Brendan Gregg wrote: > It's a good idea, but I'm not sure the DWARF unwind approach is > suitable for dynamic JIT. I'm usually sampling at 99 Hertz. With > inlined symbols, just the perf.map file can become 10s of Mbytes, and > I assume the DWARF info would be similar. So the file would need to be > in a consistent state so that perf can begin reading it anytime, and > do stack walking based on what it reads, while at the same time > symbols may be compiled anytime and the map file would need to change. Valgrind has a nice solution to this: a high-speed DWARF unwinder cache which converts the unwind info into an internal form. Andrew. From erik.helin at oracle.com Tue Dec 9 09:51:20 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 09 Dec 2014 10:51:20 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5485BE52.9000500@us.ibm.com> <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> Message-ID: <5486C618.6000105@oracle.com> On 2014-12-08 21:31, Brendan Gregg wrote: > G'Day Staffan, > > On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen > wrote: >> >>> On 8 dec 2014, at 16:05, Maynard Johnson wrote: >>> > [...] >>> >>> And if the VM creates a /tmp/perf-.map file to save information about >>> JITed methods, the perf's post-profiling tool will find it and use it to >>> correlate sampled addresses it collected from the VM's executable anonymous >>> memory mappings to the method names. >> >> Is there a way in this .map file to express that different JITed methods are located at the same address at different times? This typically happens a lot when classes and their JITed methods are being unloaded from the VM. That space will be reused by a different method. I?m guessing this would confuse perf. > > In the .map file, no, at least not currently. > > However, consider the following perf sampled stack trace (this is from > my patched OpenJDK 8, with frame pointers): > > # perf record -F 99 -a -g -- sleep 10 > # perf script > [...] > java 10532 [008] 3444046.716431: cpu-clock: > 7fe919301c30 (/tmp/perf-10490.map) > 7fe91934d50c (/tmp/perf-10490.map) > 7fe9193a43d0 (/tmp/perf-10490.map) > 7fe9194ffcf0 (/tmp/perf-10490.map) > 7fe9195026d0 (/tmp/perf-10490.map) > 7fe9194ffc4c (/tmp/perf-10490.map) > 7fe91b6c440c (/tmp/perf-10490.map) > 7fe91afa9c00 (/tmp/perf-10490.map) > 7fe91ab739f4 (/tmp/perf-10490.map) > 7fe91df23630 (/tmp/perf-10490.map) > 7fe91ab739f4 (/tmp/perf-10490.map) > 7fe91acc7ea8 (/tmp/perf-10490.map) > 7fe91c4fa014 (/tmp/perf-10490.map) > 7fe9190072e0 (/tmp/perf-10490.map) > 7fe9190072e0 (/tmp/perf-10490.map) > 7fe919007325 (/tmp/perf-10490.map) > 7fe9190004e7 (/tmp/perf-10490.map) > 7fe92f70670e JavaCalls::call_helper(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/am > 7fe92f707a3f JavaCalls::call_virtual(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-r > 7fe92f707edf JavaCalls::call_virtual(JavaValue*, Handle, > KlassHandle, Symbol*, Symbol*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/l > 7fe92f741668 thread_entry(JavaThread*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92fa555c8 JavaThread::thread_main_inner() > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92fa5581c JavaThread::run() > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92f916ba2 java_start(Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92ff95e9a start_thread (/lib/x86_64-linux-gnu/libpthread-2.15.so) > > perf script emits every sampled stack trace, which I normally do for > flame graph generation. If I had Johannes's perf-map-agent loaded, > then those hex addresses become Java method symbols. > > Note the timestamp on the cpu-clock line. > > So... It should be easy to change perf-map-agent to write a > timestamped map file, to a different location (so perf doesn't find > it). Use the same timestamp type as perf. Then, a little Perl wrapper > can take "perf script" output and translate the addresses based on the > timestamped map file. (perf itself can be enhanced to do this, > although the time frame for a perf change propagating to Linux users > may be years, so the Perl wrapper could be used in the meantime.) > > I haven't needed to do this yet. map file churn in production has been > small (depends on workload). The real pain for us is switching apps > from Oracle JDK to my patched OpenJDK, so we get the frame pointer. Another approach is outlined in the paper "Fast Java profiling with scheduling-aware stack fragment sampling and asynchronous analysis" [0]: use the perf system call to get 16kB of stack, then translate that asynchronously using JVMTI and then finally save the "decoded" stack trace to disk. This technique has the advantage of reusing all the knowledge already in the JVM about the stack and frame layout while still use perf for sampling. The drawback of this approach is that you would not be using the perf tool to set the probes, since the perf kernel utility is now started with the perf system call from a JVMTI agent. You would also have to translate an eventual native part and the kernel part of the stack trace yourself (probably by using some DWARF library). Thanks, Erik [0]: http://dl.acm.org/citation.cfm?doid=2647508.2647509 > Brendan > From erik.helin at oracle.com Tue Dec 9 09:53:00 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 09 Dec 2014 10:53:00 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: <5486C67C.2030302@oracle.com> I applied the patch on top of jdk9/hs-comp and created a webrev: http://cr.openjdk.java.net/~ehelin/brendan/frame-pointer/webrev/ I also successfully run the patch through JPRT. Thanks, Erik On 2014-12-05 20:57, Brendan Gregg wrote: > > > On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg > wrote: > > G'Day, > > I've hacked hotspot to return the frame pointer, in part to see what > this involves, and also to have a working prototype for analysis. > Along with an agent to resolve symbols, this has allowed full stack > profiling using Linux perf_events. The following flame graphs show > the resulting profiles. > > A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg > > Same thing, but this time disabling inlining, to show more frames: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg > > As expected, performance is worse without inlining. You can compare > the flame graphs side by side to see why. Less time spent doing work > / I/O! > > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > is my patch, > > [...] > > > In case there's problems with the patch URL, the patch is: > > --- openjdk8clean/hotspot/src/cpu/x86/vm/x86_64.ad > 2014-03-04 02:52:11.000000000 +0000 > +++ openjdk8/hotspot/src/cpu/x86/vm/x86_64.ad > 2014-11-08 01:10:49.686044933 +0000 > @@ -166,10 +166,9 @@ > // 3) reg_class stack_slots( /* one chunk of stack-based "registers" */ ) > // > > -// Class for all pointer registers (including RSP) > +// Class for all pointer registers (including RSP, excluding RBP) > reg_class any_reg(RAX, RAX_H, > RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -184,10 +183,9 @@ > R14, R14_H, > R15, R15_H); > > -// Class for all pointer registers except RSP > +// Class for all pointer registers except RSP and RBP > reg_class ptr_reg(RAX, RAX_H, > RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -199,9 +197,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all pointer registers except RAX and RSP > +// Class for all pointer registers except RAX, RSP and RBP > reg_class ptr_no_rax_reg(RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -226,9 +223,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all pointer registers except RAX, RBX and RSP > +// Class for all pointer registers except RAX, RBX, RSP and RBP > reg_class ptr_no_rax_rbx_reg(RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -260,10 +256,9 @@ > // Singleton class for TLS pointer > reg_class ptr_r15_reg(R15, R15_H); > > -// Class for all long registers (except RSP) > +// Class for all long registers (except RSP and RBP) > reg_class long_reg(RAX, RAX_H, > RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -275,9 +270,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all long registers except RAX, RDX (and RSP) > -reg_class long_no_rax_rdx_reg(RBP, RBP_H, > - RDI, RDI_H, > +// Class for all long registers except RAX, RDX (and RSP, RBP) > +reg_class long_no_rax_rdx_reg(RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > RBX, RBX_H, > @@ -288,9 +282,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all long registers except RCX (and RSP) > -reg_class long_no_rcx_reg(RBP, RBP_H, > - RDI, RDI_H, > +// Class for all long registers except RCX (and RSP, RBP) > +reg_class long_no_rcx_reg(RDI, RDI_H, > RSI, RSI_H, > RAX, RAX_H, > RDX, RDX_H, > @@ -302,9 +295,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all long registers except RAX (and RSP) > -reg_class long_no_rax_reg(RBP, RBP_H, > - RDX, RDX_H, > +// Class for all long registers except RAX (and RSP, RBP) > +reg_class long_no_rax_reg(RDX, RDX_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -325,10 +317,9 @@ > // Singleton class for RDX long register > reg_class long_rdx_reg(RDX, RDX_H); > > -// Class for all int registers (except RSP) > +// Class for all int registers (except RSP and RBP) > reg_class int_reg(RAX, > RDX, > - RBP, > RDI, > RSI, > RCX, > @@ -340,10 +331,9 @@ > R13, > R14); > > -// Class for all int registers except RCX (and RSP) > +// Class for all int registers except RCX (and RSP, RBP) > reg_class int_no_rcx_reg(RAX, > RDX, > - RBP, > RDI, > RSI, > RBX, > @@ -355,8 +345,7 @@ > R14); > > // Class for all int registers except RAX, RDX (and RSP) > -reg_class int_no_rax_rdx_reg(RBP, > - RDI, > +reg_class int_no_rax_rdx_reg(RDI, > RSI, > RCX, > RBX, > @@ -718,6 +707,7 @@ > st->print("# stack bang"); > st->print("\n\t"); > st->print("pushq rbp\t# Save rbp"); > + // BDG consider: st->print("movq rbp, rsp\t# "); > if (framesize) { > st->print("\n\t"); > st->print("subq rsp, #%d\t# Create frame",framesize); > --- openjdk8clean/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp > 2014-03-04 02:52:11.000000000 +0000 > +++ openjdk8/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-11-07 > 23:57:11.589593723 +0000 > @@ -5236,6 +5236,7 @@ > // We always push rbp, so that on return to interpreter rbp, will be > // restored correctly and we can correct the stack. > push(rbp); > + mov(rbp, rsp); > // Remove word for ebp > framesize -= wordSize; > > --- openjdk8clean/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp > 2014-03-04 02:52:10.000000000 +0000 > +++ openjdk8/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp > 2014-11-07 23:57:21.933257882 +0000 > @@ -358,6 +358,7 @@ > generate_stack_overflow_check(frame_size_in_bytes); > > push(rbp); > + mov(rbp, rsp); > #ifdef TIERED > // c2 leaves fpu stack dirty. Clean it on entry > if (UseSSE < 2 ) { > > > Brendan From staffan.larsen at oracle.com Tue Dec 9 10:09:46 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 9 Dec 2014 11:09:46 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5485BE52.9000500@us.ibm.com> <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> Message-ID: > On 8 dec 2014, at 21:31, Brendan Gregg wrote: > > G'Day Staffan, > > On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen > wrote: >> >>> On 8 dec 2014, at 16:05, Maynard Johnson wrote: >>> > [...] >>> >>> And if the VM creates a /tmp/perf-.map file to save information about >>> JITed methods, the perf's post-profiling tool will find it and use it to >>> correlate sampled addresses it collected from the VM's executable anonymous >>> memory mappings to the method names. >> >> Is there a way in this .map file to express that different JITed methods are located at the same address at different times? This typically happens a lot when classes and their JITed methods are being unloaded from the VM. That space will be reused by a different method. I?m guessing this would confuse perf. > > In the .map file, no, at least not currently. > > However, consider the following perf sampled stack trace (this is from > my patched OpenJDK 8, with frame pointers): > > # perf record -F 99 -a -g -- sleep 10 > # perf script > [...] > java 10532 [008] 3444046.716431: cpu-clock: > 7fe919301c30 (/tmp/perf-10490.map) > 7fe91934d50c (/tmp/perf-10490.map) > 7fe9193a43d0 (/tmp/perf-10490.map) > 7fe9194ffcf0 (/tmp/perf-10490.map) > 7fe9195026d0 (/tmp/perf-10490.map) > 7fe9194ffc4c (/tmp/perf-10490.map) > 7fe91b6c440c (/tmp/perf-10490.map) > 7fe91afa9c00 (/tmp/perf-10490.map) > 7fe91ab739f4 (/tmp/perf-10490.map) > 7fe91df23630 (/tmp/perf-10490.map) > 7fe91ab739f4 (/tmp/perf-10490.map) > 7fe91acc7ea8 (/tmp/perf-10490.map) > 7fe91c4fa014 (/tmp/perf-10490.map) > 7fe9190072e0 (/tmp/perf-10490.map) > 7fe9190072e0 (/tmp/perf-10490.map) > 7fe919007325 (/tmp/perf-10490.map) > 7fe9190004e7 (/tmp/perf-10490.map) > 7fe92f70670e JavaCalls::call_helper(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/am > 7fe92f707a3f JavaCalls::call_virtual(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-r > 7fe92f707edf JavaCalls::call_virtual(JavaValue*, Handle, > KlassHandle, Symbol*, Symbol*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/l > 7fe92f741668 thread_entry(JavaThread*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92fa555c8 JavaThread::thread_main_inner() > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92fa5581c JavaThread::run() > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92f916ba2 java_start(Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92ff95e9a start_thread (/lib/x86_64-linux-gnu/libpthread-2.15.so) > > perf script emits every sampled stack trace, which I normally do for > flame graph generation. If I had Johannes's perf-map-agent loaded, > then those hex addresses become Java method symbols. > > Note the timestamp on the cpu-clock line. > > So... It should be easy to change perf-map-agent to write a > timestamped map file, to a different location (so perf doesn't find > it). Use the same timestamp type as perf. Then, a little Perl wrapper > can take "perf script" output and translate the addresses based on the > timestamped map file. (perf itself can be enhanced to do this, > although the time frame for a perf change propagating to Linux users > may be years, so the Perl wrapper could be used in the meantime.) I see. Thanks for explaining! /Staffan > > I haven't needed to do this yet. map file churn in production has been > small (depends on workload). The real pain for us is switching apps > from Oracle JDK to my patched OpenJDK, so we get the frame pointer. > > Brendan From erik.helin at oracle.com Tue Dec 9 10:14:54 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 09 Dec 2014 11:14:54 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5486C67C.2030302@oracle.com> References: <5486C67C.2030302@oracle.com> Message-ID: <5486CB9E.2090505@oracle.com> I should also add that I don't have enough knowledge of the compiler internals to review this patch, sorry. Thanks, Erik On 2014-12-09 10:53, Erik Helin wrote: > I applied the patch on top of jdk9/hs-comp and created a webrev: > http://cr.openjdk.java.net/~ehelin/brendan/frame-pointer/webrev/ > > I also successfully run the patch through JPRT. > > Thanks, > Erik > > On 2014-12-05 20:57, Brendan Gregg wrote: >> >> >> On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg > > wrote: >> >> G'Day, >> >> I've hacked hotspot to return the frame pointer, in part to see what >> this involves, and also to have a working prototype for analysis. >> Along with an agent to resolve symbols, this has allowed full stack >> profiling using Linux perf_events. The following flame graphs show >> the resulting profiles. >> >> A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> Same thing, but this time disabling inlining, to show more frames: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg >> >> As expected, performance is worse without inlining. You can compare >> the flame graphs side by side to see why. Less time spent doing work >> / I/O! >> >> >> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >> >> is my patch, >> >> [...] >> >> >> In case there's problems with the patch URL, the patch is: >> >> --- openjdk8clean/hotspot/src/cpu/x86/vm/x86_64.ad >> 2014-03-04 02:52:11.000000000 +0000 >> +++ openjdk8/hotspot/src/cpu/x86/vm/x86_64.ad >> 2014-11-08 01:10:49.686044933 +0000 >> @@ -166,10 +166,9 @@ >> // 3) reg_class stack_slots( /* one chunk of stack-based "registers" >> */ ) >> // >> >> -// Class for all pointer registers (including RSP) >> +// Class for all pointer registers (including RSP, excluding RBP) >> reg_class any_reg(RAX, RAX_H, >> RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -184,10 +183,9 @@ >> R14, R14_H, >> R15, R15_H); >> >> -// Class for all pointer registers except RSP >> +// Class for all pointer registers except RSP and RBP >> reg_class ptr_reg(RAX, RAX_H, >> RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -199,9 +197,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all pointer registers except RAX and RSP >> +// Class for all pointer registers except RAX, RSP and RBP >> reg_class ptr_no_rax_reg(RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -226,9 +223,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all pointer registers except RAX, RBX and RSP >> +// Class for all pointer registers except RAX, RBX, RSP and RBP >> reg_class ptr_no_rax_rbx_reg(RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -260,10 +256,9 @@ >> // Singleton class for TLS pointer >> reg_class ptr_r15_reg(R15, R15_H); >> >> -// Class for all long registers (except RSP) >> +// Class for all long registers (except RSP and RBP) >> reg_class long_reg(RAX, RAX_H, >> RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -275,9 +270,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all long registers except RAX, RDX (and RSP) >> -reg_class long_no_rax_rdx_reg(RBP, RBP_H, >> - RDI, RDI_H, >> +// Class for all long registers except RAX, RDX (and RSP, RBP) >> +reg_class long_no_rax_rdx_reg(RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> RBX, RBX_H, >> @@ -288,9 +282,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all long registers except RCX (and RSP) >> -reg_class long_no_rcx_reg(RBP, RBP_H, >> - RDI, RDI_H, >> +// Class for all long registers except RCX (and RSP, RBP) >> +reg_class long_no_rcx_reg(RDI, RDI_H, >> RSI, RSI_H, >> RAX, RAX_H, >> RDX, RDX_H, >> @@ -302,9 +295,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all long registers except RAX (and RSP) >> -reg_class long_no_rax_reg(RBP, RBP_H, >> - RDX, RDX_H, >> +// Class for all long registers except RAX (and RSP, RBP) >> +reg_class long_no_rax_reg(RDX, RDX_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -325,10 +317,9 @@ >> // Singleton class for RDX long register >> reg_class long_rdx_reg(RDX, RDX_H); >> >> -// Class for all int registers (except RSP) >> +// Class for all int registers (except RSP and RBP) >> reg_class int_reg(RAX, >> RDX, >> - RBP, >> RDI, >> RSI, >> RCX, >> @@ -340,10 +331,9 @@ >> R13, >> R14); >> >> -// Class for all int registers except RCX (and RSP) >> +// Class for all int registers except RCX (and RSP, RBP) >> reg_class int_no_rcx_reg(RAX, >> RDX, >> - RBP, >> RDI, >> RSI, >> RBX, >> @@ -355,8 +345,7 @@ >> R14); >> >> // Class for all int registers except RAX, RDX (and RSP) >> -reg_class int_no_rax_rdx_reg(RBP, >> - RDI, >> +reg_class int_no_rax_rdx_reg(RDI, >> RSI, >> RCX, >> RBX, >> @@ -718,6 +707,7 @@ >> st->print("# stack bang"); >> st->print("\n\t"); >> st->print("pushq rbp\t# Save rbp"); >> + // BDG consider: st->print("movq rbp, rsp\t# "); >> if (framesize) { >> st->print("\n\t"); >> st->print("subq rsp, #%d\t# Create frame",framesize); >> --- openjdk8clean/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp >> 2014-03-04 02:52:11.000000000 +0000 >> +++ openjdk8/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-11-07 >> 23:57:11.589593723 +0000 >> @@ -5236,6 +5236,7 @@ >> // We always push rbp, so that on return to interpreter rbp, >> will be >> // restored correctly and we can correct the stack. >> push(rbp); >> + mov(rbp, rsp); >> // Remove word for ebp >> framesize -= wordSize; >> >> --- openjdk8clean/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp >> 2014-03-04 02:52:10.000000000 +0000 >> +++ openjdk8/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp >> 2014-11-07 23:57:21.933257882 +0000 >> @@ -358,6 +358,7 @@ >> generate_stack_overflow_check(frame_size_in_bytes); >> >> push(rbp); >> + mov(rbp, rsp); >> #ifdef TIERED >> // c2 leaves fpu stack dirty. Clean it on entry >> if (UseSSE < 2 ) { >> >> >> Brendan From jaroslav.bachorik at oracle.com Tue Dec 9 12:25:11 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 09 Dec 2014 13:25:11 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <548644A7.9040103@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> Message-ID: <5486EA27.800@oracle.com> On 12/09/2014 01:39 AM, Stuart Marks wrote: > On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >> >> The test fails very intermittently when RMI registry is trying to bind >> to a port >> previously used in the test (via ServerSocket). >> >> This seems to be caused by the sockets created via `new >> ServerSocket(0)` and >> being in reusable mode. The fix attempts to prevent this by explicitly >> forbidding the reusable mode. > > Hi Jaroslav, > > I happened to see this fly by, and there are (I think) some similar > issues going on in the RMI tests. > > But first I'll note that I don't think setReuseAddress() will have the > effect that you want. Typically it's set to true before binding a > socket, so that a subsequent bind operation will succeed even if the > address/port is already in use. ServerSockets created with new > ServerSocket(0) are already bound, and I'm not sure what calling > setReuseAddress(false) will do on such sockets. The spec says behavior > is undefined, but my bet is that it does nothing. > > I guess it doesn't hurt to try this out to see if it makes a difference, > but I don't have much confidence it will help. > > The potential similarity to the RMI tests is exemplified by JDK-8049202 > (sorry, this bug report isn't open) but briefly this tests the RMI > registry as follows: > > 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default > RMI registry port] in order to ensure that 1099 isn't in use by > something else already; > > 2. If this succeeds, it immediately closes the ServerSocket. > > 3. Then it creates a new RMI registry on port 1099. > > In principle, this should succeed, yet it fails around 10% of the time > on some systems. The error is "port already in use". My best theory is > that even though the socket has just been closed by a user program, the > kernel has to run the socket through some of the socket states such as > FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually closed > and is available for reuse. If a program -- even the same one -- > attempts to open a socket on the same port before the socket has reached > its final state, it will get an "already in use error". > > If this is true I don't believe that setting SO_REUSEADDR will work if > the socket is in one of these final states. (I remember reading this > somewhere but I'm not sure where at the moment. I can try to dig it up > if there is interest.) > > I admit this is just a theory and I'm open to alternatives, and I'm also > open to hearing about ways to deal with this problem. > > Could something similar be going on with this JMX test? Hm, this is exactly what happened with this test :( The problem is that the port is reported as available while it is still occupied and RMI registry attempts to start using that port. If setting SO_REUSEADDR does not work then the only solution would be to retry the test case when this exception occurs. -JB- > > s'marks From dmitry.samersoff at oracle.com Tue Dec 9 13:51:35 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Dec 2014 16:51:35 +0300 Subject: RFR(S) 8028773: SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <54858557.8030907@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> <54846185.3050508@oracle.com> <54858557.8030907@oracle.com> Message-ID: <5486FE67.9070500@oracle.com> Serguei, Fixed. Webrev updated in-place, please press shift-reload. http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.03/ -Dmitry On 2014-12-08 14:02, serguei.spitsyn at oracle.com wrote: > Looks good. > > Some minor comments. > > Better to reformat with one variable at a line: > > 113 const char *error_message = NULL, *jrepath = NULL, *libname = NULL; > > 283 jbyte *start, *end; > > > Uninitialized locals: > > 115 #ifdef _WINDOWS > 116 HINSTANCE hsdis_handle; > 117 #else > 118 void* hsdis_handle; > 119 #endif > ... > 201 jlong result; > ... > > 282 jboolean isCopy; > 283 jbyte *start, *end; > 284 jclass disclass; > 285 const char *options; > > > Unaligned parameters: > > 209 result = (*env)->CallLongMethod(env, denv->dis, denv->handle_event, denv->visitor, > 210 event_string, (jlong) (uintptr_t)arg); > > > Thanks, > Serguei > > > On 12/7/14 6:17 AM, Dmitry Samersoff wrote: >> Please, review a modified fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.03/ >> >> Windows compiler doesn't allow declaration in the middle of the function >> for c code. >> >> Also I put my few cents to reduce build noise and add a pragma that >> disable windows compiler warnings that have no value in this context. >> >> -Dmitry >> >> >> On 2014-12-03 16:01, Staffan Larsen wrote: >>> Changes look good. What testing have you done? >>> >>> /Staffan >>> >>>> On 3 dec 2014, at 13:06, Dmitry Samersoff wrote: >>>> >>>> Serguei, >>>> >>>> Updated webrev >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ >>>> >>>> -Dmitry >>>> >>>> On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >>>>> Dmitry, >>>>> >>>>> It is good in general modulo Staffan's comments. >>>>> >>>>> There are some inconsistencies: >>>>> - the ExceptionOccurred(env) is compared to != NULL (which make the >>>>> logic more complex) >>>>> in some places and no such comparison (implicit comparison instead) >>>>> in others >>>>> - two different forms of check/action are used: >>>>> - (*env)->ExceptionOccurred(env) and >>>>> - !(*env)->ExceptionOccurred(env) >>>>> >>>>> I'd suggest to do it the same way and always return the "default" value >>>>> if an exception occurred. >>>>> It will make the logic more flat and clear. >>>>> Otherwise, we have to think what exact value is returned in exception >>>>> occurred cases like at lines 241, 255. >>>>> >>>>> The comment // OOM is used inconsistently too. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>>>>> Please review the small fix. >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>>>>> >>>>>> Added more missed exception checks to sadis.c >>>>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Tue Dec 9 14:10:02 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 09 Dec 2014 06:10:02 -0800 Subject: RFR(S) 8028773: SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <5486FE67.9070500@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> <54846185.3050508@oracle.com> <54858557.8030907@oracle.com> <5486FE67.9070500@oracle.com> Message-ID: <548702BA.4080303@oracle.com> Dmitry, It looks good. Than you for the update! Serguei On 12/9/14 5:51 AM, Dmitry Samersoff wrote: > Serguei, > > Fixed. Webrev updated in-place, please press shift-reload. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.03/ > > -Dmitry > > On 2014-12-08 14:02, serguei.spitsyn at oracle.com wrote: >> Looks good. >> >> Some minor comments. >> >> Better to reformat with one variable at a line: >> >> 113 const char *error_message = NULL, *jrepath = NULL, *libname = NULL; >> >> 283 jbyte *start, *end; >> >> >> Uninitialized locals: >> >> 115 #ifdef _WINDOWS >> 116 HINSTANCE hsdis_handle; >> 117 #else >> 118 void* hsdis_handle; >> 119 #endif >> ... >> 201 jlong result; >> ... >> >> 282 jboolean isCopy; >> 283 jbyte *start, *end; >> 284 jclass disclass; >> 285 const char *options; >> >> >> Unaligned parameters: >> >> 209 result = (*env)->CallLongMethod(env, denv->dis, denv->handle_event, denv->visitor, >> 210 event_string, (jlong) (uintptr_t)arg); >> >> >> Thanks, >> Serguei >> >> >> On 12/7/14 6:17 AM, Dmitry Samersoff wrote: >>> Please, review a modified fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.03/ >>> >>> Windows compiler doesn't allow declaration in the middle of the function >>> for c code. >>> >>> Also I put my few cents to reduce build noise and add a pragma that >>> disable windows compiler warnings that have no value in this context. >>> >>> -Dmitry >>> >>> >>> On 2014-12-03 16:01, Staffan Larsen wrote: >>>> Changes look good. What testing have you done? >>>> >>>> /Staffan >>>> >>>>> On 3 dec 2014, at 13:06, Dmitry Samersoff wrote: >>>>> >>>>> Serguei, >>>>> >>>>> Updated webrev >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >>>>>> Dmitry, >>>>>> >>>>>> It is good in general modulo Staffan's comments. >>>>>> >>>>>> There are some inconsistencies: >>>>>> - the ExceptionOccurred(env) is compared to != NULL (which make the >>>>>> logic more complex) >>>>>> in some places and no such comparison (implicit comparison instead) >>>>>> in others >>>>>> - two different forms of check/action are used: >>>>>> - (*env)->ExceptionOccurred(env) and >>>>>> - !(*env)->ExceptionOccurred(env) >>>>>> >>>>>> I'd suggest to do it the same way and always return the "default" value >>>>>> if an exception occurred. >>>>>> It will make the logic more flat and clear. >>>>>> Otherwise, we have to think what exact value is returned in exception >>>>>> occurred cases like at lines 241, 255. >>>>>> >>>>>> The comment // OOM is used inconsistently too. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>>>>>> Please review the small fix. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>>>>>> >>>>>>> Added more missed exception checks to sadis.c >>>>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * I would love to change the world, but they won't give me the sources. > From johannes.rudolph at googlemail.com Mon Dec 8 18:32:46 2014 From: johannes.rudolph at googlemail.com (Johannes Rudolph) Date: Mon, 8 Dec 2014 19:32:46 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5485BE52.9000500@us.ibm.com> <5485DCB7.4010901@oracle.com> Message-ID: Hi there, I'm the one who started the perf-map-agent project. Thanks, Brendan and all others for having this discussion here. On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis wrote: > That said, I still don't know how perf creates stack traces. Does it > attach to the process with ptrace or how else does it inspect the > stacks after a performance counter event? `perf` is part of the Linux kernel. It supports different kind of trace events like hardware performance counter in the CPU. IIUC it creates a counter that is incremented on certain events (like CPU cycles, cache misses, etc.) and if the counter overflows the currently running program is interrupted and the kernel's event processing is allowed to record the event. No debugger is needed as the event is generated directly in the context of the monitored process (IIUC, right?). You can instruct the perf infrastructure (and thus the kernel) to capture a stacktrace when the event triggers and the (very simple) capturing logic is then run inside the kernel. [2] I guess adapting the kernel stacktrace collection logic would be possible but probably hard with all the constraints kernel code has to run under. As I just found out (and as Mikael confirms), there's an alternative stacktrace collection mode enabled by the `-g dwarf` setting of `perf record` which instructs the kernel to capture the complete X bytes at the top of the stack [3] and actually walks the stack in user mode. It would be probably much easier to adapt this user-mode code to figure out stacktraces for JIT'd methods if we can recover their frame pointers. Would that work? Maybe it's enough to get the stackframe size of the nmethod, because if `rsp` never changes during a JIT'd method (i.e. if nmethods have a constant frame size) you may be able to walk the stack by calculating the frame from `rsp` and the frame size (it seems that's basically also how hotspot does it). How could you get at the frame size information? -- Johannes [1] https://github.com/jrudolph/perf-map-agent [2] https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/perf_event.c#L2051 [3] https://github.com/torvalds/linux/blob/master/tools/perf/util/evsel.c#L547 ----------------------------------------------- Johannes Rudolph http://virtual-void.net From volker.simonis at gmail.com Tue Dec 9 18:10:52 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Dec 2014 19:10:52 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: Hi, can somebody from the serviceability team please review this webrev? http://cr.openjdk.java.net/~simonis/webrevs/8049716 https://bugs.openjdk.java.net/browse/JDK-8049716 The shared changes are really all trivial. Thanks, Volker On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: > Hi Sasha, > > thanks for looking at this change. > I'll incorporate your suggestions into the final version. > I'm just waiting for one more review before preparing a new webrev. > > Regards, > Volker > > > On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>> You are correct, but there no need to have this code for LE at all. >> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >> along with the "#if defined(ppc64)". >>> >>> BTW, a bit on nitpicking in the same file: >>> + String endian = System.getProperty("sun.cpu.endian"); >>> + if (endian.equals("big")) >>> + return true; >>> + else >>> + return false; >>> can be rewirtten as >>> return "big".equals(System.getProperty("sun.cpu.endian")); >> Right. A silly piece of coding there. :-/ >> >> -Maynard >>> >>> >>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>> The changes for agent/src/os/linux/symtab.c >>>>> b/agent/src/os/linux/symtab.c in >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>> Linux/PPC64 little-endian: >>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>> brackets in it should >>>>> read >>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>> instead of just >>>>> #if defined(ppc64) >>>> Hi, Alexander, >>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>> the rest of that function, opd is checked for non-null before using it. The only >>>> place where I think there may be a problem is at line 455: >>>> >>>> -------------------------- >>>> #if defined(ppc64) >>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>> // with the above algorithm impossible (we would need the have both, the >>>> // .opd section from the library and the symbol table from the debuginfo >>>> // file which doesn't match with the current workflow.) >>>> if (false) { >>>> #else >>>> // Look for a separate debuginfo file. >>>> if (try_debuginfo) { >>>> #endif >>>> -------------------------- >>>> >>>> Here I think we should do as you suggest: >>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>> >>>> -Maynard >>>>> >>>>> Sorry for the late notice. >>>>> Sasha >>>>> >>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>> change: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>> >>>>>> I have already reviewed and tested the change and from my side >>>>>> everything looks fine. >>>>>> >>>>>> The change touches quite some shared code but all of these changes are >>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>> Java). >>>>>> >>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>> hotspot repository once the review is completed. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>> >>>> >>> >> From dmitry.samersoff at oracle.com Tue Dec 9 19:03:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Dec 2014 22:03:18 +0300 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: <54874776.2080303@oracle.com> Volker, I'll take a look at it. -Dmitry On 2014-12-09 21:10, Volker Simonis wrote: > Hi, > > can somebody from the serviceability team please review this webrev? > > http://cr.openjdk.java.net/~simonis/webrevs/8049716 > https://bugs.openjdk.java.net/browse/JDK-8049716 > > The shared changes are really all trivial. > > Thanks, > Volker > > > On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >> Hi Sasha, >> >> thanks for looking at this change. >> I'll incorporate your suggestions into the final version. >> I'm just waiting for one more review before preparing a new webrev. >> >> Regards, >> Volker >> >> >> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>> You are correct, but there no need to have this code for LE at all. >>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>> along with the "#if defined(ppc64)". >>>> >>>> BTW, a bit on nitpicking in the same file: >>>> + String endian = System.getProperty("sun.cpu.endian"); >>>> + if (endian.equals("big")) >>>> + return true; >>>> + else >>>> + return false; >>>> can be rewirtten as >>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>> Right. A silly piece of coding there. :-/ >>> >>> -Maynard >>>> >>>> >>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>> The changes for agent/src/os/linux/symtab.c >>>>>> b/agent/src/os/linux/symtab.c in >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>> Linux/PPC64 little-endian: >>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>> brackets in it should >>>>>> read >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> instead of just >>>>>> #if defined(ppc64) >>>>> Hi, Alexander, >>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>> place where I think there may be a problem is at line 455: >>>>> >>>>> -------------------------- >>>>> #if defined(ppc64) >>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>> // with the above algorithm impossible (we would need the have both, the >>>>> // .opd section from the library and the symbol table from the debuginfo >>>>> // file which doesn't match with the current workflow.) >>>>> if (false) { >>>>> #else >>>>> // Look for a separate debuginfo file. >>>>> if (try_debuginfo) { >>>>> #endif >>>>> -------------------------- >>>>> >>>>> Here I think we should do as you suggest: >>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>> >>>>> -Maynard >>>>>> >>>>>> Sorry for the late notice. >>>>>> Sasha >>>>>> >>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>> change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>> >>>>>>> I have already reviewed and tested the change and from my side >>>>>>> everything looks fine. >>>>>>> >>>>>>> The change touches quite some shared code but all of these changes are >>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>> Java). >>>>>>> >>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>> hotspot repository once the review is completed. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>> >>>>> >>>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue Dec 9 19:50:40 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Dec 2014 22:50:40 +0300 Subject: RFR(S): 8067030 JDWP crash in transport_startTransport on OOM Message-ID: <54875290.7090001@oracle.com> Hi Everybody, Please review small fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8067030/webrev.01/ JDWP crash if allocation fails because it calls strcpy before check of allocation results. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Tue Dec 9 22:30:00 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 09 Dec 2014 14:30:00 -0800 Subject: RFR(S): 8067030 JDWP crash in transport_startTransport on OOM In-Reply-To: <54875290.7090001@oracle.com> References: <54875290.7090001@oracle.com> Message-ID: <548777E8.8080209@oracle.com> Hi Dmitry, The fix looks good. However, there are a couple of more places in that file where the result of the jvmtiAllocate() is not checked: 68 utf8msg = (jbyte*)jvmtiAllocate(maxlen+1); 393 buf = jvmtiAllocate(len*3+3); Could you fix this as well? Thanks, Serguei On 12/9/14 11:50 AM, Dmitry Samersoff wrote: > Hi Everybody, > > Please review small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067030/webrev.01/ > > JDWP crash if allocation fails because it calls strcpy before > check of allocation results. > > -Dmitry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Wed Dec 10 10:40:27 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 10 Dec 2014 11:40:27 +0100 Subject: [PING] RFR 8034263: Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails intermittently In-Reply-To: <54802C68.6010908@oracle.com> References: <54802C68.6010908@oracle.com> Message-ID: <5488231B.3020500@oracle.com> A kindly reminder ... On 12/04/2014 10:42 AM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8034263 > Webrev: http://cr.openjdk.java.net/~jbachorik/8034263/webrev.00 > > The test fails intermittently only for CMS collector - > > "One thing about CMS is that it does concurrent work. So just a theory > would be that a concurrent cycle is started and sometime finishes (which > might trigger a notification) and sometimes does not finish before the > test has completed. " (from discussion with Bengt Rutisson) > > The 'fix' is to relax the condition for when CMS is used and check that > at least the expected number of notifications was triggered. > > Thanks, > > -JB- From staffan.larsen at oracle.com Wed Dec 10 10:52:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 10 Dec 2014 11:52:09 +0100 Subject: [PING] RFR 8034263: Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails intermittently In-Reply-To: <5488231B.3020500@oracle.com> References: <54802C68.6010908@oracle.com> <5488231B.3020500@oracle.com> Message-ID: <4BB118A9-6438-476B-BD8E-611BACB3518F@oracle.com> Looks good. Perhaps use RuntimeMXBean.getInputArguments() instead of the dcmd? /Staffan > On 10 dec 2014, at 11:40, Jaroslav Bachorik wrote: > > A kindly reminder ... > > On 12/04/2014 10:42 AM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8034263 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8034263/webrev.00 >> >> The test fails intermittently only for CMS collector - >> >> "One thing about CMS is that it does concurrent work. So just a theory >> would be that a concurrent cycle is started and sometime finishes (which >> might trigger a notification) and sometimes does not finish before the >> test has completed. " (from discussion with Bengt Rutisson) >> >> The 'fix' is to relax the condition for when CMS is used and check that >> at least the expected number of notifications was triggered. >> >> Thanks, >> >> -JB- > From filipp.zhinkin at oracle.com Wed Dec 10 13:48:23 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 10 Dec 2014 17:48:23 +0400 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms Message-ID: <54884F27.2020206@oracle.com> Hi all, please review a fix for 8066862. Issue: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with RuntimeException: All Platform's methods with signature '():Z' should be tested Root cause: In order to prevent issues caused by the fact that some mutually exclusive predicates may return "true" on on the same platform (for example if isARM and isPPC will return true simultaneously) I decided to check in test if all Platform's methods with '():Z' signature were tested. Fix for 8039995 added new methods with "():Z" signature, but these methods were not marked in TestMutuallyExclusivePlatformPredicates as methods that should be ignored. Proposed fix: Mark newly added methods as ignored in TestMutuallyExclusivePlatformPredicates.java, add this test to sanity test group in order to run it in JPRT Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ Testing: manual & automated From igor.ignatyev at oracle.com Wed Dec 10 14:26:00 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 10 Dec 2014 17:26:00 +0300 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <54884F27.2020206@oracle.com> References: <54884F27.2020206@oracle.com> Message-ID: <548857F8.70107@oracle.com> Hi Filipp, looks good to me. thanks for fixing this. Igor On 12/10/2014 04:48 PM, Filipp Zhinkin wrote: > Hi all, > > please review a fix for 8066862. > > Issue: > testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with > RuntimeException: All Platform's methods with signature '():Z' should be > tested > > Root cause: > In order to prevent issues caused by the fact that some mutually exclusive > predicates may return "true" on on the same platform (for example if > isARM and > isPPC will return true simultaneously) I decided to check in test if all > Platform's methods with '():Z' signature were tested. > > Fix for 8039995 added new methods with "():Z" signature, but these > methods were > not marked in TestMutuallyExclusivePlatformPredicates as methods that > should be ignored. > > Proposed fix: > Mark newly added methods as ignored in > TestMutuallyExclusivePlatformPredicates.java, > add this test to sanity test group in order to run it in JPRT > > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ > Testing: manual & automated From filipp.zhinkin at oracle.com Wed Dec 10 14:20:40 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 10 Dec 2014 18:20:40 +0400 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <548857F8.70107@oracle.com> References: <54884F27.2020206@oracle.com> <548857F8.70107@oracle.com> Message-ID: <548856B8.8020107@oracle.com> Hi Igor, thank you for review! Regards, Filipp. On 12/10/2014 06:26 PM, Igor Ignatyev wrote: > Hi Filipp, > > looks good to me. > thanks for fixing this. > > Igor > > On 12/10/2014 04:48 PM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a fix for 8066862. >> >> Issue: >> testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with >> RuntimeException: All Platform's methods with signature '():Z' should be >> tested >> >> Root cause: >> In order to prevent issues caused by the fact that some mutually exclusive >> predicates may return "true" on on the same platform (for example if >> isARM and >> isPPC will return true simultaneously) I decided to check in test if all >> Platform's methods with '():Z' signature were tested. >> >> Fix for 8039995 added new methods with "():Z" signature, but these >> methods were >> not marked in TestMutuallyExclusivePlatformPredicates as methods that >> should be ignored. >> >> Proposed fix: >> Mark newly added methods as ignored in >> TestMutuallyExclusivePlatformPredicates.java, >> add this test to sanity test group in order to run it in JPRT >> >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ >> Testing: manual & automated From jaroslav.bachorik at oracle.com Wed Dec 10 15:20:14 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 10 Dec 2014 16:20:14 +0100 Subject: [PING] RFR 8034263: Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails intermittently In-Reply-To: <4BB118A9-6438-476B-BD8E-611BACB3518F@oracle.com> References: <54802C68.6010908@oracle.com> <5488231B.3020500@oracle.com> <4BB118A9-6438-476B-BD8E-611BACB3518F@oracle.com> Message-ID: <548864AE.6020802@oracle.com> On 12/10/2014 11:52 AM, Staffan Larsen wrote: > Looks good. Perhaps use RuntimeMXBean.getInputArguments() instead of the dcmd? Sounds good. I will change the test to use RuntimeMXBean.getInputArguments() then. Thanks! -JB- > > /Staffan > >> On 10 dec 2014, at 11:40, Jaroslav Bachorik wrote: >> >> A kindly reminder ... >> >> On 12/04/2014 10:42 AM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8034263 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8034263/webrev.00 >>> >>> The test fails intermittently only for CMS collector - >>> >>> "One thing about CMS is that it does concurrent work. So just a theory >>> would be that a concurrent cycle is started and sometime finishes (which >>> might trigger a notification) and sometimes does not finish before the >>> test has completed. " (from discussion with Bengt Rutisson) >>> >>> The 'fix' is to relax the condition for when CMS is used and check that >>> at least the expected number of notifications was triggered. >>> >>> Thanks, >>> >>> -JB- >> > From ivan.gerasimov at oracle.com Thu Dec 11 06:52:09 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 11 Dec 2014 09:52:09 +0300 Subject: RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects Message-ID: <54893F19.6060108@oracle.com> Hello! After the fix for JDK-8064694 some more failures of WaitForMultipleObjects() were observed under heavy load. The reason was that the limitation on wait object number was overlooked. The total number of the objects should not be greater than MAXIMUM_WAIT_OBJECTS (= 64). The proposed fix is to get rid of constant MAX_EXIT_HANDLES and use MAXIMUM_WAIT_OBJECTS instead for all kinds of builds. I also added the last error code to the failure reports, so it would be easier to identify the cause of a failure. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8066863 WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ Sincerely yours, Ivan From dmitry.samersoff at oracle.com Thu Dec 11 08:48:31 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Dec 2014 11:48:31 +0300 Subject: RFR(S): 8067030 JDWP crash in transport_startTransport on OOM In-Reply-To: <548777E8.8080209@oracle.com> References: <54875290.7090001@oracle.com> <548777E8.8080209@oracle.com> Message-ID: <54895A5F.4080700@oracle.com> Serguei, Fixed two more missed error checks (in-place, press shift-reload) http://cr.openjdk.java.net/~dsamersoff/JDK-8067030/webrev.01/ -Dmitry On 2014-12-10 01:30, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > The fix looks good. > > However, there are a couple of more places in that file > where the result of the jvmtiAllocate() is not checked: > > 68 utf8msg = (jbyte*)jvmtiAllocate(maxlen+1); > > 393 buf = jvmtiAllocate(len*3+3); > > > Could you fix this as well? > > > Thanks, > Serguei > > > On 12/9/14 11:50 AM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8067030/webrev.01/ >> >> JDWP crash if allocation fails because it calls strcpy before >> check of allocation results. >> >> -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 Dec 11 08:54:40 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 11 Dec 2014 00:54:40 -0800 Subject: RFR(S): 8067030 JDWP crash in transport_startTransport on OOM In-Reply-To: <54895A5F.4080700@oracle.com> References: <54875290.7090001@oracle.com> <548777E8.8080209@oracle.com> <54895A5F.4080700@oracle.com> Message-ID: <54895BD0.1000506@oracle.com> Dmitry, It looks good. Reviewed. Thank you for fixing two more cases! Thanks, Serguei On 12/11/14 12:48 AM, Dmitry Samersoff wrote: > Serguei, > > Fixed two more missed error checks (in-place, press shift-reload) > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067030/webrev.01/ > > -Dmitry > > On 2014-12-10 01:30, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> The fix looks good. >> >> However, there are a couple of more places in that file >> where the result of the jvmtiAllocate() is not checked: >> >> 68 utf8msg = (jbyte*)jvmtiAllocate(maxlen+1); >> >> 393 buf = jvmtiAllocate(len*3+3); >> >> >> Could you fix this as well? >> >> >> Thanks, >> Serguei >> >> >> On 12/9/14 11:50 AM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067030/webrev.01/ >>> >>> JDWP crash if allocation fails because it calls strcpy before >>> check of allocation results. >>> >>> -Dmitry >>> > From jaroslav.bachorik at oracle.com Thu Dec 11 09:07:05 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 11 Dec 2014 10:07:05 +0100 Subject: RFR(S): 8067030 JDWP crash in transport_startTransport on OOM In-Reply-To: <54895A5F.4080700@oracle.com> References: <54875290.7090001@oracle.com> <548777E8.8080209@oracle.com> <54895A5F.4080700@oracle.com> Message-ID: <54895EB9.2080804@oracle.com> Hi, Looks good! -JB- On 12/11/2014 09:48 AM, Dmitry Samersoff wrote: > Serguei, > > Fixed two more missed error checks (in-place, press shift-reload) > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067030/webrev.01/ > > -Dmitry > > On 2014-12-10 01:30, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> The fix looks good. >> >> However, there are a couple of more places in that file >> where the result of the jvmtiAllocate() is not checked: >> >> 68 utf8msg = (jbyte*)jvmtiAllocate(maxlen+1); >> >> 393 buf = jvmtiAllocate(len*3+3); >> >> >> Could you fix this as well? >> >> >> Thanks, >> Serguei >> >> >> On 12/9/14 11:50 AM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067030/webrev.01/ >>> >>> JDWP crash if allocation fails because it calls strcpy before >>> check of allocation results. >>> >>> -Dmitry >>> >> > > From david.holmes at oracle.com Thu Dec 11 09:48:49 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Dec 2014 19:48:49 +1000 Subject: RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects In-Reply-To: <54893F19.6060108@oracle.com> References: <54893F19.6060108@oracle.com> Message-ID: <54896881.7050902@oracle.com> Hi Ivan, On 11/12/2014 4:52 PM, Ivan Gerasimov wrote: > Hello! > > After the fix for JDK-8064694 some more failures of > WaitForMultipleObjects() were observed under heavy load. > The reason was that the limitation on wait object number was overlooked. > The total number of the objects should not be greater than > MAXIMUM_WAIT_OBJECTS (= 64). > > The proposed fix is to get rid of constant MAX_EXIT_HANDLES and use > MAXIMUM_WAIT_OBJECTS instead for all kinds of builds. > I also added the last error code to the failure reports, so it would be > easier to identify the cause of a failure. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8066863 > WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ The webrev changes do not correspond to the description you gave above. David > Sincerely yours, > Ivan From david.holmes at oracle.com Thu Dec 11 10:01:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Dec 2014 20:01:09 +1000 Subject: RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects In-Reply-To: <54896881.7050902@oracle.com> References: <54893F19.6060108@oracle.com> <54896881.7050902@oracle.com> Message-ID: <54896B65.8020401@oracle.com> On 11/12/2014 7:48 PM, David Holmes wrote: > Hi Ivan, > > On 11/12/2014 4:52 PM, Ivan Gerasimov wrote: >> Hello! >> >> After the fix for JDK-8064694 some more failures of >> WaitForMultipleObjects() were observed under heavy load. >> The reason was that the limitation on wait object number was overlooked. >> The total number of the objects should not be greater than >> MAXIMUM_WAIT_OBJECTS (= 64). >> >> The proposed fix is to get rid of constant MAX_EXIT_HANDLES and use >> MAXIMUM_WAIT_OBJECTS instead for all kinds of builds. >> I also added the last error code to the failure reports, so it would be >> easier to identify the cause of a failure. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8066863 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ > > The webrev changes do not correspond to the description you gave above. Correct webrev URL: http://cr.openjdk.java.net/~igerasim/8066863/0/webrev/ Seems this saga will never end. :( Changes seem okay. Thanks, David > David > > >> Sincerely yours, >> Ivan From jaroslav.bachorik at oracle.com Thu Dec 11 14:06:44 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 11 Dec 2014 15:06:44 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5486EA27.800@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> Message-ID: <5489A4F4.5030600@oracle.com> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: > On 12/09/2014 01:39 AM, Stuart Marks wrote: >> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>> >>> The test fails very intermittently when RMI registry is trying to bind >>> to a port >>> previously used in the test (via ServerSocket). >>> >>> This seems to be caused by the sockets created via `new >>> ServerSocket(0)` and >>> being in reusable mode. The fix attempts to prevent this by explicitly >>> forbidding the reusable mode. >> >> Hi Jaroslav, >> >> I happened to see this fly by, and there are (I think) some similar >> issues going on in the RMI tests. >> >> But first I'll note that I don't think setReuseAddress() will have the >> effect that you want. Typically it's set to true before binding a >> socket, so that a subsequent bind operation will succeed even if the >> address/port is already in use. ServerSockets created with new >> ServerSocket(0) are already bound, and I'm not sure what calling >> setReuseAddress(false) will do on such sockets. The spec says behavior >> is undefined, but my bet is that it does nothing. >> >> I guess it doesn't hurt to try this out to see if it makes a difference, >> but I don't have much confidence it will help. >> >> The potential similarity to the RMI tests is exemplified by JDK-8049202 >> (sorry, this bug report isn't open) but briefly this tests the RMI >> registry as follows: >> >> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >> RMI registry port] in order to ensure that 1099 isn't in use by >> something else already; >> >> 2. If this succeeds, it immediately closes the ServerSocket. >> >> 3. Then it creates a new RMI registry on port 1099. >> >> In principle, this should succeed, yet it fails around 10% of the time >> on some systems. The error is "port already in use". My best theory is >> that even though the socket has just been closed by a user program, the >> kernel has to run the socket through some of the socket states such as >> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually closed >> and is available for reuse. If a program -- even the same one -- >> attempts to open a socket on the same port before the socket has reached >> its final state, it will get an "already in use error". >> >> If this is true I don't believe that setting SO_REUSEADDR will work if >> the socket is in one of these final states. (I remember reading this >> somewhere but I'm not sure where at the moment. I can try to dig it up >> if there is interest.) >> >> I admit this is just a theory and I'm open to alternatives, and I'm also >> open to hearing about ways to deal with this problem. >> >> Could something similar be going on with this JMX test? > > Hm, this is exactly what happened with this test :( > > The problem is that the port is reported as available while it is still > occupied and RMI registry attempts to start using that port. > > If setting SO_REUSEADDR does not work then the only solution would be to > retry the test case when this exception occurs. Further investigation shows that the problem was rather the client connecting to a socket being shut down. It sounds like setting SO_REUSEADDR to false should prevent this failure. From the ServerSocket javadoc: "When a TCP connection is closed the connection may remain in a timeout state for a period of time after the connection is closed (typically known as the TIME_WAIT state or 2MSL wait state). For applications using a well known socket address or port it may not be possible to bind a socket to the required SocketAddress if there is a connection in the timeout state involving the socket address or port." It also turns out that the test does not close the server sockets properly so there might be several sockets being opened or timed out dangling around. I've updated the test so it is setting SO_REUSEADDR for all the new ServerSockets instances + introduced the mechanism to run the test code while properly cleaning up any allocated ports. http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ -JB- > > -JB- > >> >> s'marks > From dmitry.samersoff at oracle.com Thu Dec 11 14:43:11 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Dec 2014 17:43:11 +0300 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5489A4F4.5030600@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> Message-ID: <5489AD7F.7090200@oracle.com> Jaroslav, You can set SO_LINGER to zero, in this case socket will be closed immediately without waiting in TIME_WAIT But there are no reliable way to predict whether you can take this port or not after you close it. So the only valid solution is to try to connect to a random port and if this attempt fails try another random port. Everything else will cause more or less frequent intermittent failures. -Dmitry On 2014-12-11 17:06, Jaroslav Bachorik wrote: > On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>> >>>> The test fails very intermittently when RMI registry is trying to bind >>>> to a port >>>> previously used in the test (via ServerSocket). >>>> >>>> This seems to be caused by the sockets created via `new >>>> ServerSocket(0)` and >>>> being in reusable mode. The fix attempts to prevent this by explicitly >>>> forbidding the reusable mode. >>> >>> Hi Jaroslav, >>> >>> I happened to see this fly by, and there are (I think) some similar >>> issues going on in the RMI tests. >>> >>> But first I'll note that I don't think setReuseAddress() will have the >>> effect that you want. Typically it's set to true before binding a >>> socket, so that a subsequent bind operation will succeed even if the >>> address/port is already in use. ServerSockets created with new >>> ServerSocket(0) are already bound, and I'm not sure what calling >>> setReuseAddress(false) will do on such sockets. The spec says behavior >>> is undefined, but my bet is that it does nothing. >>> >>> I guess it doesn't hurt to try this out to see if it makes a difference, >>> but I don't have much confidence it will help. >>> >>> The potential similarity to the RMI tests is exemplified by JDK-8049202 >>> (sorry, this bug report isn't open) but briefly this tests the RMI >>> registry as follows: >>> >>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>> RMI registry port] in order to ensure that 1099 isn't in use by >>> something else already; >>> >>> 2. If this succeeds, it immediately closes the ServerSocket. >>> >>> 3. Then it creates a new RMI registry on port 1099. >>> >>> In principle, this should succeed, yet it fails around 10% of the time >>> on some systems. The error is "port already in use". My best theory is >>> that even though the socket has just been closed by a user program, the >>> kernel has to run the socket through some of the socket states such as >>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually closed >>> and is available for reuse. If a program -- even the same one -- >>> attempts to open a socket on the same port before the socket has reached >>> its final state, it will get an "already in use error". >>> >>> If this is true I don't believe that setting SO_REUSEADDR will work if >>> the socket is in one of these final states. (I remember reading this >>> somewhere but I'm not sure where at the moment. I can try to dig it up >>> if there is interest.) >>> >>> I admit this is just a theory and I'm open to alternatives, and I'm also >>> open to hearing about ways to deal with this problem. >>> >>> Could something similar be going on with this JMX test? >> >> Hm, this is exactly what happened with this test :( >> >> The problem is that the port is reported as available while it is still >> occupied and RMI registry attempts to start using that port. >> >> If setting SO_REUSEADDR does not work then the only solution would be to >> retry the test case when this exception occurs. > > Further investigation shows that the problem was rather the client > connecting to a socket being shut down. > > It sounds like setting SO_REUSEADDR to false should prevent this failure. > > From the ServerSocket javadoc: > "When a TCP connection is closed the connection may remain in a timeout > state for a period of time after the connection is closed (typically > known as the TIME_WAIT state or 2MSL wait state). For applications using > a well known socket address or port it may not be possible to bind a > socket to the required SocketAddress if there is a connection in the > timeout state involving the socket address or port." > > It also turns out that the test does not close the server sockets > properly so there might be several sockets being opened or timed out > dangling around. > > I've updated the test so it is setting SO_REUSEADDR for all the new > ServerSockets instances + introduced the mechanism to run the test code > while properly cleaning up any allocated ports. > > http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ > > -JB- > >> >> -JB- >> >>> >>> s'marks >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From olivier.lagneau at oracle.com Thu Dec 11 15:01:51 2014 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Thu, 11 Dec 2014 16:01:51 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5489A4F4.5030600@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> Message-ID: <5489B1DF.2000302@oracle.com> Hi Jaroslav, On 11/12/2014 15:06, Jaroslav Bachorik wrote: > Further investigation shows that the problem was rather the client > connecting to a socket being shut down. I remember I met this situation for an RMI fix a while ago and IIRC no flag setting could help (SO_REUSEADDR as well), the port kept being unavailable. > > It sounds like setting SO_REUSEADDR to false should prevent this failure. > > From the ServerSocket javadoc: > "When a TCP connection is closed the connection may remain in a > timeout state for a period of time after the connection is closed > (typically known as the TIME_WAIT state or 2MSL wait state). For > applications using a well known socket address or port it may not be > possible to bind a socket to the required SocketAddress if there is a > connection in the timeout state involving the socket address or port." > > It also turns out that the test does not close the server sockets > properly so there might be several sockets being opened or timed out > dangling around. I think this is the main reason why we see these intermittent failures. > > I've updated the test so it is setting SO_REUSEADDR for all the new > ServerSockets instances + introduced the mechanism to run the test > code while properly cleaning up any allocated ports. Olivier. On 11/12/2014 15:06, Jaroslav Bachorik wrote: > On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>> >>>> The test fails very intermittently when RMI registry is trying to bind >>>> to a port >>>> previously used in the test (via ServerSocket). >>>> >>>> This seems to be caused by the sockets created via `new >>>> ServerSocket(0)` and >>>> being in reusable mode. The fix attempts to prevent this by explicitly >>>> forbidding the reusable mode. >>> >>> Hi Jaroslav, >>> >>> I happened to see this fly by, and there are (I think) some similar >>> issues going on in the RMI tests. >>> >>> But first I'll note that I don't think setReuseAddress() will have the >>> effect that you want. Typically it's set to true before binding a >>> socket, so that a subsequent bind operation will succeed even if the >>> address/port is already in use. ServerSockets created with new >>> ServerSocket(0) are already bound, and I'm not sure what calling >>> setReuseAddress(false) will do on such sockets. The spec says behavior >>> is undefined, but my bet is that it does nothing. >>> >>> I guess it doesn't hurt to try this out to see if it makes a >>> difference, >>> but I don't have much confidence it will help. >>> >>> The potential similarity to the RMI tests is exemplified by JDK-8049202 >>> (sorry, this bug report isn't open) but briefly this tests the RMI >>> registry as follows: >>> >>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>> RMI registry port] in order to ensure that 1099 isn't in use by >>> something else already; >>> >>> 2. If this succeeds, it immediately closes the ServerSocket. >>> >>> 3. Then it creates a new RMI registry on port 1099. >>> >>> In principle, this should succeed, yet it fails around 10% of the time >>> on some systems. The error is "port already in use". My best theory is >>> that even though the socket has just been closed by a user program, the >>> kernel has to run the socket through some of the socket states such as >>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually closed >>> and is available for reuse. If a program -- even the same one -- >>> attempts to open a socket on the same port before the socket has >>> reached >>> its final state, it will get an "already in use error". >>> >>> If this is true I don't believe that setting SO_REUSEADDR will work if >>> the socket is in one of these final states. (I remember reading this >>> somewhere but I'm not sure where at the moment. I can try to dig it up >>> if there is interest.) >>> >>> I admit this is just a theory and I'm open to alternatives, and I'm >>> also >>> open to hearing about ways to deal with this problem. >>> >>> Could something similar be going on with this JMX test? >> >> Hm, this is exactly what happened with this test :( >> >> The problem is that the port is reported as available while it is still >> occupied and RMI registry attempts to start using that port. >> >> If setting SO_REUSEADDR does not work then the only solution would be to >> retry the test case when this exception occurs. > > Further investigation shows that the problem was rather the client > connecting to a socket being shut down. > > It sounds like setting SO_REUSEADDR to false should prevent this failure. > > From the ServerSocket javadoc: > "When a TCP connection is closed the connection may remain in a > timeout state for a period of time after the connection is closed > (typically known as the TIME_WAIT state or 2MSL wait state). For > applications using a well known socket address or port it may not be > possible to bind a socket to the required SocketAddress if there is a > connection in the timeout state involving the socket address or port." > > It also turns out that the test does not close the server sockets > properly so there might be several sockets being opened or timed out > dangling around. > > I've updated the test so it is setting SO_REUSEADDR for all the new > ServerSockets instances + introduced the mechanism to run the test > code while properly cleaning up any allocated ports. > > http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ > > -JB- > >> >> -JB- >> >>> >>> s'marks >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.lagneau at oracle.com Thu Dec 11 15:09:41 2014 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Thu, 11 Dec 2014 16:09:41 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5489AD7F.7090200@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> Message-ID: <5489B3B5.1010801@oracle.com> Hi Dmitry, On 11/12/2014 15:43, Dmitry Samersoff wrote: > Jaroslav, > > You can set SO_LINGER to zero, in this case socket will be closed > immediately without waiting in TIME_WAIT SO-LINGER did not help either in my case (see my previous mail to Jaroslav). That ended-up in using another hard-coded (supposedly free) port. Note that was before RMI tests used randomly allocated ports. > But there are no reliable way to predict whether you can take this port > or not after you close it. This is what I observed in my case. > > So the only valid solution is to try to connect to a random port and if > this attempt fails try another random port. Everything else will cause > more or less frequent intermittent failures. IIRC think this is what is currently done in RMI tests. Olivier. > > On 2014-12-11 17:06, Jaroslav Bachorik wrote: >> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >>> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>>> >>>>> The test fails very intermittently when RMI registry is trying to bind >>>>> to a port >>>>> previously used in the test (via ServerSocket). >>>>> >>>>> This seems to be caused by the sockets created via `new >>>>> ServerSocket(0)` and >>>>> being in reusable mode. The fix attempts to prevent this by explicitly >>>>> forbidding the reusable mode. >>>> Hi Jaroslav, >>>> >>>> I happened to see this fly by, and there are (I think) some similar >>>> issues going on in the RMI tests. >>>> >>>> But first I'll note that I don't think setReuseAddress() will have the >>>> effect that you want. Typically it's set to true before binding a >>>> socket, so that a subsequent bind operation will succeed even if the >>>> address/port is already in use. ServerSockets created with new >>>> ServerSocket(0) are already bound, and I'm not sure what calling >>>> setReuseAddress(false) will do on such sockets. The spec says behavior >>>> is undefined, but my bet is that it does nothing. >>>> >>>> I guess it doesn't hurt to try this out to see if it makes a difference, >>>> but I don't have much confidence it will help. >>>> >>>> The potential similarity to the RMI tests is exemplified by JDK-8049202 >>>> (sorry, this bug report isn't open) but briefly this tests the RMI >>>> registry as follows: >>>> >>>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>>> RMI registry port] in order to ensure that 1099 isn't in use by >>>> something else already; >>>> >>>> 2. If this succeeds, it immediately closes the ServerSocket. >>>> >>>> 3. Then it creates a new RMI registry on port 1099. >>>> >>>> In principle, this should succeed, yet it fails around 10% of the time >>>> on some systems. The error is "port already in use". My best theory is >>>> that even though the socket has just been closed by a user program, the >>>> kernel has to run the socket through some of the socket states such as >>>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually closed >>>> and is available for reuse. If a program -- even the same one -- >>>> attempts to open a socket on the same port before the socket has reached >>>> its final state, it will get an "already in use error". >>>> >>>> If this is true I don't believe that setting SO_REUSEADDR will work if >>>> the socket is in one of these final states. (I remember reading this >>>> somewhere but I'm not sure where at the moment. I can try to dig it up >>>> if there is interest.) >>>> >>>> I admit this is just a theory and I'm open to alternatives, and I'm also >>>> open to hearing about ways to deal with this problem. >>>> >>>> Could something similar be going on with this JMX test? >>> Hm, this is exactly what happened with this test :( >>> >>> The problem is that the port is reported as available while it is still >>> occupied and RMI registry attempts to start using that port. >>> >>> If setting SO_REUSEADDR does not work then the only solution would be to >>> retry the test case when this exception occurs. >> Further investigation shows that the problem was rather the client >> connecting to a socket being shut down. >> >> It sounds like setting SO_REUSEADDR to false should prevent this failure. >> >> From the ServerSocket javadoc: >> "When a TCP connection is closed the connection may remain in a timeout >> state for a period of time after the connection is closed (typically >> known as the TIME_WAIT state or 2MSL wait state). For applications using >> a well known socket address or port it may not be possible to bind a >> socket to the required SocketAddress if there is a connection in the >> timeout state involving the socket address or port." >> >> It also turns out that the test does not close the server sockets >> properly so there might be several sockets being opened or timed out >> dangling around. >> >> I've updated the test so it is setting SO_REUSEADDR for all the new >> ServerSockets instances + introduced the mechanism to run the test code >> while properly cleaning up any allocated ports. >> >> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ >> >> -JB- >> >>> -JB- >>> >>>> s'marks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Dec 11 16:05:15 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Dec 2014 09:05:15 -0700 Subject: RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects In-Reply-To: <54896B65.8020401@oracle.com> References: <54893F19.6060108@oracle.com> <54896881.7050902@oracle.com> <54896B65.8020401@oracle.com> Message-ID: <5489C0BB.8080002@oracle.com> On 12/11/14 3:01 AM, David Holmes wrote: > On 11/12/2014 7:48 PM, David Holmes wrote: >> Hi Ivan, >> >> On 11/12/2014 4:52 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> After the fix for JDK-8064694 some more failures of >>> WaitForMultipleObjects() were observed under heavy load. >>> The reason was that the limitation on wait object number was >>> overlooked. >>> The total number of the objects should not be greater than >>> MAXIMUM_WAIT_OBJECTS (= 64). >>> >>> The proposed fix is to get rid of constant MAX_EXIT_HANDLES and use >>> MAXIMUM_WAIT_OBJECTS instead for all kinds of builds. >>> I also added the last error code to the failure reports, so it would be >>> easier to identify the cause of a failure. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8066863 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >> >> The webrev changes do not correspond to the description you gave above. > > Correct webrev URL: > > http://cr.openjdk.java.net/~igerasim/8066863/0/webrev/ src/os/windows/vm/os_windows.cpp Thanks for adding the GetLastError() info to the messages. Thumbs up. RT_Baseline has already pushed to Main_Baseline for this week so you should be good to go if you're happy with your pre-push testing. > Seems this saga will never end. :( Changes seem okay. On the plus side, we're seeing fewer and fewer exit_code stomping failures in nightly so things are getting better... Dan > > Thanks, > David > >> David >> >> >>> Sincerely yours, >>> Ivan From dmitry.samersoff at oracle.com Thu Dec 11 16:44:01 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Dec 2014 19:44:01 +0300 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: <5489C9D1.6030508@oracle.com> Volker, Below is fist part of review - shared files. * agent/make/Makefile - no comments * agent/src/os/linux/LinuxDebuggerLocal.c - no comments * agent/src/os/linux/symtab.c: 438: - What is the magic of symbols that starts with '.' ? - As far as I understand you are getting indirect value from opd section. Could you reformat it a bit to have it better readable? Something like: uintptr_t sym_value; ... symvalue = syms->st_value #ifdef ppc64 // Some comments here // ppc specific code here sym_value = #endif symtab->symbols[j].offset = sym_value - baseaddr; 454: I appreciate detailed comments here. if (false) can cause unreachable code warning, and unused variable warning so it might be better to add #ifdef ppc64 on caller site at ll. 516 and leave here only a comment. But if you decide to guard against try_debuginfo please replace if (false) to goto quit * agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java 38: return (endian.equals("big")); is enough * agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java - no comments * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments * make/linux/makefiles/sa.make - no comments * make/sa.files - no comments * src/share/vm/runtime/vmStructs.cpp - no comments -Dmitry On 2014-12-09 21:10, Volker Simonis wrote: > Hi, > > can somebody from the serviceability team please review this webrev? > > http://cr.openjdk.java.net/~simonis/webrevs/8049716 > https://bugs.openjdk.java.net/browse/JDK-8049716 > > The shared changes are really all trivial. > > Thanks, > Volker > > > On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >> Hi Sasha, >> >> thanks for looking at this change. >> I'll incorporate your suggestions into the final version. >> I'm just waiting for one more review before preparing a new webrev. >> >> Regards, >> Volker >> >> >> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>> You are correct, but there no need to have this code for LE at all. >>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>> along with the "#if defined(ppc64)". >>>> >>>> BTW, a bit on nitpicking in the same file: >>>> + String endian = System.getProperty("sun.cpu.endian"); >>>> + if (endian.equals("big")) >>>> + return true; >>>> + else >>>> + return false; >>>> can be rewirtten as >>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>> Right. A silly piece of coding there. :-/ >>> >>> -Maynard >>>> >>>> >>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>> The changes for agent/src/os/linux/symtab.c >>>>>> b/agent/src/os/linux/symtab.c in >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>> Linux/PPC64 little-endian: >>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>> brackets in it should >>>>>> read >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> instead of just >>>>>> #if defined(ppc64) >>>>> Hi, Alexander, >>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>> place where I think there may be a problem is at line 455: >>>>> >>>>> -------------------------- >>>>> #if defined(ppc64) >>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>> // with the above algorithm impossible (we would need the have both, the >>>>> // .opd section from the library and the symbol table from the debuginfo >>>>> // file which doesn't match with the current workflow.) >>>>> if (false) { >>>>> #else >>>>> // Look for a separate debuginfo file. >>>>> if (try_debuginfo) { >>>>> #endif >>>>> -------------------------- >>>>> >>>>> Here I think we should do as you suggest: >>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>> >>>>> -Maynard >>>>>> >>>>>> Sorry for the late notice. >>>>>> Sasha >>>>>> >>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>> change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>> >>>>>>> I have already reviewed and tested the change and from my side >>>>>>> everything looks fine. >>>>>>> >>>>>>> The change touches quite some shared code but all of these changes are >>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>> Java). >>>>>>> >>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>> hotspot repository once the review is completed. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>> >>>>> >>>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From ivan.gerasimov at oracle.com Thu Dec 11 16:55:45 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 11 Dec 2014 19:55:45 +0300 Subject: RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects In-Reply-To: <54896B65.8020401@oracle.com> References: <54893F19.6060108@oracle.com> <54896881.7050902@oracle.com> <54896B65.8020401@oracle.com> Message-ID: <5489CC91.3030406@oracle.com> On 11.12.2014 13:01, David Holmes wrote: > On 11/12/2014 7:48 PM, David Holmes wrote: >> Hi Ivan, >> >> On 11/12/2014 4:52 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> After the fix for JDK-8064694 some more failures of >>> WaitForMultipleObjects() were observed under heavy load. >>> The reason was that the limitation on wait object number was >>> overlooked. >>> The total number of the objects should not be greater than >>> MAXIMUM_WAIT_OBJECTS (= 64). >>> >>> The proposed fix is to get rid of constant MAX_EXIT_HANDLES and use >>> MAXIMUM_WAIT_OBJECTS instead for all kinds of builds. >>> I also added the last error code to the failure reports, so it would be >>> easier to identify the cause of a failure. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8066863 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >> >> The webrev changes do not correspond to the description you gave above. > > Correct webrev URL: > > http://cr.openjdk.java.net/~igerasim/8066863/0/webrev/ > Thank you David for correcting the link and the review! > Seems this saga will never end. :( Changes seem okay. > I still have a hope to have it finished one day. Sincerely yours, Ivan > Thanks, > David > >> David >> >> >>> Sincerely yours, >>> Ivan > > From ivan.gerasimov at oracle.com Thu Dec 11 16:58:03 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 11 Dec 2014 19:58:03 +0300 Subject: RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects In-Reply-To: <5489C0BB.8080002@oracle.com> References: <54893F19.6060108@oracle.com> <54896881.7050902@oracle.com> <54896B65.8020401@oracle.com> <5489C0BB.8080002@oracle.com> Message-ID: <5489CD1B.3000702@oracle.com> On 11.12.2014 19:05, Daniel D. Daugherty wrote: > On 12/11/14 3:01 AM, David Holmes wrote: >> On 11/12/2014 7:48 PM, David Holmes wrote: >>> Hi Ivan, >>> >>> On 11/12/2014 4:52 PM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> After the fix for JDK-8064694 some more failures of >>>> WaitForMultipleObjects() were observed under heavy load. >>>> The reason was that the limitation on wait object number was >>>> overlooked. >>>> The total number of the objects should not be greater than >>>> MAXIMUM_WAIT_OBJECTS (= 64). >>>> >>>> The proposed fix is to get rid of constant MAX_EXIT_HANDLES and use >>>> MAXIMUM_WAIT_OBJECTS instead for all kinds of builds. >>>> I also added the last error code to the failure reports, so it >>>> would be >>>> easier to identify the cause of a failure. >>>> >>>> Would you please help review the fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8066863 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>> >>> The webrev changes do not correspond to the description you gave above. >> >> Correct webrev URL: >> >> http://cr.openjdk.java.net/~igerasim/8066863/0/webrev/ > > src/os/windows/vm/os_windows.cpp > Thanks for adding the GetLastError() info to the messages. > > Thumbs up. > > RT_Baseline has already pushed to Main_Baseline for this week > so you should be good to go if you're happy with your pre-push > testing. > > Thank you Daniel for the review! I've run a JPRT job + hotspot test set, with so single failure. Sincerely yours, Ivan >> Seems this saga will never end. :( Changes seem okay. > > On the plus side, we're seeing fewer and fewer exit_code stomping > failures in nightly so things are getting better... > > Dan > > >> >> Thanks, >> David >> >>> David >>> >>> >>>> Sincerely yours, >>>> Ivan > > > From stuart.marks at oracle.com Thu Dec 11 17:53:30 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 11 Dec 2014 09:53:30 -0800 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5489B3B5.1010801@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5489B3B5.1010801@oracle.com> Message-ID: <5489DA1A.1080108@oracle.com> On 12/11/14 7:09 AM, olivier.lagneau at oracle.com wrote: > On 11/12/2014 15:43, Dmitry Samersoff wrote: >> You can set SO_LINGER to zero, in this case socket will be closed >> immediately without waiting in TIME_WAIT > SO-LINGER did not help either in my case (see my previous mail to Jaroslav). > That ended-up in using another hard-coded (supposedly free) port. > Note that was before RMI tests used randomly allocated ports. > >> But there are no reliable way to predict whether you can take this port >> or not after you close it. > This is what I observed in my case. >> >> So the only valid solution is to try to connect to a random port and if >> this attempt fails try another random port. Everything else will cause >> more or less frequent intermittent failures. > IIRC think this is what is currently done in RMI tests. The RMI tests are still suffering from this problem, unfortunately. The RMI test library gets a "random" port with "new ServerSocket(0)", gets the port number, closes the socket, then returns the port to the caller. The caller then assumes that it can use that port as it wishes. That's when the BindException can occur. There are about 10 RMI test bugs in the database that all seem to have this as their root cause. There is some retry logic in RMI's test library, but that's to avoid the so-called "reserved ports" that specific RMI tests use, or if "new ServerSocket(0)" fails. It doesn't have anything to do with the BindException that occurs when the caller attempts to reuse the port with another socket. My observation is also that setting SO_REUSEADDR has no effect. I haven't tried SO_LINGER. My hunch is that it won't have any effect, since the sockets in question aren't actually going into TIME_WAIT state. But I suppose it's worth a try. I don't have any solution for this; we're still discussing the issue. I think the best approach would be to refactor the code so that the eventual user of the socket opens it up on an ephemeral port in the first place. That avoids the open/close/reopen business. Unfortunately that doesn't help the case where you want to tell another JVM to run a service on a specific port. We don't have a solution for that case yet. The second-best approach (not really a solution) is to open/close a serversocket to get the port, sleep for a little bit, then return the port number to the caller. This might give the kernel a chance to clean up the socket after the close. Of course, this still has a race condition, but it might reduce the incidence of problems to an acceptable level. I'll let you know if we come up with anything better. s'marks From dmitry.samersoff at oracle.com Thu Dec 11 18:18:25 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Dec 2014 21:18:25 +0300 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5489DA1A.1080108@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5489B3B5.1010801@oracle.com> <5489DA1A.1080108@oracle.com> Message-ID: <5489DFF1.7010800@oracle.com> Stuart, As soon as you close socket, you open a door for the race. So you need another communication channel to pass a port number (or bind result) between a client and a server without closing a socket on the server side. Typical scenario used by network related code is: 1. Server opens the socket 2. Server binds to port(0) 3. Server gets port number assigned by OS 4. Server informs client (e.g. write the port down to known file, broadcast it etc) 5. Client establishes connection. If the server is a blackbox and have to get a port number from outside, scenario looks like: WHILE(!success and !timeout) 1. Driver chooses random port number 2. Driver runs a server with this number 3. Driver checks that server is actually listening on this port (e.g. try to connect by it self) WEND 4. Driver runs a client with this port number or bails out with descriptive error message. -Dmitry On 2014-12-11 20:53, Stuart Marks wrote: > > > On 12/11/14 7:09 AM, olivier.lagneau at oracle.com wrote: >> On 11/12/2014 15:43, Dmitry Samersoff wrote: >>> You can set SO_LINGER to zero, in this case socket will be closed >>> immediately without waiting in TIME_WAIT >> SO-LINGER did not help either in my case (see my previous mail to >> Jaroslav). >> That ended-up in using another hard-coded (supposedly free) port. >> Note that was before RMI tests used randomly allocated ports. >> >>> But there are no reliable way to predict whether you can take this port >>> or not after you close it. >> This is what I observed in my case. >>> >>> So the only valid solution is to try to connect to a random port and if >>> this attempt fails try another random port. Everything else will cause >>> more or less frequent intermittent failures. >> IIRC think this is what is currently done in RMI tests. > > The RMI tests are still suffering from this problem, unfortunately. > > The RMI test library gets a "random" port with "new ServerSocket(0)", > gets the port number, closes the socket, then returns the port to the > caller. The caller then assumes that it can use that port as it wishes. > That's when the BindException can occur. There are about 10 RMI test > bugs in the database that all seem to have this as their root cause. > > There is some retry logic in RMI's test library, but that's to avoid the > so-called "reserved ports" that specific RMI tests use, or if "new > ServerSocket(0)" fails. It doesn't have anything to do with the > BindException that occurs when the caller attempts to reuse the port > with another socket. > > My observation is also that setting SO_REUSEADDR has no effect. I > haven't tried SO_LINGER. My hunch is that it won't have any effect, > since the sockets in question aren't actually going into TIME_WAIT > state. But I suppose it's worth a try. > > I don't have any solution for this; we're still discussing the issue. I > think the best approach would be to refactor the code so that the > eventual user of the socket opens it up on an ephemeral port in the > first place. That avoids the open/close/reopen business. Unfortunately > that doesn't help the case where you want to tell another JVM to run a > service on a specific port. We don't have a solution for that case yet. > > The second-best approach (not really a solution) is to open/close a > serversocket to get the port, sleep for a little bit, then return the > port number to the caller. This might give the kernel a chance to clean > up the socket after the close. Of course, this still has a race > condition, but it might reduce the incidence of problems to an > acceptable level. > > I'll let you know if we come up with anything better. > > s'marks -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From shanliang.jiang at oracle.com Fri Dec 12 07:33:49 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 12 Dec 2014 08:33:49 +0100 Subject: RFR 8067241 DeadlockTest.java failed with negative timeout value Message-ID: <548A9A5D.6020000@oracle.com> Hi, It is a test bug, it is not correct: while(!wb.done || timeToWait > 0) { it should be: while(!wb.done && timeToWait > 0) { || should be changed to && Another issue is that the waiting time could be not enough (final long timeout = 2000). The fix is to remove the waiting time specified in the test, the timeout of test harness will be used as the max waiting time. bug: https://bugs.openjdk.java.net/browse/JDK-8067241 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ thanks, Shanliang From daniel.fuchs at oracle.com Fri Dec 12 08:34:23 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Dec 2014 09:34:23 +0100 Subject: RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548A9A5D.6020000@oracle.com> References: <548A9A5D.6020000@oracle.com> Message-ID: <548AA88F.3050401@oracle.com> Hi Shanliang, These two statements are no longer needed and should be removed - as they are misleading: 64 if (!bb.gotLock) { 65 throw new RuntimeException("Failed to get lock, impossible!"); 66 } 81 if (!wb.done) { 82 throw new RuntimeException("It is blocked!"); 83 } which makes me wonder whether your changes are deeper than intended. Now the test will either succeed, or fail in jtreg timeout. The condition "It is blocked!" can no longer be detected by the test. Is that your intention? If that's your intention - I guess it is OK - but maybe it would deserve a comment in the @summary of the test. Something like 'This bug attempts to reproduce a deadlock situation and will block forever if the deadlock is present.' best regards, -- daniel On 12/12/14 8:33 AM, shanliang wrote: > Hi, > > It is a test bug, it is not correct: > while(!wb.done || timeToWait > 0) { > > it should be: > while(!wb.done && timeToWait > 0) { > > || should be changed to && > > Another issue is that the waiting time could be not enough (final long > timeout = 2000). > > The fix is to remove the waiting time specified in the test, the > timeout of test harness will be used as the max waiting time. > > bug: https://bugs.openjdk.java.net/browse/JDK-8067241 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ > > thanks, > Shanliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanliang.jiang at oracle.com Fri Dec 12 08:56:35 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 12 Dec 2014 09:56:35 +0100 Subject: RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AA88F.3050401@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AA88F.3050401@oracle.com> Message-ID: <548AADC3.30301@oracle.com> Daniel Fuchs wrote: > Hi Shanliang, > > These two statements are no longer needed and should be removed - as they > are misleading: > > 64 if (!bb.gotLock) { > 65 throw new RuntimeException("Failed to get lock, impossible!"); > 66 } > > > 81 if (!wb.done) { > 82 throw new RuntimeException("It is blocked!"); > 83 } > Yes, can be removed. > > > which makes me wonder whether your changes are deeper than intended. > Now the test will either succeed, or fail in jtreg timeout. The condition > "It is blocked!" > can no longer be detected by the test. Is that your intention? If that's > your intention - I guess it is OK - but maybe it would deserve a comment > in the @summary of the test. Something like 'This bug attempts to > reproduce > a deadlock situation and will block forever if the deadlock is present.' Updated. Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/ Thanks, Shanliang > > best regards, > > -- daniel > > On 12/12/14 8:33 AM, shanliang wrote: >> Hi, >> >> It is a test bug, it is not correct: >> while(!wb.done || timeToWait > 0) { >> >> it should be: >> while(!wb.done && timeToWait > 0) { >> >> || should be changed to && >> >> Another issue is that the waiting time could be not enough (final >> long timeout = 2000). >> >> The fix is to remove the waiting time specified in the test, the >> timeout of test harness will be used as the max waiting time. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8067241 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ >> >> thanks, >> Shanliang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Dec 12 09:11:31 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Dec 2014 01:11:31 -0800 Subject: RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548A9A5D.6020000@oracle.com> References: <548A9A5D.6020000@oracle.com> Message-ID: <548AB143.8070808@oracle.com> Hi Shanliang, The fix is good. Just a side note... I do not see why the line 98 is needed as no other thread is going to sync on the DeadlockTest object (that is o) that is passed to the BadBoy constructor: 98 synchronized(o) { Thanks, Serguei On 12/11/14 11:33 PM, shanliang wrote: > Hi, > > It is a test bug, it is not correct: > while(!wb.done || timeToWait > 0) { > > it should be: > while(!wb.done && timeToWait > 0) { > > || should be changed to && > > Another issue is that the waiting time could be not enough (final long > timeout = 2000). > > The fix is to remove the waiting time specified in the test, the > timeout of test harness will be used as the max waiting time. > > bug: https://bugs.openjdk.java.net/browse/JDK-8067241 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ > > thanks, > Shanliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Dec 12 10:15:11 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Dec 2014 11:15:11 +0100 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AB143.8070808@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AB143.8070808@oracle.com> Message-ID: <548AC02F.7000307@oracle.com> On 12/12/14 10:11, serguei.spitsyn at oracle.com wrote: > Hi Shanliang, > > The fix is good. > > Just a side note... > I do not see why the line 98 is needed as no other thread is going to sync > on the DeadlockTest object (that is o) that is passed to the BadBoy > constructor: > > 98 synchronized(o) { Hi Sergey, I believe this is the purpose of the test. See https://bugs.openjdk.java.net/browse/JDK-6331746 best regards, -- daniel > > > Thanks, > Serguei > > > On 12/11/14 11:33 PM, shanliang wrote: >> Hi, >> >> It is a test bug, it is not correct: >> while(!wb.done || timeToWait > 0) { >> >> it should be: >> while(!wb.done && timeToWait > 0) { >> >> || should be changed to && >> >> Another issue is that the waiting time could be not enough (final long >> timeout = 2000). >> >> The fix is to remove the waiting time specified in the test, the >> timeout of test harness will be used as the max waiting time. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8067241 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ >> >> thanks, >> Shanliang > From serguei.spitsyn at oracle.com Fri Dec 12 10:30:26 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Dec 2014 02:30:26 -0800 Subject: jmx-dev RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AC02F.7000307@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AB143.8070808@oracle.com> <548AC02F.7000307@oracle.com> Message-ID: <548AC3C2.5000902@oracle.com> Thank you, Daniel! It is clear now. Thanks, Serguei On 12/12/14 2:15 AM, Daniel Fuchs wrote: > On 12/12/14 10:11, serguei.spitsyn at oracle.com wrote: >> Hi Shanliang, >> >> The fix is good. >> >> Just a side note... >> I do not see why the line 98 is needed as no other thread is going to >> sync >> on the DeadlockTest object (that is o) that is passed to the BadBoy >> constructor: >> >> 98 synchronized(o) { > > Hi Sergey, > > I believe this is the purpose of the test. > See https://bugs.openjdk.java.net/browse/JDK-6331746 > > best regards, > > -- daniel > >> >> >> Thanks, >> Serguei >> >> >> On 12/11/14 11:33 PM, shanliang wrote: >>> Hi, >>> >>> It is a test bug, it is not correct: >>> while(!wb.done || timeToWait > 0) { >>> >>> it should be: >>> while(!wb.done && timeToWait > 0) { >>> >>> || should be changed to && >>> >>> Another issue is that the waiting time could be not enough (final long >>> timeout = 2000). >>> >>> The fix is to remove the waiting time specified in the test, the >>> timeout of test harness will be used as the max waiting time. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8067241 >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/ >>> >>> thanks, >>> Shanliang >> > From staffan.larsen at oracle.com Fri Dec 12 10:31:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 12 Dec 2014 11:31:31 +0100 Subject: RFR(S) 8028773: SA, warnings from b116 for hotspot.agent.src.share.native: JNI exception pending In-Reply-To: <548702BA.4080303@oracle.com> References: <547E0FB2.3060402@oracle.com> <547E3C0D.5040307@oracle.com> <547EFCD9.5020301@oracle.com> <31D363FE-3BB9-49A4-AE0B-E9540F592E45@oracle.com> <54846185.3050508@oracle.com> <54858557.8030907@oracle.com> <5486FE67.9070500@oracle.com> <548702BA.4080303@oracle.com> Message-ID: <90EB87B3-969B-49B6-BBB7-571897EC35F9@oracle.com> Looks good! Thanks, /Staffan > On 9 dec 2014, at 15:10, serguei.spitsyn at oracle.com wrote: > > Dmitry, > > It looks good. > > Than you for the update! > Serguei > > On 12/9/14 5:51 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Fixed. Webrev updated in-place, please press shift-reload. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.03/ >> >> -Dmitry >> >> On 2014-12-08 14:02, serguei.spitsyn at oracle.com wrote: >>> Looks good. >>> >>> Some minor comments. >>> >>> Better to reformat with one variable at a line: >>> >>> 113 const char *error_message = NULL, *jrepath = NULL, *libname = NULL; >>> >>> 283 jbyte *start, *end; >>> >>> >>> Uninitialized locals: >>> >>> 115 #ifdef _WINDOWS >>> 116 HINSTANCE hsdis_handle; >>> 117 #else >>> 118 void* hsdis_handle; >>> 119 #endif >>> ... >>> 201 jlong result; >>> ... >>> >>> 282 jboolean isCopy; >>> 283 jbyte *start, *end; >>> 284 jclass disclass; >>> 285 const char *options; >>> >>> >>> Unaligned parameters: >>> >>> 209 result = (*env)->CallLongMethod(env, denv->dis, denv->handle_event, denv->visitor, >>> 210 event_string, (jlong) (uintptr_t)arg); >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/7/14 6:17 AM, Dmitry Samersoff wrote: >>>> Please, review a modified fix: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.03/ >>>> >>>> Windows compiler doesn't allow declaration in the middle of the function >>>> for c code. >>>> >>>> Also I put my few cents to reduce build noise and add a pragma that >>>> disable windows compiler warnings that have no value in this context. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-12-03 16:01, Staffan Larsen wrote: >>>>> Changes look good. What testing have you done? >>>>> >>>>> /Staffan >>>>> >>>>>> On 3 dec 2014, at 13:06, Dmitry Samersoff wrote: >>>>>> >>>>>> Serguei, >>>>>> >>>>>> Updated webrev >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.02/ >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-12-03 01:24, serguei.spitsyn at oracle.com wrote: >>>>>>> Dmitry, >>>>>>> >>>>>>> It is good in general modulo Staffan's comments. >>>>>>> >>>>>>> There are some inconsistencies: >>>>>>> - the ExceptionOccurred(env) is compared to != NULL (which make the >>>>>>> logic more complex) >>>>>>> in some places and no such comparison (implicit comparison instead) >>>>>>> in others >>>>>>> - two different forms of check/action are used: >>>>>>> - (*env)->ExceptionOccurred(env) and >>>>>>> - !(*env)->ExceptionOccurred(env) >>>>>>> >>>>>>> I'd suggest to do it the same way and always return the "default" value >>>>>>> if an exception occurred. >>>>>>> It will make the logic more flat and clear. >>>>>>> Otherwise, we have to think what exact value is returned in exception >>>>>>> occurred cases like at lines 241, 255. >>>>>>> >>>>>>> The comment // OOM is used inconsistently too. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 12/2/14 11:14 AM, Dmitry Samersoff wrote: >>>>>>>> Please review the small fix. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8028773/webrev.01/ >>>>>>>> >>>>>>>> Added more missed exception checks to sadis.c >>>>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the sources. >> > From shanliang.jiang at oracle.com Fri Dec 12 12:44:10 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 12 Dec 2014 13:44:10 +0100 Subject: RFR: 8066952 [TEST-BUG] javax/management/monitor/CounterMonitorTest.java hangs Message-ID: <548AE31A.8050109@oracle.com> Hi, As Daniel said: "I think that what happens here is that the StdObservedObject.getNbObjects() getter unblocks the main thread before returning the value to the monitor. This makes it possible to have a race condition where the next setNbObjects called by the main thread can then occur before the result of StdObservedObject.getNbObjects() is taken into account - and even before the StdObservedObject.getNbObjects() actually returns. So StdObservedObject.getNbObjects() may return a value different than the one which was observed. In our case, it would return 3 (the newer value) instead of 0 (the value that was observed). " The suggested fix is to return "observedValue" instead of "count", in this way we check also that the monitor never starts next observation before the current one finishes. bug: https://bugs.openjdk.java.net/browse/JDK-8066952 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8066952/00/ Thanks, Shanliang From daniel.fuchs at oracle.com Fri Dec 12 13:05:32 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Dec 2014 14:05:32 +0100 Subject: RFR: 8066952 [TEST-BUG] javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <548AE31A.8050109@oracle.com> References: <548AE31A.8050109@oracle.com> Message-ID: <548AE81C.5040405@oracle.com> On 12/12/14 13:44, shanliang wrote: > Hi, > > As Daniel said: "I think that what happens here is that the > StdObservedObject.getNbObjects() getter unblocks the main thread before > returning the value to the monitor. This makes it possible to have a > race condition where the next setNbObjects called by the main thread can > then occur before the result of StdObservedObject.getNbObjects() is > taken into account - and even before the > StdObservedObject.getNbObjects() actually returns. So > StdObservedObject.getNbObjects() may return a value different than the > one which was observed. In our case, it would return 3 (the newer value) > instead of 0 (the value that was observed). " > > The suggested fix is to return "observedValue" instead of "count", in > this way we check also that the monitor never starts next observation > before the current one finishes. Looks good Shanliang! -- daniel > > bug: https://bugs.openjdk.java.net/browse/JDK-8066952 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8066952/00/ > > Thanks, > Shanliang From dchan at atlassian.com Fri Dec 12 19:06:07 2014 From: dchan at atlassian.com (David Chan) Date: Fri, 12 Dec 2014 13:06:07 -0600 Subject: JDK-6584008 Message-ID: Hi, I do not have an account with openjdk bug tracker, but ran into what looks like the bug mentioned here: - https://bugs.openjdk.java.net/browse/JDK-6584008 I'm hoping to leave feedback that it occurred on Java 7: # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGSEGV (0xb) at pc=0x00007f88fd18f84b, pid=25705, tid=140225870702336 > > # > > # JRE version: 7.0_25-b15 > > # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode > linux-amd64 compressed oops) > > # Problematic frame: > > # V [libjvm.so+0x63784b] invoke_string_value_callback(int (*)(long, > long, long*, unsigned short const*, int, void*), CallbackWrapper*, > oopDesc*, void*)+0x11b > Current thread (0x00007f88f831d800): VMThread [stack: > 0x00007f88e1262000,0x00007f88e1363000] [id=25725] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), > si_addr=0x000000000000000c Stack: [0x00007f88e1262000,0x00007f88e1363000], sp=0x00007f88e13619a0, > free space=1022k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > V [libjvm.so+0x63784b] invoke_string_value_callback(int (*)(long, long, > long*, unsigned short const*, int, void*), CallbackWrapper*, oopDesc*, > void*)+0x11b > V [libjvm.so+0x639496] > IterateThroughHeapObjectClosure::do_object(oopDesc*)+0x476 > V [libjvm.so+0x708964] MutableSpace::object_iterate(ObjectClosure*)+0x74 > V [libjvm.so+0x7a5a50] PSYoungGen::object_iterate(ObjectClosure*)+0x20 > V [libjvm.so+0x75d008] > ParallelScavengeHeap::object_iterate(ObjectClosure*)+0x18 > V [libjvm.so+0x63a363] VM_HeapIterateOperation::doit()+0x43 > V [libjvm.so+0x8aac8c] VM_Operation::evaluate()+0x4c > V [libjvm.so+0x8a96a0] VMThread::evaluate_operation(VM_Operation*)+0x80 > V [libjvm.so+0x8a9c26] VMThread::loop()+0x1e6 > V [libjvm.so+0x8aa2c0] VMThread::run()+0x70 > V [libjvm.so+0x744270] java_start(Thread*)+0x100 -David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Fri Dec 12 20:54:27 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 12 Dec 2014 23:54:27 +0300 Subject: RFR: 8067295 - Need to port Utils chagnes... 8067307: Need custom classloaders... 8067291: Need additional vm checks... Message-ID: <548B5603.5030902@oracle.com> Hi, Please review changes for https://bugs.openjdk.java.net/browse/JDK-8067291 - Need additional vm checks in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking which vm is run https://bugs.openjdk.java.net/browse/JDK-8067295 - Need to port Utils chagnes from JDK-8059613 into jdk workspace https://bugs.openjdk.java.net/browse/JDK-8067307 - Need custom classloaders(parent-last and filtering one) for JDK-8066625 in testlibrary Description: A number of small testlibrary changes needed for further test development, 2 of 3 is porn from respective hotspot changes 3rd one (JDK-8067307) introduce 2 classloaders for testlibrary. 1st is FilterClassLoader - loads classes using target classloader in case class name meets provided condition, and using parent otherwise. 2nd is ParentLastURLClassLoader which loads classes using provided URL[] with fallback to parent, Webrevs: http://cr.openjdk.java.net/~iignatyev/dpochepk/8067291/webrev.00/ http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.00/ http://cr.openjdk.java.net/~iignatyev/dpochepk/8067307/webrev.00/ Thanks, Dmitrij From david.holmes at oracle.com Sat Dec 13 01:00:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 13 Dec 2014 11:00:42 +1000 Subject: JDK-6584008 In-Reply-To: References: Message-ID: <548B8FBA.6010504@oracle.com> Hi David, I've added this info to the bug report. Cheers, David H. On 13/12/2014 5:06 AM, David Chan wrote: > Hi, > > I do not have an account with openjdk bug tracker, but ran into what > looks like the bug mentioned here: > > * https://bugs.openjdk.java.net/browse/JDK-6584008 > > I'm hoping to leave feedback that it occurred on Java 7: > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGSEGV (0xb) at pc=0x00007f88fd18f84b, pid=25705, > tid=140225870702336 > > # > > # JRE version: 7.0_25-b15 > > # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode > linux-amd64 compressed oops) > > # Problematic frame: > > # V [libjvm.so+0x63784b] invoke_string_value_callback(int > (*)(long, long, long*, unsigned short const*, int, void*), > CallbackWrapper*, oopDesc*, void*)+0x11b > > Current thread (0x00007f88f831d800): VMThread [stack: > 0x00007f88e1262000,0x00007f88e1363000] [id=25725] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), > si_addr=0x000000000000000c > > > Stack: [0x00007f88e1262000,0x00007f88e1363000], > sp=0x00007f88e13619a0, free space=1022k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x63784b] invoke_string_value_callback(int (*)(long, > long, long*, unsigned short const*, int, void*), CallbackWrapper*, > oopDesc*, void*)+0x11b > V [libjvm.so+0x639496] > IterateThroughHeapObjectClosure::do_object(oopDesc*)+0x476 > V [libjvm.so+0x708964] > MutableSpace::object_iterate(ObjectClosure*)+0x74 > V [libjvm.so+0x7a5a50] PSYoungGen::object_iterate(ObjectClosure*)+0x20 > V [libjvm.so+0x75d008] > ParallelScavengeHeap::object_iterate(ObjectClosure*)+0x18 > V [libjvm.so+0x63a363] VM_HeapIterateOperation::doit()+0x43 > V [libjvm.so+0x8aac8c] VM_Operation::evaluate()+0x4c > V [libjvm.so+0x8a96a0] > VMThread::evaluate_operation(VM_Operation*)+0x80 > V [libjvm.so+0x8a9c26] VMThread::loop()+0x1e6 > V [libjvm.so+0x8aa2c0] VMThread::run()+0x70 > V [libjvm.so+0x744270] java_start(Thread*)+0x100 > > > -David From dmitrij.pochepko at oracle.com Mon Dec 15 14:06:16 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 15 Dec 2014 17:06:16 +0300 Subject: RFR: 8067295 - Need to port Utils chagnes... 8067307: Need custom classloaders... 8067291: Need additional vm checks... In-Reply-To: <548B5603.5030902@oracle.com> References: <548B5603.5030902@oracle.com> Message-ID: <548EEAD8.7000509@oracle.com> Hi, a bit of update for https://bugs.openjdk.java.net/browse/JDK-8067295 (port of JDK-8066440) http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.01/ Thanks, Dmitrij > Hi, > > Please review changes for > https://bugs.openjdk.java.net/browse/JDK-8067291 - Need additional vm > checks in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking > which vm is run > https://bugs.openjdk.java.net/browse/JDK-8067295 - Need to port Utils > chagnes from JDK-8059613 into jdk workspace > https://bugs.openjdk.java.net/browse/JDK-8067307 - Need custom > classloaders(parent-last and filtering one) for JDK-8066625 in > testlibrary > > Description: A number of small testlibrary changes needed for further > test development, 2 of 3 is port from respective hotspot changes > 3rd one (JDK-8067307) introduce 2 classloaders for testlibrary. 1st is > FilterClassLoader - loads classes using target classloader in case > class name meets provided condition, and using parent otherwise. 2nd > is ParentLastURLClassLoader which loads classes using provided URL[] > with fallback to parent, > > Webrevs: > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067291/webrev.00/ > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.00/ > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067307/webrev.00/ > > Thanks, > Dmitrij From dmitry.samersoff at oracle.com Mon Dec 15 14:32:10 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 15 Dec 2014 17:32:10 +0300 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: <548EF0EA.6010200@oracle.com> Volker, This is part two of review. Code looks good for me, only minor nits. * agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: 41 missed space around = 51 extra space between pc * agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java 47, 48 extra space before = * agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java 34 extra space before id 42 extra space before = , it might be better to create a constant for size of integer. * agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java -no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java 43 missed space before ? it might be be better to reformat this line to usual if and add comments * agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java - no comments * agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java 57, 58 extra space before = 63 and below extra space after public 108 unaligned comments * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java 49 Formatting in PPC64Frame.java looks much better for me. 40 private static final boolean DEBUG; 41 static { 42 DEBUG = ... 43 } 60, 61 extra space before = 147 missed {} after if (DEBUG) * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java 49 - 61, please fix extra and missed spaces 64,67 - extra spaces after static 81 missed space after (int) 115,137 - I would prefer to always use {} after if 212 - multiple missed space before '?' 271 extra space before return * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java - no comments * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java - no comments -Dmitry On 2014-12-09 21:10, Volker Simonis wrote: > Hi, > > can somebody from the serviceability team please review this webrev? > > http://cr.openjdk.java.net/~simonis/webrevs/8049716 > https://bugs.openjdk.java.net/browse/JDK-8049716 > > The shared changes are really all trivial. > > Thanks, > Volker > > > On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >> Hi Sasha, >> >> thanks for looking at this change. >> I'll incorporate your suggestions into the final version. >> I'm just waiting for one more review before preparing a new webrev. >> >> Regards, >> Volker >> >> >> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>> You are correct, but there no need to have this code for LE at all. >>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>> along with the "#if defined(ppc64)". >>>> >>>> BTW, a bit on nitpicking in the same file: >>>> + String endian = System.getProperty("sun.cpu.endian"); >>>> + if (endian.equals("big")) >>>> + return true; >>>> + else >>>> + return false; >>>> can be rewirtten as >>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>> Right. A silly piece of coding there. :-/ >>> >>> -Maynard >>>> >>>> >>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>> The changes for agent/src/os/linux/symtab.c >>>>>> b/agent/src/os/linux/symtab.c in >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>> Linux/PPC64 little-endian: >>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>> brackets in it should >>>>>> read >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> instead of just >>>>>> #if defined(ppc64) >>>>> Hi, Alexander, >>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>> place where I think there may be a problem is at line 455: >>>>> >>>>> -------------------------- >>>>> #if defined(ppc64) >>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>> // with the above algorithm impossible (we would need the have both, the >>>>> // .opd section from the library and the symbol table from the debuginfo >>>>> // file which doesn't match with the current workflow.) >>>>> if (false) { >>>>> #else >>>>> // Look for a separate debuginfo file. >>>>> if (try_debuginfo) { >>>>> #endif >>>>> -------------------------- >>>>> >>>>> Here I think we should do as you suggest: >>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>> >>>>> -Maynard >>>>>> >>>>>> Sorry for the late notice. >>>>>> Sasha >>>>>> >>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>> change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>> >>>>>>> I have already reviewed and tested the change and from my side >>>>>>> everything looks fine. >>>>>>> >>>>>>> The change touches quite some shared code but all of these changes are >>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>> Java). >>>>>>> >>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>> hotspot repository once the review is completed. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>> >>>>> >>>> >>> -- 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.fuchs at oracle.com Mon Dec 15 17:38:39 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 15 Dec 2014 18:38:39 +0100 Subject: RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548AADC3.30301@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AA88F.3050401@oracle.com> <548AADC3.30301@oracle.com> Message-ID: <548F1C9F.2090000@oracle.com> On 12/12/14 09:56, shanliang wrote: > Updated. > > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/ > > Thanks, > Shanliang Hi Shanliang, Your changes looks good to me. WRT using a Phaser, it would require a careful analysis to assert that modifying the locking strategy - especially things like 90 synchronized(o) { 91 synchronized(this) { 92 gotLock = true; 93 94 this.notify(); 95 } still preserve the nature of the test. I wonder if it's worth the trouble. best regards, -- daniel From jaroslav.bachorik at oracle.com Tue Dec 16 12:08:50 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 16 Dec 2014 13:08:50 +0100 Subject: RFR 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <548F1C9F.2090000@oracle.com> References: <548A9A5D.6020000@oracle.com> <548AA88F.3050401@oracle.com> <548AADC3.30301@oracle.com> <548F1C9F.2090000@oracle.com> Message-ID: <549020D2.9020501@oracle.com> On 12/15/2014 06:38 PM, Daniel Fuchs wrote: > On 12/12/14 09:56, shanliang wrote: >> Updated. >> >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/ >> >> Thanks, >> Shanliang > > Hi Shanliang, > > Your changes looks good to me. WRT using a Phaser, it would > require a careful analysis to assert that modifying the > locking strategy - especially things like > 90 synchronized(o) { > 91 synchronized(this) { > 92 gotLock = true; > 93 > 94 this.notify(); > 95 } > still preserve the nature of the test. > I wonder if it's worth the trouble. Well, the test tries to achieve step-by-step execution of two concurrent threads where one thread can only proceed when the other one has already reached a predefined execution point. This is exactly what the Phaser is fit for. Please note that by using Phasero one could also get rid off the Thread.sleep() construct to simulate the fact that the BadBoy thread doesn't finish before the main thread had the chance to assert the postconditions. But the change is already in .. what is done is done. It's just a pity we missed the chance to improve the test a bit while fixing this issue. -JB- > > best regards, > > -- daniel From yekaterina.kantserova at oracle.com Tue Dec 16 15:57:03 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 16 Dec 2014 16:57:03 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid Message-ID: <5490564F.2010907@oracle.com> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-6977426 webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ java/util/logging/LoggerWeakRefLeak.sh and java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in java. sun/tools/common/CommonTests.sh is removed because it doesn't test the product but sun/tool/common library functionality. Thanks, Katja From jaroslav.bachorik at oracle.com Tue Dec 16 16:41:50 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 16 Dec 2014 17:41:50 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <5490564F.2010907@oracle.com> References: <5490564F.2010907@oracle.com> Message-ID: <549060CE.5080505@oracle.com> Hi Katja, This request should probably go to core-libs as well. Other than that I have just a few nits: test/java/util/logging/TestLoggerWeakRefLeak.java L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? L127: // in LogManager.loggers that *arebeing* properly managed -> *are being* callLoggerAndCount() and callAnonymousLoggerAndCount() are using the 'count' variable to always return 100. Could they be made to return a constant instead? Cheers, -JB- On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-6977426 > webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ > > java/util/logging/LoggerWeakRefLeak.sh and > java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in > java. sun/tools/common/CommonTests.sh is removed because it doesn't test > the product but sun/tool/common library functionality. > > Thanks, > Katja From maynardj at us.ibm.com Tue Dec 16 16:47:59 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Tue, 16 Dec 2014 10:47:59 -0600 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <548EF0EA.6010200@oracle.com> References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> Message-ID: <5490623F.1020604@us.ibm.com> On 12/15/2014 08:32 AM, Dmitry Samersoff wrote: > Volker, > > This is part two of review. Code looks good for me, only minor nits. Thanks for the review, Dmitry. *Volker*, will you be making the suggested changes (from all review comments) to the patch set or do you want me to do it? Actually, I am retiring from IBM and, as of Friday, will no longer have access to a ppc64 machine or to my IBM email account. So my colleague, Tiago Daitx (on cc) will take over for me any responsibilities left in pushing this patch set upstream. Thanks again for all the help. -Maynard > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: > > 41 missed space around = > 51 extra space between pc > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java > > > - no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java > > 47, 48 extra space before = > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java > > 34 extra space before id > 42 extra space before = , > it might be better to create a constant for size of integer. > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java > > - no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java > > -no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java > > 43 missed space before ? > it might be be better to reformat this line to usual if and add comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java > > > 57, 58 extra space before = > > 63 and below extra space after public > > 108 unaligned comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java > > 49 Formatting in PPC64Frame.java looks much better for me. > > 40 private static final boolean DEBUG; > 41 static { > 42 DEBUG = ... > 43 } > > > 60, 61 extra space before = > > 147 missed {} after if (DEBUG) > > * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java > > 49 - 61, please fix extra and missed spaces > > 64,67 - extra spaces after static > 81 missed space after (int) > > 115,137 - I would prefer to always use {} after if > > 212 - multiple missed space before '?' > > 271 extra space before return > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java > > - no comments > > -Dmitry > > > On 2014-12-09 21:10, Volker Simonis wrote: >> Hi, >> >> can somebody from the serviceability team please review this webrev? >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >> https://bugs.openjdk.java.net/browse/JDK-8049716 >> >> The shared changes are really all trivial. >> >> Thanks, >> Volker >> >> >> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>> Hi Sasha, >>> >>> thanks for looking at this change. >>> I'll incorporate your suggestions into the final version. >>> I'm just waiting for one more review before preparing a new webrev. >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>> You are correct, but there no need to have this code for LE at all. >>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>> along with the "#if defined(ppc64)". >>>>> >>>>> BTW, a bit on nitpicking in the same file: >>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>> + if (endian.equals("big")) >>>>> + return true; >>>>> + else >>>>> + return false; >>>>> can be rewirtten as >>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>> Right. A silly piece of coding there. :-/ >>>> >>>> -Maynard >>>>> >>>>> >>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>> Linux/PPC64 little-endian: >>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>> brackets in it should >>>>>>> read >>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>> instead of just >>>>>>> #if defined(ppc64) >>>>>> Hi, Alexander, >>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>> place where I think there may be a problem is at line 455: >>>>>> >>>>>> -------------------------- >>>>>> #if defined(ppc64) >>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>> // file which doesn't match with the current workflow.) >>>>>> if (false) { >>>>>> #else >>>>>> // Look for a separate debuginfo file. >>>>>> if (try_debuginfo) { >>>>>> #endif >>>>>> -------------------------- >>>>>> >>>>>> Here I think we should do as you suggest: >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> >>>>>> -Maynard >>>>>>> >>>>>>> Sorry for the late notice. >>>>>>> Sasha >>>>>>> >>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>> change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>> >>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>> everything looks fine. >>>>>>>> >>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>> Java). >>>>>>>> >>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>> hotspot repository once the review is completed. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>> >>>>>> >>>>> >>>> > > From erik.gahlin at oracle.com Tue Dec 16 17:23:36 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 16 Dec 2014 18:23:36 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <5490564F.2010907@oracle.com> References: <5490564F.2010907@oracle.com> Message-ID: <54906A98.1020907@oracle.com> You could use a lambda instead of a boolean and the duplicated functions, i.e. public static void main(String[] args) throws Exception { if (args[0].equals("Logger")) { testIfLeaking(TestLoggerWeakRefLeak::getLogger); } else { testIfLeaking(TestLoggerWeakRefLeak::getAnonymousLogger); } } private static void testIfLeaking(Runnable getLogger) { ... getLogger.run(); ... } Erik Yekaterina Kantserova skrev 2014-12-16 16:57: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-6977426 > webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ > > java/util/logging/LoggerWeakRefLeak.sh and > java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in > java. sun/tools/common/CommonTests.sh is removed because it doesn't > test the product but sun/tool/common library functionality. > > Thanks, > Katja From daniel.fuchs at oracle.com Tue Dec 16 17:37:40 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Dec 2014 18:37:40 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <5490564F.2010907@oracle.com> References: <5490564F.2010907@oracle.com> Message-ID: <54906DE4.5030409@oracle.com> Hi Katja, Nice too see some more shell scripts go away! I wonder - shouldn't the test force a System.gc() at some point before taking the histogram? If not what guarantee do we have that the various weak references will be purged? best regards, -- daniel On 16/12/14 16:57, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-6977426 > webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ > > java/util/logging/LoggerWeakRefLeak.sh and > java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in > java. sun/tools/common/CommonTests.sh is removed because it doesn't test > the product but sun/tool/common library functionality. > > Thanks, > Katja From stuart.marks at oracle.com Tue Dec 16 22:55:58 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 16 Dec 2014 14:55:58 -0800 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5489DFF1.7010800@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5489B3B5.1010801@oracle.com> <5489DA1A.1080108@oracle.com> <5489DFF1.7010800@oracle.com> Message-ID: <5490B87E.7020709@oracle.com> Hi Dmitry, Strictly speaking you are correct. As soon as you close a socket, there is a possibility -- perhaps vanishingly small but nonzero -- that you might not be able to open it again. The first scenario, where the user of the socket itself opens the socket using an ephemeral port (e.g. new ServerSocket(0)) is of course preferred. This avoids race conditions entirely. It's the second case that I'm still wrestling with, and maybe Jaroslav too. It's fairly difficult to get such "black box" systems to open an ephemeral port and report it back, as opposed to opening up their service on some port number handed in from the outside. (For RMI, rmid is the culprit here. I don't know about JMX.) What makes this difficult is that the rmid service is running in a separate VM, so getting reliable information back from it can be difficult. It's also fairly difficult to establish the retry logic in such cases. If the service fails with a BindException, maybe -- maybe -- it was because there was a conflict over the port, and a retry is warranted. But this needs to be distinguished from other failure modes that might occur, that should be reported as failures instead of causing a retry. In principle, this is possible to do, of course, it's just that it involves more restructuring of the tests, and possibly adding debug/test code to rmid. (It may yet come to that.) I'm still pondering the reasons that, in the open/close/reopen scenario, why the reopen might fail. The obvious reason is that some other process on the system has opened that port between the close and the reopen. I admit that this is a possibility. However, with the open/close/reopen scenario in place, we see tests that fail up to 15% of the time with BindExceptions. This is an extraordinarily high failure rate to be caused by some random other process happening to open the same port in the few microseconds between the close and reopen. It's simply not believable to me. My thinking is still that the port isn't ready for reuse until a small amount of time after it's closed. I have some test programs that exercise sockets in a particular way (e.g., from multiple threads, or opening and closing batches of sockets) that can reproduce the problem on some systems, and these test programs seem to behave better if a time delay is added between the close and the reopen. The exact circumstances under which the problem occurs is difficult to pin down and seems OS specific, and so choosing the "right" delay time is very difficult. But it does strengthen this conjecture in my mind. Naturally it would be better if there were a way to determine when a port is available for reuse without actually opening it. I'm not aware of any such way, but I'm holding onto a little hope that one can be found. s'marks On 12/11/14 10:18 AM, Dmitry Samersoff wrote: > Stuart, > > As soon as you close socket, you open a door for the race. > > So you need another communication channel to pass a port number (or bind > result) between a client and a server without closing a socket on the > server side. > > Typical scenario used by network related code is: > > 1. Server opens the socket > 2. Server binds to port(0) > 3. Server gets port number assigned by OS > 4. Server informs client (e.g. write the port down to known file, > broadcast it etc) > 5. Client establishes connection. > > If the server is a blackbox and have to get a port number from outside, > scenario looks like: > > WHILE(!success and !timeout) > 1. Driver chooses random port number > 2. Driver runs a server with this number > 3. Driver checks that server is actually listening on this port > (e.g. try to connect by it self) > WEND > > 4. Driver runs a client with this port number or bails out with > descriptive error message. > > -Dmitry > > On 2014-12-11 20:53, Stuart Marks wrote: >> >> >> On 12/11/14 7:09 AM, olivier.lagneau at oracle.com wrote: >>> On 11/12/2014 15:43, Dmitry Samersoff wrote: >>>> You can set SO_LINGER to zero, in this case socket will be closed >>>> immediately without waiting in TIME_WAIT >>> SO-LINGER did not help either in my case (see my previous mail to >>> Jaroslav). >>> That ended-up in using another hard-coded (supposedly free) port. >>> Note that was before RMI tests used randomly allocated ports. >>> >>>> But there are no reliable way to predict whether you can take this port >>>> or not after you close it. >>> This is what I observed in my case. >>>> >>>> So the only valid solution is to try to connect to a random port and if >>>> this attempt fails try another random port. Everything else will cause >>>> more or less frequent intermittent failures. >>> IIRC think this is what is currently done in RMI tests. >> >> The RMI tests are still suffering from this problem, unfortunately. >> >> The RMI test library gets a "random" port with "new ServerSocket(0)", >> gets the port number, closes the socket, then returns the port to the >> caller. The caller then assumes that it can use that port as it wishes. >> That's when the BindException can occur. There are about 10 RMI test >> bugs in the database that all seem to have this as their root cause. >> >> There is some retry logic in RMI's test library, but that's to avoid the >> so-called "reserved ports" that specific RMI tests use, or if "new >> ServerSocket(0)" fails. It doesn't have anything to do with the >> BindException that occurs when the caller attempts to reuse the port >> with another socket. >> >> My observation is also that setting SO_REUSEADDR has no effect. I >> haven't tried SO_LINGER. My hunch is that it won't have any effect, >> since the sockets in question aren't actually going into TIME_WAIT >> state. But I suppose it's worth a try. >> >> I don't have any solution for this; we're still discussing the issue. I >> think the best approach would be to refactor the code so that the >> eventual user of the socket opens it up on an ephemeral port in the >> first place. That avoids the open/close/reopen business. Unfortunately >> that doesn't help the case where you want to tell another JVM to run a >> service on a specific port. We don't have a solution for that case yet. >> >> The second-best approach (not really a solution) is to open/close a >> serversocket to get the port, sleep for a little bit, then return the >> port number to the caller. This might give the kernel a chance to clean >> up the socket after the close. Of course, this still has a race >> condition, but it might reduce the incidence of problems to an >> acceptable level. >> >> I'll let you know if we come up with anything better. >> >> s'marks > > From yekaterina.kantserova at oracle.com Wed Dec 17 07:52:26 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 17 Dec 2014 08:52:26 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <54906DE4.5030409@oracle.com> References: <5490564F.2010907@oracle.com> <54906DE4.5030409@oracle.com> Message-ID: <5491363A.7060604@oracle.com> Hi Daniel, Thank you for reviewing the fix! That's what 'vm.heapHisto("-live")' does - it will request a full GC. Best regards, Katja On 12/16/2014 06:37 PM, Daniel Fuchs wrote: > Hi Katja, > > Nice too see some more shell scripts go away! > > I wonder - shouldn't the test force a System.gc() > at some point before taking the histogram? > > If not what guarantee do we have that the various weak references > will be purged? > > best regards, > > -- daniel > > On 16/12/14 16:57, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >> >> java/util/logging/LoggerWeakRefLeak.sh and >> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in >> java. sun/tools/common/CommonTests.sh is removed because it doesn't test >> the product but sun/tool/common library functionality. >> >> Thanks, >> Katja > From yekaterina.kantserova at oracle.com Wed Dec 17 09:10:47 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 17 Dec 2014 10:10:47 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <549060CE.5080505@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> Message-ID: <54914897.2050006@oracle.com> Hi, Thanks for all reviews! The new webrev can be found here: http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ // Katja On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: > Hi Katja, > > This request should probably go to core-libs as well. > > Other than that I have just a few nits: > > test/java/util/logging/TestLoggerWeakRefLeak.java > > L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? > L127: // in LogManager.loggers that *arebeing* properly managed -> > *are being* > > callLoggerAndCount() and callAnonymousLoggerAndCount() are using the > 'count' variable to always return 100. Could they be made to return a > constant instead? > > > Cheers, > > -JB- > > > On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >> >> java/util/logging/LoggerWeakRefLeak.sh and >> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in >> java. sun/tools/common/CommonTests.sh is removed because it doesn't test >> the product but sun/tool/common library functionality. >> >> Thanks, >> Katja > From yekaterina.kantserova at oracle.com Wed Dec 17 09:15:45 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 17 Dec 2014 10:15:45 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <54914897.2050006@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> <54914897.2050006@oracle.com> Message-ID: <549149C1.4050205@oracle.com> Adding Erik. On 12/17/2014 10:10 AM, Yekaterina Kantserova wrote: > Hi, > > Thanks for all reviews! > > The new webrev can be found here: > http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ > > // Katja > > > > On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: >> Hi Katja, >> >> This request should probably go to core-libs as well. >> >> Other than that I have just a few nits: >> >> test/java/util/logging/TestLoggerWeakRefLeak.java >> >> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? >> L127: // in LogManager.loggers that *arebeing* properly managed -> >> *are being* >> >> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the >> 'count' variable to always return 100. Could they be made to return a >> constant instead? >> >> >> Cheers, >> >> -JB- >> >> >> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >>> >>> java/util/logging/LoggerWeakRefLeak.sh and >>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in >>> java. sun/tools/common/CommonTests.sh is removed because it doesn't >>> test >>> the product but sun/tool/common library functionality. >>> >>> Thanks, >>> Katja >> > From daniel.fuchs at oracle.com Wed Dec 17 09:55:16 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Dec 2014 10:55:16 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <54914897.2050006@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> <54914897.2050006@oracle.com> Message-ID: <54915304.4080503@oracle.com> Hi Katja, Sorry for not thinking of that when I replied earlier. Your new test is so much more readable than the old shell script :-) These are minor suggestions but they might help analysis if the test fails: On 17/12/14 10:10, Yekaterina Kantserova wrote: > Hi, > > Thanks for all reviews! > > The new webrev can be found here: > http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ Not that I believe it's very likely to happen, but I wonder if the condition to exit the while loop: 79 while (now < (startTime + (LOOP_TIME_SEC * 1000))) { should also make sure that count > 1000 - and continue if not. (Thinking of passed timeout related issues when tests where run with -Xcomp on fastdebug builds during integration nightlies) Possibly printing the value of 'count' before the assert at line 103 could help with debugging too, if the test actually fails (even though the combination of increasingCount + decreasingCount would give us a hint) best regards, -- daniel > > // Katja > > > > On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: >> Hi Katja, >> >> This request should probably go to core-libs as well. >> >> Other than that I have just a few nits: >> >> test/java/util/logging/TestLoggerWeakRefLeak.java >> >> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? >> L127: // in LogManager.loggers that *arebeing* properly managed -> >> *are being* >> >> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the >> 'count' variable to always return 100. Could they be made to return a >> constant instead? >> >> >> Cheers, >> >> -JB- >> >> >> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >>> >>> java/util/logging/LoggerWeakRefLeak.sh and >>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in >>> java. sun/tools/common/CommonTests.sh is removed because it doesn't test >>> the product but sun/tool/common library functionality. >>> >>> Thanks, >>> Katja >> > From jaroslav.bachorik at oracle.com Wed Dec 17 10:19:00 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 17 Dec 2014 11:19:00 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code Message-ID: <54915894.3060101@oracle.com> Please, review the following change. Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 This patch is a precursor for implementing https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). Here, the code related to manipulating JVM flags is extracted to a separate ManagedFlags class and the codebease is adjusted to use this class. Thanks, -JB- From yekaterina.kantserova at oracle.com Wed Dec 17 11:05:53 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 17 Dec 2014 12:05:53 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <54915304.4080503@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> <54914897.2050006@oracle.com> <54915304.4080503@oracle.com> Message-ID: <54916391.9010307@oracle.com> Daniel, It's really funny to get such a feedback! (1) The output from test right now looks like: ----------System.out:(7/183)---------- call count = 1000 instance count: 1001 call count = 2000 instance count: 1001 Finishing early due to non-increasing instance count increasing count: 1 decreasing or the same count: 1 so printing the value of 'count' is already in there: 'call count ='. (2) In the case we want to have an extra condition I think it should be 'count > 2000'. Otherwise if the end time is passed the 'count > 1000' will result in having just one iteration (we will left the loop on 1100) and test will fail on assert. The test timeout value should be increased as well. Right now it's 120 + 30 sec. * @run main/timeout=150 TestLoggerWeakRefLeak Logger If the test will not be completed in 120 s the extra 30 s will not make the trick and JTreg will interrupt it. What do you think will be enough? // Katja On 12/17/2014 10:55 AM, Daniel Fuchs wrote: > Hi Katja, > > Sorry for not thinking of that when I replied earlier. > Your new test is so much more readable than the old shell > script :-) > > These are minor suggestions but they might help analysis > if the test fails: > > On 17/12/14 10:10, Yekaterina Kantserova wrote: >> Hi, >> >> Thanks for all reviews! >> >> The new webrev can be found here: >> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ > > Not that I believe it's very likely to happen, but I wonder > if the condition to exit the while loop: > > 79 while (now < (startTime + (LOOP_TIME_SEC * 1000))) { > > should also make sure that count > 1000 - and continue if not. > (Thinking of passed timeout related issues when tests where run > with -Xcomp on fastdebug builds during integration nightlies) > > Possibly printing the value of 'count' before the assert > at line 103 could help with debugging too, if the test actually > fails (even though the combination of increasingCount > + decreasingCount would give us a hint) > > best regards, > > -- daniel > >> >> // Katja >> >> >> >> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: >>> Hi Katja, >>> >>> This request should probably go to core-libs as well. >>> >>> Other than that I have just a few nits: >>> >>> test/java/util/logging/TestLoggerWeakRefLeak.java >>> >>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? >>> L127: // in LogManager.loggers that *arebeing* properly managed -> >>> *are being* >>> >>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the >>> 'count' variable to always return 100. Could they be made to return a >>> constant instead? >>> >>> >>> Cheers, >>> >>> -JB- >>> >>> >>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >>>> >>>> java/util/logging/LoggerWeakRefLeak.sh and >>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in >>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't >>>> test >>>> the product but sun/tool/common library functionality. >>>> >>>> Thanks, >>>> Katja >>> >> > From daniel.fuchs at oracle.com Wed Dec 17 11:33:30 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Dec 2014 12:33:30 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <54916391.9010307@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> <54914897.2050006@oracle.com> <54915304.4080503@oracle.com> <54916391.9010307@oracle.com> Message-ID: <54916A0A.6080508@oracle.com> On 17/12/14 12:05, Yekaterina Kantserova wrote: > Daniel, > > It's really funny to get such a feedback! > > (1) The output from test right now looks like: > > ----------System.out:(7/183)---------- > call count = 1000 > instance count: 1001 > call count = 2000 > instance count: 1001 > Finishing early due to non-increasing instance count > increasing count: 1 > decreasing or the same count: 1 > > so printing the value of 'count' is already in there: 'call count ='. I meant to print the final value for count - but OK - having the 'call count' printed every 1000 count should be enough :-) > (2) In the case we want to have an extra condition I think it should be > 'count > 2000'. Otherwise if the end time is passed the 'count > 1000' > will result in having just one iteration (we will left the loop on 1100) > and test will fail on assert. right. my mistake. you need at least two histograms. > The test timeout value should be increased as well. Right now it's 120 + > 30 sec. > > * @run main/timeout=150 TestLoggerWeakRefLeak Logger > > If the test will not be completed in 120 s the extra 30 s will not make > the trick and JTreg will interrupt it. What do you think will be enough? I am not sure - but I guess what you have now should be good enough for starter. In the problematic configurations there often is an additional timeout factor - so in such case the real jtreg timeout would I believe be something like 150*4 anyway - which should hopefully leave time enough for the while loop to take two histograms. Simply adding the extra condition to keep looping until we have at least two should do the trick. best regards, and thanks again for taking care of 6977426! -- daniel > > // Katja > > > > On 12/17/2014 10:55 AM, Daniel Fuchs wrote: >> Hi Katja, >> >> Sorry for not thinking of that when I replied earlier. >> Your new test is so much more readable than the old shell >> script :-) >> >> These are minor suggestions but they might help analysis >> if the test fails: >> >> On 17/12/14 10:10, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Thanks for all reviews! >>> >>> The new webrev can be found here: >>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ >> >> Not that I believe it's very likely to happen, but I wonder >> if the condition to exit the while loop: >> >> 79 while (now < (startTime + (LOOP_TIME_SEC * 1000))) { >> >> should also make sure that count > 1000 - and continue if not. >> (Thinking of passed timeout related issues when tests where run >> with -Xcomp on fastdebug builds during integration nightlies) >> >> Possibly printing the value of 'count' before the assert >> at line 103 could help with debugging too, if the test actually >> fails (even though the combination of increasingCount >> + decreasingCount would give us a hint) >> >> best regards, >> >> -- daniel >> >>> >>> // Katja >>> >>> >>> >>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: >>>> Hi Katja, >>>> >>>> This request should probably go to core-libs as well. >>>> >>>> Other than that I have just a few nits: >>>> >>>> test/java/util/logging/TestLoggerWeakRefLeak.java >>>> >>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? >>>> L127: // in LogManager.loggers that *arebeing* properly managed -> >>>> *are being* >>>> >>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the >>>> 'count' variable to always return 100. Could they be made to return a >>>> constant instead? >>>> >>>> >>>> Cheers, >>>> >>>> -JB- >>>> >>>> >>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >>>>> >>>>> java/util/logging/LoggerWeakRefLeak.sh and >>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in >>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't >>>>> test >>>>> the product but sun/tool/common library functionality. >>>>> >>>>> Thanks, >>>>> Katja >>>> >>> >> > From yekaterina.kantserova at oracle.com Wed Dec 17 13:11:43 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 17 Dec 2014 14:11:43 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <54916A0A.6080508@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> <54914897.2050006@oracle.com> <54915304.4080503@oracle.com> <54916391.9010307@oracle.com> <54916A0A.6080508@oracle.com> Message-ID: <5491810F.6030900@oracle.com> Hopefully the last version :) Erik has recommended to skip the whole timeout concept. Instead the test will loop until a decreasing count is found. Otherwise the test will timeout. The default JTreg time out is 5 minutes so it would be enough even for slower configurations. The new webrev can be found here: http://cr.openjdk.java.net/~ykantser/6977426/webrev.02/ // Katja On 12/17/2014 12:33 PM, Daniel Fuchs wrote: > On 17/12/14 12:05, Yekaterina Kantserova wrote: >> Daniel, >> >> It's really funny to get such a feedback! >> >> (1) The output from test right now looks like: >> >> ----------System.out:(7/183)---------- >> call count = 1000 >> instance count: 1001 >> call count = 2000 >> instance count: 1001 >> Finishing early due to non-increasing instance count >> increasing count: 1 >> decreasing or the same count: 1 >> >> so printing the value of 'count' is already in there: 'call count ='. > > I meant to print the final value for count - but OK - having the > 'call count' printed every 1000 count should be enough :-) > > >> (2) In the case we want to have an extra condition I think it should be >> 'count > 2000'. Otherwise if the end time is passed the 'count > 1000' >> will result in having just one iteration (we will left the loop on 1100) >> and test will fail on assert. > > right. my mistake. you need at least two histograms. > >> The test timeout value should be increased as well. Right now it's 120 + >> 30 sec. >> >> * @run main/timeout=150 TestLoggerWeakRefLeak Logger >> >> If the test will not be completed in 120 s the extra 30 s will not make >> the trick and JTreg will interrupt it. What do you think will be enough? > > I am not sure - but I guess what you have now should be good enough > for starter. In the problematic configurations there often is > an additional timeout factor - so in such case the real jtreg timeout > would I believe be something like 150*4 anyway - which should hopefully > leave time enough for the while loop to take two histograms. Simply > adding the extra condition to keep looping until we have at least two > should do the trick. > > best regards, and thanks again for taking care of 6977426! > > -- daniel > >> >> // Katja >> >> >> >> On 12/17/2014 10:55 AM, Daniel Fuchs wrote: >>> Hi Katja, >>> >>> Sorry for not thinking of that when I replied earlier. >>> Your new test is so much more readable than the old shell >>> script :-) >>> >>> These are minor suggestions but they might help analysis >>> if the test fails: >>> >>> On 17/12/14 10:10, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> Thanks for all reviews! >>>> >>>> The new webrev can be found here: >>>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ >>> >>> Not that I believe it's very likely to happen, but I wonder >>> if the condition to exit the while loop: >>> >>> 79 while (now < (startTime + (LOOP_TIME_SEC * 1000))) { >>> >>> should also make sure that count > 1000 - and continue if not. >>> (Thinking of passed timeout related issues when tests where run >>> with -Xcomp on fastdebug builds during integration nightlies) >>> >>> Possibly printing the value of 'count' before the assert >>> at line 103 could help with debugging too, if the test actually >>> fails (even though the combination of increasingCount >>> + decreasingCount would give us a hint) >>> >>> best regards, >>> >>> -- daniel >>> >>>> >>>> // Katja >>>> >>>> >>>> >>>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: >>>>> Hi Katja, >>>>> >>>>> This request should probably go to core-libs as well. >>>>> >>>>> Other than that I have just a few nits: >>>>> >>>>> test/java/util/logging/TestLoggerWeakRefLeak.java >>>>> >>>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? >>>>> L127: // in LogManager.loggers that *arebeing* properly managed -> >>>>> *are being* >>>>> >>>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the >>>>> 'count' variable to always return 100. Could they be made to return a >>>>> constant instead? >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> -JB- >>>>> >>>>> >>>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >>>>>> Hi, >>>>>> >>>>>> Could I please have a review of this fix. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >>>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >>>>>> >>>>>> java/util/logging/LoggerWeakRefLeak.sh and >>>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and >>>>>> rewritten in >>>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't >>>>>> test >>>>>> the product but sun/tool/common library functionality. >>>>>> >>>>>> Thanks, >>>>>> Katja >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Wed Dec 17 13:22:49 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 17 Dec 2014 14:22:49 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <5491810F.6030900@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> <54914897.2050006@oracle.com> <54915304.4080503@oracle.com> <54916391.9010307@oracle.com> <54916A0A.6080508@oracle.com> <5491810F.6030900@oracle.com> Message-ID: <549183A9.3040508@oracle.com> On 12/17/2014 02:11 PM, Yekaterina Kantserova wrote: > > Hopefully the last version :) > > Erik has recommended to skip the whole timeout concept. Instead the test > will loop until a decreasing count is found. Otherwise the test will > timeout. The default JTreg time out is 5 minutes so it would be enough > even for slower configurations. > > The new webrev can be found here: > http://cr.openjdk.java.net/~ykantser/6977426/webrev.02/ So, basically, instead of relying on the test timeout we will use the harness timeout. Sounds legit. Thumbs up! -JB- > > // Katja > > > > On 12/17/2014 12:33 PM, Daniel Fuchs wrote: >> On 17/12/14 12:05, Yekaterina Kantserova wrote: >>> Daniel, >>> >>> It's really funny to get such a feedback! >>> >>> (1) The output from test right now looks like: >>> >>> ----------System.out:(7/183)---------- >>> call count = 1000 >>> instance count: 1001 >>> call count = 2000 >>> instance count: 1001 >>> Finishing early due to non-increasing instance count >>> increasing count: 1 >>> decreasing or the same count: 1 >>> >>> so printing the value of 'count' is already in there: 'call count ='. >> >> I meant to print the final value for count - but OK - having the >> 'call count' printed every 1000 count should be enough :-) >> >> >>> (2) In the case we want to have an extra condition I think it should be >>> 'count > 2000'. Otherwise if the end time is passed the 'count > 1000' >>> will result in having just one iteration (we will left the loop on 1100) >>> and test will fail on assert. >> >> right. my mistake. you need at least two histograms. >> >>> The test timeout value should be increased as well. Right now it's 120 + >>> 30 sec. >>> >>> * @run main/timeout=150 TestLoggerWeakRefLeak Logger >>> >>> If the test will not be completed in 120 s the extra 30 s will not make >>> the trick and JTreg will interrupt it. What do you think will be enough? >> >> I am not sure - but I guess what you have now should be good enough >> for starter. In the problematic configurations there often is >> an additional timeout factor - so in such case the real jtreg timeout >> would I believe be something like 150*4 anyway - which should hopefully >> leave time enough for the while loop to take two histograms. Simply >> adding the extra condition to keep looping until we have at least two >> should do the trick. >> >> best regards, and thanks again for taking care of 6977426! >> >> -- daniel >> >>> >>> // Katja >>> >>> >>> >>> On 12/17/2014 10:55 AM, Daniel Fuchs wrote: >>>> Hi Katja, >>>> >>>> Sorry for not thinking of that when I replied earlier. >>>> Your new test is so much more readable than the old shell >>>> script :-) >>>> >>>> These are minor suggestions but they might help analysis >>>> if the test fails: >>>> >>>> On 17/12/14 10:10, Yekaterina Kantserova wrote: >>>>> Hi, >>>>> >>>>> Thanks for all reviews! >>>>> >>>>> The new webrev can be found here: >>>>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ >>>> >>>> Not that I believe it's very likely to happen, but I wonder >>>> if the condition to exit the while loop: >>>> >>>> 79 while (now < (startTime + (LOOP_TIME_SEC * 1000))) { >>>> >>>> should also make sure that count > 1000 - and continue if not. >>>> (Thinking of passed timeout related issues when tests where run >>>> with -Xcomp on fastdebug builds during integration nightlies) >>>> >>>> Possibly printing the value of 'count' before the assert >>>> at line 103 could help with debugging too, if the test actually >>>> fails (even though the combination of increasingCount >>>> + decreasingCount would give us a hint) >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>>> >>>>> // Katja >>>>> >>>>> >>>>> >>>>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: >>>>>> Hi Katja, >>>>>> >>>>>> This request should probably go to core-libs as well. >>>>>> >>>>>> Other than that I have just a few nits: >>>>>> >>>>>> test/java/util/logging/TestLoggerWeakRefLeak.java >>>>>> >>>>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? >>>>>> L127: // in LogManager.loggers that *arebeing* properly managed -> >>>>>> *are being* >>>>>> >>>>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the >>>>>> 'count' variable to always return 100. Could they be made to return a >>>>>> constant instead? >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please have a review of this fix. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >>>>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >>>>>>> >>>>>>> java/util/logging/LoggerWeakRefLeak.sh and >>>>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and >>>>>>> rewritten in >>>>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't >>>>>>> test >>>>>>> the product but sun/tool/common library functionality. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>> >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Wed Dec 17 13:36:51 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Dec 2014 14:36:51 +0100 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <5491810F.6030900@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> <54914897.2050006@oracle.com> <54915304.4080503@oracle.com> <54916391.9010307@oracle.com> <54916A0A.6080508@oracle.com> <5491810F.6030900@oracle.com> Message-ID: <549186F3.5070608@oracle.com> Hi Katja, On 17/12/14 14:11, Yekaterina Kantserova wrote: > > Hopefully the last version :) > > Erik has recommended to skip the whole timeout concept. Instead the test > will loop until a decreasing count is found. Otherwise the test will > timeout. The default JTreg time out is 5 minutes so it would be enough > even for slower configurations. Good suggestion. I should have thought of that :-) > The new webrev can be found here: > http://cr.openjdk.java.net/~ykantser/6977426/webrev.02/ Thumbs up from me! cheers, -- daniel > > // Katja > > > > On 12/17/2014 12:33 PM, Daniel Fuchs wrote: >> On 17/12/14 12:05, Yekaterina Kantserova wrote: >>> Daniel, >>> >>> It's really funny to get such a feedback! >>> >>> (1) The output from test right now looks like: >>> >>> ----------System.out:(7/183)---------- >>> call count = 1000 >>> instance count: 1001 >>> call count = 2000 >>> instance count: 1001 >>> Finishing early due to non-increasing instance count >>> increasing count: 1 >>> decreasing or the same count: 1 >>> >>> so printing the value of 'count' is already in there: 'call count ='. >> >> I meant to print the final value for count - but OK - having the >> 'call count' printed every 1000 count should be enough :-) >> >> >>> (2) In the case we want to have an extra condition I think it should be >>> 'count > 2000'. Otherwise if the end time is passed the 'count > 1000' >>> will result in having just one iteration (we will left the loop on 1100) >>> and test will fail on assert. >> >> right. my mistake. you need at least two histograms. >> >>> The test timeout value should be increased as well. Right now it's 120 + >>> 30 sec. >>> >>> * @run main/timeout=150 TestLoggerWeakRefLeak Logger >>> >>> If the test will not be completed in 120 s the extra 30 s will not make >>> the trick and JTreg will interrupt it. What do you think will be enough? >> >> I am not sure - but I guess what you have now should be good enough >> for starter. In the problematic configurations there often is >> an additional timeout factor - so in such case the real jtreg timeout >> would I believe be something like 150*4 anyway - which should hopefully >> leave time enough for the while loop to take two histograms. Simply >> adding the extra condition to keep looping until we have at least two >> should do the trick. >> >> best regards, and thanks again for taking care of 6977426! >> >> -- daniel >> >>> >>> // Katja >>> >>> >>> >>> On 12/17/2014 10:55 AM, Daniel Fuchs wrote: >>>> Hi Katja, >>>> >>>> Sorry for not thinking of that when I replied earlier. >>>> Your new test is so much more readable than the old shell >>>> script :-) >>>> >>>> These are minor suggestions but they might help analysis >>>> if the test fails: >>>> >>>> On 17/12/14 10:10, Yekaterina Kantserova wrote: >>>>> Hi, >>>>> >>>>> Thanks for all reviews! >>>>> >>>>> The new webrev can be found here: >>>>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ >>>> >>>> Not that I believe it's very likely to happen, but I wonder >>>> if the condition to exit the while loop: >>>> >>>> 79 while (now < (startTime + (LOOP_TIME_SEC * 1000))) { >>>> >>>> should also make sure that count > 1000 - and continue if not. >>>> (Thinking of passed timeout related issues when tests where run >>>> with -Xcomp on fastdebug builds during integration nightlies) >>>> >>>> Possibly printing the value of 'count' before the assert >>>> at line 103 could help with debugging too, if the test actually >>>> fails (even though the combination of increasingCount >>>> + decreasingCount would give us a hint) >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>>> >>>>> // Katja >>>>> >>>>> >>>>> >>>>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: >>>>>> Hi Katja, >>>>>> >>>>>> This request should probably go to core-libs as well. >>>>>> >>>>>> Other than that I have just a few nits: >>>>>> >>>>>> test/java/util/logging/TestLoggerWeakRefLeak.java >>>>>> >>>>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? >>>>>> L127: // in LogManager.loggers that *arebeing* properly managed -> >>>>>> *are being* >>>>>> >>>>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the >>>>>> 'count' variable to always return 100. Could they be made to return a >>>>>> constant instead? >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please have a review of this fix. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >>>>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >>>>>>> >>>>>>> java/util/logging/LoggerWeakRefLeak.sh and >>>>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and >>>>>>> rewritten in >>>>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't >>>>>>> test >>>>>>> the product but sun/tool/common library functionality. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>> >>>>> >>>> >>> >> > From markus.gronlund at oracle.com Wed Dec 17 14:45:01 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 17 Dec 2014 06:45:01 -0800 (PST) Subject: RFR(XS): 8066814: Reduce accessibility in TraceEvent Message-ID: <2c9d1e54-7ee2-444d-8ee2-36fefb866f78@default> Greetings, ? Kindly asking for reviews for the following changeset: ? Bug: https://bugs.openjdk.java.net/browse/JDK-8066814 Webrev: http://cr.openjdk.java.net/~mgronlun/8066814/webrev01/ ? Description: TraceEvent currently exposes internals unnecessarily. ? Therefore: ? Remove unnecessarily exposed methods. Add assert for not committing a cancelled event. Add method stubs for !INCLUDE_TRACE ? Thanks in advance Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Wed Dec 17 15:00:18 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 17 Dec 2014 16:00:18 +0100 Subject: RFR(XS): 8066814: Reduce accessibility in TraceEvent In-Reply-To: <2c9d1e54-7ee2-444d-8ee2-36fefb866f78@default> References: <2c9d1e54-7ee2-444d-8ee2-36fefb866f78@default> Message-ID: <54919A82.6090109@oracle.com> Looks good Erik Markus Gr?nlund skrev 2014-12-17 15:45: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066814 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8066814/webrev01/ > > > > Description: > > TraceEvent currently exposes internals unnecessarily. > > > > Therefore: > > > > Remove unnecessarily exposed methods. > Add assert for not committing a cancelled event. > Add method stubs for !INCLUDE_TRACE > > > > Thanks in advance > > Markus From kevin.walls at oracle.com Wed Dec 17 16:15:27 2014 From: kevin.walls at oracle.com (KEVIN WALLS) Date: Wed, 17 Dec 2014 16:15:27 +0000 Subject: RFR(S): backport 8039995 and 8061785 changes to SA testcase Message-ID: <5491AC1F.6020704@oracle.com> Hi, I'd like a review of a backport of these test changes, into 8u. webrev: http://cr.openjdk.java.net/~kevinw/8039995_8061785/webrev.00/ Changes simply hg imported from: 8039995 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/da92e4c42b24 8061785 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/3cdb9f480a8c Thanks! Kevin From serguei.spitsyn at oracle.com Wed Dec 17 17:26:17 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Dec 2014 09:26:17 -0800 Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54762FC9.2010800@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> Message-ID: <5491BCB9.10505@oracle.com> Please, review the second round fix for: https://bugs.openjdk.java.net/browse/JDK-8008678 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ Summary: This fix implements a footprint saving approach suggested by Coleen. To be able to reconstitute a class constant pool, an intermediate pseudo-string map is used. Now, this field is accounted optionally, only if the 'cp_patches' is provided in the ClassFileParser::parseClassFile() before ConstantPool is allocated. This fix is not elegant, even a little bit ugly, but it is the only way I see so far. Unfortunately, this approach did not help much to make some other fields (eg., 'operands') optional. The problem is that we have to account optional fields before parsing, at the CP allocation time. It is possible to re-allocate the ConstantPool when any InvokeDynamic bytecode is discovered, but it looks too complicated. Testing: - the unit test from bug report - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument - vm.mlvm.testlist, vm.quick.testlist, vm.parallel_class_loading.testlist (in progress) Thanks, Serguei On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: > Coleen, > > Thank you for looking at this! > I'll check how this can be improved. > It is my concern too. > > Thanks, > Serguei > > On 11/26/14 9:17 AM, Coleen Phillimore wrote: >> >> Serguei, >> I had a quick look at this. I was wondering if we could make the >> pseudo_string_map conditional in ConstantPool and not make all >> classes pay in footprint for this field? The same thing probably >> could be done for operands too. There are flags that you can set to >> conditionally add a pointer to base() in this function. >> >> Typical C++ would subclass ConstantPool to add >> InvokeDynamicConstantPool fields, but this is not typical C++ so the >> trick we use is like the one in ConstMethod. I think it's worth >> doing in this case. >> >> Thanks, >> Coleen >> >> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>> >>> >>> >>> Summary: >>> The pseudo-strings are currently not supported in reconstitution >>> of constant pool. >>> >>> This is an explanation from John Rose about what the >>> pseudo-strings are: >>> >>> "We still need "live" oop constants pre-linked into the constant >>> pool of bytecodes which >>> implement some method handles. We use the anonymous class >>> pseudo-string feature for that. >>> The relevant code is here: >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>> >>> These oops are what "pseudo-strings" are. >>> The odd name refers to the fact that, even though they are >>> random oops, they appear in the constant pool >>> where one would expect (because of class file syntax) to find a >>> string." >>> ... >>> If you really wanted to reconstitute a class file for an >>> anonymous class, and >>> if that class has oop patching (pseudo-strings), you would need >>> either to (a) reconstitute the patches array >>> handed to Unsafe.defineAnonymousClass, or (b) accept whatever >>> odd strings were there first, as an approximation. >>> The "odd strings" are totally insignificant, and are typically >>> something like "CONSTANT_PLACEHOLDER_42" >>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>> >>> >>> Reconstitution of the ConstantPool is needed for both the JVMTI >>> GetConstantPool() and RetransformClasses(). >>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>> >>> The problem is that a pseudo-string is a patched string that does >>> not have >>> a reference to the string symbol anymore: >>> unresolved_string_at(idx) == NULL >>> >>> The fix is to create and fill in a map from JVM_CONSTANT_String >>> cp index to the JVM_CONSTANT_Utf8 cp index >>> to be able to restore this assotiation in the >>> JvmtiConstantPoolReconstituter. >>> >>> Testing: >>> Run: >>> - java/lang/instrument tests >>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>> >>> >>> Thanks, >>> Serguei >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Dec 17 17:37:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Dec 2014 18:37:13 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <548EF0EA.6010200@oracle.com> References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> Message-ID: Hi Dmitry, once again, thanks for your detailed review. You can find the new version of the webrev under: http://cr.openjdk.java.net/~simonis/webrevs/8049716.v2/ I've rebased it to the latest jdk9/hs-rt repository today. I hope I adressed all your concerns. Please find my additional comments inline below: And I still need a sponsor for pushing this reviewed change. Any volunteers:) Thank you and best regards, Volker > Below is fist part of review - shared files. > > > * agent/make/Makefile - no comments > > * agent/src/os/linux/LinuxDebuggerLocal.c - no comments > > * agent/src/os/linux/symtab.c: > > 438: > - What is the magic of symbols that starts with '.' ? > - As far as I understand you are getting indirect value from opd section. > There's already a very detailed descrition of the whole story in "hotspot/src/share/vm/utilities/elfFuncDescTable.hpp" and I've added a reference to that file in the comment now. > Could you reformat it a bit to have it better readable? > > Something like: > > uintptr_t sym_value; > ... > symvalue = syms->st_value > > #ifdef ppc64 > // Some comments here > // ppc specific code here > sym_value = > #endif > > symtab->symbols[j].offset = sym_value - baseaddr; > Good point. Done as suggested by you. > > 454: > > I appreciate detailed comments here. > > if (false) can cause unreachable code warning, and unused variable > warning so it might be better to add #ifdef ppc64 on caller > site at ll. 516 and leave here only a comment. > > But if you decide to guard against try_debuginfo please replace > > if (false) > > to > > goto quit > I think there's already a comment in place. The problem is that the debuginfo file only has an empty .opd section. So if we would use the debuginfo file for symbol resolution we would still need the .opd section from the regular library. This doesn't fit in the current function work flow which only uses ELF data from a single file and I didn?t wanted to change that. But your suggestion of using 'goto quit' is good and I've used that version. > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java > > 38: return (endian.equals("big")); > > is enough > I've used the even shorter version proposed by Alexander Smundak: return "big".equals(System.getProperty("sun.cpu.endian")) > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java > - no comments > > * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments > > * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments > > * make/linux/makefiles/sa.make - no comments > > * make/sa.files - no comments > > * src/share/vm/runtime/vmStructs.cpp > - no comments > > This is part two of review. Code looks good for me, only minor nits. > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: > > 41 missed space around = > 51 extra space between pc > Done. > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java > > > - no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java > > 47, 48 extra space before = > Done. > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java > > 34 extra space before id > 42 extra space before = , Done. > it might be better to create a constant for size of integer. > I agree, but this code was just copied from the corresponding AMD64 version and as far as I can see all the other architectures do it the same way so I didn't change it. > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java > > - no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java > > -no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java > > 43 missed space before ? > it might be be better to reformat this line to usual if and add comments > The same here - this is copied code. But I've adjusted it to at least match with the other platforms. > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java > > > 57, 58 extra space before = > > 63 and below extra space after public > > 108 unaligned comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java > > 49 Formatting in PPC64Frame.java looks much better for me. > > 40 private static final boolean DEBUG; > 41 static { > 42 DEBUG = ... > 43 } > > > 60, 61 extra space before = > > 147 missed {} after if (DEBUG) > Done. > * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java > > 49 - 61, please fix extra and missed spaces > > 64,67 - extra spaces after static > 81 missed space after (int) > > 115,137 - I would prefer to always use {} after if > > 212 - multiple missed space before '?' > > 271 extra space before return > Done. > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java > > - no comments > > -Dmitry > > > On 2014-12-09 21:10, Volker Simonis wrote: >> Hi, >> >> can somebody from the serviceability team please review this webrev? >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >> https://bugs.openjdk.java.net/browse/JDK-8049716 >> >> The shared changes are really all trivial. >> >> Thanks, >> Volker >> >> >> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>> Hi Sasha, >>> >>> thanks for looking at this change. >>> I'll incorporate your suggestions into the final version. >>> I'm just waiting for one more review before preparing a new webrev. >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>> You are correct, but there no need to have this code for LE at all. >>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>> along with the "#if defined(ppc64)". >>>>> >>>>> BTW, a bit on nitpicking in the same file: >>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>> + if (endian.equals("big")) >>>>> + return true; >>>>> + else >>>>> + return false; >>>>> can be rewirtten as >>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>> Right. A silly piece of coding there. :-/ >>>> >>>> -Maynard >>>>> >>>>> >>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>> Linux/PPC64 little-endian: >>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>> brackets in it should >>>>>>> read >>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>> instead of just >>>>>>> #if defined(ppc64) >>>>>> Hi, Alexander, >>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>> place where I think there may be a problem is at line 455: >>>>>> >>>>>> -------------------------- >>>>>> #if defined(ppc64) >>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>> // file which doesn't match with the current workflow.) >>>>>> if (false) { >>>>>> #else >>>>>> // Look for a separate debuginfo file. >>>>>> if (try_debuginfo) { >>>>>> #endif >>>>>> -------------------------- >>>>>> >>>>>> Here I think we should do as you suggest: >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> >>>>>> -Maynard >>>>>>> >>>>>>> Sorry for the late notice. >>>>>>> Sasha >>>>>>> >>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>> change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>> >>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>> everything looks fine. >>>>>>>> >>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>> Java). >>>>>>>> >>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>> hotspot repository once the review is completed. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>> >>>>>> >>>>> >>>> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Dec 17 18:06:20 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 17 Dec 2014 21:06:20 +0300 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> Message-ID: <5491C61C.1060609@oracle.com> Volker, The changes looks good for me and I'll sponsor the push. But please check, whether you need one more reviewer or not. -Dmitry On 2014-12-17 20:37, Volker Simonis wrote: > Hi Dmitry, > > once again, thanks for your detailed review. You can find the new > version of the webrev under: > > http://cr.openjdk.java.net/~simonis/webrevs/8049716.v2/ > > I've rebased it to the latest jdk9/hs-rt repository today. > > I hope I adressed all your concerns. Please find my additional > comments inline below: > > And I still need a sponsor for pushing this reviewed change. Any volunteers:) > > Thank you and best regards, > Volker > >> Below is fist part of review - shared files. >> >> >> * agent/make/Makefile - no comments >> >> * agent/src/os/linux/LinuxDebuggerLocal.c - no comments >> >> * agent/src/os/linux/symtab.c: >> >> 438: >> - What is the magic of symbols that starts with '.' ? >> - As far as I understand you are getting indirect value from opd section. >> > > There's already a very detailed descrition of the whole story in > "hotspot/src/share/vm/utilities/elfFuncDescTable.hpp" and I've added a > reference to that file in the comment now. > >> Could you reformat it a bit to have it better readable? >> >> Something like: >> >> uintptr_t sym_value; >> ... >> symvalue = syms->st_value >> >> #ifdef ppc64 >> // Some comments here >> // ppc specific code here >> sym_value = >> #endif >> >> symtab->symbols[j].offset = sym_value - baseaddr; >> > > Good point. Done as suggested by you. > >> >> 454: >> >> I appreciate detailed comments here. >> >> if (false) can cause unreachable code warning, and unused variable >> warning so it might be better to add #ifdef ppc64 on caller >> site at ll. 516 and leave here only a comment. >> >> But if you decide to guard against try_debuginfo please replace >> >> if (false) >> >> to >> >> goto quit >> > > I think there's already a comment in place. The problem is that the > debuginfo file only has an empty .opd section. So if we would use the > debuginfo file for symbol resolution we would still need the .opd > section from the regular library. This doesn't fit in the current > function work flow which only uses ELF data from a single file and I > didn?t wanted to change that. > > But your suggestion of using 'goto quit' is good and I've used that version. > >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java >> >> 38: return (endian.equals("big")); >> >> is enough >> > > I've used the even shorter version proposed by Alexander Smundak: > > return "big".equals(System.getProperty("sun.cpu.endian")) > >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java >> - no comments >> >> * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments >> >> * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments >> >> * make/linux/makefiles/sa.make - no comments >> >> * make/sa.files - no comments >> >> * src/share/vm/runtime/vmStructs.cpp >> - no comments >> > >> This is part two of review. Code looks good for me, only minor nits. >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: >> >> 41 missed space around = >> 51 extra space between pc >> > > Done. > >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java >> >> >> - no comments >> >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java >> >> 47, 48 extra space before = >> > > Done. > >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java >> >> 34 extra space before id >> 42 extra space before = , > > Done. > >> it might be better to create a constant for size of integer. >> > > I agree, but this code was just copied from the corresponding AMD64 > version and as far as I can see all the other architectures do it the > same way so I didn't change it. > >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java >> >> - no comments >> >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java >> >> -no comments >> >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java >> >> 43 missed space before ? >> it might be be better to reformat this line to usual if and add comments >> > > The same here - this is copied code. But I've adjusted it to at least > match with the other platforms. > >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java >> >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java >> >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java >> >> >> 57, 58 extra space before = >> >> 63 and below extra space after public >> >> 108 unaligned comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java >> >> 49 Formatting in PPC64Frame.java looks much better for me. >> >> 40 private static final boolean DEBUG; >> 41 static { >> 42 DEBUG = ... >> 43 } >> >> >> 60, 61 extra space before = >> >> 147 missed {} after if (DEBUG) >> > > Done. > >> * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java >> >> 49 - 61, please fix extra and missed spaces >> >> 64,67 - extra spaces after static >> 81 missed space after (int) >> >> 115,137 - I would prefer to always use {} after if >> >> 212 - multiple missed space before '?' >> >> 271 extra space before return >> > > Done. > >> * >> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java >> >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java >> >> - no comments >> >> -Dmitry >> >> >> On 2014-12-09 21:10, Volker Simonis wrote: >>> Hi, >>> >>> can somebody from the serviceability team please review this webrev? >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>> >>> The shared changes are really all trivial. >>> >>> Thanks, >>> Volker >>> >>> >>> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>>> Hi Sasha, >>>> >>>> thanks for looking at this change. >>>> I'll incorporate your suggestions into the final version. >>>> I'm just waiting for one more review before preparing a new webrev. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>>> You are correct, but there no need to have this code for LE at all. >>>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>>> along with the "#if defined(ppc64)". >>>>>> >>>>>> BTW, a bit on nitpicking in the same file: >>>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>>> + if (endian.equals("big")) >>>>>> + return true; >>>>>> + else >>>>>> + return false; >>>>>> can be rewirtten as >>>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>>> Right. A silly piece of coding there. :-/ >>>>> >>>>> -Maynard >>>>>> >>>>>> >>>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>>> Linux/PPC64 little-endian: >>>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>>> brackets in it should >>>>>>>> read >>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>> instead of just >>>>>>>> #if defined(ppc64) >>>>>>> Hi, Alexander, >>>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>>> place where I think there may be a problem is at line 455: >>>>>>> >>>>>>> -------------------------- >>>>>>> #if defined(ppc64) >>>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>>> // file which doesn't match with the current workflow.) >>>>>>> if (false) { >>>>>>> #else >>>>>>> // Look for a separate debuginfo file. >>>>>>> if (try_debuginfo) { >>>>>>> #endif >>>>>>> -------------------------- >>>>>>> >>>>>>> Here I think we should do as you suggest: >>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>> >>>>>>> -Maynard >>>>>>>> >>>>>>>> Sorry for the late notice. >>>>>>>> Sasha >>>>>>>> >>>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>>> change: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>>> >>>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>>> everything looks fine. >>>>>>>>> >>>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>>> Java). >>>>>>>>> >>>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>>> hotspot repository once the review is completed. >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> Volker >>>>>>>> >>>>>>> >>>>>> >>>>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Dec 17 18:40:52 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 17 Dec 2014 21:40:52 +0300 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5490B87E.7020709@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5489B3B5.1010801@oracle.com> <5489DA1A.1080108@oracle.com> <5489DFF1.7010800@oracle.com> <5490B87E.7020709@oracle.com> Message-ID: <5491CE34.4020900@oracle.com> Stuart, 1. Ever if you set SO_LINGER to zero, socket will not be closed immediately. see TCP shutdown sequence. 2. In a native world it's quite easy to find the port your rmi server uses - it could be achieved by parsing /proc//net/tcp on Linux or using special API on windows and solaris. 3. For rmid and port provided from outside I think the only reliable way to get what you need is: Write a driver that: 1. starts rmid -port 2. connect to this port to make sure rmid is actually started (no rmi, just plain tcp connect) 3. if (2) fail return to (1) 4. run client with this port number. 4. For rmid you can also emulate inetd behaviour - i.e. driver open a server port, communicate it to client than redirect everything that come to this port to stdin of rmid. -Dmitry On 2014-12-17 01:55, Stuart Marks wrote: > Hi Dmitry, > > Strictly speaking you are correct. As soon as you close a socket, there > is a possibility -- perhaps vanishingly small but nonzero -- that you > might not be able to open it again. > > The first scenario, where the user of the socket itself opens the socket > using an ephemeral port (e.g. new ServerSocket(0)) is of course > preferred. This avoids race conditions entirely. > > It's the second case that I'm still wrestling with, and maybe Jaroslav > too. It's fairly difficult to get such "black box" systems to open an > ephemeral port and report it back, as opposed to opening up their > service on some port number handed in from the outside. (For RMI, rmid > is the culprit here. I don't know about JMX.) What makes this difficult > is that the rmid service is running in a separate VM, so getting > reliable information back from it can be difficult. > > It's also fairly difficult to establish the retry logic in such cases. > If the service fails with a BindException, maybe -- maybe -- it was > because there was a conflict over the port, and a retry is warranted. > But this needs to be distinguished from other failure modes that might > occur, that should be reported as failures instead of causing a retry. > In principle, this is possible to do, of course, it's just that it > involves more restructuring of the tests, and possibly adding debug/test > code to rmid. (It may yet come to that.) > > I'm still pondering the reasons that, in the open/close/reopen scenario, > why the reopen might fail. The obvious reason is that some other process > on the system has opened that port between the close and the reopen. I > admit that this is a possibility. However, with the open/close/reopen > scenario in place, we see tests that fail up to 15% of the time with > BindExceptions. This is an extraordinarily high failure rate to be > caused by some random other process happening to open the same port in > the few microseconds between the close and reopen. It's simply not > believable to me. > > My thinking is still that the port isn't ready for reuse until a small > amount of time after it's closed. I have some test programs that > exercise sockets in a particular way (e.g., from multiple threads, or > opening and closing batches of sockets) that can reproduce the problem > on some systems, and these test programs seem to behave better if a time > delay is added between the close and the reopen. The exact circumstances > under which the problem occurs is difficult to pin down and seems OS > specific, and so choosing the "right" delay time is very difficult. But > it does strengthen this conjecture in my mind. > > Naturally it would be better if there were a way to determine when a > port is available for reuse without actually opening it. I'm not aware > of any such way, but I'm holding onto a little hope that one can be found. > > s'marks > > > > On 12/11/14 10:18 AM, Dmitry Samersoff wrote: >> Stuart, >> >> As soon as you close socket, you open a door for the race. >> >> So you need another communication channel to pass a port number (or bind >> result) between a client and a server without closing a socket on the >> server side. >> >> Typical scenario used by network related code is: >> >> 1. Server opens the socket >> 2. Server binds to port(0) >> 3. Server gets port number assigned by OS >> 4. Server informs client (e.g. write the port down to known file, >> broadcast it etc) >> 5. Client establishes connection. >> >> If the server is a blackbox and have to get a port number from outside, >> scenario looks like: >> >> WHILE(!success and !timeout) >> 1. Driver chooses random port number >> 2. Driver runs a server with this number >> 3. Driver checks that server is actually listening on this port >> (e.g. try to connect by it self) >> WEND >> >> 4. Driver runs a client with this port number or bails out with >> descriptive error message. >> >> -Dmitry >> >> On 2014-12-11 20:53, Stuart Marks wrote: >>> >>> >>> On 12/11/14 7:09 AM, olivier.lagneau at oracle.com wrote: >>>> On 11/12/2014 15:43, Dmitry Samersoff wrote: >>>>> You can set SO_LINGER to zero, in this case socket will be closed >>>>> immediately without waiting in TIME_WAIT >>>> SO-LINGER did not help either in my case (see my previous mail to >>>> Jaroslav). >>>> That ended-up in using another hard-coded (supposedly free) port. >>>> Note that was before RMI tests used randomly allocated ports. >>>> >>>>> But there are no reliable way to predict whether you can take this >>>>> port >>>>> or not after you close it. >>>> This is what I observed in my case. >>>>> >>>>> So the only valid solution is to try to connect to a random port >>>>> and if >>>>> this attempt fails try another random port. Everything else will cause >>>>> more or less frequent intermittent failures. >>>> IIRC think this is what is currently done in RMI tests. >>> >>> The RMI tests are still suffering from this problem, unfortunately. >>> >>> The RMI test library gets a "random" port with "new ServerSocket(0)", >>> gets the port number, closes the socket, then returns the port to the >>> caller. The caller then assumes that it can use that port as it wishes. >>> That's when the BindException can occur. There are about 10 RMI test >>> bugs in the database that all seem to have this as their root cause. >>> >>> There is some retry logic in RMI's test library, but that's to avoid the >>> so-called "reserved ports" that specific RMI tests use, or if "new >>> ServerSocket(0)" fails. It doesn't have anything to do with the >>> BindException that occurs when the caller attempts to reuse the port >>> with another socket. >>> >>> My observation is also that setting SO_REUSEADDR has no effect. I >>> haven't tried SO_LINGER. My hunch is that it won't have any effect, >>> since the sockets in question aren't actually going into TIME_WAIT >>> state. But I suppose it's worth a try. >>> >>> I don't have any solution for this; we're still discussing the issue. I >>> think the best approach would be to refactor the code so that the >>> eventual user of the socket opens it up on an ephemeral port in the >>> first place. That avoids the open/close/reopen business. Unfortunately >>> that doesn't help the case where you want to tell another JVM to run a >>> service on a specific port. We don't have a solution for that case yet. >>> >>> The second-best approach (not really a solution) is to open/close a >>> serversocket to get the port, sleep for a little bit, then return the >>> port number to the caller. This might give the kernel a chance to clean >>> up the socket after the close. Of course, this still has a race >>> condition, but it might reduce the incidence of problems to an >>> acceptable level. >>> >>> I'll let you know if we come up with anything better. >>> >>> s'marks >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu Dec 18 08:10:40 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 18 Dec 2014 09:10:40 +0100 Subject: RFR(XS): 8066814: Reduce accessibility in TraceEvent In-Reply-To: <2c9d1e54-7ee2-444d-8ee2-36fefb866f78@default> References: <2c9d1e54-7ee2-444d-8ee2-36fefb866f78@default> Message-ID: <93A84CDA-632F-4A58-A675-A640DE17AF00@oracle.com> Looks good! Thanks, /Staffan > On 17 dec 2014, at 15:45, Markus Gr?nlund wrote: > > Greetings, > > Kindly asking for reviews for the following changeset: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066814 > Webrev: http://cr.openjdk.java.net/~mgronlun/8066814/webrev01/ > > Description: > TraceEvent currently exposes internals unnecessarily. > > Therefore: > > Remove unnecessarily exposed methods. > Add assert for not committing a cancelled event. > Add method stubs for !INCLUDE_TRACE > > Thanks in advance > Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Dec 18 08:12:56 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 18 Dec 2014 09:12:56 +0100 Subject: RFR(S): backport 8039995 and 8061785 changes to SA testcase In-Reply-To: <5491AC1F.6020704@oracle.com> References: <5491AC1F.6020704@oracle.com> Message-ID: <694F0DCD-B3CC-4FD4-B461-D8E443176C8F@oracle.com> Looks good! Thanks, /Staffan > On 17 dec 2014, at 17:15, KEVIN WALLS wrote: > > Hi, > > I'd like a review of a backport of these test changes, into 8u. > > webrev: > http://cr.openjdk.java.net/~kevinw/8039995_8061785/webrev.00/ > > Changes simply hg imported from: > > 8039995 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/da92e4c42b24 > > 8061785 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/3cdb9f480a8c > > > Thanks! > Kevin > > From kevin.walls at oracle.com Thu Dec 18 08:20:05 2014 From: kevin.walls at oracle.com (KEVIN WALLS) Date: Thu, 18 Dec 2014 08:20:05 +0000 Subject: RFR(S): backport 8039995 and 8061785 changes to SA testcase In-Reply-To: <694F0DCD-B3CC-4FD4-B461-D8E443176C8F@oracle.com> References: <5491AC1F.6020704@oracle.com> <694F0DCD-B3CC-4FD4-B461-D8E443176C8F@oracle.com> Message-ID: <54928E35.2000800@oracle.com> Thanks! On 18/12/2014 08:12, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 17 dec 2014, at 17:15, KEVIN WALLS wrote: >> >> Hi, >> >> I'd like a review of a backport of these test changes, into 8u. >> >> webrev: >> http://cr.openjdk.java.net/~kevinw/8039995_8061785/webrev.00/ >> From dmitry.samersoff at oracle.com Thu Dec 18 08:22:15 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 18 Dec 2014 11:22:15 +0300 Subject: RFR(S): backport 8039995 and 8061785 changes to SA testcase In-Reply-To: <5491AC1F.6020704@oracle.com> References: <5491AC1F.6020704@oracle.com> Message-ID: <54928EB7.6050806@oracle.com> Looks good for me! -Dmitry On 2014-12-17 19:15, KEVIN WALLS wrote: > Hi, > > I'd like a review of a backport of these test changes, into 8u. > > webrev: > http://cr.openjdk.java.net/~kevinw/8039995_8061785/webrev.00/ > > Changes simply hg imported from: > > 8039995 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/da92e4c42b24 > > 8061785 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/3cdb9f480a8c > > > Thanks! > Kevin > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu Dec 18 09:31:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 18 Dec 2014 10:31:31 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <5491C61C.1060609@oracle.com> References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> <5491C61C.1060609@oracle.com> Message-ID: Since both Volker and Dmitry have reviewed this, no further reviews are necessary. I took a look at the changes in shared code, anyway, and it looks good. Thanks, /Staffan > On 17 dec 2014, at 19:06, Dmitry Samersoff wrote: > > Volker, > > The changes looks good for me and I'll sponsor the push. > > But please check, whether you need one more reviewer or not. > > -Dmitry > > On 2014-12-17 20:37, Volker Simonis wrote: >> Hi Dmitry, >> >> once again, thanks for your detailed review. You can find the new >> version of the webrev under: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049716.v2/ >> >> I've rebased it to the latest jdk9/hs-rt repository today. >> >> I hope I adressed all your concerns. Please find my additional >> comments inline below: >> >> And I still need a sponsor for pushing this reviewed change. Any volunteers:) >> >> Thank you and best regards, >> Volker >> >>> Below is fist part of review - shared files. >>> >>> >>> * agent/make/Makefile - no comments >>> >>> * agent/src/os/linux/LinuxDebuggerLocal.c - no comments >>> >>> * agent/src/os/linux/symtab.c: >>> >>> 438: >>> - What is the magic of symbols that starts with '.' ? >>> - As far as I understand you are getting indirect value from opd section. >>> >> >> There's already a very detailed descrition of the whole story in >> "hotspot/src/share/vm/utilities/elfFuncDescTable.hpp" and I've added a >> reference to that file in the comment now. >> >>> Could you reformat it a bit to have it better readable? >>> >>> Something like: >>> >>> uintptr_t sym_value; >>> ... >>> symvalue = syms->st_value >>> >>> #ifdef ppc64 >>> // Some comments here >>> // ppc specific code here >>> sym_value = >>> #endif >>> >>> symtab->symbols[j].offset = sym_value - baseaddr; >>> >> >> Good point. Done as suggested by you. >> >>> >>> 454: >>> >>> I appreciate detailed comments here. >>> >>> if (false) can cause unreachable code warning, and unused variable >>> warning so it might be better to add #ifdef ppc64 on caller >>> site at ll. 516 and leave here only a comment. >>> >>> But if you decide to guard against try_debuginfo please replace >>> >>> if (false) >>> >>> to >>> >>> goto quit >>> >> >> I think there's already a comment in place. The problem is that the >> debuginfo file only has an empty .opd section. So if we would use the >> debuginfo file for symbol resolution we would still need the .opd >> section from the regular library. This doesn't fit in the current >> function work flow which only uses ELF data from a single file and I >> didn?t wanted to change that. >> >> But your suggestion of using 'goto quit' is good and I've used that version. >> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java >>> >>> 38: return (endian.equals("big")); >>> >>> is enough >>> >> >> I've used the even shorter version proposed by Alexander Smundak: >> >> return "big".equals(System.getProperty("sun.cpu.endian")) >> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java >>> - no comments >>> >>> * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments >>> >>> * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments >>> >>> * make/linux/makefiles/sa.make - no comments >>> >>> * make/sa.files - no comments >>> >>> * src/share/vm/runtime/vmStructs.cpp >>> - no comments >>> >> >>> This is part two of review. Code looks good for me, only minor nits. >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: >>> >>> 41 missed space around = >>> 51 extra space between pc >>> >> >> Done. >> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java >>> >>> >>> - no comments >>> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java >>> >>> 47, 48 extra space before = >>> >> >> Done. >> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java >>> >>> 34 extra space before id >>> 42 extra space before = , >> >> Done. >> >>> it might be better to create a constant for size of integer. >>> >> >> I agree, but this code was just copied from the corresponding AMD64 >> version and as far as I can see all the other architectures do it the >> same way so I didn't change it. >> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java >>> >>> - no comments >>> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java >>> >>> -no comments >>> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java >>> >>> 43 missed space before ? >>> it might be be better to reformat this line to usual if and add comments >>> >> >> The same here - this is copied code. But I've adjusted it to at least >> match with the other platforms. >> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java >>> >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java >>> >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java >>> >>> >>> 57, 58 extra space before = >>> >>> 63 and below extra space after public >>> >>> 108 unaligned comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java >>> >>> 49 Formatting in PPC64Frame.java looks much better for me. >>> >>> 40 private static final boolean DEBUG; >>> 41 static { >>> 42 DEBUG = ... >>> 43 } >>> >>> >>> 60, 61 extra space before = >>> >>> 147 missed {} after if (DEBUG) >>> >> >> Done. >> >>> * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java >>> >>> 49 - 61, please fix extra and missed spaces >>> >>> 64,67 - extra spaces after static >>> 81 missed space after (int) >>> >>> 115,137 - I would prefer to always use {} after if >>> >>> 212 - multiple missed space before '?' >>> >>> 271 extra space before return >>> >> >> Done. >> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java >>> >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java >>> >>> - no comments >>> >>> -Dmitry >>> >>> >>> On 2014-12-09 21:10, Volker Simonis wrote: >>>> Hi, >>>> >>>> can somebody from the serviceability team please review this webrev? >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>> >>>> The shared changes are really all trivial. >>>> >>>> Thanks, >>>> Volker >>>> >>>> >>>> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>>>> Hi Sasha, >>>>> >>>>> thanks for looking at this change. >>>>> I'll incorporate your suggestions into the final version. >>>>> I'm just waiting for one more review before preparing a new webrev. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>>>> You are correct, but there no need to have this code for LE at all. >>>>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>>>> along with the "#if defined(ppc64)". >>>>>>> >>>>>>> BTW, a bit on nitpicking in the same file: >>>>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>>>> + if (endian.equals("big")) >>>>>>> + return true; >>>>>>> + else >>>>>>> + return false; >>>>>>> can be rewirtten as >>>>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>>>> Right. A silly piece of coding there. :-/ >>>>>> >>>>>> -Maynard >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>>>> Linux/PPC64 little-endian: >>>>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>>>> brackets in it should >>>>>>>>> read >>>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>>> instead of just >>>>>>>>> #if defined(ppc64) >>>>>>>> Hi, Alexander, >>>>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>>>> place where I think there may be a problem is at line 455: >>>>>>>> >>>>>>>> -------------------------- >>>>>>>> #if defined(ppc64) >>>>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>>>> // file which doesn't match with the current workflow.) >>>>>>>> if (false) { >>>>>>>> #else >>>>>>>> // Look for a separate debuginfo file. >>>>>>>> if (try_debuginfo) { >>>>>>>> #endif >>>>>>>> -------------------------- >>>>>>>> >>>>>>>> Here I think we should do as you suggest: >>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>> >>>>>>>> -Maynard >>>>>>>>> >>>>>>>>> Sorry for the late notice. >>>>>>>>> Sasha >>>>>>>>> >>>>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>>>> change: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>>>> >>>>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>>>> everything looks fine. >>>>>>>>>> >>>>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>>>> Java). >>>>>>>>>> >>>>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>>>> hotspot repository once the review is completed. >>>>>>>>>> >>>>>>>>>> Thank you and best regards, >>>>>>>>>> Volker >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>> >>> >>> -- >>> 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 volker.simonis at gmail.com Thu Dec 18 09:38:38 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 18 Dec 2014 10:38:38 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> <5491C61C.1060609@oracle.com> Message-ID: Great Staffan! Thanks a lot, Volker On Thu, Dec 18, 2014 at 10:31 AM, Staffan Larsen wrote: > Since both Volker and Dmitry have reviewed this, no further reviews are necessary. I took a look at the changes in shared code, anyway, and it looks good. > > Thanks, > /Staffan > >> On 17 dec 2014, at 19:06, Dmitry Samersoff wrote: >> >> Volker, >> >> The changes looks good for me and I'll sponsor the push. >> >> But please check, whether you need one more reviewer or not. >> >> -Dmitry >> >> On 2014-12-17 20:37, Volker Simonis wrote: >>> Hi Dmitry, >>> >>> once again, thanks for your detailed review. You can find the new >>> version of the webrev under: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049716.v2/ >>> >>> I've rebased it to the latest jdk9/hs-rt repository today. >>> >>> I hope I adressed all your concerns. Please find my additional >>> comments inline below: >>> >>> And I still need a sponsor for pushing this reviewed change. Any volunteers:) >>> >>> Thank you and best regards, >>> Volker >>> >>>> Below is fist part of review - shared files. >>>> >>>> >>>> * agent/make/Makefile - no comments >>>> >>>> * agent/src/os/linux/LinuxDebuggerLocal.c - no comments >>>> >>>> * agent/src/os/linux/symtab.c: >>>> >>>> 438: >>>> - What is the magic of symbols that starts with '.' ? >>>> - As far as I understand you are getting indirect value from opd section. >>>> >>> >>> There's already a very detailed descrition of the whole story in >>> "hotspot/src/share/vm/utilities/elfFuncDescTable.hpp" and I've added a >>> reference to that file in the comment now. >>> >>>> Could you reformat it a bit to have it better readable? >>>> >>>> Something like: >>>> >>>> uintptr_t sym_value; >>>> ... >>>> symvalue = syms->st_value >>>> >>>> #ifdef ppc64 >>>> // Some comments here >>>> // ppc specific code here >>>> sym_value = >>>> #endif >>>> >>>> symtab->symbols[j].offset = sym_value - baseaddr; >>>> >>> >>> Good point. Done as suggested by you. >>> >>>> >>>> 454: >>>> >>>> I appreciate detailed comments here. >>>> >>>> if (false) can cause unreachable code warning, and unused variable >>>> warning so it might be better to add #ifdef ppc64 on caller >>>> site at ll. 516 and leave here only a comment. >>>> >>>> But if you decide to guard against try_debuginfo please replace >>>> >>>> if (false) >>>> >>>> to >>>> >>>> goto quit >>>> >>> >>> I think there's already a comment in place. The problem is that the >>> debuginfo file only has an empty .opd section. So if we would use the >>> debuginfo file for symbol resolution we would still need the .opd >>> section from the regular library. This doesn't fit in the current >>> function work flow which only uses ELF data from a single file and I >>> didn?t wanted to change that. >>> >>> But your suggestion of using 'goto quit' is good and I've used that version. >>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java >>>> >>>> 38: return (endian.equals("big")); >>>> >>>> is enough >>>> >>> >>> I've used the even shorter version proposed by Alexander Smundak: >>> >>> return "big".equals(System.getProperty("sun.cpu.endian")) >>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java >>>> - no comments >>>> >>>> * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments >>>> >>>> * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments >>>> >>>> * make/linux/makefiles/sa.make - no comments >>>> >>>> * make/sa.files - no comments >>>> >>>> * src/share/vm/runtime/vmStructs.cpp >>>> - no comments >>>> >>> >>>> This is part two of review. Code looks good for me, only minor nits. >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: >>>> >>>> 41 missed space around = >>>> 51 extra space between pc >>>> >>> >>> Done. >>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java >>>> >>>> >>>> - no comments >>>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java >>>> >>>> 47, 48 extra space before = >>>> >>> >>> Done. >>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java >>>> >>>> 34 extra space before id >>>> 42 extra space before = , >>> >>> Done. >>> >>>> it might be better to create a constant for size of integer. >>>> >>> >>> I agree, but this code was just copied from the corresponding AMD64 >>> version and as far as I can see all the other architectures do it the >>> same way so I didn't change it. >>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java >>>> >>>> - no comments >>>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java >>>> >>>> -no comments >>>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java >>>> >>>> 43 missed space before ? >>>> it might be be better to reformat this line to usual if and add comments >>>> >>> >>> The same here - this is copied code. But I've adjusted it to at least >>> match with the other platforms. >>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java >>>> >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java >>>> >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java >>>> >>>> >>>> 57, 58 extra space before = >>>> >>>> 63 and below extra space after public >>>> >>>> 108 unaligned comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java >>>> >>>> 49 Formatting in PPC64Frame.java looks much better for me. >>>> >>>> 40 private static final boolean DEBUG; >>>> 41 static { >>>> 42 DEBUG = ... >>>> 43 } >>>> >>>> >>>> 60, 61 extra space before = >>>> >>>> 147 missed {} after if (DEBUG) >>>> >>> >>> Done. >>> >>>> * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java >>>> >>>> 49 - 61, please fix extra and missed spaces >>>> >>>> 64,67 - extra spaces after static >>>> 81 missed space after (int) >>>> >>>> 115,137 - I would prefer to always use {} after if >>>> >>>> 212 - multiple missed space before '?' >>>> >>>> 271 extra space before return >>>> >>> >>> Done. >>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java >>>> >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java >>>> >>>> - no comments >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-12-09 21:10, Volker Simonis wrote: >>>>> Hi, >>>>> >>>>> can somebody from the serviceability team please review this webrev? >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>> >>>>> The shared changes are really all trivial. >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>>>>> Hi Sasha, >>>>>> >>>>>> thanks for looking at this change. >>>>>> I'll incorporate your suggestions into the final version. >>>>>> I'm just waiting for one more review before preparing a new webrev. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>>>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>>>>> You are correct, but there no need to have this code for LE at all. >>>>>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>>>>> along with the "#if defined(ppc64)". >>>>>>>> >>>>>>>> BTW, a bit on nitpicking in the same file: >>>>>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>>>>> + if (endian.equals("big")) >>>>>>>> + return true; >>>>>>>> + else >>>>>>>> + return false; >>>>>>>> can be rewirtten as >>>>>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>>>>> Right. A silly piece of coding there. :-/ >>>>>>> >>>>>>> -Maynard >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>>>>> Linux/PPC64 little-endian: >>>>>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>>>>> brackets in it should >>>>>>>>>> read >>>>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>>>> instead of just >>>>>>>>>> #if defined(ppc64) >>>>>>>>> Hi, Alexander, >>>>>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>>>>> place where I think there may be a problem is at line 455: >>>>>>>>> >>>>>>>>> -------------------------- >>>>>>>>> #if defined(ppc64) >>>>>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>>>>> // file which doesn't match with the current workflow.) >>>>>>>>> if (false) { >>>>>>>>> #else >>>>>>>>> // Look for a separate debuginfo file. >>>>>>>>> if (try_debuginfo) { >>>>>>>>> #endif >>>>>>>>> -------------------------- >>>>>>>>> >>>>>>>>> Here I think we should do as you suggest: >>>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>>> >>>>>>>>> -Maynard >>>>>>>>>> >>>>>>>>>> Sorry for the late notice. >>>>>>>>>> Sasha >>>>>>>>>> >>>>>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>>>>> change: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>>>>> >>>>>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>>>>> everything looks fine. >>>>>>>>>>> >>>>>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>>>>> Java). >>>>>>>>>>> >>>>>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>>>>> hotspot repository once the review is completed. >>>>>>>>>>> >>>>>>>>>>> Thank you and best regards, >>>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>> >>>> >>>> -- >>>> 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 jaroslav.bachorik at oracle.com Thu Dec 18 14:29:37 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 18 Dec 2014 15:29:37 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5489AD7F.7090200@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> Message-ID: <5492E4D1.7040501@oracle.com> On 12/11/2014 03:43 PM, Dmitry Samersoff wrote: > Jaroslav, > > You can set SO_LINGER to zero, in this case socket will be closed > immediately without waiting in TIME_WAIT > > But there are no reliable way to predict whether you can take this port > or not after you close it. > > So the only valid solution is to try to connect to a random port and if > this attempt fails try another random port. Everything else will cause > more or less frequent intermittent failures. Thanks for all the suggestions! http://cr.openjdk.java.net/~jbachorik/8066708/webrev.02 I've enhanced the original patch with the retry logic using different random port if starting the JMX agent on the provided port fails with BindException. I'm keeping there the changes for properly closing the ports opened for the test purposes and also setting the SO_REUSEADDR - anyway, it does not make sense to reuse the ephemeral test ports. I've split the original "test_06" test case in order to keep it readable even with the new retry logic - and also to make each test case to test just one scenario. Cheers, -JB- > > -Dmitry > > > On 2014-12-11 17:06, Jaroslav Bachorik wrote: >> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >>> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>>> >>>>> The test fails very intermittently when RMI registry is trying to bind >>>>> to a port >>>>> previously used in the test (via ServerSocket). >>>>> >>>>> This seems to be caused by the sockets created via `new >>>>> ServerSocket(0)` and >>>>> being in reusable mode. The fix attempts to prevent this by explicitly >>>>> forbidding the reusable mode. >>>> >>>> Hi Jaroslav, >>>> >>>> I happened to see this fly by, and there are (I think) some similar >>>> issues going on in the RMI tests. >>>> >>>> But first I'll note that I don't think setReuseAddress() will have the >>>> effect that you want. Typically it's set to true before binding a >>>> socket, so that a subsequent bind operation will succeed even if the >>>> address/port is already in use. ServerSockets created with new >>>> ServerSocket(0) are already bound, and I'm not sure what calling >>>> setReuseAddress(false) will do on such sockets. The spec says behavior >>>> is undefined, but my bet is that it does nothing. >>>> >>>> I guess it doesn't hurt to try this out to see if it makes a difference, >>>> but I don't have much confidence it will help. >>>> >>>> The potential similarity to the RMI tests is exemplified by JDK-8049202 >>>> (sorry, this bug report isn't open) but briefly this tests the RMI >>>> registry as follows: >>>> >>>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>>> RMI registry port] in order to ensure that 1099 isn't in use by >>>> something else already; >>>> >>>> 2. If this succeeds, it immediately closes the ServerSocket. >>>> >>>> 3. Then it creates a new RMI registry on port 1099. >>>> >>>> In principle, this should succeed, yet it fails around 10% of the time >>>> on some systems. The error is "port already in use". My best theory is >>>> that even though the socket has just been closed by a user program, the >>>> kernel has to run the socket through some of the socket states such as >>>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually closed >>>> and is available for reuse. If a program -- even the same one -- >>>> attempts to open a socket on the same port before the socket has reached >>>> its final state, it will get an "already in use error". >>>> >>>> If this is true I don't believe that setting SO_REUSEADDR will work if >>>> the socket is in one of these final states. (I remember reading this >>>> somewhere but I'm not sure where at the moment. I can try to dig it up >>>> if there is interest.) >>>> >>>> I admit this is just a theory and I'm open to alternatives, and I'm also >>>> open to hearing about ways to deal with this problem. >>>> >>>> Could something similar be going on with this JMX test? >>> >>> Hm, this is exactly what happened with this test :( >>> >>> The problem is that the port is reported as available while it is still >>> occupied and RMI registry attempts to start using that port. >>> >>> If setting SO_REUSEADDR does not work then the only solution would be to >>> retry the test case when this exception occurs. >> >> Further investigation shows that the problem was rather the client >> connecting to a socket being shut down. >> >> It sounds like setting SO_REUSEADDR to false should prevent this failure. >> >> From the ServerSocket javadoc: >> "When a TCP connection is closed the connection may remain in a timeout >> state for a period of time after the connection is closed (typically >> known as the TIME_WAIT state or 2MSL wait state). For applications using >> a well known socket address or port it may not be possible to bind a >> socket to the required SocketAddress if there is a connection in the >> timeout state involving the socket address or port." >> >> It also turns out that the test does not close the server sockets >> properly so there might be several sockets being opened or timed out >> dangling around. >> >> I've updated the test so it is setting SO_REUSEADDR for all the new >> ServerSockets instances + introduced the mechanism to run the test code >> while properly cleaning up any allocated ports. >> >> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ >> >> -JB- >> >>> >>> -JB- >>> >>>> >>>> s'marks >>> >> > > From coleen.phillimore at oracle.com Thu Dec 18 19:23:11 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 18 Dec 2014 14:23:11 -0500 Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <5491BCB9.10505@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> Message-ID: <5493299F.60005@oracle.com> Hi Serguei, Thank you for making the patches an optional field. http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html 198 if (!patched()) { 199 assert(false, "a pseudo-string map may exists for patched CP only"); 200 return 0; 201 } Why not assert(patched(), "a pseud-string map must exist for patched CP only"); Why is this? Is this really a ShouldNotReachHere? should it be false? 215 assert(true, "not found a matching entry in pseudo-string map"); http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html Don't you have to move the value of the patched field from the old constant pool to the new one? I hate to ask but is there merging that needs to be done? I don't know how to write this test case though. Is it possible to redefine a class with a constant pool patches with another that has constant pool patches? Somehow I thought you'd have to save the value of the cp_patches oops passed in. So I was wondering why you can't change this instead: bool is_pseudo_string_at(int which) { // A pseudo string is a string that doesn't have a symbol in the cpSlot - return unresolved_string_at(which) == NULL; + return (strncmp(unresolved_string_at(which)->as_utf8(), "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); } And the asserts in the other functions below it. Coleen On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: > Please, review the second round fix for: > https://bugs.openjdk.java.net/browse/JDK-8008678 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ > > > Summary: > > This fix implements a footprint saving approach suggested by Coleen. > To be able to reconstitute a class constant pool, an intermediate > pseudo-string map is used. > Now, this field is accounted optionally, only if the 'cp_patches' is > provided in the > ClassFileParser::parseClassFile() before ConstantPool is allocated. > This fix is not elegant, even a little bit ugly, but it is the only > way I see so far. > > Unfortunately, this approach did not help much to make some other > fields (eg., 'operands') optional. > The problem is that we have to account optional fields before > parsing, at the CP allocation time. > It is possible to re-allocate the ConstantPool when any > InvokeDynamic bytecode is discovered, > but it looks too complicated. > > Testing: > - the unit test from bug report > - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument > - vm.mlvm.testlist, vm.quick.testlist, > vm.parallel_class_loading.testlist (in progress) > > > Thanks, > Serguei > > > On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> Thank you for looking at this! >> I'll check how this can be improved. >> It is my concern too. >> >> Thanks, >> Serguei >> >> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>> >>> Serguei, >>> I had a quick look at this. I was wondering if we could make the >>> pseudo_string_map conditional in ConstantPool and not make all >>> classes pay in footprint for this field? The same thing probably >>> could be done for operands too. There are flags that you can set to >>> conditionally add a pointer to base() in this function. >>> >>> Typical C++ would subclass ConstantPool to add >>> InvokeDynamicConstantPool fields, but this is not typical C++ so the >>> trick we use is like the one in ConstMethod. I think it's worth >>> doing in this case. >>> >>> Thanks, >>> Coleen >>> >>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>> >>>> >>>> >>>> Summary: >>>> The pseudo-strings are currently not supported in reconstitution >>>> of constant pool. >>>> >>>> This is an explanation from John Rose about what the >>>> pseudo-strings are: >>>> >>>> "We still need "live" oop constants pre-linked into the constant >>>> pool of bytecodes which >>>> implement some method handles. We use the anonymous class >>>> pseudo-string feature for that. >>>> The relevant code is here: >>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>> >>>> These oops are what "pseudo-strings" are. >>>> The odd name refers to the fact that, even though they are >>>> random oops, they appear in the constant pool >>>> where one would expect (because of class file syntax) to find a >>>> string." >>>> ... >>>> If you really wanted to reconstitute a class file for an >>>> anonymous class, and >>>> if that class has oop patching (pseudo-strings), you would need >>>> either to (a) reconstitute the patches array >>>> handed to Unsafe.defineAnonymousClass, or (b) accept whatever >>>> odd strings were there first, as an approximation. >>>> The "odd strings" are totally insignificant, and are typically >>>> something like "CONSTANT_PLACEHOLDER_42" >>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>> >>>> >>>> Reconstitution of the ConstantPool is needed for both the JVMTI >>>> GetConstantPool() and RetransformClasses(). >>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>> >>>> The problem is that a pseudo-string is a patched string that >>>> does not have >>>> a reference to the string symbol anymore: >>>> unresolved_string_at(idx) == NULL >>>> >>>> The fix is to create and fill in a map from JVM_CONSTANT_String >>>> cp index to the JVM_CONSTANT_Utf8 cp index >>>> to be able to restore this assotiation in the >>>> JvmtiConstantPoolReconstituter. >>>> >>>> Testing: >>>> Run: >>>> - java/lang/instrument tests >>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>> >>>> >>>> Thanks, >>>> Serguei >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Dec 18 22:00:19 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 18 Dec 2014 14:00:19 -0800 Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <5493299F.60005@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> Message-ID: <54934E73.4080808@oracle.com> Hi Coleen, Thank you for reviewing! On 12/18/14 11:23 AM, Coleen Phillimore wrote: > > Hi Serguei, > > Thank you for making the patches an optional field. > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html > 198 if (!patched()) { > 199 assert(false, "a pseudo-string map may exists for patched CP only"); > 200 return 0; > 201 } > Why not > assert(patched(), "a pseud-string map must exist for > patched CP only"); Wanted it to be more reliable but it looks pointless. Will make this change. > > > Why is this? Is this really a ShouldNotReachHere? should it be false? > > 215 assert(true, "not found a matching entry in pseudo-string map"); A typo, must be false. It is the last minute change. Thanks for the catch! > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html > > Don't you have to move the value of the patched field from the old > constant pool to the new one? I hate to ask but is there merging that > needs to be done? I don't know how to write this test case though. > Is it possible to redefine a class with a constant pool patches with > another that has constant pool patches? Thank you for asking this question. If I understand correctly, the patching comes from the compiler side for anonymous classes only. I saw it for LambdaForm's only. I think, the patching can not be changed with a retransformation. But I'm not sure if it can not be changed with a redefinition. But if it can - then it would be safe to merge the 'patched' condition, i.e. make it patched if either the_class or scratch class is patched. > > Somehow I thought you'd have to save the value of the cp_patches oops > passed in. > > So I was wondering why you can't change this instead: > > bool is_pseudo_string_at(int which) { > // A pseudo string is a string that doesn't have a symbol in the > cpSlot > - return unresolved_string_at(which) == NULL; > + return (strncmp(unresolved_string_at(which)->as_utf8(), > "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); > } I was thinking about the same but was not sure if it would work for the compiler team. We have to ask John about this (added John and Christian to the cc-list). This question to John was in my plan! :) The beauty of the above approach is that there is no need to create an intermediate pseudo-string map and most of the code in from this webrev is not needed. Thanks, Serguei > > And the asserts in the other functions below it. > > Coleen > > > On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the second round fix for: >> https://bugs.openjdk.java.net/browse/JDK-8008678 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >> >> >> Summary: >> >> This fix implements a footprint saving approach suggested by Coleen. >> To be able to reconstitute a class constant pool, an intermediate >> pseudo-string map is used. >> Now, this field is accounted optionally, only if the 'cp_patches' >> is provided in the >> ClassFileParser::parseClassFile() before ConstantPool is allocated. >> This fix is not elegant, even a little bit ugly, but it is the only >> way I see so far. >> >> Unfortunately, this approach did not help much to make some other >> fields (eg., 'operands') optional. >> The problem is that we have to account optional fields before >> parsing, at the CP allocation time. >> It is possible to re-allocate the ConstantPool when any >> InvokeDynamic bytecode is discovered, >> but it looks too complicated. >> >> Testing: >> - the unit test from bug report >> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >> - vm.mlvm.testlist, vm.quick.testlist, >> vm.parallel_class_loading.testlist (in progress) >> >> >> Thanks, >> Serguei >> >> >> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>> Coleen, >>> >>> Thank you for looking at this! >>> I'll check how this can be improved. >>> It is my concern too. >>> >>> Thanks, >>> Serguei >>> >>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>> >>>> Serguei, >>>> I had a quick look at this. I was wondering if we could make the >>>> pseudo_string_map conditional in ConstantPool and not make all >>>> classes pay in footprint for this field? The same thing probably >>>> could be done for operands too. There are flags that you can set >>>> to conditionally add a pointer to base() in this function. >>>> >>>> Typical C++ would subclass ConstantPool to add >>>> InvokeDynamicConstantPool fields, but this is not typical C++ so >>>> the trick we use is like the one in ConstMethod. I think it's >>>> worth doing in this case. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>> >>>>> >>>>> >>>>> Summary: >>>>> The pseudo-strings are currently not supported in >>>>> reconstitution of constant pool. >>>>> >>>>> This is an explanation from John Rose about what the >>>>> pseudo-strings are: >>>>> >>>>> "We still need "live" oop constants pre-linked into the >>>>> constant pool of bytecodes which >>>>> implement some method handles. We use the anonymous class >>>>> pseudo-string feature for that. >>>>> The relevant code is here: >>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>> >>>>> These oops are what "pseudo-strings" are. >>>>> The odd name refers to the fact that, even though they are >>>>> random oops, they appear in the constant pool >>>>> where one would expect (because of class file syntax) to find >>>>> a string." >>>>> ... >>>>> If you really wanted to reconstitute a class file for an >>>>> anonymous class, and >>>>> if that class has oop patching (pseudo-strings), you would >>>>> need either to (a) reconstitute the patches array >>>>> handed to Unsafe.defineAnonymousClass, or (b) accept whatever >>>>> odd strings were there first, as an approximation. >>>>> The "odd strings" are totally insignificant, and are typically >>>>> something like "CONSTANT_PLACEHOLDER_42" >>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>> >>>>> >>>>> Reconstitution of the ConstantPool is needed for both the JVMTI >>>>> GetConstantPool() and RetransformClasses(). >>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>> >>>>> The problem is that a pseudo-string is a patched string that >>>>> does not have >>>>> a reference to the string symbol anymore: >>>>> unresolved_string_at(idx) == NULL >>>>> >>>>> The fix is to create and fill in a map from JVM_CONSTANT_String >>>>> cp index to the JVM_CONSTANT_Utf8 cp index >>>>> to be able to restore this assotiation in the >>>>> JvmtiConstantPoolReconstituter. >>>>> >>>>> Testing: >>>>> Run: >>>>> - java/lang/instrument tests >>>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Dec 18 22:23:04 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 18 Dec 2014 14:23:04 -0800 Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54934E73.4080808@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> Message-ID: <549353C8.9000706@oracle.com> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Thank you for reviewing! > > > On 12/18/14 11:23 AM, Coleen Phillimore wrote: >> >> Hi Serguei, >> >> Thank you for making the patches an optional field. >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >> 198 if (!patched()) { >> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >> 200 return 0; >> 201 } >> Why not >> assert(patched(), "a pseud-string map must exist for >> patched CP only"); > > Wanted it to be more reliable but it looks pointless. > Will make this change. > >> >> >> Why is this? Is this really a ShouldNotReachHere? should it be false? >> >> 215 assert(true, "not found a matching entry in pseudo-string map"); > > > A typo, must be false. > It is the last minute change. > Thanks for the catch! > > >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >> >> Don't you have to move the value of the patched field from the old >> constant pool to the new one? I hate to ask but is there merging >> that needs to be done? I don't know how to write this test case >> though. Is it possible to redefine a class with a constant pool >> patches with another that has constant pool patches? > > Thank you for asking this question. > If I understand correctly, the patching comes from the compiler side > for anonymous classes only. > I saw it for LambdaForm's only. > I think, the patching can not be changed with a retransformation. > But I'm not sure if it can not be changed with a redefinition. > > But if it can - then it would be safe to merge the 'patched' > condition, i.e. make it patched > if either the_class or scratch class is patched. > >> >> Somehow I thought you'd have to save the value of the cp_patches oops >> passed in. Forgot to answer this good question. If the cp_patches can be changed with a class redefinition (it, probably, can) then it needs to be saved and merged too. Can we separate this cp_patches merge issue into another bug or RFE? The need still has to be clarified though, I'll check this with John. Thanks, Serguei >> >> So I was wondering why you can't change this instead: >> >> bool is_pseudo_string_at(int which) { >> // A pseudo string is a string that doesn't have a symbol in the >> cpSlot >> - return unresolved_string_at(which) == NULL; >> + return (strncmp(unresolved_string_at(which)->as_utf8(), >> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >> } > > I was thinking about the same but was not sure if it would work for > the compiler team. > We have to ask John about this (added John and Christian to the cc-list). > This question to John was in my plan! :) > > The beauty of the above approach is that there is no need to create an > intermediate > pseudo-string map and most of the code in from this webrev is not needed. > > > Thanks, > Serguei > >> >> And the asserts in the other functions below it. >> >> Coleen >> >> >> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the second round fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>> >>> >>> Summary: >>> >>> This fix implements a footprint saving approach suggested by Coleen. >>> To be able to reconstitute a class constant pool, an intermediate >>> pseudo-string map is used. >>> Now, this field is accounted optionally, only if the 'cp_patches' >>> is provided in the >>> ClassFileParser::parseClassFile() before ConstantPool is allocated. >>> This fix is not elegant, even a little bit ugly, but it is the >>> only way I see so far. >>> >>> Unfortunately, this approach did not help much to make some other >>> fields (eg., 'operands') optional. >>> The problem is that we have to account optional fields before >>> parsing, at the CP allocation time. >>> It is possible to re-allocate the ConstantPool when any >>> InvokeDynamic bytecode is discovered, >>> but it looks too complicated. >>> >>> Testing: >>> - the unit test from bug report >>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>> - vm.mlvm.testlist, vm.quick.testlist, >>> vm.parallel_class_loading.testlist (in progress) >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>> Coleen, >>>> >>>> Thank you for looking at this! >>>> I'll check how this can be improved. >>>> It is my concern too. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>> >>>>> Serguei, >>>>> I had a quick look at this. I was wondering if we could make the >>>>> pseudo_string_map conditional in ConstantPool and not make all >>>>> classes pay in footprint for this field? The same thing probably >>>>> could be done for operands too. There are flags that you can set >>>>> to conditionally add a pointer to base() in this function. >>>>> >>>>> Typical C++ would subclass ConstantPool to add >>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so >>>>> the trick we use is like the one in ConstMethod. I think it's >>>>> worth doing in this case. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> The pseudo-strings are currently not supported in >>>>>> reconstitution of constant pool. >>>>>> >>>>>> This is an explanation from John Rose about what the >>>>>> pseudo-strings are: >>>>>> >>>>>> "We still need "live" oop constants pre-linked into the >>>>>> constant pool of bytecodes which >>>>>> implement some method handles. We use the anonymous class >>>>>> pseudo-string feature for that. >>>>>> The relevant code is here: >>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>> >>>>>> These oops are what "pseudo-strings" are. >>>>>> The odd name refers to the fact that, even though they are >>>>>> random oops, they appear in the constant pool >>>>>> where one would expect (because of class file syntax) to find >>>>>> a string." >>>>>> ... >>>>>> If you really wanted to reconstitute a class file for an >>>>>> anonymous class, and >>>>>> if that class has oop patching (pseudo-strings), you would >>>>>> need either to (a) reconstitute the patches array >>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept whatever >>>>>> odd strings were there first, as an approximation. >>>>>> The "odd strings" are totally insignificant, and are >>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>> >>>>>> >>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>> >>>>>> The problem is that a pseudo-string is a patched string that >>>>>> does not have >>>>>> a reference to the string symbol anymore: >>>>>> unresolved_string_at(idx) == NULL >>>>>> >>>>>> The fix is to create and fill in a map from >>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>> to be able to restore this assotiation in the >>>>>> JvmtiConstantPoolReconstituter. >>>>>> >>>>>> Testing: >>>>>> Run: >>>>>> - java/lang/instrument tests >>>>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Dec 18 23:01:59 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 18 Dec 2014 18:01:59 -0500 Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <549353C8.9000706@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <549353C8.9000706@oracle.com> Message-ID: <54935CE7.2020400@oracle.com> On 12/18/14, 5:23 PM, serguei.spitsyn at oracle.com wrote: > On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Thank you for reviewing! >> >> >> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>> >>> Hi Serguei, >>> >>> Thank you for making the patches an optional field. >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>> 198 if (!patched()) { >>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>> 200 return 0; >>> 201 } >>> Why not >>> assert(patched(), "a pseud-string map must exist for >>> patched CP only"); >> >> Wanted it to be more reliable but it looks pointless. >> Will make this change. >> >>> >>> >>> Why is this? Is this really a ShouldNotReachHere? should it be false? >>> >>> 215 assert(true, "not found a matching entry in pseudo-string map"); >> >> >> A typo, must be false. >> It is the last minute change. >> Thanks for the catch! >> >> >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>> >>> Don't you have to move the value of the patched field from the old >>> constant pool to the new one? I hate to ask but is there merging >>> that needs to be done? I don't know how to write this test case >>> though. Is it possible to redefine a class with a constant pool >>> patches with another that has constant pool patches? >> >> Thank you for asking this question. >> If I understand correctly, the patching comes from the compiler side >> for anonymous classes only. >> I saw it for LambdaForm's only. >> I think, the patching can not be changed with a retransformation. >> But I'm not sure if it can not be changed with a redefinition. >> >> But if it can - then it would be safe to merge the 'patched' >> condition, i.e. make it patched >> if either the_class or scratch class is patched. >> >>> >>> Somehow I thought you'd have to save the value of the cp_patches >>> oops passed in. > > Forgot to answer this good question. > > If the cp_patches can be changed with a class redefinition (it, > probably, can) > then it needs to be saved and merged too. > Can we separate this cp_patches merge issue into another bug or RFE? > The need still has to be clarified though, I'll check this with John. Yes, it seems good to have a follow up bug for this once the requirement is understood. It may be a fair bit of work. Thanks, Coleen > > > Thanks, > Serguei > > >>> >>> So I was wondering why you can't change this instead: >>> >>> bool is_pseudo_string_at(int which) { >>> // A pseudo string is a string that doesn't have a symbol in the >>> cpSlot >>> - return unresolved_string_at(which) == NULL; >>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>> } >> >> I was thinking about the same but was not sure if it would work for >> the compiler team. >> We have to ask John about this (added John and Christian to the cc-list). >> This question to John was in my plan! :) >> >> The beauty of the above approach is that there is no need to create >> an intermediate >> pseudo-string map and most of the code in from this webrev is not needed. >> >> >> Thanks, >> Serguei >> >>> >>> And the asserts in the other functions below it. >>> >>> Coleen >>> >>> >>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the second round fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>> >>>> >>>> Summary: >>>> >>>> This fix implements a footprint saving approach suggested by Coleen. >>>> To be able to reconstitute a class constant pool, an intermediate >>>> pseudo-string map is used. >>>> Now, this field is accounted optionally, only if the 'cp_patches' >>>> is provided in the >>>> ClassFileParser::parseClassFile() before ConstantPool is allocated. >>>> This fix is not elegant, even a little bit ugly, but it is the >>>> only way I see so far. >>>> >>>> Unfortunately, this approach did not help much to make some other >>>> fields (eg., 'operands') optional. >>>> The problem is that we have to account optional fields before >>>> parsing, at the CP allocation time. >>>> It is possible to re-allocate the ConstantPool when any >>>> InvokeDynamic bytecode is discovered, >>>> but it looks too complicated. >>>> >>>> Testing: >>>> - the unit test from bug report >>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>>> - vm.mlvm.testlist, vm.quick.testlist, >>>> vm.parallel_class_loading.testlist (in progress) >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>> Coleen, >>>>> >>>>> Thank you for looking at this! >>>>> I'll check how this can be improved. >>>>> It is my concern too. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Serguei, >>>>>> I had a quick look at this. I was wondering if we could make the >>>>>> pseudo_string_map conditional in ConstantPool and not make all >>>>>> classes pay in footprint for this field? The same thing probably >>>>>> could be done for operands too. There are flags that you can set >>>>>> to conditionally add a pointer to base() in this function. >>>>>> >>>>>> Typical C++ would subclass ConstantPool to add >>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so >>>>>> the trick we use is like the one in ConstMethod. I think it's >>>>>> worth doing in this case. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>> >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> The pseudo-strings are currently not supported in >>>>>>> reconstitution of constant pool. >>>>>>> >>>>>>> This is an explanation from John Rose about what the >>>>>>> pseudo-strings are: >>>>>>> >>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>> constant pool of bytecodes which >>>>>>> implement some method handles. We use the anonymous class >>>>>>> pseudo-string feature for that. >>>>>>> The relevant code is here: >>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>> >>>>>>> These oops are what "pseudo-strings" are. >>>>>>> The odd name refers to the fact that, even though they are >>>>>>> random oops, they appear in the constant pool >>>>>>> where one would expect (because of class file syntax) to >>>>>>> find a string." >>>>>>> ... >>>>>>> If you really wanted to reconstitute a class file for an >>>>>>> anonymous class, and >>>>>>> if that class has oop patching (pseudo-strings), you would >>>>>>> need either to (a) reconstitute the patches array >>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>> whatever odd strings were there first, as an approximation. >>>>>>> The "odd strings" are totally insignificant, and are >>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>> >>>>>>> >>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>> >>>>>>> The problem is that a pseudo-string is a patched string that >>>>>>> does not have >>>>>>> a reference to the string symbol anymore: >>>>>>> unresolved_string_at(idx) == NULL >>>>>>> >>>>>>> The fix is to create and fill in a map from >>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>> to be able to restore this assotiation in the >>>>>>> JvmtiConstantPoolReconstituter. >>>>>>> >>>>>>> Testing: >>>>>>> Run: >>>>>>> - java/lang/instrument tests >>>>>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Dec 18 23:20:28 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 18 Dec 2014 15:20:28 -0800 Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54935CE7.2020400@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <549353C8.9000706@oracle.com> <54935CE7.2020400@oracle.com> Message-ID: <5493613C.6040804@oracle.com> On 12/18/14 3:01 PM, Coleen Phillimore wrote: > > On 12/18/14, 5:23 PM, serguei.spitsyn at oracle.com wrote: >> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> Thank you for reviewing! >>> >>> >>> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>>> >>>> Hi Serguei, >>>> >>>> Thank you for making the patches an optional field. >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>>> 198 if (!patched()) { >>>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>>> 200 return 0; >>>> 201 } >>>> Why not >>>> assert(patched(), "a pseud-string map must exist >>>> for patched CP only"); >>> >>> Wanted it to be more reliable but it looks pointless. >>> Will make this change. >>> >>>> >>>> >>>> Why is this? Is this really a ShouldNotReachHere? should it be >>>> false? >>>> >>>> 215 assert(true, "not found a matching entry in pseudo-string map"); >>> >>> >>> A typo, must be false. >>> It is the last minute change. >>> Thanks for the catch! >>> >>> >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>>> >>>> Don't you have to move the value of the patched field from the old >>>> constant pool to the new one? I hate to ask but is there merging >>>> that needs to be done? I don't know how to write this test case >>>> though. Is it possible to redefine a class with a constant pool >>>> patches with another that has constant pool patches? >>> >>> Thank you for asking this question. >>> If I understand correctly, the patching comes from the compiler side >>> for anonymous classes only. >>> I saw it for LambdaForm's only. >>> I think, the patching can not be changed with a retransformation. >>> But I'm not sure if it can not be changed with a redefinition. >>> >>> But if it can - then it would be safe to merge the 'patched' >>> condition, i.e. make it patched >>> if either the_class or scratch class is patched. >>> >>>> >>>> Somehow I thought you'd have to save the value of the cp_patches >>>> oops passed in. >> >> Forgot to answer this good question. >> >> If the cp_patches can be changed with a class redefinition (it, >> probably, can) >> then it needs to be saved and merged too. >> Can we separate this cp_patches merge issue into another bug or RFE? >> The need still has to be clarified though, I'll check this with John. > > Yes, it seems good to have a follow up bug for this once the > requirement is understood. It may be a fair bit of work. Ok, thanks! Serguei > > Thanks, > Coleen > >> >> >> Thanks, >> Serguei >> >> >>>> >>>> So I was wondering why you can't change this instead: >>>> >>>> bool is_pseudo_string_at(int which) { >>>> // A pseudo string is a string that doesn't have a symbol in >>>> the cpSlot >>>> - return unresolved_string_at(which) == NULL; >>>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>>> } >>> >>> I was thinking about the same but was not sure if it would work for >>> the compiler team. >>> We have to ask John about this (added John and Christian to the >>> cc-list). >>> This question to John was in my plan! :) >>> >>> The beauty of the above approach is that there is no need to create >>> an intermediate >>> pseudo-string map and most of the code in from this webrev is not >>> needed. >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> And the asserts in the other functions below it. >>>> >>>> Coleen >>>> >>>> >>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the second round fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This fix implements a footprint saving approach suggested by Coleen. >>>>> To be able to reconstitute a class constant pool, an >>>>> intermediate pseudo-string map is used. >>>>> Now, this field is accounted optionally, only if the >>>>> 'cp_patches' is provided in the >>>>> ClassFileParser::parseClassFile() before ConstantPool is allocated. >>>>> This fix is not elegant, even a little bit ugly, but it is the >>>>> only way I see so far. >>>>> >>>>> Unfortunately, this approach did not help much to make some >>>>> other fields (eg., 'operands') optional. >>>>> The problem is that we have to account optional fields before >>>>> parsing, at the CP allocation time. >>>>> It is possible to re-allocate the ConstantPool when any >>>>> InvokeDynamic bytecode is discovered, >>>>> but it looks too complicated. >>>>> >>>>> Testing: >>>>> - the unit test from bug report >>>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>>>> - vm.mlvm.testlist, vm.quick.testlist, >>>>> vm.parallel_class_loading.testlist (in progress) >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Coleen, >>>>>> >>>>>> Thank you for looking at this! >>>>>> I'll check how this can be improved. >>>>>> It is my concern too. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Serguei, >>>>>>> I had a quick look at this. I was wondering if we could make >>>>>>> the pseudo_string_map conditional in ConstantPool and not make >>>>>>> all classes pay in footprint for this field? The same thing >>>>>>> probably could be done for operands too. There are flags that >>>>>>> you can set to conditionally add a pointer to base() in this >>>>>>> function. >>>>>>> >>>>>>> Typical C++ would subclass ConstantPool to add >>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so >>>>>>> the trick we use is like the one in ConstMethod. I think it's >>>>>>> worth doing in this case. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>> >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> The pseudo-strings are currently not supported in >>>>>>>> reconstitution of constant pool. >>>>>>>> >>>>>>>> This is an explanation from John Rose about what the >>>>>>>> pseudo-strings are: >>>>>>>> >>>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>>> constant pool of bytecodes which >>>>>>>> implement some method handles. We use the anonymous class >>>>>>>> pseudo-string feature for that. >>>>>>>> The relevant code is here: >>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>>> >>>>>>>> These oops are what "pseudo-strings" are. >>>>>>>> The odd name refers to the fact that, even though they are >>>>>>>> random oops, they appear in the constant pool >>>>>>>> where one would expect (because of class file syntax) to >>>>>>>> find a string." >>>>>>>> ... >>>>>>>> If you really wanted to reconstitute a class file for an >>>>>>>> anonymous class, and >>>>>>>> if that class has oop patching (pseudo-strings), you would >>>>>>>> need either to (a) reconstitute the patches array >>>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>>> whatever odd strings were there first, as an approximation. >>>>>>>> The "odd strings" are totally insignificant, and are >>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>>> >>>>>>>> >>>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>>> >>>>>>>> The problem is that a pseudo-string is a patched string that >>>>>>>> does not have >>>>>>>> a reference to the string symbol anymore: >>>>>>>> unresolved_string_at(idx) == NULL >>>>>>>> >>>>>>>> The fix is to create and fill in a map from >>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>>> to be able to restore this assotiation in the >>>>>>>> JvmtiConstantPoolReconstituter. >>>>>>>> >>>>>>>> Testing: >>>>>>>> Run: >>>>>>>> - java/lang/instrument tests >>>>>>>> - new jtreg test (see webrev) that was written by Filipp >>>>>>>> Zhinkin >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Fri Dec 19 18:41:29 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 19 Dec 2014 10:41:29 -0800 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5491CE34.4020900@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5489B3B5.1010801@oracle.com> <5489DA1A.1080108@oracle.com> <5489DFF1.7010800@oracle.com> <5490B87E.7020709@oracle.com> <5491CE34.4020900@oracle.com> Message-ID: <54947159.2040106@oracle.com> On 12/17/14 10:40 AM, Dmitry Samersoff wrote: > 1. Ever if you set SO_LINGER to zero, socket will not be closed > immediately. see TCP shutdown sequence. Which TCP shutdown sequence? The one that involves FIN_WAIT_1, FIN_WAIT_2, and TIME_WAIT? That's the state machine for a connected socket; the sockets in question here have never been connected. There is still apparently a state the socket goes through before the port is actually freed, but it might not have anything to do with TCP. If you have references for this behavior I'd appreciate them. What I've learned about this issue is only through empirical observation. By the way, more empiricism: I can reproduce the EADDRINUSE on Solaris a large fraction of the time, by running multiple programs (or threads) that simply close and reopen distinct sockets. I've also observed that setting SO_REUSEPORT (introduced in Solaris 11) seems to avoid this problem entirely. Unfortunately SO_REUSEPORT isn't available from Java, it doesn't exist on all systems, and I don't know if it would have this same behavior on other systems on which it does exist. > 2. In a native world it's quite easy to find the port your rmi server > uses - it could be achieved by parsing /proc//net/tcp on Linux or > using special API on windows and solaris. I think your definition of "easy" differs from mine. :-) The context is the jdk regression tests, does support native code. I'd prefer not to have to explore this new area, especially in addition to writing a bunch of system-specific native code. > 3. For rmid and port provided from outside I think the only reliable way > to get what you need is: [...] I think it's pretty clear at this point that the open-close-reopen approach can't be made reliable in any platform-independent way. For rmid I think I might create a new mode that opens an ephemeral port and sends that to the test driver somehow. Looks like Jaroslav is proceeding with a retry strategy. > 4. For rmid you can also emulate inetd behaviour - i.e. driver open a > server port, communicate it to client than redirect everything that come > to this port to stdin of rmid. Thanks, but unfortunately this is actually one of the modes that needs to be tested in rmid. It has a mode where it opens and listens on its own socket, and another mode where it inherits one from its parent process, so that it can be invoked from inetd. s'marks > -Dmitry > > On 2014-12-17 01:55, Stuart Marks wrote: >> Hi Dmitry, >> >> Strictly speaking you are correct. As soon as you close a socket, there >> is a possibility -- perhaps vanishingly small but nonzero -- that you >> might not be able to open it again. >> >> The first scenario, where the user of the socket itself opens the socket >> using an ephemeral port (e.g. new ServerSocket(0)) is of course >> preferred. This avoids race conditions entirely. >> >> It's the second case that I'm still wrestling with, and maybe Jaroslav >> too. It's fairly difficult to get such "black box" systems to open an >> ephemeral port and report it back, as opposed to opening up their >> service on some port number handed in from the outside. (For RMI, rmid >> is the culprit here. I don't know about JMX.) What makes this difficult >> is that the rmid service is running in a separate VM, so getting >> reliable information back from it can be difficult. >> >> It's also fairly difficult to establish the retry logic in such cases. >> If the service fails with a BindException, maybe -- maybe -- it was >> because there was a conflict over the port, and a retry is warranted. >> But this needs to be distinguished from other failure modes that might >> occur, that should be reported as failures instead of causing a retry. >> In principle, this is possible to do, of course, it's just that it >> involves more restructuring of the tests, and possibly adding debug/test >> code to rmid. (It may yet come to that.) >> >> I'm still pondering the reasons that, in the open/close/reopen scenario, >> why the reopen might fail. The obvious reason is that some other process >> on the system has opened that port between the close and the reopen. I >> admit that this is a possibility. However, with the open/close/reopen >> scenario in place, we see tests that fail up to 15% of the time with >> BindExceptions. This is an extraordinarily high failure rate to be >> caused by some random other process happening to open the same port in >> the few microseconds between the close and reopen. It's simply not >> believable to me. >> >> My thinking is still that the port isn't ready for reuse until a small >> amount of time after it's closed. I have some test programs that >> exercise sockets in a particular way (e.g., from multiple threads, or >> opening and closing batches of sockets) that can reproduce the problem >> on some systems, and these test programs seem to behave better if a time >> delay is added between the close and the reopen. The exact circumstances >> under which the problem occurs is difficult to pin down and seems OS >> specific, and so choosing the "right" delay time is very difficult. But >> it does strengthen this conjecture in my mind. >> >> Naturally it would be better if there were a way to determine when a >> port is available for reuse without actually opening it. I'm not aware >> of any such way, but I'm holding onto a little hope that one can be found. >> >> s'marks >> >> >> >> On 12/11/14 10:18 AM, Dmitry Samersoff wrote: >>> Stuart, >>> >>> As soon as you close socket, you open a door for the race. >>> >>> So you need another communication channel to pass a port number (or bind >>> result) between a client and a server without closing a socket on the >>> server side. >>> >>> Typical scenario used by network related code is: >>> >>> 1. Server opens the socket >>> 2. Server binds to port(0) >>> 3. Server gets port number assigned by OS >>> 4. Server informs client (e.g. write the port down to known file, >>> broadcast it etc) >>> 5. Client establishes connection. >>> >>> If the server is a blackbox and have to get a port number from outside, >>> scenario looks like: >>> >>> WHILE(!success and !timeout) >>> 1. Driver chooses random port number >>> 2. Driver runs a server with this number >>> 3. Driver checks that server is actually listening on this port >>> (e.g. try to connect by it self) >>> WEND >>> >>> 4. Driver runs a client with this port number or bails out with >>> descriptive error message. >>> >>> -Dmitry >>> >>> On 2014-12-11 20:53, Stuart Marks wrote: >>>> >>>> >>>> On 12/11/14 7:09 AM, olivier.lagneau at oracle.com wrote: >>>>> On 11/12/2014 15:43, Dmitry Samersoff wrote: >>>>>> You can set SO_LINGER to zero, in this case socket will be closed >>>>>> immediately without waiting in TIME_WAIT >>>>> SO-LINGER did not help either in my case (see my previous mail to >>>>> Jaroslav). >>>>> That ended-up in using another hard-coded (supposedly free) port. >>>>> Note that was before RMI tests used randomly allocated ports. >>>>> >>>>>> But there are no reliable way to predict whether you can take this >>>>>> port >>>>>> or not after you close it. >>>>> This is what I observed in my case. >>>>>> >>>>>> So the only valid solution is to try to connect to a random port >>>>>> and if >>>>>> this attempt fails try another random port. Everything else will cause >>>>>> more or less frequent intermittent failures. >>>>> IIRC think this is what is currently done in RMI tests. >>>> >>>> The RMI tests are still suffering from this problem, unfortunately. >>>> >>>> The RMI test library gets a "random" port with "new ServerSocket(0)", >>>> gets the port number, closes the socket, then returns the port to the >>>> caller. The caller then assumes that it can use that port as it wishes. >>>> That's when the BindException can occur. There are about 10 RMI test >>>> bugs in the database that all seem to have this as their root cause. >>>> >>>> There is some retry logic in RMI's test library, but that's to avoid the >>>> so-called "reserved ports" that specific RMI tests use, or if "new >>>> ServerSocket(0)" fails. It doesn't have anything to do with the >>>> BindException that occurs when the caller attempts to reuse the port >>>> with another socket. >>>> >>>> My observation is also that setting SO_REUSEADDR has no effect. I >>>> haven't tried SO_LINGER. My hunch is that it won't have any effect, >>>> since the sockets in question aren't actually going into TIME_WAIT >>>> state. But I suppose it's worth a try. >>>> >>>> I don't have any solution for this; we're still discussing the issue. I >>>> think the best approach would be to refactor the code so that the >>>> eventual user of the socket opens it up on an ephemeral port in the >>>> first place. That avoids the open/close/reopen business. Unfortunately >>>> that doesn't help the case where you want to tell another JVM to run a >>>> service on a specific port. We don't have a solution for that case yet. >>>> >>>> The second-best approach (not really a solution) is to open/close a >>>> serversocket to get the port, sleep for a little bit, then return the >>>> port number to the caller. This might give the kernel a chance to clean >>>> up the socket after the close. Of course, this still has a race >>>> condition, but it might reduce the incidence of problems to an >>>> acceptable level. >>>> >>>> I'll let you know if we come up with anything better. >>>> >>>> s'marks >>> >>> > > From dmitrij.pochepko at oracle.com Fri Dec 19 19:03:19 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 19 Dec 2014 22:03:19 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature Message-ID: <54947677.7050104@oracle.com> Hi all, Please review changes for https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature Description: this fix introduce dtrace test, which verify that different combinations of available compile levels(and, in case compile levels allows it, different code heaps as result) doesn't affect callstack shown by dtrace. There is a control class SegmentedCodeCacheDtraceTest.java and class for running via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also present (SegmentedCodeCacheDtraceTestScript.d). A control class is using DtraceRunner.java to run dtrace and then analyzing results using class SegmentedCodeCacheDtraceResultsAnalyzer with DtraceResultsAnalyzer interface. There is also a small class CompilerUtils.java created for usefull common code. webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ Additional note: Please note that this path assumes that fix for JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also applied. Thanks, Dmitrij From igor.ignatyev at oracle.com Mon Dec 22 14:59:32 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 22 Dec 2014 17:59:32 +0300 Subject: RFR: 8067295 - Need to port Utils chagnes... 8067307: Need custom classloaders... 8067291: Need additional vm checks... In-Reply-To: <548EEAD8.7000509@oracle.com> References: <548B5603.5030902@oracle.com> <548EEAD8.7000509@oracle.com> Message-ID: <549831D4.1070701@oracle.com> Dmitrij, all fixes look good to me. // could you please send separate RFR for each CR next time? Thanks, Igor On 12/15/2014 05:06 PM, Dmitrij Pochepko wrote: > Hi, > a bit of update for https://bugs.openjdk.java.net/browse/JDK-8067295 > (port of JDK-8066440) > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.01/ > > Thanks, > Dmitrij >> Hi, >> >> Please review changes for >> https://bugs.openjdk.java.net/browse/JDK-8067291 - Need additional vm >> checks in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking >> which vm is run >> https://bugs.openjdk.java.net/browse/JDK-8067295 - Need to port Utils >> chagnes from JDK-8059613 into jdk workspace >> https://bugs.openjdk.java.net/browse/JDK-8067307 - Need custom >> classloaders(parent-last and filtering one) for JDK-8066625 in >> testlibrary >> >> Description: A number of small testlibrary changes needed for further >> test development, 2 of 3 is port from respective hotspot changes >> 3rd one (JDK-8067307) introduce 2 classloaders for testlibrary. 1st is >> FilterClassLoader - loads classes using target classloader in case >> class name meets provided condition, and using parent otherwise. 2nd >> is ParentLastURLClassLoader which loads classes using provided URL[] >> with fallback to parent, >> >> Webrevs: >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8067291/webrev.00/ >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.00/ >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8067307/webrev.00/ >> >> Thanks, >> Dmitrij > From christian.thalinger at oracle.com Mon Dec 22 22:17:55 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Dec 2014 14:17:55 -0800 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54947677.7050104@oracle.com> References: <54947677.7050104@oracle.com> Message-ID: 40 public static int[] getAvailableCompilationLevels() { 41 if (System.getProperty("java.vm.info").startsWith("interpreted ")) { 42 return new int[0]; 43 } Wouldn?t it be better to check the UseCompiler flag instead? > On Dec 19, 2014, at 11:03 AM, Dmitrij Pochepko wrote: > > Hi all, > > Please review changes for https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature > > Description: this fix introduce dtrace test, which verify that different combinations of available compile levels(and, in case compile levels allows it, different code heaps as result) doesn't affect callstack shown by dtrace. There is a control class SegmentedCodeCacheDtraceTest.java and class for running via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also present (SegmentedCodeCacheDtraceTestScript.d). A control class is using DtraceRunner.java to run dtrace and then analyzing results using class SegmentedCodeCacheDtraceResultsAnalyzer with DtraceResultsAnalyzer interface. > There is also a small class CompilerUtils.java created for usefull common code. > > webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ > > Additional note: Please note that this path assumes that fix for JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also applied. > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Dec 23 07:27:30 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Dec 2014 23:27:30 -0800 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54947677.7050104@oracle.com> References: <54947677.7050104@oracle.com> Message-ID: <54991962.7020806@oracle.com> Hi Dmitry, It looks good in general. Some minor comments are below. test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE 60 private static final String WORKER_CLASS_NAME 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); ... 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, The WORKER_CLASS_NAME can be used at 81. 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() ... 179 List tml 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; ... 235 List mlist 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; The TESTED_METHODS_LIST is used three times. It can be cached at the top and re-used. Thanks, Serguei On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: > Hi all, > > Please review changes for > https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: > Test task: DTrace- tests for segmented codecache feature > > Description: this fix introduce dtrace test, which verify that > different combinations of available compile levels(and, in case > compile levels allows it, different code heaps as result) doesn't > affect callstack shown by dtrace. There is a control class > SegmentedCodeCacheDtraceTest.java and class for running via dtrace > SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also > present (SegmentedCodeCacheDtraceTestScript.d). A control class is > using DtraceRunner.java to run dtrace and then analyzing results using > class SegmentedCodeCacheDtraceResultsAnalyzer with > DtraceResultsAnalyzer interface. > There is also a small class CompilerUtils.java created for usefull > common code. > > webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ > > Additional note: Please note that this path assumes that fix for > JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also > applied. > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Tue Dec 23 08:36:10 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 11:36:10 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: References: <54947677.7050104@oracle.com> Message-ID: <5499297A.2070402@oracle.com> Looks like that. Will fix. Thank you. Dmitrij > 40 public static int[] getAvailableCompilationLevels() { > 41 if (System.getProperty("java.vm.info").startsWith("interpreted ")) { > 42 return new int[0]; > 43 } > > Wouldn?t it be better to check the UseCompiler flag instead? > >> On Dec 19, 2014, at 11:03 AM, Dmitrij Pochepko >> > wrote: >> >> Hi all, >> >> Please review changes for >> https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: >> Test task: DTrace- tests for segmented codecache feature >> >> Description: this fix introduce dtrace test, which verify that >> different combinations of available compile levels(and, in case >> compile levels allows it, different code heaps as result) doesn't >> affect callstack shown by dtrace. There is a control class >> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >> using DtraceRunner.java to run dtrace and then analyzing results >> using class SegmentedCodeCacheDtraceResultsAnalyzer with >> DtraceResultsAnalyzer interface. >> There is also a small class CompilerUtils.java created for usefull >> common code. >> >> webrev: >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >> >> >> Additional note: Please note that this path assumes that fix for >> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also >> applied. >> >> Thanks, >> Dmitrij > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Tue Dec 23 08:37:44 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 11:37:44 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54991962.7020806@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> Message-ID: <549929D8.7050003@oracle.com> Hi, Thank you for catching these issues. I have a question regarding last comment: does it make any difference to change "reading of static member 3 times" to "copying into static member of another class and then read it 3 times"? Thanks, Dmitrij > Hi Dmitry, > > > It looks good in general. > Some minor comments are below. > > test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java > > 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; > A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE > > > test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java > > 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, > A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE > > > 60 private static final String WORKER_CLASS_NAME > 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); > ... > 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, > 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, > The WORKER_CLASS_NAME can be used at 81. > > 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() > ... > 179 List tml > 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > ... > 235 List mlist > 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > The TESTED_METHODS_LIST is used three times. > It can be cached at the top and re-used. > > Thanks, > Serguei > > > > On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >> Hi all, >> >> Please review changes for >> https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: >> Test task: DTrace- tests for segmented codecache feature >> >> Description: this fix introduce dtrace test, which verify that >> different combinations of available compile levels(and, in case >> compile levels allows it, different code heaps as result) doesn't >> affect callstack shown by dtrace. There is a control class >> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >> using DtraceRunner.java to run dtrace and then analyzing results >> using class SegmentedCodeCacheDtraceResultsAnalyzer with >> DtraceResultsAnalyzer interface. >> There is also a small class CompilerUtils.java created for usefull >> common code. >> >> webrev: >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >> >> Additional note: Please note that this path assumes that fix for >> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also >> applied. >> >> Thanks, >> Dmitrij > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Dec 23 09:10:11 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Dec 2014 01:10:11 -0800 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549929D8.7050003@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> Message-ID: <54993173.6030003@oracle.com> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: > Hi, > > Thank you for catching these issues. > I have a question regarding last comment: does it make any difference > to change "reading of static member 3 times" to "copying into static > member of another class and then read it 3 times"? Yes, it does (it is a minor issue though). It is because the class names are pretty big. It would simplify the code and improve readability, right? You already do it two times: 179 List tml 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; ... 235 List mlist 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; My suggestion is to do it once somewhere before the line 74: static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; and then use the mlist in other places where it is needed: 75 String params = MLIST.stream() ... 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), ... 239 for (int i = MLIST.size() - 1; i > -1; i--) { 240 sb.append(MLIST.get(i).getName()).append(delimeter); These lines will go away: 179 List tml 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; ... 235 List mlist 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; Both private static classes are inner classes of the public one. The MLIST will be in a context for the inner classes, and so, needs no prefixing. Thanks, Serguei > > Thanks, > Dmitrij >> Hi Dmitry, >> >> >> It looks good in general. >> Some minor comments are below. >> >> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >> >> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >> >> >> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >> >> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >> >> >> 60 private static final String WORKER_CLASS_NAME >> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >> ... >> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >> The WORKER_CLASS_NAME can be used at 81. >> >> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >> ... >> 179 List tml >> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> ... >> 235 List mlist >> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> The TESTED_METHODS_LIST is used three times. >> It can be cached at the top and re-used. >> >> Thanks, >> Serguei >> >> >> >> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> Please review changes for >>> https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: >>> Test task: DTrace- tests for segmented codecache feature >>> >>> Description: this fix introduce dtrace test, which verify that >>> different combinations of available compile levels(and, in case >>> compile levels allows it, different code heaps as result) doesn't >>> affect callstack shown by dtrace. There is a control class >>> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >>> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >>> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >>> using DtraceRunner.java to run dtrace and then analyzing results >>> using class SegmentedCodeCacheDtraceResultsAnalyzer with >>> DtraceResultsAnalyzer interface. >>> There is also a small class CompilerUtils.java created for usefull >>> common code. >>> >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>> >>> Additional note: Please note that this path assumes that fix for >>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also >>> applied. >>> >>> Thanks, >>> Dmitrij >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Tue Dec 23 11:36:30 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 14:36:30 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54993173.6030003@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> Message-ID: <549953BE.50404@oracle.com> Hi, please review updated webrev http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ Thanks, Dmitrij > On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >> Hi, >> >> Thank you for catching these issues. >> I have a question regarding last comment: does it make any difference >> to change "reading of static member 3 times" to "copying into static >> member of another class and then read it 3 times"? > > Yes, it does (it is a minor issue though). > It is because the class names are pretty big. > It would simplify the code and improve readability, right? > > You already do it two times: > 179 List tml > 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > ... > 235 List mlist > 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > > My suggestion is to do it once somewhere before the line 74: > static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > and then use the mlist in other places where it is needed: > > 75 String params = MLIST.stream() > ... > 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), > ... > 239 for (int i = MLIST.size() - 1; i> -1; i--) { > 240 sb.append(MLIST.get(i).getName()).append(delimeter); > These lines will go away: > 179 List tml > 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > ... > 235 List mlist > 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > > > Both private static classes are inner classes of the public one. > The MLIST will be in a context for the inner classes, and so, needs no > prefixing. > > > Thanks, > Serguei > >> >> Thanks, >> Dmitrij >>> Hi Dmitry, >>> >>> >>> It looks good in general. >>> Some minor comments are below. >>> >>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>> >>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>> >>> >>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>> >>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>> >>> >>> 60 private static final String WORKER_CLASS_NAME >>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>> ... >>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>> The WORKER_CLASS_NAME can be used at 81. >>> >>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>> ... >>> 179 List tml >>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> ... >>> 235 List mlist >>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> The TESTED_METHODS_LIST is used three times. >>> It can be cached at the top and re-used. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>> Hi all, >>>> >>>> Please review changes for >>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache >>>> feature >>>> >>>> Description: this fix introduce dtrace test, which verify that >>>> different combinations of available compile levels(and, in case >>>> compile levels allows it, different code heaps as result) doesn't >>>> affect callstack shown by dtrace. There is a control class >>>> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >>>> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >>>> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >>>> using DtraceRunner.java to run dtrace and then analyzing results >>>> using class SegmentedCodeCacheDtraceResultsAnalyzer with >>>> DtraceResultsAnalyzer interface. >>>> There is also a small class CompilerUtils.java created for usefull >>>> common code. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>> >>>> Additional note: Please note that this path assumes that fix for >>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>> also applied. >>>> >>>> Thanks, >>>> Dmitrij >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Dec 23 11:46:51 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Dec 2014 03:46:51 -0800 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549953BE.50404@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> Message-ID: <5499562B.5020008@oracle.com> Hi Dmitrij, There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java 42 public static final String PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, Otherwise, looks good. Please, consider it reviewed (no need to re-review). Thanks, Serguei On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: > Hi, > please review updated webrev > > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ > > Thanks, > Dmitrij >> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> Thank you for catching these issues. >>> I have a question regarding last comment: does it make any >>> difference to change "reading of static member 3 times" to "copying >>> into static member of another class and then read it 3 times"? >> >> Yes, it does (it is a minor issue though). >> It is because the class names are pretty big. >> It would simplify the code and improve readability, right? >> >> You already do it two times: >> 179 List tml >> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> ... >> 235 List mlist >> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> >> My suggestion is to do it once somewhere before the line 74: >> static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> and then use the mlist in other places where it is needed: >> >> 75 String params = MLIST.stream() >> ... >> 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), >> ... >> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >> These lines will go away: >> 179 List tml >> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> ... >> 235 List mlist >> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> >> >> Both private static classes are inner classes of the public one. >> The MLIST will be in a context for the inner classes, and so, needs >> no prefixing. >> >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> Dmitrij >>>> Hi Dmitry, >>>> >>>> >>>> It looks good in general. >>>> Some minor comments are below. >>>> >>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>> >>>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>> >>>> >>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>> >>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>> >>>> >>>> 60 private static final String WORKER_CLASS_NAME >>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>> ... >>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>> The WORKER_CLASS_NAME can be used at 81. >>>> >>>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>> ... >>>> 179 List tml >>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> ... >>>> 235 List mlist >>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> The TESTED_METHODS_LIST is used three times. >>>> It can be cached at the top and re-used. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>> Hi all, >>>>> >>>>> Please review changes for >>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache >>>>> feature >>>>> >>>>> Description: this fix introduce dtrace test, which verify that >>>>> different combinations of available compile levels(and, in case >>>>> compile levels allows it, different code heaps as result) doesn't >>>>> affect callstack shown by dtrace. There is a control class >>>>> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >>>>> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >>>>> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >>>>> using DtraceRunner.java to run dtrace and then analyzing results >>>>> using class SegmentedCodeCacheDtraceResultsAnalyzer with >>>>> DtraceResultsAnalyzer interface. >>>>> There is also a small class CompilerUtils.java created for usefull >>>>> common code. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>> >>>>> Additional note: Please note that this path assumes that fix for >>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>> also applied. >>>>> >>>>> Thanks, >>>>> Dmitrij >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Tue Dec 23 13:35:35 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 16:35:35 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <5499562B.5020008@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> Message-ID: <54996FA7.3070607@oracle.com> Hi, There is one more issues related to these tests(not directly). Currently, dtrace tests can't be run in jprt, because dtrace require additional previleges for launching user. Perhaps it's just user to be granted previleges in jprt solaris hosts... Not sure about some guard in tests... the only way i know so far is to just try launching dtrace and parse output saying about missing previleges, but it doesn't seem to be good solution. I think test should assume to be launched in correct environment and in case it's failed because of previleges, evaluating engineer starting to work on respective env. issue... Does anybody have some additional concerns? Thanks, Dmitrij > Hi Dmitrij, > > > There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): > > test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java > 42 public static final String PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; > > test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java > 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, > > > Otherwise, looks good. > Please, consider it reviewed (no need to re-review). > > Thanks, > Serguei > > > On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >> Hi, >> please review updated webrev >> >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >> >> Thanks, >> Dmitrij >>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> Thank you for catching these issues. >>>> I have a question regarding last comment: does it make any >>>> difference to change "reading of static member 3 times" to "copying >>>> into static member of another class and then read it 3 times"? >>> >>> Yes, it does (it is a minor issue though). >>> It is because the class names are pretty big. >>> It would simplify the code and improve readability, right? >>> >>> You already do it two times: >>> 179 List tml >>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> ... >>> 235 List mlist >>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> >>> My suggestion is to do it once somewhere before the line 74: >>> static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> and then use the mlist in other places where it is needed: >>> >>> 75 String params = MLIST.stream() >>> ... >>> 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), >>> ... >>> 239 for (int i = MLIST.size() - 1; i> -1; i--) { >>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>> These lines will go away: >>> 179 List tml >>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> ... >>> 235 List mlist >>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> >>> >>> Both private static classes are inner classes of the public one. >>> The MLIST will be in a context for the inner classes, and so, needs >>> no prefixing. >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi Dmitry, >>>>> >>>>> >>>>> It looks good in general. >>>>> Some minor comments are below. >>>>> >>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>> >>>>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>> >>>>> >>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>> >>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>> >>>>> >>>>> 60 private static final String WORKER_CLASS_NAME >>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>> ... >>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>> The WORKER_CLASS_NAME can be used at 81. >>>>> >>>>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>> ... >>>>> 179 List tml >>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> ... >>>>> 235 List mlist >>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> The TESTED_METHODS_LIST is used three times. >>>>> It can be cached at the top and re-used. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review changes for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache >>>>>> feature >>>>>> >>>>>> Description: this fix introduce dtrace test, which verify that >>>>>> different combinations of available compile levels(and, in case >>>>>> compile levels allows it, different code heaps as result) >>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>> class SegmentedCodeCacheDtraceTest.java and class for running via >>>>>> dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script >>>>>> is also present (SegmentedCodeCacheDtraceTestScript.d). A control >>>>>> class is using DtraceRunner.java to run dtrace and then analyzing >>>>>> results using class SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>> DtraceResultsAnalyzer interface. >>>>>> There is also a small class CompilerUtils.java created for >>>>>> usefull common code. >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>> >>>>>> Additional note: Please note that this path assumes that fix for >>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>> also applied. >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Dec 23 14:31:10 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Dec 2014 15:31:10 +0100 Subject: Change "8057744: (process) Synchronize exiting of threads and process [win]" breaks HotSpot on Win Server 2003 Message-ID: Hi Ivan, I have just realized that the change 8057744 breaks HotSpot on Windows Server 2003 because the InitOnceExecuteOnce function isn't supported there. I suppose you're aware of this as the change contains the following comment in os_windows.cpp: // Must be at least Windows Vista or Server 2008 to use InitOnceExecuteOnce #define _WIN32_WINNT 0x0600 I just wanted to ask if there are any plans to downport this change to jdk8 because we currently still still support jdk8 HotSpot on Server 2003. Unfortunately the bug 8057744 is closed so I can not subscribe for notifications. If there are no special reasons for keeping it closed, can you please make it visible to everybody. Thank you and best regards, Volker On Sun, Sep 7, 2014 at 8:07 AM, Ivan Gerasimov wrote: > Hello! > > This is a proposal to address issue with wrong exit codes from a Java > processes on Windows. > In order to avoid a race, calls to _endthread(), exit and _exit() are > explicitly synchronized. > We allow simultaneous calls to _endthread() by multiple threads. > However, at the time exit() or _exit() is called, no calls to _endthread() > are allowed. > > Some instrumentation added with JDK-8055338 remain in the code to help > diagnose the failures if they still occur. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8057744 > WEBREV: http://cr.openjdk.java.net/~igerasim/8057744/0/webrev/ > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Wed Dec 24 07:21:56 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 24 Dec 2014 10:21:56 +0300 Subject: Change "8057744: (process) Synchronize exiting of threads and process [win]" breaks HotSpot on Win Server 2003 In-Reply-To: References: Message-ID: <549A6994.2080108@oracle.com> Hi Volker! Yes, I do hope to port this fix to jdk8u, once it is proved to fix the bug. However, as you correctly noticed, it will require some reorganization of the code: the initialization of the critical section will be done with initialization of other global variables. I preferred to do it with InitOnceExecuteOnce, since it helps keep all this workaround code in one place. JDK-8057744 is subtask of another confidential bug (due to internal links), and Jira does not allow to set different visibility level for subtask. Sincerely yours, Ivan On 23.12.2014 17:31, Volker Simonis wrote: > Hi Ivan, > > I have just realized that the change 8057744 breaks HotSpot on Windows > Server 2003 because the InitOnceExecuteOnce function isn't supported > there. I suppose you're aware of this as the change contains the > following comment in os_windows.cpp: > > // Must be at least Windows Vista or Server 2008 to use InitOnceExecuteOnce > #define _WIN32_WINNT 0x0600 > > I just wanted to ask if there are any plans to downport this change to > jdk8 because we currently still still support jdk8 HotSpot on Server > 2003. Unfortunately the bug 8057744 is closed so I can not subscribe > for notifications. If there are no special reasons for keeping it > closed, can you please make it visible to everybody. > > Thank you and best regards, > Volker > > > On Sun, Sep 7, 2014 at 8:07 AM, Ivan Gerasimov > wrote: >> Hello! >> >> This is a proposal to address issue with wrong exit codes from a Java >> processes on Windows. >> In order to avoid a race, calls to _endthread(), exit and _exit() are >> explicitly synchronized. >> We allow simultaneous calls to _endthread() by multiple threads. >> However, at the time exit() or _exit() is called, no calls to _endthread() >> are allowed. >> >> Some instrumentation added with JDK-8055338 remain in the code to help >> diagnose the failures if they still occur. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8057744 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8057744/0/webrev/ >> >> Sincerely yours, >> Ivan > From dmitry.samersoff at oracle.com Wed Dec 24 16:11:15 2014 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Wed, 24 Dec 2014 19:11:15 +0300 Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved Message-ID: <5e6a7ea3-1090-4158-9779-d3312d188868.maildroid@localhost> Looks good for me (not a reviewer). --Dmitry -----Original Message----- From: Alexander Kulyakhtin To: serviceability-dev at openjdk.java.net Cc: "Dmitry ?????????? Samersoff" , Serguei Vladimirovich Spitsyn Sent: Wed, 24 Dec 2014 17:32 Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved Hi, Could I, please, have a review of this fix. This is a oneline change to quarantine a test until JDK-8068162 is resolved bug: https://bugs.openjdk.java.net/browse/JDK-8068242 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00/ @ignore JDK-8068162 added to the test to have it ignored until JDK-8068162 is resolved Thanks, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Wed Dec 24 20:09:01 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 24 Dec 2014 23:09:01 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54996FA7.3070607@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> Message-ID: <549B1D5D.8030908@oracle.com> Hi, i've placed a guard which skips test in case dtrace exits with non-zero code. http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ Thanks, Dmitrij > Hi, > > There is one more issues related to these tests(not directly). > Currently, dtrace tests can't be run in jprt, because dtrace require > additional previleges for launching user. > Perhaps it's just user to be granted previleges in jprt solaris hosts... > Not sure about some guard in tests... the only way i know so far is to > just try launching dtrace and parse output > saying about missing previleges, but it doesn't seem to be good solution. > I think test should assume to be launched in correct environment and > in case it's failed because of previleges, evaluating engineer > starting to work on respective env. issue... > Does anybody have some additional concerns? > > Thanks, > Dmitrij > >> Hi Dmitrij, >> >> >> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >> >> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >> 42 public static final String PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >> >> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >> >> >> Otherwise, looks good. >> Please, consider it reviewed (no need to re-review). >> >> Thanks, >> Serguei >> >> >> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>> Hi, >>> please review updated webrev >>> >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>> >>> Thanks, >>> Dmitrij >>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> Thank you for catching these issues. >>>>> I have a question regarding last comment: does it make any >>>>> difference to change "reading of static member 3 times" to >>>>> "copying into static member of another class and then read it 3 >>>>> times"? >>>> >>>> Yes, it does (it is a minor issue though). >>>> It is because the class names are pretty big. >>>> It would simplify the code and improve readability, right? >>>> >>>> You already do it two times: >>>> 179 List tml >>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> ... >>>> 235 List mlist >>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> >>>> My suggestion is to do it once somewhere before the line 74: >>>> static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> and then use the mlist in other places where it is needed: >>>> >>>> 75 String params = MLIST.stream() >>>> ... >>>> 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), >>>> ... >>>> 239 for (int i = MLIST.size() - 1; i> -1; i--) { >>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>> These lines will go away: >>>> 179 List tml >>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> ... >>>> 235 List mlist >>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> >>>> >>>> Both private static classes are inner classes of the public one. >>>> The MLIST will be in a context for the inner classes, and so, needs >>>> no prefixing. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> Hi Dmitry, >>>>>> >>>>>> >>>>>> It looks good in general. >>>>>> Some minor comments are below. >>>>>> >>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>> >>>>>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>> >>>>>> >>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>> >>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>> >>>>>> >>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>> ... >>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>> >>>>>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>> ... >>>>>> 179 List tml >>>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> The TESTED_METHODS_LIST is used three times. >>>>>> It can be cached at the top and re-used. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review changes for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>> codecache feature >>>>>>> >>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>> different combinations of available compile levels(and, in case >>>>>>> compile levels allows it, different code heaps as result) >>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>> analyzing results using class >>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>> DtraceResultsAnalyzer interface. >>>>>>> There is also a small class CompilerUtils.java created for >>>>>>> usefull common code. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>> >>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>> also applied. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Wed Dec 24 20:07:53 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Dec 2014 21:07:53 +0100 Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved In-Reply-To: <5e6a7ea3-1090-4158-9779-d3312d188868.maildroid@localhost> References: <5e6a7ea3-1090-4158-9779-d3312d188868.maildroid@localhost> Message-ID: <204FB51C-BB6C-4FB8-A1FF-F7A306996551@oracle.com> Reviewed. Merry Christmas, ho-ho-ho :) On 24 December 2014 17:11:15 CET, dmitry.samersoff at oracle.com wrote: >Looks good for me (not a reviewer). > >--Dmitry > > > >-----Original Message----- >From: Alexander Kulyakhtin >To: serviceability-dev at openjdk.java.net >Cc: "Dmitry ?????????? Samersoff" , >Serguei Vladimirovich Spitsyn >Sent: Wed, 24 Dec 2014 17:32 >Subject: Review request JDK-8068242: quarantine the test >IsModifiableClassAgent.java until JDK-8068162 is resolved > >Hi, > >Could I, please, have a review of this fix. This is a oneline change to >quarantine a test until JDK-8068162 is resolved > >bug: https://bugs.openjdk.java.net/browse/JDK-8068242 >webrev: >http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00/ > >@ignore JDK-8068162 added to the test to have it ignored until >JDK-8068162 is resolved > >Thanks, >Alexander -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Dec 24 20:14:20 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Dec 2014 12:14:20 -0800 Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved In-Reply-To: <5e6a7ea3-1090-4158-9779-d3312d188868.maildroid@localhost> References: <5e6a7ea3-1090-4158-9779-d3312d188868.maildroid@localhost> Message-ID: <549B1E9C.80704@oracle.com> Looks good. Thanks, Serguei On 12/24/14 8:11 AM, dmitry.samersoff at oracle.com wrote: > Looks good for me (not a reviewer). > > --Dmitry > > > > -----Original Message----- > From: Alexander Kulyakhtin > To: serviceability-dev at openjdk.java.net > Cc: "Dmitry ?????????? Samersoff" , > Serguei Vladimirovich Spitsyn > Sent: Wed, 24 Dec 2014 17:32 > Subject: Review request JDK-8068242: quarantine the test > IsModifiableClassAgent.java until JDK-8068162 is resolved > > Hi, > > Could I, please, have a review of this fix. This is a oneline change > to quarantine a test until JDK-8068162 is resolved > > bug: https://bugs.openjdk.java.net/browse/JDK-8068242 > webrev: > http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00 > / > > > @ignore JDK-8068162 added to the test to have it ignored > until JDK-8068162 is resolved > > Thanks, > Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Thu Dec 25 09:57:55 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 13:57:55 +0400 Subject: RFR: 8067295 - Need to port Utils chagnes... 8067307: Need custom classloaders... 8067291: Need additional vm checks... In-Reply-To: <548B5603.5030902@oracle.com> References: <548B5603.5030902@oracle.com> Message-ID: <549BDFA3.1020904@oracle.com> Hi Dmitrij, all three changes looks good. Thanks, Filipp. On 12/13/2014 12:54 AM, Dmitrij Pochepko wrote: > Hi, > > Please review changes for > https://bugs.openjdk.java.net/browse/JDK-8067291 - Need additional vm checks > in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking which vm is run > https://bugs.openjdk.java.net/browse/JDK-8067295 - Need to port Utils chagnes > from JDK-8059613 into jdk workspace > https://bugs.openjdk.java.net/browse/JDK-8067307 - Need custom > classloaders(parent-last and filtering one) for JDK-8066625 in testlibrary > > Description: A number of small testlibrary changes needed for further test > development, 2 of 3 is porn from respective hotspot changes > 3rd one (JDK-8067307) introduce 2 classloaders for testlibrary. 1st is > FilterClassLoader - loads classes using target classloader in case > class name meets provided condition, and using parent otherwise. 2nd is > ParentLastURLClassLoader which loads classes using provided URL[] with > fallback to parent, > > Webrevs: > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067291/webrev.00/ > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.00/ > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067307/webrev.00/ > > Thanks, > Dmitrij From igor.ignatyev at oracle.com Thu Dec 25 10:05:27 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 13:05:27 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549B1D5D.8030908@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> Message-ID: <549BE167.8090305@oracle.com> I'd prefer to check privileges by running dtrace against dtrace; and do it in DtraceRunner::dtraceAvailable, smth like > result = false; > dtrace = getDtracePath(); > if ($dtrace) { > $dtrace $dtrace > result = $? == 0; > } > return $result; Igor On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: > Hi, > > i've placed a guard which skips test in case dtrace exits with non-zero > code. > > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ > > Thanks, > Dmitrij >> Hi, >> >> There is one more issues related to these tests(not directly). >> Currently, dtrace tests can't be run in jprt, because dtrace require >> additional previleges for launching user. >> Perhaps it's just user to be granted previleges in jprt solaris hosts... >> Not sure about some guard in tests... the only way i know so far is to >> just try launching dtrace and parse output >> saying about missing previleges, but it doesn't seem to be good solution. >> I think test should assume to be launched in correct environment and >> in case it's failed because of previleges, evaluating engineer >> starting to work on respective env. issue... >> Does anybody have some additional concerns? >> >> Thanks, >> Dmitrij >> >>> Hi Dmitrij, >>> >>> >>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>> >>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>> 42 public static final String PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>> >>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>> >>> >>> Otherwise, looks good. >>> Please, consider it reviewed (no need to re-review). >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>> Hi, >>>> please review updated webrev >>>> >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>> >>>> Thanks, >>>> Dmitrij >>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> Thank you for catching these issues. >>>>>> I have a question regarding last comment: does it make any >>>>>> difference to change "reading of static member 3 times" to >>>>>> "copying into static member of another class and then read it 3 >>>>>> times"? >>>>> >>>>> Yes, it does (it is a minor issue though). >>>>> It is because the class names are pretty big. >>>>> It would simplify the code and improve readability, right? >>>>> >>>>> You already do it two times: >>>>> 179 List tml >>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> ... >>>>> 235 List mlist >>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> >>>>> My suggestion is to do it once somewhere before the line 74: >>>>> static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> and then use the mlist in other places where it is needed: >>>>> >>>>> 75 String params = MLIST.stream() >>>>> ... >>>>> 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), >>>>> ... >>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>> These lines will go away: >>>>> 179 List tml >>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> ... >>>>> 235 List mlist >>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> >>>>> >>>>> Both private static classes are inner classes of the public one. >>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>> no prefixing. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> >>>>>>> It looks good in general. >>>>>>> Some minor comments are below. >>>>>>> >>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>> >>>>>>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>> >>>>>>> >>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>> >>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>> >>>>>>> >>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>> ... >>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>> >>>>>>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>> ... >>>>>>> 179 List tml >>>>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> ... >>>>>>> 235 List mlist >>>>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>> It can be cached at the top and re-used. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review changes for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>> codecache feature >>>>>>>> >>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>> different combinations of available compile levels(and, in case >>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>> analyzing results using class >>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>> usefull common code. >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>> >>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>> also applied. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>> >>>>>> >>>>> >>>> >>> >> > From filipp.zhinkin at oracle.com Thu Dec 25 10:25:17 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 14:25:17 +0400 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549BE167.8090305@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> Message-ID: <549BE60D.2060501@oracle.com> Hi Dmitrij, DtraceRunner::runDtrace prints warning in case of non-zero exit code. It means that the test will pass even if traced JVM crashed. I can name several issues that were found accidentally, because tests didn't care about a crash. Are there any other sane reasons for DTrace to return non-zero exit code except lack of privileges? Igor's suggestion will prevent us from running DTrace without required privileges, so I'd prefer to see the test failure instead of a warning in case of non-zero exit code returned by DTrace. Also, please add @bug to the test. Thanks, Filipp. On 12/25/2014 02:05 PM, Igor Ignatyev wrote: > I'd prefer to check privileges by running dtrace against dtrace; > and do it in DtraceRunner::dtraceAvailable, smth like > >> result = false; >> dtrace = getDtracePath(); >> if ($dtrace) { >> $dtrace $dtrace >> result = $? == 0; >> } >> return $result; > > > Igor > > On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >> Hi, >> >> i've placed a guard which skips test in case dtrace exits with non-zero >> code. >> >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >> >> Thanks, >> Dmitrij >>> Hi, >>> >>> There is one more issues related to these tests(not directly). >>> Currently, dtrace tests can't be run in jprt, because dtrace require >>> additional previleges for launching user. >>> Perhaps it's just user to be granted previleges in jprt solaris hosts... >>> Not sure about some guard in tests... the only way i know so far is to >>> just try launching dtrace and parse output >>> saying about missing previleges, but it doesn't seem to be good solution. >>> I think test should assume to be launched in correct environment and >>> in case it's failed because of previleges, evaluating engineer >>> starting to work on respective env. issue... >>> Does anybody have some additional concerns? >>> >>> Thanks, >>> Dmitrij >>> >>>> Hi Dmitrij, >>>> >>>> >>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>> >>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>> 42 public static final String >>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>> >>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>> >>>> >>>> Otherwise, looks good. >>>> Please, consider it reviewed (no need to re-review). >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> please review updated webrev >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thank you for catching these issues. >>>>>>> I have a question regarding last comment: does it make any >>>>>>> difference to change "reading of static member 3 times" to >>>>>>> "copying into static member of another class and then read it 3 >>>>>>> times"? >>>>>> >>>>>> Yes, it does (it is a minor issue though). >>>>>> It is because the class names are pretty big. >>>>>> It would simplify the code and improve readability, right? >>>>>> >>>>>> You already do it two times: >>>>>> 179 List tml >>>>>> 180 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> >>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>> static final List MLIST = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> and then use the mlist in other places where it is needed: >>>>>> >>>>>> 75 String params = MLIST.stream() >>>>>> ... >>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>> MethodData(MLIST.get(i).getName(), >>>>>> ... >>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>> These lines will go away: >>>>>> 179 List tml >>>>>> 180 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> >>>>>> >>>>>> Both private static classes are inner classes of the public one. >>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>> no prefixing. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> >>>>>>>> It looks good in general. >>>>>>>> Some minor comments are below. >>>>>>>> >>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>> >>>>>>>> 42 public static final String >>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>> >>>>>>>> >>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>> >>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>> >>>>>>>> >>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>> ... >>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>> >>>>>>>> 75 String params = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>> ... >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>> It can be cached at the top and re-used. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review changes for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>> codecache feature >>>>>>>>> >>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>> analyzing results using class >>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>> usefull common code. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>> >>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>> also applied. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From dmitrij.pochepko at oracle.com Thu Dec 25 12:06:49 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 25 Dec 2014 15:06:49 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549BE167.8090305@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> Message-ID: <549BFDD9.5060309@oracle.com> v.$next > I'd prefer to check privileges by running dtrace against dtrace; > and do it in DtraceRunner::dtraceAvailable, smth like > >> result = false; >> dtrace = getDtracePath(); >> if ($dtrace) { >> $dtrace $dtrace >> result = $? == 0; >> } >> return $result; > > > Igor > > On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >> Hi, >> >> i've placed a guard which skips test in case dtrace exits with non-zero >> code. >> >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >> >> Thanks, >> Dmitrij >>> Hi, >>> >>> There is one more issues related to these tests(not directly). >>> Currently, dtrace tests can't be run in jprt, because dtrace require >>> additional previleges for launching user. >>> Perhaps it's just user to be granted previleges in jprt solaris >>> hosts... >>> Not sure about some guard in tests... the only way i know so far is to >>> just try launching dtrace and parse output >>> saying about missing previleges, but it doesn't seem to be good >>> solution. >>> I think test should assume to be launched in correct environment and >>> in case it's failed because of previleges, evaluating engineer >>> starting to work on respective env. issue... >>> Does anybody have some additional concerns? >>> >>> Thanks, >>> Dmitrij >>> >>>> Hi Dmitrij, >>>> >>>> >>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>> >>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>> 42 public static final String >>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>> >>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>> 85 >>>> DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>> >>>> >>>> Otherwise, looks good. >>>> Please, consider it reviewed (no need to re-review). >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> please review updated webrev >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thank you for catching these issues. >>>>>>> I have a question regarding last comment: does it make any >>>>>>> difference to change "reading of static member 3 times" to >>>>>>> "copying into static member of another class and then read it 3 >>>>>>> times"? >>>>>> >>>>>> Yes, it does (it is a minor issue though). >>>>>> It is because the class names are pretty big. >>>>>> It would simplify the code and improve readability, right? >>>>>> >>>>>> You already do it two times: >>>>>> 179 List tml >>>>>> 180 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> >>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>> static final List MLIST = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> and then use the mlist in other places where it is needed: >>>>>> >>>>>> 75 String params = MLIST.stream() >>>>>> ... >>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>> MethodData(MLIST.get(i).getName(), >>>>>> ... >>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>> 240 >>>>>> sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>> These lines will go away: >>>>>> 179 List tml >>>>>> 180 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> >>>>>> >>>>>> Both private static classes are inner classes of the public one. >>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>> no prefixing. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> >>>>>>>> It looks good in general. >>>>>>>> Some minor comments are below. >>>>>>>> >>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>> >>>>>>>> >>>>>>>> 42 public static final String >>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>> >>>>>>>> >>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>> >>>>>>>> 84 >>>>>>>> DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>> >>>>>>>> >>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>> 61 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>> ... >>>>>>>> 80 >>>>>>>> runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>>>> 81 >>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>> >>>>>>>> 75 String params = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>> ... >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>> It can be cached at the top and re-used. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review changes for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>> codecache feature >>>>>>>>> >>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>> analyzing results using class >>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>> usefull common code. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>> >>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>> also applied. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- diff -r 89977bee2ddd test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,305 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import com.oracle.java.testlibrary.Asserts; +import com.oracle.java.testlibrary.JDKToolFinder; +import com.oracle.java.testlibrary.OutputAnalyzer; +import com.oracle.java.testlibrary.Utils; +import com.oracle.java.testlibrary.dtrace.DtraceResultsAnalyzer; +import com.oracle.java.testlibrary.dtrace.DtraceRunner; +import java.io.IOException; +import java.lang.reflect.Executable; +import java.nio.file.Files; +import java.nio.file.Paths; +import java.util.Arrays; +import java.util.Collections; +import java.util.HashMap; +import java.util.HashSet; +import java.util.List; +import java.util.Map; +import java.util.Random; +import java.util.Set; +import java.util.regex.Matcher; +import java.util.regex.Pattern; +import java.util.stream.Collectors; + +/* + * @test SegmentedCodeCacheDtraceTest + * @requires os.family=="solaris" + * @library /testlibrary /compiler/testlibrary + * @build SegmentedCodeCacheDtraceTestWorker + * @run main ClassFileInstaller sun.hotspot.WhiteBox + * sun.hotspot.WhiteBox$WhiteBoxPermission + * @run main/othervm/timeout=600 -Xbootclasspath/a:. -XX:+TieredCompilation + * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI + * SegmentedCodeCacheDtraceTest + * @summary testing of dtrace for segmented code cache + */ +public class SegmentedCodeCacheDtraceTest { + + private static final String WORKER_CLASS_NAME + = SegmentedCodeCacheDtraceTestWorker.class.getName(); + private static final String JAVA_OPTS = " -XX:+DTraceMethodProbes " + + "-Xbootclasspath/a:" + System.getProperty("test.classes") + " " + + "-XX:+UnlockDiagnosticVMOptions " + + "-XX:+WhiteBoxAPI -XX:+SegmentedCodeCache " + + "-XX:CompileCommand=compileonly," + + WORKER_CLASS_NAME + "::* " + + " -classpath " + System.getProperty("test.class.path") + " " + + String.join(" ", Utils.getTestJavaOpts()); + private static final String DTRACE_SCRIPT + = "SegmentedCodeCacheDtraceTestScript.d"; + private static final List MLIST = + SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; + private static final int WORKER_METHODS_COUNT = MLIST.size(); + + private void runTest(TestCombination tc) { + String params = MLIST.stream() + .map(Executable::getName) + .map(x -> tc.data.get(x).compileLevel + " " + tc.data.get(x).isInlined) + .collect(Collectors.joining(" ")); + DtraceRunner runner = new DtraceRunner(); + runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, + WORKER_CLASS_NAME, params, Paths.get(System.getProperty("test.src"), + DTRACE_SCRIPT).toString(), + DtraceRunner.PERMIT_DESTRUCTIVE_ACTIONS_DTRACE_OPTION, + new SegmentedCodeCacheDtraceResultsAnalyzer()); + } + + private static TestCombination generateUniqueCombination( + int[] availableLevels, Set combinations) { + int len = availableLevels.length; + /* first, check if we're out of combinations. */ + int maxCombinationsCount + = (1 << WORKER_METHODS_COUNT) + * (int) Math.pow(len, WORKER_METHODS_COUNT); + if (combinations.size() == maxCombinationsCount) { + return null; + } + Random r = Utils.getRandomInstance(); + while (combinations.size() < maxCombinationsCount) { + int levels[] = new int[WORKER_METHODS_COUNT]; + boolean inlines[] = new boolean[WORKER_METHODS_COUNT]; + for (int i = 0; i < WORKER_METHODS_COUNT; i++) { + levels[i] = availableLevels[r.nextInt(len)]; + inlines[i] = r.nextBoolean(); + } + TestCombination tc = new TestCombination(levels, inlines); + if (combinations.add(tc)) { + return tc; + } + } + return null; + } + + public static void main(String args[]) { + int iterations + = Integer.getInteger("com.oracle.java.testlibrary.iterations", 1); + if (!DtraceRunner.dtraceAvailable()) { + System.out.println("INFO: There is no dtrace avaiable. Skipping."); + return; + } + int[] availableLevels = CompilerUtils.getAvailableCompilationLevels(); + // adding one more entry(zero) for interpeter + availableLevels + = Arrays.copyOf(availableLevels, availableLevels.length + 1); + Set combinations = new HashSet<>(); + for (int i = 0; i < iterations; i++) { + TestCombination tc + = generateUniqueCombination(availableLevels, combinations); + if (tc == null) { + System.out.println("INFO: no more combinations available"); + return; + } else { + System.out.println("INFO: Running testcase for: " + tc); + new SegmentedCodeCacheDtraceTest().runTest(tc); + } + } + } + + private static class MethodData { + + public final int compileLevel; + public final boolean isInlined; + public final String name; + + public MethodData(String name, int compileLevel, boolean isInlined) { + this.name = name; + this.compileLevel = compileLevel; + this.isInlined = isInlined; + } + + @Override + public boolean equals(Object o) { + if (o == null || !(o instanceof MethodData)) { + return false; + } + MethodData md = (MethodData) o; + return md.compileLevel == compileLevel + && md.isInlined == isInlined + && md.name.equals(name); + } + + @Override + public int hashCode() { + return 100 * name.hashCode() + 10 * compileLevel + (isInlined ? 1 : 0); + } + + @Override + public String toString() { + return name + " " + compileLevel + " " + isInlined; + } + } + + private static class TestCombination { + + private final Map data; + + public TestCombination(int compLevels[], boolean inlines[]) { + Map d = new HashMap<>(); + for (int i = 0; i < MLIST.size(); i++) { + d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), + compLevels[i], inlines[i])); + } + data = Collections.unmodifiableMap(d); + } + + @Override + public boolean equals(Object o) { + if (o == null || !(o instanceof TestCombination)) { + return false; + } + TestCombination second = (TestCombination) o; + return second.data.equals(data); + } + + @Override + public int hashCode() { + int sum = 0; + for (MethodData md : data.values()) { + sum += md.hashCode(); + } + return sum; + } + + private String getMethodDescString(MethodData md) { + return (md == null) + ? null + : String.format("Method %s compilation level %d and %s", + md.name, md.compileLevel, + md.isInlined ? "inlined" : "not inlined"); + } + + @Override + public String toString() { + return data.values().stream().map(m -> getMethodDescString(m)) + .collect(Collectors.joining(Utils.NEW_LINE, + "Combination: ", "")); + } + } + + private class SegmentedCodeCacheDtraceResultsAnalyzer + implements DtraceResultsAnalyzer { + + private static final int EXPECTED_MATCH_COUNT = 2; + + private final Pattern checkPattern; + + public SegmentedCodeCacheDtraceResultsAnalyzer() { + String workerClassRegExp = "\\s*" + WORKER_CLASS_NAME + "\\."; + String delimeter = "\\(\\)V\\*?" + workerClassRegExp; + String suffix = "test\\(\\)V\\*?" + workerClassRegExp + + "main\\(\\[Ljava\\/lang\\/String;\\)V"; + StringBuilder sb = new StringBuilder(workerClassRegExp); + // method order is important, so, going from list tail to head, + // accoring to call order representation in stacktrace + for (int i = MLIST.size() - 1; i > -1; i--) { + sb.append(MLIST.get(i).getName()).append(delimeter); + } + sb.append(suffix); + checkPattern = Pattern.compile(sb.toString()); + /* such pattern match should pass on a stacktrace like + CPU ID FUNCTION:NAME + 0 53573 __1cNSharedRuntimeTdtrace_method_entry6FpnKJavaThread_pnGMethod__i_:method-entry ustack: + + libjvm.so`__1cNSharedRuntimeTdtrace_method_entry6FpnKJavaThread_pnGMethod__i_+0x39c + SegmentedCodeCacheDtraceTestWorker.baz()V* + SegmentedCodeCacheDtraceTestWorker.bar()V + SegmentedCodeCacheDtraceTestWorker.foo()V* + SegmentedCodeCacheDtraceTestWorker.test()V + SegmentedCodeCacheDtraceTestWorker.main([Ljava/lang/String;)V + 0xffffffff6b0004b8 + libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x94c + libjvm.so`__1cRjni_invoke_static6FpnHJNIEnv__pnJJavaValue_pnI_jobject_nLJNICallType_pnK_jmethodID_pnSJNI_ArgumentPusher_pnGThread__v_+0xa64 + libjvm.so`jni_CallStaticVoidMethod+0x508 + libjli.so`JavaMain+0x584 + libc.so.1`_lwp_start + jstack: + + libjvm.so`__1cNSharedRuntimeTdtrace_method_entry6FpnKJavaThread_pnGMethod__i_+0x39c + SegmentedCodeCacheDtraceTestWorker.baz()V* + SegmentedCodeCacheDtraceTestWorker.bar()V + SegmentedCodeCacheDtraceTestWorker.foo()V* + SegmentedCodeCacheDtraceTestWorker.test()V + SegmentedCodeCacheDtraceTestWorker.main([Ljava/lang/String;)V + 0xffffffff6b0004b8 + libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x94c + libjvm.so`__1cRjni_invoke_static6FpnHJNIEnv__pnJJavaValue_pnI_jobject_nLJNICallType_pnK_jmethodID_pnSJNI_ArgumentPusher_pnGThread__v_+0xa64 + libjvm.so`jni_CallStaticVoidMethod+0x508 + libjli.so`JavaMain+0x584 + libc.so.1`_lwp_start + */ + } + + protected List loadLog(String dtraceOutFile) throws IOException { + return Files.readAllLines(Paths.get(dtraceOutFile)); + } + + @Override + public void analyze(OutputAnalyzer oa, String dtraceOutFilePath) { + List dOut; + try { + dOut = loadLog(dtraceOutFilePath); + } catch (IOException e) { + throw new Error("Can't load log", e); + } + StringBuilder allDtraceOutput = new StringBuilder(); + for (String entry : dOut) { + allDtraceOutput.append(entry); + } + int matchCount = getMatchCount(allDtraceOutput.toString()); + Asserts.assertEQ(matchCount, EXPECTED_MATCH_COUNT, + "Unexpected output match amount. expected: " + + EXPECTED_MATCH_COUNT + " but found " + matchCount); + } + + protected int getMatchCount(String source) { + Matcher m = checkPattern.matcher(source); + int matchCount = 0; + while (m.find()) { + matchCount++; + } + return matchCount; + } + } +} diff -r 89977bee2ddd test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTestScript.d --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTestScript.d Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,33 @@ +#!/usr/sbin/dtrace -s + +/* + Copyright (c) 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 + under the terms of the GNU General Public License version 2 only, as + published by the Free Software Foundation. + + This code is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + version 2 for more details (a copy is included in the LICENSE file that + accompanied this code). + + You should have received a copy of the GNU General Public License version + 2 along with this work; if not, write to the Free Software Foundation, + Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + + Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + or visit www.oracle.com if you need additional information or have any + questions. +*/ + +hotspot$target:::method-entry +/ copyinstr(arg3, arg4) == "baz" / +{ + printf("ustack:\n"); + ustack(50, 500); + printf("jstack:\n"); + jstack(); +} diff -r 89977bee2ddd test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTestWorker.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTestWorker.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,113 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import com.oracle.java.testlibrary.Utils; +import java.lang.reflect.Executable; +import java.util.ArrayList; +import java.util.Arrays; +import java.util.Collections; +import java.util.List; +import sun.hotspot.WhiteBox; + +public class SegmentedCodeCacheDtraceTestWorker { + + private static final String METHOD1_NAME = "foo"; + private static final String METHOD2_NAME = "bar"; + private static final String METHOD3_NAME = "baz"; + public static final List TESTED_METHODS_LIST; + private final WhiteBox wb; + private final int compLevels[]; + + static { + List methods = new ArrayList<>(); + try { + // method order is important. Need to place methods in call order, + // to be able to verify results later + methods.add(SegmentedCodeCacheDtraceTestWorker.class.getMethod(METHOD1_NAME)); + methods.add(SegmentedCodeCacheDtraceTestWorker.class.getMethod(METHOD2_NAME)); + methods.add(SegmentedCodeCacheDtraceTestWorker.class.getMethod(METHOD3_NAME)); + } catch (NoSuchMethodException e) { + throw new Error("TESTBUG: no expected method found", e); + } + TESTED_METHODS_LIST = Collections.unmodifiableList(methods); + } + + protected static final boolean BACKGROUND_COMPILATION + = WhiteBox.getWhiteBox().getBooleanVMFlag("BackgroundCompilation"); + + public static void main(String[] args) { + if (args.length != 2 * TESTED_METHODS_LIST.size()) { + throw new Error("Usage: java " + + " " + + " "); + } else { + int compLevels[] = new int[TESTED_METHODS_LIST.size()]; + boolean inlines[] = new boolean[TESTED_METHODS_LIST.size()]; + for (int i = 0; i < TESTED_METHODS_LIST.size(); i++) { + compLevels[i] = Integer.parseInt(args[2 * i]); + inlines[i] = Boolean.parseBoolean(args[2 * i + 1]); + } + new SegmentedCodeCacheDtraceTestWorker(compLevels, inlines).test(); + } + } + + public SegmentedCodeCacheDtraceTestWorker(int compLevels[], boolean inlines[]) { + wb = WhiteBox.getWhiteBox(); + this.compLevels = Arrays.copyOf(compLevels, compLevels.length); + for (int i = 0; i < compLevels.length; i++) { + if (inlines[i]) { + wb.testSetForceInlineMethod(TESTED_METHODS_LIST.get(i), true); + } else { + wb.testSetDontInlineMethod(TESTED_METHODS_LIST.get(i), true); + } + } + } + + private void waitForCompilation(Executable executable, int compLevel) { + if (compLevel > 0) { + Utils.waitForCondition(() -> wb.isMethodCompiled(executable)); + } + } + + protected void test() { + for (int i = 0; i < TESTED_METHODS_LIST.size(); i++) { + Executable method = TESTED_METHODS_LIST.get(i); + int compLevel = compLevels[i]; + wb.enqueueMethodForCompilation(method, compLevel); + waitForCompilation(method, compLevel); + } + foo(); + } + + public static void foo() { + bar(); + } + + public static void bar() { + baz(); + } + + public static void baz() { + System.out.println("Reached baz method"); + } +} diff -r 89977bee2ddd test/compiler/testlibrary/CompilerUtils.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/testlibrary/CompilerUtils.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,61 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import com.oracle.java.testlibrary.Asserts; +import com.oracle.java.testlibrary.Platform; +import java.util.stream.IntStream; +import sun.hotspot.WhiteBox; + +public class CompilerUtils { + + private CompilerUtils() { + // to prevent from instantiation + } + + /** + * Returns available compilation levels + * + * @return int array with compilation levels + */ + public static int[] getAvailableCompilationLevels() { + if (!WhiteBox.getWhiteBox().getBooleanVMFlag("UseCompiler")) { + return new int[0]; + } + if (WhiteBox.getWhiteBox().getBooleanVMFlag("TieredCompilation")) { + Long flagValue = WhiteBox.getWhiteBox() + .getIntxVMFlag("TieredStopAtLevel"); + int maxLevel = flagValue.intValue(); + Asserts.assertEQ(new Long(maxLevel), flagValue, + "TieredStopAtLevel has value out of int capacity"); + return IntStream.rangeClosed(1, maxLevel).toArray(); + } else { + if (Platform.isServer()) { + return new int[]{4}; + } + if (Platform.isClient() || Platform.isMinimal()) { + return new int[]{1}; + } + } + return new int[0]; + } +} diff -r 89977bee2ddd test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceResultsAnalyzer.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceResultsAnalyzer.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,29 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ +package com.oracle.java.testlibrary.dtrace; + +import com.oracle.java.testlibrary.OutputAnalyzer; + +public interface DtraceResultsAnalyzer { + public void analyze(OutputAnalyzer oa, String logFilePath); +} diff -r 89977bee2ddd test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,122 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ +package com.oracle.java.testlibrary.dtrace; + +import com.oracle.java.testlibrary.Asserts; +import com.oracle.java.testlibrary.OutputAnalyzer; +import java.io.File; +import java.io.IOException; +import java.util.ArrayList; +import java.util.List; + +public class DtraceRunner { + + private static final String DTRACE_DEFAULT_PATH = "/usr/sbin/dtrace"; + private static final String DTRACE_PATH_PROPERTY + = "com.oracle.test.dtrace.path"; + private static final String OUTPUT_FILE_DTRACE_OPTION = "o"; + private static final String RUN_COMMAND_DTRACE_OPTION = "c"; + private static final String RUN_SCRIPT_DTRACE_OPTION = "s"; + private static final String ALLOW_ZERO_PROBE_DESCRIPTION_DTRACE_OPTION = "Z"; + private static final String DTRACE_OPTION_PREFIX = "-"; + public static final String PERMIT_DESTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; + public static final String DTRACE_OUT_LOG = "dtrace.out"; + + private final String dtraceExecutable; + + public DtraceRunner() { + dtraceExecutable = getDtracePath(); + } + + private List getLaunchCmd(String java, String javaOpts, + String execClass, String testArgs, String dtraceScript, + String dtraceAddOpts) { + Asserts.assertTrue(!java.matches("\\s"), "Current dtrace implementation" + + " can't handle whitespaces in application path"); + List result = new ArrayList<>(); + result.add(dtraceExecutable); + result.add(DTRACE_OPTION_PREFIX + System.getProperty("sun.arch.data.model")); + result.add(DTRACE_OPTION_PREFIX + + ALLOW_ZERO_PROBE_DESCRIPTION_DTRACE_OPTION + + ((dtraceAddOpts == null) ? "" : dtraceAddOpts) + + RUN_SCRIPT_DTRACE_OPTION); // run_script should be last one + result.add(dtraceScript); + result.add(DTRACE_OPTION_PREFIX + OUTPUT_FILE_DTRACE_OPTION); + result.add(DTRACE_OUT_LOG); + result.add(DTRACE_OPTION_PREFIX + RUN_COMMAND_DTRACE_OPTION); + result.add(java + " " + javaOpts + " " + execClass + " " + testArgs); + return result; + } + + private void backupLogFile(File file) { + if (file.exists()) { + file.renameTo(new File(file.getPath() + ".bak")); + } + } + + public void runDtrace(String java, String javaOpts, String execClass, + String testArgs, String dtraceScript, String dtraceAddOpts, + DtraceResultsAnalyzer analyzer) { + backupLogFile(new File(DTRACE_OUT_LOG)); + ProcessBuilder pbuilder = new ProcessBuilder( + getLaunchCmd(java, javaOpts, execClass, testArgs, + dtraceScript, dtraceAddOpts)); + OutputAnalyzer oa; + try { + oa = new OutputAnalyzer(pbuilder.start()); + } catch (IOException e) { + throw new Error("TESTBUG: Can't start process", e); + } + analyzer.analyze(oa, DTRACE_OUT_LOG); + } + + public static boolean dtraceAvailable() { + String path = getDtracePath(); + if (path == null) { + return false; + } + // now we'll launch dtrace to trace itself just to be sure it works + // and have all additional previleges set + ProcessBuilder pbuilder = new ProcessBuilder(path, path); + try { + Process proc = pbuilder.start(); + proc.waitFor(); + if (proc.exitValue() != 0) { + return false; + } + } catch (IOException | InterruptedException e) { + return false; + } + return true; + } + + private static String getDtracePath() { + String propPath = System.getProperty(DTRACE_PATH_PROPERTY); + if (propPath != null && new File(propPath).exists()) { + return propPath; + } else if (new File(DTRACE_DEFAULT_PATH).exists()) { + return DTRACE_DEFAULT_PATH; + } + return null; + } +} From dmitrij.pochepko at oracle.com Thu Dec 25 12:19:06 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 25 Dec 2014 15:19:06 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549BE60D.2060501@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> Message-ID: <549C00BA.6040106@oracle.com> Hi, new webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 I've added @bug tag and moved process guard to DtraceRunner::dtraceAvailable Thanks, Dmitrij > Hi Dmitrij, > > DtraceRunner::runDtrace prints warning in case of non-zero exit code. > It means that the test will pass even if traced JVM crashed. > > I can name several issues that were found accidentally, because tests > didn't care about a crash. > > Are there any other sane reasons for DTrace to return non-zero exit code > except lack of privileges? > Igor's suggestion will prevent us from running DTrace without required > privileges, so I'd prefer to see the test failure instead of a warning > in case > of non-zero exit code returned by DTrace. > > Also, please add @bug to the test. > > Thanks, > Filipp. > > On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >> I'd prefer to check privileges by running dtrace against dtrace; >> and do it in DtraceRunner::dtraceAvailable, smth like >> >>> result = false; >>> dtrace = getDtracePath(); >>> if ($dtrace) { >>> $dtrace $dtrace >>> result = $? == 0; >>> } >>> return $result; >> >> >> Igor >> >> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> i've placed a guard which skips test in case dtrace exits with non-zero >>> code. >>> >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>> >>> Thanks, >>> Dmitrij >>>> Hi, >>>> >>>> There is one more issues related to these tests(not directly). >>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>> additional previleges for launching user. >>>> Perhaps it's just user to be granted previleges in jprt solaris >>>> hosts... >>>> Not sure about some guard in tests... the only way i know so far is to >>>> just try launching dtrace and parse output >>>> saying about missing previleges, but it doesn't seem to be good >>>> solution. >>>> I think test should assume to be launched in correct environment and >>>> in case it's failed because of previleges, evaluating engineer >>>> starting to work on respective env. issue... >>>> Does anybody have some additional concerns? >>>> >>>> Thanks, >>>> Dmitrij >>>> >>>>> Hi Dmitrij, >>>>> >>>>> >>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>> >>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>> 42 public static final String >>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>> >>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>> >>>>> >>>>> Otherwise, looks good. >>>>> Please, consider it reviewed (no need to re-review). >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> please review updated webrev >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Thank you for catching these issues. >>>>>>>> I have a question regarding last comment: does it make any >>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>> times"? >>>>>>> >>>>>>> Yes, it does (it is a minor issue though). >>>>>>> It is because the class names are pretty big. >>>>>>> It would simplify the code and improve readability, right? >>>>>>> >>>>>>> You already do it two times: >>>>>>> 179 List tml >>>>>>> 180 = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> ... >>>>>>> 235 List mlist >>>>>>> 236 = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> >>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>> static final List MLIST = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> and then use the mlist in other places where it is needed: >>>>>>> >>>>>>> 75 String params = MLIST.stream() >>>>>>> ... >>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>> ... >>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>> These lines will go away: >>>>>>> 179 List tml >>>>>>> 180 = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> ... >>>>>>> 235 List mlist >>>>>>> 236 = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> >>>>>>> >>>>>>> Both private static classes are inner classes of the public one. >>>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>>> no prefixing. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> >>>>>>>>> It looks good in general. >>>>>>>>> Some minor comments are below. >>>>>>>>> >>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>> >>>>>>>>> >>>>>>>>> 42 public static final String >>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>> >>>>>>>>> >>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>> >>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>> >>>>>>>>> >>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>> 61 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>> ... >>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>> JAVA_OPTS, >>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>> >>>>>>>>> 75 String params = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>> ... >>>>>>>>> 179 List tml >>>>>>>>> 180 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> ... >>>>>>>>> 235 List mlist >>>>>>>>> 236 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>> It can be cached at the top and re-used. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review changes for >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>> codecache feature >>>>>>>>>> >>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>> analyzing results using class >>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>> usefull common code. >>>>>>>>>> >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>> also applied. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dmitrij >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From igor.ignatyev at oracle.com Thu Dec 25 12:19:13 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 15:19:13 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549C00BA.6040106@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> Message-ID: <549C00C1.2020001@oracle.com> looks good to me. Thanks, Igor On 12/25/2014 03:19 PM, Dmitrij Pochepko wrote: > Hi, > > new webrev: > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 > I've added @bug tag > and moved process guard to DtraceRunner::dtraceAvailable > > Thanks, > Dmitrij >> Hi Dmitrij, >> >> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >> It means that the test will pass even if traced JVM crashed. >> >> I can name several issues that were found accidentally, because tests >> didn't care about a crash. >> >> Are there any other sane reasons for DTrace to return non-zero exit code >> except lack of privileges? >> Igor's suggestion will prevent us from running DTrace without required >> privileges, so I'd prefer to see the test failure instead of a warning >> in case >> of non-zero exit code returned by DTrace. >> >> Also, please add @bug to the test. >> >> Thanks, >> Filipp. >> >> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>> I'd prefer to check privileges by running dtrace against dtrace; >>> and do it in DtraceRunner::dtraceAvailable, smth like >>> >>>> result = false; >>>> dtrace = getDtracePath(); >>>> if ($dtrace) { >>>> $dtrace $dtrace >>>> result = $? == 0; >>>> } >>>> return $result; >>> >>> >>> Igor >>> >>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> i've placed a guard which skips test in case dtrace exits with non-zero >>>> code. >>>> >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi, >>>>> >>>>> There is one more issues related to these tests(not directly). >>>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>>> additional previleges for launching user. >>>>> Perhaps it's just user to be granted previleges in jprt solaris >>>>> hosts... >>>>> Not sure about some guard in tests... the only way i know so far is to >>>>> just try launching dtrace and parse output >>>>> saying about missing previleges, but it doesn't seem to be good >>>>> solution. >>>>> I think test should assume to be launched in correct environment and >>>>> in case it's failed because of previleges, evaluating engineer >>>>> starting to work on respective env. issue... >>>>> Does anybody have some additional concerns? >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>> >>>>>> Hi Dmitrij, >>>>>> >>>>>> >>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>> >>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>> 42 public static final String >>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>> >>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>> >>>>>> >>>>>> Otherwise, looks good. >>>>>> Please, consider it reviewed (no need to re-review). >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> please review updated webrev >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Thank you for catching these issues. >>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>> times"? >>>>>>>> >>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>> It is because the class names are pretty big. >>>>>>>> It would simplify the code and improve readability, right? >>>>>>>> >>>>>>>> You already do it two times: >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> >>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>> static final List MLIST = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>> >>>>>>>> 75 String params = MLIST.stream() >>>>>>>> ... >>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>> ... >>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>> These lines will go away: >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> >>>>>>>> >>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>>>> no prefixing. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It looks good in general. >>>>>>>>>> Some minor comments are below. >>>>>>>>>> >>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 42 public static final String >>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>> >>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>> 61 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>> ... >>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>>> JAVA_OPTS, >>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>> >>>>>>>>>> 75 String params = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>> ... >>>>>>>>>> 179 List tml >>>>>>>>>> 180 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> ... >>>>>>>>>> 235 List mlist >>>>>>>>>> 236 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review changes for >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>> codecache feature >>>>>>>>>>> >>>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>>> analyzing results using class >>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>> usefull common code. >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>>> also applied. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From filipp.zhinkin at oracle.com Thu Dec 25 12:12:45 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 16:12:45 +0400 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549C00BA.6040106@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> Message-ID: <549BFF3D.2060905@oracle.com> Dmitrij, I believe that it should be "@bug 8015774". Now DtraceRunner::runDtrace isn't checking exit code at all. I think that it should assert on zero exit code. Thanks, Filipp. On 12/25/2014 04:19 PM, Dmitrij Pochepko wrote: > Hi, > > new webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 > I've added @bug tag > and moved process guard to DtraceRunner::dtraceAvailable > > Thanks, > Dmitrij >> Hi Dmitrij, >> >> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >> It means that the test will pass even if traced JVM crashed. >> >> I can name several issues that were found accidentally, because tests >> didn't care about a crash. >> >> Are there any other sane reasons for DTrace to return non-zero exit code >> except lack of privileges? >> Igor's suggestion will prevent us from running DTrace without required >> privileges, so I'd prefer to see the test failure instead of a warning in case >> of non-zero exit code returned by DTrace. >> >> Also, please add @bug to the test. >> >> Thanks, >> Filipp. >> >> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>> I'd prefer to check privileges by running dtrace against dtrace; >>> and do it in DtraceRunner::dtraceAvailable, smth like >>> >>>> result = false; >>>> dtrace = getDtracePath(); >>>> if ($dtrace) { >>>> $dtrace $dtrace >>>> result = $? == 0; >>>> } >>>> return $result; >>> >>> >>> Igor >>> >>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> i've placed a guard which skips test in case dtrace exits with non-zero >>>> code. >>>> >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi, >>>>> >>>>> There is one more issues related to these tests(not directly). >>>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>>> additional previleges for launching user. >>>>> Perhaps it's just user to be granted previleges in jprt solaris hosts... >>>>> Not sure about some guard in tests... the only way i know so far is to >>>>> just try launching dtrace and parse output >>>>> saying about missing previleges, but it doesn't seem to be good solution. >>>>> I think test should assume to be launched in correct environment and >>>>> in case it's failed because of previleges, evaluating engineer >>>>> starting to work on respective env. issue... >>>>> Does anybody have some additional concerns? >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>> >>>>>> Hi Dmitrij, >>>>>> >>>>>> >>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>> >>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>> 42 public static final String >>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>> >>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>> >>>>>> >>>>>> Otherwise, looks good. >>>>>> Please, consider it reviewed (no need to re-review). >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> please review updated webrev >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Thank you for catching these issues. >>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>> times"? >>>>>>>> >>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>> It is because the class names are pretty big. >>>>>>>> It would simplify the code and improve readability, right? >>>>>>>> >>>>>>>> You already do it two times: >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> >>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>> static final List MLIST = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>> >>>>>>>> 75 String params = MLIST.stream() >>>>>>>> ... >>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>> ... >>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>> These lines will go away: >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> >>>>>>>> >>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>>>> no prefixing. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It looks good in general. >>>>>>>>>> Some minor comments are below. >>>>>>>>>> >>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>> >>>>>>>>>> 42 public static final String >>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>> >>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>> ... >>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>> >>>>>>>>>> 75 String params = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>> ... >>>>>>>>>> 179 List tml >>>>>>>>>> 180 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> ... >>>>>>>>>> 235 List mlist >>>>>>>>>> 236 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review changes for >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>> codecache feature >>>>>>>>>>> >>>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>>> analyzing results using class >>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>> usefull common code. >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>>> also applied. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From igor.ignatyev at oracle.com Thu Dec 25 12:22:52 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 15:22:52 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549BFF3D.2060905@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> <549BFF3D.2060905@oracle.com> Message-ID: <549C019C.4070803@oracle.com> On 12/25/2014 03:12 PM, Filipp Zhinkin wrote: > Dmitrij, > > I believe that it should be "@bug 8015774". agree > > Now DtraceRunner::runDtrace isn't checking exit code at all. > I think that it should assert on zero exit code. no, it shouldn't it should be a part of custom implementation of DtraceResultsAnalyzer::analyze. Dima, could you please add exit code check into SegmentedCodeCacheDtraceTest.SegmentedCodeCacheDtraceResultsAnalyzer::analyze > > Thanks, > Filipp. > > On 12/25/2014 04:19 PM, Dmitrij Pochepko wrote: >> Hi, >> >> new webrev: >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 >> I've added @bug tag >> and moved process guard to DtraceRunner::dtraceAvailable >> >> Thanks, >> Dmitrij >>> Hi Dmitrij, >>> >>> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >>> It means that the test will pass even if traced JVM crashed. >>> >>> I can name several issues that were found accidentally, because tests >>> didn't care about a crash. >>> >>> Are there any other sane reasons for DTrace to return non-zero exit code >>> except lack of privileges? >>> Igor's suggestion will prevent us from running DTrace without required >>> privileges, so I'd prefer to see the test failure instead of a >>> warning in case >>> of non-zero exit code returned by DTrace. >>> >>> Also, please add @bug to the test. >>> >>> Thanks, >>> Filipp. >>> >>> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>>> I'd prefer to check privileges by running dtrace against dtrace; >>>> and do it in DtraceRunner::dtraceAvailable, smth like >>>> >>>>> result = false; >>>>> dtrace = getDtracePath(); >>>>> if ($dtrace) { >>>>> $dtrace $dtrace >>>>> result = $? == 0; >>>>> } >>>>> return $result; >>>> >>>> >>>> Igor >>>> >>>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> i've placed a guard which skips test in case dtrace exits with >>>>> non-zero >>>>> code. >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> Hi, >>>>>> >>>>>> There is one more issues related to these tests(not directly). >>>>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>>>> additional previleges for launching user. >>>>>> Perhaps it's just user to be granted previleges in jprt solaris >>>>>> hosts... >>>>>> Not sure about some guard in tests... the only way i know so far >>>>>> is to >>>>>> just try launching dtrace and parse output >>>>>> saying about missing previleges, but it doesn't seem to be good >>>>>> solution. >>>>>> I think test should assume to be launched in correct environment and >>>>>> in case it's failed because of previleges, evaluating engineer >>>>>> starting to work on respective env. issue... >>>>>> Does anybody have some additional concerns? >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>> >>>>>>> Hi Dmitrij, >>>>>>> >>>>>>> >>>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>>> >>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>> >>>>>>> 42 public static final String >>>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>> >>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>> >>>>>>> >>>>>>> Otherwise, looks good. >>>>>>> Please, consider it reviewed (no need to re-review). >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>>> Hi, >>>>>>>> please review updated webrev >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Thank you for catching these issues. >>>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>>> times"? >>>>>>>>> >>>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>>> It is because the class names are pretty big. >>>>>>>>> It would simplify the code and improve readability, right? >>>>>>>>> >>>>>>>>> You already do it two times: >>>>>>>>> 179 List tml >>>>>>>>> 180 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> ... >>>>>>>>> 235 List mlist >>>>>>>>> 236 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> >>>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>>> static final List MLIST = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>>> >>>>>>>>> 75 String params = MLIST.stream() >>>>>>>>> ... >>>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>>> ... >>>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>>> These lines will go away: >>>>>>>>> 179 List tml >>>>>>>>> 180 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> ... >>>>>>>>> 235 List mlist >>>>>>>>> 236 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> >>>>>>>>> >>>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>>> The MLIST will be in a context for the inner classes, and so, >>>>>>>>> needs >>>>>>>>> no prefixing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dmitrij >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It looks good in general. >>>>>>>>>>> Some minor comments are below. >>>>>>>>>>> >>>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 42 public static final String >>>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>>> >>>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>>> 61 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>>> ... >>>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>>>> JAVA_OPTS, >>>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), >>>>>>>>>>> params, >>>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>>> >>>>>>>>>>> 75 String params = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>>> ... >>>>>>>>>>> 179 List tml >>>>>>>>>>> 180 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> ... >>>>>>>>>>> 235 List mlist >>>>>>>>>>> 236 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review changes for >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>>> codecache feature >>>>>>>>>>>> >>>>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>>>> script is also present >>>>>>>>>>>> (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>>>> analyzing results using class >>>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>>> usefull common code. >>>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Additional note: Please note that this path assumes that fix >>>>>>>>>>>> for >>>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>>>> also applied. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dmitrij >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From dmitrij.pochepko at oracle.com Thu Dec 25 13:04:52 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 25 Dec 2014 16:04:52 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549C019C.4070803@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> <549BFF3D.2060905@oracle.com> <549C019C.4070803@oracle.com> Message-ID: <549C0B74.6000900@oracle.com> Hi, please take a look at fixed version http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.04 Thanks, Dmitrij > > On 12/25/2014 03:12 PM, Filipp Zhinkin wrote: >> Dmitrij, >> >> I believe that it should be "@bug 8015774". > agree >> >> Now DtraceRunner::runDtrace isn't checking exit code at all. >> I think that it should assert on zero exit code. > no, it shouldn't it should be a part of custom implementation of > DtraceResultsAnalyzer::analyze. > > Dima, could you please add exit code check into > SegmentedCodeCacheDtraceTest.SegmentedCodeCacheDtraceResultsAnalyzer::analyze > >> >> Thanks, >> Filipp. >> >> On 12/25/2014 04:19 PM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> new webrev: >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 >>> I've added @bug tag >>> and moved process guard to DtraceRunner::dtraceAvailable >>> >>> Thanks, >>> Dmitrij >>>> Hi Dmitrij, >>>> >>>> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >>>> It means that the test will pass even if traced JVM crashed. >>>> >>>> I can name several issues that were found accidentally, because tests >>>> didn't care about a crash. >>>> >>>> Are there any other sane reasons for DTrace to return non-zero exit >>>> code >>>> except lack of privileges? >>>> Igor's suggestion will prevent us from running DTrace without required >>>> privileges, so I'd prefer to see the test failure instead of a >>>> warning in case >>>> of non-zero exit code returned by DTrace. >>>> >>>> Also, please add @bug to the test. >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>>>> I'd prefer to check privileges by running dtrace against dtrace; >>>>> and do it in DtraceRunner::dtraceAvailable, smth like >>>>> >>>>>> result = false; >>>>>> dtrace = getDtracePath(); >>>>>> if ($dtrace) { >>>>>> $dtrace $dtrace >>>>>> result = $? == 0; >>>>>> } >>>>>> return $result; >>>>> >>>>> >>>>> Igor >>>>> >>>>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> i've placed a guard which skips test in case dtrace exits with >>>>>> non-zero >>>>>> code. >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>> Hi, >>>>>>> >>>>>>> There is one more issues related to these tests(not directly). >>>>>>> Currently, dtrace tests can't be run in jprt, because dtrace >>>>>>> require >>>>>>> additional previleges for launching user. >>>>>>> Perhaps it's just user to be granted previleges in jprt solaris >>>>>>> hosts... >>>>>>> Not sure about some guard in tests... the only way i know so far >>>>>>> is to >>>>>>> just try launching dtrace and parse output >>>>>>> saying about missing previleges, but it doesn't seem to be good >>>>>>> solution. >>>>>>> I think test should assume to be launched in correct environment >>>>>>> and >>>>>>> in case it's failed because of previleges, evaluating engineer >>>>>>> starting to work on respective env. issue... >>>>>>> Does anybody have some additional concerns? >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>> >>>>>>>> Hi Dmitrij, >>>>>>>> >>>>>>>> >>>>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>>>> >>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>> >>>>>>>> >>>>>>>> 42 public static final String >>>>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>> >>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>> >>>>>>>> >>>>>>>> Otherwise, looks good. >>>>>>>> Please, consider it reviewed (no need to re-review). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi, >>>>>>>>> please review updated webrev >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Thank you for catching these issues. >>>>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>>>> times"? >>>>>>>>>> >>>>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>>>> It is because the class names are pretty big. >>>>>>>>>> It would simplify the code and improve readability, right? >>>>>>>>>> >>>>>>>>>> You already do it two times: >>>>>>>>>> 179 List tml >>>>>>>>>> 180 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> ... >>>>>>>>>> 235 List mlist >>>>>>>>>> 236 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> >>>>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>>>> static final List MLIST = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>>>> >>>>>>>>>> 75 String params = MLIST.stream() >>>>>>>>>> ... >>>>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>>>> ... >>>>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>>>> These lines will go away: >>>>>>>>>> 179 List tml >>>>>>>>>> 180 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> ... >>>>>>>>>> 235 List mlist >>>>>>>>>> 236 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>>>> The MLIST will be in a context for the inner classes, and so, >>>>>>>>>> needs >>>>>>>>>> no prefixing. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It looks good in general. >>>>>>>>>>>> Some minor comments are below. >>>>>>>>>>>> >>>>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 42 public static final String >>>>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>>>> 61 = >>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>>>> ... >>>>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>>>>> JAVA_OPTS, >>>>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), >>>>>>>>>>>> params, >>>>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>>>> >>>>>>>>>>>> 75 String params = >>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>>>> >>>>>>>>>>>> ... >>>>>>>>>>>> 179 List tml >>>>>>>>>>>> 180 = >>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>>> ... >>>>>>>>>>>> 235 List mlist >>>>>>>>>>>> 236 = >>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review changes for >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>>>> codecache feature >>>>>>>>>>>>> >>>>>>>>>>>>> Description: this fix introduce dtrace test, which verify >>>>>>>>>>>>> that >>>>>>>>>>>>> different combinations of available compile levels(and, in >>>>>>>>>>>>> case >>>>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A >>>>>>>>>>>>> dtrace d >>>>>>>>>>>>> script is also present >>>>>>>>>>>>> (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and >>>>>>>>>>>>> then >>>>>>>>>>>>> analyzing results using class >>>>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>>>> usefull common code. >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Additional note: Please note that this path assumes that fix >>>>>>>>>>>>> for >>>>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for >>>>>>>>>>>>> JDK-8059613 is >>>>>>>>>>>>> also applied. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Dmitrij >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> From dmitry.samersoff at oracle.com Thu Dec 25 13:00:27 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 25 Dec 2014 16:00:27 +0300 Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved In-Reply-To: <05478eef-6b62-4087-a888-aef42a437259@default> References: <05478eef-6b62-4087-a888-aef42a437259@default> Message-ID: <549C0A6B.60909@oracle.com> I'll push it later today. On 2014-12-25 15:45, Alexander Kulyakhtin wrote: > Hi, > > Could someone, please, push the fix reviewed below? > > This is just one-line change to quarantine a test while the fix is being > worked on. > > bug: https://bugs.openjdk.java.net/browse/JDK-8068242 > webrev: > http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00 > / > > Thank you very much, > Alexander > > ----- Original Message ----- > From: jaroslav.bachorik at oracle.com > To: dmitry.samersoff at oracle.com, serviceability-dev at openjdk.java.net, > alexander.kulyakhtin at oracle.com > Sent: Wednesday, December 24, 2014 11:07:58 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: Review request JDK-8068242: quarantine the > test IsModifiableClassAgent.java until JDK-8068162 is resolved > > Reviewed. > > Merry Christmas, ho-ho-ho :) > > On 24 December 2014 17:11:15 CET, dmitry.samersoff at oracle.com wrote: > > Looks good for me (not a reviewer). > > --Dmitry > > > > -----Original Message----- > From: Alexander Kulyakhtin > To: serviceability-dev at openjdk.java.net > Cc: "Dmitry ?????????? Samersoff" , > Serguei Vladimirovich Spitsyn > Sent: Wed, 24 Dec 2014 17:32 > Subject: Review request JDK-8068242: quarantine the test > IsModifiableClassAgent.java until JDK-8068162 is resolved > > Hi, > > Could I, please, have a review of this fix. This is a oneline change > to quarantine a test until JDK-8068162 is resolved > > bug: https://bugs.openjdk.java.net/browse/JDK-8068242 > webrev: > http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00/ > > @ignore JDK-8068162 added to the test to have it > ignored until JDK-8068162 is resolved > > Thanks, > Alexander > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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 filipp.zhinkin at oracle.com Thu Dec 25 13:05:12 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 17:05:12 +0400 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549C0B74.6000900@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> <549BFF3D.2060905@oracle.com> <549C019C.4070803@oracle.com> <549C0B74.6000900@oracle.com> Message-ID: <549C0B88.9080408@oracle.com> Looks good. Thanks, Filipp. On 12/25/2014 05:04 PM, Dmitrij Pochepko wrote: > Hi, > > please take a look at fixed version > > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.04 > > Thanks, > Dmitrij >> >> On 12/25/2014 03:12 PM, Filipp Zhinkin wrote: >>> Dmitrij, >>> >>> I believe that it should be "@bug 8015774". >> agree >>> >>> Now DtraceRunner::runDtrace isn't checking exit code at all. >>> I think that it should assert on zero exit code. >> no, it shouldn't it should be a part of custom implementation of >> DtraceResultsAnalyzer::analyze. >> >> Dima, could you please add exit code check into >> SegmentedCodeCacheDtraceTest.SegmentedCodeCacheDtraceResultsAnalyzer::analyze >> >>> >>> Thanks, >>> Filipp. >>> >>> On 12/25/2014 04:19 PM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> new webrev: >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 >>>> I've added @bug tag >>>> and moved process guard to DtraceRunner::dtraceAvailable >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi Dmitrij, >>>>> >>>>> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >>>>> It means that the test will pass even if traced JVM crashed. >>>>> >>>>> I can name several issues that were found accidentally, because tests >>>>> didn't care about a crash. >>>>> >>>>> Are there any other sane reasons for DTrace to return non-zero exit code >>>>> except lack of privileges? >>>>> Igor's suggestion will prevent us from running DTrace without required >>>>> privileges, so I'd prefer to see the test failure instead of a >>>>> warning in case >>>>> of non-zero exit code returned by DTrace. >>>>> >>>>> Also, please add @bug to the test. >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>>>>> I'd prefer to check privileges by running dtrace against dtrace; >>>>>> and do it in DtraceRunner::dtraceAvailable, smth like >>>>>> >>>>>>> result = false; >>>>>>> dtrace = getDtracePath(); >>>>>>> if ($dtrace) { >>>>>>> $dtrace $dtrace >>>>>>> result = $? == 0; >>>>>>> } >>>>>>> return $result; >>>>>> >>>>>> >>>>>> Igor >>>>>> >>>>>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> i've placed a guard which skips test in case dtrace exits with >>>>>>> non-zero >>>>>>> code. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> Hi, >>>>>>>> >>>>>>>> There is one more issues related to these tests(not directly). >>>>>>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>>>>>> additional previleges for launching user. >>>>>>>> Perhaps it's just user to be granted previleges in jprt solaris >>>>>>>> hosts... >>>>>>>> Not sure about some guard in tests... the only way i know so far >>>>>>>> is to >>>>>>>> just try launching dtrace and parse output >>>>>>>> saying about missing previleges, but it doesn't seem to be good >>>>>>>> solution. >>>>>>>> I think test should assume to be launched in correct environment and >>>>>>>> in case it's failed because of previleges, evaluating engineer >>>>>>>> starting to work on respective env. issue... >>>>>>>> Does anybody have some additional concerns? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>>> >>>>>>>>> Hi Dmitrij, >>>>>>>>> >>>>>>>>> >>>>>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>>>>> >>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>> >>>>>>>>> 42 public static final String >>>>>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>> >>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>> >>>>>>>>> >>>>>>>>> Otherwise, looks good. >>>>>>>>> Please, consider it reviewed (no need to re-review). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>>>>> Hi, >>>>>>>>>> please review updated webrev >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dmitrij >>>>>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for catching these issues. >>>>>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>>>>> times"? >>>>>>>>>>> >>>>>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>>>>> It is because the class names are pretty big. >>>>>>>>>>> It would simplify the code and improve readability, right? >>>>>>>>>>> >>>>>>>>>>> You already do it two times: >>>>>>>>>>> 179 List tml >>>>>>>>>>> 180 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> ... >>>>>>>>>>> 235 List mlist >>>>>>>>>>> 236 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> >>>>>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>>>>> static final List MLIST = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>>>>> >>>>>>>>>>> 75 String params = MLIST.stream() >>>>>>>>>>> ... >>>>>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>>>>> ... >>>>>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>>>>> These lines will go away: >>>>>>>>>>> 179 List tml >>>>>>>>>>> 180 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> ... >>>>>>>>>>> 235 List mlist >>>>>>>>>>> 236 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>>>>> The MLIST will be in a context for the inner classes, and so, >>>>>>>>>>> needs >>>>>>>>>>> no prefixing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dmitrij >>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It looks good in general. >>>>>>>>>>>>> Some minor comments are below. >>>>>>>>>>>>> >>>>>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 42 public static final String >>>>>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>>>>> >>>>>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>>>>> 61 = >>>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>>>>> ... >>>>>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>>>>>> JAVA_OPTS, >>>>>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), >>>>>>>>>>>>> params, >>>>>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>>>>> >>>>>>>>>>>>> 75 String params = >>>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>>>>> ... >>>>>>>>>>>>> 179 List tml >>>>>>>>>>>>> 180 = >>>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>>>> ... >>>>>>>>>>>>> 235 List mlist >>>>>>>>>>>>> 236 = >>>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review changes for >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>>>>> codecache feature >>>>>>>>>>>>>> >>>>>>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>>>>>> script is also present >>>>>>>>>>>>>> (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>>>>>> analyzing results using class >>>>>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>>>>> usefull common code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Additional note: Please note that this path assumes that fix >>>>>>>>>>>>>> for >>>>>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>>>>>> also applied. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Dmitrij >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> > From Alan.Bateman at oracle.com Sun Dec 28 14:47:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Dec 2014 14:47:16 +0000 Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved In-Reply-To: <5e6a7ea3-1090-4158-9779-d3312d188868.maildroid@localhost> References: <5e6a7ea3-1090-4158-9779-d3312d188868.maildroid@localhost> Message-ID: <54A017F4.4090504@oracle.com> On 24/12/2014 16:11, dmitry.samersoff at oracle.com wrote: > Looks good for me (not a reviewer). > > --Dmitry Just an FYI that we moved from using @ignore to using an exclude list (jtreg -exclude jdk/test/ProblemList.txt) a few years ago. The reason is that it's more flexible than @ignore in that tests can be excluded on a per OS/arch basis. -Alan From jaroslav.bachorik at oracle.com Mon Dec 29 11:04:37 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 29 Dec 2014 12:04:37 +0100 Subject: RFR 8068233: java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is still in exclude list Message-ID: <54A13545.8050507@oracle.com> Please, review this simple ProblemList.txt update Issue : https://bugs.openjdk.java.net/browse/JDK-8068233 Webrev: http://cr.openjdk.java.net/~jbachorik/8068233/webrev.00 Part of the fix for JDK-8058506 was lost after incorrect merging of repo during modularization of JDK. This fix reintroduces the lost change. Thanks, -JB- From chris.hegarty at oracle.com Mon Dec 29 12:49:07 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 29 Dec 2014 12:49:07 +0000 Subject: RFR 8068233: java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is still in exclude list In-Reply-To: <54A13545.8050507@oracle.com> References: <54A13545.8050507@oracle.com> Message-ID: > On 29 Dec 2014, at 11:04, Jaroslav Bachorik wrote: > > Please, review this simple ProblemList.txt update > > Issue : https://bugs.openjdk.java.net/browse/JDK-8068233 > Webrev: http://cr.openjdk.java.net/~jbachorik/8068233/webrev.00 > > Part of the fix for JDK-8058506 was lost after incorrect merging of repo during modularization of JDK. This fix reintroduces the lost change. Thanks Jaroslav, looks ok to me. -Chris. > Thanks, > > -JB- From claes.redestad at oracle.com Mon Dec 29 15:51:49 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 29 Dec 2014 16:51:49 +0100 Subject: RFR: 8028357: Unnecessary allocation in AliasFileParser Message-ID: <54A17895.3010707@oracle.com> Hi, some classes in jvmstat/perfdata code contains debug logging code predating the logging APIs, which provokes some unnecessary allocation in certain applications. Since the debug logging can't have been used for quite some time, I propose to remove it altogether rather than converting it to the j.u.l. framework. bug: https://bugs.openjdk.java.net/browse/JDK-8028357 webrev: http://cr.openjdk.java.net/~redestad/8028357/webrev.01/ /Claes From alexander.kulyakhtin at oracle.com Wed Dec 24 14:32:43 2014 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 24 Dec 2014 06:32:43 -0800 (PST) Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved Message-ID: <1191c753-dc8f-415f-86ae-0182bef301b8@default> Hi, Could I, please, have a review of this fix. This is a oneline change to quarantine a test until JDK-8068162 is resolved bug: https://bugs.openjdk.java.net/browse/JDK-8068242 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00/ @ignore JDK-8068162 added to the test to have it ignored until JDK-8068162 is resolved Thanks, Alexander From alexander.kulyakhtin at oracle.com Thu Dec 25 12:45:16 2014 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 25 Dec 2014 04:45:16 -0800 (PST) Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved Message-ID: <05478eef-6b62-4087-a888-aef42a437259@default> Hi, Could someone, please, push the fix reviewed below? This is just one-line change to quarantine a test while the fix is being worked on. bug: https://bugs.openjdk.java.net/browse/JDK-8068242 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00 / Thank you very much, Alexander ----- Original Message ----- From: jaroslav.bachorik at oracle.com To: dmitry.samersoff at oracle.com, serviceability-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com Sent: Wednesday, December 24, 2014 11:07:58 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved Reviewed. Merry Christmas, ho-ho-ho :) On 24 December 2014 17:11:15 CET, dmitry.samersoff at oracle.com wrote: Looks good for me (not a reviewer). --Dmitry -----Original Message----- From: Alexander Kulyakhtin To: serviceability-dev at openjdk.java.net Cc: "Dmitry ?????????? Samersoff" , Serguei Vladimirovich Spitsyn Sent: Wed, 24 Dec 2014 17:32 Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved Hi, Could I, please, have a review of this fix. This is a oneline change to quarantine a test until JDK- 8068162 is resolved bug: https://bugs.openjdk.java.net/browse/JDK-8068242 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00 / @ignore JDK- 8068162 added to the test to have it ignored until JDK- 8068162 is resolved Thanks, Alexander -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kulyakhtin at oracle.com Mon Dec 29 13:54:30 2014 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Mon, 29 Dec 2014 05:54:30 -0800 (PST) Subject: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved Message-ID: Alan, Thank you very much for the information. I'm going to remove the @ignore annotation from the JDK-8068242 test as soon as it's fixed, and will be using the ProblemList.txt for any future quarantine requests. Best regards, Alexander ----- Original Message ----- From: Alan.Bateman at oracle.com To: dmitry.samersoff at oracle.com, serviceability-dev at openjdk.java.net, alexander.kulyakhtin at oracle.com Sent: Sunday, December 28, 2014 5:47:18 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved On 24/12/2014 16:11, dmitry.samersoff at oracle.com wrote: > Looks good for me (not a reviewer). > > --Dmitry Just an FYI that we moved from using @ignore to using an exclude list (jtreg -exclude jdk/test/ProblemList.txt) a few years ago. The reason is that it's more flexible than @ignore in that tests can be excluded on a per OS/arch basis. -Alan From serguei.spitsyn at oracle.com Mon Dec 29 17:26:22 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Dec 2014 09:26:22 -0800 Subject: RFR 8068233: java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is still in exclude list In-Reply-To: <54A13545.8050507@oracle.com> References: <54A13545.8050507@oracle.com> Message-ID: <54A18EBE.7060500@oracle.com> Reviewed. Thanks, Serguei On 12/29/14 3:04 AM, Jaroslav Bachorik wrote: > Please, review this simple ProblemList.txt update > > Issue : https://bugs.openjdk.java.net/browse/JDK-8068233 > Webrev: http://cr.openjdk.java.net/~jbachorik/8068233/webrev.00 > > Part of the fix for JDK-8058506 was lost after incorrect merging of > repo during modularization of JDK. This fix reintroduces the lost change. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Dec 30 13:43:34 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 30 Dec 2014 14:43:34 +0100 Subject: RFR: 8028357: Unnecessary allocation in AliasFileParser In-Reply-To: <54A17895.3010707@oracle.com> References: <54A17895.3010707@oracle.com> Message-ID: <54A2AC06.6030705@oracle.com> On 29.12.2014 16:51, Claes Redestad wrote: > Hi, > > some classes in jvmstat/perfdata code contains debug logging code > predating the logging APIs, which > provokes some unnecessary allocation in certain applications. > > Since the debug logging can't have been used for quite some time, I > propose to remove it altogether > rather than converting it to the j.u.l. framework. While it's good to see the dead code gone I would prefer keeping the logging code just commented out - the logging code could be useful when investigating any future failures. Converting to j.u.l. wouldn't probably completely remove the unnecessary allocation (due to object arrays for varargs) unless you guard each log call for the required logging level. -JB- > > bug: https://bugs.openjdk.java.net/browse/JDK-8028357 > webrev: http://cr.openjdk.java.net/~redestad/8028357/webrev.01/ > > /Claes From claes.redestad at oracle.com Tue Dec 30 16:07:27 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 30 Dec 2014 17:07:27 +0100 Subject: RFR: 8028357: Unnecessary allocation in AliasFileParser In-Reply-To: <54A2AC06.6030705@oracle.com> References: <54A17895.3010707@oracle.com> <54A2AC06.6030705@oracle.com> Message-ID: <54A2CDBF.7010408@oracle.com> Hi Jaroslav, thanks for looking at this! On 2014-12-30 14:43, Jaroslav Bachorik wrote: > > While it's good to see the dead code gone I would prefer keeping the > logging code just commented out - the logging code could be useful > when investigating any future failures. Do you mean all of it, or just the utility methods? I'm in the habit of not checking in commented out code (due to potential for bit rot etc) and instead rely on recreating from VCS history, but I have no strong preference. How about leaving the non-trivial dumpAll/dump_entry_fixed-methods (which use the DEBUG flag but not the log/logln methods), but removing all log/logln calls? > > Converting to j.u.l. wouldn't probably completely remove the > unnecessary allocation (due to object arrays for varargs) unless you > guard each log call for the required logging level. Guards or simply using only single-parameter log methods in j.u.l is generally doable workarounds when performance matters so much that even the varargs allocation matters. I can only hope https://bugs.openjdk.java.net/browse/JDK-8013269 or similar will deal with removing that overhead generally, though. /Claes > > -JB- From jaroslav.bachorik at oracle.com Tue Dec 30 17:35:17 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 30 Dec 2014 18:35:17 +0100 Subject: RFR: 8028357: Unnecessary allocation in AliasFileParser In-Reply-To: <54A2CDBF.7010408@oracle.com> References: <54A17895.3010707@oracle.com> <54A2AC06.6030705@oracle.com> <54A2CDBF.7010408@oracle.com> Message-ID: <54A2E255.3080708@oracle.com> On 30.12.2014 17:07, Claes Redestad wrote: > Hi Jaroslav, thanks for looking at this! > > On 2014-12-30 14:43, Jaroslav Bachorik wrote: >> >> While it's good to see the dead code gone I would prefer keeping the >> logging code just commented out - the logging code could be useful >> when investigating any future failures. > > Do you mean all of it, or just the utility methods? I'm in the habit of > not checking in commented out code (due to potential for bit rot etc) > and instead rely on recreating from VCS history, but I have no strong > preference. As a matter of fact I don't like the commented out code much either. > > How about leaving the non-trivial dumpAll/dump_entry_fixed-methods > (which use the DEBUG flag but not the log/logln methods), but removing > all log/logln calls? The affected files are pretty stable so we could remove *all* the logging related methods. When a necessity arises to have a configurable logging we would just need to re-introduce it properly. This got me thinking - a comment warning about the possible performance issues when adding logging could be added as a courtesy to the later maintainers. -JB- > >> >> Converting to j.u.l. wouldn't probably completely remove the >> unnecessary allocation (due to object arrays for varargs) unless you >> guard each log call for the required logging level. > > Guards or simply using only single-parameter log methods in j.u.l is > generally doable workarounds when performance matters so much that even > the varargs allocation matters. I can only hope > https://bugs.openjdk.java.net/browse/JDK-8013269 or similar will deal > with removing that overhead generally, though. > > /Claes > >> >> -JB- > From claes.redestad at oracle.com Tue Dec 30 22:22:40 2014 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 30 Dec 2014 23:22:40 +0100 Subject: RFR: 8028357: Unnecessary allocation in AliasFileParser In-Reply-To: <54A2E255.3080708@oracle.com> References: <54A17895.3010707@oracle.com> <54A2AC06.6030705@oracle.com> <54A2CDBF.7010408@oracle.com> <54A2E255.3080708@oracle.com> Message-ID: <54A325B0.3070703@oracle.com> On 2014-12-30 18:35, Jaroslav Bachorik wrote: > The affected files are pretty stable so we could remove *all* the > logging related methods. When a necessity arises to have a > configurable logging we would just need to re-introduce it properly. Right, I'll leave the patch as-is when it comes to code changes. > This got me thinking - a comment warning about the possible > performance issues when adding logging could be added as a courtesy to > the later maintainers. If so, what should we write? I'm not sure we really need to be this cautious in this particular code, and I hope future maintainers will care about performance at least as much as we are without well-meaning warnings. I guess something like "// 8028357 removed old, inefficient debug logging" in place of the DEBUG declaration in each affected file wouldn't be too busy and also give future maintainers a handle to this changeset and thus this discussion. Would that suffice? /Claes > > -JB- From jaroslav.bachorik at oracle.com Wed Dec 31 11:16:01 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 31 Dec 2014 12:16:01 +0100 Subject: RFR: 8028357: Unnecessary allocation in AliasFileParser In-Reply-To: <54A325B0.3070703@oracle.com> References: <54A17895.3010707@oracle.com> <54A2AC06.6030705@oracle.com> <54A2CDBF.7010408@oracle.com> <54A2E255.3080708@oracle.com> <54A325B0.3070703@oracle.com> Message-ID: <54A3DAF1.60601@oracle.com> On 30.12.2014 23:22, Claes Redestad wrote: > > On 2014-12-30 18:35, Jaroslav Bachorik wrote: >> The affected files are pretty stable so we could remove *all* the >> logging related methods. When a necessity arises to have a >> configurable logging we would just need to re-introduce it properly. > > Right, I'll leave the patch as-is when it comes to code changes. > >> This got me thinking - a comment warning about the possible >> performance issues when adding logging could be added as a courtesy to >> the later maintainers. > > If so, what should we write? I'm not sure we really need to be this > cautious in this particular code, and I hope future maintainers will > care about performance at least as much as we are without well-meaning > warnings. Well, it might take time till they realize this code is performance sensitive (it took us some time :) So, why not to make it easier for the future ourselves? > > I guess something like "// 8028357 removed old, inefficient debug > logging" in place of the DEBUG declaration in each affected file > wouldn't be too busy and also give future maintainers a handle to this > changeset and thus this discussion. Would that suffice? Sounds good. Please, update the copyright years in the affected files before push. Reviewed. -JB- > > /Claes > >> >> -JB- > From serguei.spitsyn at oracle.com Wed Dec 31 17:42:28 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 31 Dec 2014 09:42:28 -0800 Subject: RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found Message-ID: <54A43584.6050707@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8068162 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/ Summary: The sun.misc.Unsafe:throwIllegalAccessError() method is used in place of a default interface method in the itable if a default method was not defined in the interface. This approach creates a problem when the class sun.misc.Unsafe is retransformed. The Method* pointer to the old (redefined) method in the itable triggers an assert (see the hs_err log in the bug report). The fix is to replace the old method in the itable with the latest method version. Testing: In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests Thanks, Serguei From coleen.phillimore at oracle.com Wed Dec 31 18:40:00 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 31 Dec 2014 13:40:00 -0500 Subject: RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54A43584.6050707@oracle.com> References: <54A43584.6050707@oracle.com> Message-ID: <54A44300.4010801@oracle.com> The adjustment should be in klassItable::adjust_method_entries() not the checking function. I don't think check_no_old_or_obsolete_entries is called in product mode. I still don't see how the first klassItable::adjust_method_entries() missed this function. Coleen On 12/31/14, 12:42 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8068162 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/ > > > > Summary: > > The sun.misc.Unsafe:throwIllegalAccessError() method is used in > place of a default > interface method in the itable if a default method was not defined > in the interface. > > This approach creates a problem when the class sun.misc.Unsafe is > retransformed. > The Method* pointer to the old (redefined) method in the itable > triggers an assert > (see the hs_err log in the bug report). > > The fix is to replace the old method in the itable with the latest > method version. > > > Testing: > In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Wed Dec 31 18:50:10 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 31 Dec 2014 10:50:10 -0800 Subject: RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54A44300.4010801@oracle.com> References: <54A43584.6050707@oracle.com> <54A44300.4010801@oracle.com> Message-ID: <54A44562.3090207@oracle.com> Colleen, Thank you for a quick review. You are right, this is a good catch! I need to rework my fix as it is incorrect in general. On 12/31/14 10:40 AM, Coleen Phillimore wrote: > > The adjustment should be in klassItable::adjust_method_entries() not > the checking function. I don't think check_no_old_or_obsolete_entries > is called in product mode. > > I still don't see how the first klassItable::adjust_method_entries() > missed this function. The Unsafe::throw_illegal_access is added to other itables, not to the one that belongs to the class Unsafe. Thanks, Serguei > > Coleen > > On 12/31/14, 12:42 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8068162 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/ >> >> >> >> Summary: >> >> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >> place of a default >> interface method in the itable if a default method was not defined >> in the interface. >> >> This approach creates a problem when the class sun.misc.Unsafe is >> retransformed. >> The Method* pointer to the old (redefined) method in the itable >> triggers an assert >> (see the hs_err log in the bug report). >> >> The fix is to replace the old method in the itable with the latest >> method version. >> >> >> Testing: >> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >> >> >> Thanks, >> Serguei >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: